I’ve been pretty aware of the risks of SQL injection and am militant about keeping my database interactions clean. Mark Jaquith today reminded me about the need to make sure my browser output is filtered through clean_url(), sanitize_url(), and attribute_escape(). Furthermore, we all need to remember current_user_can(), check_admin_referer(), and nonces.

Via Brad Neuberg: RSnake’s XSS (Cross Site Scripting) Cheatsheet: Esp: for filter evasion.

Limitations on cross site scripting (XSS hereafter) have been troubling me as I try to write enhancements to our library catalog, but the reasons for the prohibition are sound. Without them I could snort your browser cookies (RSnake lists: “cookie/credential stealing/replay/session riding” among the threats, but a well-planned attack could also fetch resources from internal webservers and deliver them to external data thieves).
It turns out you can insert JavaScript in <img> tags (among many, many others) and obfuscate it with Unicode, hex, and other less-readable encodings or by inserting tab characters (“&#x09;”) or newlines (“&#x0A;”). It would be impossible for me to list every possible attack vector, but RSnake takes a good stab at it.

If you allow users to insert HTML in comments, you should be aware of this….

tags: browser threats, cheatsheet, cross site javascript, cross site scripting, filter evasion, internet threats, javascript, scripting, threat, threats, web, web browser, xss