0 / 10 flipped
Concept
What is input validation, and which attack classes does it directly prevent?
Answer
Input validation verifies that every piece of data entering the application matches the expected type, format, length, and character set. It must cover every input source: web forms, API parameters, URL strings, headers, file uploads.
Attack classes it prevents:
• SQL injection — rejecting special chars like ', --, ; in fields that query databases
• Cross-site scripting (XSS) — rejecting/escaping < > and script tags in text inputs
• Buffer overflow — enforcing maximum input length
• Command injection — rejecting shell metacharacters
Companion process: normalization — decode and standardize input before validation to prevent encoding bypass attacks.
Attack classes it prevents:
• SQL injection — rejecting special chars like ', --, ; in fields that query databases
• Cross-site scripting (XSS) — rejecting/escaping < > and script tags in text inputs
• Buffer overflow — enforcing maximum input length
• Command injection — rejecting shell metacharacters
Companion process: normalization — decode and standardize input before validation to prevent encoding bypass attacks.
Term
Fuzzing / Fuzz Testing
Definition
An automated security testing technique that submits large volumes of unexpected, malformed, or random input to an application to discover vulnerabilities. A fuzzer does not know valid input — it deliberately provides invalid values: oversized strings, null bytes, wrong data types, boundary values, special characters.
If the application crashes, hangs, or behaves unexpectedly, a vulnerability has been found — typically a gap in input validation.
Attacker use: fuzz production applications to find exploitable vulnerabilities.
Defender use: fuzz your own application during development and QA to find vulnerabilities before attackers do.
Fuzzers find edge cases that human testers would never think to try.
If the application crashes, hangs, or behaves unexpectedly, a vulnerability has been found — typically a gap in input validation.
Attacker use: fuzz production applications to find exploitable vulnerabilities.
Defender use: fuzz your own application during development and QA to find vulnerabilities before attackers do.
Fuzzers find edge cases that human testers would never think to try.
Term
Secure Cookie — Secure attribute
Definition
A flag set on a browser cookie that instructs the browser to only transmit the cookie over HTTPS (encrypted) connections. The browser will refuse to send a Secure-flagged cookie over HTTP.
What it prevents: network interception of session cookies — an attacker on the same network cannot capture the session token over an unencrypted connection because the browser never sends it over HTTP.
What it does NOT do: encrypt the cookie's contents; it only controls when the cookie is transmitted.
Companion: HttpOnly attribute — prevents JavaScript from reading the cookie, blocking XSS-based session theft. Both attributes should be set on session cookies.
What it prevents: network interception of session cookies — an attacker on the same network cannot capture the session token over an unencrypted connection because the browser never sends it over HTTP.
What it does NOT do: encrypt the cookie's contents; it only controls when the cookie is transmitted.
Companion: HttpOnly attribute — prevents JavaScript from reading the cookie, blocking XSS-based session theft. Both attributes should be set on session cookies.
Concept
What SHOULD and what SHOULD NOT be stored in cookies?
Answer
Appropriate cookie content:
• Session tokens (random, server-validated identifiers)
• User preferences (theme, language)
• Non-sensitive tracking identifiers
Never store in cookies:
• Passwords (even hashed)
• Financial data (credit card numbers, bank details)
• Personally identifiable information (SSN, date of birth)
• Authorization levels or roles
Why: Cookies are not designed for secure storage. They are accessible to JavaScript (unless HttpOnly is set), transmitted to the server with every request, logged by servers, and visible to browser extensions. The design assumption is that cookie contents are not highly sensitive — session tokens are acceptable because they are meaningless without the server's session database.
• Session tokens (random, server-validated identifiers)
• User preferences (theme, language)
• Non-sensitive tracking identifiers
Never store in cookies:
• Passwords (even hashed)
• Financial data (credit card numbers, bank details)
• Personally identifiable information (SSN, date of birth)
• Authorization levels or roles
Why: Cookies are not designed for secure storage. They are accessible to JavaScript (unless HttpOnly is set), transmitted to the server with every request, logged by servers, and visible to browser extensions. The design assumption is that cookie contents are not highly sensitive — session tokens are acceptable because they are meaningless without the server's session database.
Term
SAST — Static Application Security Testing
Definition
A security testing technique that analyzes application source code (or compiled binary) for vulnerabilities without executing the application.
Finds well:
• Buffer overflow — unsafe functions (gets, strcpy without bounds)
• SQL injection — string concatenation in queries
• Hardcoded credentials
• Use of deprecated/broken algorithms (MD5, DES)
• Insecure function calls
Integrates into CI/CD pipelines for automated scanning on every code commit. Catches vulnerabilities during development — cheapest time to fix them.
Key limitation: not everything is visible in code; false positives require human review.
Finds well:
• Buffer overflow — unsafe functions (gets, strcpy without bounds)
• SQL injection — string concatenation in queries
• Hardcoded credentials
• Use of deprecated/broken algorithms (MD5, DES)
• Insecure function calls
Integrates into CI/CD pipelines for automated scanning on every code commit. Catches vulnerabilities during development — cheapest time to fix them.
Key limitation: not everything is visible in code; false positives require human review.
Concept
What types of vulnerabilities can SAST NOT find, and why?
Answer
SAST identifies code patterns — it cannot evaluate logic, intent, or runtime behavior.
What SAST misses:
• Cryptographic implementation errors — the code calls a crypto function; SAST cannot evaluate if the parameters (key size, IV handling, padding mode) are correct
• Authentication design flaws — session token predictability, race conditions in auth flow
• Business logic vulnerabilities — price manipulation, workflow bypass, privilege escalation through intended features
• Vulnerabilities from component interaction — emerge at runtime, not visible in any single file
False positives: SAST flags safe code that resembles vulnerable patterns — developers must manually review every finding. SAST output is not a definitive vulnerability list.
What SAST misses:
• Cryptographic implementation errors — the code calls a crypto function; SAST cannot evaluate if the parameters (key size, IV handling, padding mode) are correct
• Authentication design flaws — session token predictability, race conditions in auth flow
• Business logic vulnerabilities — price manipulation, workflow bypass, privilege escalation through intended features
• Vulnerabilities from component interaction — emerge at runtime, not visible in any single file
False positives: SAST flags safe code that resembles vulnerable patterns — developers must manually review every finding. SAST output is not a definitive vulnerability list.
Term
Code Signing
Definition
Using asymmetric encryption and digital certificates to verify that software has not been modified since publication and genuinely originates from the claimed developer.
Answers two questions:
• Integrity: Has this application been altered since the developer released it?
• Authenticity: Did this application actually come from the claimed developer?
Protects against:
• Supply chain tampering (modified installer on download mirror)
• Malware masquerading as legitimate software
For internal apps: organizations can run their own CA; internal CA root cert is distributed to all devices so they trust the internal developer's signatures.
Answers two questions:
• Integrity: Has this application been altered since the developer released it?
• Authenticity: Did this application actually come from the claimed developer?
Protects against:
• Supply chain tampering (modified installer on download mirror)
• Malware masquerading as legitimate software
For internal apps: organizations can run their own CA; internal CA root cert is distributed to all devices so they trust the internal developer's signatures.
Concept
Walk through the code signing process. Who signs what with which key at each step?
Answer
1. CA signs developer's public key (using CA's private key) → creates developer's code-signing certificate. CA vouches for the developer's identity.
2. Developer signs code with their private key → attaches digital signature + certificate to the application package.
3. User's OS verifies using developer's public key (from the cert) → decrypts signature, independently hashes the code, compares hashes.
• Match + trusted cert chain → install proceeds
• No match or untrusted cert → OS warning: application may be tampered or from unknown publisher
Memory anchor: CA signs the developer. Developer signs the code. OS verifies everything.
2. Developer signs code with their private key → attaches digital signature + certificate to the application package.
3. User's OS verifies using developer's public key (from the cert) → decrypts signature, independently hashes the code, compares hashes.
• Match + trusted cert chain → install proceeds
• No match or untrusted cert → OS warning: application may be tampered or from unknown publisher
Memory anchor: CA signs the developer. Developer signs the code. OS verifies everything.
Term
Sandboxing — concept and purpose
Definition
An isolation mechanism that restricts an application to only the resources it needs, preventing access to unrelated files, processes, and system components.
Purpose: limits blast radius of a compromise. Even if an app is exploited, the attacker is bounded by the sandbox.
Implementations:
• Dev sandbox — development isolated from production
• Virtual machines — VMs isolated from each other
• Mobile OS — each app in its own container; can't read other apps' data
• Browser iframes — embedded content isolated from parent page
• Windows UAC — apps run at standard privilege; admin actions require elevation
Key principle: sandboxing doesn't prevent compromise — it contains it.
Purpose: limits blast radius of a compromise. Even if an app is exploited, the attacker is bounded by the sandbox.
Implementations:
• Dev sandbox — development isolated from production
• Virtual machines — VMs isolated from each other
• Mobile OS — each app in its own container; can't read other apps' data
• Browser iframes — embedded content isolated from parent page
• Windows UAC — apps run at standard privilege; admin actions require elevation
Key principle: sandboxing doesn't prevent compromise — it contains it.
Concept
What are the four capabilities of application security monitoring?
Answer
1. Real-time monitoring: Current user activity, request volumes, access patterns — operational visibility and immediate detection of active attacks or anomalies.
2. Blocked attack log: Records SQL injection attempts, unauthorized access attempts, and WAF blocks that were successfully stopped — shows what's being attempted even when defenses hold.
3. Audit logs: Timestamped records of authentication events, admin actions, file accesses, configuration changes — primary forensic record for incident investigation and compliance demonstration.
4. Anomaly detection: Identifies behavior deviating from established baselines — spike in failed logins, unusual data volume, off-hours access — flags potential insider threats and novel attacks that don't match known signatures.
2. Blocked attack log: Records SQL injection attempts, unauthorized access attempts, and WAF blocks that were successfully stopped — shows what's being attempted even when defenses hold.
3. Audit logs: Timestamped records of authentication events, admin actions, file accesses, configuration changes — primary forensic record for incident investigation and compliance demonstration.
4. Anomaly detection: Identifies behavior deviating from established baselines — spike in failed logins, unusual data volume, off-hours access — flags potential insider threats and novel attacks that don't match known signatures.