2/n Deserialization based on data supplied by the user could result in two types of attacks:
Remote code execution attacks, where the structure of the serialized data is changed to modify the behavior of the object being unserialized.
3/n Parameter tampering attacks, where data is modified to escalate privileges or change for example quantity or price of products.
The best way to protect against deserialization attacks is probably to challenge the use of the deserialization mechanism in the application.
4/n They are cases where the use of the deserialization mechanism was not justified and created breaches (CVE-2017-9785).
If the use of deserialization mechanisms is valid in your context, the problem could be mitigated in any of the following ways:
5/n
- Instead of using a native data interchange format, use a safe, standard format such as untyped JSON or structured data approaches such as Google Protocol Buffers.
6/n - To ensure integrity is not compromised, add a digital signature (HMAC) to the serialized data that is validated before deserialization (this is only valid if the client doesn’t need to modify the serialized data)
n/n
- As a last resort, restrict deserialization to be possible only to specific, whitelisted classes.
#SecurityExplained S-87: CWE Top 25: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product makes sensitive information available to someone who isn't explicitly permitted to access it.
1/n
2/n
CWE-200 arises when confidential information (e.g., application systems and network information, user-supplied data such as names email addresses) is made available to individuals who are not authorized to see it.
3/n
This flaw could be the outcome of various issues involving the disclosure of sensitive information.
When the following conditions exist, the information is considered sensitive:
2/n Applications that perform NoSQL operations based on tainted data can be exploited similarly to regular SQL injection bugs. Depending on the code, the same risks exist as with SQL injections: The attacker aims to access sensitive information or compromise data integrity.
3/n Attacks may involve the injection of query operators, JavaScript code, or string operations. This problem can be mitigated by using an Object Document Mapper (ODM) library or by validating user-supplied data based on its size or allowed characters.
2/n Constructing SQL queries directly from tainted data enables attackers to inject specially crafted values that change the initial meaning of the query itself. Successful database query injection attacks can read, modify, or delete sensitive information from the database ...
3/n ...and sometimes even shut it down or execute arbitrary operating system commands. The solution is to use prepared statements and to bind variables to SQL query parameters with dedicated methods like bindParam, which ensures that user-provided data will be properly escaped.