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

Re: A DOM sanitizer

From: Jim Manico <jim.manico@owasp.org>
Date: Sun, 18 Dec 2016 11:49:02 -0800
To: Ahmed Elsobky <0xsobky@gmail.com>, public-webappsec@w3.org
Message-ID: <b335a689-ab3e-c296-f647-85fb9d637d8a@owasp.org>
Ahmed,

One of the best DOM sanitizers that I know of is
https://github.com/cure53/DOMPurify from the Cure53 team. Please check
out their unit tests to help with your efforts. This tool focuses on
taking un-trusted HTML and making it safe to render. This is something
that web standards do not address.

This is not exactly what you are up to, but perhaps their methods and
tests could aid in your effort.

Aloha, Jim


On 12/16/16 5:14 AM, Ahmed Elsobky wrote:
> 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
> <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 <http://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
> <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/
> <https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/>
> http://www.fuzzysecurity.com/tutorials/14.html
> <http://www.fuzzysecurity.com/tutorials/14.html>
> http://blog.mindedsecurity.com/2011/04/god-save-omniture-quine.html
> <http://blog.mindedsecurity.com/2011/04/god-save-omniture-quine.html>
> https://hackerone.com/reports/125386#activity-888336
> <https://hackerone.com/reports/125386#activity-888336>
>
> Any thoughts on this approach?
Received on Sunday, 18 December 2016 19:49:43 UTC

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