In critical web apps (such as banking, finance, healthcare), payload encryption is often implemented to protect sensitive data during transmission.
Most developers and product owners assume that encryption is secure and tend to apply it as a final foolproof fix to prevent tampering of data. Although encryption does add a layer of security, it is not always effective if not implemented correctly.
This blog post explores common techniques used to break payload encryption in web applications.
Understanding Payload Encryption
Payload encryption is a method used to secure data by converting it into an unreadable format using cryptographic algorithms.
This is done to protect sensitive information from being intercepted and understood by unauthorized parties during transmission over networks. Most commonly, payload encryption is implemented on the client side (e.g., in JavaScript for web apps or in mobile apps) before sending data to the server and on the server side before sending data back to the client.
Payload encryption is over and above the standard transport layer encryption provided by HTTPS (TLS). So, tools like Burp Suite or OWASP ZAP will not be able to decrypt/encrypt the payloads automatically.
Types of Payload Encryption
- Symmetric Encryption (Commonly used, easier to implement)
- The same key is used for both encryption and decryption.
- Common algorithms: AES, DES, 3DES.
- Asymmetric Encryption (Rarer in payload encryption, more complex and resource-intensive)
- Uses a pair of keys: a public key for encryption and a private key for decryption.
- Common algorithms: RSA, ECC.
Is payload encryption effective?
- While payload encryption adds a layer of security, it is not foolproof.
- Encrypting payloads is more of a deterrent than a complete security solution. This is security through obscurity.
- If the encryption implementation is weak or if the encryption keys are poorly managed, attackers may find ways to break the encryption and access the sensitive data.
Common Techniques to Break Payload Encryption
- Find how the encryption is implemented
- Observe the request and response carefully using a proxy tool like Burp Suite or OWASP ZAP.
- Look for clues in the client-side code (JavaScript, mobile app code) that may reveal how the encryption is implemented.
- Identify the encryption algorithm
- Look for functions or libraries used for encryption (e.g.,
CryptoJS, WebCrypto API). - Look for modes of operation like
CBC, GCM, ECB, etc. - Look for padding schemes like
PKCS7, NoPadding, etc.
- Find the encryption key, iv or secret used for encryption/decryption
- Look for hardcoded keys or secrets in the code.
- Look for any dynamic generation of keys, ivs or secrets in the code.
- Look for any usage of cookies, local storage, session storage, etc. which may contain keys, ivs or secrets.
- Use DevTools to debug and trace the code execution
- Use browser DevTools to set breakpoints and step through the code to understand how encryption/decryption is performed.
- Look for any functions that are called before sending the request or after receiving the response.
- Replicate the encryption/decryption process
- Use the identified
algorithm, key, iv or secret to replicate the encryption/decryption process. - Use #specific tools or write custom scripts to encrypt/decrypt the payloads.
- If the request is encrypted, certainly the payload is encrypted in client side and hence we can find the encryption code and the key, iv or secret used for encryption.
- If the response is encrypted and we see the data in plaintext in the client side, certainly the payload is decrypted in client side and hence we can find the decryption code and the key, iv or secret used for decryption.
What to Look For in Client Side Code
- Analyse request and response carefully using a proxy tool like Burp Suite or OWASP ZAP.
- Look for keywords like
encrypt, decrypt, crypto, key, iv, secret in the code. - Look for libraries like
CryptoJS, JSEncrypt, WebCrypto API, etc. - Look for modes of operation like
CBC, GCM, ECB, etc. - Look for padding schemes like
PKCS7, NoPadding, etc. - Look of variables which post body contains the payload.
example:
{
"enc_data": "<encrypted_payload_here>"
}
- Look for functions which are called before sending request or after receiving response.
- Look for any hardcoded keys, ivs or secrets in the code.
- Look for any dynamic generation of keys, ivs or secrets in the code.
- Look for any usage of cookies, local storage, session storage, etc. which may contain keys, ivs or secrets.
Potential Vulnerabilities to Exploit after Breaking Encryption
- Unlocked functionality by tampering response data.
- Bypassing client side validations.
- IDORs and other access control issues.
- Extrenous data exposure.
- Business logic flaws.
Edge Cases (Tricky Implementations)
Developers are tricksy and may use a out of the box methods to encrypt/decrypt data.
I’ve seen cases where developers use weird methods. All these edge cases can be found by carefully analysing the request/response and client side code.
Example 1:
- Encryption key is send back in response of
OPTIONS request or used from Response of previous request. - This key is then used to encrypt/decrypt data in next request and a new key is presented in response of next request.
Example 2:
- For each request a new
key/iv pair is generated using some logic and these values are sent in Request headers. So, for each request the key/iv will be different.
Example 3:
- Application uses a
cookie for authentication but sends key/iv in Authorization header.
Example 4:
- Application sends some other data in request/response which is used to generate key/iv pair.
- In one case, I found that the application was sending a
Correlation ID in request which was used to generate the key for encryption.
