How a Small Security Flaw Can Lead to Massive Data Breach
Web Exploitation · Published December 17, 2024 · 8 minute read
Everything Online Is Vulnerable. This is how Attackers Exploit SQLi to Expose Your Personal Information
Blog 2 — cover.jpg
Introduction
Every time you create an account online, make a purchase, or sign up for a service, you're trusting companies with pieces of your personal information. Your name, address, phone number, and sometimes even more sensitive details like financial information become part of their digital records. They don't know that nothing is secure when they enter the internet, even the safest system could break.
In my recent bug hunting activity, I discovered several critical vulnerabilities that could exposed thousands of students' personal data in X University. What's concerning about this vulnerability is that it wasn't hidden in some obscure corner of the system. It was sitting in plain sight, in a place where users regularly interact with the website. Through an SQL injection technique, any attacker with basic knowledge could have potentially accessed the university's entire database.
Anyway if u tired reading the whole article and its concept, u can skip to Proof of Concept to see me in action, But if u want to directly see some Facts, jump in to the Findings section!
How does the Database works?
Before we dive into what I discovered, let's understand how websites handle user inputs when they interact with the system. Every time you fill out a form online like username and password, the website takes these inputs and prepares it to be sent to its database, which is stored on secure servers.
Blog 2 — input\-flow.png
Every website you use relies on databases to store information. These databases are organized into tables, similar to spreadsheets. One table might contain user information with columns for usernames, passwords, email, and other personal details. Another table might store your activity history, preferences, or other data specific to the service. For example, when you log in, the query might look something like this :
The database then processes this request, searches through its records, and sends back an answer. If it finds a match, you're logged in. If not, you get an error message saying your login details are incorrect.
SQL Injection Attack Flow
Now here's where things can go wrong. Many websites trust that users will only type normal usernames and passwords into forms. But what if someone types in special characters and commands that are part of the SQL language itself? This is where SQL Injection becomes possible. It's like if you were filling out a login form, and instead of just writing your account credential, you could somehow add extra instructions that trick the system into showing you everyone else's account information too.
Blog 2 — sanitazion.png
The image illustrates two scenarios of how a web application handles a search query containing malicious input. In the properly sanitized version, the search system treats the input as literal text to search for. When the query reaches the database, all the special characters and SQL syntax are escaped and treated as regular text that should be matched against the database entries.
As a result, the system looks for records containing the exact phrase ' OR '1'='1, and naturally finds no matches since this isn't a normal piece of text that would exist in legitimate records. This is the correct and secure behavior. The system is treating user input as data, not as code. However, the bottom scenario reveals a dangerous vulnerability where the input isn't properly sanitized.
When the same search term ' OR '1'='1 is processed by this vulnerable system, something different happens. The DB interprets this input as part of the SQL query's logic rather than as search text. The first quotation marks in the input break out of the intended query structure, and the OR '1'='1' portion adds a new condition that is always TRUE. The impact of this vulnerability is instead of finding no results, the search returns multiple "Search Result" entries.
Blog 2 — failed\-sanitazion.png
This happens because the condition '1'='1' is always TRUE in SQL logic, telling the database to return all records regardless of what they contain, and since the second part is always TRUE, you get everything. What makes this more dangerous is that an attacker who discovers this behavior can modify their injection payload to do much more than just return all search results. This means they could steal usernames, passwords, email addresses, and any other sensitive information stored there. Even worse, since many people reuse passwords across different websites, a breach at one site could lead to compromised accounts on other platforms.
The vulnerability I discovered was exactly this type of security flaw. The website wasn't properly checking and cleaning up what users typed into one of its forms before sending that information to the database. This meant that anyone who understood SQL Injection could potentially manipulate the website's database queries to expose sensitive user information.
Proof of Concept
Before diving into the technical details of this discovery, I want to emphasize that what you're about to read describes a security vulnerability that has been fully patched, so you can't exploit the same way i tried in this blog. Okay, the first step was understanding what I was dealing with. Every website has different technology stack. I discovered that the X university's web was running on Oracle database.
Next, I started with the search functionality. My testing progression went like this: First, I entered a normal search:
This returned expected results about student resources. Then, I tried a simple test payload:
Blog 2 — poc1.png
Something unexpected happened. Instead of seeing a few relevant results , it returned more results from A to Z. To confirm this wasn't a false positive, I tried another test:
This time, I got zero results because '1'='2' is always FALSE. The different responses to these inputs confirmed that the application was directly embedding my search terms into its SQL queries without proper sanitization. After confirming the vulnerability through manual testing, I moved to an automation tool using SQLMap. I began by capturing search request from the university's website using BurpSuite Interceptor. This request was saved to a file named request.txt.
Since I already knew the system used Oracle from our reconnaissance, I specified --dbms=Oracle to ensure our tests efficient. Next, i use sqlmap to automate the process
Blog 2 — poc2.png
When I ran this command, the results were concerning. Sqlmap was able to mapping out the structure of the X university's database. I immediately halted the testing at this point. Finding the database schemas was enough to confirm the severity of the vulnerability without risking any damage to the systems.
The X university's security team later confirmed that the vulnerability has been completely patched. They implemented proper input validation, query parameterization, and additional security layers to prevent any such SQL injection attacks in the future. This is why I can now share these technical details.
Findings
Blog 2 — findings1.png
Perhaps the most alarming discovery was that some DB tables stored passwords in PLAIN TEXT meaning they weren't even encrypted or hashed. When I verified these credentials on the website, they worked perfectly, confirming that these were actual, active passwords.
Blog 2 — findings2.png
In modern security practices, passwords should always be stored using strong hashing algorithms, making them unreadable even if someone gains database access. The fact that I could see these passwords in clear text means that anyone who gained access to this database could potentially log into users' accounts.
The ability to spawn an SQL shell and execute SELECT queries is especially troubling. While I didn't attempt destructive queries (INSERT, UPDATE, DELETE) for ethical reasons, the possibility of threat actors to not only view sensitive data but potentially modify or destroy it poses a severe risk.
Blog 2 — findings4.png
One of the most concerning discoveries was that some of these plaintext passwords worked on other web platforms (password reuse). When students use the same password across multiple services, a breach in one system can lead to compromised accounts everywhere.
The discovery of password reuse among students reveals a critical need for better security awareness. Your account password should be unique and never used for other services. Why? Because even if other platforms properly secure your password, using the same password across services means a breach anywhere becomes a breach everywhere.
Blog 2 — findings5.png
As we conclude this journey, I want to leave you with some important reflections. When I discovered this findings, I had access to sensitive information that could have affected real people's lives: ID cards that determine futures, financial data that impacts livelihoods, and personal information that could be exploited for malicious purposes. I want to be clear, I never used this access for personal gain or malicious purposes. They were used to fix problems and raise awareness about the importance of data privacy.
Conclusion
While we often read about data breaches affecting large companies, this case demonstrates that privacy risks exist in places we trust the most, which is our campus institutions. This was a university system containing the personal information of thousands of students, faculty, and staff.
People who walk the same halls I do every day. People who trust the institution with their sensitive data, future prospects, and digital security. The vulnerability I discovered could have exposed their grades, personal information, and even their passwords which, as I found, many reused across different platforms.
But this story isn't meant to spread fear. Instead, it should serve for change in how we think about our privacy. Every time you create an account, share personal information, or reuse a password, you're making decisions that affect your data privacy. The vulnerability in this university's system has been fixed, but somewhere, right now, similar vulnerabilities exist in other systems holding your personal information.
The good news is that you have the power to protect yourself. Use unique passwords for every account. Be mindful of what information you share and where you share it. Privacy isn't about having something to hide. It's about having something to protect. And in our world, we all have something worth protecting.
\- Wzrd.