Monday 18 August 2008

Hello again

I had a couple of questions from readers. I answered most of these on a 1:1 basis but there were a few common ones that I would like to address here.

The first question was “What could a successful SQL injection attack do?” Well, that is a good question and it very much depends on what your website holds. If it is a website containing pictures of your cats, then the worst that will happen to you is that you might have your website defaced. Your visitors might be attacked by maliciously uploaded HTML and scripts but that is unlikely to harm you – at least, not until you browse to your own site. Quite often it is the admin who checks the site. Not a good account to have compromised. What if it is not a website of your cats. Maybe your database is on the same machine as the internet information server or the Apache web server. That isn’t at all uncommon in small businesses. Windows Server Small Business Edition is designed to work that way. Ok, a successful SQL injection attack will give the attacker the ability to read any of the database records at least. If the rights are left at the default, then they can also write to the tables. If you have the xp_cmdshell enabled then they can rapidly install a remote admin tool and own the box. On small business server, the account used is normally an admin. An admin on a domain controller is a domain admin. You just lost your domain.

The second question that I got asked multiple times was where people learned these skills. Well, it is well known that hackers are exponents of open source – of course, so are many, many perfectly legitimate professionals and I have some open source software that I used daily. However, the hackers all love open source and they tend to be open with information too. Want to know how to hack? No charge! Just share the love at http://www.hackthissite.org/ and practice to your heart’s content.

So, what can you do to protect yourself? The good news is that there is quite a bit that you can do. The bad news is that a lot of this is risk reduction rather than risk elimination but anything that makes life harder for the bad guys is all to the good. There is more than this but these are very good starts.

1. Code review, at least of your web interfaces. So, imagine that you have a classic ASP app with a COM object called from the script running on an IIS server. The methods callable from the script have to be your main focus. Wherever you have user supplied text being appended into a SQL statement, there is a probable exploit. User supplied text needs to be validated before use. The validation rules are complex and hackers will look for a way around them.

2. Design with a compromise in mind. If your application were malicious, it should be able to do least harm. Does it need write access to all those tables? Probably not. A great many tables such as the web page content will never be modified by the web application. Why does the account that reads them have permission to write them? Limit accounts as much as possible.

3. The web facing systems should be in a domain with one way trust to the main domain if you have multiple domains – and for all but the smallest companies, the overhead is worth the security.

4. This one is a bit controversial. I know that banner adverts are a source of revenue. You can do some really good looking stuff with silverlight or flash and dynamic content. However, it is sometimes overkill and static HTML works and is safe every time.

I could talk about these things for hours and indeed, often have. However, that is it for today. If you want some advice, the contact number is on the website. The first 2 hours are free. Hard to beat that as a price point

Signing off

Mark Long, Digital Looking Glass

No comments: