Share via

Vulnerabilities in Web Applications due to improper use of Crypto – Part 4

  • Article

Digital signature is a cryptographic mechanism that provides three security services; data origin authentication, data integrity and non repudiation [1]. Verification of a digital signature using a public key, gives the verifier proof, that the signature was created by someone in possession of the corresponding private key. Also if a particular user is the only one known to be associated with that private key, then it can be proved that the data has originated from that user and has not changed since.

Digital signatures, on their own, provide no notion of when in the past the message was signed. Continuing with the earlier posts on Vulnerabilities in Web Applications due to improper use of Crypto, let us see what might happen if assumptions are made about what security services digital signatures provide implicitly.

Let us consider the business case of a fictitious organization, say, Contoso. Contoso sells two different categories of products, furniture and soaps. It also has two different web sites to showcase these products (Let us call them product sites). Consumers can visit these product sites, https://www.furniture.contoso.com and https://www.soap.contoso.com, browse the products and view their prices. When they want to purchase any product, they are then redirected to another web site, also hosted by Contoso. This web site, https://www.order.contoso.com is Contoso’s payment and order processing web site (Let us call this payment site). The product identifier and the price, of any products selected by the customer are sent from the product site to the payment site as HTTP POST data during redirection. This means that the customer, using a Web proxy tool like Fiddler [2], can view and modify this HTTP POST request and thereby modify the price at which that product will be sold to that customer.

To counter this threat, the developers decide to digitally sign the HTTP POST data. When the customer decides to buy a list of products, the product data (product identifier, name and price) is created in XML format and then signed using XML Signature [3][4] by the product site. This XML Signature is then verified by the payment site. If a user, during redirection, changes the price of a product using a Web proxy tool, the signature will be invalidated and the request will be rejected by the payment site.

Below is a sample of the product data and its signature sent from Contoso’s product site to Contoso’s payment site when a customer decides to buy that product. 

    1: <request>

    2:   <productid>1234-4567-2345-34556</productid>

    3:   <productname>Special Soap</productname>

    4:   <price>49.99</price>

    5:   <Signature xmlns="https://www.w3.org/2000/09/xmldsig#">

    6:     <SignedInfo>

    7:       <CanonicalizationMethod Algorithm="https://www.w3.org/TR/2001/REC-xml-c14n-20010315" />

    8:       <SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />

    9:       <Reference URI="">

   10:         <Transforms>

   11:           <Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />

   12:         </Transforms>

   13:         <DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />

   14:         <DigestValue>6Cfv59mwYopzsEKuJ0yiSTncWBo=</DigestValue>

   15:       </Reference>

   16:     </SignedInfo>

   17:     <SignatureValue>X+CbtpNlQkXq3hb2K1GEFO0Czr4EOIzFh/DRaPZp3/+mt0kF1Yc9CWsIm6c/qU6fIPoSH3cpIDPp2R2dUI7xgw==</SignatureValue>

   18:   </Signature>

   19: </request>

The developers are content that the use of digital signatures in this case is proper and has helped them in countering this threat.

There is although a scenario where this is not quite true! Consider the case, where the price of a product with identifier, say, 1234-4567-2345-34556 is $49.99 today. The customer selects this product. The product data and its signature are then sent as a HTTP POST to the payment site. The customer, using a Web proxy tool, simply captures and stores this request. Later, say after a month, the price of this same product goes up to $79.99. Now, the customer can, during redirection, using the Web proxy tool, replace the current request with the earlier stored request and thereby purchase the product at an earlier price, which is lower than the current price. The payment site will not know the difference, since the signature is still valid.

This is a classic example of a replay attack and can be prevented by introducing a notion of freshness in the request. For example, in this case, a good mitigation may be for the payment site to include a timestamp in the XML request and ensure that the timestamp is also included while calculating the signature. The payment site, after validating the signature can now also verify that the timestamp is sufficiently recent and if not, reject the request.

References:-

[1] Internet Security Glossary, Version 2
https://tools.ietf.org/html/rfc4949

[2] Introducing Fiddler
https://www.fiddler2.com/fiddler2/

[3] .NET Framework Class Library Signature Class
https://msdn.microsoft.com/en-us/library/system.security.cryptography.xml.signature.aspx

[4] Understanding XML Digital Signature
https://msdn.microsoft.com/en-us/library/ms996502.aspx

Related articles:-
Vulnerabilities in Web Applications due to improper use of Crypto – Part 1, Part 2 and Part 3

Varun Sharma
Security Engineer, ACE Team
https://blogs.msdn.com/varun_sharma

Comments