[Cosmo-dev] Bug 9930: XSS vulnerability

[Bobby Rullo]

I don't quite agree with the analogy. I do agree that having the  
password accessible the way it is is bad, but I think if anything  
that just adds weight to the fact that XSS stuff should be fixed,  
because what can be done with it is so much worse.

However, given the fact that in the short-term at least Cosmo is  
meant to be used amongst groups of trusted users, I don't think it's  
critical to fix this right away - maybe 0.7.X


On Jul 13, 2007, at 9:38 PM, Matthew Eernisse wrote:

> Howdy.
>
> While I agree that allowing injection of arbitrary scripts that can  
> grab client-side data (calendar event info or what have you) and  
> send it somewhere on the 'Net is a Bad Thing -- I think the example  
> of passwords used here is kind of like worrying about the quality  
> of your lock when the door itself is made out of balsa wood.
>
> Right now you can type this into your (or your boss's) location bar:
>
> javascript:alert(cosmo.util.auth.getPassword());
>
> And see the password in clear text.
>
> I'm pretty sure I understand the reasons why we're currently doing  
> things this way, and that it's a hard problem given the  
> requirements we currently have set for ourselves. But I don't know  
> of any credible online services that store passwords on the client  
> in such a trivially retrievable way.
>
> Maybe it's already on the agenda, but I'd really like us to fix  
> this, even if it means adjusting our requirements for auth (e.g.,  
> no sticky sessions).
>
>
> Matthew
>
> Travis Vachon wrote:
>> Hi folks
>> During bug council today it was mentioned that we need to have a  
>> list discussion about bug 9930. For anyone that hasn't seen it,  
>> this is a pretty classic example of what wikipedia refers to as a  
>> "type 2" XSS bug: http://en.wikipedia.org/wiki/XSS
>> The long and short of this is that anyone can run arbitrary code  
>> in the web ui by setting the title of an event to some sneaky  
>> html. To try this out, log in to any recent version of Cosmo  
>> before r5077 for example, qacosmo as of right now) and enter "<img  
>> src='doesntexist.jpg' onerror='alert(cosmo.util.auth.getPassword 
>> ())'/>" as the title of an event. It would be an easy extension of  
>> this to put the password in an event and save it to the server,  
>> allowing anyone subscribed to the calendar you are looking at to  
>> see your password.
>> I've gone ahead and fixed this particular bug, and confirmed that  
>> this is not a problem in the calendar ui or the collection  
>> selector. That said, we should probably do a full review of the UI  
>> and the UI code at some point to make sure there are no other  
>> places that this could happen. From the discussion in IRC today it  
>> sounds like the current feeling is that this review will be punted  
>> to post preview, possibly 0.7.1 (the real, new 0.7.1 ;-) ) but we  
>> felt it should be discussed on the list to make sure there is  
>> community agreement. At least part of the reasoning behind this  
>> feeling is that we expect our users to have some sort of trusting  
>> relationship with anyone they share their calendars with.
>> Personally, I would suggest that we consider any XSS bugs we find  
>> blockers for the release, since they tend to be easy to fix (see  
>> r5077) but wait until later to do a thorough code review. Perhaps  
>> foolishly, I volunteer to grab any that we find.
>> Let the debate (or lack thereof) begin!
>> -Travis
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev