When performing web security assessments, it’s easy for us to feel confident in what we see. Take Cross-Site Scripting (XSS) for instance. Your scanner finds this web vulnerability. You validate that it does indeed exist. What more is there to do? Well, it depends on how much pushback your get from your network admins or developers. They may know the rest of the story that you’re not privy to. Let me share a situation with you to explain why this matters.
I recently came across a XSS flaw on a client’s in-house web server that happened to be associated with their front-end marketing site. I validated the XSS finding and documented it the final report. It was as clear as day that this web vulnerability was exploitable on the page. The HTTP responses showed it. I could even manually enter the script code directly into a URL string and watch the pop-up window in the browser.
I got push-back on the finding because supposedly the vulnerable page did not exist on the server in question. But it did! At least it appeared that way from the outside. I loaded up a proxy to confirm which site the specific page request was going to. Sure enough, the call was to the back-end web server where I thought it was. There no reference whatsoever to the marketing site.
I told my client that unless there is some type of weird proxying or load balancing going on behind the scenes, I didn’t know what else to check for from my perspective without being on the actual server itself to see what’s taking place. This whole situation was perplexing to all of us.
Guess what the problem was? It was an error in the external DNS setup for the web servers. When trying to access the server page where I found XSS, their external DNS could not resolve the subdomain name. The request was passed on to a catch-all entry that ended up re-directing to the front-end marketing site. The fact that no URL rewriting was taking place is the variable that created the confusion. From the outside you couldn’t tell the difference between requests sent to the back-end server and ones that were redirected to the marketing site.
One quick DNS tweak and suddenly HTTP 404s were being returned when trying to access the suspected vulnerable page. Problem solved. Good – and interesting – lesson that not all web vulnerabilities are what they appear to be. When in doubt or when you get pushback, dig in deeper. The answer’s in there somewhere.
Join the Acunetix community and stay up to date with the latest web security news by liking the Acunetix Facebook Page. Also, follow us on Twitter and read the Acunetix Blog.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
