Joe Rosa ::   Blog | Network | | Aggregator | Profile | Page

• View all Friends

#391: XSS in File Upload

A user can upload an HTML file containing JavaScript. When another user downloads the file, the script is run as if the script comes from the same domain, an XSS vulnerability.

Patch included simply sets content disposition to attachment for all files that are not images instead of just files with application/octet-stream MIME types, as done in Elgg 1.0.

#390: Prevent uploading files with dot prefix (e.g.: .htaccess)

By default, elgg 0.9.x ships data directory within root directory accessbile by web, mailicious users can upload a .htaccess file and disable rewrite engine in his files (data/files/u/username/)

#389: TAGs lost when admin edits others blogs

When the administrator edits others Blogs the TAGs are not retrieved as it uses sessionid, but a simple identification of the $page_owner tells display_input_field to use that as the $page_owner.

Patch attached

#388: User can manipulate populartags -

In 'populartags' code selects TAGs using the 'ident' field that is a sequential code generated each time we 'add' or 'edit' a Blog post. However editing an old blog post it generates a new 'ident' without changing its position in the cue for the MySql? query that uses the record ID, and consequently brings it that TAG to the latest blogs.

This allows an user to manipulate the TAG cloud pointing to his/her personal blogs. (We had that case - people are creative)

Changing the field 'ident' to 'ref' and using the clause MAX() in the MySQL query as well as the constraint tagtype='weblog' made an effective solution.

Patch attached

#387: Invitation and password reset code collision

Elgg currently uses a rather simple algorithm for calculating the invitation code used to identify a new user. It uses the first 8 characters of an MD5 hash of the name of a new user and the current time. This same algorithm is used when calculating a code for a password reset.

In a heavily used system, it is very possible with the current algorithm to have two emails sent out with the same code (had that happen to me twice in the past two days!). If error reporting is disabled (hide errors), this effectively has the result that a user clicking on the link is presented with the password reset or invitation of another user!

I have chosen a very straightforward approach to fix this. Before the new code is inserted in the invitation table, the table is checked to make sure the code is unique. If it is not, we sleep() for 1 second and generate a new code. This continues until a unique code is found. This is still not 100% proof (we would need table write locking for that), but it's a lot better.