Opening a site Google has listed as spreading malicious software via the browser.

What is an SQL-injection. How can it affect my site. How does it happen and how can I avoid it?

Since Firefox (2 and 3) and MSIE 7 started using Google’s (and others) system for blocking sites that produce harmful web pages the problem with SQL-injections have been put on the spot.

What happens is that an attacker hacks a site by placing their own SQL-code into the database of the victim system. Instead of just performing a DOS (denial of service) attack bringing the whole site down by for instance deleting all the tables or doing something else harmful to the site the attacker plants client side browser code in the database making all visitors run client side code that will infect their computer with a virus. This virus may do everything from listening in on traffic between the client (web browser) and bank applications, to connecting the client system to a botnet.

Needless to say, the SQL-injection attack has become a problem not so much for the owner of the originally defunct site as for the visitors to said site. (Although users of the web should not underestimate the consequence of a good virus protection, system update policy and secure browsing policy).

Since the owner of the vulnerable software won’t notice any detour from business as usual (and neither will most infected clients), nobody is the wiser to the problem.

This is why Google (and others) have started evaluating (and flagging) sites with bad content, and why Firefox and MSIE (and probably others) have started blocking them.

What is an SQL-injection?

The short explanation (hinted above) is that an SQL-injection is an attack where the attacker inserts their own SQL code into the attacked system, and thus alters the database content of the attacked system. Either wrecks havoc by destroying part of or the whole system, or by inserting virus spreading code onto the pages of the attacked site (if their content is stored in the database).

How is an SQL-injection attack performed?

There are two major ways of doing this (and in order to follow this part of the conversation you will need to know a bit of SQL).

The first method of performing an SQL-injection is by manipulating the input to different kinds of forms on the site (search forms, contact forms, and other places where the user can put information into the system).

To understand this attack you need a basic understanding of SQL.

Imagine we have a database table with products, each having a color, and we want to list all products that are ‘green’. This would be done with the following question:

SELECT * FROM products WHERE color = 'green';

Each database command is ended with a semicolon (;), and all literal strings are enclosed by single quotes (‘). So issuing two commands in a row would look something like:

SELECT * FROM products WHERE color = 'green';
UPDATE products SET hasBeenSearchedFor = 'true' WHERE color = 'green';

Notice the semicolons and the single quotes. You do not need to understand what the commands do in order to understand the rest.

Now imagine that we get the value ‘green’ from an application the user can input data into. As long as the user types things like green, red, blue everything is safe, but what would happen if the user typed in the following as a color?

'; do harmful thing to database; '

In an unprotected system the SQL-string is usually tacked together one part after the other without checking if the search parameter is valid or sane. Imagine the search command is built in the following way (double quotes are used in most systems to create strings, they are not to be confused with the single quotes of the database query):

sql = "SELECT * FROM products WHERE color = '" + colorValue + "'";

Now if a user would put the above value into the color search (placing it in “colorValue”) the value of the sql string (and what would be passed on to the database would be):

"SELECT * FROM products WHERE color = '" +
          "'; do harmful thing to database; '" + "'"

This in turn would evaluate to:

SELECT * FROM products WHERE color = ''; do harmful thing to database; ''

I.e. select all products with an empty color value, then “do harmful thing to database”. After that the SQL-server will encounter the empty quotes and issue an error.

If the database question is executed in a transaction all changes will be rolled back, however this is a rather weak defense against SQL-injections since it is possible to input values that will create three valid commands easily. (I’ll leave that up to the fantasy of the reader!)

The second way of performing an SQL-injection attack is to tack on values to numerical input to the system. Pages that display products, user profiles, or any other information easily mapped to a row in a database table are usually candidates for this kind of attack.

Imagine a page that displays a product profile. It might be called with the following URL:

http://www.mysite.com/showProduct?productid=123

The “productid” value will then be passed on to make the following database question:

sql = "SELECT * FROM products WHERE id = " + productid;

Here the attacker does not even have to add a single quote to get an extra SQL-command. All they need to do is add a trailing “;” and they’re in. The only complicating factor is that the URL used to call the system will have to be URL-encoded in order for this attack to work, but that’s far from a problem even for an unskilled attacker.

How do you protect against SQL-injections?

The key concept is: never, NEVER, NEVER, trust input from a user!

That’s right. NEVER TRUST THE USER.

Don’t ask what-if a user tries to gain access to our system.

Say WHEN the user tries to gain access to our system, then we’re gonna….

The short, technical answer (for Java, .NET and similar languages) is to NEVER build SQL-strings like shown above. Use “prepared statements” or similar constructs where the input variables can be tested by JDBC (or ADODB or LINQ or similar framworks).

Another safe way to go is to use stored procedures. These are not just optimized for speed and performance, they are also, almost always strongly typed, disallowing the kind of problems displayed above.

If neither of these are feasible always make sure the input’s single quotes are filtered away or “escaped”. Escaping a single quote means that all databases have support for using single quotes as values in a table column, if you prepend them with a backslash (\) or use double single quotes (”, that’s two single quotes). Do this programatically before sending the data on to the database.

Protecting against attacks on pages with numerical input is even simpler. If there’s a number input value, make sure it is numerical by translating it into a number before passing it on to the database (input from web applications are almost always sent as strings, but if a value should be a number, make sure it is!)

Part from this a sound backup and restore policy is a sure way to not only protect hours of time invested in putting information into the system but the users trust in the system, and the time it will take to get a blocked site back up on its feet.

Read more about SQL-injections here: http://en.wikipedia.org/wiki/SQL_injection

The problem is that the FTP client (ftp) doesn’t offer much to help (like recursive downloads, or mapping up the directories on the client side with those on the serverside, etc).

I searched and I found this thread:

http://ubuntuforums.org/archive/index.php/t-378221.html

…with this excellent snippet (posted by Mr. C.):

wget -r –ftp-user YourUSERNAME –ftp-password YourPASS ftp://FTPSITE//dir/’*.html’

If you want to download something other than *.html, you can change the file name pattern as you would expect.

If you want to add more directories, simply add them, but keep track of the number of slashes (“/”).  There should be only one after the new directory names (at least that’s how I made it work.  It may work wonderfully regardless of the number of slashes, but then again, why challenge fate?)

Happy FTPing!

Read more on todotnet.com

A UUID, Universally Unique Identifier, is a hexadecimal number divided into five sections. A UUID has the special quality that it is universally unique. This means two people on each side of the world could create a UUID each at the exact same time, and still be sure their UUIDs are not identical. In fact they can create a large number of UUIDs and still be sure they are not identical. (The same goes for two people on the same server.)

This quality makes UUIDs a perfect tool for assigning unique IDs to web pages or other Internet resources (in fact any resource of any kind, your dog, the cuttlery in your drawers, you name it.)

This could be done like this:

Step 1: Place the UUID on the page

First a UUID has to be put on the webpage, perhaps with a meta-tag, or with plain text on the page.

With a meta tag it could be done like:

<meta name=”UUID” content=”8523813a-7c47-4cd9-ad78-09c14dfb505f”/>

Or on the page, like:

UUID: 8523813a-7c47-4cd9-ad78-09c14dfb505f

Step 2: Find the UUID

The second step would be to make sure every time a program stores a URL to the page it also stores the UUID. (When creating bookmarks, or linking from one site to another etc).

So, once the page get lost, either because the link has changed, the page has been moved or something similar, the browser (or site) can use the UUID to find the page again.

The second step obviously demands a search engine (or some other central registry) that utilizes UUIDs in it’s index since the system does require some kind of central processing for keeping track of a UUID-to-page-link.

A UUID is not a particularly good URI since even UUIDs generated at the same host just a few seconds apart are still totally different from each others (this actually depends on implementation, but one should not assume UUIDs from the same host shares any similarities).

This however is also one of the strengths of UUIDs since it means an Internet resource should be possible to locate regardless of its physical location (in a contrary to ordinary http-URLs that are tightly bound to their location — they start with the server name).

Since a UUID (per definition) is universally unique, it is fairly simple to generate one wherever you are, and use it in a page, be sure there are no duplicates and locate the exact page of the UUID again.

A Google experiment

I’ve placed the text “UUID: 8523813a-7c47-4cd9-ad78-09c14dfb505f” on this page. (Several times now). As far as I’ve been able to discern, Google indexes even such arbitrary information as UUID data (the exact string “8523813a-7c47-4cd9-ad78-09c14dfb505f” to be precise, check out this page with a discussion on how to use UUIDs to make pages unique… It has nothing to do with this discussion but is an interesting example on how UUIDs could be used with Google).

By searching for “8523813a-7c47-4cd9-ad78-09c14dfb505f” it should be possible to locate this page… (see if it works? — Give Google time to index the page though… Update: the above link seems to not work, but this one [searching for the UUID with "-" replaced to space -- or "+"], however, does…)

Finally

The page localization should work regardless of the page’s position, site, or anything. In fact, as long as the UUID is still there, it should even be possible to place this text in a document of type Word/OpenDocument/PDF or any other format a search engine can index, and the text would still be possible to find with nothing but the UUID.

Obviously the end result of this technology would be that there is no “search-engine-in-between” but instead whenever the link is lost, the caller goes to the central repository/search engine (or some other place) and locate the page, then links to it automatically. It should even be smart enough to retry until it finds a link that works if a UUID has several possible links.