Injection, broken authentication, sensitive data exposure. Real-world CVE examples for each category. Lab walk (ungraded): sqlmap demonstration against a deliberately-vulnerable application.
Reading (~30 min)
Read the OWASP Top 10 category pages for A03 (Injection) and A07 (Identification and Authentication Failures). These are the current OWASP 2021 names for what was historically called "SQL Injection" and "Broken Authentication." Notice that the 2021 list broadened the Injection category to include LDAP injection, OS command injection, SSTI (server-side template injection), and others beyond just SQL.
Then read the brief summary of the 2017 Equifax breach (search "Equifax breach Apache Struts CVE-2017-5638"). It is one of the clearest examples of sensitive data exposure at scale: a known vulnerability in a framework component, unpatched for months, led to the exposure of 147 million records.
Lecture outline (~1.5 hr)
Part 1: OWASP Top 10 overview (15 min)
The OWASP Top 10 is a list of the ten most common web-application security risk categories, updated periodically (2010, 2013, 2017, 2021; 2025 edition under development). It is the industry's agreed-upon vocabulary for web-application risks, not an exhaustive catalog of every possible vulnerability.
The 2021 list:
- A01: Broken Access Control (was A05 in 2017; moved to #1 because it appeared in 94% of tested applications)
- A02: Cryptographic Failures (was "Sensitive Data Exposure" in 2017; renamed to focus on the root cause)
- A03: Injection (SQL, LDAP, OS command, SSTI, XPath, etc.)
- A04: Insecure Design (new in 2021; covers architectural failures, not just implementation bugs)
- A05: Security Misconfiguration (includes XML External Entities, moved from A04 in 2017)
- A06: Vulnerable and Outdated Components (the Equifax story)
- A07: Identification and Authentication Failures (renamed from Broken Authentication)
- A08: Software and Data Integrity Failures (new in 2021; covers insecure deserialization + CI/CD attacks)
- A09: Security Logging and Monitoring Failures
- A10: Server-Side Request Forgery (SSRF) (new in 2021)
This week covers A03, A07, and A02. Weeks 8 and 9 cover the rest.
Part 2: Injection (A03) (30 min)
Injection occurs when an attacker can insert data into a context where it is interpreted as code or commands. The root cause is almost always the same: the application fails to separate data from instructions at the trust boundary between the application and the backend system (database, shell, template engine, LDAP server).
SQL injection (SQLi):
Consider a login check:
SELECT * FROM users WHERE username = '[input]' AND password_hash = '[hash]';
If the application builds this query by concatenating the user's input into the string, an attacker can input admin' -- as the username. The resulting query:
SELECT * FROM users WHERE username = 'admin' --' AND password_hash = '[hash]';
The -- begins a SQL comment, which causes the rest of the line to be ignored. The query authenticates as "admin" regardless of the password. This is authentication bypass via SQL injection.
The fix: parameterized queries (prepared statements). The query template is sent to the database engine separately from the user-supplied values; the engine treats the values as data, not as SQL syntax. The user's input cannot escape the data context and become SQL.
Other injection types:
- OS command injection: user input fed to a shell command (e.g.,
os.system("ping " + user_input)). Input of8.8.8.8; rm -rf /appends a destructive command. - SSTI (server-side template injection): user input rendered by a template engine that interprets syntax (e.g., Flask's Jinja2). Input of
{{ 7*7 }}that renders as49reveals the template engine is interpreting the input. - LDAP injection: user input in an LDAP query, similar mechanics to SQLi.
All injection variants share the same root cause and the same fix: treat user input as data, not as part of the instruction syntax. Use parameterized queries, whitelist-based validation, or an output-encoding layer appropriate to the context.
sqlmap (instructor-led demo, not a student-run tool in SEC-101):
sqlmap is an automated SQL injection tool. Given a URL with a suspected injection point, it automatically identifies the injection type and extracts the database schema, table contents, and sometimes credentials. The demo shows how a classical SQLi vulnerability in an unprotected web form falls in 30 seconds to a publicly-available tool.
The defensive lesson: if sqlmap can find and exploit it automatically, any motivated attacker can too. Parameterized queries are not optional.
Part 3: Broken authentication and authentication failures (A07) (20 min)
Covered in depth in Week 6. This week's frame is OWASP-vocabulary: what the industry calls "authentication failures" and what the OWASP 2021 category covers.
The 2021 A07 category captures:
- Permitting brute-force without lockout or CAPTCHA
- Using weak or well-known passwords (credential stuffing attacks rely on leaked password lists from other breaches)
- Storing passwords in reversible forms or fast hashes (Week 5)
- Broken session management: insecure session IDs, no session expiry, session IDs in URLs
- Missing MFA for sensitive operations
- Exposing session IDs in logs or error messages
One concrete case: the HaveIBeenPwned database (haveibeenpwned.com) contains billions of leaked credential pairs from prior breaches. Credential stuffing is automated testing of those pairs against new targets. An application without rate limiting, MFA, or breach-credential checking is vulnerable to automated credential stuffing at scale.
Part 4: Sensitive data exposure / cryptographic failures (A02) (15 min)
A02 was renamed from "Sensitive Data Exposure" to "Cryptographic Failures" in 2021 to focus on the root cause. Most sensitive data exposure occurs because data is stored or transmitted without appropriate cryptographic protection.
Common failure modes:
- Storing sensitive data (passwords, PII, financial records) in plaintext (no encryption at rest)
- Transmitting data over HTTP instead of HTTPS (no encryption in transit)
- Using deprecated encryption (MD5, SHA-1, 3DES, RC4, DES) for data that needs to remain secure
- Missing certificate validation (accepting self-signed certificates, ignoring hostname mismatches)
- Hardcoded cryptographic keys or secrets in source code (common in repositories; tools like
git-secretsortrufflehogscan for this)
The Equifax 2017 breach was an A06 case (outdated component), but the impact was A02: 147 million Social Security Numbers, birth dates, and financial records were exposed because the data was accessible to the attacker once the perimeter was breached. Defense-in-depth (encryption at the field level, not just at the perimeter) would have limited the exposure.
Lab exercises (~1.5 hr)
Lab walk: sqlmap demonstration (ungraded, instructor-led)
Follow the instructor's screen-share (or work independently on a deliberately-vulnerable local target) to watch sqlmap find and exploit an SQL injection vulnerability. The goal is to see the automated tool's output and understand what information it extracts.
You do NOT run sqlmap against systems you don't own or control. The demonstration target is a locally-installed vulnerable application (DVWA or SQLi-Labs Docker image, or the provided lab URL if running a class setup).
Document in your lab notebook: what parameter was injected, what sqlmap identified as the injection type, and what data it was able to extract.
Independent practice (~5 hr)
- Reading (1 hr): Read the OWASP SQL Injection Prevention Cheat Sheet. Focus on the "Defense Option 1: Prepared Statements (with Parameterized Queries)" section. This is the standard fix; everything else is defense-in-depth.
- picoCTF spine (3 hr): Work in Web Exploitation challenges. Good targets: a beginner SQL injection challenge or a cookies/authentication challenge. If you've already completed beginner Web Exploitation, push into intermediate.
- Reflection (1 hr): Write the prompts below.
Reflection prompts
-
SQL injection and OS command injection look different but have the same root cause. Describe the root cause in one sentence. Then explain why "input validation" alone (checking that the input looks right) is not a complete defense, and why parameterized queries or prepared statements are required.
-
Credential stuffing attacks use previously-leaked passwords from other breaches. A user who uses the same password on multiple services is vulnerable to this attack even if they have never made a security mistake on your platform. What can a web application do to reduce credential stuffing risk that does not require the user to change their behavior?
-
The OWASP Top 10 was updated from 2017 to 2021. Broken Access Control moved from A05 to A01 (the highest-risk category). What might explain why access-control failures became more prevalent, or at least more detected, between 2017 and 2021? (Hint: consider the shift to single-page applications and REST APIs over that period.)
Week 7 of 14. Next: OWASP Top 10 II (XXE, broken access control, security misconfiguration, XSS).