Uploaded image for project: 'Rules Repository'
  1. Rules Repository
  2. RSPEC-5135

Deserialization should not be vulnerable to injection attacks

    Details

    • Message:
      Change this code to not deserialize user-controlled data.
    • Highlighting:
      Hide

      "[varname]" is tainted (assignments and parameters)
      this argument is tainted (method invocations)
      the returned value is tainted (returns & method invocations results)

      Show
      " [varname] " is tainted (assignments and parameters) this argument is tainted (method invocations) the returned value is tainted (returns & method invocations results)
    • Default Severity:
      Blocker
    • Impact:
      High
    • Likelihood:
      High
    • Default Quality Profiles:
      Sonar way
    • Covered Languages:
      C#, Java, PHP, Python
    • Remediation Function:
      Constant/Issue
    • Constant Cost:
      30min
    • Analysis Level:
      Abstract Interpretation
    • Analysis Scope:
      Main Sources
    • Common Rule:
      Yes
    • CWE:
      CWE-134, CWE-502
    • OWASP:
      A8
    • SANS Top 25:
      Risky Resource Management

      Description

      User provided data such as URL parameters, POST data payloads or cookies should always be considered untrusted and tainted. 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.
      • 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. They are cases were the use of 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:

      • 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.
      • 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)
      • As a last resort, restrict deserialization to be possible only to specific, whitelisted classes.

      See

        Attachments

          Issue Links

          1.
          Java RSPEC-5136 Language-Specification Active Unassigned
          2.
          PHP RSPEC-5138 Language-Specification Active Unassigned
          3.
          C# RSPEC-5593 Language-Specification Active Unassigned
          4.
          Python RSPEC-5700 Language-Specification Active Unassigned

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                lars.svensson Lars Svensson (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: