This question already has an answer here:

Basically, I've found an XSS injection by changing the payload with the X-Forwarded-Host header, since its value is reflected in the document and is not sanitized.

An example, this is the document source:

<a href="http://[PAYLOAD]"></a>

I set the X-Forwarded-Host to foo"></a><script>alert(1)</script>, and the alert immediately popups.

Does an attack schema exist behind this type of XSS?


Since to exploit this type of XSS I have to profit of the CORS implementation, I've found this:

GET /index.php HTTP/1.1
Host: example.org
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Origin: https://milkislyudxi.com

which returns this:

HTTP/1.1 401 Unauthorized
Date: Sun, 15 Oct 2017 20:30:45 GMT
Content-Type: application/json; charset=UTF-8
Content-Length: 113
Connection: close
Set-Cookie: wfvt_3441637102=59e3c57552f99; expires=Sun, 15-Oct-2017 21:00:45 GMT; Max-Age=1800; path=/; secure; HttpOnly
X-Robots-Tag: noindex
Link: <https://example.org/>; rel="https://api.w.org/"
X-Content-Type-Options: nosniff
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Origin: https://milkislyudxi.com
Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Credentials: true
Vary: Origin
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
Server: cloudflare-nginx
CF-RAY: 3ae589bca9b44316-MXP

{"code":"rest_cannot_access","message":"Only authenticated users can access the REST API.","data":{"status":401}}

so, is this exploitable?

marked as duplicate by Arminius, Anders, Xander, Steve, Serge Ballesta Oct 25 '17 at 15:57

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Hi @Arminius, it's not a duplicate. I'm using the X-Forwarded-Host header, not the Host header in order to exploit the issue. – WayneXMayersX Oct 23 '17 at 19:56
  • It's a different header name, but the question and answer are functionally equivalent, which is what counts. – Xander Oct 24 '17 at 17:54

Reflected XSS from HTTP headers usually isn't exploitable. You need to trick the victim into sending a request with a malicious header, and how would you do that? You can't just craft a malicious link as you would if the reflection was from the URL. There's a risk that the only person you can own with this is yourself.

However, I still see two possibilities:

  • Stored XSS, i.e. if your header value is displayed to someone else. This would be the case for e.g. a log.
  • If, and this is a big if, the site has a CORS policy (Access-Control-Allow-Headers) allowing that header to be set, you could trick the victim to visit a site under your control that makes an XHR call to the vulnerable site.
  • I think I just found the application allowed access from my requested origin https://evil.com (CORS). How can I exploit through this? – WayneXMayersX Oct 23 '17 at 20:11
  • @WayneXMayersX Read up on CORS and how to make HTTP requests with JS. – Anders Oct 23 '17 at 20:17
  • Sorry, I'm reading but I still don't understand. How do I make it do an XHR by using CORS? Do I need to bind the JS file in the index by using <script src="code.js"></script>? – WayneXMayersX Oct 23 '17 at 20:33
  • I've updated the OP, please read it. I've posted the request/response body against the webpage with CORS. – WayneXMayersX Oct 23 '17 at 20:48
  • 1
    Please don't change your question when you already have answers. And no, it is not exploitable since the header in question (X-Forwarded-For) is not listed under Access-Control-Allow-Headers. – Anders Oct 23 '17 at 20:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.