[ Music ]
^M00:00:09
>> In the book, "Daemon," Brian Gragg uses an SQL injection attack to hack into a server in order to join a secret society run by a dead man. Good book. SQL injection attacks are real, though. I've consulted with several experts, who remain anonymous, in order to help give you a very basic explanation of what they are. Let's start with blog software, as an example. A lot of people run it, but they don't really understand how it works. And that's okay, as long as you regularly update and don't expose administrative functions to the Internet. When you type your log in ID and password into a web page, it is passed as a string of text into a variable. And that variable is then interpreted as part of a command. Let's say the statement's like this, a select command looking for a user name. This tells the application to select from a table called "users" the name that equals the string "user name." So, let's say you type your user name "4thelulz," the string will look like this. And only the name "4thelulz" will be selected. Normal SQL injection is often detected by fuzzing a parameter with malicious characters like this. So you've got your example log in sending some post-data that's malicious, and the application will return a 500 internal server error, and SQL error, or both. Now, a clever hacker could enter something like, "a' or 't' = 't, with the apostrophes, as the user name. Then that's gonna turn the command to this. And the request is gonna look like this. Do you see how the single quotes are used to surround what becomes an argument? Since "t" always equals "t," the selection comes back as evaluated "true," even though a real user name has not been entered. This could work for a password, too. Now, the problem here is allowing multiple statements within one call. Your query API should not allow this. The injection attack in Daemon is what is sometimes known as a "magic string." This one's clever because unlike the injection we just talked about, a magic string can potentially give you admin access, not just generic user access. The attacker simply enters 'or 1 = 1. As far as an example, here's your login, and the post data is passed as so. This causes the statement to be interpreted as this. Where it's saying "name = blank or 1 = 1." Well, this selects for all the users in the table and allows you to be logged in at the user at the top of the table because 1 always equals 1. There are many more injection types than this, including blind SQL injections and vulnerabilities inside the server, but this should give you a fair idea of what these attacks are and how they work. The experts I consulted recommending using manual code reviews and enforcing the use of parameterized statements to ward off these kinds of attacks. Thanks for watching Hacks. Stay safe out there.
^M00:02:54
[ Music ]
