Red Hat Security Advisory: flatpak security update

1. Implementation · Parameterization

   Where possible, avoid building a single string that contains the command and its arguments. Some languages or frameworks have functions that support specifying independent arguments, e.g. as an array, which is used to automatically perform the appropriate quoting or escaping while building the command.

2. Architecture and Design · Input Validation

   Understand all the potential areas where untrusted inputs can enter your product: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application.

3. Implementation · Input Validation

   Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

OWASP Cheat Sheets

• Abuse Case (opens in a new tab)
• Deserialization (opens in a new tab)
• Injection Prevention (opens in a new tab)
• SQL Injection Prevention (opens in a new tab)
• Injection Prevention in Java (opens in a new tab)

OWASP ASVS 4.0.3

• V1.5.1 (opens in a new tab)

Attack patterns

• Flash Parameter Injection (opens in a new tab)
• Using Meta-characters in E-mail Headers to Inject Malicious Payloads (opens in a new tab)
• HTTP Parameter Pollution (HPP) (opens in a new tab)
• OS Command Injection (opens in a new tab)
• Parameter Injection (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).