Improper Authentication
Last updated
Was this helpful?
Last updated
Was this helpful?
Check for comments inside the page (scroll down and to the right?)
Emails tricks
Check if you can directly access the restricted pages
Check to not send the parameters (do not send any or only 1)
Check the PHP comparisons error: user[]=a&pwd=b
, user=a&pwd[]=b
, user[]=a&pwd[]=b
Change content type to json and send json values (bool true included)
If you get a response saying that POST is not supported you can try to send the JSON in the body but with a GET request with Content-Type: application/json
Check nodejs potential parsing error (read ): password[password]=1
Nodejs will transform that payload to a query similar to the following one:
which makes the password bit to be always true.
If you can send a JSON object you can send "password":{"password": 1}
to bypass the login.
Remember that to bypass this login you still need to know and send a valid username.
Adding "stringifyObjects":true
option when calling mysql.createConnection
will eventually block all unexpected behaviours when Object
is passed in the parameter.
(root, admin, password, name of the tech, default user with one of these passwords).
Dictionarry attack using python script
Dictionary_Attack_Script.py
Or using tools like Crunc
The application returned an unusually large content-length (over 40,000 bytes!) on the redirection response.
The application was leaking its internal responses to every request while sending the user to the redirection to the SSO
So, it was possible to tamper the responses and change the 302 Found
header to 200 OK
and delete the entire *Location* header
, giving access to the whole application
Attack Scenario
The attacker uses the session cookies to authenticate as victim user.
vuln Explain
In this case, once a user logged into the application with valid credentials, it created a Bearer Authentication token
used elsewhere in the application.
This auth token expired after some time. Just before expiration, the application sent a request to the back-end server within the endpoint /*refresh/tokenlogin*
containing the valid auth token
in the headers and username parameter
on the HTTP body section.
Further testing revealed that deleting Authorization header
on the request and changing the username
parameter on the HTTP body created a new valid token for the supplied username
. Using this exploit, an attacker with an anonymous profile could generate an authentication token for any user by just supplying their username.
Steps
Find Refresh Token Endpoint
Remove Bearer Header
change username
Get the token for any user in response
Attack Explain
One popular CMS platform, Liferay, was used in an internal application in one case I examined. The application only had a single login page accessible without authentication, and all other pages were restricted on the application UI.
For those not familiar with Liferay, the CMS uses portlets for application workflow, which have a parameter as p_p_id within numeric numbers. For that application, it was possible to access the login portlet by changing the parameter to value 58. On the normal login page, only the login form was accessible. However, by accessing the portlet directly, it was possible to reach the Create Account functionality, which then allowed self-registration to access internal applications without proper authorization.
Please note that while Liferay used this workflow before, its latest version uses portlet names instead of numeric ids. Still, it is possible to access other portlets by changing names as well.
Play with numerical parameters like p_p_id
change it to 58 or parameters that use username play with them
[Admin Approval Bypass](https://hackerone.com/reports/1861487)
TikTok Account Recovery Flaws:
TikTok’s recovery process allows users to search for accounts using usernames, revealing linked phone numbers or emails without authentication.
Using Burp Suite and a script to bypass SSL pinning, Cekal intercepted API requests to endpoints like /tiktok_username/, /safe_verify/, and /available_ways/. These endpoints provided sensitive account details, such as masked emails and linked third-party platforms, via a "not login token."
Not Login Token Issue:
The "not login token," generated during account recovery, was overly permissive, allowing access to sensitive actions like sending verification codes to linked phone numbers or emails without needing account credentials.
Account Takeover Vulnerability #1:
A flaw in the password reset process allowed bypassing the SMS verification code by omitting the codeparameter, enabling password changes for accounts with known phone numbers. Using the not login token, attackers could reset passwords by only knowing the username, provided a phone number was linked. This was quickly reported and patched.
OTP Bypass for Unlinking Phone Numbers/Emails:
Cekal found that the same "verify token" used for unlinking phone numbers or emails was generated during 2FA setup when entering a correct password. This allowed attackers with the account password to bypass OTP verification and unlink contact details, facilitating account takeover. TikTok marked this as a duplicate and has not patched it as of 2024.
Account Takeover Vulnerability #2:
Cekal exploited flaws in the email change process, where the /email/update/ endpoint failed to validate the verify token properly and accepted the not login token instead of a session ID. By spoofing verification codes and using a verify token from 2FA setup, he could link his email to any TikTok account, enabling password resets. Reported and patched in early 2024, earning a $12,000 bounty.
Account Takeover Vulnerability #3:
A more advanced exploit involved using the not login token and a misconfigured /verification_manage/endpoint to obtain a valid verify token for any account without logging in. By sending a spoofed OTP and exploiting a 30-second validation window, Cekal could change an account’s email and bypass 2FA. This was patched but marked as a duplicate, with no bounty awarded due to a near-simultaneous report.
Authentication Bypass on via Subdomain Takeover of
A subdomain () is pointing to the CDN hostname (.) but has not been claimed yet.
The Single-Sign-On (SSO) functionality sets the cookie domain attribute as "[](%)".
The attacker claims the CDN hostname . and hosts own application.
A logged in user (*.ubnt.com) visits the subdomain (unknowingly or lured by attacker) and the session cookies are transferred to and logged by . (owned by attacker).
to Twitter - 1157 upvotes, $20160
to Snapchat - 891 upvotes, $25000
to Roblox - 718 upvotes, $2500
to - 340 upvotes, $4000
to Shopify - 287 upvotes, $20000
to Twitter - 260 upvotes, $700
to LINE - 223 upvotes, $12500
to Starbucks - 221 upvotes, $4000
to Razer - 196 upvotes, $1000
to Uber - 165 upvotes, $5000
to HackerOne - 151 upvotes, $1500
to Localize - 144 upvotes, $500
to - 143 upvotes, $8000
to Twitter - 122 upvotes, $2520
to Snapchat - 102 upvotes, $5000
to Starbucks - 92 upvotes, $0
to Picsart - 91 upvotes, $0
to Uber - 82 upvotes, $8500
to Zenly - 82 upvotes, $1750