

How to prevent XSS attacks - amix
http://amix.dk/blog/viewEntry/19432

======
bsaunder
Has anyone tried tying a session to the client's IP address? Seems like this
might make the session cookie harder to use externally (could still use XSS to
perform all the attacks from the browser though).

~~~
decode
phpbb used to do this, but I don't think it does anymore. The problem is that
some users have ISPs that transparently route their web access through
rotating HTTP proxies, all with different IP addresses. So, each click has the
potential for sending the user through a different IP, and invalidating their
session. AOL was infamous for this practice. You can imagine this might also
happen closer to the client, say within a corporate network.

~~~
troels
You can still tie the session to other properties that won't change, such as
the user-agent string. I'm not sure how widespread this practise is, but I
don't see any pitfalls in it (Except of course that it isn't guaranteed to
catch the hijacking).

~~~
modoc
If they're able to sniff/steal your cookie they can easily capture any other
request headers. This wouldn't be the case for brute forcing cookie values,
but hopefully your cookie is secure enough to make that a non-issue.

AOL, and a few others, unfortunately still break the "IP for session security"
thing:(

~~~
troels
You're right - I weren't thinking that through really.

------
kierank
Useful XSS cheatsheet:

[http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr...](http://www.owasp.org/index.php/XSS_\(Cross_Site_Scripting\)_Prevention_Cheat_Sheet)

------
Steve0
The hole in twitter was really big, surprised it took that long to exploit.

------
utsmokingaces
Does anyone know if using a xss_clean function such as the one in PHP would be
a problem for user passwords?

Many people like to use special char for password not sure that will conflict
with xss_clean. Thanks!

~~~
troels
You would never have to filter a password. In general, you shouldn't rely on
filtering, but rather on escaping. Escaping always work, whereas filtering can
have subtle edge cases. The only place where you should resort to filtering,
is when you (for some reason) need to display input _as code_. But it's
important to stress that filtering is _less_ safe than escaping - it's not the
other way around. That's counter-intuitive, so a lot of people get it wrong.

------
abcphp_com
more interesting links can be about XSS found here
<http://www.abcphp.com/search.php?search=xss>

