Fwd: Best practices for Security

Moving to public list. Slides and papers from workshop are publicly  
accessible.

regards, Frederick

Frederick Hirsch
Nokia



Begin forwarded message:
> From: "ext Pratik Datta" <pratik.datta@oracle.com>
> Date: April 7, 2008 3:24:00 PM EDT
> Cc: XMLSec XMLSec Member-Only <member-xmlsec-maintwg@w3.org>,  
> Frederick Hirsch <frederick.hirsch@nokia.com>, Thomas Roessler  
> <tlr@w3.org>
> Subject: Best practices for Security
>
> It might be useful to have some security related best practices for  
> XML Signatures, in the lines of Brad Hill's presentation (http:// 
> www.w3.org/2007/xmlsec/ws/papers/04-hill-isecpartners/)
>
> 1. Don't use complicated transforms, because then the receiver  
> wouldn't know what is really being signed.
>
> It is quite possible to have a complicated looking XPath which  
> selects not a single node, but this signature still looks pretty  
> valid.
> Brad Hill proposed "The enveloped, enveloping, base64 and  
> canonicalization transforms are the only allowed algorithms. Each  
> algorithm may appear in its relevant context EXACTLY ONCE".  I  
> think this is a little restrictive, since XPath is very common, but  
> we should have but recommend only very simple xpath. Also in the  
> WSS world STRTransform is widely used, so we need to consider some  
> other transforms too.
>
>
>
> 2. Validate the signing key.
>
> Public keys cannot be validated, so it is not a good practice to  
> use them. Instead use certificates, or just have hints about the  
> certificate e.g. a SKI or a Serial and Issuer.  Symmetric keys also  
> can't be validated, but they can be used if the key is encrypted.
>
>
> 3. It is often unsafe to sign small parts of a document, you are  
> better off signing all or most of it.
>
> 3a)  I have seen a case where someone signed the action part of the  
> request, but didn't include the user name part.  So an attacker can  
> easily take the signed request as is, and just change the user name  
> and resubmit it.  These Replay attacks are much easier when you are  
> signing a small part of the document. To prevent replay attacks, it  
> is recommended to include user names, keys, timestamps, etc into  
> the signature
>
> 3b) See the PurchaseOrder example in the wrapping attack example  
> Michael McIntosh paper.  It could have been avoided if the whole PO  
> was signed, instead of only the amounts.
>
>
>
> 4. Prevent denial of service attacks
>  4a) at first validate key, then validate signed info, at finally  
> the references
>  4b) don't use RetrievalMethod for keys - this can have infinite loops
>  4c) control external references - i.e. you have a file: or http:  
> you should wither not support or it, or verify the location before  
> attempting to reach it. Some kinds of references .e.g "cid:"  
> references in case of SOAP Attachments are ok, because that is  
> really not external but part of the message.   If you follow the  
> rule 4a) then external references is Reference URI may be  
> acceptable, because the key and signed info have already been  
> validated, but external references in Retrieval method are  
> especially dangerous because you haven't validated anything yet
>  4d) have limits on number of transforms - E.g. a request with  
> 10,000 C14N transforms should definitely be considered a DoS attack
>  4e) Beware of XSLT Transforms. it is easy to have a DoS attack  
> with a single XSLT transform, just by having many levels of nested  
> for loops.
>
> Pratik
>
>

Received on Friday, 11 April 2008 13:49:45 UTC