5.1: Application and Data Vulnerabilities and Attacks

Essential Questions

• How can an attacker access sensitive files on a system even without knowing your password?
• What is an “injection” attack, and how does it trick an application into revealing secrets?
• Why is letting a user type anything they want into a website’s search box a potential security disaster?
• How does an attacker use a simple URL to look for files they should not be able to see?
• When is a data breach considered a “high risk” versus a “low risk”?

Overview

Imagine you’re using your favorite social media app. You upload a photo, add a caption, and hit “post.” Behind the scenes, the app takes your caption and saves it to a database. But what if, instead of a caption, you typed a command that the database understood? What if you could trick the app into deleting other people's photos or, even worse, revealing their private messages? This is the world of application and data vulnerabilities. It’s not about guessing passwords; it’s about manipulating the very logic of the software to make it misbehave.

In this lesson, you’ll learn how adversaries turn everyday application features—like search bars and login forms—into weapons. We’ll explore how unencrypted files, poorly configured permissions, and a failure to validate user input can open the door to devastating attacks. You’ll see how techniques like SQL injection, cross-site scripting (XSS), and buffer overflows work in practice. Finally, you’ll learn to think like a security professional, assessing the potential impact of these vulnerabilities to understand which ones pose the greatest risk to an organization’s precious data.

Exploiting Application and File Vulnerabilities (5.1.A)

At the most basic level, data is just information stored in files, and applications are the tools we use to interact with those files. But if an attacker can bypass the application, they can often get to the data directly. The simplest way is by gaining access to the device where the files are stored. If your research paper is on a laptop and an adversary gets access to that laptop, they can read the paper if it isn't encrypted, regardless of any application passwords.

This risk extends beyond physical theft. When user accounts on a computer system are not properly managed, they create vulnerabilities. Computers distinguish between standard users, who have limited permissions, and administrative users, who can change system settings and access almost any file. If a regular user account is given administrative privileges unnecessarily—a common mistake made for convenience—it becomes a prime target. If an adversary compromises that single "over-privileged" account, they effectively gain the keys to the entire kingdom, able to read, modify, or delete any data on the system.

Weak access control settings are another common vulnerability. Imagine a shared network drive where every employee can see every file, including sensitive HR documents and financial records. An attacker who compromises any single employee's account can now access a treasure trove of data. Properly configured access controls ensure that users can only access the specific files and applications necessary for their jobs, a concept known as the "principle of least privilege."

How Application Attacks Exploit Vulnerabilities (5.1.B)

Application attacks are clever ways of tricking software into doing things it was never intended to do. Many of these attacks exploit a single, fundamental weakness: the application trusts user input too much. Developers should always treat input from users as potentially hostile and validate it to ensure it meets the expected format and type. When they fail to do so, they open the door to a variety of "injection" attacks.

SQL Injection (SQLi): Many web applications use a database to store information, and they use a language called Structured Query Language (SQL) to talk to that database. For example, when you log into a site, the application might use SQL to ask the database, "Does a user named 'Alice' with the password 'password123' exist?" An SQL injection attack involves inserting SQL commands into an input field. For instance, an attacker might enter ' OR '1'='1 as their username. If the application isn't validating input, the database might see the query as "Find a user where the name is '' OR '1'='1'". Since '1'='1' is always true, the database might grant access without a valid password.

-- A legitimate query
SELECT * FROM users WHERE username = 'Alice' AND password = 'password123';

-- A query vulnerable to SQL injection
SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = '...';
-- The '--' at the end is a comment in SQL, ignoring the rest of the original query.

Cross-Site Scripting (XSS): Websites are built with HTML, and they often use JavaScript to make pages interactive. An XSS attack injects malicious JavaScript code into a website, which then runs in the browsers of other users who visit the page. For example, an attacker could post a comment on a blog that contains a hidden script. When you view that blog post, the script runs on your computer, potentially stealing the cookies your browser uses to keep you logged in, allowing the attacker to impersonate you.

Buffer Overflow: Applications use a temporary storage area in memory called a buffer to hold data, such as user input. A buffer has a fixed size. A buffer overflow attack occurs when an attacker intentionally sends more data than the buffer can handle. This extra data "overflows" into adjacent memory areas, potentially overwriting critical instructions. A successful overflow can crash the system or, in a more sophisticated attack, trick the computer into running malicious code provided by the attacker, giving them control over the machine.

Directory Traversal: Web applications store their files in directories on a server. A directory traversal attack uses manipulated URLs to access files outside of the intended web root directory. For example, an attacker might change a URL from http://example.com/view.php?file=image.jpg to http://example.com/view.php?file=../../../../etc/passwd to try and access a sensitive system file.

Assessing and Documenting Risks (5.1.C)

Not all vulnerabilities are created equal. A security professional must assess the risk posed by each vulnerability to prioritize which ones to fix first. Risk is generally a combination of two factors: the likelihood that a vulnerability will be exploited and the impact that would result from a successful exploit.

The impact is often measured by the harm to confidentiality, integrity, or availability (the "CIA triad").

• Confidentiality: Could an attacker access sensitive data?
• Integrity: Could an attacker alter or manipulate data?
• Availability: Could an attacker destroy data or prevent legitimate users from accessing it?

Risks can be categorized as high, moderate, or low.

• High Risk: These are vulnerabilities that are likely to be exploited and would cause severe damage. For example, storing unencrypted technical specifications for a new military jet engine on a publicly accessible server is a high risk. The data is extremely sensitive (high impact), and the lack of security makes an attack highly likely.

• Moderate Risk: These vulnerabilities involve sensitive data that is not protected adequately. For example, a company storing its customers' Personally Identifiable Information (PII) in a spreadsheet that is encrypted with a weak, easily guessable password. The impact of a breach would be significant, but an attacker would still need to get the file and crack the password.

• Low Risk: These involve less sensitive information or vulnerabilities that are harder to exploit. For example, an internal company memo being stored on a shared drive with overly broad access controls. While it's not ideal (a breach of confidentiality), the impact is likely limited to internal embarrassment rather than catastrophic financial or legal damage.

Documenting these risks in a structured way, often in a risk register, is a critical step. This allows an organization to track vulnerabilities, assign resources to fix them, and make informed decisions about where to focus their security efforts.

Further Reading & Resources

• OWASP Top Ten Project
• A Guide to Buffer Overflow Attacks
• SQL Injection Prevention Cheat Sheet
• Cross Site Scripting (XSS) Explained

References

• NIST Special Publication 800-30: Guide for Conducting Risk Assessments
• The Privacy Act of 1974