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).

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.

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).

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:(

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

a lot of browsers have the same user agent string as well. The only two ways, that i know of, to uniquely identify a particular individual is through a cookie or a query string parameter on every click.

Useful XSS cheatsheet:

http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr...

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

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!

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.

I would not recommend showing a user's password for security reasons. If you do show it thought, then using xss_clean would probably complicate things as it probably removes or escapes some special chars like <, > and &.