I am working on a web application, both the backend and the frontend are hosted on different endpoints on an internal PaaS, which redirects to a SSO page if any request coming to it doesn't have the authenticated cookie.
When I send a GET request from the frontend to the backend, it also passes through the cookies (with credentials in axios). But when I make a POST request, the browser first makes a preflight OPTIONS request without cookie and internally the backend service redirects to the SSO, as a result it never gets to sending the POST request at all.
The preflight request by design exclude user credentials, how can I get around it?
Write a middleware in your backend, top in the heirarchy and check the request type in it.
if it is "OPTIONS", just verify the origin, if it is familiar respond right away with 200 instead of passing control to next, if not then respond with 403
if it is not "OPTIONS", just pass the control to next so that it deals accordingly
assuming a node-express server, the middleware would look like this
app.use((req,res,next)=>{
if(req.method==='OPTIONS' && whiteListUrls.includes(req.origin)){
res.status(200);
}else{
next();
}
})
Related
I am working on a react application, where there is a need to send the object parameters inside a body because of confidentiality. So I am making a POST request from the react app client-side to the backend server like this
axios
.post('htps://java.backend.xyz/path1', {
data: password,
})
.catch(function (error) {
handle(error);
});
After making this POST request there is a preflight request with "method = OPTIONS" and "URL= 'htps://java.backend.xyz/path1'"...to which java-backend-server responds with status_code=200.
After the above preflight request, java-backend-server addresses the POST request and instead of sending a response the java-backend-server respond with a GET request (i.e redirect) as for example:
https://express-app.xyz/path2?query_para1=abc&query_param2=123, requestMethod=GET
And in response to the above GET request, the express app responds with status_code=200
But immediately after this GET request, there is a preflight request with request Method=OPTIONS and having the same URL as above i.e
https://express-app.xyz/path2?query_para1=abc&query_param2=123, requestMethod=OPTIONS
and for this above OPTIONS request express server responds with a status_code=204 which means that the client doesn't need to navigate away from its current page...this is something prohibiting my app to make a final redirect i.e after the backend server responds with a GET request, my react app is not able to make a redirect even search engine does not update the redirect URL which is
https://express-app.xyz/path2?query_para1=abc&query_param2=123
So, here Is this even possible? I am assuming that the preflight request after the GET request prohibits the client side to be able to make a final redirect. Can someone please help me with this scenario
I am not sure if I understand your problem correctly but what you can do is send a post response which will which will indicate client to redirect to specific location.
This can be achieved by sending response with status code 302 and location in header (location:redirect_url)
For more info :- https://en.m.wikipedia.org/wiki/HTTP_302
I've a Gatsby (React) page with a contact-form which sends the params to an API endpoint.
The form is on the browsers client side.
That Api Endpoint sends to an Email service provider, so far so good.
BUT how can I prevent people from sending emails directly to that endpoint /api/contact-form, in my contact-form I have a ReCaptcha to do that, but the API endpoint is not "secured".
First I thought I can do that with a "host"-check... but the page is on the client side...
Is it the right approach to create a token, when the page is delivered to the client, and check it then against on the API endpoint?
I assume you're talking about CSRF token. It is definitely one way to prevent CSRF attacks. The other option could be setting cors to allow only specific origins to access your API endpoints.
I'm going through the following security tutorial and it configures a CsrfTokenRepository like this:
.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
Is that all that is required to get Ajax requests working across all libraries? The Angular documentation for $http says that Angular reads the CSRF cookie that Spring provides and sets a corresponding a header when it makes requests. So I'm assuming it does this because the cookie will not automatically be included when sending Ajax requests?
[Update]
I read the article again and it says that the CSRF protection is provided by the header. So if I interpret that the right way it's the fact that the client is sending back the cookie value in a unique way that is different than it was sent in the first place that provides the CSRF protection. In other words the client receives the cookie and changes the way it is sent back, so that the server knows that the client is indeed in control of the cookie?
CSRF protection with Spring CookieCsrfTokenRepository works as follows:
Client makes a GET request to Server (Spring backend), e.g. request for the main page
Spring sends the response for GET request along with Set-cookie header which contains securely generated XSRF Token
Browser sets the cookie with XSRF Token
While sending state changing request (e.g. POST) the client (Angular) copies the cookie value to the HTTP request header
The request is sent with both header and cookie (browser attaches the cookie automaticaly)
Spring compares the header and the cookie values, if they are the same the request is accepted, otherwise 403 is returned to the client
Note that only state changing requests (POST, PUT, DELETE) are CSRF protected by default and only these need to be protected when API is properly designed (i.e. GET requests don't have side effects and modify the state of the app for example).
The method withHttpOnlyFalse allows angular to read XSRF cookie. Make sure that Angular makes XHR request with withCreddentials flag set to true.
I have two web apps, one for the Web UI in AngularJS and one for the REST webservices in Java. Both are deployed on separate domains.
The applications uses cookie for authentication. Whenever user enters a valid username and password, server returns a http only cookie back containing the token and that cookie is passed across all requests. I have enabled CORS on both apps, thats why the session cookie is working properly.
Now, I am trying to add CSRF protection for this. I was trying to use the csrf cookie where in the server will send the csrf cookie(not httponly) as part of REST response and the UI will read the value from the cookie and pass that in a csrf token header for the other REST calls.
The problem with this approach I am facing is that since the server is in different domain, I cannot read the cookie using $cookies in AngularJs. Is there a way to read a value of that cookie?
If not, then can I implement CSRF in some other way?
I also tried to implement the creation of the csrf cookie on the Web UI itself in the browser but the browser does not send the cookie to the webservice as its in different domain.
So, my question is how to implement csrf protection for this kind of situation?
You were on the right track with this:
I also tried to implement the creation of the csrf cookie on the Web UI itself in the browser but the browser does not send the cookie to the webservice as its in different domain.
The CSRF cookie isn't meant to be "sent" to the server, it is meant to be read by the client and then supplied in a custom HTTP request header. Forged GET requests (triggered by HTML tags such as <img src="">) from other domains cannot set custom headers, so this is how you assert that the request is coming from a javascript client on your domain.
Here is how you can implement the idea you were working on, imagine you have api.domain.com and ui.domain.com:
1) User loads the Angular client from ui.domain.com
2) User posts authentication information from Angular client to api.domain.com
2) Sever replies with an HttpOnly authentication cookie, called authCookie, and a custom header e.g. X-Auth-Cookie, where the value of this header is a unique value that is linked to the session that is identified by the authCookie
3) The Angular client reads the X-Auth-Cookie header value and stores that value in a XSRF-TOKEN cookie on its domain, ui.domain.com
So now you have:
XSRF-TOKEN cookie on ui.domain.com
authCookie cookie on api.domain.com
4) User makes a request of a protected resource on api.domain.com. The browser will automatically supply the authCookie value, and Angular will automatically send the X-XSRF-TOKEN header, and will send the value that it reads from the XSRF-TOKEN cookie
5) Your server asserts that the value of X-XSRF-TOKEN is linked to the same session that is identified by the value of the authCookie
I hope this helps! I've also written about token authentication for Angular, Token Based Authentication for Single Page Apps (SPAs) (Disclaimer: I work at at Stormpath)
Angularjs has built-in support for CSRF but unfortunately it doesn't work cross domain, so you have to build your own.
I managed to get it working by first returning a random token in the headers and cookies on the first request. In order to read the header you need to add it to Access-Control-Expose-Headers. This is then added to all posts
$http.get('url').
success(function(data, status, headers) {
$http.defaults.headers.post['X-XSRF-TOKEN'] = headers('XSRF-TOKEN');
});
Then on the server you can compare the cookie value with the value in the header to ensure they are the same.
$http docs : Angular provides a mechanism to counter XSRF. When performing XHR requests, but will not be set for cross-domain requests.
This is a small lib put together might help you https://github.com/pasupulaphani/angular-csrf-cross-domain
I've run into an issue when using OAuth 2 authorization codes in an web app's URL, such as is returned by Google's OAuth method (https://developers.google.com/accounts/docs/OAuth2Login).
I've been using the google redirect method; where you redirect the user to a Google URL, passing in client_id and redirect_uri. The user authenticates and the authorization code is passed to the redirect_uri as a
The issue is that the access code stays in the page URL, so if the user bookmarks or posts the URL, they are sending an invalid Authorization Code.
Eg:
http://myapp.com/?code=kACASDSDdAS81J5B8M_owCyUNgV46XdZaqBBMh4T8OJFEKPRrgN7gtiFOcMW5Fv3gk
What is the best way to handle this case? Ideally, I would like to send the authorization code in a POST body as it isn't visible to the player?
I've spent a bit of time looking at Google App Engine (the platform I'm using) to redirect the user, but can't seem to send a POST body in a redirect.
After the user is directed to your app with the authorization code in the URL query parameter, you should:
1) Exchange the authorization code for an access token by making a HTTPs POST to Google's OAuth 2.0 token endpoint and save that access token as appropriate (datastore, memcache, etc)
2) Redirect the user to a URL without the ?code. You can't send a POST body in a redirect (HTTP doesn't allow it), but that shouldn't be necessary if you store the access token server-side for making API calls.
If you must make the token accessible client-side, you can:
a) Send it back as a cookie along with the redirect (which exposes it to the client, though you could encrypt it) OR
b) Generate a HTML form, with JavaScript for auto-submitting it instead of doing the redirect. Kind of ugly, but common.