Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too broad regex replacement #61

Open
jplitza opened this issue Jan 4, 2022 · 0 comments · May be fixed by #62
Open

Too broad regex replacement #61

jplitza opened this issue Jan 4, 2022 · 0 comments · May be fixed by #62

Comments

@jplitza
Copy link

jplitza commented Jan 4, 2022

Consider the following slightly modified access log line from the first regex test:

3.3.3.3 - - [20/May/2015:21:05:01 +0000] "GET /723.3.3.357 HTTP/1.1" 200 13358 "-" "useragent"

The requested URI could be an OID from an SNMP MIB or something like that.

The current implementation would replace the 3.3.3.3 in that URI, even though it has nothing to do with the client IP address and isn't, in fact, an IP address at all:

3.3.0.0 - - [20/May/2015:21:05:01 +0000] "GET /723.3.0.057 HTTP/1.1" 200 13358 "-" "useragent"'

Note that this depends on the real client address being contained in the URI. The following line

2.2.2.2 - - [20/May/2015:21:05:01 +0000] "GET /723.3.3.357 HTTP/1.1" 200 13358 "-" "useragent"

doesn't modify the URI:

2.2.0.0 - - [20/May/2015:21:05:01 +0000] "GET /723.3.3.357 HTTP/1.1" 200 13358 "-" "useragent"

Hence this could even reveal the real client IP address if only 723.3.3.357 makes sense in that place, and 723.3.0.057 doesn't.

I'll open a PR in a minute that - among other things - addresses this problem by only replacing the groups where they actually matched and modifies the first test case to highlight this problem.

@jplitza jplitza linked a pull request Jan 4, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant