Add filter_xss() functionality to drupal.js

I tested it out:
document.write(Drupal.filterXSS('<script>alert("xss!");'));
and this came out:

alert("xss!");

Looks good, and very useful IMHO.

Robin

This patch is committed :

#197425: Usability: enable BLOCKQUOTE by default

Doesn't seem to be working properly. I tried this:
document.write(Drupal.filterXSS("<strong> <script>alert('xss');</scr"+"ipt> foo </strong>"));
It wrongly removed the <strong>, and failed to remove the <script>.

Need pass this tests : http://ha.ckers.org/xss.html

@stella : you can test all in one ...

I can imagine why this might be useful, but it's a fair bit of code and we won't be using it yet in core.

Can you expand a bit on the use cases? Why is this needed? When is checkPlain not appropriate? How widespread is the need? (Without I guess naming specific modules that should be doing this but aren't ;)).

@stella - these modules (why should they remain nameless?) take untrusted input and show them to different users? I doubt it, because then you could have run filter_xss() on the server side. I don't yet see the point in filtering a user's own input when shown to self?

hmm... couldn't you do this using an AJAX request where ANY input format could be invoked?

filter_xss() is pretty limited because it allows only whitelisting HTML elements, and then it blindly allows any attributes in them, except on* and style, but you can still pass class or id, which can cause harm to the page layout, or otherwise unexpeted results. So, there maybe someone that needs a different kind of filter such as HTML Purifier, htmlLawed, WYSIWYG Filter, etc.

PS: when porting filter_xss(), please take this issue into account.

failure was due to HEAD not installing properly

I think Markus has a valid point here:
why not implement it through an AJAX request and use the same functionality as on the server side?
This would provide the same results without duplicating any code.

Not bad, but it won't be that easy :) Should be simpler and cleaner using AJAX, but if you want it that way, here are some thoughts.

Firstly, it eats my tags:

Drupal.filterXSS('<em>uuu</em>');
Drupal.filterXSS('<em>uuu</em>', new Array('em'));

both give just: uuu</em>. (Seems it only likes first tags: "a<em>b</em>c<em>d</em>" gives "ab</em>c<em>d</em>".)

Secondly, the "for (var character in replace) ..." loop is risky. According to par. 12.2, ECMA-357, order of properties is implementation dependent. Not sure if any implementation would really reorder that, but, if so, this would at least cause removing of Netscape 4.x JS entites ineffective.

Thirdly, entity decoding doesn't seem to take numerical character entities into account, so:

Drupal.filterXSS('<img src="jav&&#x23;x0D;ascript:alert(0)" />', new Array('img'));

should work in IE6 (that is x0D before or inside a protocol). This is unconfirmed, because it eats my tags ;)

While trying to verify the above I've hit something like this:

Drupal.filterXSS('<img><img src="javascript:alert(0);" /><img src="" /><img src="" /><img src=""  />asdf', new Array('img'));

which surprisingly does work (IE6, a script in an article using document.write). Not sure why. :)

Is there anywhere in core that would benefit from this?

Being a GET request, it may fail depending on the size of the string to parse -vs- server configuration and/or hardcoded limitations.

See for example: http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline

Depending on the purpose of this API, it might be interesting to use filter_xss_admin() or check_markup(). For passing arguments, maybe using Drupal.settings?

In regards to synchronous/asynchronous dilema... if it was asynchronous, it could accept a callback which would be used to process the response, which probably be used to alter the DOM in some way, I guess. :)

While using synchronous XMLHttpRequests (the A in AJAX means asynchronous, so this can no longer be named ‘AJAX’) facilitates the implementation of this function, it comes at a high cost: When the server or the user’s connection is slow, such a request COMPLETELY BLOCKS the browser. The user can’t do any action on the site and has to wait until the request finishes.

I don't think such a function is really necessary in client-side JavaScript. The reason for filtering text for XSS is that an attacker might foist code to another user, stealing their session or performing other malicious actions like forging requests. However, when the user enters text which is subsequently injected into the very same page, the user could only harm themselves. When the input is stored on the server, it has to be filtered anyway *on the server* before it is sent back to the user (or another user).

Drupal.checkPlain() is mainly used for being able to display literally what the user entered and less for security purposes.

See #586098: Add a core Drupal.checkMarkup() function like check_markup() which could be more useful for input filtering.

No longer possible to do for D7.

js_filter_xss.patch queued for re-testing.

First it needs a reroll,
Second it needs to not use async: false, just like the checkMarkup issue.

Well no, you have to wait for the callback to insert your sanitized content. You can't just use procedural code in JS, it doesn't work that way.

I've experimented with implementing this purely in Javascript, without an AJAX call back to Drupal. You can see my code here:

http://jsfiddle.net/dsnopek/ygwyaw18/

It seems to work, but without a TON more review and testing, I can't really say there isn't a browser/configuration/trick to get around it.

With CKEditor we have something similar because of the same security concerns. If we want that it should be looked into. It's using an async ajax call.

The use case outline in #12 is a bit thing to add that sort of functionality especially when the kind of people doing that nowdays are probably using react, angular or whatever is popular in 2 weeks.