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

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

  • Comments 4

Cryptography is used often in web applications. Web sites that use cookie based authentication encrypt and sign the authentication cookie. Query strings are sometimes encrypted to prevent manipulation and also to pass sensitive data from one page to another. Form fields may be encrypted and signed to hold sensitive data on the client side.

In this article and its successors I will show by means of case studies, the kind of vulnerabilities that may arise due to improper use of cryptography. 

Consider a fictitious web app for users to enter their expense reports. These reports are confidential; one user should not be able to see another user’s report.

The users can see their reports in a data grid with pagination.

xpns-1

On clicking the View button, the corresponding report is shown.

xpns-4

“ReportId” is passed in the query string. It is the primary key (incrementing integer, starting with 1), based on which the report is fetched from the database . “ReportId” is encrypted to ensure that a user cannot tamper with it. So instead of redirecting the user to ViewReport.aspx?ReportId=22, the user is instead redirected to ViewReport.aspx?ReportId=KKqUCgJzld0%3d (Cipher text for 22). If “ReportId” was not encrypted, a malicious user could change it to 23, 24 or some other integral value in an attempt to access another user’s report [1].

Also passed in the query string is the current page number (“pageNum”) of the data grid. This is used to return the user back to the page she was viewing on the data grid. “pageNum” is also encrypted using the same symmetric key

A user can therefore, deduce the encrypted value for a set of integers using the page numbers (Known plaintext attack [2]).

xpns-7

and use the same encrypted value as “ReportId” to access another user’s report.

xpns-8

The vulnerability arises for two reasons:-

1. Instead of simply performing an authorization check on the “ReportId” parameter, the developer has instead used encryption to prevent tampering.

2. The same symmetric key is used to encrypt two different parameters. Therefore the cipher text for one can be replaced as the cipher text for the other, leading to the authorization issue.

References:-

[1]  Insecure Direct Object Reference
http://www.owasp.org/index.php/Top_10_2007-A4

[2] Known-plaintext attack
http://en.wikipedia.org/wiki/Known-plaintext_attack

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

Page 1 of 1 (4 items)