What happens if a user looks at my JavaScript file, copies the content of a function and sends a request to my server using AJAX? And is there a way to properly protect against this from happening?
+4
A:
The way to protected against this is no different to the way you protected against any web request. You make it so that your site requires some form of authentication (i.e. users have to log in) and don't do thing if the request is not properly authenticated.
Typically, when you make an AJAX request, cookies are also sent along with the request so you should just be able to use the same authentication method that you use for your regular requests with your AJAX requests.
Dean Harding
2010-06-04 05:58:54
Ahh makes sense. I just didn't know whether browsers had some sort of cross domain protection of some sort. Thanks bud.
Raphael Caixeta
2010-06-04 06:00:04
the browser wont allow xmlhttprequest from another server/domain. However if you are allowing json-p requests, it could happen, also someone could spoof the browser, treat requests for ajax like any other, as mentioned.
Tracker1
2010-06-04 06:10:03
+3
A:
As per codeka, there is no way to prevent someone from crafting their own Ajax query that is identical to the one you have in your Javascript request. Cross-domain protection will not necessarily protect you there, as they can, if they wished, just type the Javascript into the address bar for themselves while on a page on your site.
The only protection you have is to validate the input and parameters provided through the Ajax query on the server-side. Limit each PHP or Python or whatever response script to a very specific task, and check the input on the server-side. If something's wrong, respond with an error.
In short, there is no way to prevent someone from sending the request, but you can prevent them from doing something you don't want them to do on your server.
phsource
2010-06-04 06:01:41
A:
I guess you don't have to worry about that because of this cross domain protection...
Reigel
2010-06-04 06:02:19
That is no guarantee. You can just disable the cross-origin-policy in most browsers.
jAndy
2010-06-04 06:05:25
@jAndy - wooow! really??? did not know that... thanks, and can you give me some links to read? or something??
Reigel
2010-06-04 06:11:05
In Gecko Browsers you can even access it by calling `netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');` which an user has to verify. In IE check the settings for something like "allow cross-domain access". Chrome has a special commandline argument.
jAndy
2010-06-04 06:20:02
It's true you can disable it, but I seriously doubt this is a problem. The same-domain policy is enabled by default in all browser builds and the overwhelming majority of people (developers included) don't know they can disable this. If they do know and disable it anyway, they are voluntarily reducing security for the entire browser and for all websites. I think this setting is configurable for things like kiosks and intranet applications that have limited access to the Internet, even though now there are other standard techniques to break the same-domain barrier.
Andrew
2010-06-04 06:29:08
`don't know they can disable this`, I was shocked cause I'm one... hmmmm.... do I have to panic?... seriously? did not know this... any article please...
Reigel
2010-06-04 06:42:46
A:
Assuming that you need some form of authentication:
I guess you can maintain database session to validate if the request is coming from a genuine user for forged. Use encrypted cookies to store the session ID, and refer the cookie session ID to the database to validate the user
Chaitannya
2010-06-04 06:43:43