The security of web applications is a major issue for organisations. SaaS platforms, internal applications, or e-commerce websites, all these systems must be secured to counter the increasing number of attacks targeting all their functionalities and components: servers, APIs, authentication, sessions, access control, third-party components, etc.
Beyond the protection against attacks, security has also become a key factor and a differentiating asset in pre-sales processes, particularly in B2B.
Securing your web applications is therefore vital, and this requires the implementation of development and security testing best practices. In this article, we will focus on best practices for securing the authentication, session management and access control systems of your web applications.
What are the best practices for securing the authentication, session management and access control systems of your web applications?
Authentication and session management
Authentication and session management systems are critical features of web applications. Authentication ensures that only legitimate users can access the application, while the session mechanism keeps track of the various actions performed by users on the application.
Vulnerabilities in these mechanisms are often targeted in attacks and allow attackers to spoof or hijack user accounts or sessions. It is therefore essential to design secure systems to counter these attacks and ensure the integrity of your data.
The following are the best practices for securing authentication and session management systems:
To secure authentication
- Do not hard-code logins and/or passwords.
- Ensure that each user account is nominative and used only by the user with whom it is associated. This will facilitate the identification of security incidents or potential vulnerabilities.
- Handle authentication error messages correctly.
Login failure messages should not indicate the origin of the error (e.g. unknown username or invalid password), as this provides valuable information to an attacker.
Indeed, during a brute force attack for example, a login failure message such as “invalid password” allows an attacker to focus on the user ID entered, which saves him a lot of time.
In addition, it facilitates user enumeration and thus data leakage when the user ID is the email address (which is quite common). This data can be used in social engineering attacks and especially spear phishing attacks.
- Implement an effective password policy.
The security of authentication naturally depends on the implementation of an effective password policy. Firstly, the complexity of the password that must be enforced when an account is created: it must be long enough (15 to 20 characters).
Furthermore, passwords containing the user ID, the name of the company or application followed by the year and an exclamation mark, are widespread practices known to attackers, who often carry out password spraying attacks. It is therefore recommended to force the creation of passwords that do not contain at least the identifier and to make users aware of the risks associated with the use of passwords that are too predictable.
Another issue is password expiration policies to encourage frequent password changes to prevent potential data leakage. At first glance, this seems like a good security measure. However, the analysis of user behaviour shows a different picture. In fact, most of the time, users simply create another password that is not secure because it is easy for attackers to guess and crack. It is therefore recommended to ban these password expiration policies and simply encourage users to choose a sufficiently long and complex password.
- Ensure that all authentication checks are performed on the server side and not on the client side.
- Ask for the user’s password before any sensitive operation (modification of sensitive information: password, e-mail accounts, payment information, etc.).
- Implement a secure password reset system.
The “forgot password” functionality and other recovery paths should not reveal the current password; and the new password should never be sent in clear text to the user.
A unique token, made up of a random string of characters, should be generated for each reset request and then invalidated once the reset is complete.
- Implement technical measures against brute force. For example:
- Limit the number of invalid logins and increase the delay after and between each login attempt.
- Set up a temporary IP block and/or display a CAPTCHA after several unsuccessful login attempts.
- Implement multi-factor authentication, preferably via authentication applications such as Google Authenticator, to ensure that the authentication process is performed by a human and not a bot.
- Store user passwords with a robust, iterative, and salted hash function.
User passwords should never be stored in clear text. They should be stored using secure key derivation hashing techniques such as the bcrypt algorithm.
For more information, you can check our article: How to securely store passwords in database?
To secure session management
- Ensure that session IDs are automatically generated and consist of a random string of characters, unique and long enough to avoid session hijacking by prediction.
- Generate a new session token after the authentication of a user to prevent session fixation attacks.
- Implement a session timeout and force re-authentication when users are inactive to mitigate the risk of an attacker using a hijacked session for a long time.
- Destroy a session and associated data on the server when a user logs out of the application.
- Do not expose session IDs in URLs.
- Use secure attributes for session cookies, including HTTPOnly, secure and samesite.
HTTPOnly prevents the session ID from being accessible to Javascript scripts, thus countering some session theft methods.
The “Secure” attribute informs browsers that the session ID must only be transmitted via HTTPS channels, which helps to counter some network sniffing attacks.
Finally, the “samesite” attribute protects against CSRF attacks. For more information, you can check our article: Protect yourself from CSRF attacks with the SameSite cookie attribute
Security of access control
Access control is the process of granting or denying access to a specific resource or functionality, based on the rights initially assigned.
Vulnerabilities related to lack of access control are often exploited by attackers to gain access to other users’ information, high-privileged user access or even administrator access.
Here are the best practices for securing access control on your web applications:
- Ensure that all pages in the application, which should not be public, have an authentication check.
- Assign access rights using the principle of least privilege.
- Check the user’s rights when a direct reference to an object (ID) is made before returning the relevant resources.
- Do not allow users to have direct access to the file tree on the server.
- Revoke the access of former users of the application.
Carry out a penetration test to assess the security of your web applications
Web applications are particularly attractive targets for attackers, due to their large attack surface and vulnerabilities that are too often ignored during the development or deployment of new features.
Implementing best development practices is of paramount importance as it helps to avoid programming and configuration errors, and therefore to multiply vulnerabilities that could be easily exploited by attackers. However, it is important to ensure that your web application is robust against real attacks. This is what penetration testing (or pentesting) is all about.
A penetration test is a simulated attack that aims to confirm or deny the effectiveness of security controls in a specific system by highlighting the risks created by exploitable vulnerabilities. It is built around a manual testing process, which aims to go much further than security audits through vulnerability scans.
On a web application, this will involve looking for vulnerabilities both on the server side and on the application layer, with 3 possible approaches: black box, grey box and white box tests.
In black box, the pentesters will not have any information or specific access to the application, while in grey box, the tests will be carried out with standard user access. In this case, rights tests will be performed to verify the correct partitioning of data and thus ensure that a user A cannot access the data of a user B (horizontal data partitioning) or an administrator (vertical data partitioning).
For a more in-depth analysis, white box testing may be considered. In this case, the pentesters will be provided with the source code of the application.
Regardless of the approach taken or the scope of the tests, a comprehensive report is produced following a penetration test. It includes the methodology followed, the vulnerabilities identified, the level of criticality, the possible exploitation as well as recommendations for correction. The penetration test can be combined with a remediation validation phase to check that they have been properly implemented and that there are no side effects.
A penetration test remains the best way to test the robustness of your web application. Not only does it identify security weaknesses, but it also raises awareness among developers and users of the best practices to be implemented in terms of cybersecurity.
Contact us for any question related to a penetration test project on your web application. We will discuss your needs and provide you with an intervention adapted to your security issues and constraints.