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

Deserialization should not be vulnerable to injection attacks

    Details

    • Message:
      Refactor this code to not deserialize tainted, 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
    • Targeted languages:
      C#, Python
    • Covered Languages:
      Java, PHP
    • 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

        1.
        Java RSPEC-5136 Language-Specification Active Unassigned
        2.
        PHP RSPEC-5138 Language-Specification Active Unassigned
        3.
        C# RSPEC-5593 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: