Web App Attacks: Sneaking in the Front Door
By the LiveSecurity® writers
The attack target of choice is no longer just your network servers, but also the applications that run on them. Many of the leading brains in network security believe that misconfigured websites represent the most likely vector for compromising today's network. Real life examples include bad website design by banks, major international corporations, and critical infrastructure providers. We've seen a breathtaking array of break-ins compromising the databases behind all kinds of websites. If we had to boil it all down to one key message to the CFOs of the world, it would look like this:
The message carries even more impact for retailers or banks that store or process credit card data. The PCI Data Security Standard has mandated the importance of writing secure applications. Requirement 6 specifies the need to incorporate information security in the development lifecycle for web applications.
We asked Saumil Shah, a well known BlackHat security instructor, how the average network administrator could communicate the importance and severity of web app attacks to their application development team. His simple answer: "If you need to convince them of how critical all this is, just show them."
In fact, in his BlackHat courses Saumil demonstrates many of these types of web application attacks and teaches techniques web administrators and developers can use to prevent them. Three examples follow, suitable for showing your web app development leader:
Directory Browsing and Unexpected File Retrieval
Is your web server using default settings? If it is and your website's root directory contains subdirectories, an attacker can probably retrieve a listing of all the files in those directories.
Disclosing a directory listing doesn't sound dangerous, but it is. Web administrators often leave files in these directories that they don't intend visitors to see (for example, log files, zip or backup files, or perhaps an include file that contains sensitive PHP source code). If your website doesn't know how to handle a particular type of file, it simply sends the file directly to any visitor requesting it. So if you leave sensitive files within web directories, they may not stay secret for long.
You can easily correct this issue by hardening your web server's configuration. For example, turn off directory browsing on your server. Provide a default web document (even if it's empty) in every web directory so that your web server doesn't display the directory's contents instead. Avoid placing sensitive files in directories that web users can access. And finally, create dummy handlers for file types your web server doesn't recognize by default. These steps prevent attackers from discovering what files reside on your server and also prevent them from downloading non-web files.
Although experienced web administrators probably consider most of these hardening techniques common sense, you'd be surprised how many websites don't use them.
Suppose Joe Shmoe, hacker, visits his banking site and decides to explore. After logging onto his bank account, he fires up a special Web proxy (for example, Paros) that traps all Web traffic and allows him to view and edit it before forwarding it. During such a transaction, Joe sees an interesting parameter: CustomerID = 23147. "Hmmm," Joe muses, "what happens if I change 23147 to 23148?" Voila! Joe gains access to Sucker X's bank account without needing to log in. Now he can transfer Sucker's hard-earned savings to his own account!
This is a classic example of a session hijacking attack. The HTTP protocol was never designed to keep track of a user session. Every HTTP link you click creates a brand new TCP connection, independent from the last. When your HTTP request gets the object it seeks, the connection then drops. So the only way you can track user sessions on your own website is within your web application code.
Unfortunately, not all web developers know how to handle user sessions securely. Some try to code up their own methods for handling the state of a user connection. This leads to web application design flaws that allow in hackers like Joe Shmoe. Fortunately, most web application languages have built-in session variables specifically designed to handle sessions securely. Make sure your web developers are aware of session variables, and are using them to help prevent site coding flaws that allow session hijacking attacks.
Metacharacter Insertion Attacks and SQL Query Injection
Imagine Joe Shmoe visiting a consumer electronics website where anyone can purchase the latest tech gear. He clicks on a link to read about a digital camera, and the URL in Internet Explorer changes to:
Thinking like a hacker, Joe decides to change the p_id=1 to a p_id=2 just to see what happens. Look at that! A product page about some printer popped up instead of the description about the camera. Neat! That means p_id summons product descriptions from some database. Hmm, wonder what kind of database it is. Microsoft? Oracle?
Next Joe tries p_id='1. In SQL syntax, a single quotation mark is an example of a metacharacter — a character that the program interprets not as part of a word, but as part of a command. In SQL, single quotation marks must always travel in pairs. Joe enters one ' because if this Web page relies on SQL and allows customers to enter metacharacters, he can get an error message telling him exactly what database software is in use.
Joe hits Enter, and... what's that? Ha! Now he knows this website's product page relies on a back-end Microsoft SQL server. He decides to see what happens if he appends his own SQL query to the p_id=1 query. He adds, OR 1=1. Since 1 always equals 1, this query is always true. If the Web app is not validating customer input and discarding any inappropriate characters, as it should, this SQL query will return all the values for p_id from the website's SQL database. To make the URL HTTP friendly, he adds + characters for spaces, like this:
Bam! The Web site displays every product in the database.
Joe just demonstrated a class of attacks known as SQL injection, and an attacker can accomplish almost anything with it. For instance, if you allow default stored procedures on a Microsoft SQL server, an attacker might call the "xp_cmdshell" procedure to allow him to execute any code on your machine and gain full control.
So what can you do about this class of attacks? For one, validate customer input! More specifically, make your Web app developers learn about input validation and use it to sanitize all user input. If you have a form that asks for a name, there is no reason a visitor should be able to enter numbers or special characters, especially characters like ' or < that have special meaning in SQL or HTML. If your developers' code checks the user's input for such characters and refuses them, attackers won't be able to inject HTML scripts into your web forms.
Fully protecting against SQL injection can be complex. You should have your web developers review how they implement SQL queries in their web code to make sure they do it securely.
Also, harden your SQL server. As with any application, when SQL installs, it includes all sorts of items that are irrelevant to your particular use; delete them. For example, you should remove all unnecessary default databases and users. This prevents attackers from taking over guest accounts you were unaware of or forgot about.
Create special low privileged users for your web applications that can only access what's necessary for your site to function. Finally, delete any unused (and often dangerous) stored procedures.
Obviously, this is the briefest of introductions to the harmful potential of web application attacks. Now that you're aware of the issue, continue your research at sites like Open Web Application Security (OWASP) so you can advocate safe web coding practices at your organization. OWASP publishes a list of the top ten web application security vulnerabilities. The PCI standard was even updated in version 1.2 in October 2008 to specifically require that web applications get developed based on the OWASP guidelines.
The reason hackers moved on to web apps is because you successfully denied them access to your servers. If you won that battle, you can win this next one — assuming you tweak your site before Joe Shmoe does.