Hacker News Reader

Comment by elric | Hacker News Reader

Can someone elaborate on how this is a security issue?

Commonly used in access control to check IP addresses, usernames, cookies, query params, URI paths, environment variables ... Also filtering REQUEST_METHOD to allowed verbs is good practice.

Anti-"image theft" example from Apache httpd documentation that would break with this bug:

    RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://%{HTTP_HOST}/*'"
    RewriteRule "^/images" "-" [F]

Off the top of my head, all that springs to mind is: If someone is using rewrite rules to direct users depending on cookies and other request values, it could permit access to things the current user should not see, or should need to re-auth to see.

Though this doesn't seem to be a good way of doing that anyway, certainly not on its own (perhaps as a low resource initial test it is valid, in a bloom filter sort of way it could cover some "definitely shouldn't be here" cases efficiently).

Interesting. I've never used rewrite rules conditionally, and if a rewritten request is your only defense you've probably got bigger problems.

For better or worse, mod_rewrite's flexibility meant it got used to add logic, primitive flow control and conditional behaviours. You don't actually need to rewrite a URL path. More recently, "Require expr" can do some of this.

That's what I mean by "not a good way" and "at least not on its own". It _can_ be a good optimisation to make some easy decisions quickly on the web server before pushing anything less definite to your more expensive logic processing, if well implemented. If badly implemented it leads to security holes and actually worse performance.

Typically a boolean issue like this is a cause for escalation if you use it in combination with some auth handler, like "if has session cookie then serve protected files" and since the condition always passes then it could bypass auth. For example.

Reply on news.ycombinator.com