Before we get started I have started a slack group dedicated to hacking. We welcome everyone from beginner to advanced to join. I will be on everyday answer questions, doing CTFs, and talking about cool hacks. If you enjoy hacking and are looking for like minded people join below:
NEW Hacking Group Slack Channel
Most modern day web applications are built with a front end programming language that communicates with an application programming interface(API). Developers will typically create some sort of api documentation which helps other developers understand and use their api. Swagger is a frame work that makes creating these documents easier. If left on a production server these files can help hackers identify vulnerabilities,design flaws, hidden functionality, and much more. These files provide a tremendous amount of information and should not be over looked.
When testing a web application one of the first things I do is figure out if its communicating with an api or not. With the rise of microservices you might notice a lot of websites sending ajax requests to get data from a backend api server. If you notice the target you are interacting with is an api or is communicating with an api you should immediately look for exposed api documentation. Some common paths to find swagger api documentation include:
As shown above swagger documentation gives you the name,path,and arguments of every possible api call. When testing api functionality this is a gold mine. Clicking on a request will expand it and you can perform all of your testing right there as shown below:
Seeing the image above I imminently think to test for insecure redirect due to the redirect parameter being present. Typically when looking at the documentation I look for design flaws, authentication issues, and the OWASP top 10. I have personally found hidden passwords resets that are easily bypassable, hidden admin functionality that allows you to control the entire site unauthenticated, sql injection, and much more.
Swagger is a popular tool so its bound to have some known exploits. I have personally found reflected XSS on several swagger endpoint while testing. A while back some one found this XSS flaw on the url parameter as shown below:
http://your-swagger-url/?url=%3Cscript%3Ealert(atob(%22SGVyZSBpcyB0aGUgWFNT%22))%3C/script%3EXSS in url parameter · Issue #1262 · swagger-api/swagger-ui
Here is the XSS. http://petstore.swagger.io/?url=%3Cscript%3Ealert(atob(%22SGVyZSBpcyB0aGUgWFNT%22))%3C/script%3E The…github.com
You can also get persistent XSS if you give it a malicious file to parse as shown below:XSS Vulnerability with Swagger UI v3 · Issue #3847 · swagger-api/swagger-ui
Q A Bug or feature request? Bug Which Swagger/OpenAPI version? 2 Which Swagger-UI version? 3.x How did you install…github.com
Its always a good idea to test for these vulnerabilities if you find an endpoint with swagger documentation.
Modern day web application are using APIs. Most of the time when you find an endpoint that uses an API you can find the API documentation as well. If you plan on finding vulnerabilities in the backend API you will need to know where to find this documentation and how to properly read and utilize it. API documentation is a gold mine, it allows you to easily find hidden features, design flaws, and so on. If you happen to come across swagger you should also check for those known XSS vulnerabilities. API documentation is your friend, a lot of the times I wont even need to open up burp suit because I can do all my testing in swagger. Next time your hunting for bugs make sure to check for and examine the API documentation you just might find a win.