Question: a basic API for most common use-case? about xss-filters HOT 4 CLOSED

Now I have been using xss-filters for a day, it appears I need to do following:

1. Given the general rule filter/escape data as closed to client as possible, the sensible place to do it is in the template/render function, because only then will we know if an url is being used as attribute value, or as html data, or both in some cases.
2. Because we use virtual-dom to generate html, templates are shared between client and server, meaning we need to run xss-filters on both server-side and client-side, fortunately it can 👍
3. I don't see an easy alternative to run filters fully server-side (that is, filter data before output to JSON API for client-side rendering), I guess we can create some schema or conventions between data model and view, so that in cases mentioned above, the same url will be transformed into 2 different url, one for attribute and one for html data, and view knows which one to choose from...

That's my understanding so far, let me know if I missed anything.

from xss-filters.

Here're my thoughts:

due to usability concerns, let's make some filters not as context-sensitive as what we're exposing

First of all, this is a natural tradeoff question. We're aware of the mental burden put on developers, and thus we proposed two automated solutions at https://www.npmjs.com/package/express-secure-handlebars . In fact, this library is designed for those corner cases that can't/yet-to-be covered by the auto solutions.

possibility of reducing into perhaps only two filters, i.e., inHTMLData and inDoubleQuotedAttr

Regarding possibility of reducing filters, let's take inHTMLData() and uriInHTMLData() as examples. First, sensitive character in html data context includes <. Then, inHTMLData() is to cook it to <, while uriInHTMLData() will cook it to %3C. So, I hope you see that it's hard to come up with a universal filter. The filtering rules are not mutually exclusive.

possibility of pre-escaping at server-side

As you've perceived, in terms of security, filters must be placed as close to the output sink (call it placeholder, position if you like) as possible. So, filters should be executed during data/template binding. If the binding happens on client-side, then filter on client-side. Similarly, if it's on server-side, then filter on server-side. Pre-escape data at server-side by running through every filter like what you suggested is doable, but it's gonna have performance issues.

from xss-filters.

Got it, I think we are going to put xss-filters client-side (ie. in template) and see how it goes, as it felt most natural to me.

2 quick questions:

• Do you have a list of supported browsers (or what you are targeting to support at the moment)?
• Have you guys run into any scenario where you need to run multiple filters on a value, it would seem that there are enough API to cover every use-case?

Thx in advance.

from xss-filters.

• We aim at IE 7 or above, Firefox 30 or above, Chrome 30 or above, and Safari 5 or above. It may just work fine in older versions.
• No. One filter per value.

from xss-filters.