4 ms·

URL parsing is a mess. The specification is poorly defined, and different libraries and/or servers handle them differently. This is one kind of attack; many SSR

URL parsing is a mess. The specification is poorly defined, and different libraries and/or servers handle them differently. This is one kind of attack; many SSRFs exist which leverage that weakness. The regex approach, btw, is even worse. Parse your URLs before doing things with them.

wahern 7y ago
IMO the spec is well defined and simple. What's broken are the browsers. Permitting a backslash as a delimiter rather obviously breaks the syntax. No surprise that security issues are introduced when the browsers don't follow an otherwise simple standard, while everybody else does. That's what makes this crazy. Generally I agree that people shouldn't abuse regular expressions for parsing security-critical data. But it just so happens that a standards-compliant URL can be trivially parsed using a naive regular expression that relies on the semantics of the gen-delimiters character set in the standard. In fact, it's really hard to break such a naive regular expression even when we move beyond the domain of standards compliance. One glaring exception is anything that introduces ambiguity between the userinfo authority section and the path, which the browsers have chosen to do. sigh A new RFC should be issued that updates the syntax to include the semantics which browsers give to backslash. Among other things, this will help to publicize the issue.
- rndgermandude 7y ago
  The browsers are implementing the WhatWG URL spec, not the RFC, and it mentions \ is valid for "special" URLs (scheme is http/https, ftp, file, ws/wss): https://url.spec.whatwg.org/#hostname-state https://url.spec.whatwg.org/#hostname-state
  - robocat 7y ago
    There’s some comedy in that URL standard: Calculating file origin: "Unfortunate as it is, this is left as an exercise to the reader.” 3.7. Host equivalence: “To determine whether a host A equals B, return true if A is B, and false otherwise.” “The application/x-www-form-urlencoded format is in many ways an aberrant monstrosity”

wahern 7y ago

IMO the spec is well defined and simple. What's broken are the browsers. Permitting a backslash as a delimiter rather obviously breaks the syntax. No surprise that security issues are introduced when the browsers don't follow an otherwise simple standard, while everybody else does. That's what makes this crazy. Generally I agree that people shouldn't abuse regular expressions for parsing security-critical data. But it just so happens that a standards-compliant URL can be trivially parsed using a naive regular expression that relies on the semantics of the gen-delimiters character set in the standard. In fact, it's really hard to break such a naive regular expression even when we move beyond the domain of standards compliance. One glaring exception is anything that introduces ambiguity between the userinfo authority section and the path, which the browsers have chosen to do. sigh A new RFC should be issued that updates the syntax to include the semantics which browsers give to backslash. Among other things, this will help to publicize the issue.

rndgermandude 7y ago
The browsers are implementing the WhatWG URL spec, not the RFC, and it mentions \ is valid for "special" URLs (scheme is http/https, ftp, file, ws/wss): https://url.spec.whatwg.org/#hostname-state https://url.spec.whatwg.org/#hostname-state
- robocat 7y ago
  There’s some comedy in that URL standard: Calculating file origin: "Unfortunate as it is, this is left as an exercise to the reader.” 3.7. Host equivalence: “To determine whether a host A equals B, return true if A is B, and false otherwise.” “The application/x-www-form-urlencoded format is in many ways an aberrant monstrosity”