id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	difficulty
3553	create list of best practices for preventing XSS vulnerabilities	cash		"Elgg does a pretty good job with user submitted content that ends up in the database judging by reports and what I've seen in code.

Elgg has had a few problems with GET parameters that are used in page generation (think a search query) and has ignored parameters used in a URL section used in the same way. For example, I send Evan a link in the email:

Evan, check out the new plugin uploaded by Brett: http://community.elgg.org/pg/plugins/brettp/#hack

The #hack there is my stand in for a XSS attack. Let's say it rewrites the url for the download to point to a trojan horse.

The issue is that we often take a URL section and use it in a menu or use a GET parameter in a heading. The GET parameter should be going through the XSS filter so no really bad stuff should affect us there - just CSS modifications and image inserts. The use of URL segments are not going through get_input() (bad news).

Best practices:
 * any user input gets filtered and that includes url segments that are used in menu items or passed to page handler scripts
 * if we know we are looking for an int, it should be cast as an int
 * always grab variables and filter/cast at top of function/script
 * consider using dirty/clean variable names
 * consider using the action token in the ajax/view page handler

Additional functions: 
 * add a function that parallels current get_input() but instead of putting stuff through htmlawed, it casts it to an int and returns. Better that sprinkling (int) throughout the code.
 * Besides passing GUIDs in URLs, we often pass usernames. Check if there is a function that we can use to filter or validate those before passing them on."	Task	new	normal	Documentation	Documentation	1.7	minor			brett@…