Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working on a project that is creating two new, separate web modules (possibly even on different servers) to support a new web application, with one serving up a static JS-based UI and the other project providing an API. The API will be secured by role, meaning that you must be logged-in and have the right role(s) in order to access endpoints, however I was wondering whether there's much merit in securing the UI?

I'm not talking about SSL, as hopefully we'll be able to enforce that on both projects, but more about whether it's ok to just dump a single, large JS file onto a user's machine (once they've logged in with any role), regardless of which roles they have, and to rely on the API to secure the data?

I get the feeling I'm missing something fundamental here, but as far as I can see the only real risk is in terms of application logic in the UI being visible to all customers, although it would obviously be minified - and therefore obfuscated.

Apologies for the slightly vague question ... I'm afraid this is not an area in which I have much experience.

share|improve this question
    
I am not sure I can understand your scenario completely. So you have a JS you send and user and then, what? They can only use certain data depending on his role? who checks the role? –  kiBytes Feb 10 at 17:12

4 Answers 4

up vote 6 down vote accepted

If your API is solid, then the real vulnerability relates to whether or not you can be certain the user is who they say they are.

One attack vector is called cross-site request forgery ("CSRF" or "XSRF"). Basically, someone impersonating another user and making requests to your server.

When you establish a session (which contains the roles for a given user), you need to make sure that nobody else can hijack that session. This is typically done by setting a unique cookie on the user's machine that's "http only" (i.e., a cookie that client-side JS shouldn't be able to manipulate), then ensuring that that cookie is the same on subsequent requests.

Here's a Node module intended to harden the web server with CSRF protection -- among other safeguards -- that might be worth looking at: https://npmjs.org/package/helmet

Re: the API specifically, here's a really interesting breakdown of someone hacking GitHub.

This is probably going beyond your security needs, but keep in mind that any nefarious Chrome extension with the right permissions can alter the client-side in such a way as to break your security model (by sending data offsite, or changing the UI, for example).

share|improve this answer
    
Thanks. Some good answers, but this one gives me the most, specific detail, so thank you. –  Martin Feb 11 at 10:12

Unfortunately, you cannot restrict information from a user effectively once it gets to the client computer. In other words, if I understand you correctly that you are sending a JS file with code or information that you don't want the user to be able to read unless they are of specific roles, then you will not be able to accomplish that goal. You will need to filter the information on the server side before sending to the client. This can be a time consuming task to always check the user roles before sending data. This requires more calls to the server as the user does certain tasks that require information. But such actions I believe are required in order to make sure information is being access only by correct users.

Minified js doesn't really provide much obfuscation once it has been sent to the user.

share|improve this answer
    
Not quite. All the data - obtained from the API - will be secured by roles. The real question may be for me to analyse the client-side code and see if there's any proprietary code or security risks in letting anyone see the code that calls the secure API. I'm aware that minification is no obstacle to a determined attacker with plenty of time, but it would deter a casual hacker quite succesfully. –  Martin Feb 10 at 21:01
    
I haven't heard that before, of minification successfully deterring the casual hacker. I just assumed even casual hackers would know of free online tools such as jsbeautifier.org which can reverse a minification in some circumstances. I too have service calls from the client side for my applications so hope someone provides better recommendations than me on this question. Best –  user3219814 Feb 11 at 16:25

I think you are on the right track. As long as the API is secure and won't allow incorrect behavior, then there is no way for the UI to be manipulated to cause bad behavior directly, at least as far as the application is concerned.

The problems start when you realize that from the user's perspective the UI can't be trusted though. If it is possible to manipulate what the user sees, then it may be possible to get them to enter incorrect information by misleading their input. Similarly, information leakage from the UI may or may not be a problem in your context.

You won't have to worry about bulk exploits breaking business rules, since the API won't allow it, but you still have security concerns around the end user experience.

share|improve this answer
    
Thank you. So, what sort of steps could one take to minimise the concerns of others attempting to "manipulate what the user sees"? –  Martin Feb 10 at 20:59
    
@Martin - using SSL and protecting against things like cross site scripting issues are a start, but there are a lot of different possible concerns. Making sure input to JavaScript is validated, making sure that it isn't possible to inject markup in to pages via other forms of input, etc. –  AJ Henderson Feb 10 at 21:00
    
@Martin You can also use en.wikipedia.org/wiki/Content_Security_Policy to further secure your WebApp and be informed about attacks (that violate the policy) in progress. –  Matrix Feb 11 at 7:29

Theoretically it's sufficient for just the API to be secure, such as the case with typical server-client applications where the user uses a client of his choice and it's the user's problem if the client is exploited.

However in the case of a website, since you're providing the client (the web interface) it's up to you to ensure that it cannot be exploited by third parties once the user has logged in using techniques like XSS and CSRF.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.