Database security & inegrity is an issue that should be taken very seriously by an organisation. I'm going to be, hopefully, brief and non-techy.....

SQL injection hacks are common knowledge and the ways to stop them are well documented (http://unixwiz.net/techtips/sql-injection.html).

There are many different Good Practice guidelines to also reduce the chance of compromising your server.

Let me tell you what has happened, briefly, when you clicked the link to read this blog. The web browser sent a request to the Finextra web server to look at a page. The finextra web server needed to obtain some information (i.e. my blog) from a database on one of our Finextra Database servers. To access this information, the web server provided a user name & password to the database server to gain permission to obtain that data.

This user name and password could be a potential weak spot. At Finextra we use a random combination of letters and numbers for our passwords to mitigate against brute force attacks.

We also use a unique user name for each database on the server - so if, somehow, a hacker gained the username and password for one of our databases we would be less compromised than if he'd gained access to all our databases. We also have clear limits on the functionality of those users.

There is another user that has access to your server, and that's the Server admin/root user. In SQL Server there is a user called, "sa" - or Super Administrator. This user has god-like powers to create and delete databases, add and revoke users and even remove all your backups. It is never, ever a good idea to use this user to access your server from your web server. It would give too much control to a hacker. The security implications are enormous.

So, where am I going with this blog? Well, here actually:

http://threestore.three.co.uk/broadband/

Hopefully, by the time you read this blog, the link will be working. But if it isn't then you can clearly see:

1. The user that's being used to connect to the SQL Server instance - in this case the sa user
2. The user's password.
3. The database server instance name.
4. The specific database that the user is trying to connect to.

What has happened here is that the user has failed to connect to the database , the web server didn't know what to do with this information - the programmers have not put any error handling in place, so the web server has just regurgitated some details to screen. Namely, the connection string it used to access the server.

In the image below I've removed the password to save someone's blushes!