Martin Zvarík wrote:
Jan G.B. napsal(a):
2009/3/15 Martin Zvarík <mzvarik@xxxxxxxxx>:
"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: http://ha.ckers.org/xss.html
regards
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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
