Application Security

Introduction

Securing a web application has many aspects to it. Many best practices and security algorithms have evolved with time. Securing an application can be an endless affair. One has to assess the impact and likelihood and decide where to spend our energy and resources. This is commonly known as threat modeling. The threat modeling manifesto defines 5 values and 4 principles in this respect.

The best practices are meant to control the threats:

  • Prevention: Where a certain best practice can avoid the threat altogether
  • Mitigation: Where you reduce (but not completely eliminate) the likelihood or impact of a threat

Especially for a banking application, we have to take the security aspects very seriously, and take appropriate precautions upfront. Some of these precautions need to be taken at the application design level and at the code level, and those are of our primary concern for now. There will be some security practices / backup policies at the time of application deployment, and those will have to be considered at that time.

The best practices / algorithms keep getting updated every now and then. OWASP top 10 list is updated every few years highlighting the top 10 threats observed. We need to keep updated on the security aspects and refer to them every time we create a new application. Not only that, we need to keep upgrading an application in security aspects from time to time even beyond the development phase. The OWASP cheat sheets is a handy reference to the best practices with respect to security.

Specifics

  1. Multifactor authentication is used while logging in, both for agents / superusers and for the banker users. Reference

  2. Application stores password hashes in the database using a strong one way encryption algorithm that uses salts (Argon2id), so that even if a hacker gets access to the database, they will not be able to get the passwords of the users. Reference

  3. Application encrypts important variables while storing in the database using a strong encryption. algorithm (AES). TODO

  4. The user classes do not have a password field, so that they are not loaded in memory unnecessarily.

  5. Database queries use PreparedStatement, thereby preventing SQL injection attacks.

  6. Sensitive data (such as passwords, account numbers) does not get logged.

  7. Application logging is detailed, so that it would be possible to analyse it and detect any attacks. Reference

  8. Redis cache is used for token based authentication of every request. The token is automatically set to expire within certain time, unless renewed. This sets a natural timeout on user's login.

  9. A new login token gets generated every time the user logs in. This login token is then used throughout the user's session for authentication. It is stored in a cookie whose max age is 24 hrs, with Secure and HttpOnly flags set. Reference

  10. Browser side field validation is not sufficient. Important validations happen on the server side even if they are done on the browser side.

  11. The application uses roles and responsibilities framework for authorizing access to the banking users. The roles are specifically defined for a given bank, and the responsibilities (authorities) are mapped to those at the bank level. User responsibilities are considered while displaying options. They are also checked whenever the server receives a request.

  12. The application uses a single main database, plus optionally any number of bank databases. The schema is designed to be multi-tenant, in the sense that every database can cater to more than one banks. The application ensures logical separation within the banks through its queries. To facilitate that, every database table that can hold bank specific data has a bank id column. The SQL queries use this column to filter the results. For additional physical separation, a bank may have a separate dedicated database reserved for it.

  13. The application sets HSTS header on agent and banker user login pages. Therefore, the site is forced