As we are covering OWASP top 10 vulnerabilities,broken authentication is one of it. Broken Authentication itself suggests the breach in the authentication procedure of a web application. Session management is the rule which checks for the interactions amid a web application and end-users. A web session is actually a transactional chain of HTTP commands and responses made by the client to a server. HTTP/HTTPS is the protocol to communicate between the website and the browser.

So, in broken authentication, hackers find the exposures where the breach could be done to dodge or seize the authentication functions.

Following are the ways where the authentication breach could happen –

• Probable login credentials.
• Exposed session IDs in the URL (e.g., URL rewriting).
• Vulnerable session IDs to fixation attacks.
• Unprotected user authentication credentials.
• Session IDs, passwords, and other identifications sent over unprotected and unencrypted connections.
• Non-rotated or Unshuffled session IDs after successful login.
• Undestroyed or not invalidated session values after logout.

Such attacks aim to get access to more than one account and gain all the privileges of the user which is attacked. These privileges let the attacker do whatever he wants.

EXAMPLES OF AUTHENTICATION AND SESSION BREACHES

Example #1: Probable login credentials

It is a matter of common sense that you should not keep the values of usernames and passwords so easy that everyone can predict them. The credentials should not be the ones which are used very frequently. Attackers can get a hold of this with ease. You should always use strong credentials.

Example #2: URL rewriting in exposed sessions

Consider a web application via which you book your travel reservations. The sites where we enter our personal data are easy targets of URL rewriting because the attacker can get data by putting session IDs in URLs. Check this –

http://travelsite.com/ticketbooking/premium_ticket;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=hyderabad

The authenticated user of this site is booking a ticket. This user wants to let his friends know about the ticket confirmation, so he sends this link. He doesn’t realise that he is also sending his session ID. When those friends use the same link, they can use his session as well as credit card.

Example #3: Non-hashed and Non-salted passwords

Sometimes, passwords are improperly hashed and salted which leaves a room for attackers to scrape them by gaining access to the database. Proper encryption along with adding salt to hashed passwords is an essential matter, else every user’s credentials will be at stake.

Example #4: Not setting application’s timeout properly

Consider that you access a public computer or an internet café or that of a friend/colleague for accessing a website or doing a transaction. After finishing up, you forget to click on the logout button and directly close the browser. The attacker can use the same browser after some time, and he gets what? An authenticated account with all the details! Even he can check it from the past sessions.

TIPS TO PREVENT BROKEN AUTHENTICATION AND SESSION BREACHES

• The complexity of passwords – This is a no-brainer that passwords should always be a combination of alphanumeric and special characters. You should essentially put a complex password.
• Length of passwords – The minimum length of a password should be at least having eight (8) characters. The complexity and length of a password go hand-in-hand. Together, they make a robust password.
• Preventing the login with brute force– The web application must have a code mechanism which disables the user account when there is a set of invalid login trials, like three or five. After the set number of login attempts, the user account shall be deactivated for a reasonable period of time.
• Enumerating username and password – If authentication fails the generic responses should be mentioned instead of specifying what exactly is wrong. Though this might hamper the usability factor for the user, it can safeguard from the attacks.

MANAGING SESSIONS

• Don’t show session ID in the URL – The session IDs should be kept hidden and not shown in the URL, else it can cause URL rewriting.
• Protect the credentials – The authentication credentials of users should be encrypted and while storing, the process of salting and should be done.
• Renew session IDs – The session IDs should be renewed after successful login.
• Destroy session IDs after the timeout – The authentication tokens or the sessions should be destroyed entirely after logging out.
• Beware of unencrypted networks – Sensitive data like session IDs, passwords, and similar credentials should not be used over unsafe and unencrypted networks/connections.

If you wish to stay protected from such type of brutal attacks, ESDS VTMScan is one of the best tools available as a web application scanner.