3 ms·
How to prevent XSS attacks
- utsmokingaces 18y agoDoes 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!
- amix 18y agoI 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 &.
- troels 18y agoYou 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.
- Steve0 18y agoThe hole in twitter was really big, surprised it took that long to exploit.
- abcphp_com 18y agomore interesting links can be about XSS found here http://www.abcphp.com/search.php?search=xss http://www.abcphp.com/search.php?search=xss
- kierank 18y agoUseful XSS cheatsheet: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr...
- bsaunder 18y agoHas 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 18y agophpbb 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 18y agoYou 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 18y agoIf 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 18y agoYou're right - I weren't thinking that through really.
- pj 18y agoa 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.