5.1 - Application and Data Vulnerabilities and Attacks
Application and File Vulnerabilities
Unencrypted File Access
Anyone with access to a device or drive can read unencrypted files outright, whether through physical access (a stolen laptop's drive removed and read on another computer, improperly wiped disposed equipment recovered through dumpster diving, or a lost USB drive), or through network and system access (a compromised account browsing file shares, malware automatically scanning and exfiltrating files, or stolen backup media exposing years of data at once).
Example: a stolen healthcare laptop with no encryption lets an attacker boot from USB, bypass the Windows login entirely (it doesn't matter with physical access), mount the drive, and read thousands of patient records stored as plain Word documents, a serious HIPAA breach. With encryption like BitLocker or FileVault in place, that same stolen laptop's drive simply can't be read without the decryption key, protecting the data even after physical theft.
Administrative Privilege Risks
Standard users have limited permissions, they can access their own files and run approved apps but can't touch system settings. Admin users can modify system settings, access all files, install software, and create accounts. Giving regular users unnecessary admin rights is a real vulnerability, since compromising a standard user contains the damage to that one user's files, but compromising an admin user hands the attacker the whole system, letting them install persistent malware, access everyone's data, create backdoor accounts, and disable security software entirely.
In other words, if a regular user is given admin rights and an adversary compromises that user's account (through phishing or a stolen password, for example), the adversary instantly has elevated privileges on the system. They don't have to find a way to escalate privileges, because the account already has them.
Example: a company gives everyone local admin "for convenience." An employee clicks a phishing link, the malware runs with admin rights, disables antivirus, installs a keylogger in a system directory, harvests credentials from 50 employees, moves laterally using those stolen credentials, and deploys ransomware network-wide. If those same users had only standard privileges, the malware would've been stuck in the user's own profile, unable to disable security software or persist across reboots, keeping the breach far more contained. This is the principle of least privilege in action: give people only the minimum access their role actually needs, and only grant admin rights temporarily when truly necessary.
Weak Access Control Settings
Weak configurations include things like giving the entire "Everyone" group read/write access to sensitive folders, never reviewing accumulated permissions over time, sharing passwords for service accounts, or setting overly broad group access. For example, a payroll folder that should only be accessible to a handful of HR staff and one finance director instead grants read/write access to all 500 employees in the company. This kind of weak control could let a curious employee stumble onto executive compensation data and post it publicly, damaging morale and reputation, or let a disgruntled employee delete critical HR files entirely, especially damaging if there's no backup because nobody thought access control was even a real risk here.
Weak settings on an application's own files cause a third kind of damage: disruption. If every user can edit a web app's configuration file or delete the files it runs from, one careless or malicious user can break the application or take it offline for everyone.
Application Attack Vulnerabilities
Applications are programs that run instructions on a computer, which makes them executable data (data the computer runs, not just stores). Some applications run locally on the user's own computer, like a word processor. Others, like web applications, run on a server, and users reach them over a network through a browser, like an online store or a school's grade portal. Either way, any place an application takes input from a user is a place an adversary can try to feed it something unexpected.
Input Validation Failures
Applications that accept user input (search boxes, forms, comment fields) need to validate that input matches what's actually expected before processing it, like confirming an age field is genuinely numeric and within a sensible range. Applications that skip this validation become vulnerable to injection attacks, where an attacker deliberately submits unexpected characters or strings designed to alter how the program behaves.
This process of verifying that user input meets the expected criteria before processing it is called data validation. For example, a "number of items" box should only accept a whole number, maybe from 1 to 99. If someone types letters, punctuation, or 5,000 characters, the application should reject it and ask for valid input instead of trying to process it. SQL injection and XSS, below, are both injection-type attacks: the adversary inserts unexpected character strings into an input field to change how the program behaves.
SQL Injection Attacks
SQL is the language used to query and modify databases. A vulnerable application might build its database queries by directly concatenating raw user input into the query string, with no validation at all. If an attacker enters something like a username ending in a quote followed by comment characters, that quote can prematurely close the intended string and the comment characters can wipe out the rest of the query (like the password check), letting the attacker log in as an existing user, like an admin, without actually knowing their password at all.
A more advanced version can be used to pull data straight out of the database, like entering specially crafted text into a search field that appends a UNION SELECT statement, causing the application to display usernames, passwords, and even credit card numbers instead of the expected search results.
SQL injection threatens both confidentiality (an attacker extracting the entire database) and integrity (an attacker deleting tables, altering records, changing prices, or creating fake admin accounts). The infamous 2008 Heartland Payment Systems breach started with exactly this kind of vulnerability: attackers got in through SQL injection, then planted malware that captured about 130 million credit card numbers, and the breach ended up costing Heartland around $140 million, all traced back to a simple lack of input validation.
Cross-Site Scripting (XSS) Attacks
Websites are written in HTML (hypertext markup language), which lays out a page's text, images, and links. Many websites also use JavaScript to create dynamic content, like a feed that updates without reloading or a form that checks your input as you type.
JavaScript runs inside a user's own browser with their privileges, meaning it can potentially access cookies (including session tokens), saved passwords, local storage, browsing history, and can make requests as if it were the user. XSS attacks work by injecting malicious JavaScript into a website that then executes in victims' browsers.
Reflected XSS embeds malicious code directly in a link, which executes the moment a victim clicks it, for example a crafted search URL containing a script that sends the victim's session cookie straight to the attacker's server the instant they click, letting the attacker hijack their session.
Stored XSS gets saved on the server itself, like in a comment field or forum post, meaning it affects every visitor who loads that page afterward. For example, an attacker posts a blog comment containing a hidden script; anyone who later views that page has their browser silently run the script and send their session cookie off to the attacker, letting the attacker collect potentially hundreds of stolen session tokens over time to hijack accounts, post as victims, or access private data.
These two types are also numbered: reflected XSS is Type I and stored XSS is Type II. Stored XSS can hide anywhere a site saves what visitors type and shows it to other people, including comment fields, forum posts, and visitor logs.
XSS overall enables session hijacking, credential theft through fake login forms, keylogging, defacement, and even redirecting victims toward malware.
Buffer Overflow Attacks
A buffer is a designated section of memory with a fixed size, set aside to hold data. When an application takes user input, that input gets written to a buffer. If the application doesn't check the size of the input first, an attacker can supply input longer than the buffer's capacity, and the extra data overflows into adjacent memory, overwriting whatever was stored there. For example, if a program reads a password into a fixed 10-byte buffer with no length check, typing 500 characters doesn't just fill the buffer. The other 490 bytes spill into the memory next to it, which can include the value that tells the program where to go next when the current function finishes. If that value gets overwritten with carefully chosen data, the program can end up running the attacker's code instead of its own.
This can cause a simple crash (denial of service), let an attacker run arbitrary code with the vulnerable program's own privilege level, or even lead to full privilege escalation if that vulnerable program happened to be running as admin. The 1988 Morris Worm exploited a buffer overflow to become the first major internet worm, infecting roughly 10% of the internet at the time, and more recently, the 2017 EternalBlue exploit used a buffer overflow in Windows SMB to power both WannaCry and NotPetya, causing billions in damages, despite a patch having already existed.
Directory Traversal Attacks
Web apps organize their files in directory structures on the server, and normal requests fetch specific files from expected locations. A directory traversal attack manipulates a URL, often by inserting sequences like "../" to climb up out of the intended folder, to reach files well outside where the application meant to allow access. For example, a URL meant to fetch a specific report file could instead be modified to climb several directories up and pull something like a system's password file entirely unrelated to the app's own files.
Here's how normal requests work. When you use a web application, your browser sends GET requests using HTTP (hypertext transfer protocol), and each GET request asks for a file somewhere in the server's filesystem. For example, a site might store its images in
/var/www/images/, so a request for photo1.jpg returns /var/www/images/photo1.jpg.In a directory traversal attack, the adversary modifies the URL or GET request so it asks for
../../../etc/passwd instead. Each .. means "move up one directory," so the server walks up like this:Start: /var/www/images/ ../ -> /var/www/ ../ -> /var/ ../ -> / (the root of the filesystem) etc/passwd -> /etc/passwd
Three
.. steps reach the root, and from there the request points at /etc/passwd, the file that lists all the authorized usernames on a Linux server. If the application doesn't check the path, it hands that file over just like it would a photo.Common high-value targets include Windows files like the SAM database (password hashes) or web config files with database credentials, and Linux/Unix files like
/etc/passwd, /etc/shadow, application secret files, or SSH private keys. For example, a vulnerable photo gallery app that normally fetches image files by name could be tricked into instead fetching the application's own database configuration file, exposing database credentials that let the attacker access the database directly and steal all the customer data inside it. Preventing this means validating file paths, stripping out traversal sequences, using a whitelist of allowed files, and never trusting user-supplied input in file operations.Assessing Application and Data Vulnerability Risks
These risks threaten the same three things as always: confidentiality (unauthorized access to data), integrity (data getting altered), and availability (data getting destroyed or locked away, like ransomware).
To rate a risk as high, moderate, or low, look at how sensitive the data is and how likely the exploit is. High risks usually involve highly sensitive data (often data governed by laws or regulations) that could be compromised through a highly likely exploit. Moderate risks usually involve sensitive data that doesn't have strong enough encryption or strict enough access controls. Low risks usually involve less sensitive information that's encrypted with shorter keys or has access controls that aren't strict enough. The three examples below show one of each.
High risk example: highly sensitive jet engine technical specifications stored completely unencrypted on a network drive. Given the network accessibility, lack of encryption, and status as an actively sought target for espionage, likelihood is high, and impact is catastrophic given the potential loss of military technological advantage and billions in compromised R&D, landing this as a high risk where the cost of fixing it (around $50,000 for encryption and access controls) is trivial compared to a virtually incalculable potential loss.
Moderate risk example: a spreadsheet of 100,000 customers' PII protected only by weak, easily crackable 40-bit encryption sitting on a file share. Likelihood is medium, since the data is technically encrypted but that encryption is trivial to break and the file's exposed if the network's compromised, and impact is high, given regulatory fines potentially reaching $2.5 million, identity theft affecting all 100,000 customers, notification costs, and real reputational damage, adding up to an estimated $4 to 5 million in total exposure against maybe $75,000 to properly fix with real database encryption and access controls, a very strong ROI.
Low risk example: a CEO's internal memos sitting unencrypted on a broadly accessible share drive. Likelihood is medium since it's technically accessible to all employees and might contain some sensitive strategic discussion, but impact is low to moderate, limited to potential embarrassment or minor competitive disadvantage rather than any regulatory violation or customer data exposure, landing this as a low risk that might get addressed with simple access restrictions or could reasonably just be accepted given the limited cost-benefit case for anything more elaborate.
A thorough risk write-up for something like a customer portal application might identify SQL injection as critical (highly exploitable, public-facing, huge potential impact), stored XSS in a review section as high (moderate exploitability, real impact on session security), and weak admin panel access controls as moderate (lower exploitability since it needs prior account access, but still meaningful impact if exploited), with fixes prioritized by severity: fixing SQL injection immediately through parameterized queries and input validation, fixing XSS within 30 days through output encoding and a content security policy, and strengthening access controls within 90 days through role-based access and regular reviews, altogether costing a fraction of what an actual breach would run.
Summary
Application and data vulnerabilities let attackers read unencrypted files, abuse excessive privileges, get around weak access controls, inject SQL commands, run malicious scripts through XSS, overflow buffers to execute arbitrary code, and traverse directories to reach sensitive system files. Solid protection comes down to encryption (both at rest and in transit), least privilege, input validation, output encoding, bounds checking, path validation, and regular proactive security testing, with risk assessment weighing sensitivity, exploitability, and impact together to prioritize what gets fixed first.