Approaching Login, Signup Pages and Password Reset Instances for Bug Bounty Hunting
Hello Security World, In this blog we analyze the detailed approach to bug bounty hunting on login and sign up pages as well as change password instances and pages.
We are not detailing the full exploitation tutorials for each but we point the arrow to the bulls eye .
But are they really low-hanging fruits always? Maybe not. Let us dig right in!!
But why should one go for the login and sign up pages? Well as a beginner in bug bounty the very first attack endpoints include these pages and as professionals in the industry you can start from the login or password resets and dig your way up to critical bugs and all from a simple sign up
What makes the pages and easy to go after target? Because doesn’t matter the technology used because maybe someone is intimidated by web3 technologies but again all the technologies whether too old or futuristic the sign up and login pages are all vulnerable to quite similar bug trends and well, all allow user inputs and that makes it even more interesting.
Let us look and the bugs or issues approach for bug bounty or just web application security as a developer.
1. Captcha Bypass and Missing Captcha
The very first thing organizations and developers have mastered recently over the years is the use of captcha(Completely Automated Public Turing test to tell Computers and Humans Apart) to verify requests and avoid bots on their platforms and this includes the famous google captcha for : “verify you are not a robot” .
But well ,someone might say it does not really have anything on security or rather does not attract attention to bug bounty hunters but honestly you should look it up as the first targets to login and sign up pages.
The captcha exist to: prevent automated bots from performing malicious activities such as creating multiple accounts, spamming, scraping data, or carrying out brute-force attacks to crack passwords and as well to avoid fake clicks on revenue accounts and private click programs.
What if you bypassed the captcha set to carry out unrestricted brute-force, spamming, scrap data and even exhaust server resources for DOS or DDOS? That becomes a security issue and thus the presence of a CAPTCHA on webpages should always attract a bug bounty hunter to exploit the bugs / scenarios listed(but not limited to): creating multiple accounts, spamming, scraping data, DOS,DDOS , locking users out of their accounts or carrying out brute-force attacks to crack passwords
More on captcha bypass: https://book.hacktricks.xyz/pentesting-web/captcha-bypass
2. Improper password validation
The next easy to note bug is the incorrect password validation which comes hand in hand with error validations that can cause security issues like displaying sensitive information to the user or allowing attackers to gain information about the website’s architecture . This typically involves the regex ( Regular Expressions ) used in the password validation while creating an account and this validation is the one that alerts you with errors like: Well for a regex like(^(?=.*\d)(?=.*[a-zA-Z])(?=.*[A-Z])(?=.*[-\#\$\.\%\&\*])(?=.*[a-zA-Z]).{8,16}$)
The password must match:
- At least 8–16 characters,
- must contain at least 1 uppercase letter,
- must contain at least 1 lowercase letter,
- and 1 number
- Can contain any of this special characters $ % # * & — .
But some sites will not properly validate this and allows for any password length and patterns including breached passwords and as well give suggestive error messages like: “Password 1 for user admin is invalid”
Well , the error messages should not freely give details that allows for username enumerations by brute-force or scrapping by automations like selenium or just basic linux tools . The password regex should despite limiting the password patterns to specific requirements have atleast a specific set length for inputs .
This is because having unlimited length for password input even if by decryption in the database, the server will use up too much resources rendering the logins or sign ups for the specified user which well , could potentially lead to DOS .
The password regex should be easy to comply to but again secure from attacks by wordlists made from leaked password databases of common simple patterns . That keeps accounts safe .
As a bug bounty hunter or developer, the password regex and validations should be an area to check.
More on password validation and regex: https://gist.github.com/rogers0404/36762d5e2e60fc6bedc3a2a33c7b1310
3. Email validation
Ever signed up on a site with a fake email or a temporary one? Well , what did that imply or why did you do that instead of using your real email? Well, for different reasons obviously but why is this a security issue if out of control?
The use of fake emails and temporary emails allows for fake users and sometimes even accounts using other peoples emails and the accounts made can be used for malicious reasons like cyber bullying, spam, malicious access to services or just a threat actor rendering an organizations statistics inaccurate.
Email validation is done using email codes and sometimes even email links on sign up but well, temporary emails are not caught in the net. To filter out temporary emails there is several options including:
Blocking popular temporary emails domains / services. This helps avoid use of easily accessible temporary email services.
Use a third party email verification service like mail gun to filter out and notify users that disposable emails are not accepted and only keep clean records or legitimate emails
Implement email validation rules that are custom to fake email patterns and flag sign ups but be keen not to filter legitimate forwarders .
This becomes an issue where a user can sign up for accounts with fake emails and this time unlimited and for any malicious reasons and get away with thus violating the security measures for site / platform users and services.
4. Email Injection
This is in instances where you sign up as a user to a website using a real email and you get an email with the title or content like: “Hello John , welcome to xyz.com” .
That should be thoroughly checked as all the other entries may be an xml template but the name is fetched from database and added to each new users invites. How do we attack that?
An attacker can inject malicious content into an email message sent by the application. This includes HTML for the name that is added to the template or doing a full template injection for the emailed welcome message!! An attacker can change their account name to :
<button href="attacker.com">OFFER FOR YOU!!</button>Then change account email to victims email and victim gets an email verification with: Hello, OFFER FOR YOU!! and on click of the button they land on attacker domain
-> Another exploitation method is using email spoofing to render CRLF injection attacks!! By that you move from an out of scope email spoofing to in scope email injection bug.
More on email injection: https://www.invicti.com/learn/email-injection/
More on CRLF Injection: https://owasp.org/www-community/vulnerabilities/CRLF_Injection
5. Cross-site scripting (XSS) attacks
One of the most common attacks and well paid for bugs are from XSS which is an issue so hard to be rid of .
Cross-site scripting (XSS) is a type of security vulnerability that occurs when a website allows malicious code to be injected into its pages by an attacker. The attacker can use this vulnerability to steal sensitive information, such as user credentials, or to perform unauthorized actions on the website.
XSS comes with user inputs mostly and thus ecommerce and social platforms are the most affected from search bars, comments or forum posts, reactions and others. XSS can also be from unsanitized user inputs on html such as an input field or a URL parameter or storing unsanitized data to the database then rendering it on a page without proper encoding or filtering.
Once an attacker has injected malicious code into a page, they can use it to perform a wide range of actions, such as stealing session cookies, redirecting the user to a phishing site, or executing arbitrary code on the user’s machine.
The prevention of XSS in as much is hard to totally do is well mitigated by actions like filtering user inputs, sanitizing database, using content security policies, web application firewalls(WAF) and using HTTP-only session cookies to prevent them from being stolen by XSS attacks.
As a bug bounty hunter , XSS is always an exploit to try always on any target!!
Take a look at the different XSS types exploitations:
https://portswigger.net/web-security/cross-site-scripting
6. SQL injection attacks
Something to ALWAYS test on is SQL injection that typically involves where an attacker injects malicious code into a website’s SQL statements, allowing them to access, modify, or delete data in the website’s database just from the login and sign up pages and mostly use the login errors to render the database data.
If you ever run successful and with well detailed POC of SQL injections that is undoubtedly a valid bug !!
However , the well known mitigations for SQL injections are: Sanitizing user input, Limiting database privileges, using parameterized queries , use of access control and well , use of WAF(web application firewall)
What if you bypassed the SQL injection protections set?? Again that is a way to attack the target and is validated is successful in the bypass. Tools like sqlmap and others will come in handy for such
More on SQL injections: https://portswigger.net/kb/issues/00100200_sql-injection
7. Email Verification Bypass
What is email verification bypass? It is a technique used to circumvent the email verification process that is often required when signing up for an online service or platform.
How can you approach a target for such?
You can attempt to use temporary emails where a websites mailing integration fails to send emails to emails with mx records of common disposable email providers and fake emails that miss the mx records and if you create accounts with such and there is no restrictions to account features. That is a highlight.
Another way is the use of old records where you can reuse changed emails for new accounts and they get no verification prompts.
As a bug bounty hunter you can use creativity to try and bypass the email verification prompts by several techniques.
8. Parameter Pollution
Another approach to login and sign up pages is parameter pollution where you try and manipulate the values of parameters that are passed to a web application in order to modify its behavior.
This can be done for sign up and forgot password pages where you can use parameter pollution like: email=victim@target.com&email=attacker@gmail.com and the reset link gets emailed to both victim and attacker. You can also employ other parameter pollution techniques like incremental parameter or listing depending on the tech stack.
More on parameter pollution: https://book.hacktricks.xyz/pentesting-web/parameter-pollution
9. Exploiting Forgot Password and Change Password Instances
Another feature of login and sign up pages is the forgot password where a user is allowed to request new passwords or password links to change account passwords.
How can this be exploited? Lets us do a quick list of the possible scenarios to exploit
Password reset can be exploited from:
1. Email reset links where parameter pollution can make attacker reset password of any user by emailing the reset token to their email and the victim at the same time
2. Weak regex in new temporary passwords where an attacker predicts the pattern for the emailed new temporary passwords and uses brute-force or custom dictionaries for attacks.
3. Password reset token leak in referrer header on POST requests and accessing any other links on the password reset pages
4. Password reset codes brute-force where an attacker can brute-force the confirmation codes that are emailed or sent via SMS to users on password reset requests
5. Password reset pages user enumeration, XSS and SQL injections.
6. CSRF where an attacker can force a password change to a logged in user where the pages do not employ use of recent password and new password on account settings.
7. CSRF on account settings where attacker forces an email change on a logged in user and resets the password then booted them off their own account.
8. Password reset sessions not invalidating old sessions and thus users are unable to flush out attackers from their accounts even on password change.
9. Use of easy to decrypt password reset tokens . Attackers can decrypt reset tokens sometimes easily and manipulate them to match victims account like for JWT tokens or basic MD5 or common encryption algorithms .
10. Use of easy to IDOR where the reset token decrypts on front end to user id reference and attackers manipulate that to change password of any accounts.
Well that is not all the possible exploitation methods for login, sign up and password reset pages abut that is the most common approach I give to the pages on any targets and work most of the times .
It is not a detailed exploitation tutorial but a skeleton of what to aim at with no limits to the technology used or version controls.
I will update the exploitation areas on a consistent basis on this blog.
THANK YOU
