There’s an interesting thread on sla.ckers about how Firefox overwrites attributes. The short of it is if you have attribute=”false” followed by attribute=”true” the second attribute overwrites the first. This is definitely not the first time I’ve come across this, and if you think about it, it makes sense - one of them has to win, so it’s a tossup as to which one should. So for the most part I totally ignored that phenomena, chalking it up to potentially problematic, but difficult or impossible to exploit in any useful way. However, that was until this thread.

One thing that MySpace does, for instance, is add the attribute allowScriptAccess=”never” to any object tags, neutering their effectiveness in an attack. However, if you immediately follow it up with your own attribute allowScriptAccess=”always” it will override MySpace’s security settings (I don’t know if there is a working exploit out there for this - it’s just an example as far as I know). However, now it’s clear that there could be situations where there are other attributes that users are allowed to write into, that in all other ways prevent XSS, but allow you to change the functionality of the tag you are within. Clever attack!

This entry was posted on Thursday, August 30th, 2007 at 9:23 am and is filed under XSS, Webappsec. You can leave a response as well.