Test in Forgot Password Page n Change Password, cuz the registration usually have length limit but others don’t.
Use a password around 150-200 words to check if there has length limit. Then choose a longer password n keep checking the response time, to see if the app crashes for few seconds.
reason: The long password will cause a problem while hashing it for storing in dataset.
Long string DoS:
Create app and put field like username or address or even profile picture name parameter (second reference) like 1000 character of string .
change the response value of (eg: login) success to ‘true’ from ‘false’
Status Code Manipulation
change the status code from 4xx to 200 to see if if can bypass
2FA Code Leakage in Response
check the response of the 2FA Code Triggering Request to see if the code is leaked
JS File Analysis (rare)
some JS files may contain info about the 2FA code
2FA Code Reusability
same code can be reused
Lack of Brute-Force Protection
(possible)
Missing 2FA Code Integrity Validation
Code for any user acc can be used to bypass the 2FA
CSRF on 2FA Disabling
signup for two account -> Login into attacker account & capture the disable 2FA request -> generate CSRF POC with .HTML extension -> Login into victim account and fire the request — — -> It disable 2FA which leads to 2FA Bypass.
<methodCall> <methodName>pingback.ping</methodName> <params><param> <value><string>http://<YOUR SERVER >:<port></string></value> </param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string> </value></param></params> </methodCall>
pingback.ping SSRF (internal PORT scan only)
1 2 3 4 5 6 7
<methodCall> <methodName>pingback.ping</methodName> <params><param> <value><string>http://<YOUR SERVER >:<port></string></value> </param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string> </value></param></params> </methodCall>
Exploiting clickjacking on the same endpoint bypasses all CSRF protection. Because technically, the request is indeed originating from the legitimate site. If the page where the vulnerable endpoint is located on is vulnerable to clickjacking, all CSRF protection will be rendered irrelevant and you will be able to achieve the same results as a CSRF attack on the endpoint, albeit with a bit more effort.
Finding CVEs
CVEs 1.Grab all the subdomains i.e, subfinder -d domain.com | tee -a domains.txt 2.Grap all alive domains i.e, cat domains.txt | httpx -status-code | grep 200 | cut -d “ “ -f1 | tee -a alive.txt 3.Run nuclei basic-detection,panels,workflows,cves templates differently and store results in different file. i.e, cat alive.txt | nuclei -t nuclei-templates/workflows | tee -a workflows. 4.Read each output carefully with patience. 5.Find interest tech used by target. i.e, jira 6.put that link into browser check the version used by target. 7.Go on google search with jira version exploit. 8.grep the cves 9.Go to twitter in explore tab search CVE(that you found from google) poc or CVE exploit 10.Go to google and put cve or some details grab from twitter for a better poc read writeups related to that. 11.Try all cves if success report it.:)
important functions first When reading source code, focus on important functions such as authentication, password reset, state-changing actions and sensitive info reads. (What is the most important would depend on the application.) Then, review how these components interact with other functionality. Finally, audit other less sensitive parts of the application.
follow user input Another approach is to follow the code that processes user input. User input such as HTTP request parameters, HTTP headers, HTTP request paths, database entries, file reads, and file uploads provide the entry points for attackers to exploit the application’s vulnerabilities.This may also help us to find some critical vulnerabilities like xxe,xxs,sql injection
hard-coded secrets n credentials Hard-coded secrets such as API keys, encryption keys and database passwords can be easily discovered during a source code review. You can grep for keywords such as “key”, “secret”, “password”, “encrypt” or regex search for hex or base64 strings (depending on the key format in use).
use of dangerous functions n outdated dependencies Unchecked use of dangerous functions and outdated dependencies are a huge source of bugs. Grep for specific functions for the language you are using and search through the dependency versions list to see if they are outdated.
developer comments, hidden debug functionalities, configuration files, and the .git directory These are things that developers often forget about and they leave the application in a dangerous state. Developer comments can point out obvious programming mistakes, hidden debug functionalities often lead to privilege escalation, config files allow attackers to gather more information about your infrastructure and finally, an exposed .git directory allows attackers to reconstruct your source code.
hidden paths, deprecated endpoints, and endpoints in development These are endpoints that users might not encounter when using the application normally. But if they work and they are discovered by an attacker, it can lead to vulnerabilities such as authentication bypass and sensitive information leak, depending on the exposed endpoint.
weak cryptography or hashing algorithms This is an issue that is hard to find during a black-box test, but easy to spot when reviewing source code. Look for issues such as weak encryption keys, breakable encryption algorithms, and weak hashing algorithms. Grep for terms like ECB, MD4, and MD5.
missing security checks on user input and regex strength Reviewing source code is a great way to find out what kind of security checks are missing. Read through the application’s documentation and test all the edge cases that you can think of. A great resource for what kind of edge cases that you should consider is PayloadsAllTheThings.(github)
missing cookie flags Look out for missing cookie flags such as httpOnly and secure.
unexpected behavior, conditionals, unnecessarily complex and verbose functions Additionally, pay special attention to the application’s unexpected behavior, conditionals, and complex functions. These locations are where obscure bugs are often discovered.
EXIF geo data not stripped
EXIF geo data not stripped (sensitive info leaked)
Password reset links are usually addressed to your account name followed by the reset link. Also if the application allows you to have your account name with tags and special characters then you should try this.
steps
Create ur acc, edit the name to<h1>attacker</h1> or "abc><h1>attacker</h1> and save it.
request a password reset n check the reset email.
see if the <h1> tag executed.
tips
HTML injection are usually considered as low to medium severity bugs but you can escalate the severity by serving a malicious link by using <a href> for eg: <h1>attacker</h1><a href="your-controlled-domain"Click here</a>
You can redirect the user to your malicious domain and serve a fake reset password page to steal credentials Also you can serve a previously found XSS page and steal user cookies etc.
create an acc, record the user profile link, logout n clean all the cookies.
paste n visit the profile link, it may redirect u to the login like https://samplesite.me/login?next=accounts/profile or https://samplesite.me/login?retUrl=accounts/profile
try to exploit the parameter by adding an external domain eg: https://samplesite.me/login?next=https://evil.com/ or https://samplesite.me/login?next=https://samplesite.me@evil.com/ #or https://targetweb.com?url=www.targetweb.com.attackersite.com (with created subdomain) (to beat the bad regex filter)
else, try the XSS eg: https://samplesite.me/login?next=javascript:alert(1);//
Parameter pollution
Parameter pollution in social sharing buttons
find a social sharing button n get the sharing link.
modified it from https://taget.com/how-to-hunt to such as https://taget.com/how-to-hunt?&u=https://attacker.com/vaya&text=another_site:https://attacker.com/vaya
click the share button n see if the attack website is in the sharing content