Showing posts with label research. Show all posts
Showing posts with label research. Show all posts

Tuesday, June 10, 2008

I was going to name this blog post “You’re only as strong as your weakest Linq,” but I thought that would be trite (but funny enough not to not mention).

Here it is: Linq is not impervious to Sql Injection, as claimed in Eliminate SQL Injection Attacks Painlessly with LINQ. While I agree with the statement in the article that to eliminate SQL Injection, eliminate SQL; the reality for Linq is not so cut and dried. The author states that “every SQL query that Linq executes on your behalf is parameterized.” This is not true. In fact, inline SQL is recommended to improve the performance of certain Linq queries:

· see http://shrinkster.com/z2q for improved performance

· see http://shrinkster.com/z2p for bulk updating issues with Linq

· and here’s a fun one – passing the query to a function, http://shrinkster.com/z2o ).

It should be easy to see that the use of the DataContext ExecuteQuery and ExecuteCommand functions are problematic. Here is my proof of concept code using a simple example – a LinqDataSource and a web page with unvalidated input:

I am using Visual Studio 2008 and SQL Server 2005. For the datasource I needed to create a DataContext. I created a database with a table named Trade to query against:

clip_image002

Then I created the DBML for the DataContext by adding LINQ to SQL Classes and added my table to the design surface :

clip_image004

I created a simple page (includes a LinqDataSource, a ListView, a TextBox and a Button):

Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" 
CodeFile="Default.aspx.cs" Inherits="_Default"
%>

<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<
html xmlns
="http://www.w3.org/1999/xhtml">
<
head runat
="server">
<
title>Untitled Page</title
>
</
head
>
<
body
>
<
form id="form1" runat
="server">
<
div
>

<
asp:Literal ID="Literal1" runat="server"></asp:Literal
>
<
br
/>
<
br
/>
<
asp:ListView ID="lstTrades" runat="server" DataKeyNames
="TradeID"
DataSourceID
="LinqDataSource1"> … template markup removed …
</asp:ListView
>
<
br
/>
<
br
/>
<
asp:TextBox ID="txtParams" runat="server" Width="352px"></asp:TextBox
>
<
br
/>
<
br
/>
<
asp:Button ID="btnExecuteQuery" runat="server" onclick
="btnExecuteQuery_Click"
Text
="Execute Query" />
<
asp:LinqDataSource ID="LinqDataSource1" runat
="server"
ContextTypeName="DriveHaxDataContext" TableName
="Trades">
</
asp:LinqDataSource
>

</
div
>
</
form
>
</
body
>
</
html
>

Default.aspx.cs

using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Diagnostics;

public partial class _Default : System.Web.UI.
Page
{
protected void Page_Init(object sender, EventArgs e)
{
this.LinqDataSource1.Selecting += new EventHandler<LinqDataSourceSelectEventArgs>(LinqDataSource1_Selecting);

}

void LinqDataSource1_Selecting(object sender, LinqDataSourceSelectEventArgs e)
{
DriveHaxDataContext driveHax = new DriveHaxDataContext();

if (this.txtParams.Text.Length > 0)
{

string sql = "select * from Trade where DealMember='" + this.txtParams.Text + "'";

            var trades = driveHax.ExecuteQuery<Trade>(sql);
e.Result = trades.ToList();
}

}

protected void btnExecuteQuery_Click(object sender, EventArgs e)
{
this.lstTrades.DataSourceID = this.LinqDataSource1.ID;
}
}

Here’s a quick look at results and how SQL injection causes more data to be returned.

No Parameters:


clip_image006


Use a name that I know has a trade, and return data:


clip_image008



Use a simple SQL injection statement, and return more data:


clip_image010


I only did a query statement for this post; I have repeated this with ExecuteCommand with DML operations.

As you can see, while Linq has probably reduced the scope of SQL injection vulnerabilities for those who use it, it is certainly not impervious. What hacks and shortcuts have you done for performance? Or because it was too time consuming to learn a new syntax. Linq and its functional programming aspects will be new to many developers. I personally like Linq and think it is a very useful technology, but you should be aware of both its strengths and its weaknesses.

Friday, May 9, 2008

First off, this is my blog for stuff for the OWASP .NET Project. It isn't moderated or officially endorsed by OWASP. And anything I write here, is my opinion or experience. Feel free to comment or criticize.

That being said, I'd like to use this blog as an online notebook to track progress and capture ideas that aren't necessarily ready for the OWASP .NET Project Wiki. I'd like to use this to preview articles and content and have anyone who is interested give me feedback. I will also use it for announcements about OWASP projects and OWASP events that are relevant to the .NET Project.

The status for the .NET Project as of 5/10/2008

Project Reorganization
I've spent more time on drafts and ideas. I put more links for pages up, but am still working on the content for roles. My draft is becoming more like a guide (and maybe that's what it should be).

I started a Google code project, OWASP .NET Content, to track content submissions, edits, reviews and archives. Specific status items can be found here. I'll keep it updated and when a critical mass is reached, I'll ping the mailing list. Each task will be listed, and you can get a status of what is being worked on. Feel free to join the project.

Media Outreach
I worked on the presentation and will put out "talking points" for the project (this is actually the current tasks that I am working on).

I'll put a link to the tracking document here. This week I'll send out a letter to the editor for MSDN, Code Magazine and hit up a few of the podcasts to see if anyone is interested. I'll also hit up OWASP again about their podcasting plan.

The difficulty I expect to have is that everything is a work in progress and everyone is short on time (this is why I started the Content project on Google Code, to get a good list of completed items to talk about).

Looking Ahead
Here are a few ideas that I'd like to explore beyond my commitment to the reorganization:

1. Measure / Countermeasure research for .NET technologies and platforms

I put up a page for OWASP .NET Vulnerability research. Has any of the stuff that we're putting into play been pen tested or is there sufficient guidance for security? Maybe, but OWASP .NET can be the clearinghouse for testing these projects.

2. Developing a Security Framework for ASP.NET

One of my personal fears is that as secure as I can make my site, or a client's site, that's all moot if you wander to a site that isn't secure. With the express editions of Visual Studio and the relatively cheap cost to run a .NET / SQL Server web application on a shared server, there's the potential of a lot of insecure code waiting to be exploited. I'd like to distill the SDL to a few checklists and push out a framework that gives a decent secure site. Some of the features that the framework would include:

  • Guidance navigator content (checklists for securing a site or service)
  • Provider model for security API (e.g. ESAPI .NET integration and realization
  • Webform and MVC flavors (including web controls using the API)
  • Unit tests
  • Access Control visualization - start with full exclusion and have an access control visualization for configuration and validation to test the controls.
  • Plugin / Provider framework for XSS / SQL Injection / Fuzzing / other vulnerability testing (ala NUNIT for penetration testing)
3. Interactive .NET Security Educational Materials

I've been using the Grava beta and it's a pretty engaging tool for education. It's obvious with the recent SQL Injection "worm" that applications are not being tested for basic security flaws. The problem is part tools and part education. And with the next generation of developers coming into the workforce, we have to provide the tools and education (and a discussion about consequences and ethics) to protect our users.

Comments are welcome.