A web app that queries the backend to retrieve your previously sent messages
To test if this feature is vulnerable to XXE, we could try and retrieve a local file
To do so, we'd have to add the XML entity definition ourselves:
Afterwards, include your entity in the field and send the request
The response should contain the contents of the local file "/etc/passwd"
But we can also take the same approach to request an internal or external resource and escalate this into an SSRF vulnerability!
2โฃ Exploitation via OOB technique
This exploitation technique involves us hosting a DTD file and referencing it in our payload
The XML parser will then parse our malicious XML data and retrieve the external DTD
That DTD file contains our payload
And just as before, we can send our request and retrieve the contents of a local file for example!
We hope you've learned something new from this thread on XXE exploitation:
If you have enjoyed this thread: 1. Follow us @INTIGRITI for more of these threads ๐๏ธ 2. Retweet the first Tweet to share it with your friends ๐๏ธ
12 API hacking bug bounty tips you must try on your target! ๐
๐งต ๐
1๏ธโฃ Blind XSS via request headers
Applications log your data in various ways, including in insecure ways. Always test for blind XSS vulnerabilities by injecting your payload in common request headers, such as:
โข Referrer
โข X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Ip, Host (in case of a reverse proxy)
โข User-Agent
โข Etc.
Are your request paths prefixed with an "/api/v2"? Try testing legacy endpoints by:
โข Replacing "/api/v2" with "/api/v1"
โข Removing "/v2" altogether
Try similarly in case it's a subdomain: api-v2\.example\.com โ api-v1\.example\.com or api\.example\.com
XML eXternal Entity (XXE) injection is a vulnerability class that stems from inadequate user input validation during XML parsing, allowing attackers to take advantage of parser misconfigurations!
This often leads to local file read, server-side request forgery, and, in severe cases, even remote code execution!
However, XXE vulnerabilities are much harder to spot nowadays.
You must pay close attention to application components that might accept and process XML data, such as:
โข Document converters (Word/Excel)
โข SVG file processors
โข RSS/Atom feed processors
โข Importing features (accepting XML data)
This is the thread I wish someone created for me when I started participating in bug bounty! ๐
Not everyone shares these methods... but
Here are a few tips to help you identify & exploit more IDOR vulnerabilities! ๐ค
๐งต ๐
IDOR (insecure direct object reference) vulnerabilities are present in web services that directly reference a data object without proper access controls!
The data object can be anything, from sensitive fields that are stored in databases to files stored in a storage bucket.
Prefer a video instead? Watch our "IDOR In 100 seconds" explanation video on Youtube! ๐