- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Fri, 11 Apr 2008 09:42:38 -0400
- To: XMLSec XMLSec <public-xmlsec-maintwg@w3.org>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
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