check_xi_deface ARG option getting incorrect escaping

[eloyd]

We're monitoring changes on a vendor's firmware page. Decided to use the web page defacing wizard in XI to do it. Running into a problem with parameters as part of the URL getting escaped automatically and therefore, being incorrect. Sample:

Code: Select all

check_command: check_xi_deface
host is vendor's web server
ARG1 is "v1.2.3latest" (proper string to look for to see what's the latest firmware listed)
ARG2 is something like "/download/release.html?mdfid=12345&flowid=67890&softwareid=24680" without the quotes
ARG3 is "-f follow" without the quotes

Comes back with an error, since it does not properly pass the full ARG2. When we change host to something we control, so we can see web logs, we get this in our web server log:

Code: Select all

GET /download/release.html\\?mdfid=12345
/code]
Note that the ? is doubly escaped with two backslashes and any arguments after (and including) the first & were just dropped.  Putting quotes around it just add quotes to the URL.  This is not the fault of the check_command definition as this is stock XI with nothing weird in commands.cfg for this command.

Running
[code]
/usr/local/libexec/check_http -H <host> -r "v1.2.3latest" -u "/download/release.html?mdfid=12345&flowid=67890&softwareid=24680" -f follow

from command line works fine. So why is this input field apparently being converted inside the deface wizard in XI?

[eloyd]

Turns out that there is a lot of improper argument handling in ARG values that include URLs. I'm guessing that this is a input sanitizing mechanism at play here somehow, but it's making it impossible to do what I want with XI.

Ended up running this service check on one of our Core boxes and it works just fine.

[tmcdonald]

Cross-referencing for visibility, but does it look like the problem Willem is facing? https://support.nagios.com/forum/viewto ... 91#p179791

Seems pretty similar to me.

[eloyd]

Will have to read later, but at first glance, it is possible.

[ssax]

Try running your $ARG2$ through this and see if it works that way:

http://meyerweb.com/eric/tools/dencoder/

[eloyd]

My ARG2 looks exactly like the ARG2 in my example, except that the numbers were changed to protect the innocent. It is a straightforward URI (minus protocol and host) with a single question mark and two ampersands. It should not need to be encoded or decoded, it is being truncated.

As Trevor said (https://support.nagios.com/forum/viewto ... 10#p179858) these two problems are linked. However, I think it has to do with illegal characters, since the "&" and everything after it is truncated, but the "?" ends up being double-slash escaped.

Mind you - this is all while doing this in XI GUI. If I drop the same thing into a Core services.cfg file and skip the GUI, check-http works like a champ with no truncating or weird escaping.

This leads me to believe the problem is with whatever input validator is being called for parsing input in the ARG fields of XI.

[tmcdonald]

Turns out that there is a lot of improper argument handling in ARG values that include URLs. I'm guessing that this is a input sanitizing mechanism at play here somehow, but it's making it impossible to do what I want with XI.

Ended up running this service check on one of our Core boxes and it works just fine. :)

Mind you - this is all while doing this in XI GUI. If I drop the same thing into a Core services.cfg file and skip the GUI, check-http works like a champ with no truncating or weird escaping.

Can you provide a side-by-side of what you save in XI vs what ends up in Core configs? I want to see exactly what is going on with your example.

[eloyd]

Yah, I could, but I'm busy right now. I just ended up writing a check on one of our Core servers, since I know it won't parse anything special. I'll see if I can get back to this example on Monday, since I wouldn't want to put anything into your system before you leave on a Friday.

[eloyd]

ARG. It's no longer failing to work properly. Close my thread. The problem is either something else or it's related to illegal characters configuration and I'll fix it.

[tmcdonald]

Regarding Willem, I think his is a semi-colon that didn't get escaped and caused Core to comment out the rest. Gonna look into yours more when you get back.

I wouldn't want to put anything into your system before you leave on a Friday. :-)

Update:

Close my thread. The problem is either something else or it's related to illegal characters configuration and I'll fix it.

You got it, can always re-open if needed. Just PM me.