开发者

Question about AJAX safety please inquire

开发者 https://www.devze.com 2023-02-19 08:05 出处:网络
I have a social network that I am creating and have a security question. I have the ability to have friends on the website and when you request a friendit would be a button that would run a script wit

I have a social network that I am creating and have a security question. I have the ability to have friends on the website and when you request a friend it would be a button that would run a script with AJAX using jQuery.

I know that javascript can be easily hacked and also read here http://www.acunetix.com/websitesecurity/ajax.htm that AJAX is not as secure as it would seem. They state that "Since XML HTTP requests function by using the same protocol as all else on the web (HTTP), technically speaking, AJAX-based web applications are 开发者_如何学编程vulnerable to the same hacking methodologies as ‘normal’ applications" .

So basically I don't want a worm to just keep running friend requests through my AJAX function and someone signs on the site and they have 14 million friend requests. This is also an issue with several other AJAX scripts that I run on the site. The question that I have is that should I just keep everything server side. I am using php so should every friend request just be a reload of the page as much as I would like to avoid such a thing? Please any help would be greatly appreciated.


If you have security concerns, they aren't unique to ajax, but there are simple ways to make things harder to mess with.

1) As Diodeus says - absolutely don't let people use your services without them being authenticated via a session. Same as any other page on a web site that requires you to be logged in.

2) Make session hijacking harder by embedding client info into the session key (cookie) and verifying it at the server, e.g. IP address, browser version. This can still be spoofed, though.

3) If a particular session makes more than x requests in a certain time period (e.g. 10 in a minute), log them out and ban them for an hour. Set a higher limit to ban them until restored by an admin. Have the code send yourself an email whenever this happens so you know if you ever have a problem.

4) If you are really worried, then use SSL. This is really the only way to absolutely prevent session hijacking (other than implementing your own private key encryption mechanism for session data).

5) If not using SSL you can't stop the possibility of session hijacking, but you CAN protect your user's passwords from being snooped easily. When authenticating, do this:

  • Client script requests salt from the server (a random string)
  • Server sends salt to client and remembers it with the session
  • Client hashes the password using Sha-256 e.g., with the salt, and authenticates with their username & hashed password. Server hashes password associated with the user at its own end using same salt, and authenticates if it matches the hash sent by the client. Server forgets salt it used this one time.

This way, someone watching a session could only see the hashed password, and because the hash is different every time, they couldn't actually log in again using that hash against your service. You still can't stop them from hijacking the session, but you can stop them from seeing your users' passwords or being able to log in on their own.

In reality, session hijacking is not all that common, though the high-profile implementation is, of course, facebook via wifi. If someone comes out with a Firefox plugin to hack your social network, then you should be thrilled because you know you've made it.


These are not problems specific to AJAX. All it comes down to is checking and sanitizing your data. I assume users have to register/login before they can add friends (after all, how else would you keep track of who's friends with whom?) so here are some obvious points to consider:

  • Add a CAPTCHA or similar to your registration process to cut down on bot users. reCAPTCHA seems to be the industry standard these days (and is very easy to set up).
  • When processing an AJAX call, make sure the user is allowed to do what he is doing (i.e. is he logged in, has he activated his account, etc)
  • When processing a friend request, ignore duplicates. People sometimes tend to ignore friend requests on purpose, and they probably don't want to get the invite again when the inviter gets impatient.
  • Find a way to keep track of suspicious behaviour. If a user has sent 50 friend requests in the past two seconds, odds are it might be a bot. Block the account temporarily and have a human check it out. It might also be a good idea to hide friend requests from blocked users.

There's a whole lot more, but these should get you started.


Set a login cookie on the client. Send the cookie value with the ajax request and validate it on the server.


I'm not sure I fully understand, because if there was some worm or whatever submitting AJAX requests, why couldn't the same worm make non-ajax requests?

Either way you should definitely have server-side validation to make sure the request is valid. Whether or not you want to have some validation regarding the number of friend requests that can be made is independent of whether you use ajax or not.


There's really no such thing as AJAX. The term AJAX is a general description of a way of organizing things. A so-called "AJAX" request is just an HTTP GET or PUT.

0

精彩评论

暂无评论...
验证码 换一张
取 消