[Figure: FiveStudy logo]
FiveStudy
Cybersecurity · Unit 5 · 5.1.b
AP Cybersecurity · Securing Applications and Data
How Application Attacks Exploit Vulnerabilities
All four are the same failure: user input treated as instructions instead of data.
key ideaAll four are the same failure: user input treated as instructions instead of data.
The categories
Applications are programs that run instructions on computers — they are executable data. Many take user input through open-ended input fields, and developers should include user input checks. Where those checks are missing, the four attacks below follow.
The four differ only in where the unvalidated input lands. That is also the shape of the defense: validate and sanitize input before it reaches any interpreter — a query, a browser, a buffer, or a file path.| Attack | Where the input goes | What the adversary achieves |
|---|
| SQL injection | into a database query built from unvalidated input | a breach of confidentiality — the application returns more information than intended |
| cross-site scripting (XSS) | into a page another user's browser executes | malicious code runs in the victim's browser session |
| buffer overflow | beyond a buffer — a fixed-size section of memory | a crash, or code executed outside the program’s security policy |
| directory traversal | into a file path via a modified URL or GET request | access to sensitive data on the server’s file system — usernames, passwords |
Note what SQL injection actually yields: the application returns more information than it was designed to. The adversary never breaks in — they ask a question the application answers too fully.
ApplicationA program that runs instructions on a computer — executable data. Some run locally, others, like web applications, on a server.
SQLA language used to request information from databases and make changes to them. Applications querying with unvalidated input are vulnerable to injection.
JavascriptUsed to create dynamic content on websites. Because its commands run in the browser, injected script executes on the victim's machine.
BufferA designated section of computer memory with a fixed size. Input exceeding it overflows into adjacent memory.
GET requestHow a browser asks for a resource over HTTP. Modifying it is how directory traversal reaches unintended files.
Telling them apart
the deciding question
- Does the input reach a database? → SQL injection.
- Does it reach another user’s browser? → XSS — reflected via a clicked link, or stored on the site.
- Does it exceed a fixed-size memory region? → buffer overflow.
- Does it alter a URL or file path? → directory traversal.
A querySQL injection
A browsercross-site scripting
Memory or a pathoverflow or traversal
Worked examples
EX 1
Input that becomes a command
A login form passes what the user types directly into a database query. What is the attack, and what does it yield?
1
Identify the missing check
No user input validation before the input reaches the query.
2
Name the attack
SQL injection — placing SQL commands and control characters into a user-input field.
3
State the mechanism
The database cannot tell data from instructions, so it executes what was typed.
4
State the result
A breach of confidentiality: the application returns more information than intended, and the database can also be changed.
5
Give the defense
Validate and sanitize input before it ever forms part of a query.
EX 2
Two kinds of XSS
Distinguish the XSS variant delivered in a link from the one that lives on the site.
1
Name the first
Type I, reflected XSS — the malicious code is embedded in a link the user clicks.
2
Name the second
Stored XSS — the code is saved on the site and served to every visitor.
3
State the shared mechanism
Injected code that a user’s browser then executes, because Javascript runs in the browser.
4
Compare the reach
Reflected needs a victim to click; stored affects everyone who views the page.
5
Give the defense
Sanitize input before storing or reflecting it, so it is rendered as text rather than executed as script.
EX 3
Memory and file paths
Compare a buffer overflow with a directory traversal attack.
1
Describe the overflow
More data is fed into memory than was allotted to a fixed-size buffer.
2
State its two outcomes
The system crashes, or code executes outside the scope of the program’s security policy — effectively giving the adversary control.
3
Describe the traversal
Adversaries modify URLs and GET requests to reach files outside the intended directory.
4
State its outcome
Access to sensitive data on the server’s file system, such as usernames and passwords.
5
Note the shared root
Both treat user-supplied input as a trusted instruction — one about memory size, one about file location.
Watch out
Every one of these is an input-validation failure
The CED is explicit: developers should include user input checks. The four attacks differ in destination, not in root cause.
XSS runs in the victim's browser, not on the server
Javascript commands run in the browser. The server's role is to have served the injected code — the execution happens on the user's machine.
A buffer is a fixed size, and that is the whole vulnerability
Input exceeding it overflows into adjacent memory, which is how a crash becomes code execution outside the program's security policy.
Directory traversal needs no exploit code
It is a modified URL. That simplicity is why unvalidated path input is such a common and serious finding.