Original ticket http://trac.elgg.org/ticket/3553 on 41440228-07-20 by cash, assigned to unknown.

Elgg version: 1.7

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.