Vulnerable Encoded URLs

We can also use that previous code for generating asymmetric key programmatically but we move ahead with “ajaykumar007”.

Generating Salt

A salt typically is random data that is used as a supplementary input to a one-way function that hashes a passphrase or sensitive data. The salt and the password are concatenated and processed with a cryptographic hash function and the resulting output (but not the original password) is stored with the salt in a database. The key purpose of a salt is to protect against a pre-computed rainbow table and dictionary attacks.

It is not necessary to keep the salt value secret. An attacker never ever assumes in advance what the salt will be, so they can't use the rainbow table or pre-compute the lookup table because a salt value is generated at random and each time the hashed value would be different. Generally, we can create a salt with a random value using the following code:
Although the previous code could be a best fit when generating a raw salt value but it is a bit complicated. Hence, we can generate a random salt value by ASCII Convertor too. The salt value could be anything as we explained earlier. So, just put any value in the plain-text box for example “keyencrypt” and convert it into a hexadecimal format. Simply, we have generated the salt value that will be merged with the secret to encrypt the plain text as in the following:



As we can observe from the previous figure, the salt value is in hex form, now prefix the 0X to each hex byte and place them into a sequence and finally assign this value to an Array of Byte data type that would be referenced in the Rfc2898DeriveBytes later with the secret key. Just remember one thing; the salt value must be the same during both encryption and decryption.
Hashing Algorithm

We shall encrypt the Query String parameters by employing the Advanced Encryption Standard (AES) algorithm, which is a variant of Rijandael algorithm and of course, provides virtuous security and performance. AES reduces the amount of parameters you need to configure and allows you to work at a very high level of abstraction. The AES algorithm is a symmetric-key block cipher that can use keys of 128, 192 and 256 bits and encrypts and decrypts data in blocks of 128 bits. The following image depicts the entire life cycle of encrypting the Query string as well as decrypting at the receiving site as in the following:



Ok, we now have all the ingredients for hashing, like query string, secret key and salt value. In the Encrypt() method, the key derivation method Rfc2898DeriveBytes in the AES implementation repeatedly hashes the password along with a salt and padding and a block size configuration.
Testing

Everything is now in place for the Encrypt() method. Now run the project and enter some login information in the page along with enabling the Secure Sign-in check box. As decided, the user would be redirected to the Welcome.aspx page but notice the query string parameter value. They are encrypted and totally fool-proof from hacking. For our convenience, we are also displaying the query string value (login data) over the welcome.aspx as in the following:



Query String Decryption

As you have seen in the previous figure, the query string is also displayed over the page in encrypted form and that form also provides the facility to decrypt these ciphered values. This section shows that mechanism with the Decrypt() method that would be called when the user clicks over the Decrypt button. Here, we need two things; the key to encrypt the query string parameters and the salt. Both of these must not be tempered with, otherwise the decryption won't happen.
This time click over the Decrypt button and the web page will display the deciphered value that was entered in the login form and passed through the query string as in the following:



Vulnerability and Redemption

This paper demonstrates the generation of a persistent a symmetric key using the AES algorithm to encrypt and decrypt sensitive URL data. However, data in the query string is successfully encoded but this approach is still vulnerable to Replay attack, MITM attack and Brute Force attack. Sensitive credentials are still passed in clear text form even if encrypted using the AES algorithm. A smart hacker can easily hack the user name and password via session hijacking since HTTPS is not applied. The real problem here is that the user name and password are still being transmitted in plain text at least once to the server and then the encrypted strings are being returned to the client. Those strings can be picked up off the wire and used in a replay attack. Here, the following methods should be used to fix the aforesaid problem in this article for redemption:

• HTTPS: We shall need to install a digital certificate on the server for sensitive data manipulation to protect the traffic communication between the client and server.
  
  
• Post Method: Data that travelled across the server via query string (GET method) is always vulnerable to sniffing or hijacking. Hence, it is a good idea to use the POST method rather than GET method in such a scenario.
  
  
• Secure Session Management: It is suggested to apply a proper session management to foil a man-in-the-middle or session hijacking attack.
  
  
• Encrypt XML Data: Data residing in a XML file is always in clear text form, so it is not recommended to store crucial data in XML files.

Final word

In this article, we have pinpointed the vulnerability in query string parameters while encoding them by practicing weak cryptography methods where the data is sent across the network in clear text and is susceptible to MITM attack. We have explained the scenario or glitches often done by programmers and developers during encryption and decryption of sensitive URL data using symmetric key encryption and the AES algorithm. Finally, we have seen the actual problem of applying weak cryptography methods as well as redemption methods.