My cookies in the request header look like this:
website cookies
When I log out or the session expires, I can't make a GET request in Postman, because the values of those two are different each time.
I don't know how to generate csrf token and jsessionid and include them in the response header section of Postman automatically so I can use them without adding them manually.
Will be grateful if someone helps me. Thanks in advance!
You can perform a valid login-request and have Postman automatically use the JSESSIONID and CSRF-TOKEN in the following request as described here.
The JSESSIONID should be set as a cookie, and the CSRF-TOKEN should probably be set as a header value.
Related
If the request in Mozilla looks like this, how can I make this request using postman and python. I couldn't find a way to set cookies in postman and I would appreciate any help
In postman in request tab below Send button, there is an option to Add cookie. If you want to know more about configuring cookie in Postman you can refer here
https://learning.postman.com/docs/sending-requests/cookies/
My web application (myApp further) is embedded in iframe of a single third-party webpage. MyApp sets cookie Set-Cookie: JSESSIONID=38FE580EE7D8CACA581532DD37A19182; Path=/myapi; Secure; HttpOnly for maintaining users sessions. Sometime ago it stopped working in Chrome since https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html update changed treating default behaviour for cookies without SameSite attribute from None to Lax.
I'm going to send cookies from myApp host with SameSite=None; Secure. Also X-CSRF-TOKEN header is included in every response. myApp javascript gets X-CSRF-TOKEN and puts it in header of every XHR request to myApp host. Does this suffice to prevent CSRF attack?
Should Access-Control-Allow-Origin: third-party-webpage header be added in responses?
I did more research and thought I would post my conclusion here.
I had misunderstood how the Antiforgery middleware worked.
The cookie configured by AddAntiforgery does not actually transmit the token to the client.
Instead it appears to be the encrypted or hashed token that is used to validate the token which must be provided in the header.
This allows the validation of the token to be done statelessly as the browser will pass the value of this cookie back with each request.
I refer to this cookie as the "validation cookie" below.
The middleware does not automatically transmit the token itself to the client.
That must be done by calling GetAndStoreTokens and providing the RequestToken value to the client to be set as a header for subsequent requests.
In our application we do that with a separate cookie (I call this the "token cookie" below).
Here's the Microsoft article demonstrating this technique.
I have determined that it is safe to use SameSite=None for the validation cookie and for the token cookie.
The SameSite setting does not have any effect on who can read the cookie value, it just determines whether or not the cookie will be sent to the server with future requests.
The validation cookie must be sent back to the server with future requests so that the token provided in the header can be validated.
It is acceptable that this cookie is sent even for cross origin requests since those requests will only validate if the token is provided in the header.
It is also acceptable for the token cookie to use SameSite=None since we are only using this cookie to provide the value to the client.
We never read this value from the cookie on the server when validating the token, the middleware reads the token from the header.
The value of the token cookie cannot be read by a different origin regardless of the SameSite property so that remains secure.
I also that realized that this exact pattern was employed by the Antiforgery middleware long before SameSite=Lax became the default value for cookies by chrome in 2020.
Prior to this the default behavior for the validation cookie would have always been None.
So I think it is reasonable to conclude that this technique is just as secure now with SameSite=None as it was before Lax became the default.
NOTE: There appear to be some browsers that don't handle SameSite=None correctly so the antiforgery process might fail for these browsers when the app is hosted in an iframe.
I am using Siteminder for Authentication, once it is successfully Authenticated by Siteminder, it will return us the cookies (which will be used for Authorization) as header param.
I'm trying to add these cookies with the WLResourceRequest API for Authorization but my code doesn't seem to send any cookie and giving me "Authorization Failure"
Code used to add cookie using WLClient
WLClient.getInstance().addGlobalHeader("Cookie", cookies);
I even tried to add the cookie before WLResourceRequest call,
request.addHeader("Cookie", cookies);
I can see the cookies has been added to the header but when I try to use that header param for Authorization, it is getting failed
Consider adding the Cookie as a header to your WLResourceRequest itself.
Please refer to the API documentation here.
Look for the setHeader() method.
I'm setting a cookie in a response from my web service. The set-cookie header is coming through, and I can see the cookie in the network tab in Chrome, but the cookie isn't being stored. It doesn't show up in the resources->cookies tab, and the cookie isn't sent with subsequent requests. Nothing shows up in the JS console. I've also tried leaving the domain field off the cookie, but it still isn't stored.
Is there a way to debug the browser to understand why the cookie was rejected from being stored?
Turns out it had to do with the way I was making the request. I expected fetch() to work the same way as XHR requests. Setting credentials: 'include' on my fetch call resolved the problem. See 5.6.14 of the fetch spec
I'm using the chrome rest client to test the api calls.
A GET request is working fine but while making a POST request , getting 403 hidden response.
description is
CSRF verification failed. Request aborted
I'm setting as Content-Type=application/json.
One way would be to use #csrf_extempt, but seems to be good choice.
How to resolve above issue ?
Using #csrf_extempt is infact a good practice when you are providing an API to your site. Cross-site request forgery is what csrf is but in your case it won't be a forgery since an api can(should) be called from any site but yours.
.
Moreover sharing csrf token will prove to be very tricky.
In thre request, include an X-CSRFToken header with the CSRF token value obtained from the csrftoken cookie.