Web Application Security: Vulnerabilities and Mitigations
English with a size of 1.73 MBWeb Security Fundamentals
Common Cross-Site Scripting (XSS) Types
| XSS Type | Example Payload | Description |
|---|---|---|
| Reflected XSS | <script>alert(1)</script> | Injected payload reflected immediately in server response. |
| Stored XSS | <img src="x" onerror="alert(1)"> | Payload stored on server (e.g., in database), executed later. |
| DOM-Based XSS | URL: #<script>alert(1)</script> | Payload executed via client-side JavaScript manipulation. |
| Event Handler XSS | <a onclick="alert(1)">Click</a> | Injects event attributes to run JS on user actions. |
| Attribute Injection | "><script>alert(1)</script> | Breaks out of HTML attribute to inject malicious code. |
| JavaScript URI XSS | <a href="javascript:alert(1)">Click</a> | Runs JS via link clicks using javascript: scheme. |
| Polyglot Payloads | "><svg></svg> | Versatile payload working across multiple injection contexts. |
| Obfuscated XSS | <script>alert(String.fromCharCode(88,83,83))</script> | Encodes payload to evade filters. |
DAST vs SAST: Security Testing Comparison
| Aspect | DAST (Dynamic Application Security Testing) | SAST (Static Application Security Testing) |
|---|---|---|
| Definition | Tests the running application from the outside (black-box testing). | Analyzes source code or binaries without executing the app (white-box testing). |
| When Used | During or after deployment; tests real app behavior in runtime. | Early in development; tests code before running. |
| Scope | Focuses on vulnerabilities exposed in the running app, e.g., XSS, SQLi. | Focuses on code-level issues, e.g., buffer overflows, insecure coding patterns. |
| Test Type | Black-box; interacts with the app via HTTP, UI, APIs. | White-box; parses and analyzes source code or bytecode. |
| Pros |
|
|
| Cons |
|
|
| Common Vulnerabilities Found | XSS, SQL Injection, Authentication flaws, Broken Access Control | SQL Injection, Buffer overflows, Hardcoded secrets, Unsafe functions |
| Tools Examples | OWASP ZAP, Burp Suite, IBM AppScan, Netsparker | SonarQube, Fortify, Checkmarx, Veracode, Semgrep |
| Output | Vulnerability reports with URLs, inputs, responses | Code-level findings with line numbers, severity, fix suggestions |
| Best Use Cases |
|
|
Session Management and CSRF Attacks
Session management involves maintaining stateful information about user interactions across multiple requests. It enables the server to recognize and track users, maintain user-specific data, and provide a personalized experience. Poorly managed web applications can become vulnerable to attacks such as CSRF (Cross-Site Request Forgery) attacks that can cause unintentional changes or forced transactions on behalf of a logged-in user.
Core Principles of Secure System Design
| # | Principle | Core Idea |
|---|---|---|
| 1 | Security by Design | Build security into architecture from the start |
| 2 | Security by Default | Default settings should be the most secure |
| 3 | No Security Guarantee | No system is perfect—focus on deterrence |
| 4 | Defense in Depth | Use multiple layers of security |
| 5 | Fail Safe | Default to secure behavior on errors |
| 6 | Least Privilege | Grant minimum required access |
| 7 | Compartmentalize | Limit access using need-to-know |
| 8 | Separation of Duties | Require multiple people or conditions for sensitive ops |
| 9 | Economy of Mechanism | Keep systems simple and understandable |
| 10 | Complete Mediation | Check access every time |
| 11 | Open Design | Security shouldn't rely on obscurity |
| 12 | Least Common Mechanism | Avoid shared components between privilege levels |
| 13 | Psychological Acceptability | Make security user-friendly |
| 14 | Usability & Manageability | Easy for admins to use and maintain securely |
| 15 | Secure the Weakest Link | Strengthen the most vulnerable parts first |
| 16 | Leverage Existing Components | Use well-tested, secure libraries and tools |
STRIDE Threat Modeling Framework
| STRIDE Category | Threat Description | Common Attack Examples | Mitigation Strategies |
|---|---|---|---|
| S – Spoofing | Pretending to be something or someone else | Stolen credentials, forged tokens | - Strong authentication (MFA) - Use secure tokens - Certificate validation, mutual TLS |
| T – Tampering | Unauthorized modification of data or code | Data injection, unauthorized config changes | - Data integrity checks (hash, signatures) - Input validation and sanitization - Code signing and integrity verification |
| R – Repudiation | Denying having performed an action | User denies transaction, logs deleted | - Implement audit logs with non-repudiation - Use digital signatures - Maintain tamper-proof logs |
| I – Information Disclosure | Exposing sensitive info to unauthorized users | Data leaks, verbose error messages | - Encrypt sensitive data at rest and in transit - Access control and least privilege - Mask error messages |
| D – Denial of Service (DoS) | Making service unavailable or slow | Flooding, resource exhaustion | - Rate limiting and throttling - Use of CAPTCHAs - Redundancy and failover mechanisms |
| E – Elevation of Privilege | Gaining higher access rights than allowed | Exploiting vulnerabilities to escalate privilege | - Enforce strict access control policies - Use role-based access control (RBAC) - Patch vulnerabilities promptly |
