Is this LINQ statment vulnerable to SQL injection?

Is this LINQ statment vulnerable to SQL injection?

var result = from b in context.tests
    where b.id == inputTextBox.Text
    select b;

where context is an Entity and tests is a table. I'm trying to learn LINQ and I thought that the benefit of it was that it wasn't vulnerable to sql injection, but some stuff I've see has said differently. Would I need to parametrize this LINQ statement to make it safer? If so, How?

Also would this be considered linq to sql 开发者_开发问答or linq to entities?

---

Short answer: LINQ is not vulnerable to SQL injection.

Long answer:

LINQ is not like SQL. There's a whole library behind the scenes that builds SQL from expression trees generated by compiler from your code, mapping the results to objects—and of course it takes care of making things safe on the way.

See LINQ to SQL FAQ:

Q. How is LINQ to SQL protected from SQL-injection attacks?

A. SQL injection has been a significant risk for traditional SQL queries formed by concatenating user input. LINQ to SQL avoids such injection by using SqlParameter in queries. User input is turned into parameter values. This approach prevents malicious commands from being used from customer input.

Internally, it means that when LINQ to SQL queries the database, instead of using plain values, it passes them as SQL parameters, which means they can never be treated as executable code by the database. This is also true for most (if not all) ORM mappers out there.

Compare these two approaches (totally pseudo-code):

string name = "' ; DROP DATABASE master  --"
run ("SELECT * FROM Authors WHERE Name = '" + name + "'") // oops!

// now we'd better use parameters
SqlParameter name = new SqlParameter ("@name", "' ; DROP DATABASE master  --")
run ("SELECT * FROM Authors WHERE Name = @name", name) // this is pretty safe

I suggest you dive deeper into what LINQ statements actually mean and when and how they get translated to the real SQL. You may want to learn about LINQ standard query operator translation, deferred execution, different LINQ providers et cetera. In case of LINQ, much like any abstraction technology, it is both fascinating and incredibly useful to know what's happening behind the scenes.

P.S. Everytime I see a question about SQL injection I can't help but remember this webcomic.

---

LINQ uses parameterized queries so it is not generally susceptible to SQL injection. Your example, for instance, isn't vulnerable.

---

The LINQ to Entities provider uses parametrized queries and is completely safe against SQL injection.

---

No. LINQ to Entities and LINQ to SQL handle the generation of SQL Queries to avoid SQL Injection. You can use LINQPad if you're curious to see what SQL statement gets generated when you run this query with various inputs.

Whether it's LINQ to SQL or LINQ to Entities depends on what your context object is, and cannot be determined from this code snippet.

The only time you need to worry about SQL injection in LINQ is if you're using the ExecuteQuery method to run a custom SQL query (see here). But at that point, you've moved away from the Language-INtegrated Query, and back into the world of generating your own strings.

---

LINQ To SQL generates a parameterised query so it protects against SQL injection attacks

---

Linq paramaterizes all queries, so isn't susceptible to SQL injection attacks. However you should still validate all of your user input as otherwise you will leave yourself open to cross site scripting attacks.