Frequently targeted web applications include: social media sites, online retailers, and universities. Small-to-medium sized businesses are especially vulnerable as they are often not familiar with the techniques cybercriminals use in a SQLI attack and, likewise, don't know how to defend against such an attack.
With that, let's take the first step in defending against a SQL injection by educating ourselves on the topic. Here's your primer on SQL injections. Developed in the early 70s, SQL short for structured query language is one of the oldest programming languages still in use today for managing online databases. These databases contain things like prices and inventory levels for online shopping sites. When a user needs to access database information, SQL is used to access and present that data to the user.
But these databases can also contain more sensitive and valuable data like usernames and passwords, credit card information, and social security numbers. This is where SQL injections come into play. Put simply, a SQL injection is when criminal hackers enter malicious commands into web forms, like the search field, login field, or URL, of an unsecure website to gain unauthorized access to sensitive and valuable data. Here's an example. Imagine going to your favorite online clothing site.
You're shopping for socks and you're looking at a Technicolor world of colorful socks, all available with a click of your mouse. The wonders of technology! Every sock you see exists in a database on some server somewhere. When you find a sock you like and click on that sock, you're sending a request to the sock database, and the shopping site responds with the information on the sock you clicked. Now imagine your favorite online shopping website is constructed in a slipshod manner, rife with exploitable SQL vulnerabilities.
A cybercriminal can manipulate database queries in such a way that a request for information about a pair of socks returns the credit card number for some unfortunate customer. By repeating this process over and over again, a cybercriminal can plumb the depths of the database and steal sensitive information on every customer that's ever shopped at your favorite online clothing site—including you.
Taking the thought experiment even further, imagine you're the owner of this clothing site. You've got a huge data breach on your hands. One SQLI attack can net cybercriminals personal information, emails, logins, credit card numbers, and social security numbers for millions of consumers. Cybercriminals can then turnaround and sell this personal info on the gloomiest corners of the dark web, to be used for all kinds of illegal purposes.
Stolen emails can be used for phishing and malspam attacks. Malspam attacks, in turn, can be used to infect victims with all kinds of destructive malware like ransomware , adware , cryptojackers , and Trojans e.
Emotet , to name a few. Stolen phone numbers for Android and iOS mobile devices can be targeted with robocalls and text message spam. Stolen logins from social networking sites can even be used to send message spam and steal even more logins for additional sites.
Malwarebytes Labs previously reported on hacked LinkedIn accounts being used to spam other users with InMail messages containing bad URLs spoofed, or faked, to look like a Google Docs login page by which cybercriminals could harvest Google usernames and passwords. The SQL injection exploit was first documented in by cybersecurity researcher and hacker Jeff Forristal. His findings were published in the long running hacker zine Phrack.
Writing under the moniker Rain Forest Puppy, Forristal explained how someone with basic coding skills could piggyback unauthorized SQL commands onto legitimate SQL commands and pull sensitive information out of the database of an unsecured website. When Forristal notified Microsoft about how the vulnerability impacted their popular SQL Server product, they didn't see it as a problem.
As Forristal put it, "According to them [Microsoft], what you're about to read is not a problem, so don't worry about doing anything to stop it. What makes Microsoft's lackadaisical response so shocking is many industries and institutions seriously depended then and now on the company's database management technology to keep their operations running, including retail, education, healthcare, banking, and human resources.
The Russian hackers used SQL injections to hack into the 7-Eleven website and use that as a stepping stone into the convenience store's customer debit card database. This allowed the hackers to then withdraw cash back home in Russia. All told, the culprits made off with two million dollars, as Wired magazine reported. Not all SQLI attacks are motivated by greed. In another noteworthy example from , cybercriminals used SQLI to gain administrative control over two US Army-related websites and redirect visitors to websites with anti-American and anti-Israeli propaganda.
The MySpace data breach ranks as one of the largest attacks on a consumer website. Cybercriminals stole emails, names, and partial passwords of almost million accounts. And this is why we don't reuse passwords from one site to the next. The title for most egregious lack of security goes to Equifax.
The Equifax data breach yielded extremely personal information i. For an organization that acts as the gatekeepers of information for every single American, except those living off the grid, you'd think they would take precautions against a basic SQLI attack. Before the data breach occurred, a cybersecurity research firm even warned Equifax they were susceptible to a SQLI attack, but the credit bureau took no action until it was too late.
In what ranks as the creepiest hack in history, a SQLI attack on toy manufacturer Vtech led to a breach of nearly five million parents and , children. Speaking with Motherboard, the online multimedia publication, the hacker responsible claimed they had no plans for the data and did not publish the data anywhere online. Conversely, the hacker also explained that the data was very easy to steal and someone else could have gotten to it first.
Cold comfort indeed. Moving forward to today, the SQLI attack is still a thing. In the most recent edition , the SQLI attack ranked as number one. SQLI attacks work and will continue to work until people change their attitudes about cybersecurity. Be that change. The stats are not surprising. Businesses with crummy security present criminals with a soft target, holding a treasure trove of valuable data worth millions.
Conversely, a business at the center of a data breach can expect to pay out millions. When the stored strings are subsequently concatenated into a dynamic SQL command, the malicious code is executed. The injection process works by prematurely terminating a text string and appending a new command. Because the inserted command may have additional strings appended to it before it is executed, the malefactor terminates the injected string with a comment mark "--".
Subsequent text is ignored at execution time. The following script shows a simple SQL injection. The script builds an SQL query by concatenating hard-coded strings together with a string entered by the user:. The user is prompted to enter the name of a city. If she enters Redmond , the query assembled by the script looks similar to the following:. The semicolon ; denotes the end of one query and the start of another.
The double hyphen -- indicates that the rest of the current line is a comment and should be ignored. If the modified code is syntactically correct, it will be executed by the server. As long as injected SQL code is syntactically correct, tampering cannot be detected programmatically.
Therefore, you must validate all user input and carefully review code that executes constructed SQL commands in the server that you are using. Coding best practices are described in the following sections in this topic. Always validate user input by testing type, length, format, and range. When you are implementing precautions against malicious input, consider the architecture and deployment scenarios of your application.
Remember that programs designed to run in a secure environment can be copied to an nonsecure environment. The following suggestions should be considered best practices:. Make no assumptions about the size, type, or content of the data that is received by your application. For example, you should make the following evaluation:. How will your application behave if an errant or malicious user enters a megabyte MPEG file where your application expects a postal code? Test the size and data type of input and enforce appropriate limits.
This can help prevent deliberate buffer overruns. Test the content of string variables and accept only expected values. Reject entries that contain binary data, escape sequences, and comment characters. This can help prevent script injection and can protect against some buffer overrun exploits.
In multitiered environments, all data should be validated before admission to the trusted zone. Data that does not pass the validation process should be rejected and an error should be returned to the previous tier. Implement multiple layers of validation. Precautions you take against casually malicious users may be ineffective against determined attackers.
A better practice is to validate input in the user interface and at all subsequent points where it crosses a trust boundary. For example, data validation in a client-side application can prevent simple script injection. However, if the next tier assumes that its input has already been validated, any malicious user who can bypass a client can have unrestricted access to a system.
Never concatenate user input that is not validated. String concatenation is the primary point of entry for script injection. If you use the Parameters collection, input is treated as a literal value instead of as executable code. An additional benefit of using the Parameters collection is that you can enforce type and length checks. Values outside the range will trigger an exception. The following code fragment shows using the Parameters collection:.
This value is checked for type and length.
0コメント