As I found, it is possible to manipulate and change Ajax code in browser console by client. For example, Ajax wants to call a method and pass id to controller. As I mentioned above, how we can secure our code from interference by client?
Thank you all
Security must always be implemented on the server side, because anything you do on the client side can be ignored, overstep, modified, etc very easily. In fact, anyone can use software like Postman to make a completely custom HTML request to any server.
Don't ever rely on any client-side software in terms of security for your server. If you want keep your server safe, then make a safe server.
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.
i have the following problem:
i need to send some custom info with every request made by a WebBrowser control. For example one of the infos is the used app version.
Now i have already read here that it is impossible to set custom headers for a WebBrowser control.
I have already tried to intercept all requests and perform them on my own with a WebClient (or HttpWebRequest). It partially works but is very buggy and often throws errors.
Any other ideas how to send the custom infos with every request that is made by the WebBrowser control?
Is the web server you are interacting with your own? Could you just add a query string parameter for all the data you want? Something like
http://yourwebsite/YourPage.aspx?version=2
Then you'd be able to process it on the server, either during that request in the aspx page, or via the logfiles for the web server.
I suspect that as you can't modify the content that gets sent directly from the WebBrowser and that intercepting every call and acting as a proxy for every request, while still maintaining all browser functionality may be too cumbersome.
Instead I'd suggest sending an additional request with just the additional information you want to record every time you make a request.
That could lead to a lot of overhead so it might be easier to send this once and then pass a hash of it, or some other identifying key to the webpage (as a querystring parameter) on the first request so it can reconcile the 2 pieces of information. Assuming that you are in control of the web server you could then have the web server set that hash/key as a cookie so it would be passed again with subsequent request from the control.
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.
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.