Create an Account
username: password:
 
  MemeStreams Logo

MemeStreams Discussion

search


This page contains all of the posts and discussion on MemeStreams referencing the following web page: Ajax Security Issues. You can find discussions on MemeStreams as you surf the web, even if you aren't a MemeStreams member, using the Threads Bookmarklet.

Ajax Security Issues
by Acidus at 10:13 am EDT, Aug 29, 2006

There are several security issues with having an Ajax enabled application. Some of them are traditional web security issues that are magnified because of Ajax, and some a new issues. Here are just a few. I refer you to my BlackHat presentation Ajax (in)Security for more info.

Old Issues:
Issues:Ajax applications have a larger attack surface.

Results: Its easer to hack your webapp. Traditional applications have a relatively few number of forms or other parts that accept user input. We already do a poor job protecting these (just look at Full Disclosure any given week). Some web apps accept file format input, and we do a really bad job securing that input (see numerous PNG/JPG attackers, WMF, ZIP attacks, etc). Ajax increases yet a 3rd type of application inputs, Web services. Most Ajax requests are destin for a web service that woudln't exist if the app didn't use Ajax. As a whole, web services are rarely protected because most programmers don't think of these are inputs, they think of them as functions. This is really bad when retrofitting a traditional application to an Ajax application. Before, the web service or function was hidden inside your enterprise with no way for the client to directly call it. With an Ajax app, large parts of the applicaitons API are now publicly exposed and are rarely secured.

Issue: Ajax applications are very complex. They are written in multiple languages, the code must work on multiple platforms/OSes, and they are multi-threaded.

Results:Ajax applications are much harder to debug and test than traditional applications. JavaScript is highly dynamic, loosly typed, and can add new exection paths as well as edit current execution paths in a program. This means most JavaScript errors are runtime errors and its very hard to examine all possible paths the program will take. This, coupled with the the asynch nature of Ajax means most Ajax apps contain deadlocks and race conditions that can be exploited.

New Issues:

Issue:Your application straddles the network and exists on both the client and the server.

Results:Attackers can see data types, return types, function names, and program flow of your application by analyzing the plaintext JavaScript. While you should push not business logic to the client, most people do and Ajax Frameworks like CPAINT/"Atlas" make it easier to make this mistake by abstracting a control. Programmers don't know (and don't want to know) how much of a control is on the client and how much is on the server. CPAINT makes it very easy to "export" or "share" a PHP function so your client code can call it directly. I've seen apps in the wild that have a webservice you can send PHP or Perl to that simply get past to an eval statement.

Issue: Ajax is something that on the client, not the server. Websites cannot turn it on or off

Result: Ajax has amplified the damage XSS attacks. Ajax allows XSS to make hidden, asynchronous HTTP requests that the browser will automatically add the necessary cookies and HTTP auth to. The XSS has full access to response as well. Even sites like Yahoo's webmail that don't "use" Ajax per say can still be contacted by an HTTP request that Ajax makes. Ajax has directly lead to the creation of self propagating XSS worms.

Issue: The Server cannot tell the difference between a request made by the browser in response to a user event (clicking on a link) and a request made by the browser because JavaScript told it to.

Result: As a user, you cannot prove beyond a reasonable doubt that you did or did not issue an HTTP request. The effects of this in a financial application are frightening.


 
RE: Ajax Security Issues
by k at 2:10 pm EDT, Aug 29, 2006

Acidus wrote:
There are several security issues with having an Ajax enabled application. Some of them are traditional web security issues that are magnified because of Ajax, and some a new issues. Here are just a few. I refer you to my BlackHat presentation Ajax (in)Security for more info.

...
Even sites like Yahoo's webmail that don't "use" Ajax per say can still be contacted by an HTTP request that Ajax makes.
...

Of course, we always expect great things from Acidus and it appears he's leading the way on AJAX... I'm sure the his book will become a well respected reference for many.

So, congrats!

p.s. I hope you'll forgive me my pedantry, but as you are about to publish again I feel obligated to point out that you meant to write "per se". That one's a particular peeve of mine, since people have a level of comfort with the word "say" and use "per" semi-regularly in other contexts (e.g. "Per Kathy, we're going to have our team meeting at Moes."). "Per say" actually *feels* right, which makes it all the more insidious.


  
RE: Ajax Security Issues
by Acidus at 3:22 pm EDT, Aug 29, 2006

k wrote:
p.s. I hope you'll forgive me my pedantry, but as you are about to publish again I feel obligated to point out that you meant to write "per se". That one's a particular peeve of mine, since people have a level of comfort with the word "say" and use "per" semi-regularly in other contexts (e.g. "Per Kathy, we're going to have our team meating at Moes."). "Per say" actually *feels* right, which makes it all the more insidious.

Are you offering to proof read? :-)


   
RE: Ajax Security Issues
by k at 10:36 pm EDT, Aug 29, 2006

Acidus wrote:

k wrote:
p.s. I hope you'll forgive me my pedantry, but as you are about to publish again I feel obligated to point out that you meant to write "per se". That one's a particular peeve of mine, since people have a level of comfort with the word "say" and use "per" semi-regularly in other contexts (e.g. "Per Kathy, we're going to have our team meating at Moes."). "Per say" actually *feels* right, which makes it all the more insidious.

Are you offering to proof read? :-)

haha, sure, why not :)


 
 
Powered By Industrial Memetics