• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Ajax Security Libraries

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Are there libraries that focus on the security aspects of using Ajax? If so, which one(s) have you used and/or liked the most? Thanks,

Andrew.
 
Author
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm...

By its nature Ajax (XMLHttpRequest) is subject to the same security constraints as the Web Browser. For example you cannot violate same origin policy. Would you then be referring to the server side or something else?

Christian
[ February 21, 2006: Message edited by: Christian Gross ]
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
DWR has a pretty good way to expose API's along with the ability to specify access control based on J2EE roles. See http://getahead.ltd.uk/dwr/security

Sanjiv
 
Christian Gross
Author
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm....

I had a bit of think and with Ajax being separated from the server the bigger issue of trusted client is raised. One could ask the question how do I know that the request is coming from the client that I created. I suppose the answer is that you don't! Does this matter? I think it would as we begin writing larger Ajax applications. It would involve sending and receiving PKI signatures.

Is this more along the lines of what you were thinking?

Christian
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just to add to the discussion a bit more, I was interviewed for an article a few weeks ago on secuirty here: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1164745,00.html .

What I say in there may surprise you on that it is not much different than what you have been doing already.

Eric
 
Sanjiv Jivan
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Christian,
Just wondering whay you're viewing this as anything different from simply client authentication (which could be either basic, form or client certificate authentication). Client certificate authentication may be a more secure form of authentication than basic or form, but its just one type of client authentication.

Sanjiv
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
XmlHttpRequest has access to the HTTP headers, so HTTP authentication can be used if need be, and the connection can be over SSL. Apart from that all the usual precautions need to be applied (XSS, SQL-injection, etc). In that regard AJAX is really no different than any other web app.
 
Christian Gross
Author
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sanjiv,

When I wrote the entry I was thinking of online games. I remember that one of the early online games exposed its API and the result were rogue games that cheated. The reason why this occured is because the game used an extensive API to distribute the logic between the gamer and the server. Any hacker that could reverse engineer the data sent between the client and server could give themselves extra energy, etc.

When an Ajax application is granularized to the extend of an online game I think there is a real risk having "rogue" clients. Rogue clients could use the Ajax application in ways we have not considered before. That could be good, and bad. From what I have seen in the online game community the solution is to use DRM, and hence why I thought the same would be a solution for Ajax.
 
Andrew Christoffersen
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Authentication was definately what I was getting at, like you mentioned, figuring out if the ajax request really came from where you think it came. Currently I pass along a session id with all ajax requests, which causes a logout if it doesn't match up with the database. This seems like a good way to make sure the request is coming from the user you think it is.

Of course the user can always view your javascript code, and therefore I think the biggest thing in security is to not give the client too much power! With more of the logic existing on the client side, and having to often maintain duplicate models on both the client and server, it is ultimately up to the server what to do with the ajax requests. Thanks,

Andrew.
 
Christian Gross
Author
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew:

hmm, I would say giving the client power is the intent behind Ajax. You want to let the client wire together the data that is sent from the client and received from the server. I would also say, part of the reason behind REST and Web Services is to avoid duplicate models on the client and server.

So while authentication does say "User A is user A", does it say, "User A is using Application A?" I am tempted to believe not. Though in a Web Service world that uses SOA, do we care if User A is using Application A? Does this mean we must for Ajax applications consider the client as untrustworthy?

Just rambling here...
 
Eric Pascarello
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Christian Gross:

So while authentication does say "User A is user A", does it say, "User A is using Application A?" I am tempted to believe not. Though in a Web Service world that uses SOA, do we care if User A is using Application A? Does this mean we must for Ajax applications consider the client as untrustworthy?



This does not apply just to Ajax, it applies to any web application. A form can be hacked in the same ways. Just like what I said in my article.

Eric
 
Christian Gross
Author
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eric: Yes you are right and agree with, but to bring this discussion whole circle. This is why I was thinking of PKI signatures. Using PKI signatures, and DRM we could say, "User A is using Application A".
The reason why I am thinking about this is that I used to be against DRM, but there are definite reasons for DRM. In the case of Ajax or any Web application I want to certify that only specific users can access my Web Service.

Case in point is EBay. The EBay Web Service API's are huge, and expose the guts of EBay. To avoid problems EBay requires certification using a primitive DRM. If you pull a bait and switch (eg get verify on one application, and use another) on EBay then your license is suspended immediately. They can tell if you switch apps.

Another case in point is the new Alexa Amazon Web Service API's. They use a primitive DRM to verify who you are and what requests you are making.
[ February 21, 2006: Message edited by: Christian Gross ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic