Intel XSS and Google Chrome XSS Auditor Bypass : Application Design Matters! Its True !

Last time, I talked about the role of application design in impacting the state of client-side XSS filters. You can read that blog post here: http://zeroknock.blogspot.com/2013/12/web-application-design-does-matter.html. However, concentrating on that hypothesis, another case study came to my notice. I notified a Cross-site Scripting (XSS) bug in the Intel retailer website. The Intel security team removed the vulnerable web page from the its Internet facing environment. Responsible disclosure is the way to go.

What's the learning lesson here? Occurrences of XSS vulnerabilities are not new but the interesting part is how the vulnerable application impacts the browser defined security components such as XSS filters. In this case study, Google Chrome XSS auditor (enabled by default) again fails to perform the desired work for what is designed for.

The idea here is not to show that there is an XSS bug in Intel website rather to show execution of XSS payloads depends on the application design and there is always an unexpected behavior. Even sophisticated client-side XSS filters can be bypassed easily. I do not have time to investigate what caused the XSS payload to bypass Chrome's XSS auditor. I will notify the Google Chrome team so that they can take a look into it.

Proof-of-Concept: I used the very simple payload : JavaScript:alert(document.cookie) in "URL" parameter for the vulnerable redirect.asp webpage.

Injected XSS Payload !

The payload gets embedded as a hyperlink in the webpage. Amazingly, the XSS auditor accepted to render that payload. So, the XSS injection worked successfully and resulted in cookie extraction.

Successful XSS Injection !

Keep on trying !