Secure Software Implementation

How Deserialization Attacks Work

Deserializing untrusted data can trigger Remote Code Execution (RCE) via gadget chains — sequences of pre-existing code objects in the application's classpath that are activated by the attacker-controlled object graph. The attacker doesn't inject new code; they craft the object structure to invoke existing dangerous code paths.

Deserialization Defenses

• Never deserialize untrusted data using native binary serialization
• Prefer JSON or XML over binary serialization formats
• Validate object type before deserializing
• Use allowlists for deserializable class names
• Sign and/or encrypt serialized data; validate signature before deserializing
• Run deserialization in low-privilege sandboxed context

Server-Side Validation is Mandatory

Client-side validation (JavaScript) is UX only — it can be bypassed by any attacker using browser dev tools, curl, or a proxy. All security validation must be performed server-side. Client-side validation is acceptable in addition to, but never instead of, server-side validation.

Allowlist vs Blocklist

Allowlist (whitelist): Define exactly what IS valid — reject everything else. Most secure approach. Hard to bypass.

Blocklist (blacklist): Define what IS NOT valid. Inherently incomplete — attackers find bypasses via alternate encodings, new attack vectors, Unicode variations. Avoid for security validation.

Canonicalization Before Validation

Always normalize input before validating:
• URL-decode: %3C → <
• Unicode normalize: ＳＥＬＥＣＴ → SELECT
• Collapse path traversal: ../ sequences
Failing to canonicalize allows double-encoding bypass attacks.

Validation Dimensions

• Type: Is it an integer, string, date?
• Length: Min and max character/byte count
• Format: Regex pattern match (email, phone)
• Range: Numeric min/max bounds
• Charset: Permitted character set only

Never Expose Internal Details

Error messages shown to users must never reveal: stack traces, database error messages, internal file paths, software versions, framework names, or server configurations. Each piece of info aids attacker reconnaissance (OWASP A05 — Security Misconfiguration).

Fail Closed

On any error or unexpected condition, deny access by default — never grant. If the authorization check throws an exception, the user should be denied, not granted access. Logging should capture full detail server-side; users see only a generic message like "An error occurred."

Never Hardcode Credentials

Hardcoded secrets in source code end up in version control, logs, build artifacts, and containers — accessible to anyone with repo access and to attackers who compromise those systems. Use environment variables or secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).

Secret Hygiene Practices

• Rotate secrets regularly and immediately on suspected compromise
• Apply least-privilege: each service gets only secrets it needs
• Scan repos for accidentally committed secrets: truffleHog, git-secrets
• Add pre-commit hooks to block secret patterns before commit
• Never log secrets — mask in log output

Manual Review Focus Areas

• Authentication: Session management, MFA enforcement, credential storage
• Authorization: Is every action checked for permission?
• Input validation & output encoding: All external data sources
• Cryptography: Algorithm choices, key handling, IV reuse
• Error handling: Info disclosure, fail-open conditions
• Secret management: No hardcoded credentials or API keys

4-Eyes Principle & SAST

4-eyes principle: No developer approves their own code. A second reviewer (ideally security-aware) must approve before merge.

SAST tools: Checkmarx, SonarQube, Semgrep — analyze source code for vulnerability patterns without executing. Find different bugs than manual review (taint tracking, pattern matching). Complement, don't replace, manual review.

Secure Coding Standards

• CERT Secure Coding: Language-specific (C, C++, Java, Python) rules with risk rankings
• OWASP Secure Coding Practices: Technology-agnostic checklist; covers all OWASP Top 10 areas
• MISRA C: Embedded and automotive; safety-critical subset of C language

Never Roll Your Own Crypto

Custom crypto implementations introduce subtle, hard-to-detect vulnerabilities. Use established, audited libraries: libsodium (high-level, opinionated), OpenSSL, BouncyCastle. Even security experts make implementation mistakes — standard libraries have been reviewed by cryptographers and tested by millions of deployments.

Never Use ECB Mode

AES-ECB encrypts each 16-byte block independently with the same key. Identical plaintext blocks always produce identical ciphertext blocks — structural patterns in data are preserved and visible (the "AES-ECB penguin" example shows bitmap image structure survives encryption). Always use CBC, CTR, or preferably GCM.

Never Reuse IV/Nonce with Same Key

In CTR and GCM modes, reusing a nonce with the same key is catastrophic: XORing two ciphertexts encrypted with the same keystream reveals the XOR of the two plaintexts. In GCM, nonce reuse allows forging authentication tags. Generate a fresh random nonce per encryption operation using a CSPRNG.

Never Use Math.random() for Crypto

Math.random() and similar PRNG functions are not cryptographically secure — their output is predictable. Always use CSPRNG (Cryptographically Secure Pseudo-Random Number Generator): java.security.SecureRandom, crypto.getRandomValues() (JS), os.urandom() (Python), /dev/urandom (Unix).

Always Use Authenticated Encryption (AEAD)

AES-CBC and AES-CTR provide only confidentiality — no integrity protection. An attacker can flip bits in ciphertext to flip bits in plaintext without detection. Use AES-GCM or ChaCha20-Poly1305 (AEAD) which provide confidentiality + integrity + authentication in one operation. If using CBC, add a separate HMAC (Encrypt-then-MAC).

Always Salt Password Hashes

Without a salt, identical passwords produce identical hashes — enabling rainbow table attacks. bcrypt, Argon2, and scrypt automatically generate and store a unique per-user salt. Never use SHA-256 for passwords even with a manual salt — it's too fast (billions of hashes/second on GPU). The cost factor in bcrypt/Argon2 is designed to make brute-force computationally infeasible.

Key Generation & Storage

• Generate: CSPRNG only — never derive from weak entropy or Math.random()
• Store: Hardware Security Module (HSM) or Key Management Service (KMS — AWS KMS, Azure Key Vault, GCP KMS)
• Never: Store keys in source code, config files committed to git, or application logs

Key Rotation & Separation

• Rotate: On a defined schedule and immediately on suspected compromise
• Separate by purpose: Encryption key ≠ signing key ≠ MAC key ≠ session key
• Escrow: Backup with strict access controls for recovery scenarios
• Least privilege: Each service component accesses only the keys it needs