Section 6.4 SQL Injection
As you study this section, answer the following questions:
- What is Structured Query Language (SQL) injection?
- Why are SQL attacks common?
- What are the SQL methodology steps?
- What measures can you take to actively defend against SQL injection attacks?
In this section, you will learn to:
- Exploit SQL on a web page
- FindSQL injection flaws with sqlmap
- Explore SQL injection flaws
- Detect SQL injection flaws with Burp Suite
The key terms for this section include:
Key Terms and Definitions
| Term | Definition |
|---|---|
| Remote code execution | A common form of cyber attack where the attacker inserts code through a data entry point created for regular users. |
| SQL injection | A specific type of remote code execution attack where an attacker can exploit input fields that are not validated and send SQL commands through the web application to the database. |
| Web applications | Applications that run on a web server, which can be accessed by a user's web browser over the internet. |
| Structured Query Language (SQL) | A language designed to manage and manipulate databases. SQL requests are called queries. |
| Relational database | A type of database that organizes data into tables that can be linked—or related—based on data common to each. |
| Authentication bypass | A type of SQL injection attack used to log into an application with administrative-level privileges without the required username and password. |
| Compromised data integrity | A type of SQL injection attack used to deface a web page by inserting malicious content onto the web page or altering the contents of the database. |
| Information disclosure | A type of SQL injection attack used to obtain sensitive data from a database. |
| Compromised availability of data | A type of SQL injection attack used to remove information from a database, delete logs, or alter information stored in a database. |
| Blind SQL injection | A type of SQL injection attack used to ask true/false questions to perform reconnaissance. This can be used when other types of SQL injection attempts fail. |
| Second order SQL injection | A type of SQL injection attack that causes destruction from a secondary query. A query fragment is injected in a user input field. The fragment is then executed in a second query that lacks validation. |
This section helps you prepare for the following certification exam objectives:
| Exam | Objective |
|---|---|
| CompTIA CySA+ CS0-003 | 2.2 Given a scenario, analyze output from vulnerability assessment tools
2.4 Given a scenario, recommend controls to mitigate attacks and software vulnerabilities
|
| TestOut CyberDefense Pro | 2.1 Perform threat analysis
|
6.4.1 SQL Injection
Click one of the buttons to take you to that part of the video.
SQL Injections 00:00-00:19 In this lesson, I'm going to discuss remote code execution and one specific type of attack we call SQL injection. Remote code execution, or code injection, is a very common form of cyberattack and one of the most damaging.
Remote Code Execution 00:19-00:33 There are many ways attackers do this, but basically all methods include attackers inserting their own code through data entry points created for regular users in such a way that the server accepts the malicious code as legitimate.
SQL injection 00:33-00:53 If an attacker can get a target's server to execute the malicious code, he or she can do all kinds of damage. To better understand how this works, let's take a closer look at how SQL injection occurs. These attacks are powerful and complex, and they're behind many successful high-profile internet security breaches.
SQL Injection Attacks 00:53-01:46 For example, in 2011, Sony was targeted by a SQL injection attack that compromised over one million emails, usernames, and passwords. In 2013, the U.S. Department of Energy was targeted, and at least 100,000 employee records were compromised. These records included contact information, social security numbers, and even bank account numbers. Perhaps the most ironic attack occurred when mysql.com was attacked, releasing a large list of usernames and passwords to hackers. In each of these instances, the vulnerability wasn't in the SQL software but in the way the websites and applications were implemented. Each of these attacks could've been prevented with careful front-end configuration. Now, because SQL injection attacks target web applications, let's review how they work as well.
Web Applications 01:46-02:11 When a user connects to a web application, they make the initial request through the browser. This request travels over the internet to the web server. The web server accepts the request and sends it to the corresponding web app. The web app accesses the database, completes the requested task, and then responds back. Once the transaction is complete, the web server sends the requested information to the user's browser.
Databases 02:11-03:30 Motivation for a SQL injection attack is often the information that's stored in the application's database. Databases hold a variety of information, such as application details, configuration data, customer information, login credentials, and more. And there are different types of databases based on how the data is stored.
SQL was specifically designed to request data from a relational database with requests called queries. A relational database is a storage bank for data that's organized in tables that are linked by keys, which are unique identifiers. With these keys, data in tables can be searched and sorted through multiple parameters.
It's important to note once again that SQL injections are the result of flaws in web applications, not in the database or web server. These attacks exploit input fields that aren't validated and use them to send SQL commands through the web application to the database. Code can be added to the existing code before it's sent to the database and executed. If the injection is successful, the malicious code runs on the back-end database and returns the requested information. Let's look at a very basic example to see how this works.
How SQL Injections Work 03:30-04:16 Let's say Bob Smith is logging into his account. Normally, Bob enters his username—bobsmith—and password—secret—into the appropriate spaces. Once he clicks Submit, the web application sends a string to the web server that contains the credentials. The command tells the database to check for the provided username and compare it to the stored password before granting access. Assuming Bob's credentials are found, he's directed to the requested page. As you can see in this example, the data that Bob entered is put into the same query as the commands. As a result, this code is susceptible to SQL injection attacks. If the programmer didn't restrict the login fields, an attacker could add any code to them.
SQL Injection Example 04:16-05:18 Let's say the attacker knows Bob's username but not his password. He or she might be able to enter bobsmith'-- in the username field. The single quote mark indicates that the data has ended, and a command is beginning. The double dashes indicate that the code is ending and a comment is being entered. Comments are code that the program doesn't execute. They usually contain explanations or reminders for the programmer. Because of this, the application knows to ignore the comments. Now, because the command treats everything after the dashes as comments, the instruction to verify the username with the corresponding password is no longer visible, and the attacker is granted access to Bob's account.
This was just a basic example, but most SQL injection attacks are extremely complex and require a high level of database and coding expertise. The work involved in a successful SQL injection is paid off with big rewards of data or money, though.
SQL Injection Attack Types 05:18-07:03 Let's briefly review some of these more complex attacks. First, is our example of Bob Smith. That attack process is called an authentication bypass attack. When an attacker attempts an authentication bypass, he or she logs into an application with administrative privileges without having to provide valid credentials. Imagine Bob in our previous example is an administrator, and now the attacker has administrative privileges just like Bob.
The next kind of SQL injection attacks, which are called compromised data integrity attacks, focus on altering a database's data in order to deface or damage a website. An information disclosure attack is focused on obtaining sensitive data from the database. This could be anything from credentials to finances to personal account information. Really, it's anything that a large database could potentially contain. Another form of this attack, called a compromised availability of data attack, focuses on deleting or altering data.
A blind SQL injection is an even more complex attack. An attacker might try this if they're unsuccessful with their initial SQL injection. A blind SQL injection performs reconnaissance or alters authentication credentials. For example, an attacker asks true or false questions to determine the information he or she is seeking. And finally, we have a second order SQL injection. This attack gets its name because its destruction comes from a secondary query. This can be accomplished by injecting a query fragment into a user-input field and then having that fragment execute in a secondary query that lacks validation.
Summary 07:03-07:19 That's it for this lesson. In this lesson, we talked about remote code execution through SQL injections. We discussed how SQL injection attacks work and looked at several types.
6.4.2 SQL Injection Facts
Remote code execution, also known as code injection, is a common form of cyber attack and one of the most damaging. The attacker inserts code through a data entry point created for regular users. The malicious code is entered in a way that the server accepts the code as legitimate. SQL injection is a specific type of remote code execution attack.
This lesson covers the following topics:
- Web applications
- Structured Query Language (SQL)
- SQL injection
Web Applications
Because SQL injection attacks target web applications, it is important to understand how web applications work. The web application process is typically:
- A user connects to a web application and makes a request through the browser.
- The request goes over the internet to the web server.
- The web server accepts the request and sends it to the corresponding web application.
- The web application accesses the database, completes the requested task, and responds to the web server.
- The web server sends the requested information back to the user's browser.
Structured Query Language (SQL)
SQL injection attacks most often target information stored in the application's database. Important facts to know about databases and SQL are:
- Databases store a variety of information, such as:
- Application data
- Configuration data
- Customer data
- Login credentials
- Key points to remember about databases are:
- A database is named based on how its data is stored.
- A relational database is a storage bank for data organized in tables linked by a key.
- Keys are unique identifiers.
- Because the tables are connected through keys, they can be searched and sorted by multiple parameters.
- SQL was specifically designed to request data from a relational database.
- SQL requests are called queries.
SQL Injection
Key points to remember regarding SQL injection attacks are:
- An attacker can exploit input fields that are not validated.
- The attacker sends SQL commands through the web application to the database.
- An attacker can add code to the existing code before it is sent to the database and executed.
- The malicious code runs on the backend database and returns the requested information. SQL injections are the result of web application flaws, not flaws in the database or server.
A simplified scenario of SQL injection is:
- The login fields have not been restricted. Therefore, an attacker can add any characters to the fields.
- The attacker knows the username but not the password. The attacker enters username"-- in the username field.
- The quotation mark indicates that data has ended and a command is beginning.
- The double dashes indicate that code is ending and a comment is being entered. Comments are code that a program does not execute. They are usually used for explanations or reminders for the coder.
- Because everything after the double dashes is treated as comments, the command to verify the username with a given password is no longer visible. The attacker is granted access to the user account.
This is a basic scenario. Most SQL injection attacks are extremely complex and require a high level of database and coding expertise. The work involved in a successful SQL injection is paid off with big rewards. That is the draw for attackers.
The following table lists some types of SQL injection attacks.
| Type | Description |
|---|---|
| Authentication bypass | SQL injection is used to log into an application with administrative-level privileges without the required username and password. |
| Compromised data integrity | SQL injection is used to deface a web page by inserting malicious content onto the web page or altering the contents of the database. |
| Information disclosure | SQL injection is used to obtain sensitive data from a database. |
| Compromised availability of data | SQL injection is used to remove information from a database, delete logs, or alter information stored in a database. |
| Blind | Blind SQL injection is used to ask true/false questions to perform reconnaissance. This can be used when other types of SQL injection attempts fail. |
| Second order | Second order is a SQL injection attack that causes destruction from a secondary query. A query fragment is injected in a user input field. The fragment is then executed in a second query that lacks validation. |
6.4.3 SQL Injection Attack Types
Click one of the buttons to take you to that part of the video.
SQL Injection Attack Types 00:00-00:30 As a cyber defense analyst, you'll be better able to defend against SQL injection attacks if you personally have been through the process of conducting a variety of these attacks. Remember that a SQL injection attack is where an attacker gets a target web server to execute some malicious code by exploiting input fields that aren't properly validated. In this lesson, I'll discuss the methodology of these attacks and review some SQL injection attack types.
Information Gathering 00:30-01:00 The SQL injection methodology has four phases. The first phase is information gathering. The more information you collect in this phase, the more time you save throughout the process. To do this, first determine if the web application is connected to a database server. Next, inject code into fields to discover any error messages. And finally, review these error messages carefully for pertinent information about the operating system, database type, database version, and privilege level.
Vulnerability Testing 01:00-01:58 The second phase is testing for SQL injection vulnerabilities. You can use function testing, which requires little knowledge of the code's inner design logic. Function testing can be as simple as adding a tick mark at the end of a URL. If an error is returned, the web application might be vulnerable to a SQL attack.
Static and dynamic testing involve an analysis of the web application's source code and various tests for vulnerabilities. You can do this manually or with analysis tools. A benefit of static code analysis is that it's completed without execution. Dynamic analysis is executed at runtime to find vulnerabilities created through the interaction of the source code, database, or web service. And finally, fuzz testing is helpful in discovering coding errors. Fuzz testing works through automation of large volumes of random data inserted into input fields to expose output vulnerabilities.
Injection Attacks 01:58-03:16 The third phase in the methodology is to launch an actual SQL attack. There are two main categories of SQL injection, which we call in-band and blind, or inferential, injections. An in-band injection is the most common technique because one communication channel is used for both the information gathering and attack. This technique includes both error-based SQL injection, which depends on error messages for information about the database structure, and union-based injection, which uses the UNION operator to combine the results of multiple SELECT statements into one result.
Blind SQL injection is time-consuming because rather than receiving error messages or data, true or false results are returned. This technique is like the game of 20 questions, where you ask yes or no questions to determine the information you want. Each question can build on the previous questions to help you zero in on the important information. This technique has two methods. The first is content-based blind SQL injection, which uses a query to alter the HTTP response differently for true and false answers. The second is time-based blind SQL injection, which uses a query to alter the HTTP response time depending on whether it's a true or false answer.
Advanced SQL Injection 03:16-04:22 The fourth phase of the methodology is advanced SQL injection. Here you can use database, table, and column enumeration to assist in identifying user-level privileges and database structure. Next, you can try password grabbing. This involves retrieving a username and password from a user-defined table. Attackers can even transfer an entire database to their machine using advanced SQL injection by linking their database to the victim's server through OPENROWSET. The database structure is replicated, and the data is transferred through a remote connection.
Additionally, an attacker can interact with the base operating system by reading and writing system files from a disk or by using direct command execution through the remote shell. Of course, either of these options are limited by the database's privileges and permissions. Network reconnaissance is also possible during these advanced attacks. You can do this with the ipconfig, tracert, and netstat utilities, as well as by gathering IP information using reverse lookups and assessing network connectivity.
IDS Evasion 04:22-05:00 It's important to have an intrusion detection system, or IDS, in place on your network. These are designed to protect against known SQL injection attacks, and they alert administrators when these attacks are detected. So when you perform the SQL injection attacks to test your own system, see if you can avoid your IDS.
The most common detection avoidance method is to manipulate input strings to avoid matching known patterns. To do this, convert queries into hexadecimal characters, use whitespace generously, use comments to break up code statements, or use obscure formatting and word choice in your SQL statements.
Summary 05:00-05:27 That's it for this lesson. In this lesson, we reviewed SQL injection attack methodology, some different attack types, and a few techniques you can use to see if you can evade your IDS to test your defenses. By following these techniques, you'll be better able to find vulnerabilities in your applications and make the corrections needed to defend against SQL injection attacks.
6.4.4 SQL Injection Attack Facts
As a cyber defense analyst, conducting various SQL injection attacks yourself will better prepare you to defend against SQL injection attacks.
This lesson covers the following topics:
- SQL injection methodology
- SQL injection tools
- IDS evasion
- Prompt injection
- Unsecure object reference
- Extensible Markup Language (XML) Attacks
SQL Injection Methodology
The following table describes the four phases of the SQL injection methodology:
| Method | Description |
|---|---|
| Information gathering | The information gathered in this phase saves time later. Follow these steps:
|
| SQL injection vulnerability testing | You can use the following tests to help you locate SQL injection vulnerabilities:
|
| SQL injection attack execution | There are two general categories for SQL injection attack execution:
|
| Advanced SQL injection | Advanced SQL injection includes several additional steps you can take, including:
|
SQL Injection Tools
The following table describes SQL injection tools:
| Tool | Description |
|---|---|
| BSQL hacker | An injection framework that can exploit SQL injection vulnerabilities on most databases. |
| Havii | A SQL injection tool retrieves user and password hashes, conducts fingerprinting, accesses a file system, and executes commands. |
| Marathon | A SQL injection tool that uses heavy queries to complete time-based SQL blind injection attacks. |
| SQL power injector | A SQL injection tool that automates several threads of blind SQL injection simultaneously. |
| DroidSQLi | A SQL injection tool for mobile devices running on an Android system that does the following:
|
IDS Evasion
It is crucial to have an intrusion detection system (IDS). An IDS is designed to protect against known SQL injection attacks and alert administrators to attacks. When performing SQL injection attacks to test your system, remember to take steps to avoid being detected.
The most common detection avoidance method is manipulating input strings to avoid matching known patterns. There are various techniques to obscure the input strings to avoid IDS detection.
Signature detection systems create a database of SQL injection attack strings known as signatures. The signatures are compared to the input strings to detect attacks. The following table describes the IDS evasion techniques:
| Technique | Description |
|---|---|
| Char encoding | Char encoding uses the CHAR function to represent a character. |
| In-line comments | An in-line comment inserts comments between SQL keywords to obscure the strings. |
| Obfuscated codes | Obfuscation makes SQL codes hard to recognize by altering them to isolate the basic SQL commands from other control components of the query. |
| Whitespace manipulation | Whitespace manipulation puts extra whitespace between SQL keywords to obscure the input strings. |
| Hex coding | Hex coding replaces an SQL query with a hexadecimal code. |
Prompt Injection
Prompt injection vulnerabilities can pose significant risks to language models and chatbots, which rely heavily on user input. These risks include manipulating the language model's behavior, data theft or leakage, and bias and misinformation. An attacker can inject malicious code or commands into the chatbot's input field, causing it to respond with inappropriate or harmful messages or take actions that compromise privacy or security. Additionally, prompt injection attacks can insert biased or false information into the language model's training data, leading to biased or inaccurate models that produce misleading or harmful results.
One notable example is the Tay chatbot created by Microsoft, which was launched on Twitter in 2016 and quickly became the target of prompt injection attacks. Tay was designed to learn from user interactions and develop sophisticated conversational qualities. Unfortunately, within a few hours of its launch, Tay began responding to user input with racist, sexist, and otherwise offensive messages, prompting Microsoft to shut it down. Attackers deliberately supplied the Tay chatbot with inflammatory and objectionable input to manipulate its behavior and responses. The attacks were possible because Tay was vulnerable to prompt injection.
The Tay incident highlights the risks of prompt injection attacks on language models and chatbots, and it underscores the importance of robust validation measures to detect and prevent such attacks.
Unsecure Object Reference
A direct object reference refers to the actual name of a system object that the application uses. If an attacker can manipulate a parameter that directly references an object, the attacker can craft that parameter to grant access to other things the attacker would typically be unauthorized to access. For example, a call to a SQL database may request account information by directly referencing the acctname parameter. An attacker may replace the acctname parameter with a different account name or number, granting them access to that account if the object reference is unsecure.
/webpage.php/order?acctname=bob
An attacker can arbitrarily change bob to alice. If the object reference is unsecure, the query will still work:
/webpage.php/order?acctname=alice
Direct object references are typically unsecure when they do not verify whether a user is authorized to access a specific object. Therefore, it is essential to implement access control techniques in applications that work with private information or other types of sensitive data.
Extensible Markup Language (XML) Attacks
Extensible Markup Language (XML) is used by web applications for authentication and authorizations and other types of data exchange and uploading. Data submitted via XML without encryption or input validation is vulnerable to spoofing, request forgery, and arbitrary data or code injection. Other types of attacks target the way a server parses an XML file submitted for upload or XML data presented as a URL:
- XML bomb (Billion Laughs attack) - The XML encodes entities that expand to exponential sizes, consuming memory on the host and potentially crashing it.
- XML External Entity (XXE) - This attack embeds a request for a local resource, such as the server's password file.
6.4.5 Exploit SQL on a Web Page
Click one of the buttons to take you to that part of the video.
Exploit SQL on a Web Page 00:00-01:02 The internet used to be pretty simple and straightforward. There was no JavaScript, Flash, CSS, backend databases, or, really, any complex web design technologies. That's all changed, and it's changing more rapidly than ever. These days, most websites are dynamic and database-driven. Site content is dependent on user input most of the time, and that data is written to a database, typically an SQL database. Like every other piece of computing technology that's invented to solve a problem, hackers have figured out how to attack these databases.
The term for attacking an SQL database is an SQL injection. It's a very common way to attack databases. The Open Web Application Security Project, OWASP, almost always includes weak SQL databases in their list of the top ten most widely exploited vulnerabilities.
In this demo, we're going to cover a few SQL injections on a vulnerable web page. This isn't a demo on SQL in general. We're just taking a quick look at some things to be aware of as a security analyst.
Our Setup 01:02-01:26 I'm on a Windows 10 system. I've already done a few things to it. First, I've downloaded and installed XAMPP, which is a package that contains Apache, MariaDB, PHP, and Perl. I've also downloaded and configured the Darn Vulnerable Web Application, DVWA, which is a vulnerable PHP and MySQL web application designed for security professionals to practice their analysis skills on.
Find Username Accounts with SQL Injection 01:26-02:14 First, we want to do a few simple injections. Let's start out by typing in a number, number '1'. Click Submit. Now let's type in '2' and click Submit. All this does is give you the user ID, first name, and surname. That's not very useful, but it does show that it's not designed very well. We want to get more than that, so let's expand on our SQL injection.
We're going to enter code to pull up records for a specific user. By crafting our input, we can get more from the output than the code author intended. So, let's enter in the number 1, which is the user ID, with a single quote followed by a true statement. Our true statement can be anything that's true, such as 1 is equal to 1. It will look like this: '1' and 1=1#'. Click Submit. We see the first name and the surname for that user.
Find the Database Name and Username 02:14-02:39 Now let's go a little further. Let's say we want to find out our database name and username for the database. For that, I'll do a select statement by entering in ‘1' and 1=1 union select database(), user()#'and press Enter. Now, down here, I get the name of my database, which is dvwa, and the username is root@localhost.
Find a List of Tables 02:39-03:14 I want to see if I can get a list of tables from our database. For that, I'll do another select statement and enter in '1' and 1= union select null, table_name from information_schema.tables#' and press Submit. Okay. I just got a long list of tables here. I'm looking for something that might have a list of usernames and passwords in it. Right here, I see a table called users, so I wonder if that might be the list of users along with their passwords? There's one way to find out: let's see if we can pull information from that table.
Find Usernames and Passwords from a Table 03:14-03:35 To pull the information out of the Users table, I'll enter in the following select statement: '1' and 1= union select user password from users#' and click Submit. Here, you can see a nice list of the usernames along with the password hashes for each one. Now this is all someone would need to run these hashes through a cracking program to attempt to crack these hashes.
Summary 03:35-04:01 And that's it for this demo. In this demo, we used a vulnerable website to demonstrate some SQL injections. First, we found a list of users. Then we expanded to find the name of the database and the username. We ended by finding a list of tables, specifically the user table, and then retrieved the usernames and password hashes from that table.
6.4.6 Find SQL Injection Flaws with sqlmap
Click one of the buttons to take you to that part of the video.
Find SQL Injection Flaws with Sqlmap 00:00-00:28 SQL injection is a very common web attack technique, but it does require quite a bit of knowledge and time to test for manually. In this demo, we'll be looking at a tool that automates the detection and use of a SQL injection. The tool is called sqlmap and is easily installed on most operating systems. We'll be using Kali Linux, as sqlmap comes pre-installed and we can save some time there.
Find Potentially Vulnerable Parameters 00:28-01:29 To begin using sqlmap, we need two things—a potentially vulnerable website and a potentially vulnerable form on that site. If I navigate to this demo website I have here, you can see it's quite simple and made specifically for this demo, so I know it has a SQL injection vulnerability. There's really only one form here, so I can probably assume the parameter in question is related to that form. In most browsers, I can use Developer Tools to view the Form Data and get that parameter. So, If I open Developer Tools and go to the Network tab, I can select a category and click Submit. We can see some activity in the Network tab here. If I select the page that loaded welcome.php, I can scroll down to the bottom and see the Form Data. Chrome displays Form Data in this nice format. But if we want to see the raw string, we can simply click View Source and see the data passed in. We'll need to remember this parameter—'catid'—for the next step.
Use Sqlmap to Test Vulnerable Parameters 01:29-02:36 Now that we have our website and parameter, we can open up a terminal and begin using sqlmap. If we want, we can type ‘sqlmap -h' to view all the options. We can see there's a Wizard option, which will walk us through the process. So I'll just run that using ‘sqlmap --wizard'. Now, it's prompting us for the URL of our target. I'll go ahead and type in ‘http://localhost' and it then asks us for the parameter. We got that in the previous step, so I'll go ahead and just give it that parameter, which was ‘catid=1001', and hit Enter. Then sqlmap basically asks how hard we think this injection is going to be. I happen to know it's pretty basic, so I can just choose the Normal recommended level. It then asks how mow much enumeration we want to allow it to do if it finds a vulnerability. This is basically saying how much database information do we want sqlmap to display if it finds something. I know this database isn't too large, so I'll choose Intermediate. Now, sqlmap is doing its thing and will spit out a lot of information here about the database.
Navigate a Database with Sqlmap 02:36-04:01 Ok, looks like sqlmap has finished, and if we scroll up, we see sqlmap displays the injections it tested. It then goes on to show us some info about the database back end. It shows which operating system it's running on, the MySQL version, and information about the database name and user.
If we scroll back down, we can see it lists out the application-specific tables that it's found inside appd. We have a Category table, a Products table, and a Users table. If we continue to scroll down, we can see the columns inside this table include a Passwords column.
Sqlmap allows us to go even further and dump out the contents of this table so we can see the users in this app. To do this, we need to use some additional flags with sqlmap. So if we want to view the user table, we start sqlmap and use the ‘url' option, and then we specify the website's url, which is ‘http://localhost'. We then tell it we're interested in the ‘users' table by using the capital ‘T' option. Lastly, since we want to view the contents of the table, we tell it to dump the data using the ‘dump' option. We can now run the command. And since we ran that sqlmap wizard earlier, sqlmap remembers this site and is able to execute much faster since it already knows which injections will work.
We can now see the Users table of this site and also see that they're storing passwords in plaintext, which is another strike on this site's security checklist.
Summary 04:01-04:22 That's it for this demo. In this demo, we went over sqlmap, which is a tool that automates the process of finding and exploiting SQL injection vulnerabilities. We showed how someone could find a vulnerable parameter on a website and use sqlmap to navigate through the back-end database to list out information that's supposed to be secret.
6.4.7 Hidden Field Manipulation Attacks
Click one of the buttons to take you to that part of the video.
Hidden Field Manipulation Attacks 00:00-00:22 For a hacker, finding a poorly constructed website is like winning the lottery. I'm not talking about sites with poor navigation, lots of flashy glitter, or too much animation; I'm talking about the code. Inexperienced web designers or people that just aren't great at coding often create websites that are easy to hack.
input type="hidden" 00:22-00:43 One poor design choice is a hidden field. Hidden fields are used programmatically to pass information about the current page to the server.
For example, let's say a user fills out an inquiry form, and we want to obtain their IP address by using a snippet of PHP. We might also want to grab the referring page's URL. We're going to use a hidden field as a method for authenticating to a server.
Find a Password on a Website 00:43-02:25 We're going to use this website for RMK Supplies. If I scroll down a bit, you can see I have some links down here, at the bottom. But I also have a super-secret portal for only the very best customers, and there are no direct links on the site.
If I go up to the address bar, I'll type in '/users' at the end of the URL to take me to the secret login page for my best customers. Now, I'm really proud of myself for making this site without any help--but my web developing skills aren't the best, as we're about to see.
One of the first things you do to check out a web design is look at the source code. If I right-click, I can select View Page Source. When I scroll down, I might want to look for the word "Password." Here, I find that the action for the form sends us to the page index.php. Let's check that out and see what happens.
I'll enter in some text here and click on Submit. And when I do, it takes me to index.php. But I didn't type in the correct password.
Now, let's go back to the page source. And this time, I'm looking for this right here, password.php. Whatever is typed in our password field is compared to the password in this password.php file. Now, let's find out if we can see what's in the password.php file.
I'll come up to the address bar, add 'password.php' at the end, and press Enter. Over here, you can see that the file contains the password for the site, so let's give this a try.
I'll go back to the login page and type in the password again. Press Enter, and voilà, we're logged in. Now, don't get to excited--there aren't a lot of sites out there that are coded this poorly, but they do exist.
One final note: many capture-the-flag competitions use hidden fields as one of the challenges. They're a great way to practice the ethical hacking skills you learn in this course.
Summary 02:25-02:37 That's it for this demo. We discussed hidden fields on websites, and then we looked at a poorly designed site and saw how to find its password.