I have a REST API and a frontend project like react angular. The REST API have private videos and images besides json data. So, I was using Authorization header with bearer thing. The token created via jsonwebtoken as known as jwt. So, the browser javascript does not let me to add a header while using video tag or img tag. I cannot use Authorization header anymore. I think i have two choices
I will use my token in url via queryParams, like apikey.
I will use cookie, that will automatically send cookies even using video or img tag.
So, what should i do. First option is the easiest for me, i did it before. But not much secure. Https d- oest not encrypt url. A rest api should set cookie, via using set-cookie header. Is there any problem with jwt while using cookie?
It is only safe to put a JWT into the query parameters under these conditions.
Based on what I know, using a cookie to remind your REST API that your user is authenticated would be preferable.
But do not put sensitive information in cookies, even secure and httponly cookies. From MDN Cookies:
A secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Even with Secure, sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection.
Related
I have a site composed by a frontend (written in Vue) and a backend (written in node).
The api use the jwt authentication, so that only a logged in user can make requests to the backend.
The jwt is placed in the Authorization: Bearer xxx.
The problem comes when I have sensitive images or documents statically served such as identity cards.
Let's say I have a sensitive image statically served. Now, I could just add the jwt authentication also for that statically served image, no problem, but in the frontend side, how do I tell to the browser to put my jwt on the request?
<img href="/my/sensitive/image.png" />
Note that the jwt is not known a priori, it is retreived by the user login.
Use cookies. Store the JSON Web Token in a cookie (preferably with HTTPOnly, Secure and SameSite flags on), so that the browser automatically appends the value on every request to your origin.
This is a good idea from the security point of view, too - if client-side JS cannot access the token at any time, the risk of leaking it via a cross-site scripting vulnerability drops to zero.
So my current state is I have a REST API web server (ASP.Net Web API), a website in plain Html which communicates with the server via ajax / angular post and get, also I have a mobile application which communicates via ajax / angular post and get.
I use Basic Auth header to secure the request, the web server will decrypt the content of the auth header and do the verification after.
What kind of attacks would the system be vulnerable to? Also what kind of security should I implement.
I read about the CSRF attacks and I think my system have no protection against it, but I have no idea how to implement it on REST API.
Also what about the cookie stealing attacks. Because my system uses persist cookies to store the auth token, how to deal with this kind of attack?
To prevent CSRF attacks, both your backend (ASP.NET Web API) and frontend (Angular) must be configured to prevent such an attack.
Taken from https://angular.io/guide/security#xsrf:
To prevent XSRF, the application must ensure that a user request originates from the real application, not from a different site. The server and client must cooperate to thwart this attack.
In a common anti-XSRF technique, the application server [backend] sends a randomly generated authentication token in a cookie. The client code reads the cookie and adds a custom request header with the token in all subsequent requests. The server compares the received cookie value to the request header value and rejects the request if the values are missing or don't match.
This technique is effective because all browsers implement the same origin policy. Only code from the website on which cookies are set can read the cookies from that site and set custom headers on requests to that site. That means only your application can read this cookie token and set the custom header. The malicious code on evil.com can't.
With that in mind, here's another quote from Angular HttpClient Docs which explains how you can implement it.
Taken from https://angular.io/guide/http#security-xsrf-protection:
When performing HTTP requests, an interceptor reads a token from a cookie, by default XSRF-TOKEN, and sets it as an HTTP header, X-XSRF-TOKEN. Since only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.
By default, an interceptor sends this header on all mutating requests (POST, etc.) to relative URLs but not on GET/HEAD requests or on requests with an absolute URL.
your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on either the page load or the first GET request. On subsequent requests the server can verify that the cookie matches the X-XSRF-TOKEN HTTP header, and therefore be sure that only code running on your domain could have sent the request. The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens. Set the token to a digest of your site's authentication cookie with a salt for added security.
Key points to take note would be:
When the angular app is loaded, it should make an API call first to your backend to retrieve an authentication token that is saved as a cookie that with the name "XSRF-TOKEN". Probably somewhere on root component (app.component.ts) ngOnInit() sounds like a good place.
By default, the authentication token will be automatically injected in the http header on all mutating requests such as POST. (Take note of this though, it is undocumented: Angular 6 does not add X-XSRF-TOKEN header to http request). Unless you return a custom-named cookie, then you have to use Angular's HttpClientXsrfModule.
With that in mind, your ASP.NET Web API should also be validating the XSRF-TOKEN as it receives requests.
With regards to your second question, cookie hijacking is done via XSS.
XSS vulnerabilities generally occur when an application takes user input and outputs it to a page without validating, encoding or escaping it.
Angular by default sanitizes inputs for tags. However, this is provided you do things "the angular way". If you use third-party libs, such as jQuery, to manipulate the DOM instead of using Angular's renderer2 module, you might lose this protections.
Taken from: https://angular.io/guide/security#xss:
In the same way, if you interact with other libraries that manipulate the DOM, you likely won't have the same automatic sanitization as with Angular interpolations. Avoid directly interacting with the DOM and instead use Angular templates where possible.
For cases where this is unavoidable, use the built-in Angular sanitization functions. Sanitize untrusted values with the DomSanitizer.sanitize method and the appropriate SecurityContext.
To increase security, you should also sanitize any mutating requests (such as PUT or POST) in your backend.
It is difficult to provide you with code examples because your question seem to be a more theory-based question.
I hope you will take a read on those links that I have hyperlinked above. They are definitely more detailed and well-explained. I hope it will at least point you in the right direction of what to get started on.
I am working through some architecture issues in my head related to JWT authentication security and I'm trying to figure out the following:
How does JWT securely pass a secret between server and client?
Take a look at the below excerpt from from https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ ....................
CSRF can be prevented by using synchronized token patterns. This sounds complicated, but all modern web frameworks have support for this.
For example, AngularJS has a solution to validate that the cookie is accessible by only your domain. Straight from AngularJS docs:
'When performing XHR requests, the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain can read the cookie, your server can be assured that the XHR came from JavaScript running on your domain.
You can make this CSRF protection stateless by including a xsrfToken JWT claim:'
{
"iss": "http://galaxies.com",
"exp": 1300819380,
"scopes": ["explorer", "solar-harvester", "seller"],
"sub": "tom#andromeda.com",
"xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}
How does the client create and send a valid request including the xsrfToken claim unless it can first sign the JWT after including the claim? (This xsrfToken after all is what's supposed to keep EvilBob from forging a request right?)
More details regarding my current understanding of the JWT XSRF process can be found here http://spring.io/blog/2013/08/21/spring-security-3-2-0-rc1-highlights-csrf-protection/.
I can explain how Stormpath does it, there are some other ways as well. Stormpath includes a 'kid' (key id) field in the JWT header, which is the identifier for the API Key ID / Secret pair. The JWT was signed with the Secret, and the ID is stored in key id field. When Stormpath validates the token, it can retrieve the secret. This works across servers and services but is never passed to the client. Using the client to glue separate services together with the secret is extremely insecure.
The client SHOULD NOT generate the JWT, this needs to be done on the server. The server knows the XSRF token and can sign it in the JWT and put it in the cookie.
Hope this information helps!
The article appears to call this the "synchronized token pattern", however the solution described better fits with the Double Submit Cookies method rather than the Synchronizer Token Pattern.
Double submit cookies involves sending the cookie value in a header or body as well as sending it with the browser cookies that are automatically sent. If you are not supporting CORS, then setting a token in a header is secure anyway, as is with any custom header value (e.g. X-Requested-With). This is because a custom header cannot be sent cross-domain in the first place, so verifying that it has transported from the client verifies that it is not from another domain already. As a defence in depth strategy, you can set it to a random value, as explained by this answer.
The random value doesn't need to come from the server, nor be signed. It just needs to be generated by a CSPRNG. If generated client-side, window.crypto should be used for this. All the server does is check that the header and cookie values match.
A third party domain cannot forge a request because even though the cookie value will be sent by the browser automatically from the victim's machine, the attacker cannot include the value in the header or the request body.
With the Synchronizer Token Pattern the CSRF token is generated server-side and stored against the session. This value has to be sent from each form submission and is verified server-side that it matches the stored token.
Supposed I have a single page application that uses JWT tokens to authenticate against a backend REST api. I transfer the JWT token inside the http header when doing a REST request. So far, so good.
Now, supposed I want to download an image from the server, and I want the image only to be accessible for authenticated users. On the server, this is no problem: Simply define a route that delivers the image, and in that route verify the JWT token.
But: How do I transfer the token from the client to the server? If I use a regular <img ...> tag, I can not attach the token as an http header. What should I do?
I basically can think of adding the token, e.g. base64-encoded, to the query string, but that does not seem to be very secure, since the token then appears in the browser's history. On the other hand, I can not think of another approach, without loading images entirely using JavaScript.
Any hints?
If i think of Amazon S3 a signed url is what you want here. As you already suggested adding a token to the query string would be fine.
About security: I think this is a matter of the expiration date of the token. As there is no invalidation of the token maybe it is better to use signed URLs:
Get a JWT
Get a signed URL with that token
Use that URL to retrieve the img
This way you can control the expiration of the signed URL independent of the JWT and also define the length of the token used for the signed URL.
I am building a web page that will be embedded on a third party website using iframe. No login service is required to initiate the communication so I can't manage any session token.
Therefore, I am planning to validate the origin header of the https request to check if the request comes from the expected source. This external website is not in my control but I can ask them to make some changes to achieve secure communication.
I have two questions:
Is it possible to set or modify "origin" header maliciously in an https request? Or is it always set by browser itself?
Because I am not very sure of the level of security provided by origin header I plan to use HMAC-SHA256 as well. The external site should generate a unique number for each request and sign it with secret key.
So, if I implement the above two things, is there anything else I should be worried about?