SQLServerCentral.com / Discuss Content Posted by Robert Marda / Article Discussions / Article Discussions by Author / SQL Injection Attacks / Latest PostsInstantForum.NET v2.9.0SQLServerCentral.comhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 31 Mar 2015 16:05:48 GMT20RE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspx<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>One last statement perhaps, I've never seen a *NIX system crashed so hard, that root had no chance but reinstall, but I do have seen this happen to Windows system.<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>Agreed, we probably do need to carry on a different topic, probably on a Win centric site. ;) However, I have seen this happen... I've seen a Solaris box crash like this, and I've seen a Linux box as well. It's always very, very messy. <img src=icon_smile_sad.gif border=0 align=middle>K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Tue, 03 Jun 2003 07:54:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxHi Brian,I think we should stop here. We're somehow off-topic. One last statement perhaps, I've never seen a *NIX system crashed so hard, that root had no chance but reinstall, but I do have seen this happen to Windows system. Well, that seems to be more than enough stuff for a separate thread.Cheers,FrankTue, 03 Jun 2003 07:44:00 GMTFrank KalisRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxOut of the box installation is a stand-alone PC with the OS and 1 user account: the administrator. So in reality, until you create the user account (you wouldn't give a user root in a *nix system) or you join it to a domain, the end-user doesn't have rights to do anything. Keep in mind that OS files are protected, services aren't accessible, network and computer settings may be viewable, but they aren't changeable by an account that is just a member of users. Therefore, what the user can do is limited. Sure, the user can wipe out non-critical files (in the sense of the OS running), but then again, this can happen in the *nix world as well. When I create an account in the *nix world, thereby giving user access, usually the user has a home directory, etc. and it amounts basically to the same thing... not quite because the users tend to have access to files under \Program Files in the Windows world. So it's not as quite wide open as its painted to be.Also, from a SQL Server perspective, run a query to find out what the public role has access to. I also should point out that the guest account is active in the master database (it is necessary), meaning anyone you give the ability to log on to SQL Server has access to these tables and stored procedures.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Tue, 03 Jun 2003 06:42:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxHi Brian,thanks for correcting me!With out of the box installation the normal user has at least enough rights to crash his box ultimately <img src=icon_smile.gif border=0 align=middle>What I take from this, is that you need highly-skilled admins to get this job efficiently done. So you have three risk factors, the software, the hardware, and the 'human factor'.Nonetheless, I'd prefer the SQL Server (and *NIX) approach to deny the normal user 'anything' unless it is explicitly granted.Cheers,FrankTue, 03 Jun 2003 01:33:00 GMTFrank KalisRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspx<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>With an out of the box Windows2000 installation there are not specific user permission installed, that means the users can do everything unless he is denied this privilege. <hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>No, this isn't exactly correct. While the default permissions on the file system is Everyone - full control (although this gets tightened automatically in some cases, such as when you promote to a DC), users don't have full admin rights. They have normal user rights. This is true, of course, if they have a login to the system. Then they can access files but they can't do things like change network settings, stop/start services, change system properties, etc.Servers tend not to be an issue. The reason is because in order to gain access to the entire file system, one has to be able to log on locally (no shares for non-admin users by default). If they can, that's a physical security domain issue. Of course, if the user can physically get to the server, you're system is pretty much compromised right there (just as would be on most any OS).Workstations, on the other hand, can be. Join it to a domain and by default any authenticated user can log on (but then we've passed the definition of out of the box). There should be appopriate lock-down policies whether formal procedures or group policies or what-have-you from that point forward.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Mon, 02 Jun 2003 09:20:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxHi Brian,<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>Another indeed. Any well-known web server is vulnerable straight out of the box. The IIS Lockdown Tool is a start. It is not the cure-all. However, if sysadmins run it, it'll eliminate most all of the vulnerabilities script kiddies are going to target with their pre-built and downloaded programs. <hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>some time ago I had a discussion with our network admins on vulnerabilities. Correct me, if I'm wrong. What I remember from this was:With an out of the box Windows2000 installation there are not specific user permission installed, that means the users can do everything unless he is denied this privilege. Now, if that (even partially) is true, I'd prefer the *NIX approach to deny a user everything unless he is granted permission to.Cheers,FrankMon, 02 Jun 2003 02:37:00 GMTFrank KalisRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspx<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>If you're talking about ASP ISP one really huge security hole is the provider himself and his knowledge about the Windows OS he is using. I have a script utilizing the FileScriptingObject I used to test my provider and he fails the test.<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>Another indeed. Any well-known web server is vulnerable straight out of the box. The IIS Lockdown Tool is a start. It is not the cure-all. However, if sysadmins run it, it'll eliminate most all of the vulnerabilities script kiddies are going to target with their pre-built and downloaded programs. K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Thu, 29 May 2003 07:42:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspx<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>all database access should be done with command objects and stored procedures, and not dynamic SQL<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>Indeed. Unfortunately, there's a ton of code out there that isn't using Command objects. That was the root of the recommendation I made for my friend to pass on.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Thu, 29 May 2003 07:40:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxAs a developer-cum-dba, my training (and unfortunate self experience) has proven that all database access should be done with command objects and stored procedures, and not dynamic SQL. This prevents the SQL injection attacks, and gives you better application performance and maintainability as well. Wed, 28 May 2003 23:39:00 GMTgeoff_baRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxHi Brian,<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>Like I said, as a DBA, you're really hand-cuffed if the developer doesn't build the application securely. Hence the reason for code reviews. Pair programming, a la Extreme Programming, ain't a bad practice, either, so long as one of the programmers is versed in defensive programming.<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>not only SQL Security or app security is relevant. If you're talking about ASP ISP one really huge security hole is the provider himself and his knowledge about the Windows OS he is using. I have a script utilizing the FileScriptingObject I used to test my provider and he fails the test. If it is wanted I will post the script (of course, only for demonsration purposes only!!!!)Cheers,FrankTue, 27 May 2003 09:32:00 GMTFrank KalisRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspx<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>Has anyone ever been injected?<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>While I haven't, I have done security consulting after the fact. A friend of mine owns an ISP and he had a customer complaining that my friend's servers were insecure because data was appearing and disappearing in his database unexpectedly and not as his application would handle it. My friend, security paranoid that he is, knew the guy was running an ASP-based site using SQL Server as a back-end. My friend also knew the web server and the SQL Server were secure. So he called me in.It only took about two minutes of looking to see that his code was vulnerable to SQL Injection. I sent to my friend the links from NGSSoftware as well as a sample couple of links that demonstrated a successful SQL Injection attack on the web site. He quickly passed this on to the person in question.Like I said, as a DBA, you're really hand-cuffed if the developer doesn't build the application securely. Hence the reason for code reviews. Pair programming, a la Extreme Programming, ain't a bad practice, either, so long as one of the programmers is versed in defensive programming.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Tue, 27 May 2003 08:21:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxAnother great site to keep up to date with security issues is http://www.securityfocus.com . They offer also a great variety of mailing listsCheers,FrankEdited by - a5xo3z1 on 05/26/2003 08:46:14 AMMon, 26 May 2003 08:45:00 GMTFrank KalisRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxHi David,<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>I understand the principle of the above article, I just don't understand how someone could submit the commands to the server unless they already had access to the server. Can anyone throw some light on this?<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>just came across the thread. Maybe someone else above has already mentioned, but here are some of my thoughts.Consider a website where you validate yourself as legitimate user via a login page. This could be a great starting point for sql injection. If validation of user input AND error handling in your app is not properly, sql injection is not that hard to do, meaning you do not have to be an bitkid. Most of the ADO Error Messages are very descriptive.In my apps I don't use Adoconnection.Execute("SELECT....")If it comes to database access first thing is proper validation at app level. If validation fails, nothing happens. Next the input is passed to a Stored Proc. This means, better control on privileges, execution and so on. Here plugs in my original question whether you can use nested stored procs to validate input at a db level.In addition to Brian I would mention the single ' mark. When I was new to SQL Server it had given me plenty of headache until I recovered that all I need to do is replace ' by ''.I don't know exactly how to prevent SQL Injection. If your db is exposed to web you must make a trade-off between security and performance by definition. I think the articles I've posted are full of good advices. Has anyone ever been injected?Cheers,FrankMon, 26 May 2003 06:50:00 GMTFrank KalisRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxObviously, you lock down rights as much as possible.If the developer isn't doing proper input validation and isn't using proper coding technique, there isn't a whole lot you can do. The semi-colon (;) and the double dash (--) really kill you. For instance, you can't stop the fact that this gets passed:EXEC usp_mystoredprocedure 'Test';EXEC sp_password @loginame='sa', @new='password'SQL Server is going to read that semi-colon as a statement separator and break up the two statements. So if you tried to test in usp_mystoredprocedure, it does no good. Of course, with the proper security model, sp_password doesn't get executed. But whatever the user has the ability to do can be done. So as a DBA, you are heavily reliant on the developer.I'll be writing a security article on input validation that describes a real world issue I came across that dealt with a similar type of problem. K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Thu, 22 May 2003 11:41:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxThat was my question too. It looked like to use those injection attacks the user would have to have access similar to Query Analyzer. What is the best way to prevent this kind of injection attack? Are there ways to make sure the door closes before the injected SQL can get attached?Robert W. MardaSQL Programmerbigdough.comThe world’s leading capital markets contact database and software platform.Thu, 22 May 2003 11:32:00 GMTRobert W MardaRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxBy the way, an excellent web-cast that's a step-by-step walk through on how an attacker scopes out and attacks a box using SQL Injection: http://www.microsoft.com/usa/webcasts/ondemand/1765.aspThis was presented by SQLServerCentral.com's Brian Knight. Best SQL Injection web cast I've seen (and I've seen quite a few).K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Thu, 22 May 2003 10:46:00 GMTK. Brian KelleyRE: SQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspxYou're piggy-backing on legitimate access. In other words, a database call that is authorized is being made. You jump in on this call and add to it.Think of it in these terms: I have a building that requires badge access. I wait for someone to badge in, catch the door before it closes, and I'm in. The reason the door opened was because someone with legitimate access badged in. Because said person didn't make sure the door closed properly with no one else slipping through, I'm in.With SQL Injection, the input coming in to a web page (such as GetInfo.asp, for instance), isn't properly checked. Imagine where GetInfo.asp gets a field, ID. So the link looks something like:http://www.myserver.com/GetInfo.asp?id=7And the code just takes the 7 and does something similar to:SELECT * FROM Users WHERE ID = ?And the ? is of course replaced by whatever is coming in. If I append the following (I'll use regular characters instead of URL encoded):http://www.myserver.com/GetInfo.asp?id=7;EXEC sp_addlogin 'MyLogin', 'MyPassword'SQL Server will actually get the following passed to it:SELECT * FROM Users WHERE ID = 7as well asEXEC sp_addlogin 'MyLogin', 'MyPassword'The attacker is using a legitimate connection and hitching a ride.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1Thu, 22 May 2003 10:36:00 GMTK. Brian KelleySQL Injection Attackshttp://www.sqlservercentral.com/Forums/Topic12454-76-1.aspx<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>I'm sure you know this articles from http://www.appsecinc.com named Manipulating Microsoft SQL Server Using SQL Injection. Or Advanced SQL Injections in SQL Server Applications by http://www.ngssoftware.com.<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>I understand the principle of the above article, I just don't understand how someone could submit the commands to the server unless they already had access to the server. Can anyone throw some light on this? Thu, 22 May 2003 09:39:00 GMTDavid.Poole