Enterprise Web applications security

Challenges

We take security seriously and therefore we invest time into researching latest possible vulnerabilities and how to overcome such problems. Even if a company has state of the art software security in place there are still possible channels to breach the system. The most prevailing channel is human factor.

Human contribution

One of the main such vulnerabilities is email. An employee can be tricked to open email which has a sender with the company email or even by using intentional typographical errors and thinking it is coming from a colleague. For example, everyone in our company has email with domain @synetec.co.uk, but malicious email could have domain @symetec.co.uk or @synetec.com.  Such email can have an attachment with name Invoice_001 or Order_001, but in fact by opening the file the user downloads a malicious software which can encrypt files and demand ransom, called ransomware or send silently key strokes and revealing passwords. The same can be achieved by clicking on a link which redirects a user to a malicious website and downloads the eavesdropping software.  Unfortunately, this cannot be overcome by software, but only by using common sense and training.

Applications channels

The most common web application vulnerability channels are:

  • XSS – allowing attacker to inject malicious JavaScript code and change behavior of the website
  • CSRF – allowing attacker to trick a browser to buy something expensive or even execute a trade
  • SQL injection – allowing attacker to execute malicious SQL and affect database server

The technologies we use help us to overcome such problems. For example, Angular 5 blocks XSS attack by treating all input as un-trusted and sanitize the input, i.e. prevent execution of unknown JavaScript. The similar feature comes out of the box using ASP.NET MVC and Razor pages. CSRF is also built in Angular pipeline as well as ASP.NET Core by issuing X-XSRF-TOKEN and including it into POST requests automatically. SQL injection is taken care of by using Entity Framework by parameterizing queries, because queries are not constructed using string manipulations and concatenation.

There is other attack prevention ensuring security through obscurity.

  • Custom error pages
  • Redirect to a home page for non-existent route
  • HTTP- only cookie
  • Removed response headers revealing server/framework/technology information
  • Set X-Frame-Options header to SameOrigin or even better to Deny.
  • Browser’s own protection and set X-XSS-Protection to “1;mode=block”
  • X-Content-Type-Options : nosniff – this prevent browser guessing and run any file as JavaScript
  • If not using Entity Framework parameterize commands
  • Encrypt sensitive parts of the web.config using aspnet_regiis –pe
  • Tracing turned off
  • SSL for whole site including login page
  • Removed any tokens on logout
  • Local redirect instead of redirects only
  • Encoded strings passed in URL

 

Our solution

In architecting applications we decided to take approach leaning towards micro services by which each user interface whether it is web, mobile or desktop application, or another service can share common functionality. In order to securing resources‘ access there was a need to implement it in a manner once a user is logged in one can access various authorizer resources without need to be authenticated for each separate service.

It is quite common to use cookies with session identifier while the session is stored on a server and the cookie is sent automatically by a browser with every request. These can be secured by sending them only over HTTPS and not to be manipulated by JavaScript. However, they have several drawbacks.

  • ID stored in cookie must be used by a server to look up for a session leading to overhead in the large systems
  • They do not carry information defining what a user is authorized to do and again this has to be looked up by the server
  • They relate only to one system and cannot be used to authorize between desktop applications or between other services or APIs

For this reason, we adopted cookie containing a token shared amongst services called JSON Web Token (JWT) which tackle the problems with session ID cookies. These are supported by ASP.NET Core and works well with Identity Framework which is modern ASP.NET Membership system.

JWT is industry standard RFC 7519 used for identification between two parties using claims (https://tools.ietf.org/html/rfc7519).  It allows server to identify information without storing state on the server. The token itself is comprised of:

  • Header – contains algorithm and token type – base64 URL encoded
  • Payload or also called claims – this is data being secured– base64 URL encoded
  • Signature – hash verifying that the token was issued by a particular service

Each part in JWT is separated by period [Header].[Payload].[Signature]

Payload is digitally signed with algorithm in header using secret key  which ensures that the token was not tampered between the parties and can be further encrypted using JSON Web Encryption. As opposite to cookie carrying session ID, JWT is self contained and can carry information such as

  • Who issued the token
  • Who can use the token
  • When token expires
  • When token was created
  • What user can do

Conclusively, the JWT is modern solution to nowadays problems which increases security and efficiency of the system using it. It is a standard way of transporting security information which is easily implemented in complex enterprise solutions.

 

Written by Radovan Luptak

Leave a Reply

RECENT POSTS

RECENT JOBS

ADDRESS

509 The Print Rooms
164-180 Union Street
London, SE1 0LH
Phone: 0208 1444 206
Website: synetec.co.uk
Email: info@synetec.co.uk

DISCLAIMER

Important: The information contained in this website is for general information purposes only. Any reliance you place on such information is therefore strictly at your own risk. Synetec Ltd endeavour to keep it up to date and correct.
All images are copyrighted to their respective owners.
Bitnami