Alik Levin's : Input Validation

Security Code Review – String Search Patterns For Finding Input Validation Vulnerabilities

alikl — Fri, 11 Jul 2008 14:24:53 GMT

Well defined set of search patterns helps significantly reduce time (cost) when performing security code inspections. This post focuses on input validation vulnerabilities commonly found in ASP.NET web applications.

SQL Injection and Cross Site Scripting (XSS) String search patterns

SQL Injections and XSS attacks are most common that exploit improper data access and lack of output encoding. Following are the how-to’s on finding these vulnerabilities:

Input Validation vulnerabilities String Search Patterns

To search and find security vulnerabilities you start asking questions or better yet create a list of the questions. Here is the example how - Generate Your Own Security Code Review Checklist Document Using Outlook 2007.

Use search utility similar to FindStr to perform your searches (look at Performing Text Searches). When Visual Studio is available then you can use it - Visual Studio 2005 As General Code Search Tool. Any other search tool is just fine. Following are the most common questions and search patterns.

Does the code rely on client-side validation?

If the code does not use Validators or Regex there is a potential vulnerability. Review each control how it is validated for type, length, range, string format. In the searches I assume there is no inline code and developers use code behind technique to separate markup from code.

ASP.NET pages

findstr /S /I ".Validator" *.aspx

User Controls

findstr /S /I ".Validator" *.ascx

Source code

findstr /S /I "Regex" *.cs

Is the code susceptible to canonicalization attacks?

Review that there is no external input involved in building paths and file names.

findstr /S /I “File" *.cs

findstr /S /I “Path" *.cs

Does the code validate data from all sources?

Using Cookies and QueryStrings poses a risk of the tampering threat (review STRIDE Explained to understand threats). If there is a use of Params property there is a chance for CSRF attack - Cross-Site Request Forgery Attack explained

Cookies

findstr /S /I “Cookies" *.*

Query Strings

findstr /S /I “QueryString" *.*

Params

findstr /S /I “Params" *.*

Does the code use MapPath?

If there is a usage of MapPath review that it does not use external input parameters and it is restricted to access only application file space. Make sure its third parameter set to false.

findstr /S /I “MapPath" *.*

How To Mitigate Input And Data Validation Vulnerabilities

Below are detailed step-by-step guidelines for writing code that is not vulnerable to SQL Injections and XSS attacks:

How To: Prevent Cross-Site Scripting in ASP.NET

How To: Protect From Injection Attacks in ASP.NET

How To: Protect From SQL Injection in ASP.NET

How To: Use Regular Expressions to Constrain Input in ASP.NET

Microsoft Anti-Cross Site Scripting Library V1.5

Share Your Practices

If you’ve got more search patterns to suggest – please do so! Let’s make the World [Wide Web] a more secure place together.

My Related Posts

WCF Security - Input/Data Validation Using Schemas

alikl — Sun, 25 May 2008 17:52:48 GMT

WCF offers very flexible approach of Input and Data Validation based on XML Schemas. The approach is flexible since the validation rules are expressed in form of XML schema and can be changed at any time without recompiling the solution.

I followed the steps detailed in How To: Perform Message Validation with Schema Validation in WCF and ended up with another working sample (imagine that!).

It took me a bit to struggle with the schema thing and then enabling debugging info on the service side (remember, WCF is secure by default) to understand what's going on and why it fails time after time.

In the end me and WCF made friends and I'd thought it'd be good to share with you the Visual Studio project. Download it here from my SkyDrive and save yourself some time.

My related posts

WCF Security - Input/Data Validation Sample Visual Studio Project

Enjoy.

WCF Security - Input/Data Validation Sample Visual Studio Project

alikl — Sun, 25 May 2008 14:17:44 GMT

Input and Data Validation is one of the core security principles. WCF is no exception. To get most out of WCF in secure way one must implement proper Input and Data Validation.

I was following instructions on How To – Perform Input Validation in WCF compiled by patterns&practice team lead by JD Meier.

In a nutshell the process consists of creating 3 classes and tweaking a config file a "bit".

From the guide:

Step 4 – Create a Class That Implements the Validation Logic
Step 5 – Create a Class That Implements a Custom Endpoint Behavior
Step 6 – Create a Class That Implements a Custom Configuration Element
Step 7 – Add the Custom Behavior to the Configuration File
Step 8 – Create an Endpoint Behavior and Map It to Use the Custom Behavior
Step 9 – Configure the Service Endpoint to Use the Endpoint Behavior

I ended up with working sample built with Visual Studio 2008. I though it'd be good idea to share it to help you boost your productivity.

Grab the Visual Studio project on my SkyDrive here.

Enjoy

Quickly Find And Fix Cross Site Scripting (XSS) Vulnerabilities In Your ASP.NET Application.

alikl — Mon, 17 Mar 2008 15:56:00 GMT

Want to quickly check your ASP.NET Web application for Cross Site Scripting (XSS) vulnerability?

It is pretty easy with the knowledge and tools you already have. This post describes how to quickly find and fix most of XSS vulnerabilities in your code.

Why XSS vulnerabilities are possible

XSS vulnerabilities are possible when un-sanitized data printed out on the page. From what I witness when I do security code inspections most cases can be summarized to two most common:

Using DataBinder.Eval function:

<%#DataBinder.Eval(Container.DataItem, "TEXT") %>

Assigning to Text property of the control:

Label1.Text = TextBox1.Text;

[Update 20.7.08] Assigning to Text property of the control:

<%=myStringGoesHere...

How to quickly find XSS vulnerabilities

Above patterns are easily identifiable using any strings search utility. I use Visual Studio 2005 As General Code Search Tool to find such vulnerabilities. When Visual Studio is not an option, just use FindStr, here is an example - Code Inspection - First Look For What To Look For.

Run your search for ".Eval(" and then for ".Text =". You might want to modify slightly it as some folks omit space before "=" or other minor changes.

Use searches similar to these:

findstr /S /I ".Text =" *.cs
findstr /S /I ".Eval(" *.aspx
findstr /S /I ".Eval(" *.ascx
[Update 20.7.08] findstr /S /I "<%=" *.aspx

Ran your search yet? What do you see? Scared?

How to quickly fix XSS vulnerabilities

The fix is pretty simple - just apply Html Encoding to both cases. The best is using freely available Microsoft Anti-Cross Site Scripting Library V1.5. Note that ASP.NET’s Server.HtmlEncode is not the safest one as it only encodes <,>,",& characters which is not sufficient to protect against all possible attacks.

My related posts

AJAX Security - Client Side Validation Is For Usability Only, Not For Security

alikl — Wed, 03 Oct 2007 15:29:39 GMT

“As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”
Ralph Waldo Emerson

AJAX is another technique among myriads of others to present information and to send it back to server.

In Driver's Guide vs. Owner's Manual JD Meier provides great run down about the difference between "How things work" vs. "How to get most out of it".

Here is an example of how to apply it in practice:

In ASP.NET AJAX Role Application Service – Visual Studio 2008 (Orcas) David walks through new feature introduced in Orcas - AJAX Roles service. It provides also some sample. This is Owner's Manual explaining how things work:

function onLoadRolesCompleted(result, userContext, methodName){ if (Sys.Services.RoleService.isUserInRole("Administrator")){ $get("adminView").style.display = "block"; } }

In ASP.NET AJAX Roles and Security Michael comments on the above features pointing out the importance of server side role membership validation. This is Driver's Guide for safe and secure driving:

"You have to test ALWAYS on the server-side code if the user has the needed user rights to execute your code."

Some server side techniques to test server side code:

Here is another example for not following core security principle of server side validation:

How To Hack WCF - New Technology, Old Hacking Tricks

Creating a Parameterized Query In Visual Studio

alikl — Mon, 28 May 2007 07:10:00 GMT

Creating parameterized queries is one of the major countermeasures to SQL Injection attacks (not the ultimate but major).

I always did it in old fashion way - using code only and I am ashamed I never utilize advanced productivity features of Visual Studio.

Beth Massi does great job explaining how to build parameterized queries in her Creating a Parameterized Query post. I must do some critics though here - I would really love to see other example rather creating custom login form, say products catalog. Building custom authentication scheme is a surest way to disaster. I must admit that Beth put proper disclaimer though:

(By the way, this example does NOT demonstrate a secure way of writing login forms. We'll be passing what the user enters directly into the database which stores the password in clear text. It is NOT safe practice to store clear text passwords in your database. I'll post a follow-up that talks about techniques we can use to protect users' passwords, especially if we need to store them in a database. For now, let's concentrate on how we add parameterized queries to our TableAdapters.)

How To: Protect From SQL Injection in ASP.NET

How To: Protect From Injection Attacks in ASP.NET

Good read, looking forward to see the post on passwords

Security Code Inspection - Eternal Search For SQL Injection

alikl — Sat, 31 Mar 2007 23:04:00 GMT

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:

Code Inspection - First Look For What To Look For

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 http://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.

Use FxCop's ReviewSqlQueriesForSecurityVulnerabilities

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

XSS? - Do not Make Me Laugh, We Use WinForms

alikl — Mon, 26 Mar 2007 00:16:45 GMT

Reposted from XSS? - Do not Make Me Laugh, We Use WinForms

I find myself sometimes (actually too many times...) in situation explaining people of impact of Cross Site Scripting (attack) attacks as a result of importer encoding of user input (vulnerability) and how to counter this attack properly. Once all parties understand this everybody feels great relief since "our app is not web app - we use WinForms". Great!! The threat is mitigated by removing the feature of rendering HTML output...

"Hold it, you told me that your system presents to end user different types of documents, right?"

"Right, so?"

"Do you show HTML docs too?"

"Sure!"

"Great, and what do you use for it?"

"WebBrowser control, of course"

"I get it... So if you get HTML doc, it might include some script like this one:

that can render as follows, right?"

"... right..."

How one prevents scripts running inside the WebBrowser control?

I did not find an easy way to control it other than using PINVOKE described here - http://msdn.microsoft.com/workshop/browser/hosting/wbcustomization.asp?frame=true Here is another post on that one - http://slingkid.blogsome.com/2006/05/26/ (that actually points back to the above link but has good interop example) and another discussion here - http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=66493&SiteID=1

Cheers

Good Chance For Canonicalization Attack When Using Path.Combine()

alikl — Fri, 16 Mar 2007 01:31:00 GMT

In my previous post, .Net Assembly Spoof Attack, I've described potential DLL hijacking/spoof attack when using reflection for dynamically loaded assemblies.

Today I was reviewing some project where I stumbled on exactly such case. One thing that caught my eyes was that path to reflected DLL, the one to be loaded dynamically was built like this:

static void Main(string[] args)
{

string dllName = Console.ReadLine();

   while (!dllName.Equals("exit"))
   {
      string path = @"C:\DLLS\"

      //BUILD FULL PATH TO ASSEMBLY TO LOAD DYNAMICALLY USING Assembly.LoadFrom
      string fullDllPath = Path.Combine(path, dllName);

      Console.WriteLine("FULL PATH IS: " + fullDllPath);

      dllName = Console.ReadLine();
   }
}

Let me run it and see what happens if I provide expected DLL name say, alikl.dll:

And now let's provide something less expected like Z:\XACKER\ATTACK.DLL:

It means that if we supply full path as second parameter to Combine method it will ignore the first parameter.

How to validate?

1. Check the path for goodness using Path.GetFullPath() comparing result to "C:\DLLS" in our case

2. Sign your assembly and explicitly check it's evidence - example is here .Net Assembly Spoof Attack

More resources:

Canonicalization Lab (includes code and video by Keith Brown)

How To: Protect From Injection Attacks in ASP.NET

Enjoy

How To Hack WCF - New Technology, Old Hacking Tricks

alikl — Sun, 04 Mar 2007 23:11:00 GMT

First of I'd like to thank Guy for his excellent screencast - very convenient, so thanks.

Specifically I liked introductory screencast for WCF which can be found here: http://blogs.microsoft.co.il/blogs/bursteg/pages/WCF-Introduction-Demo-_2800_ScreenCast_2900_.aspx

It is dubbed in Hebrew, but the screens are flipping in so logical way so that one who does not understand Hebrew will be fine - go for it - recommended a lot for WCF newbies like me.

My interest was to understand the pipeline that the WCF Message goes through before it is put on the transport. The idea was to inject some custom modules (Inspectors) in the pipeline. Why? Is not it clear? To mess around with the message - tamper it in it raw format before it goes down to the transport signed and protected. Why? To show that it DOES NOT matter what communication technology you use - HTTP, Remoting, MSMQ, WCF, RMI, CORBA, DCOM, MQ, <<fill in your own here>> - the basic principle of VALIDATING INPUT ON THE SERVER SIDE is immutable.

Here I showed it for Web Services App Architecture with Security in mind - Video, Part I (that was easy - Fiddler is of much help here)

Then remoting came along - same result, here App Architecture with Security in mind - Video, Part II

Now it is mighty WCF.

I used excellent demo from Madhu here http://blogs.msdn.com/madhuponduru/archive/2006/07/19/671922.aspx that explained how to build IClientMessageInspector (NOTE - demo that works!)

So here is the service contract:

and the implementation:

and the client side validation:

here is the client rejects the input:

and here is the result of server processing for good input:

after adding the custom message inspector, I am offered to tamper the massage before it is sent to the service and the resulting reply from the service is in red at the bottom:

Conclusion

Does that mean that the communication technologies are bad? - NO, it is the way WE use it.

Here is an basic example for input validation in Web Services Web Service Input Validation - it has link to regex usage that you can use on the server side for input validation.

Enjoy

Alik Levin's : Input Validation

Security Code Review – String Search Patterns For Finding Input Validation Vulnerabilities

SQL Injection and Cross Site Scripting (XSS) String search patterns

Input Validation vulnerabilities String Search Patterns

Does the code rely on client-side validation?

Is the code susceptible to canonicalization attacks?

Does the code validate data from all sources?

Does the code use MapPath?

How To Mitigate Input And Data Validation Vulnerabilities

Share Your Practices

My Related Posts

WCF Security - Input/Data Validation Using Schemas

My related posts

WCF Security - Input/Data Validation Sample Visual Studio Project

Quickly Find And Fix Cross Site Scripting (XSS) Vulnerabilities In Your ASP.NET Application.

Why XSS vulnerabilities are possible

How to quickly find XSS vulnerabilities

How to quickly fix XSS vulnerabilities

My related posts

AJAX Security - Client Side Validation Is For Usability Only, Not For Security

Creating a Parameterized Query In Visual Studio

Security Code Inspection - Eternal Search For SQL Injection

XSS? - Do not Make Me Laugh, We Use WinForms

Good Chance For Canonicalization Attack When Using Path.Combine()

How To Hack WCF - New Technology, Old Hacking Tricks