I saw this header is set by user interaction- for example by writing manually the url in the url bar/bookmarks etc..
Any ideas to make a user initiated post request so this header will be passed? I have a vulnerable application to csrf only when this header is set. The request method is POST.
thanks in advance!
Related
I have a flask API, with jwt authentication, on a httponly cookie. I installed interceptor, added the domain(with HTTPS) to the list, and enabled the requests and cookies interception.
but still,
how do I make postman send the cookie I got from logging in to the server? usually, with a simple front-end, it just happens, so I didn't think about it.
all the methods I found in postman documentation, including specifying the value with the token, but I don't have it, since I can't access the httponly cookie. (or can I?)
must I access the cookies? can it be done automatically like simply sending requests from the front-end?
any guidance will be appreciated
After a full evening of research, I did two things to make it work -
in the login request, I added a "test" script(a post-request script in postman), with the following code:
const csrf_token = pm.response.headers.get("set-cookie");
const edited_token = csrf_token.split(/[;=]/)[1];
pm.environment.set("X-CSRF-TOKEN", edited_token);
console.log(csrf_token.split(/[;=]/)[1]);
First, I got the cookie from the response, and then used a regex to separate only the token value, and set it as an environment variable. this way, I could add it as a header later, for accessing protected URLs.
The second step was to add a pre-scrit in any request with a protected URL -
in the pre-request tab, I added the following:
pm.request.headers.add({
key: 'X-CSRF-TOKEN',
value: pm.environment.get("X-CSRF-TOKEN")
});
Which only added the same token I took earlier from the "X-CSRF-TOKEN" environment variable and set it to the header.
Mission accomplished :)
I hope it will help others who bumped into this
I am confused. I've added headers to a request before and, for some reason, this one does not work as I want it to.
I'm trying to perform a post request to Linkedin following their documentation to get an access_token from an OAuth2 flow. I have the preliminary code to pass to the token endpoint, that is not an issue.
This is the sample request from the docs:
POST /oauth/v2/accessToken HTTP/1.1
Host: www.linkedin.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code={authorization_code_from_step2_response}&redirect_uri=hhttps%3A%2F%2Fdev.example.com%2Fauth%2Flinkedin%2Fcallback&client_id={your_client_id}&client_secret={your_client_secret}
I assume the Host header is to avoid CORS issues, but it just isnt being set. When I perform this request, my console gives me this 404:
Given that I know the Header is not 'unsafe', how do I go about setting it in this specific case?
Any help would be greatly appreciated, thank you!
My bad. Remove the Host header from config object and set it directly in the URL. Works just fine. I now have CORS Allow-Origin issues, but that's not related.
I set cookie in request header before I call loadRequest() function to load a page. I also use document.cookie() to set cookie by WKUserScript according to [WKWebView Cookies. However, I find that if a 302 redirection occurs, request may fail for loss of cookie. For example, the request of http://A redirect to http://B, I could set cookie for request of http://A by operating request head and using WKUserScript, but these two ways can not set cookie for request of http://B, so the 302 request of http://B may fail. This situation occurs in ios8 more frequently than ios9. Does anybody have a workaround?
Note sure, but probably the first response may contain "Set-Cookie" header. Hence, you have to use the provided cookie in the second request. May be it's missing.
workaround for set cookies in iOS please check my answer. You must set cookies both in request and wkuserscript same time. otherwise it fail one time and sucess in 2nd run,
Can I set the cookies to be used by a WKWebView?
Good day.
Probably, i have any conceptual mistake in this subject, but i can not understand where is it.
I got content from www.facebook.com
recieved values of:
lds, lgnrnd, lgnjs
datr from response cookie
formed post request to 'https://www.facebook.com/login.php?login_attempt=1" with required body (email, pass, etc)+ set cookie from previous
I got start page content. Authorisation did not done.
What was left out?
im thinking what is the best RESTful way how confirm email and request reseting password. Im only aiming to find correct URI...
confirm email
PUT /users/{userId}/confirmEmail?code=xyz - does not seem much RESTful because of confirmEmail
PUT /users/{userId}/email?confirmedBy=xyz - maybe better? dunno
reset password (similar problem)
PUT /users/{userId}/resetPassword --DATA {email:xyz#xyz.xy} - same thinkin as before
PUT /users/{userId}/password --DATA {state:reseted,resent:xyz#xyz.xy} - hmmm... again Im not sure
are there any better ways in your mind?:-)
If you want your URIs to refer to resources, then call the resource confirmation and POST confirmations to user accounts.
POST /users/{userid}/confirmation
The true RESTful answer is the URL does not matter, you put it in the confirmation e-mail anyway for the recipient to follow. Use whatever is most convenient for your load balancer, reverse proxy, servers, etc.
For convenience you'll end up accepting the confirmation even if it comes in a GET request, because that's what the browsers of flesh-and-bones humans oblivious to Dr Roy T. Fielding et al. send when clicking on a link in an e-mail :-)
Having established it is completely academic, I'd argue you were right to think of PUT, as the client idempotently places evidence of having access to the e-mail. Repeating the request has no further effect.
Considering that he said a reset service for someone who forgot her password, and not a change password service for someone already logged in...
I would use 2 services. 1st to request the reset password mail, and 2nd to set the new password with the token received in the received mail.
For the 1st:
POST baseUrl/passwordReset
Request body
{
"email" : "my#self.com"
}
This could be POST or PUT, but since a mail delivery is not a resource subject to CRUD anyway, let's not be pedantic and use the old POST that was always used in html forms.
Obviously I would control that the same client (ip? browser? ...) doesn't make me send 20K mails in a minute.
Sending the mail to the user doesn't imply that the old password is not valid. That will only happen later in the second request when the new one updates it.
Response 204 (perhaps you should do it even if you don't know that email, because if you return error that means that when you don't return error you are confirming to a stranger that the given email is registered)
For the 2nd:
POST baseUrl/password
Request body
{
"token" : "3D21BA...4F",
"newPassword" : "m%4pW1!O"
}
Where the token is received in the mail. So the mail could have a link to a page including the token, when the page is loaded, the form is filled and submitted, being the token a hidden field that some javascript reads from the URL and puts here.
This is really a resource that you update, so POST. And I don't think it makes sense to have the same URI with 2 verbs for both, because they are not the same resource/entity at all.
Add
By the way, I would make both HTTPS only, and that's why I put all the sensitive information in the body, not URL parameters.
Firstly, I don't think that PUT is the right method for this. PUT broadly means "put this here", where the URL is identifying where the content should be located. You're really asking an existing resource to perform some action, which makes POST more correct.
To answer your direct question, a RESTful URL should identify the resource you want to handle your request. In this case, the resource is either the user, or some password-resetting resource within the user.
My preference would be for a password-resetting resource:
POST /users/{userid}/password-reset
This makes sense from a HTTP point of view, since you could issue a GET on the resource and receive something which indicates how to action a password reset (e.g. a HTML form prompting for the email address of the associated account).
EDIT:
For the purposes of email validation, there are two obvious options. You could either POST to a "confirm email" resource with the email address and confirmation data, to ask the server to process the confirmation, or you can execute a PUT to put the confirmation information on the server:
POST /users/{userid}/confirm-email
or
PUT /users/{userid}/email-confirmation
Here is a RESTful way.
Request
PUT /{userid}/email HTTP/1.1
Content-Type: text/json+confirmation-code
{"activateCode": "23sfgsg3twt3rgsdhgs"}
Response
HTTP/1.1 200 OK
Content-Type: text/json+email-status
{"email": "my-email#address.com", "active": "true"}
No verbs in the URI needed :)
I don't really see anything wrong with having confirmEmail like the 1st example. In the URL you have the key to the user, confirmEmail is the action, and the data with that action is in the query string.
I've recently worked on this, my take was
POST /{base_url}/password
because I was actually creating a new random password and sending it over to the user
and
PUT /{base_url}/confirmation?token=...
Because I am updating the confirmation that was already sent out when the user registered.