30

The service offered by the token is that the server will somehow recognize the token as one of its own. How can the server validate a HMAC-based token ? By recomputing it, using its secret HAMC key and the data over which HMAC operates. If you want your token to be computed over the userID, password, IP and date, then the server must know all that ...


18

Well here is how I ended up implementing CSRF: On the first request, sets a CSRF token as a cookie. Every subsequent AJAX requests include the CSRF token as a X-CSRF-Token HTTP header. Django has some nice documentation on how to do this cleanly with jQuery: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ Edit: An alternative approach whitelists ...


16

You're in luck! Just about 2 weeks ago I was asked the same question, and after a bit of head-scratching, I came up with the following. Please keep in mind that this is not well peer-reviewed, so we'll see how the comments and voting goes. Personally, I think it's a good technique. 1. First request Once you receive the first request to load your ...


15

Here is the difference between Implicit Flow and AuthCode Flow: Implicit Flow NOTE: As of April 2019, the Oauth Working Group no longer recommends the use of Implicit Flow for most cases because there are better, more secure ways to accomplish the same things. User navigates to SPA, which redirects user to IdP to sign in. User signs in (and authorizes the ...


12

Firstly, and to be very clear, OAuth 2 is not an authentication protocol. If you wish to know the identity of the user, there are other protocols designed to solve this problem, such as OpenID Connect. If you intend to use OAuth 2 for the purpose of authorizing access to your protected resources, continue reading. To answer your direct question: you appear ...


11

It's not just that they can modify the variable to show whatever dashboard they want - the fact is that they have full control over the app, can view all code, can view all data in the app, etc... The client has full control over the app, so if you have any data, logic, or code that you don't want users to see, your only option is to never send it down. ...


10

If this is for native apps, you can try the following, Store an access key in your app bundle. Nobody other than app owner (yourself) can have this. Change your API so that only requests with the access key set in header will succeed. Use HTTPS so that nobody can read the encrypted access key. If you don’t use HTTPS, you can still manually hash the access ...


9

There is a much simpler solution: Use SSL sitewide, and then use your framework's standard session tracking. That's all you need to do. In more detail, the user initially logs in by supplying their username and password; it gets POSTed to the server, who can check its validity. If the authentication is successful, your server code sets a flag in the ...


8

Are there any caveats to this approach? (security-wise) Yeah, it's not very thorough, you can get a new instance of the constructor from a new window object instead: XMLHttpRequest = null; var iframe = document.createElement('iframe'); iframe.style.display = 'none'; // optional document.body.appendChild(iframe); var XHR = iframe.contentWindow....


6

The first thought that comes to mind is either to use sessions or setup something on your page to log the IPs of incoming connections and only allow the REST API to respond to IPs that have recently accessed your main page. This won't prevent all cases, but it does mean that someone has to at least be periodically accessing the main site to make use of the ...


5

Are SPA applications more or less immune to CSRF, XSS, or other normal attacks? Generally, no. The interaction between the client and the server should similar, if not identical to that of a plain-old-AJAXifed web app. You're still dealing with HTTP requests and responses that are coming from an untrusted client, and must according be treated carefully, ...


5

If the attacker would've been able to get the access token, surely they can get the cookie storing the session information An XSS attack can't get to the cookie if you specify it with HttpOnly. It must have been an oversight, he really should have mentioned this. Oh, and Secure (HTTPS-only) as well. Then this cookie can't be stolen via XSS or MitM'd/...


4

You can't, really. Anything sent via javascript can be tampered with. Because of this your SPA will be vulnerable to XSS and MITM attacks. An option would be using session tokens and obfuscation which is such a grotesque solution. Plus this will be an opening for CSRF attacks: CSRF. Otherwise, I recommend having your users login so that there will be some ...


4

The browser should be trusted with the user's data in any case. Whether you use a single-page app or a plain HTML page, you are toast if the browser is compromised. Single-page apps do not change anything in this context. Single-page apps can however extend the potential of a server-side vulnerability - since you're now offloading some of the processing to ...


4

Now if the user wants to delete their account, they could press the button, which would send a request to the API that authenticates requests only by Authorization header Ultimately, it sends a request to perform an action which needs to be authenticated somehow. And, since you're using Authorization header for authentication, it somehow prevents CSRF ...


3

Looking at the two options you presented, sessionStorage or HttpOnly cookies, there is a trade-off. You are correct that if you use cookies, you need a CSRF token, and if you use sessionStorage and use that as the source for your header, you do not. However, what OWASP is concerned about with sessionStorage, is that an XSS vulnerability allows an attack ...


3

In order to implement CSRF protection, you need a token that is secret in the sense that it can't be calculated by an attacker. You can use a modification of the encrypted token pattern from the OWASP CSRF cheat sheet. You can either use a shared secret key between the front-end and back-end or a public/private key, storing the public key on the front-end ...


3

Check this post Using OAuth2 in HTML5 Web App. @jandersen answer gives a good explanation on using Resource owner password credentials flow in single page applications. In any case, the prefered flow for this apps should be the Implicit grant. In fact, @jandersen 's response on the referenced post is about tweaking Resource owner password credentials to act ...


3

Your API should check to see who is making the call and perform any sort of restrictions on the server side. The way to deal with this is to implement server-side authorization and mitigate against insecure object reference and function level access control. These should be standard anyway. If your API returns information you don't want the caller to be ...


3

Just to be clear, your scenario is: You have a web service, which requires authentication to use. Your customer has a web app, the server of which acts as a client of your web service. You are looking to allow your customer's users to interact with your web service directly having their browsers act as the client (presumably via CORS request). You want to ...


3

The general best practices are to use SSO/client auth. But since they don't apply to you, you can consider this approach: If you trust your users to not share the unique links that you passed sent to them, you can use that unique property of those links to request a session variable from the server and then pass that session variable in all the requests ...


2

This sounds like preventing a CSRF attack. The Same Origin Policy will already prevent anything within your API from being read by another domain, but to prevent requests that makes changes to your system you will need to guard against CSRF. On server side: I check for request header's origin and only allow requests from my-one-and-only-web-cleint.com ...


2

It sounds like a situation similar to CSRF attacks, so it should be addressable with anti-forgery tokens. Anti-forgery tokens should achieve what you need. Each time you get a web request, you serve an anti-forgery token to the client as part of the FORM or script or webapp. The token embeds values like a date, login id, and client ip, encrypted with a ...


2

If you treat a request specially because it comes from a particular IP address or includes particular cookies, then there is a potential for CSRF. If no machine-specific information influences how the request is processed, then there is no potential for CSRF. A password reset page could be subject to CSRF if it somehow defaults to the last username used ...


2

Even if this would work and you could block JavaScript from performing XMLHttpRequests - which as shown by @Alexander is not the case (ActiveXObject would be another alternative) - it doesn't really limit the dangers of XSS. An attacker still has a number of possibilities: Defacement Phishing: For example, add a login form, which sends the entered data to ...


2

Securing User Credentials – Session Cookies Vs. JWTs: - Implement HTTPS on your server, and the login form is posted over this secure channel - Store the session ID in a secure, HTTPS-only cookie that can only be sent to your server over secure channels - Preventing Malicious Code (XSS):Don’t use Local Storage - Using JSON Web Tokens to Secure Your Web ...


2

Send the token over TLS. Sign the token with a couple of private/public keys (i.e. RSA, ECDSA) to prevent tampering (You don't use a secret shared!). If your token gets stolen, the attacker can only use it for a short period of time. You can set the expiration time to 15min. JSON Web Encryption (JWE) provides confidentiality of content. You can use ...


2

The problem is that access tokens are not bound to the client. Hence there is no way to know if an access token was issued for your client or for another client. Basically, from OAuth 2.0 point of view, whoever own the access token is YOU. I wrote a big answer explaining how this is a problem. Here is the attack you can mount : Let's say your REST ...


2

If you control the CAS then it is upto you how you access a new access token. Since your user has already authorised the SPA using your CAS, if the session is still valid with the CAS there is no need to ask them to reauthenticate using their credentials. Of course, it is upto your acceptable risk level for how long they should remain authenticated at the ...


2

A web browser is not a DRM platform, full stop. The state of the art in this general area are malware distribution techniques, and javascript obfuscation. Google is the best source for the latest news, this space changes quickly. Compared to state of the art, techniques mentioned in the question would not divert a skilled analyst interested in ...


Only top voted, non community-wiki answers of a minimum length are eligible