False positives in map $http_user_agent if regex does not use word boundaries.

[mitchellkrogza@…]

This is not really a bug, merely something to point out to people who may be using

map $http_user_agent

If the regex pattern is not escaped by word boundaries it leads to false positives.

For example:

map $http_user_agent $bad_bot {
"~*Disco"		1;
}

Anything starting with Disco is detected, so an innocent user-agent like Discourse is detected as a positive hit.

But adding word boundaries like this prevents the false positive match.

map $http_user_agent $bad_bot {
   "~*\bDisco\b"		1;
}

The same occurs with

map $http_referer

If dots in referrer domains are not escaped it leads to false positives.

Example:

map $http_referer $bad_referer {
"~*ico.re" 1;
}

Will detect ico.re and also locatellicorretor.com

So dots and special characters need to be escaped

map $http_referer $bad_referer {
"~*ico\.re" 1;
}

[Maxim Dounin]

Replying to mitchellkrogza@…:

For example:

map $http_user_agent $bad_bot {
"~*Disco"		1;
}

Anything starting with Disco is detected, so an innocent user-agent like Discourse is detected as a positive hit.

Not really. Anything containing Disco is detected, including something like undiscoverable or superdiscount.

These are regular expression basics tough, and I don't think there is a room for such basic things even in introductory articles like ​How nginx processes a request (it provides some examples of properly escaped regular expressions though, as well as some other places in the documentation).

Note well that any such checks, even properly escaped, are subject to false positives. For example, an unrelated user agent may mention Disco word for some reason. Or a referer may include ico.re string somewhere in the path, like in http://example.com/favico.reference.html. It is generally a good idea to think twice before applying any restrictions based on such checks.