Martin Zvarík wrote:
Jan G.B. napsal(a):
2009/3/15 Martin Zvarík <>:
"The browser will only execute script in source files from the white-listed domains and will disregard everything else, including embedded and inline
scripts. "

wtf, can't you just take care of the INPUT and type
strip_tags($_GET['my_name']) ??

This won't be implemented in any browser, can't be.

strip_tags() isn't good. it only removes correct markup, IIRC. for
example "<b >>foo>" wouldn't be interpreted as a valid tag.
Often XSS attackers split their scripts to bypass such filters, common
regex patterns and alike. bypassing strip_tags() is easy.
the bad thing: browsers tend to accept a lot of mad markup.
take a look at this:


Forget to mention htmlspecialchars(), that should take care of everything.

Back from my weekend away.

Yes, good input filtering should make this kind of thing never trigger.

However, stuff gets passed input filters all the time, especially when the webmaster is being somewhat lenient and allowing some markup - an often requested feature by users.

You have to establish some kind of policy for what is allowed and what isn't allowed.

Once that policy is established, web app security is the most important line of defense (IE sql injection, good password hash with salt, never passing the session ID over http except when setting a session cookie, etc.) - if someone can own your server they can do whatever they want with it.

Second most important line of defense is input filtering.

However, when input filtering fails (and input filtering fails all the time on many commonly used web applications) - output filtering, such as what I'm trying to write, can catch many XSS attacks before they get sent to the users.

The browser then provides a final line of defense - but the webmaster really has zero control over what browser a user decides to use, so output filtering is as far as a webmaster can take things.

By defining a policy and then putting that policy into CSP rules, a web master offers some additional protection against flaws in input filtering. Furthermore, the web master can be notified when output had to be filtered to be compliant with the defined policy, alerting the web master to the presence of a bug in the input filter.

If you don't see the point in this, fine.

Have fun meticulously going over every line of code of every third party application you install on your server so that you can be positive there are zero holes in their input filters. Personally, I'd rather be able to add a filter class to those apps that has a good chance of catching what my eyes don't catch, and that's why I'm writing this class.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to