Detect RCE in fragments of URLs in Referer header (932205) #3498
Comments
|
Thank you for creating this issue. I think this is exactly to the point. |
|
I think creating a new rule with |
|
Yes please! |
|
The rule 932205 never gets triggered, as it's basically rule 932206 in the chain, and rule 932206 gets triggered instead, as we are targeting the uri in referrer header. Is there any way we can log 932205, or is this expected behavior? |
|
Hey @theseion , can you provide some resources showing an exploit for RCE in URL fragments, need some info for tests. |
|
There's a remark in the comment to 932205 about "Scroll to text fragment". That comment is actually obsolete rule. It was part of an FP fix (cf0bb6e). We had added that when the rule was still targeting all referrer values, including fragments. Since the rule now exclude fragments, that fix was no longer necessary. Of course it would make sense for a new rule. I can't give you any references, but the same exploits that are possible in other places of the Note that there are three variants of fragments: id, text, and media (https://developer.mozilla.org/en-US/docs/Web/URI/Fragment). If you look at the RFC you'll notice that the allowed characters consist of percent encoding, ASCII, and a couple of special symbols like HTH. |
According to the URL specification, the
Refererheader must not contain URL fragments (the part of the URL beginning with#). However, in practice many clients will simply copy the current URL into theRefererheader. Since web servers have to allow fragments in theRefererheader, this opens the door to attacks in the fragment part (we already detect attacks in the path and query parts of URLs in theRefererheader).We should add a new rule that targets the fragment part or URLs in the
Refererheader only and applies RCE detection as 932205 does to path and query.See also the discussion in #3485.
The text was updated successfully, but these errors were encountered: