Big Bazaar is under ASP.NET Padding Oracle Vulnerability

In cryptography, a padding oracle attack is a side channel attack which is performed on the padding of a cryptographic message. The plain text message often has to be padded (expanded) to be compatible with the underlying cryptographic primitive. Leakage of information about the padding may occur mainly during decryption of the ciphertext. Padding oracle attacks are mostly associated with ECB or CBC mode decryption used within block ciphers. Padding modes for asymmetric algorithms such as OAEP may also be vulnerable to padding oracle attacks.

But recent days I was testing Big Bazaar(http://www.futurebazaar.com/)website for vulnerabilities and I found that the website is vulnerable to oracle padding attack.

ASP. Net uses encryption to hide sensitive Data and protect it from tampering by the client. However, a 

Vulnerability in The ASP. Net encryption implementation can allow an attacker to decrypt and Tamper with this data. This vulnerability exists in all versions of ASP.NET. An An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the Target server, such as web. Config. This would allow the attacker to tamper with The contents of the data. By sending back the altered contents to an affected The server, the attacker could observe the error codes returned by the server.

A workaround to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your Applications to always return the same error page - regardless of the error Encountered on the server. By mapping all error pages to a single error page, You prevent a hacker from distinguishing between the different types of errors That occurs on a server.

Items that are affected:

• /

Vulnerability Impact:

An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config. This would allow the attacker to tamper with the contents of the data. By sending back the altered contents to an affected server, the attacker could observe the error codes returned by the server.

Preventions:

1) Edit your ASP.NET Application's root Web.Config file. If the file doesn't exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file