Best way to block URIs for %00 ?

nullchar

[ercancelik]

Hi,

Similar question was asked before here -> [webmasterworld.com...]
But the solutions provided doesn't work for blocking the requests that contains %00(null char) in the URL.

Any idea/solution?

[phranque]

welcome to WebmasterWorld, ercancelik! [webmasterworld.com]

what have you tried so far and what results did you get?

[keyplyr]

Is the %00 in the requested URL or the referral URL?

[ercancelik]

This issue is reported from our security team.

Actually i tried the below solution but the url not matched with the rule.

RewriteCond %{THE_REQUEST} \%(25)*00
RewriteRule .* - [F]

@keyplyr, the %00 is in the requested URL.

[phranque]

Where do you see %00 in the requested URL? The server access log file?

[ercancelik]

The %00 char is in the requested url. The security team is checking the server for vulnerabilities and find out that our system is not secured against the requests that contains %00 char in the request uri. The interesting thing is that Chrome browser do not take any action when i call the url(probably when it sees the %00 char in the url, interprets it as unsecure), but Safari and Firefox requested the url.

[lucy24]

\%(25)*00

Tangentially: the \ escape isn't needed, though it isn't actively harmful. I understand the point of (25)* -- in fact I've got the same construct, not in access rules but in my log-wrangling functions, since % = %25 -- but it isn't really needed in this context.

The reason everyone is asking about request vs. referer is that the referer remains percent-encoded, but the request is disencoded (er... decoded?) before it reaches your RewriteRules. So you'd probably need to use the literal character. Urk. Yeah. (Can it even be done with non-displaying characters? In other contexts, like text editing or major programming languages, there are ways to find characters by codepoint. I don't think Apache supports these locutions, though.)

How did your security folks find the character?

[keyplyr]

@keyplyr, the %00 is in the requested URL

If you have no inhouse links that contain "00" then the simplest (though not the most efficient) way of blocking is:

RewriteRule 00 - [F]

[phranque]

RewriteRule 00 - [F]

this would work if mod_rewrite sees the encoded version of the url and if the %00 is in the path part of the url.
if the %00 is in the query string you must examine %{THE_REQUEST}.

[phranque]

Where do you see %00 in the requested URL? The server access log file?

How did your security folks find the character?

essentially the same question...

[keyplyr]

this would work if mod_rewrite sees the encoded version of the url and if the %00 is in the path part of the url

the %00 is in the requested URL

Just did a quick test. Works perfect. I have no inhouse link paths that contain "00" though, ercancelik might.

Oh, and BTW ercancelik welcome to WebmasterWorld [webmasterworld.com]

[phranque]

Just did a quick test. Works perfect.

as i mentioned above, your ruleset won't blocks requests if the %00 is in the query string part of the url (i.e. after the "?")

[keyplyr]

phranque - ercancelik said it was in the URL.

@keyplyr, the %00 is in the requested URL

Yes, I agree with your query string comment, but that's not what ercancelik said. Of course he/she could be wrong.

[ercancelik]

Thank for all the replies. A sample url is below. I couldn't give the domain name for company's security rules.

<protocol>://<domain_name>/<context_path>this%20page%20has%20moved.%20Please%20call%20Ercan%20Celik%2005323524243%00

00 character could be exist in the requested url because a product page's url is like this .../products/12300232. The last part is an id of a product sometimes. So i must check exactly %00 char.

[phranque]

I agree with your query string comment, but that's not what ercancelik said.

the query string is not part of the path but it is part of the url so i'm not sure what you are saying.
so far ercan hasn't ruled out a possible query string situation, which would require examining %{THE_REQUEST}.

[phranque]

Actually i tried the below solution but the url not matched with the rule.

RewriteCond %{THE_REQUEST} \%(25)*00
RewriteRule .* - [F]

please try this instead:

RewriteCond %{THE_REQUEST} \x00
RewriteRule .* - [F]

[lucy24]

please try this instead:

Does this work on your server? I experimented on my test site and it didn't seem to know what to do with the \x construction in a RewriteCond--although, unlike the \o or \u or \octal constructions, it didn't result in a 500 error, so I guess that's something.

Intriguing detail:

#1 Error logs use the forms \xc3\xa0 (lower case, unicode) while access logs use %C3%A0 (upper-case, percent).
#2 The existence of a RewriteCond referring to \xblahblah causes the server to be unable to find the 404 document (it looks in the server default location, not in the location specified by site's htaccess)--as if it can't read htaccess, but normally that would result in a 500 condition.

Huh.

[phranque]

I didn't experiment - I suggested trying \x00 because it is PCRE syntax.

[ercancelik]

Hi Guys,

Sorry for the late response. The problem still continues. I couldn't find a rewrite rule to solve this issue.

Here is the access logs of apache httpd. Any suggestion?

xx.xx.79.10 xx.xx.199.56 - - [26/Jul/2017:10:09:11 +0200] "GET /home%2fsfsdfsfsfsfsdfsdfsdfd%00 HTTP/1.1" 404 235 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0"

[keyplyr]

ercancelik - You never have any control over what is requested. People and bots request all sorts of odd looking strings.

Not sure why your "security team" alerted you, but I'd just ignore those requests. Judging from your example, this is *not* a security issue.

If you (yourself) watch your raw server logs on an hourly/daily basis, you'll see a great many similar requests and much more.

[lucy24]

Based on the IP and on the surrounding requests, is that a human or a robot? If it's a robot, just ignore it. Admittedly it's a tiny bit of extra work for your server to have to go look for a nonexistent file, but in the end a 404 is probably the most useful thing to send an unwanted robot anyway.

You may also want to look at what other requests are coming in from this IP, assuming it's the same one over and over. If there are no humans in the neighborhood, you may be better off blocking the whole range.

:: detour to test site ::

Hm, now that's interesting. In the case of a displayable ASCII character, access logs will show whatever form I actually typed in, like /4.html vs. %34.html, while error logs and the browser's address bar show the decoded form (4 in this example). If, on the other hand, you request a displayable non-ASCII character, access logs will always show the encoded form. And, finally: if I manually type in \x Firefox will convert the \ to / (possibly in response to all those stupid TV ads that say "backslash" when they mean "slash" leading to slews of erroneous type-ins). Safari does approximately the same, with added business.