I wish to set cross-origin cookies in server side using POST method.
Cors settings are set up in server side to allow the cross-domain requests and credentials.
After sending a POST from a cross-domain JS application, the cookie is not shown in the browser although the response has set-cookies headers.
However, using GET method to set the cross-domain Cookie from the server works fine and it is saved in the browser.
I failed to find some documentation about this, much appreciated if anyone could explain why the cookies can’t be set using POST?
The cookie set by other server will only be visible in the origin site.
For example, you have site.com and ads.com. Site.com wants to use some resources from ads.com.
Step 1: site.com sends a GET/POST request to ads.com.
Step 2: ads.com sends a response with cookie(ad_id=blala) attached. This cookie originates from ads.com and will only be visible at ads.com.
Step 3: site.com sends other requests with the cookie(ad_id=blala) to ads.com.
If you check cookies in site.com, you cannot find the ad_id cookie because this cookie is only visible in ads.com.
In this case, to view the cookie, go to ads.com rather than your site.
Related
So I have been developing a webpage the would give random quotes whenever a user clicks on a button by calling an API.
Please refer to my previous question for more information Not able to get values (quotes) from the API using jquery
I was told that the reason I couldn't get the response from the API is because my ACAS(Access-control-Allow-Origin) is not set properly in my server and I have to debug it.
Now that I don't much about ACAS or CORS. I have some questions. SO here they are:
1. What exactly is ACAS and how is it related to CORS?
2. How do I debug my page and set the ACAS?
3. Does that have to do anything with my jQuery? Or should I configure only my browser.
You can find many documents on the internet
,so I'll just briefly talk about CORS.
When you're sending request to different domain
for example from a.com to b.com, or localhost:8080 to a.com......
your're making a cross-origin HTTP request ,
sometime this is not allowed, for example Ajax (as you're doing) requests.
Because XhttpRequest, Fetch (both are Ajax API) follow same-origin policy, which means by default you can only make requests form the same domain, ex: from site.com to site.com/users.
The reason they follow the same-origin policy is to prevent CSRF attack (Cross-site request forgery).
1.So basically you cannot get the result of cross site Ajax request, it will block by browser because of the security issue, unless the response header Access-control-Allow-Origin is set to allow client's site to send cross site ajax request. ex: Access-control-Allow-Origin:*allow all sites form different domain; Access-control-Allow-Origin:www.b.comonly allow www.b.com domain.
2.Take Chrome for example If the cross site request's result is blocked, it will show on browser's console:
You need to set the response header in your server, for example I set Access-control-Allow-Origin:*, then in browser's "network" console you can see the header is set, and now I can get the Ajax result.
I think nothing should do at client side, all is at server side.
Refer to this post as it makes this clear
Note also that there are some techniques frequently used in order to bypass CORS like setting up a proxy which acts as a relay for your request or using JSONP instead of JSON.
For an Angular 1 app I am working on, cookie authentication is used. The problem is: when making OPTIONS calls, cookies are not sent and the server tries to redirect user to login again. Just wondering, whose "fault" is it? Server (Azure API Apps) or frontend? If frontend, how do I send cookies on OPTIONS call? I am using augular-resource and have configured it as below:
$httpProvider.defaults.withCredentials = true
The specification says:
Otherwise, make a preflight request. Fetch the request URL from origin source origin using referrer source as override referrer source with the manual redirect flag and the block cookies flag set, using the method OPTIONS, and with the following additional constraints … Exclude user credentials.
and also
The term user credentials for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates that would be sent based on the user agent's previous interactions with the origin. Specifically it does not refer to proxy authentication or the Origin header.
So the client should not send cookies, and the server should be able to respond to the preflight request without requiring authentication to take place first.
I have read some articles on Same Origin Policy and CORS and still doesn't understand well the security that it brings to the user.
The Same Origin Policy gives a true valuable security, preventing a site from an origin from accessing some webpage content on another website. Thus preventing the threat of having the content of a iframe accessed by the script of the container, possibly faked/phishing website.
But here comes AJAX and CORS. CORS gives the ability for the server to control which origins can access it. But, at the end, it is the browser which stops the request if not allowed, after headers handcheck.
So, imagine you get some malicious website myphishing.com. You want to show information from another trusted website mybank.com through AJAX request to this site. This one is protected by well configured CORS headers only allowing request from mybank.com origin. What if, me author of myphising.com, relay all requests to mybank.com by a proxy that alter headers in both request and response way to fake client browser and bank server? It seems one can change the origin header in the request for a mybank.com one, and change the CORS response headers to make the browser think myphishing.com is allowed to make the request. Headers handcheck passed, you can then send the request and get the response with similar headers substitution tricks.
Perhaps I'm totally misleaded, but I would be very pleased if someone could show me where I have misunderstand the whole thing.
Possible duplicate but I didn't find my answer here: What is the threat model for the same origin policy?.
What if, me author of myphising.com, relay all requests to mybank.com by a proxy that alter headers in both request and response way to fake client browser and bank server?
You could do that anyway, CORS or no CORS.
If the request is coming from your proxy, however, then it has no way to know what credentials the browser would have sent to the server if the request was coming from the browser.
Hopefully this is simple to answer.
With a credentialed request in XHR2, which cookies are sent?
I've been following the MDN article on credentialed requests, and it shows that the cookie pageAccess=2 is sent with the request. However it doesn't explain where that cookie comes from, and why that cookie specifically is being sent. Is it simply that all cookies set by the page are sent in any credentialed request?
From the HTML5 Rocks page on CORS:
The .withCredentials property will include any cookies from the remote domain in the request, and it will also set any cookies from the remote domain.
I assume "any cookies" means "all cookies" (probably subject to a HTTPS-only flag on the cookie), since there is no mechanism to specify cookies with XHR2.
The cookies that get sent are the cookies that were set by the remote domain: if foo.com sends a request a credentialed request to bar.com, any cookies set by bar.com are sent. To put this in practical terms, suppose facebook.com has a CORS-aware API that requires you to be logged in to use. I've logged in to Facebook earlier in my browser session, but now I'm browsing foo.com, which is going to use Facebook's API on my behalf. foo.com asks th ebrowser to send a cross-domain request to facebook.com along with all my facebook.com cookies so Facebook knows who I am and that I've already authenticated to Facebook.
Just wondering if it's possible to use an XMLHTTPReq to login to a website, and store the cookie. Specifically I'm after the PHPSessionID from the website I am logging into.
I then want to pass this cookie into another request to submit a form.
Any ideas of how to do this?
Cheers,
Nick
You will be able to get your own site's cookies from document.cookie. In the AJAX callback, use a library to parse the value and read the cookie you're looking for.
Of course, if the server sets the cookie HttpOnly (which it should be doing), it won't be available in document.cookie.
At this pont, you need to reevaluate what you're doing:
If the form points to your website, your server script would have access to the cookie anyway.
If you're sending the user's session ID to another domain, why? This is a huge red flag that screams security problem.
If you're logging in to another site, then no – the same-origin policy prevents you from accessing another site's cookies.
Edit: Since this is for your own use, you can do this in a way you're not limited by the browser's origin restrictions. Some thoughts:
You could make a Chrome extension. Extensions aren't subject to origin restrictions, and the development model and API is pretty much the same as what you'd do on a regular web page.
You could use Node, which has no restrictions. You'd be able to invoke your script from the command line, but the API is going to be slightly different that what you'd use in a web page.
Use your language and framework of choice to POST to the login page, get the Set-Cookie header in the response, and use it to send a Cookie header in another POST to the form target.
You can only send cross-origin requests using XHR if both the browser and server support CORS. Additionally, the third party site needs to allow your site to send such requests and to receive its responses. If it doesn’t, you aren’t allowed to send the request or receive its response respectively.