THE DARK ARTS: SQL INJECTION AND SECURE PASSWORDS
https://www.ispeech.org/text.to.speech
As the year of 2005 was drawing to a close, a website known as Myspace was basking in popularity. With millions of users, the site was the most popular social networking site in the world. It was unique in that it let users use HTML code to customize their Myspace page. Most of us, câmonâŠadmit itâŠ.had a Myspace page. The coding part was fun! But not everything was changeable with code. You could only upload up to 12 images and the Relationship Status drop-down menu only had a few options to choose from. These limitations did not sit well with [Samy Kahkar], a 19 year old hacker out of Los Angeles.
It didnât take [Samy] long to figure out how to trick the site to let him upload more images and change his relationship status to a customized âin a hot relationshipâ. After hoodwinking the Myspace site with some simple hacks, he realized he could do just about anything he wanted to with it. And this is where things get interesting. It took just over a week to develop a script that would force people who visited his page to add him as a friend. But that wasnât enough. He then programmed the script to copy itself onto the visitorâs page. [Samy] had developed a self-propagating worm.
The script went live as [Samy] went to bed. He woke up the next morning with 200 friends requests. An hour later the number had doubled. [Samy] got worried and sent an anonymous email to the webmaster warning of the worm. It was ignored. By 1:30PM that day, he had over 6,000 friends request. And like any good hacker worth his weight in floppy drives, his sense of humor had him program the script to also add his name to each visitorâs Heroes List. This angered many people, who deleted him from their page, only to get reinfected moments later when they visited another (infected) page.
[Samyâs] script was raging out of control. Â As the evening closed in, his friends count had reached 919,664. It would top the 1 million mark just before Myspace took their servers offline to figure out what was going on. Two hours later, the site was back up. [Samyâs] profile page had been deleted.
[Samy] had used a technique known as cross-site scripting (XSS) to pull off his hack. Weâll touch on XSS in a later article. For now, weâre going to stick to the basics â proper passwords and SQL Injection.
PASSWORD SECURITY
To begin, we need to touch on some basics.  All of the hacker protections you employ can be rendered useless with an ineffective password. In our last article, we talked about how a group of hackers known 
as Lulzsec were able to hack software security expert [Aaron Barr]âs corporate website. His main password was âkibafo33â. According to a password security checker, it would take about 11 minutes to crack. Adding a single special character and capitalizing a letter, such as Kiba#fo33, brings that time up to 275 days.
Cracking passwords consists of using common phrases and brute force attacks. With brute force attacks, all letter, number and special character combinations are tried in a sequential manner. Thus choosing longer passwords and a larger number of character types makes it harder to break. This is why many websites insist that you use at least one special character and capitalize a letter as it greatly increases the security of your password. It doesnât take much effort to create what is essentially an unbreakable password. So before you go checking your site for vulnerabilities, start with your password.
SQL INJECTION
SQL injection (SQLi) is a technique that allows an attacker to execute SQL statements in an entry field. This technique was used with great success by the Lulzsec hackers. One member who went by the name [Kayla] wrote an automated program that combed thousands of URLs and returned those that were vulnerable to the attack. Typically, a mischievous SQL statement is passed to the database along with a normal input. For instance, one could type into a password field of a username/password login prompt:
passwordâ OR 0=0
The resulting SQL query would look something like:
SELECT id FROM users WHERE username=âusernameâ AND password=âpasswordâ OR 0=0
The statement â0=0â that was added is always true. If there are no checks in place, this will result in bypassing the authentication process and logging into the account of the first person on the database, which is usually the database administrator. Now, itâs highly unlikely that you would find a modern website that would have this kind of vulnerability, but it never hurts to check. It is often the simple hacks that are overlooked.
A more advanced form of SQLi is called union based SQL injection. It involves a similar process but uses the UNION SQL operator to gain access to data within the HTTP response. A security company has set up a phony testing website that is vulnerable to this type of attack that we will utilize for demonstration purposes.
Key in the following:
https://testphp.vulnweb.com/artists.php?artist=1
This is a completely normal query but vulnerable to SQL injection. You can tell by putting an apostrophe (â) at the end of the string and observing the SQL error message. This is a just a test website, so go ahead and try it! Weâre going to exploit it by asking for a nonexistent record, such as âartist = -1â. It can be any number that does not exist within the database. Weâll then use the UNION operator to join our malicious statement to the request. The malicious statement will be SELECT.
https://testphp.vulnweb.com/artists.php?artist=-1 UNION SELECT 1, 2, 3
This proves that the database will return data if we ask it nicely. Now letâs get some useful data, like a (fake) credit card number.
https://testphp.vulnweb.com/artists.php?artist=-1 UNION SELECT 1,pass,cc FROM users WHERE uname='test'
GOING DEEPER
Running rogue SQL statements on a test website is one thing, running them on a real website is another. You will have realized by now that youâll need to brush up on your SQL skills to truly understand any real penetration testing. Finding real websites with vulnerabilities is the first step, but is not much different from our example. PHP sites tend to be targets as they are more likely to be vulnerable to SQLi attacks. A method called Google Dorking (pdf) is one method used to find these sites. Hereâs just one example that can be typed into your favorite search engine:
inurl:article.php?id=
This turns up about 1.6 Million results, and as before, appending the URL with an apostrophe is the simple test. If an SQL error is returned, the site is vulnerable to an SQL attack. From this point, an attacker would go on to use SQL statements to figure out how many columns are in the database, and then start exploiting it.
PREVENTING SQL INJECTION ATTACKS
You now have more than enough information to start testing your site to see if itâs vulnerable to an SQLi hack. In many cases, the hacker winds up with the MD5 hash of the database password. Theyâll then use various crackers to get the passwordâŠanother reason you should use secure passwords and not use the same password on various accounts.
Preventing SQLi can be done by sanitizing inputs on your webpage. This would prevent anyone from entering â0=0â in an input where numbers are not needed. The vast majority of pages out there will have their inputs sanitized. But it only taks one slip up to expose the entire site to attacks. If ever you happen to run across a site that is not sanitizing its inputs, please play nice and send the webmaster an email. Save your hacking skills for constructive endeavors.
Sources
Gloss