Is there a way to send a POST request using AngularJS despite the same-origin policy?
I don't need to get the response from the request, I just need to send the request.
Just like creating a form and sending it to another server.
Thanks
You can use JSONP to send a request to another domain, however you can't use POST, it would have to be a GET request. Can you serialize your form values and send using GET?
http://docs.angularjs.org/api/ng.$http#jsonp
How to use type: "POST" in jsonp ajax call
Keep in mind that if you do use GET, you are limited with how much data you send, since URLs usually can't be over ~2000 characters.
Related
I am currently facing a requirement that could support HTTP Get Request with payload. Also this question has confused me for a long time. Is there a way to send body with a HTTP GET request from browser side? I know you could send get request with body by using Python, Php,cUrl etcs, but how about from browser side?
I have done some investigations on this topic and find out that most of the popular http request libaries such as axios,request,superagent do not support this feature. Even, the fetch and XMLHTTPrequest does not support Get method with payload.(https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send)
The weird thing is that the standard(or RFCs) did not forbid sending a get request with body.
Here comes my question, is there any way from web browser we could support http get request with body?
In my application there is a client and a WCf REST service. For invoking some wcf service the client is doing an http POST even though the service is a GET.
i do not want to do any changes in the client or the service.
So is there a way where i can convert this POST request to GET and add the data coming in as the POST to the URL and invoke the REST service.
Thanks in advance.
You can use URL Rewrite to issue 3xx Redirect which will use GET method, but you will loose all POST data.
The only safe way known to me is to rewrite POST request to some another custom page, where you:
collect all POST data/variables;
convert them into GET variables (assemble proper GET request);
issue 301 (or 302) Redirect to the proper URL (it will have all POST data sent as GET variables).
Such rewrite to custom page should be easy -- you need to check what method is used (POST or GET) and only invoke it on POST. The rest will be handled in that post-to-get script.
The reason for all of this complexity is the difference in how POST and GET requests work: with GET all data is sent as part of URL while POST uses request body to transfer variable's data.
will any webserver [IIS possibly] know whether a request is an AJAX request or a Normal one.
If you are using native XmlHttpRequests then there is no difference between this request and once generated by visiting a page or submitting a form. If you use jQuery to create the AJAX request then is adds a request header X-Requested-With: XMLHttpRequest. This header could be used to distinguish AJAX and non-AJAX requests.
Some (most?) frameworks can send a custom header, but, really, an ajax request is just the same as a "normal" request from the point of view of the server.
If you use curl, wget, telnet, or a program you write yourself, then the web server handles the request the same way - at the end of the day, it's all HTTP.
The easiest way for the receiving page to 'know' would be to send a query string parameter. This isn't 100% safe though.
Firebug can show you what is being sent to the server from both types of requests, try it out.
Possibly, it is not the webserver that can distinguish, but the server side code might be able to distinguish. If you are talking about ASP.NET and AJAX, then ScriptManager.IsInAsyncPostBack can be used to find whether a postback is from AJAX or not.
Do I need to use csrf tokens in my ajax requests?
I think that someone tricking my users to execute malicious ajax requests from another site, to my site, will fail because of the origin policy, which is handled by the browser, am I right?
I don't care about duplicated requests when using ajax, I'm only asking about the attacks.
Am I at risk if I don't use csrf in my ajax requests?
As per my research,
We can reduce the vulnerability by using POST request(for the request which will take side affect). But thing is that we can forge the POST request as well with form submission, cause same origin policy will not applies plain html for submissions. But it applies to request which are getting generated with JS.
So if you use ajax POST request and you are safe if you are using JSON payload.
Cause url encoded payload(POST request) can be forged with form submission from other sites.
If you use JSON, as it is not possible to send plain text pay load(with out urlform encoded) with html form submission you are safe. Because with ajax POST request if you use urlform encoded data payload it can be forged with POST form submission.
This is how we solved the problem with CSRF token in Ajax requests
http://mylifewithjava.blogspot.com/2010/11/implicit-csrf-protection-of-ajax_22.html
The fact that you are using Ajax doesn't mean that others have to as well. Your server won't be able to distinguish a request made by XHR from one made by <form> submission. (Yes XHR usually adds a header identifying itself, but this is not hard to spoof.)
So yes, you do need to consider CSRF attacks.
Edit
Django have a POC, which is why they and Ruby on Rails now implement CSRF protection on AJAX requests.
Once again, please check your facts before downvoting, and explain what the downvote is for.
When user is on the page you can use session or cookies to check who is he.
But when AJAX is used, for example, for sending an answer, sending page have no contact with user. How can it check is it real registered user, or just spambot sending this by headers?
What is the common practice for AJAX user validation?
AJAX requests contain the same cookies like regular requests. Besides that you can send any arguments like session IDs with the AJAX request.
Actually, for the server it makes absolutely no difference if a request is made through an XmlHttpRequest object or not. Most frameworks add an X-Requested-With: XMLHttpRequest header though but that's completely optional.
So.. whatever means you use to pass your session data, simply ensure it's also available to the script called with your AJAX request:
If you have a session id passed via GET/POST, include it in your request's arguments.
If cookies are needed, ensure they are send to the file. If it's in the same folder like the current file or a descendant of it you are usually safe. If it's on another (sub-)domain you might get problems - not only with cookies but alsowith cross-domain AJAX which usually isn't allowed due to the same-origin policy browsers have.