API Misconfiguration - No Swag of SwaggerUI

Summary

API misconfiguration refers to the improper or insecure setup of an application programming interface (API). This can include issues such as weak authentication, lack of input validation, or improper access controls.

API misconfigurations can provide an attacker with unauthorized access to sensitive data or the ability to perform actions on behalf of a user. This can lead to sensitive data leaks, system compromise and other security issues.

Description

I found an API misconfiguration on SwaggerUI endpoint in one of the web application on a private program. It was leaking the authorization token in the local storage of the web application which I used to find the sensitive information of the users on the website. However upon investigating the requests by accessing the SwaggerUI endpoint it gave me an error saying “Unauthorized, Full authentication is required to access” and one thing that caught my eye was WWW-Authenticate header with the starting value Bearer in the response, which means an Authorization request header with starting value Bearer will be used.

I started digging for the token in the requests but did not find any token then I started looking in the cookies, localstorage and sessionstorage for the token and found an authorization token being stored in the localstorage of the application. I copied the token and used it in the request then I changed the {serviceIdentifier} to 1 and I was able to enumerate the userlist which contained employee details like firstname, lastname, employee id, email, department name and phone number.

What is SwaggerUI ?

Swagger UI is a user-friendly interface for displaying and testing the endpoints of a RESTful API that is defined using the OpenAPI specification. It allows developers to easily interact with the API and view the various requests and responses in a simple, intuitive format.

How I found this vulnerability ?

  1. I went to my target endpoint of swaggerUI and intercepted the request > sent it to repeater and clicked on send

2. Then I searched for authorization token into local storage by right clicking > Inspect > Storage > LocalStorage

3. I copied the authorization token from the local storage and pasted it in a file for using it in a request

4. Then I added the Authorization header with the starting value as Bearer followed by authorization token

5. I clicked on Send and got users details

Why this happened ?

In my opinion,

There were two issues here which led to this vulnerability

  1. Accessible swaggerUI endpoint
  2. Overly permissive authorization token

Impact

Any user will easily be able to access all the user information which he/she should be restricted from accessing it.

Calculated CVSS

Vector String - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L

Score - 7.2 High

Mitigation

There would be two mitigations applicable for this issue

  1. Restricting the swaggerUI endpoint
  2. Granting proper permissions to the generated authorization token

An application should have two types of authorization, one for the normal user and another for the admin user and only admin user token should have the permission to access the details via swaggerUI endpoint.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jerry Shah (Jerry)

|Penetration Tester| |Hack The Box| |Digital Forensics| |Malware Analysis|