- Status Closed
-
Assigned To
cbay - Private
Attached to Project: Security vulnerabilities
Opened by freetb - 14.02.2024
Last edited by cbay - 16.02.2024
Opened by freetb - 14.02.2024
Last edited by cbay - 16.02.2024
FS#29 - URL Override in api.alwaysdata.com
Description
I discovered a potential vulnerability in api.alwaysdata.com that could allow an attacker to override URLs by manipulating the X-Forwarded-Host header. This issue could potentially lead to unintended redirections or access to restricted resources.
Proof-of-Concept
To demonstrate this vulnerability, we can use a simple HTTP request with a modified X-Forwarded-Host header. Replay the following request;
GET /v1/ssh/doc/ HTTP/1.1 Host: api.alwaysdata.com Accept-Encoding: gzip, deflate, br Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Connection: close Cache-Control: max-age=0 X-Forwarded-Host: evil.com Cookie: flyspray=ef2b9025azb8fd028bf6 Referer: https://api.alwaysdata.com/doc
Mitigation
Blocking or filtering out the X-Forwarded-Host header entirely and relying on other methods to determine the original domain (e.g., using the Host header or server logs).
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
I'm not sure I understand what the issue is. When you add the X-Forwarded-Host header then what happens exactly?
Kind regards,
Cyril
I will send a video
Video poc: https://file.io/UiLoiQ9vKVgy
URL Override involves some HTTP headers that can be used to override parts of the request URL or response body. This could affect the routing and lead to unvalidated redirects. If a caching system is in place, this may enable cache poisoning attacks.
I agree that it's not normal behaviour, however I don't think it can be exploited in any way.
I would need a PoC for that.
Well.. It wasn't vulnerable to CSRF so looks like a dead end. Thanks