There are a wide range of ways that your sites and web servers can be compromised. Some of them are easily blocked with a bit of forethought and positive action. Others require a more hands on approach including real-time monitoring, software updating and operating system lock down. In the past we wrote about a handful of common web vulnerabilities and in this article we will talk about how to close some of those loopholes and protect against those vulnerabilities.
Denial of Service (DoS)
The Denial of Service attack is usually done by throwing so many requests at a web server that it can’t keep up with the requests. The result is that legitimate users are unable to reach the website in question. Often, a Denial of Service attack will be done from a vast array of previously compromised computers resulting in a Distributed Denial of Service attack (DDoS).
First off, if you’ve already been the target of a DoS or DDoS attack, you’ll want to check your server to make sure it wasn’t compromised. That’s an entirely different article as its scope is quite large. As for prevention, there are some best practices to consider before you plug that new server into the network.
-
Be sure to install the latest operating system updates, which are usually based on closing a security vulnerability. Be aware that some updates may be “beta” or not fully tested and could create problems, always backup and read documentation carefully.
-
Shut down all unnecessary server services. For example, if the server is to solely be a web host, turn off things like FTP, telnet, SSH and all RPC-based services.
-
When compiling the kernel, be sure to look closely at what is included and turn off or remove anything that you don’t absolutely need.
-
When configuring the web server software (Apache, etc) disable additional support that you won’t need for your server to minimize vulnerabilities. If you don’t need Java, or CGI turn it off.
-
Set up some Intrusion Detection Software (IDS)
-
Determine the baseline operation parameters of the server and then use monitoring software or components to ensure that the server is always operating within those parameters.
These are just a few basic ways that you can start securing your server against the DoS and DDoS form of web attack. Now let’s turn our attention to another form, SQL injection.
SQL Injection Protection
SQL injection is when SQL code is used via a web-based text box to retrieve data from the database, essentially giving private information out to a malicious user. Protecting your site and server from this sort of attack depends on what kind of scripting language you’re using for your front end website forms.
The most basic protection is to not concatenate your variables into your SQL statement before processing. The way to do this will differ by scripting language but essentially you will use SQL statements to validate the variables.
An example, in PHP from php.net:
[code lang=”php”]
<?php
$stmt = $dbh->prepare(“SELECT * FROM REGISTRY where name = ?”);
if ($stmt->execute(array($_GET[‘name’]))) {
while ($row = $stmt->fetch()) {
print_r($row);
}
}
[/code]
In the above example, anything that the user inputs in the form ‘name’ field, will automatically be enclosed in quotes and therefore is not able to be executed. This technique can be used in most scripting languages and will prevent the majority of SQL injection attacks. That’s not to say there aren’t other possibilities, but this is, generally, the most automated of attack vectors for this type of attack and will cut down the largest portion of them.
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is a somewhat complicated vulnerability and as such, has some complicated prevention steps. One way to prevent such an attack is to use tokens that are synchronized to a user’s current session. This will allow the site to know that the requests are initiated by the user and not by a third-party who has hijacked the user’s identity. Somewhat bulkier for end users but easier to implement is the requiring of authentication data anytime an HTTP request is used for certain things involving money, security, etc. If you’re utilizing multimedia via Silverlight or Flash be sure there’s no unwanted accessibility through a clientaccesspolicy.xml or crossdomain.xml. Ultimately, there are several CSRF solutions available as well including OWASP’s CSRFGuard. For far more information on prevention see the Wikipedia article on CSRF.
Buffer Overflow
Buffer overflow is a problem that exists at the code level meaning that programmers and software designers need to be vigilant when creating a new piece of software. The exploit vectors and the prevention techniques are too numerous to fully outline in a single article. It is best to consult with experts or do ample research if you are concerned about buffer overflow problems.
Some programming languages do not have built-in memory overwriting checks which means that if you choose to use that language you will need to make sure that every you set bounds checking or do compile-time or run-time checking on bounds. Aside from using a programming language with built-in checking, other options include using a buffer overflow protection system like Libsafe, StackGuard or ProPolice. You might also require pointer protection, executable space protection, address space layout randomization, and, deep packet inspection. To even begin to scratch the surface of all of this in this article would be sheer folly and so it is best to do a good deal of research on the topic prior to beginning your project.
Cross-Site Scripting (XSS)Attack Prevention
There are three major types of this attack; reflected, stored and DOM-based. There are seven major rules to XSS prevention, not including “don’t accept Javascript from any source and execute it.” Each of these rules is aimed at securing your web applications against the cross-site scripting attack. They’re laid out by OWASP, the Open Web Application Security Project. The rules revolve around securing untrusted data and keeping it from being corrupted with code which is subsequently executed on the server. As a note, never put untrusted data in a script, HTML comment, attribute name, tag name or in CSS.
Rule #1 – Escape all untrusted data before inserting it into an HTML element.
Escaping is taking a character, such as &, and turning it into something that will not be executed, such as &. Other major characters that need to be escaped include <, >, “, ‘, / – all of which are significant in XML.
Rule #2 – Escape attributes before placing into HTML common attribute tags.
If you need to use untrusted data in attribute values like width, height, name, etc. then you will need to escape a wide array of characters. OWASP states “anything with an ASCII value of under 256.” That means the &#xHH ASCII code for the characters and includes [space], %, and many mathematical operators as well as ^ and |.
Rule #3 – Javascript data values
Javascript is one of the biggest holes in terms of XSS. In some contexts, even if you escape the untrusted data, it could still be executed and your site compromised. If you escape data with a an attacker could also send a and turn it into \ which will be parsed and enable the quote. This is called an escape-the-escape attack format. Essentially, it turns the escaped data into executable code. Some functions can never be safe with untrusted data, as explained by OWASP. For example:
[code lang=”javascript”]
<script>
window.setInterval(‘…EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE…’);
</script>
[/code]
Rule #3.1 – JSON values must be HTML escaped and read with JSON.parse
Using a JSON code block to store multiple values is common practice, however, this can lead to XSS and security breaches. Whenever this is done the Content-Type must be set to application/json and never to text/html. It is the only way to ensure that the code is not misread and turned into an execution statement. OWASP has a great example of what the HTTP response should look like below:
[code]
HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5….
Content-Type: application/json; charset=utf-8
[/code]
Encoding can be done either with JSON or HTML, the major difference being that with the prior, you cannot use CSP 1.0 XSS protection, with the latter, you can.
Rule #4 – Escape your CSS and validate untrusted data before insertion into HTML style property values.
You might find it absolutely necessary to insert untrusted data into your CSS. The only truly safe place for it is in a property value as in <style>selector { property : escaped untrusted data ; } </style> or a similar construct. Be aware that you can never safely use untrusted data if you have a URL in a property which begins with javascript or expression. Ultimately, you will need to escape anything with an ASCII code of 255 or lower.
Rule #5 – Escape untrusted data before insertion into HTML URL parameter values.
Whenever you need to use HTTP GET with untrusted data, you need to escape it properly to prevent an XSS exploitation. Again, you must escape all characters with an ASCII value of less than 256. Do not allow untrusted data in a data: URL because it cannot be properly escaped. Also, do not encode URLs (complete or relative) with URL encoding, instead, validate it to make sure it points to a proper protocol.
Rule #6 – Sanitize your HTML with a sanitizing library.
Whenever you need to accept markup, input that will include HMTL, you need to use a library which will understand the context and encode without breaking the tags. OWASP offers several libraries like AntiSamy and Java HTML Sanitizer. You might be using something else like Python or PHP, which also have libraries to use (Python Bleach and PHP HTML Purifier respectively). Properly utilizing these sanitizing libraries will ensure that the expected HTML is accepted and still usable for whatever purpose.
Rule #7 – DOM-based XSS attack prevention
This area is so complex, it has an entire page dedicated to it at OWASP, which includes another five rules.
- HTML Escape then JavaScript Escape Before Inserting Untrusted Data into HTML Subcontext within the Execution Context
- JavaScript Escape Before Inserting Untrusted Data into HTML Attribute Subcontext within the Execution Context
- Be Careful when Inserting Untrusted Data into the Event Handler and JavaScript code Subcontexts within an Execution Context
- JavaScript Escape Before Inserting Untrusted Data into the CSS Attribute Subcontext within the Execution Context
- URL Escape then JavaScript Escape Before Inserting Untrusted Data into URL Attribute Subcontext within the Execution Context
.
OWASP is probably the best source for security cheat sheets. They offer a multitude of pages designed to help you, as a web programmer or website owner, secure your site and server from a wide range of web vulnerabilities. We have compiled a small list of some good reading and resources on web vulnerabilities and how to prevent them below.