Security Code Inspection - Eternal Search For SQL Injection

  • Article

Here are couple of techniques I used for searching hints of SQL Injections in .Net apps.

The basic approach is described here https://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:

 

  • Look inside source code

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

from https://msdn2.microsoft.com/en-us/library/aa302437.aspx

FindStr uses the following command-line parameters:

  • /S — include subdirectories.
  • /M — list only the file names. No actual matches displayed.
  • /I — use a case insensitive search.
  • /D: dir — search a semicolon-delimited list of directories. If the file path you want to search includes spaces, surround the path in double quotes.

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.

Conclusion

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) 

:)

Enjoy