It's a sad day when someone hacks your online system. Are you angry, hurt, or violated? Or are you a combination of all three? How you feel about it doesn't matter. What does matter is what to do about it.
Your first thought is how to fix it. This site contains code on how to clean an sql-injected database. The problem is that you can go through a lot of tedious work cleaning your database only to wake up tomorrow and find that you've been injected again. If you've never experienced that feeling you're lucky. Perhaps the most unfair thing of all is that it's only creative people get punished. Those ambitious and intelligent enough to develop an online system are the targets.
So rather than doing following your instincts - which is to FIX what is wrong immediately - you need to stop and think about the cause. Fixing an injected database is dealing with the symptoms. You need to deal with the cause. You need to find the breach and close it. Once you've gotten to the root cause of the problem, then you can move on toward fixing your database.
The first thing to think about is your system. Divide your system into two parts - pages that are open to the public and pages that are inside password-protected areas. Of these two areas, I consider the pages open to the public to be the most likely target. You do NOT need to be writing to a database to be injected. You can be injected on a select statement. You also don't need a form. You can be injected from a URL (query string).
Database programs (MS SQL, MySQL) are far more powerful than necessary. Microsoft even has a database command in MS SQL that executes operating system commands (talk about scary). When deploying web databases you only use a small fraction of the capability of the database. That becomes part of the problem. SQL injectors are aware of the full capability and use it to their advantage. SQL injection happens by appending code onto the end of a database command. By adding code into a form, or appending it onto a URL, they are essentially adding a second command onto your command. Database programs, with their immense power, are capable of executing multiple commands in a single shot. Therein lies the problem. Database programs take in your command PLUS the injectors command and EXECUTE THEM BOTH. I wish database programs had a checkbox that said execute one command only but they don't. So as programmers, we're stuck with it.
Anonymous Read Access
First of all you want to look at all web pages (open to the public) that read from your database. The key thing here is HOW you connect to your database. There is a difference.
Databases have users. Users have credentials. If you look at your connection string you will see a username and password. That user has rights within the database. Many programmers are delighted just to get a database functioning. They are preoccupied with getting the logic right and are not concerned with how they are doing it. When developing there is a tendency to connect to the database using the system administrator user (also called SA) just to get the system working. When you connect using SA you eliminate all security blockages - like not being able to connect - because SA has unlimited rights to all data and functions.
If you are experiencing an attack, look at all pages open to the public to see how you are connecting to your database. If you are connecting using SA, you're in big trouble. SQL injectors sweep the Internet looking for web pages like products.asp or products.php that connect to the database using SA.
It doesn't matter if all you are doing is displaying (selecting) data. SQL injectors will append their code onto your URL and if done properly, it will go right into your database. It is imminently possible for an injector to write a program that searches for people connecting using SA and injecting those databases. The key to stopping the attack is not to filter the input (although this helps). The key is to set up a user that only has permission to read data and nothing else. You connect to your database using this user, rather than SA. Now when the injector appends a command (usually CAST) onto your URL they get permission denied.
You might wonder why anyone would inject a database. Is it just to do it? In most cases they inject the database with javascript. Here's how it works.
1. You have a database of a thousand products.
2. You have a product section on a web site that displays a list of products. When you click on a product, you get a product detail page. This is common database programming.
3. A bad guy sweeps the Internet and exposes that you are connecting to your database with privileges.
4. They inject every field of your product table with javascript - which is just ONE command by the way.
5. When your web server serves the page their javascript calls a program on THEIR server.
Think about a marketing value here. In one shot they have deployed a thousand web pages with their malicous code in it. From now on, every person that looks at any one of a thousand product pages will execute a program on their server. If you have thousands of databases like this around the Internet, your program is getting a lot of exposure.
What would their program do? It could put a warning in the middle of the screen stating that your computer is infected and THEY have the cleaner-solution for only $29.95. Click that link, put in a credit card number, and who knows what happens from there. That's how quickly a web database can degrade.
It only takes a crack and they're in. |
