| |||||||||||||
|
| |||||||||||||
AJAX and securityAJAX and securityPosted Sep 7, 2006 4:27 UTC (Thu) by mrshiny (subscriber, #4266)Parent article: AJAX and security
I'm curious about real exploits that are made possible by AJAX that don't exist otherwise.
Frankly, from the server's perspective, you still have an untrustworthy client making requests to a publicly available service. This is not new. The fact that you can dynamically request part of a page instead of a whole page changes nothing.
Also, the notion that SQL Injection or XSS attacks are somehow made worse in the presence of AJAX is strange to me. For one thing, XSS has always been able to use XmlHttpRequest, and can do so even if the host site doesn't normally use AJAX. Also, SQL Injection is a plain case of developers writing bad software, just like buffer overflows. This is a question of developer education and has nothing to do with AJAX.
Finally, an AJAX Bridge sounds just like an HTTP proxy; running an open proxy is stupid (from a security standpoint) and so is running an AJAX bridge.
The only real "news" here is that an AJAX enabled site may require javascript, which is true, but I think frankly uninteresting. Most users have found that navigating with scripts turned off has been basically impossible for years on most sites.
(Log in to post comments)
AJAX and security Posted Sep 7, 2006 7:02 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] what's different is that in a traditional web application (CGI, Java, PHP, etc) you know that your internal functions really are internal, they can't be called without going though your main pages, and you can do your input validation in those main pages.
With AJAX, those 'internal' functions are being called over the Internet by your app running on the client. At that point they are no longer internal, they are exposed to the world and each one needs to do it's own input validation from scratch, they can't assume _any_ filtering by the rest of the app.
unfortunantly the people pushing the AJAX approach tend to ignore this fact, they treat all the little helper programs as if they were only going to receive input from the app, and so they tend to have lots of problems as a result.
it's not that these vunerabilities are unique to AJAX, it's just that the opportunity to make these sorts of mistakes are much more common, and the prevaling mindset isn't prompting people to look out for them (after all, if the server side is written in Java it must be safe, right? ;-)
a suitably paranoid and carefully written AJAX app can be just as safe as any other app (in fact, since each function tends to be called as it's own URL there are forces pushing for better seperation of different functions into different, small, easily checked programs rather then throwing everything into one large, complex, monolithic program), but without the extra care it is far more likely to have security holes in it
<security rant>
the key thing to remember is that any input any routine receives over a communication channel needs to be treated with suspicion, it doesn't matter what you _intend_ to have come over that channel, the fact that that channel is external to your routine makes any data that comes over it suspect.
it doesn't matter if that channel is the Internet, a call across a local network, a modem line, or a file written to the disk by another program, a unix socket, or anything else you want to name. you can't really _know_ that the source of the data is the program that you think it is.
Even encryption is of limited help here, if the other endpoint gets comprimised the new owner of it has access to everything on that machine, including any encryption keys stored there, and the ability to initiate traffic from that 'trusted' IP address.
there have been servers comprimised via certificate authenticated SSH (without there being any known bugs in the SSH software) a remote machine gets comprimised and then that machine is 'trusted' (becouse it presents a known cert and IP) to the real target machine.
this does mean that layered, component software requires more checks then monolithic applications, but it also means that the bad guy has more things they have to go through, and as the bad guy is working on breaking each of the layers, you have more chances to catch him and respond (even if each layer is vunerable to the exact same bug you buy a little time as the bad guy has to learn what the next layer is)
remember, that if your component is only supposed to be connected to by your own application (and has network defenses in place to help enforce this), invalid input to your component isn't just a typo to be corrected or silently ignored, it's an indication of an active attacker who has already broken through your first line(s) of defense and you should start setting off alarms (this is assuming your other components are written properly, if they aren't this is an indication of bugs in those components, which are probably still worth setting off alarms for :-)
with AJAX your internet exposed components probably don't have the benifit of being able to say that they only get connected to by your own stuff, so you can't set off as many alarms (although in a suitably important application you could do things with client certs issued to each machine during a login or registration process, at which time invalid input with a valid cert indicates a compramised client machine)
</security rant>
David Lang
AJAX and security Posted Sep 8, 2006 15:32 UTC (Fri) by jbellis (guest, #14804) [Link] "With AJAX, those 'internal' functions are being called over the Internet by your app running on the client."
If your framework really exposes all internal functions to AJAX callers, you should use a better framework.
(If not, such hyperbole is silly.)
AJAX and security Posted Sep 8, 2006 16:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] I'm not saying that ALL of your internal functions are exposed, but the various things that are called by the browser javascript to perform actions are viewed by most ajax folks as being internal functions
i.e. there is never any intention of a browser connecting to them directly, only the javascript that's loaded from another page ever connects to it. and the viewpoint is that since you control that javascript you control the input to those routines.
these are the 'internal' functions that are exposed.
really good architects won't consider these internal, but far to many people do :-)
AJAX and security Posted Sep 8, 2006 22:34 UTC (Fri) by mrshiny (subscriber, #4266) [Link] But frankly this is not a new phenomenon. There have been tons of sites in the past that have done things like generate SQL on the client, or store permissions in cookies, or other stupid things. Ajax changes nothing; saying that there are security issues with Ajax is misleading.
The article seems to imply (in its headline mainly) that Ajax has security problems, and conversely that not using Ajax is secure. This article would have been better conceived as an article about web programming, with only a single paragraph dedicated to Ajax in particular. The security risks are real; let's tell all web programmers about them, instead of scaring people away from Ajax, or giving non-Ajax users a false sense of security.
AJAX and security Posted Sep 9, 2006 16:03 UTC (Sat) by dps (subscriber, #5725) [Link] I do not think AJAX exposes internals more than traditional web apps, but it might well lead to a more featurefull HTTP interface and therefore increase the range of things that can be attacked. The more you shift work onto the client the bigger this effect becomes.
Even in a tradiaional web app how do you know that your a backend was really called by pressing a button on its front end? AFAIK this is too difficult and instead the focus is usually on making sure the backend does what is supposed to do and nothing else. This might include not doing anything for those not duly authorised.
I know you can make HTTP requests within java applets wuithout relaoding the page, pass the results back to javascript and use DOM methods to change the page based on the results. The "internal" pages involved could also be (ab)used from elsewhere and need to take account of that fact.
AJAX and security Posted Sep 7, 2006 13:28 UTC (Thu) by erich (subscriber, #7127) [Link] Hi,Ajax doesn't really allow you to do new stuff - so why should it allow new exploits? It just makes them fancier.
Face it: Ajax makes code auditing and such things a lot harder. If you're using Java, you can run all kinds of code verification tools. Is there any such thing for Ajax? Do you have unit tests for your ajax?
AJAX and security Posted Sep 10, 2006 0:04 UTC (Sun) by mrshiny (subscriber, #4266) [Link] There should be no reason why you can't write unit tests for AJAX applications. For one thing, the server-side component can be easily tested by calling it from a test harness such as httpunit. The java-script side may be trickier, but nothing stops you from writing a javascript test harness, in fact there may be one.
Furthermore, as AJAX techniques become standardized, standard tools such as unit test libraries will become more widely available and used. Currently Ajax programming is very bare-bones; once there is a large body of AJAX code there will be corresponding tests.
AJAX and security Posted Sep 10, 2006 8:37 UTC (Sun) by dion (subscriber, #2764) [Link] Well, there are some very nice and easy units to test when using ajax, namely all the urls that the ajax code will run.
I thought the point of the article was that with ajax you have n+1 more urls to audit and that in itself might mean that it's harder to ensure security.
|
|
||||||||||||