Input Validation — What to Validate, What It Prevents
| Input Property | What to Enforce | Example | Attack Prevented When Missing |
|---|---|---|---|
| Data type | Only accept the expected type (numeric, alphanumeric, date) | Age field: integers only, no letters | Type confusion, unexpected function behavior |
| Length / size | Maximum (and sometimes minimum) length enforced | Username: 3–32 characters max | Buffer overflow — oversized input overwriting adjacent memory |
| Allowed character set | Restrict to expected characters; reject or escape others | ZIP code: digits only (US); reject semicolons, quotes, dashes | SQL injection, XSS, command injection — all use special characters |
| Format / pattern | Match expected pattern (regex, date format, email structure) | Email: must contain @, valid domain structure | Format string attacks, parser exploits |
| Range | Numeric values within acceptable min/max range | Age: 0–130; reject -1 or 999 | Logic errors, integer overflow conditions |
| Normalization | Decode and standardize before validation | Decode %3C → < before checking for HTML tags | Encoding bypass attacks that slip past naive validators |
Secure Cookie Attributes — What Each One Does
| Attribute | What It Does | Attack It Prevents | Exam Focus |
|---|---|---|---|
| Secure | Browser only sends cookie over HTTPS; refuses to transmit over HTTP | Network interception / session hijacking over unencrypted connections | Yes — primary exam topic; Secure = HTTPS only |
| HttpOnly | JavaScript cannot read the cookie (document.cookie returns nothing for HttpOnly cookies) | XSS-based session theft — attacker's injected script cannot steal the session cookie | Secondary — know it exists and what it blocks |
| SameSite | Restricts when cookie is sent with cross-site requests | Cross-Site Request Forgery (CSRF) — prevents attacker site from triggering authenticated requests | Awareness level |
| No sensitive data rule | Developer policy: never store passwords, PII, or financial data in cookies | Data exposure if cookie is captured, logged, or read by third-party scripts | Yes — cookies are not designed for secure storage |
SAST — What It Finds vs. What It Misses
| Category | SAST Can Find | SAST Cannot Find | Why |
|---|---|---|---|
| Memory safety | Buffer overflow from unsafe functions (gets, strcpy without bounds check) | Runtime memory corruption from complex logic paths | Simple patterns visible in code; complex paths require execution |
| Injection | SQL injection from string concatenation in queries; command injection patterns | Logic-based injection where attack depends on runtime data | Static concatenation visible; runtime data unavailable during analysis |
| Cryptography | Use of deprecated/broken algorithms (MD5, DES, RC4) | Incorrect cryptographic implementation (weak keys, IV reuse, padding errors) | Algorithm call visible; correctness of implementation is a logic problem |
| Authentication | Hardcoded credentials; plaintext password storage patterns | Authentication design flaws (session token predictability, race conditions) | Hardcoding is a code pattern; design flaws emerge from system behavior |
| Business logic | Very limited — obvious logic errors in simple code | Business logic flaws (price manipulation, workflow bypass) | Business logic requires understanding of intent, not just code syntax |
| False positives | — | SAST flags safe code that resembles vulnerable patterns — requires human review of all findings | Pattern matching lacks context; human judgment required |
Code Signing — Step-by-Step Process and Trust Chain
| Step | Who Acts | What Happens | Key Used |
|---|---|---|---|
| 1. Certificate issuance | Certificate Authority (CA) | CA verifies developer's identity and signs developer's public key, creating a code-signing certificate | CA's private key (signs the cert) |
| 2. Code signing | Developer | Developer computes a hash of the application code and encrypts it with their private key, attaching the signature and certificate to the application package | Developer's private key |
| 3. Distribution | Developer → Users | Signed application package is distributed (download site, package manager, enterprise deployment) | — |
| 4. Signature verification | User's operating system | OS decrypts the signature using the developer's public key (from the cert), independently hashes the application code, and compares the two hashes | Developer's public key |
| 5. Decision | OS | Hashes match + cert trusted → install proceeds normally. Hashes don't match or cert untrusted → OS displays warning (application modified or from unknown publisher) | — |
Sandboxing Environments — Implementations and What Each Isolates
| Environment | What Is Sandboxed | What the Sandbox Prevents | Example |
|---|---|---|---|
| Development sandbox | Development code and systems | Dev changes affecting production; testing code from impacting live users or data | Dev/staging/prod environment separation; developer cannot deploy untested code directly to production |
| Virtual machines | Each VM's memory, storage, and processes | Compromised VM from accessing other VMs on same host; lateral movement via hypervisor | VM escape vulnerabilities are rare precisely because the VM sandbox is strong |
| Mobile OS (iOS/Android) | Each app's data and permissions | App from reading another app's data; app from accessing hardware without explicit permission | Compromised browser can't read the banking app's stored credentials or the user's photos |
| Browser iframes | Embedded third-party content | Iframe content from accessing parent page's data, cookies, or JavaScript variables | Ads embedded in a page cannot read the page's session data or user input |
| Windows UAC | Application's privilege level | Applications from performing administrative actions without explicit user authorization | Malware that infects a standard user process cannot install drivers or modify system files without UAC elevation prompt |
Application Security Monitoring — Four Capabilities
| Capability | What It Captures | Primary Use | Example Signal |
|---|---|---|---|
| Real-time monitoring | Current user activity, request volume, access patterns, feature usage | Operational visibility; immediate detection of ongoing attacks or outages | Dashboard shows 10× normal request volume from one IP — possible DoS attempt or scraping |
| Blocked attack log | Attacks that were successfully blocked — SQL injection attempts, unauthorized access attempts, WAF blocks | Understanding what's being attempted even when defenses hold; identifying persistent attackers; trending new attack patterns | 50 SQL injection attempts from a single IP against the login form over 10 minutes |
| Audit logs | Authentication events, admin actions, file accesses, config changes — timestamped and attributed | Forensic investigation, compliance demonstration, incident response timeline reconstruction | Log shows admin account logged in at 03:00 AM and exported the customer database |
| Anomaly detection | Behavior deviating from established baselines — unusual access times, volumes, patterns | Detecting novel attacks, insider threats, and compromised credentials that don't match known signatures | User who normally downloads 5 MB/day suddenly downloads 8 GB in one session at midnight |