In this lesson, we discuss SQL injection and its impact, examine the source of this vulnerability. And provide a demo which show how the password information in database can be revealed by injection, logical expression in a secure expression statement, wire-input data, and bypass override the condition checking in SQL commands. SQL injection is a type of injection application vulnerability attack where SQL commands or related logical expressions are injected by the hackers as part of the input and executed by the SQL server. It resulting in revealing the sensitive data, such as password, credit card numbers, in the SQL database. It occurs when the program does not perform the input validation we saw in command injection case. The input from the users are used directly or indirectly as a parameter to the later SQL queries. The SQL injection vulnerability will allow attacker to modify, execute SQL query on the victim's actual server. The hacker can steal and create fake password and credential information inside the victim database. They can steal or forge other critical information inside the database, like command injection. In the same category of injection vulnerability, SQLinjection is one of the number 1 in OWASP Top 10 Vulnerabilities 2013. You can check on the URL listed here. It remains number 1 in OWASP Top 10 Application Security Risks, which will probably be published August this 2017. Unlike command injection, SQL injection focus on attacking the SQL server, and therefore it cannot execute arbitrary OS command. Personally I feel it's less dangerous, but then critical information could be revealed. MySQL server, which is to be run on Linux, maintain its own password file in MySQL database, by this specific database called MySQL, inside its user table, a table with the name USER. They are different from the password maintained by the operating system in /etc/shadow, typically /etc/shadow in Linux system. However, for convenience or for [LAUGH] laziness reason, if the system administrator is too lazy, often the login and password are exactly the same created. The hacker can then log in. If they break into a database, retrieve this credential information, they can then login through the victim's system. This is called escalating of the privilege. You steal credentials from one area of the services, you can authorize in the other service. Escalating privilege is one of the important hacking methodology steps. Here is a demo of SQL injection attack using a typical Membership Profile Request web app. First, let us show the normal operation. In the Membership Profile Request web app page, we enter the email address and the passwords and then we click the Submit button. If the password check are OK, the status is shown in the activity response web page coming back. Here we show SQL injection exploit, or vulnerability, of the Membership Profile Request web app. By just adding a malicious string, single quote, 'or 0=0 or' ,operator, ending with a single quote. If we enter this string right after the email address, we are able to retrieve the profile information of all the member in this particular database, including the password for access the website. Know that missing the two single quote characters or the last or operator in this malicious string, will not result in the display of those password information. It's very tricky, but we will explain why is that later on. The SQL query result will return SQL syntax error at line one, if we're missing those single quotes or the or operator. For example, by removing the last or operator, we will have 0= 0 single quote end up in the SQL query closed statement, where 0 quote is not a legal term in SQL statement. Therefore, SQL query processing will reject and print out there's a syntax error. Let's examine the showme.php code to understand where the vulnerability of the SQL injection occurs. First the code, we can spot looking at the pattern, it violates the security design pattern pattern a we discussed in the previous session. It does not check on the input right after we read in the input data, as shown in the arrow there. Furthermore, the input email is used in SQL query. The query also use star, a wildcard character, to display all the fields in the table, and that should be changed to make it more specific. For example, instead of showing the password, we probably should result in a special request before we show the password. Remember the paradigm to replacing generic mechanism with specific mechanism, the more specific, the better the security. Here we examine how SQL query with malicious string are evaluated. By turning on the print debugging statements in the showme.php, we get the following query printout, which shows out we have 'or 0=0 or', called a malicious string, injected into the SQL query, as shown in the middle there. The where clause has three expression altogether. And we highlight the malicious string with red colors. And turn out there are three expressions. They are connected with or operator. The first operation, first expression, email='cchow@uccs.edu'. This is the normal expression, which we see in normal query. It would return true as intended, and therefore it only showed one of the row when we examine all the row. The second expression, 0=0, is the malicious attack, which as a logic expression will return always true. And because anything true or another value is true although, is always returned true, we simply bypass a previous logic expression. And any of the row in the database will then be matched and displayed. The third one is a two single quote character. It doesn't matter in this case, since the middle logic expression already override that particular way across, to yield the true expiration for all or. This term, two single quotes, doesn't seem to matter. Therefore, in this case, all that row information in the member1 table will come back and display, and all the column will also display, because we use wildcard character star.
