4

I know that basically every modern browser version has a cross-site-scripting blocker for XSSed URLs, as in the type of filter that actually stops a user from visiting the URL, warning them of the malice it might inflict.

But let’s say that somehow you (it doesn’t matter how) modify and mask the URL to be something else, but the actual URL has the XSS script in it.

For example, using a proxy site- for a lot of proxy sites any link that you click on appears to be exampleproxysite.com for the URL bar, and not the XSS URL, even though it is.

However my lack of knowledge limits me from jumping to conclusions, so for all I know the actual URL (with the XSS script) might be visible to the browser and therefore susceptible to the CSP.

  1. Would masking the URL effect how the XSS works, and if so
  2. Would this bypass modern browser XSS blockers?
Improve this question

1 Answer 1

Reset to default
4

If you're talking about Content Security Policy, then, no masking the URL doesn't allow an attacker to bypass the rules. No matter how many layers of redirection or obfuscation the attacker goes through, they eventually have to inject JavaScript code into the HTML document. At this point, CSP steps in and enforces the defined policy, ideally blocking all scripts except those explicitly marked as trusted.

If you're talking about older mechanisms like the X-XSS-Protection header which enabled filters like the XSS Auditor in Chrome, then those never worked reliably, even created new XSS vulnerabilities and have therefore been disabled. It's quite possible that they can be bypassed.

Improve this answer
6
  • Thanks for the answer. Yes, I meant something like an XSS Auditor- a popup that warns a user of an XSSed site. That makes sense that these could be bypassed- but couldn’t one perform phishing/ social engineering out of this since something like a popup could convince a user to do something on their own accord?
    – Hman66
    Commented Aug 3 at 9:20
  • 1
    @security_paranoid: What do you mean? What could a popup make a victim do? In Chrome, the XSS warning also wasn't really a popup but a full page error message that couldn't be closed.
    – Ja1024
    Commented Aug 3 at 15:50
  • What I am trying to clarify is, if the Auditor or such is bypassed, and the XSSed link is accessed, but CSP is also enabled, could there be any danger still? Could locally run HTML snippets etc. get allowed seeing as they could only be used for phishing/ social engineering?
    – Hman66
    Commented Aug 3 at 23:48
  • 1
    CSP doesn’t stop JavaScript-less HTML injections. So if the application displays a message based on URL parameters, then an attacker can certainly try to abuse this for social engineering. Note that the XSS Auditor and similar filters no longer exist, which means there’s no need for bypassing them with special URLs. CSP also cannot completely prevent vulnerabilities within the legitimate JavaScript of the application. It does block inherently insecure features like eval by default. But if the application code, say, exposes sensitive data based on URL parameters, this is still exploitable.
    – Ja1024
    Commented Aug 4 at 4:25
  • 1
    There are generally no magical fixes to security vulnerabilities. The different XSS filters turned out to be counterproductive and have therefore been removed. In contrast, CSP is an extremely useful defense-in-depth feature which can stop many attacks, but it’s still the job of the individual programmers to write secure code.
    – Ja1024
    Commented Aug 4 at 4:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .