W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2016

A DOM sanitizer

From: Ahmed Elsobky <0xsobky@gmail.com>
Date: Fri, 16 Dec 2016 15:14:50 +0200
Message-ID: <CAMUMnOU1qGYkn0EcPmFp5OV-ndHrZVq3x7FHoCr+i3F=Umu2Rg@mail.gmail.com>
To: public-webappsec@w3.org
Hi everyone!

I have been working on a DOM sanitizer lately that defends against
client-side injection attacks. It simply utilizes taint checking to guard
against poor security practices often employed by third-party JS libraries.
You can find the project on GitHub at: https://github.com/0xsobky/XSSBuster..

A quick summary of how it functions is as follows:
    As soon as it gets executed, some checks are done against a variety of
input sources that might be potentially influenced by an outside origin
(like the `window.name` property for example). These checks are conducted
so that we sanitize dangerous HTML meta-characters such as "<", ">", etc.
    Afterwards, we add the sanitized input into an array that's dedicated
to store tainted strings. Any strings within that array are prohibited from
getting passed to security-sensitive functions like `eval` as is; we
achieve that by overriding these functions with equivalent safe functions
preserving their functionality as originally as possible. Data encoding is
also being taken care of, so double URL-encoding or base64-encoding a given
attack vector should not be an issue.
    Finally, we guard storage sources (e.g., `localStorage`,
`sessionStorage`, el al.) against storing tainted strings as is (i.e.
without sanitization or encoding), since that there are no guarantees that
a vulnerable script somewhere else within the same web application will not
do something security-unwise later like evaluating a value directly out of
the document's cookie or `localStorage`, etc.

These are some examples of the the problem I’m trying to solve (which
clearly CSP doesn’t help much with):
http://www.troyhunt.com/2015/07/how-i-got-xssd-by-my-ad-network.html
https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/
http://www.fuzzysecurity.com/tutorials/14.html
http://blog.mindedsecurity.com/2011/04/god-save-omniture-quine.html
https://hackerone.com/reports/125386#activity-888336

Any thoughts on this approach?
Received on Sunday, 18 December 2016 18:31:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:21 UTC