- From: Marcos Caceres <marcosc@opera.com>
- Date: Sun, 22 Feb 2009 19:10:35 +0100
- To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
2009/2/16 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>: > No problem. > > From > http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0346.html: > > > ---------------- > [mp] The hole is that signature files are excluded from the generation > of the signature values in any other signature files. This means that > if, for example, an attacker added to the widget resource a signature > file containing some malicious content, the malicious content of that > file wouldn't be covered by any of the other signatures but the widget > user agent thinks the entire widget resource is signed. This could > happen regardless of whether or not the signature file was actually > valid, or was just named according to the convention for digital > signature. Ok, good point. > To be abused by an attacker it would either be necessary to inject a > reference to the file into the widget, which might be difficult, or to > hijack an existing reference to a signature file by swapping the > intended signature file for the attacker's signature file (with the same > name). While this later attack depends on the author providing such a > reference in their widget, there are two reasons why the author may > currently choose to do this - to get some information about the > signature to display to the user, or possibly more likely, to get around > the need to sign everything in their widget resource (I thought of this > as a way around signing everything so developers will too!). Ok. > It's not a big hole and the attacks require some "assistance" from > developers, but unless there's a reason not to it should be pretty easy > to close. > ---------------- > > I realise that this still requires the ability to read in the file, > which would probably have to be via a local Ajax call, not a reference > as I suggested above. You could say that it's a pretty theoretical > vulnerability but if it's easy to fix and there's no negatives then I > think we should address it. Ok, as you saw, I created an issue so we don't forget to address this: http://www.w3.org/2008/webapps/track/issues/83 I also added your description of the hole. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Sunday, 22 February 2009 18:11:10 UTC