Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
Here are couple of techniques I used for searching hints of SQL Injections in .Net apps.
The basic approach is described here http://msdn2.microsoft.com/en-us/library/ms998399.aspx. It is basically split into two major parts - preliminary scan and the detailed scan. The keyword is hotspot - find hotspot and investigate it accordingly. Hotspot can be something around SQL injection or XSS. I personally like calling it hints rather hotspot.
Here are some techniques I used during preliminary scan to find hints for SQL Injection:
This technique allows to dump all the strings from compiled assemblies. It is very useful when looking for sensitive data in it but along the way one can recognize funny things:
that can provide some hints for further investigation.
ILDASM and FindStr are our friends with this technique. Resulting dump can be investigated using ... Outlook 2007 - Security .Net Code Inspection Using Outlook 2007:
This techniques assumes you one knows what to look for - it can be hints gathered from previous step or just finding all instances of OdbcCommand, OleDbCommand, OracleCommand, SqlCommand, SqlCeCommand usage.
FindStr is of great help here and the syntax would look like : FindStr /S /M /I /d:c:\projects\yourweb "SqlCommand" *.cs
FindStr uses the following command-line parameters:
Incase where Visual Studio is at hand same result (I presume FindStr is used under the cover) can be achieved by pressing ctrl+shift+f. This command brings up "Find In Files" dialog box:
and the result is:
(file and the string match == FindStr /S /I /d:c:\projects\yourweb "SqlCommand" *.*)
Looking at the match one can decide to look further into it or not.
Run FxCop with ReviewSqlQueriesForSecurityVulnerabilities rule checked:
Do not include any other checks - FxCop consumes tones of memory, and it may be a problem with large projects that include many DLL's.
Seems like FxCop approach is most efficient since it knows how to get hold on those hints where XXXComand object is used and CommandText property includes string that was built dynamically.
Do not fall in trap of false positives and false negatives - tools are great but the best tool is between your ears
False positives - it is situation when the tool finds the issue but from detailed inspection it is not. For example, FxCop spots the code like this:
string sql = "SELECT NAME, DESCN FROM PRODUCT WHERE NAME ='" + searchCriteria + "'" SqlCommand cmd = new SqlCommand(sql, con);
Is it a problem? Depends where searchCriteria value comes from - if it is user controlled then YES, otherwise not [sure].
False negatives - it is situation where the tool does not find anything but the problem actually exists and only manual detailed scan can reveal it.
While false positives just consume more energy while manually inspecting the findings, false negatives leave bad stuff undiscovered, which is I think worse.
While tools are vital and usually boost the productivity when inspecting the code for security vulnerabilities, it is important to have right set of expectations from those tools - what it can and what it cannot do. Remember the best tool is between your ears (original version by JD)
Imagine if security was cool like Silverlight .... But security is not that cool, so the biggest challenge
Visual Studio 2005 has powerful search capabilities. One of my favorites is "Find in Files". Just hit
DIR /S /B /A:-D I use simple DIR command to generate file lists. It serves me in many scenarios. For
How to streamline the process of capturing security flaws during security code review? How to save time
Want to quickly check your ASP.NET Web application for Cross Site Scripting (XSS) vulnerability ? It
Well defined set of search patterns helps significantly reduce time (cost) when performing security code