Given a flow of information (for example from the URL) into a sink on a certain site, and given that this information is plain, i.e. is not sanitized, does this mean that if an attacker could control the information flow, this will ALWAYS give the attacker an exploit? Or does the exploitability rather depend on the situation?

If the latter is true, could you give me an example of a sink, where the provided modified information would not lead to an exploit?

  • If I can hold lock picks and walk up to a door, does that mean that I can ALWAYS pick the lock? Uh, no. First, there must be a lock to pick, and it must be a pickable lock. And you want an example where modification does not lead to an exploit? Sure. I modify the information to be the string "6".
    – schroeder
    May 10 '21 at 15:34
  • A good Content Security Policy could prevent an XSS vulnerability from being exploitable in a modern browser.
    – nobody
    May 11 '21 at 1:25

If the sink is in a renderable or executable context (HTTP headers, HTML, CSS, JS, SVG, etc.), then yes, an unsanitized and unrestricted flow is always dangerous. Not all of them will directly lead to script execution - it's not possible to have scripts in (modern) CSS, and they're ignored in SVGs that are rendered inside img tags - but they still allow a malicious third party to control content on your page (which could lead to anything from tricking the user into unsafe actions to simply upsetting them with vulgar content that harms your site's reputation).

Note that some sources may only allow restricted inputs, which will need to be decoded/unescaped to allow full character sets. For example, most parts of a URL can't contain characters such as quotation marks in modern browsers (the browser will automatically URL-encode them before sending to the server), and no part of a URL can contain a newline. However, many server frameworks automatically URL-decode parsed URLs - after all, the developer probably doesn't want to receive URL-encoded characters when doing things like putting them in the DB or executing a search - and in that case there's no limit on what can go in a URL. Other sources may have similar restrictions and bypasses.

Note also that, for attacks either against the server (SQL injection, XML attacks, uploaded file path traversal, etc.) or that use the server to store malicious content for use later against users (stored XSS, malicious file uploads, etc.), the attacker is not limited to what a browser will send. The attacker can instead craft custom requests using tools like curl or even ncat/socat, and those requests will be sent verbatim with no restrictions. In other words, you shouldn't rely on things like "modern browsers automatically escape characters in the URL".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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