XSS vulnerabillity in response

Question

I'm checking for reflective XSS in a website and have noticed that the website uses the concept of HTML escaping, so basically any special/invalid characters are escaped. So injecting is not that easy.

Example: ' gets converted to ' and > gets converted to >

I had two questions:

1) Is it possible to bypass this type of filter?

2) Also I have noticed that when you intercept the response after the filter has escaped the payload used, the website allows the response to be tampered. (Basically it allows the user to replace the escaped version of the payload seen in the response to the original payload, hence executing the pop-up to get hostname, cookie, domain etc.) Although I guess this is not exactly how XSS works, I am still able to get some info about the website.

Answer 1

With regards to getting XSS in this setup, where the response lands inside HTML content, as @snappie says, you'd need to find a vulnerability in the encoding to bypass this in most cases.

However there is another option, which is, your vector might land inside JavaScript or JSON content (i.e. not HTML pages) in which case HTML encoding might not be an effective defence.

I'd recommend putting a traceable string in as your vector then look at all the locations that the vector appears in , in the responses from the site.

So for example if you insert the string "LoremIpsum" into various parameters that are submitted to the site, you can use a proxy tool to search through the responses and see where those strings re-emerge (i.e. do they appear just in HTML or to they appear in other types of response)

What I tend to do is start with a vanilla string without any special characters in it, as sometimes applications will strip input containing special characters entirely. That gives a starting picture and from there you can get an idea of where your input should appear in responses once you start to fuzz looking for XSS issues.

As to your second point, if you're intecepting responses and injection JavaScript code at that point, that's what's commonly called "Self-XSS" and isn't usually considered a vulnerability in the site itself. Your modifications happen after the data has been transmitted by the site and usually this is mitigated by using SSL encrypted connections.

Answer 2

1) Is it possible to bypass this type of filter?

Only if you find flaws in the implementation of the filter, but probably not. This is the default defence against XSS. You will notice for instance that Google uses the same tactic.

2) Also I have noticed that when you intercept the response after the filter has escaped the payload used, the website allows the response to be tampered.

If you can intercept and edit the response then you can do a Man In The Middle Attack. This however has nothing to do with XSS. XSS only occurs when the website itself sends back HTML tags embedded in user supplied data. If you edit the response after the website has send it, it's not the website that 'allows' the response to be edited, it's someone else pretending that the website send something it didn't.