I know all about SQL injections, and peeking into javascript files that a website uses, and also that GET requests contain all of the information in a URL.
Is there any security concern that is special to AJAX and only pertains to using AJAX?
For example, sending post requests via AJAX seems completely safe to me. Barring SQL injections, I can't think of one thing that could go wrong... is this the correct case?
Also, are "requests" of any kind that a user's browser sends or any information it receives available to be viewed by a third party who should not be viewing? And can that happen to AJAX post requests ('post' requests specifically; not 'get')?
It's like any other form of data input: validate your values, check the referrer, authenticate the session, use SSL.
Related
I know how to use ajax for submitting a form and all. What I am concerned about is, what is actually happening in the background when a form is submitted via ajax.
How are the values transferred? Encrypted or not? And what is the
need of specifying submission type, I mean get or post, if the URL is
not showing the form fields?
Edit: Found this on w3schools:
GET requests can be cached
GET requests remain in the browser history
GET requests can be bookmarked
GET requests should never be used when dealing with sensitive data
GET requests have length restrictions
GET requests should be used only to retrieve data
POST requests are never cached
POST requests do not remain in the browser history
POST requests cannot be bookmarked
POST requests have no restrictions on data length
How do these apply to ajax form submission?
Basically, when you Ajax-submit a form, it is doing exact same thing as what would happen when you as a user GET or POST submit a form - except that it is done in an asynchronous thread by the browser - i.e. called XMLHttpRequest.
If you submit form as a GET request, all of the form values are stitched together as parameter strings and appended to the URL (form's ACTION URL) - prefixed by a ?. This means anyone who can intercept that communication can read the submitted form data even if request is sent to a HTTPS URL. The POST method sends form data as a separate block (from the URL) and if URL is HTTPS then form data gets encrypted.
It looks like you are just starting out in the world of web development - welcome to the world of programming. I would recommend reading up on some good web development/programming books (I don't want to promote any particular book here). Amazon may help suggest few good ones under "Web Development" kind of search terms.
Also, I suggest that you read up a little on GET vs. POST by googling for it (I can only include one or two links - google will show you hundreds).
For the clear understanding & behind the scene things please refer the links given below.
http://www.jabet.com/
How does AJAX work?
Actually ajax request is same as the normal requests at the server end.
GET or POST has their own use cases. for example: GET has a limit of data transfer depending on the browsers from 1KB to 10 KB. where POST has no such limits.
For a server both AJAX & normal request both are same. so it depends on server code which method you wish to support.
ajax requests are NOT encrypted.
http://www.w3schools.com/tags/ref_httpmethods.asp
It looks like you want a very detailed answer so you can find it yourself:
Google it and read thoroughly the pages (wikipedia for example)
Read http://www.w3.org/TR/XMLHttpRequest/
Inspect the packets between your browser and the server
I am making one website in which the form is submitted using jQuery ajax. I have taken care of most of the security majors like HTTPS, session cookie, encryption etc.
Hence I have minimised the possibility of outside person sniffing or modify my data transfer.
But there can be a valid registered user who wants to play havoc by using Chrome inspect element. He can for example create a for loop in which is calls my jQuery ajax post call.
Can this be possible? How can I avoid this? I am unable to find a better alternative & resort once again to basic form post instead of ajax.
Thanks.
Anything you present client side can be messed with. A user will always be able to modify your front end code, and do what they want with it. This is why you need server side validation.
If you are worried about a repeating post call, it sounds like you are worried about a DOS attack I guess?
Your server configuration should be set up to detect frequent requests from the same user and deny service to it.
As the title may possibly suggest, I'm wondering what's more secure for AJAX requests: POST or GET. I can't work out which is better because they're both hidden from the user due to the URI being sent via. AJAX, not in the URL bar.
Thanks,
James
Neither add any security against either man-in-the-middle attacks or the end user. Both can be intercepted and tampered with using Wireshark, Firebug, or other tools.
If you want security against interception, you can use HTTPS. That does not prevent the user from sending requests manually, though.
It's almost trivially easy to inspect the contents of both post and get values. Your best bet, if you do not want the user to be able to get at that data directly, is to encrypt it, and / or send it over ssl.
There are no security differences between POST and GET used in AJAX. They are not hidden from the user - a simple tool like Fiddler would allow the user to see those requests. the payload in both is in plain text (ie, as your script created it). The only difference is that POST payload is in the body of the request and GET payload is in the query params of the URL.
They are not hidden from the user at all; install FireBug on FireFox and they are able to see the URI. Your choice of using GET and POST depends on the data sent; and if you going by REST standards, depending on the operation.
Treat an AJAX call as you would with information coming from the client through a form and through the address bar : Verify and sanctify.
They can view the page source and see where your target URL is and what parameters are being passed either way.
Lets consider next scenario: assume I have a web app, and authentication of users is performed through a modal dialog window (lets say, that when a user clicks login button, ajax request is sent and depending on the callback I either close the window or display an error), and I use only HTTP protocol. Why is it considered to be not secure way to do things?
Also, please make sure that a modal dialog window is taken into account, because this is vital info. There may be some data displayed underneath the dialog window and can be accessible if modality is broken.
The question includes both:
How can you break an app security by
utilizing ajax call?
Is Ajax HTTP less secure than a
regular form HTTP?
Whoever told you - he is wrong. The ajax through post is not less secure than post with regular forms. Just because it is the same thing.
Update 1 according to the last edit:
You cannot
No
Argument: the AJAX request is the same http request as any other (such as request sent by html form). Absolutely the same. So by definition it cannot be less or more secure.
I don't know how to explain more and what to say else: ajax is a http request. the same request as your browser does when you open SO page or when you post the SO question form.
I can rephrase your question to something like "Why A is less secure than A". Answer to it: A is not less secure than A, because A is A :-S
Any sensitive data should be channeled through HTTPS. GET data is sent in the querystring. POST data is sent in the HTTP Request header. Ajax can do both. BOTH are not secure. You need a channel level encryption to really secure it.
HTTP isn't secure for private data because the data is transmitted in plaintext. This can be intercepted anywhere between the client and server (eg. wifi.) Ajax over HTTPS would be much better.
I think the issue is that you are using http. No matter how you look at it it wont be secure. If you use https the ajax request will be just as secure as a html form.
Somy answer would be to use https and you will be all set.
I'm no security expert, but I think it might be more secure sending it over HTTPS. Just googling learns me that it can be done securely though:
http://www.indicthreads.com/1524/secure-ajax-based-user-authentication/
http://msdn.microsoft.com/en-us/magazine/cc793961.aspx (focused on ASP.NET)
etc.
Since browsers use the same network stack for HTTP and HTTPS, be it AJAX or not, there is no difference. All the headers, cookies, authentication, etc work exactly the same.
Why was it decided that using XMLHTTPRequest for doing XML calls should not do calls across the domain boundary? You can retrieve JavaScript, images, CSS, iframes, and just about any other content I can think of from other domains. Why are the Ajax HTTP requests not allowed to cross the domain boundaries? It seems like an odd limitation to put, considering the only way I could see it being abused, would be if someone were to inject Javascript into the page. However, in this case, you could simply add an img, script, or iframe element to the document to get it to request the third party URL and send it to the server.
[Edit]
Some of the answers point out the following reasons, let's point out the reasons they don't create a major reason to disallow this.
XSRF (Cross Site Request Forgery, also known as CSRF, XSRF)
Your can do XSRF attacks without using this at all. As a general rule, XMLHTTPRequest isn't used at all, simply because it's so hard to make an XMLHTTPRequest in a way that's compatible with all major browsers. It's much easier to just add an img tag to the URL if you want them to load your URL.
Posting to third party site
<script type="text/javascript">
$.post("http://some-bank.com/transfer-money.php",
{ amount: "10000", to_account: "xxxx" })
</script>
Could be accomplished with
<body onload="document.getElementById('InvisbleForm').submit()"
<div style="display:none">
<form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
<input type="hidden" name="amount" value="10000">
<input type="hidden" name="to_account" value="xxxxx">
</form>
</div>
</body>
JPunyon: why would you leave the vulnerability in a new feature
You aren't creating any more insecurities. You are just inconveniencing developers who want to use it in a way for good. Anybody who wants to use this feature for evil (aka awesome) could just use some other method of doing it.
Conclusion
I'm marking the answer from bobince as correct because he pointed out the critical problem. Because XMLHTTPRequest allows you to post, with credentials (cookies) to the destination site, and read the data sent back from the site, along with sending the persons credentials, you could orchestrate some javascript that would submit a series of forms, including confirmation forms, complete with any random keys generated that were put in place to try to prevent a XSRF. In this way, you could browse through the target site, like a bank, and the bank's webserver would be unable to tell that it wasn't just a regular user submitting all these forms.
Why are Ajax HTTP Requests not allowed to cross domain boundaries.
Because AJAX requests are (a) submitted with user credentials, and (b) allow the caller to read the returned data.
It is a combination of these factors that can result in a vulnerability. There are proposals to add a form of cross-domain AJAX that omits user credentials.
you could simply add an img, script, or iframe element to the document
None of those methods allow the caller to read the returned data.
(Except scripts where either it's deliberately set up to allow that, for permitted cross-domain scripting - or where someone's made a terrible cock-up.)
Your can do XSS attacks without using this at all. Posting to third party site
That's not an XSS attack. That's a cross-site request forgery attack (XSRF). There are known ways to solve XSRF attacks, such as including one-time or cryptographic tokens to verify that the submission came deliberately from the user and was not launched from attacker code.
If you allowed cross-domain AJAX you would lose this safeguard. The attacking code could request a page from the banking site, read any authorisation tokens on it, and submit them in a second AJAX request to perform the transfer. And that would be a cross-site scripting attack.
An important difference between the POST:
<body onload="document.getElementById('InvisbleForm').submit()" ...
and Ajax is that after doing any POST the browser will replace the page and after doing the Ajax call - not. The result of the POST will be:
Clearly visible to the user.
The attack will be stuck at this point because the response page from my-bank.com will take the control. No bank will implement a one-click-transfer.
The scenario of XSRF, if the cross domain Ajax would be allowed, will look like the following:
User somehow visits www.bad-guy.com.
If there no opened page to my-bank.com in other instance of the browser, the attack is unsuccessful.
But if such page is opened and the user has already entered his user-name/password, this means that there is a cookie for this session in the cache of the browser.
JavaScript code on the page from www.bad-guy.com makes an Ajax call to my-bank.com.
For the browser this is a regular HTTP call, it has to send the my-bank cookies to my-bank.com and it sends them.
Bank processes this request because it cannot distinguish this call from the regular activity of the user.
The fact that JavaScript code can read the response is not important. In the attack case this might be not necessary. What is really important is that the user in front of the computer will have no idea that this interaction takes place. He will look at nice pictures on the www.bad-guy.com page.
JavaScript code makes several other calls to my-bank.com if this is needed.
The gist is that no injection or any page tampering is needed.
A better solution might be to allow the call itself but not to send any cookies. This is very simple solution that does not require any extensive development. In many cases Ajax call goes to unprotected location and not sending cookies will not be a limitation.
The CORS (Cross Origin Resource Sharing) that is under discussion now, among other things, speaks about sending/not sending cookies.
Well, apparently you're not the only person that feels that way...
http://www.google.com/search?q=xmlhttp+cross+site
EDIT: There is an interesting discussion linked from the above search:
http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
Looks like proposals are under way to permit cross site xmlhttp requests (IE 8, FF3 etc.), although I wish they'd been there when I was writing the code for my sites :)
And then there's the problem of compatibility... It will be a while before it's ubiquitous.
When you send a HTTP request to the server, the cookies set by the server are also sent back by the browser to the server. The server uses those cookies to establish the fact that the user is logged in, etc.
This can be exploited by a malicious attacker who, with the help of some JavaScript, can steal information or perform unauthorised commands on other websites without the user knowing anything about this.
For example, one could ask an user to visit a site which has the following JavaScript code (assuming jQuery):
<script type="text/javascript">
$.post("http://some-bank.com/transfer-money.php",
{ amount: "10000", to_account: "xxxx" })
</script>
Now, if the user were really logged into the bank while the above code was executed, the attacker could have transferred USD 10K to the account XXX.
This kind of attacks are called Cross Site Request Forgery (XSRF). There is more info about this on Wikipedia.
It's mainly due to this reason the same-origin policy exists and browsers won't allow you to perform XMLHttpRequests on domains different from the origin.
There is some discussion going on to actually allow cross-domain XHR, but we have to see whether this really gets accepted.
It's a concern because it can be used for bad purposes, as you mentioned. It can also be used with good intent, and for that reason, cross domain protocols are being developed.
The two biggest concerns are when it is used in conjunction with cross-site scripting (XSS) and cross-site request forgery (CSRF). Both are serious threats (which is why they made it into the OWASP top 10 and the SANS 25).
the only way I could see it being abused, would be if someone were to inject Javascript
This is XSS Far too many apps are still vulnerable, and if browser security models don't prevent X-domain AJAX, they are opening their users to a considerable attack vector.
you could simply add an img, script, or iframe element to the document to get it to request the third party URL
Yes, but those will send a HTTP_REFERRER and (through other means) can be blocked to prevent CSRF. AJAX calls can spoof headers more easily and would allow other means of circumventing traditional CSRF protections.
I think another thing that separates this from a normal XSRF attack is that you can do stuff with the data you get back as well via javascript.
I don't know what the huge problem is? Have AJAX calls sent towards other domains firs sent to your application and then forwarded elsewhere with filtered data, parse the returned data if you really need to, and feed it to the user.
Handling sensitive AJAX requests? Nail down the incoming suckers by checking for headers, storing session time data or by filtering incoming IP addresses down to sources of you trust or your applications.
What I'd personally like to see in the future is rock solid security on all incoming requests by default on web servers, frameworks and CMSs, and then explicitly define resources that will parse request from outside sources.
With <form> you can post data, but you can't read it. With XHR you can do both.
Page like http://bank.example.com/display_my_password is safe against XSRF (assuming it only displays and not sets the password) and frames (they have same-origin policy). However cross-domain XHR would be a vulnerability.
You turn unsuspecting visitors into denial of service attackers.
Also, Imagine a cross site script that steals all your facebook stuff. It opens an IFrame and navigates to Facebook.com
You're already logged in to facebook (cookie) and it goes reads your data/friends. And does more nasties.