I’m afraid that I’ve got some bad news. You can no longer pre-order Securing SQL Server 2nd Edition from Amazon.
Instead you have to settle for ordering the book outright and having it shipped to you. That’s right, no more being a pre-order book, it’s published and available to be shipped directly to you. Currently Amazon is selling the book at full price which is $49.95, but if you have Amazon Prime it is available for Amazon Prime shipping. Because it is considered to be a text book you get a $5 Amazon MP3 Credit (what ever terms and conditions that Amazon chooses do apply).
This is a totally updated edition of the book including all sorts of new information about security within SQL Server 2012. I of course cover things like how to secure AlwaysOn Availability Groups, how to use user defined server roles, contained users, etc. I also dive into how to properly secure SQL Server Reporting Services and SQL Server Analysis Services so they can’t be used to access data that people shouldn’t have access to.
All in all this book is much larger with Amazon showing it at 408 pages compared to just 272 pages for the 1st edition. If you find someone cheaper to purchase it make sure that you are in fact ordering the second edition. The ISBN number is 1597499471.
I hope that you pick up a copy of the book and that it is useful for you in securing your SQL Server environment.
I’m pleased to be able to announce that the 2nd edition of Securing SQL Server is going to be available soon. It’s just been made available for pre-order on Amazon.com. The second edition comes in at about 350 pages (according to Amazon, I don’t actually have a copy of it yet) while the first edition came in at about 270 pages so there has been a LOT of material added to the book.
While a lot of the new information is focused on SQL Server 2012, there is also a lot of new material which relates to older version of SQL Server including chapters on SQL Server Analysis Services and SQL Server Reporting Services, information on Instant File Initialization, EXECUTE AS, Database Firewalls, SAN Security, Actual Data Security (no idea how this got missed the first time around, but that’s to Brent Ozar for pointing it out).
As far as the SQL Server 2012 information you’ll find updated information about the SHA2 hashing algorithms, Securing AlwaysOn Availability Groups, Security and SQL Server Clustering, Security and Contained Databases and a lot more.
If you already have a copy of the 1st edition I encourage you to take a look at the second edition as well. I know that it’s really soon for a second edition of a book (the first edition just came out February 2011, but this new edition comes on the release of SQL Server 2012.
Hopefully you pre-order you copy today.
P.S. Yes this edition will be available for the Kindle as well, that takes a little time. As soon as I know that it’s been posted for the Kindle (usually happens a little after Amazon gets the physical books) I’ll post another announcement here.
P.P.S. If you visit my SecuringSQLServer.com site I’ve updated everything there for the new edition. You can always find the old edition listed on the Other Books page on that site or on the Books page on mrdenny.com.
There is another massive SQL Injection attack going around. This time hitting 180k ASP.NET websites. The article which I referenced has a decent write up on the actual attack and it links to a post which has detailed information about the attack. However the article on IT World gives some really poor advice on how to protect yourself from a SQL Injection attack.
There’s no easy way to fix the vulnerability of the database to this attack except to “harden” the database by applying all the patches and making all the security requirements consistent. Monitoring the database for unusual activity is important, too.
Patching SQL Server will NOT prevent SQL Injection attack, at all. The SQL Server isn’t the attack vector for a SQL Injection attack, the web application is the attack vector. By the time the SQL Injection attack gets to the SQL Server database (or any database) it’s too late.
SQL Injection is actually really easy to protect yourself from. Simply stop using dynamically generated SQL and instead start using parametrized queries (also called bound queries). That’s it, that’s the big secret. Yes I understand that writing your .NET code as parametrized queries is harder to write than just doing string concatenation and running the query, but getting your site attacked and putting malware on your customers computers because you didn’t want to do a little typing is just no excuse.
As this is a blog about my book “Securing SQL Server” here’s the sales pitch. In the book I talk all about how to use parametrized queries. It really isn’t that hard there is lots of sample code on how to do it. You don’t need to use stored procedures to use parametrized queries. You can do it with normal dynamic SQL as well, it works basically the same.
In case you didn’t get my point yet, parametrized queries are the ONLY WAY that you can 100% be sure that you are protecting yourself from SQL Injection attacks. If you can’t find some links on how to use parametrized queries here are a few links for you PHP, .NET, and more .NET.
Apparently Barracuda (who is in the network security business) had one of their applications broken into this week as reported by CNet. While no source code was stolen from Barracuda, it still has to be embarrassing to have names and email addresses of employees, leads and partners to be downloaded all thanks to a poorly written PHP application. Passwords were also downloaded as part of the data dump, but the passwords were only stored as MD5 hashes. However MD5 isn’t considered to be very secure any more (which is one of the reasons that SQL Server “Denali” is including SHA2 which is still considered to be secure).
Apparently the website which was attacked is normally secured using a Barracuda Web Application Firewall, but it was taken offline during a maintenance window on Friday night (April 8th, 2011). On Saturday night at about 5pm a script being crawling the website looking for SQL Injection weaknesses, which is found about two hours later.
Sadly this isn’t the first SQL Injection attack to happen recently. Just a couple of weeks ago MySQL.com’s website was attacked also using SQL Injection and a large amount of information was taken from their database as well.
You can read more about the Barracuda breach on CNet or on Barracuda’s own blog.
For those of you that were wondering, SQL Server isn’t the only platform which can be attacked via a SQL Injection attack. Apparently the MySQL.com website which hosts the official distribution channel for the MySQL database platform was attacked using good old SQL Injection earlier today (notice sent out via seclists.org including their schema).
Often I hear from MySQL professionals that MySQL isn’t susceptible to SQL Injection attacks. Apparently not only is it susceptible to SQL Injection attacks, but the company that writes the MySQL engine can’t correctly secure their website from being attacked. According to sucuri.net the “customer view application was used as the entry point, where the attackers were able to list the internal databases, tables and password dump…”. Not only was the password dump captured and posted only, but people have begun cracking the passwords, and some of these passwords are stupidly simple. The account sysadm (which I assume is pretty important) has a password of “qa”.
Apparently the Director or Product Management (who has 20+ years experience with most database platforms) used a 4 digit numeric password (probably his ATM pin code) as his password.
Needless to say, if you have an account on mysql.com and you use that password anywhere, you should probably change that password anywhere else that you use it.
If you think that your application is susceptible to SQL Injection attack, I recommend chapter 6 (SQL Injection Attacks) of “Securing SQL Server” which talks about how to prevent SQL Injection attacks. The examples which I provide are not SQL Server specific and the techniques shown to prevent SQL Injection attacks can be used against pretty much any relational database platform.
UPDATE (1pm PST 2011/03/27): Apparently the SSL certificate for logging into the MySQL.com website expired a month ago. The reason that I found this was that I was going to try and log in with my normal passwords (I’m pretty sure I have a mysql.com account) but with this error message, I’m not so sure about that. It’s probably OK, but still…