Security Concerns To Build One AngularJS App

Mar 2, 2016
Best Practices>Web App>AngularJS>Technical
angularjs/best-practices/web-app

An AngularJS web app finally results in a Single Page Web Application, managing it’s own routes, states (models), incorporating workflows, CRUD operations and much more around some tasks. So, primarily we have to concentrate on the common flaws found in an web app and then figure out what kind of direct or derived vulnerability may be caused in our app.

  1. Eavesdropping: It actually happens in network layer. It has nothing to do with the coding done in the app.
    Solution: If there is no direct communication between users via the app, it’s a standard to deliver the app over SSL. But solution for this kind of attack is a combination of configurations starting from DNS setting to but not limited to use of HTTPS. (See also)

  2. Cross Site Scripting(XSS): This is where an attacker can inject scripts into a page sent by the server and browser treats the injected script as any other scripts inside the page.

  3. Cross Site Request Forgery(CSRF): A Cross-site request forgery is when a malicious site can use a visitor’s browser to make a request to your server that causes a change on the server. The server thinks that because the request comes with the user’s cookies, the user wanted to submit that form.

Cross Site Scripting(XSS)

Use Case: Showing menu based on privileges. Users with malicious mind-set can change some of the variables, such that, non privileged members can also see the higher privileged tabs.
Solution: Send or build the template, so it would only generate what is required. Nothing more. Ng-repeat may be a good resort here.

Use Case: Generation of some part of the page, depending on user input. One may input HTML to change the behaviour of the section.
Solution: Treat the user input as strings and do not bind the user input as ng-bind-html

Use Case: User may input some code as the query parameters like: http://abc.com?<script>alert(5)</script> returns "<p>There were no hits for <script>alert(5)</script>.</p>"

Solution: Use route parameters instead of query parameters. If it’s inevitable to use the query params, do not run eval on the string, use it as a string and of course check for the tags.

Lastly,

  1. Set correct mime type of the content, exchanged to-and-forth client and server
  2. If html templates are compiled into templateCache, correctly obfuscate the HTML replacing tags with HTML codes like, < should be replaced by &lt;
  3. It’s more than necessary to obfuscate JavaScript code with minifiers like Closure, YUI-Compressor etc. Signing tools may also be used, to check the page hash in server
  4. Depending upon the sensitivity of data, passing to the server, it may be required to encrypt the same
  5. Put each of the piece of the code into a closure, viz. an IIFE and if possible put ‘use strict’ at the top of each of them
  6. Use dependency injection into every providers. Life would be easy after minification
  7. If non obfuscated code needs to be used in client side, make the identifier names, as neutral possible. Use ‘re4ty_ft’ instead of ‘carPrice’
  8. Disable autocomplete in sensitive information fields. User may have to key-in (even can’t paste. Refer to CITI Bank’s login page) or press keys in a virtual keyboard
  9. It’s not advisable to put any files containing user-restricted-data in the webroot
  10. Don’t store information in a global variable

Cross Site Request Forgery(CSRF)

This form of attack includes but not limited to:

  1. Access cookie to change preferences
  2. Logout the victim
  3. Post a comment on behalf of the victim
  4. Use victim as a proxy to get data from the site
  5. Perform distributed password guessing attack, without even a pass hacker tool

Solution:

  1. Send a login hash along with a API key each time client calls the server
  2. Logout must be done, jointly by client and server, in both ways
  3. Best not to use a cookie
  4. For login and sensitive operations, use captcha, or two-factor-authentication apps like DUO
  5. It’s better to use two different (.aspx or .php whatever) pages for login and app
  6. No state should be persisted in the server, I.e. to say the REST API should implement a complete REST architecture
  7. Encourage the users to close the window after logout (Currently Google Chrome does not close the tab/window invoking window.close command)
  8. Make one landing page and from there on click of a button open a new address bar disabled window to redirect to the app

Glossary:

Blog comments powered by Disqus