1. Sub-Domain
1.1. Tools
1.1.1. Sublist3r
1.1.1.1. python3 Sublist3r.py -d (Domain) -v
1.1.2. Amass
1.1.2.1. usage:- amass enum -d (domain.com)
1.1.3. Aquatone
1.1.3.1. usage:- cat domain.txt | aquatone -out (output location)
1.1.4. AssetFinder
1.1.4.1. usage:- ./assetfinder Domain.com
1.1.5. Sudomy
1.1.5.1. usage:- ./sudomy -d (doamin.com) -o (output)
1.2. Online Tools
1.2.1. crt.sh
1.2.2. Virustotal
1.2.3. Subdomain Finder
1.3. Screenshot
1.3.1. EyeWitness
1.3.1.1. Usage:- EyeWitness.exe -f C:\Path\to\urls.txt -d [timeout in seconds]
1.3.1.1.1. ./EyeWitness -f urls.txt --web ./EyeWitness -x urls.xml --timeout 8 ./EyeWitness.py -f urls.txt --web --proxy-ip 127.0.0.1 --proxy-port 8080 --proxy-type socks5 --timeout 120
2. CSRF
2.1. WHAT IS CSRF?
2.1.1. What is CSRF? Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.
2.2. BYPASSES
2.2.1. Validation of CSRF token depends on request method Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.
2.2.2. Validation of CSRF token depends on token being present Some applications correctly validate the token when it is present but skip the validation if the token is omitted. In this situation, the attacker can remove the entire parameter containing the token (not just its value) to bypass the validation and deliver a CSRF attack.
2.2.3. CSRF token is not tied to the user session Some applications do not validate that the token belongs to the same session as the user who is making the request. Instead, the application maintains a global pool of tokens that it has issued and accepts any token that appears in this pool. In this situation, the attacker can log in to the application using their own account, obtain a valid token, and then feed that token to the victim user in their CSRF attack.
2.2.4. CSRF token is simply duplicated in a cookie In a further variation on the preceding vulnerability, some applications do not maintain any server-side record of tokens that have been issued, but instead duplicate each token within a cookie and a request parameter. When the subsequent request is validated, the application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie.
2.2.5. Validation of Referer depends on header being present Some applications validate the Referer header when it is present in requests but skip the validation if the header is omitted. In this situation, an attacker can craft their CSRF exploit in a way that causes the victim user's browser to drop the Referer header in the resulting request. There are various ways to achieve this, but the easiest is using a META tag within the HTML page that hosts the CSRF attack.
2.3. Blogs
3. Rate Limiting
3.1. Bypass Methods
3.1.1. 1. zseano bypass trick
3.1.2. 2. Bypassing Rate Limit Protection by spoofing originating IP
3.1.3. 3. Methods to Bypass Rate Limit
3.1.4. 4. Bypassing rate limit abusing misconfiguration rules
3.2. Blogs & Writeups
3.2.1. Yelp disclosed on HackerOne: No rate limiting for confirmation...
3.2.2. HackerOne disclosed on HackerOne: User login page doesn't implement...