I am a Security Researcher and I am here to share my experience on Server side request forgery Automation,
SSRF Can be abbreviated as Server Side Request Forgery.
In Web Application Security, SSRF is a type of vulnerability or bug where an attacker abuses the functionality of a server and causing it to access or manipulate the information in the zone of that server.
SSRF refers to an attack where an attacker is able to send a crafted request from a vulnerable web application , In a Layman language attacker can ask the server to fetch the URL for him.
- Gau (By Corben) → https://github.com/lc/gau
- qsreplace (By tomnomnom) → https://github.com/tomnomnom/qsreplace
- httpx (By Projectdiscovery) → https://github.com/projectdiscovery/httpx
- anew (By tomnomnom) → https://github.com/tomnomnom/anew
- Subfinder (By projectdiscovery) → https://github.com/projectdiscovery/subfinder
- Sed, Awk, Grep
- Burpsuite → Click here to download
- Gau (By Corben) → Gau is a tool that is used to fetch all URLs from the website.
2. qsreplace (By tomnomnom) →It replaces all query-related strings values with a user-specified value.
3. httpx (By Projectdiscovery) → It is mainly used for checking the status code.
4. anew (By tomnomnom) → Append lines from stdin to a file, but only if they don’t already appear in the file.
5. Subfinder (By projectdiscovery) → Used to find subdomains https://github.com/projectdiscovery/subfinder
6. SED, AWK, GREP → Some useful supporting commands
For details kindly refer to this article:
As the tools mentioned in the above section, I would like to tell you about the precise summary of how the tool functioning:
- Initially, I have used gau to find all the URLs
- After that, I have used httpx for the status code
- Used grep and sed for finding the “equals to” pattern
- Then, used qsreplace and anew for putting payloads at the end of the “=” parameter and anew for appending the file with that payload
- After that, I have used the FOR LOOP to test each and every URL with an “=” parameter
- Then, After that just used the simple color-coding to identify whether it is vulnerable or not.
By using the above-mentioned tools we are able to find the SSRF vulnerability,
The Example image has been attached below:
- Abuse the trust relationship between the vulnerable servers and others
- IP Whitelisting bypass
- Scanning the internal network to which the server is connected
- Reading files from the webserver
- Retrieve sensitive info such as the Internet Protocol Address of the webserver behind the reverse proxy
Consisting of equal to(=) parameters are most likely to be vulnerable to SSRF.
- It could lead to RCE
- Possible to scan ports and Internet protocol addresses
To prevent Server side request forgery vulnerabilities in your web apps, It is hardly advised to use a whitelist of allowed domains and protocols from where the web server can fetch remote resources
According to the thumb rule you should avoid using user input directly that can make request on behalf of the server. You should sanitize and filter user inputs