AP® Cybersecurity review sheet from Aim for Five (aimforfive.com/cybersecurity/units/5/5-1)
Unit 5 · Topic 5.1
5.1 Application and Data Vulnerabilities and Attacks
Data is often what an adversary is really after, and applications are the doors to it. This topic covers the file and permission weaknesses that expose data, four application attacks that abuse unchecked user input (SQL injection, cross-site scripting, buffer overflow and directory traversal), and how to rate data risks.
Key terms
- data validation
- SQL injection
- cross-site scripting (XSS)
- buffer overflow
- directory traversal
- administrative privileges
Weak spots that expose files
- Unencrypted files: anyone who gets access to the device or drive can read them.
- Too many admin rights: administrative users can change system settings and open nearly any file or program. If regular users are given admin privileges and an adversary takes over one of their accounts, the adversary gets those elevated privileges too.
- Weak access controls: when permissions are loose, many users can view or even edit files they don't need. Adversaries use that to steal or destroy files or disrupt applications.
Why user input is dangerous
An application is a program that runs instructions on a computer. Some run on your own device; web applications run on a server you reach over a network. Many take input through open text fields.
Data validation means checking that input matches what's expected before using it, such as accepting only digits in a quantity field, and rejecting anything else. Applications that skip this are open to injection attacks, where an adversary types unexpected characters into a field to change what the program does.
Four application attacks
- SQL injection. SQL (structured query language) is the language applications use to read and change databases. If an app builds a database command from unchecked input, an adversary can type SQL commands and control characters, like a quote mark, into a field. The database may then return far more data than it should (a confidentiality breach) or change or delete data (an integrity breach).
- Cross-site scripting (XSS). Websites are written in HTML and often use JavaScript, which runs in the visitor's browser and can reach data stored there, like usernames, passwords and cryptographic keys. In XSS, an adversary gets malicious code into a website so visitors' browsers run it. In reflected XSS (Type I), the code rides in a link the victim clicks. In stored XSS (Type II), it's saved on the site, in a comment, forum post or visitor log, and hits everyone who views that page.
- Buffer overflow. Input goes into a buffer, a fixed-size block of memory. If the input is longer than the buffer, it spills into neighboring memory and overwrites it. An adversary who sends too much data on purpose may crash the system or make it run code outside the program's security rules, letting them read, change or delete files.
- Directory traversal. A web app's files live in folders on a server, and a browser asks for them with HTTP GET requests. In a directory path, ../ means go up one folder. By adding ../ sequences to a URL, an adversary tries to climb out of the website's folder and reach sensitive files elsewhere, like the server's list of user accounts.
Rating data risks
Data risks hit confidentiality (unauthorized people read it), integrity (it's altered) or availability (it's destroyed or encrypted so no one can use it).
| Rating | Pattern | Example |
|---|---|---|
| High | Highly sensitive data, often covered by laws, exposed to a likely exploit | A defense contractor keeps secret engine designs on an unencrypted drive |
| Moderate | Sensitive data with weak encryption or loose access controls | A store's customer contact list is encrypted, but with a very short key |
| Low | Less sensitive data with short keys or loose access controls | A club's meeting-room schedule sits on a shared drive anyone in the office can edit |
Worked examples
Try each one yourself first, then open the solution.
- Example 1
Naming the application attack
Identify the attack: (a) A forum lets users post comments without filtering them. After one user's post, everyone who opens that thread has their session data sent to an unknown site. (b) A shipping site's tracking page accepts a file name in its URL; an adversary changes it to a path full of ../ sequences. (c) A login field built to hold 64 characters receives a 6,000-character username, and the server crashes.
Show the solutionHide the solution
- Step 1: (a) Code was saved on the site in a comment and runs in every visitor's browser. That's stored (Type II) cross-site scripting.
- Step 2: (b) The ../ sequences try to climb out of the web folder to reach other files on the server: directory traversal.
- Step 3: (c) Far more data than the memory set aside for it, causing a crash: a buffer overflow attempt.
Answer: (a) Stored (Type II) XSS. (b) Directory traversal. (c) Buffer overflow.
- Example 2
Counting ../ steps
A web server keeps product photos in /var/www/html/photos/. An adversary requests a photo path that begins with ../ sequences, trying to reach /etc/passwd. How many ../ steps does it take to get from the photos folder to the root folder (/), and what does that tell a defender reading logs?
Show the solutionHide the solution
- Step 1: Each ../ moves up one folder. Start in /var/www/html/photos.
- Step 2: One step reaches /var/www/html; two reach /var/www; three reach /var; four reach / (the root).
- Step 3: From the root, the adversary would then name etc/passwd, a file that lists the system's user accounts.
- Step 4: For a defender: any request containing a run of ../ sequences, especially aiming at system folders like /etc, is a sign of attempted directory traversal.
Answer: Four ../ steps. Repeated ../ sequences in a request, especially aimed at system files like /etc/passwd, indicate a directory traversal attempt.
Common mistakes
- Mixing up SQL injection and XSS. SQL injection targets the database on the server; XSS runs code in other users' browsers.
- Swapping reflected and stored XSS. Reflected (Type I) travels in a link one victim clicks; stored (Type II) is saved on the site and hits every visitor.
- Thinking directory traversal needs a password. It abuses the web server's own file requests to reach files outside the web folder.
- Forgetting that giving users admin rights is a vulnerability. A compromised admin-level account hands the adversary elevated privileges.
On the exam
- Expect short scenarios or snippets that ask which attack is happening. Use the giveaway: database commands in a field (SQL injection), script code that runs for visitors (XSS), oversized input (buffer overflow), ../ in a path (directory traversal).
- When explaining how an attack works, connect it to the missing control, usually data validation of user input.
Connected topics
Videos
Check yourself: 5.1 Application and Data Vulnerabilities and Attacks
4 questions on 5.1 Application and Data Vulnerabilities and Attacks. Pick an answer to see if you got it, and why.
An adversary steals a backup drive from a company's office. The drive is not encrypted. What can the adversary do with the files on it?
At a small company, every employee's account has administrative privileges on their laptop. An adversary steals one employee's password through phishing. Why is this especially dangerous?
A school's shared drive lets every student and staff member view and edit every folder, including the folder of upcoming exams. Which risk does this most directly create?
An online store's order form has a field for how many items to buy. Which check is an example of data validation?
0 of 4 answered