Some of MY common attack techniques while testing for authentication

Here in this post I will take you through some of the common attack techniques to assess authentication modules / login functionality for web apps. For more topics visit - http://gotowebsecurity.com

Dirbuster / gobuster : Use & run dirbuster or similar tools to uncover all hidden paths on the web server. These tools are designed to run path traversal checks & disclose hidden accessible paths. Going above & beyond is really worth it as you may be able to find more authentication modules.

Nikto: run nikto on the web server to check if you are lucky to get some known authentication related exploits due to outdated software or presence of dangerous files etc.,

Default username & password :  Sometimes we come across portals where default versions are installed & misconfigured. In such cases we just need to check the version deployed & search for default credentials which would allow to login & help to exploit any known vulnerabilities after login.

Usage of Insecure or Non-Secure channel : Usually this is the easiest one to look for & would easily be caught by any security engineer when assessing login functionality.We need to verify if its running over http or https, some apps make use of both http & https protocols. Obviously http is an insecure channel & would allow attackers in same network to sniff the traffic & obtain sensitive data ( in this case login credentials) . Incase of https protocol we need to verify if there are any weaknesses in the implemented protocol.This can be done by using various tools, the easy one available online for everyone to use is SSLLabs.

 User Enumeration:  It is a technique to fetch valid user accounts associated with the application. In some cases it is easy to get few user accounts,like incase of a wordpress blog we can get user accounts associated with blog posts. In other cases we can try to fuzz with a list of common users or custom generated user list by using tools on the running application.

BruteForce:It is a technique used with all possible combinations for a given password length to find the correct password for a user account.This can be attempted on the enumerated user accounts if there are no anti brute force implementations. Choosing the password brute force combinations wisely will help to get results faster. This should be a last resort to break in as brute force could take significantly longer durations.

Self Register: If you are able to register your own account do so & then try to give victims user id & your registered account password to check if you can access victim account.Another scenario is that give victims id while registering & try to override his password.

Forgot password: use the forgot password feature to gain access to a victim user.Some applications if misconfigured usually reveal the token required to set the password in response.It is also possible that apps may directly reveal the passwords in response.Some apps send forgot password link using http protocol to set the new password which can easily be sniffed.

Host-Header Injection: one technique used here is to direct the victims forgot password tokens to attackers domain.

Password Storage: It is important for our passwords to be stored securely in an obfuscated format by the use of hashing techniques.In some applications we come across instances while registering an account or logging in to the application, the user passwords are revealed in plain text in sub systems or in responses or redirects.

Sql Injection: It is an attack technique used by carefully crafting a sql input that allows the user to break in to the system. The sql injection payloads usually depend based on the backend DB in use & its discovery in some cases is possible through error messages. There are also a few set of tools available which help here.

Input Reflection: When we try to attempt to login to an application with a non-existent user account we usually get the user input reflected in the error message such as “user1 is not found” in such cases it could potentially lead to XSS & in most cases it will be self XSS , in rare cases it could also lead to reflected XSS.

cache Headers: Check if appropriate cache headers are set to avoid sensitive data caching

CORS: Check if CORS is configured to restrict other domains from reading victims sensitive or personal data.

Cookie Settings:Verify if appropriate cookie settings (secure flag, http-only flag etc.,) have been configured for sensitive cookies such as session identifiers.

LFI/RFI/SSRF/redirects :Sometimes we come across applications hosting login functionality at a specific path.Example: https://abc.com/app?path=/ver1/db/login .In such cases check for existence of local file inclusion or remote file inclusion or server side request forgery or open redirects.