views:

128

answers:

3

I am considering using AHAH extensively on a project and am concerned about security. Couldn't an attacker inject malicious code into my response that would then be executed in the client? If my AJAX response is JSON, I don't have to worry about this because if things are tampered with the JSON will no longer be valid.

On the other hand. It doesn't seem that AHAH is any greater risk than any normal non-https request. Is there something that I am missing or what are some other thoughts?

+3  A: 

Couldn't an attacker inject malicious code into my response that would then be executed in the client?

Couldn't they do that to a normal page that does not have Ajax? Ajax is a normal HTTP request. There is nothing new here, same security rules apply.

If they can tamper with HTML in AHAH, they can tamper with the JSON/XML/Text in those requests so it is valid.

epascarello
A: 

I've used this technique here and there over the course of 4-5 years and never really had an issue with it. You'll want to be aware of any issues as would be a concern in any JS-heavy app.

If your app requests data from 'xxx.com' and 'xxx.com' isn't you, or if your server is emitting malicious HTML/javascript without your knowledge, you have bigger concerns than the choice of data-transmission technique.

Chris Miller
This is basically the answer I was expecting but just wanted to make sure there wasn't something I was missing.
Icode4food
@jeffreymb oah yeah your just missing dom based xss.
Rook
A: 

There are very few security concerns with JavaScript when compared to server side code like PHP. One issue that you must be aware of in JavaScript is Dom Based XSS.

Rook
AHAH is not a library. DOM Based XSS can apply to the php page too. Just need an injection spot in your code.
epascarello
@epascarello you are mistaken, dom based xss *can be* completely and totally independent of server side code. You should really read more before posting. (and so should I, although I'm still correct :)
Rook
How does the XSS code get into the page? There has to be a flaw somewhere. Browser level, Server Level, User Level, or a man in the middle attack. The server language does not matter, but the code has to get into the page somehow.
epascarello
@epascarello Oah man please read the owasp link. JavaScript can read input like the URL and then write it to the page.
Rook
@TheRook I know what that page says, I have done talks at OWASP DC meetings about Ajax security. How does the content from that URL get into the page in the first place? The page has to write it to the page for the vulerability to take place. Just adding any JavaScript to a QueryString parameter is NOT going to inject code into the page by itself. Either JavaScript, PHP, C#, Java, CGIs, etc need to take that code in the querysting and inject it into the page. It is XSS 101. Great list of XSS exploits here: http://ha.ckers.org/xss.html
epascarello
@epascarello `document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");`
Rook
@epascarello I don't need a 101 on xss, you should read my profile and read more about Dom Based XSS.
Rook
@TheRook, I did read it when I first looked at your answer. My only response is how does that document.write line get into the page? Please explain that to a guy that knows nothing on this subject.
epascarello
I will answer my question I posed. This attack is the same thing as the backend doing <%= Request.QueryString["default"] %> The only difference is the level of where it happens. The payload is the same in both cases. It is an XSS attack where JavaScript adds it into the page.
epascarello
@epascarello very good, that is why dom based xss is differnt, it is a vulnerability in JavaScript code and not the server side. I have also given talks at the Phoenix owasp chapter, I like owasp a lot and I like contributing to their wiki.
Rook