Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best way to secure an AJAX app

I am currently working on the authentication of an AJAX based site, and was wondering if anybody had any reccomendations on best practices for this sort of thing.

My original approach was a cookie based system. Essentially I set a cookie with an auth code, and every data access changed the cookie. As well, whenever there was a failed authentication, all sessions by that user were de-authenticated, to keep hijackers out. To hijack a session, somebody would have to leave themselves logged in, and a hacker would need to have the very last cookie update sent to spoof a session.

Unfortunatley, due to the nature of AJAX, when making multiple requests quickly, they might come back out of order, setting the cookie wrong, and breaking the session, so I need to reimplement.

My ideas were:

  • A decidedly less secure session based method
  • using SSL over the whole site (seems like overkill)
  • Using an iFrame which is ssl authenticated to do secure transactions (I just sorta assume this is possible, with a little bit of jquery hacking)

The issue is not the data being transferred, the only concern is that somebody might get control over an account that is not theirs.

A decidedly less secure session based method

like image 942
user10520 Avatar asked Sep 23 '08 03:09

user10520


People also ask

Is AJAX secure or not?

AJAX Security: Server SideAJAX-based Web applications use the same server-side security schemes of regular Web applications. You specify authentication, authorization, and data protection requirements in your web. xml file (declarative) or in your program (programmatic).

What are the security issues with AJAX?

The Ajax calls are sent in plain text format, this might lead to insecure database access. The data gets stored on the clients browser, thus making the data available to anyone. It also allows monitoring browsing sessions by inserting scripts.

What is AJAX in Javascript with example?

AJAX allows web pages to be updated asynchronously by exchanging data with a web server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page.


3 Answers

Personally, I have not found using SSL for the entire site (or most of it) to be overkill. Maybe a while ago when speeds and feeds were slower. Now I wouldn't hesitate to put any part of a site under SSL.

If you've decided that using SSL for the entire site is acceptable, you might consider just using the old "Basic Authentication" where the server returns the 401 response which causes the browser to prompt for username/password. If your application can live with this type of login, is works great for AJAX and all other accesses to your site because the browser handles re-submitting requests with appropriate credentials (and it is safe if you use SSL, but only if you use SSL -- don't use Basic auth with plain http!).

like image 113
andy Avatar answered Oct 10 '22 18:10

andy


SSL is a must, preventing transparent proxy connections that could be used by several users. Then I'd simply check the incoming ip address with the one that got authenticated.

Re-authenticate:

  • as soon as the ip address changes
  • on a time out bigger than n seconds without any request
  • individually on any important transaction
like image 32
Oli Avatar answered Oct 10 '22 19:10

Oli


A common solution is to hash the user's session id and pass that in with every request to ensure the request is coming from a valid user (see this slideshow). This is reasonably secure from a CSRF perspective, but if someone was sniffing the data it could be intercepted. Depending on your needs, ssl is always going to be the most secure method.

like image 37
slashnick Avatar answered Oct 10 '22 17:10

slashnick