Broken Authentication and Session Management
Securely authenticating users, managing their sessions when connected, and ensuring proper logout when the sessions end are essential activities when delivering web applications. As are requests for account creation, password change requests, and password resets. Each of these activities can provide a target for malicious attackers trying to compromise a web application.
What is the vulnerability and what can be done to mitigate it?
Poorly configured site authentication or session management can allow attackers to compromise passwords, site keys, session tokens, or spoof legitimate user identities. The ways in which authentication and session management can be compromised are shown below with advice on how to mitigate the risk:
- Storing passwords in plain text – Account passwords should not be held in plain text locally in storage within the web application infrastructure. Neither on physical storage or in memory. Passwords that need to be held should always be protected by a strong cryptographic hashing algorithm. Many commercial solutions are available to ensure that passwords stored locally can be encrypted. These should be investigated before deciding to implement a custom hashing routine. Commercial options are kept up to date for you and come with expert advice and support.
- Transmitting passwords in plain text – If storing passwords locally in plain text is not something that should be done, then the same applies when passwords are transmitted over the network. Plain text passwords can easily be intercepted on both wired and wireless networks. In order to fully protect passwords, it is necessary to secure the network session with Secure Sockets Layer (SSL), or Transport Layer Security (TLS) encryption. Simply sending the password over the network in a hashed format isn’t sufficient. An attacker could grab the hashed password in transit and send it back to the server without having to decrypt it. Adding SSL with certificates to protect transmission prevents this. SSL encryption is a resource intensive operation. It is ideally a process that should be handed off to a device that is optimised to perform it. There are KEMP LoadMaster solutions that are optimised to perform SSL offloading alongside their other load balancing functions.
- Using passwords that are easy to guess or brute force – Passwords should not be common words that are easy for an attacker to guess. Nor should they be so simple and short that a brute force algorithm used by an attacker could stumble upon the password in a reasonable time. There should be a password policy in place that mandates a certain length of password, requires special characters, prevents password reuse, and forces periodic password changes.
- Allowing unlimited logon attempts – As mentioned in the previous point, passwords should not be so short that they can be stumbled upon in a reasonable time using an algorithm that tries every combination in turn. Account security settings should be set to only allow a very limited number of failed password attempts before an account is locked. This prevents brute force attacks.
- Poorly implemented password change mechanism – Only the actual user of an account should be able to successfully request and execute a change in their password. Information that only the legitimate user should have access to should be used to confirm identity. For example, a security code can be sent to their mobile phone and they are required to enter this code before being given access to a password change facility. For a password change request the old password should be asked for as well. This is known as two-factor authentication.
- Insecure password recovery features – If a user forgets their password and requests a reset then they should be presented with the same mechanism to confirm their identity that is used for allowing them to change their password. In this case they will not know their old password, hence the reason for the reset. Some other security question should be used alongside a code sent to a trusted mobile device to enable two-factor authentication before a new password creation screen is presented.
- Exposing account lists – Lists of accounts available for access to web applications should not be viewable. Attackers can use the accounts as a starting point for attacks.
- Session ID’s exposed in URLs – An authenticated user who is using a web application will generate multiple requests between her client and the web application servers. In order to make sure that the multiple requests are all associated with the users client they are bundled into sessions. Standard http does not support sessions, so a method of managing this is required. Whichever method used will likely use a session ID as an identifier to link http requests with certain clients. These session IDs should not be shown in the URLs that client devices are using to communicate with the web servers. If they are an attacker could copy the Session ID and potentially gain access to that clients authenticated session and compromise data.
- Session ID creation is not controlled centrally – Session IDs should never be under the control of users and clients to create. They should all be generated, controlled, and secured centrally by the authentication and authorisation mechanism.
- Session IDs don’t expire after time period or on logout – Once a Session ID is in use it is a very powerful token that provides access to the data and services of a Web Application. If it falls into the control of an attacker it could be used in lieu of a logon account and password. It is vital that Session IDs have a built in time to live and that they are destroyed when a user logs out of a web application. This prevents an attacker using the Back button on a browser to establish a valid session.
- Browsers caching Session IDs – Session IDs should not be stored between browser sessions. They should be destroyed when a browser is closed. This prevents an attacker retrieving a valid session by using the history in a Browser or by finding the Session ID on the client’s local storage.
- Session IDs not using SSL – Session IDs are vulnerable to hijacking when they are passed across the network with http requests. As with hashed passwords it’s essential that session ID tokens are protected with SSL to ensure they remain secure.
- Trust relationships between components delivering a service – Many web applications are made up of component services that frequently interact to deliver data and functionality for users. It is tempting to set up trusted relationships between these components. This is not recommended. Interaction between different components should be based on authentication and authorisation requests that are initiated when required and destroyed when done. Like Session IDs there should be a time to live on these authenticated connections. Doing this ensures that if one part of a component system is compromised the other parts are protected with security measures.
How to protect against Broken Authentication and Session Management vulnerabilities
The points above outline how to protect against the various vulnerabilities that can compromise authentication and Session ID management. It’s also good practice to do regular reviews to ensure that users who have left an organisation don’t have access to their accounts. Engaging the services of external penetration testers to try and breach a web applications security is a good idea. In addition, make sure that out of the box settings for server and network security software are reviewed. Out of the box settings and accounts often provide known targets for attack. This topic will be covered in future posts about other vulnerabilities in the OWASP Top 10.
As stated in other articles in this series it’s also vital that systems are kept up to date with the latest software versions. Security vulnerabilities and bugs are constantly being discovered and fixed. General network security infrastructure should be kept up to date as well. Firewalls, content checkers, anti-malware systems and Load Balancers should be running the latest software patches. Additional security tools should also be deployed and kept up to date. The KEMP Web Application Firewall Pack (AFP) for LoadMaster includes tools that continuously monitor traffic to application and web servers. It detects and counters known vulnerabilities, including those outlined in the OWASP top 10. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities developers and system administrators may not have heard about are countered.
