Search code examples
encodingxssclient-side-validationclient-side-scripting

How can the client side encoding be bypassed in XSS


I hear everyone saying Output encoding has to be done client-side instead of server-side. My question is: doesnt it vary with context?

  1. Are there cases where client-side output encoding is good enough and cant be bypassed?
  2. If I use a client side js function like encodeURIComponent to encode a url causing XSS, how can an attacker bypass this and still cause XSS?
  3. Phishing can also happen due to XSS. If I at least do output encoding can phishing be prevented?

Solution

  • The short answer is that XSS encoding needs to happen where data is put into html or javascript be it server-sider and/or client-side. I could easily imagine data put into a script tag on the server side begin properly encoded, but then javascript on the client-side is using that value in an insecure way, creating an XSS vulnerability.

    So when putting untrusted data into a web page (be it in a html tag, inside -tags, in css. etc - see the OWASP XSS prevention cheat sheet) we need to encode. Then when we come to the client side, we also need to make sure our javascript does not introduce XSS-problems. This could for instance be DOM-based XSS, or the example mentioned above.

    So my answer is, you need to do encoding both on the server AND client side.

    I don't understand how the 3rd question is related. Phishing could happen in so many different ways. On a completely different domain just mimicking the original page etc.

    Edit: One more thing. If utrusted data is put into the page server side without encoding, there is very little the client side can do to fix that. It's most likely already to late.