June 19, 2008 - 00:36 UTC - Tags: security linq sql injection
The last couple of days I've been attending NDC2008(Norwegian Developer Conference) here in Oslo. Mats Torgersen's talk on LINQ under the covers was quite interesting.
Mats' talk was basically explaining how the compiler was transforming LINQ to suit the .NET CLR. He was using a combination of Visual Studio and Reflector to show the actual (de)compiled code in 3.5, 2.0 and 1.0 format.
One of the most interesting features of "LINQ to SQL" security wise, is that it completely separates data from control. As you might now, SQL injection exists only because control and data is mixed in dynamic SQL statements. This problem is often called a meta character problem, because a meta character is what separates control from data in the statement.
Interestingly enough the "from-where-select"-format of LINQ is not a string, but supports intellisense and separates the code from the data, by making the query language a part of the programming language. By doing this, and by generating prepared statements (parameterized queries) from the expression trees, using the "from-where-select"-format of LINQ will actually prevent you from writing code that is prone to SQL injection. In this sense LINQ protects you from SQL injection. That is actually quite profound. Not only is it easier to write and understand - it's also more secure.
Remember though, LINQ itself does not protect you against injection attacks. It all depends on how the expression tree is transformed to the query string used to fetch the data. LINQ to SQL uses prepared statements, but other LINQ providers may have errors that still allow injection attacks.
Comments closed for this post
Mats' talk was basically explaining how the compiler was transforming LINQ to suit the .NET CLR. He was using a combination of Visual Studio and Reflector to show the actual (de)compiled code in 3.5, 2.0 and 1.0 format.
One of the most interesting features of "LINQ to SQL" security wise, is that it completely separates data from control. As you might now, SQL injection exists only because control and data is mixed in dynamic SQL statements. This problem is often called a meta character problem, because a meta character is what separates control from data in the statement.
Interestingly enough the "from-where-select"-format of LINQ is not a string, but supports intellisense and separates the code from the data, by making the query language a part of the programming language. By doing this, and by generating prepared statements (parameterized queries) from the expression trees, using the "from-where-select"-format of LINQ will actually prevent you from writing code that is prone to SQL injection. In this sense LINQ protects you from SQL injection. That is actually quite profound. Not only is it easier to write and understand - it's also more secure.
Remember though, LINQ itself does not protect you against injection attacks. It all depends on how the expression tree is transformed to the query string used to fetch the data. LINQ to SQL uses prepared statements, but other LINQ providers may have errors that still allow injection attacks.
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
