What are (if any) the security drawbacks of REST B

问题:

I have this application that consists of a REST back-end intended to servicing requests from an HTML5/JavaScript client (which I'm also building).

I'm planning on implementing an authentication mechanism that uses Basic Authentication where the JavaScript client would store the Base64-encoded user's credentials for the duration of a session. These credentials would be sent with each REST request in the "Authorization: Basic" header.

All the conversation between the JavaScript client and the REST backend would occur over HTTPS. I'm know that's a performance drawback in itself as it adds the overhead of encrypting/decrypting every single request/response, and that's ok for now.

What I'm really interested in at this point is the security aspect of it. I know the schema I've described is nothing novel and a lot of people have used it in their implementations (at least that's my understanding). However, I'm interested in knowing if anyone has encountered any security breaches or drawbacks with that.

The only thing I can think of would be if malicious code on the client side could somehow gain access to the stored credentials… I think thats is highly unlikely (but hackers are a creative bunch and some JS engines are buggy, so you never know :-)). Thoughts?

回答1:

The “hard” credentials should never be stored in an area that is accessible by Javascript, otherwise you open yourself wide to XSS attacks.

I recommend using access tokens and storing them in HTTPS-only cookies. You do an initial exchange of hard credentials for access token, then use the token (which is time limited) for subsequent requests.

I have written a lengthly article on this subject and It covers my answer in detail: Token Based Authentication for Single Page Apps

Hope this helps!

回答2:

CORS issues aside (assuming you're making rest calls to your same domain), the big concern is the client would need to have the credentials inside the javascript. Anyone would be able to read your code and use them (as you've pointed out).

Even if the credentials are just the users own, anything in your client side could be in danger of exposure by cross site scripting or any browser plugins that can manipulate the DOM (I'm thinking for example things like the selenium testing IDE)

回答3:

Basic authentication is really basic ;-) You don't really control the session, ... Here is a link about a more advanced approach (token-based authentication) for RESTful services: https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/.

Otherwise I agree with the previous Robert's answer that we need to be very careful when storing credentials in the client side (XSS attacks).

The problem with cookies is that your client needs to be a browser to leverage this feature transparently... If it's the case, you can leverage this. If you're opened to any REST clients, it could be a problem since clients need to handle cookies manually. Moreover it's really not the better approach for authentication within RESTful services ;-)

I don't really see other approaches (exception of cookies) to implement authentication in SPA in a convenient and flexible way. Notice that JavaScript frameworks like Angular provided supports to prevent from XSS attacks.

I give an answer here about such issue: Is there any safe way to keep rest auth token on the client side for SPA?.

Hope it will give hints to your issue. Thierry