If user input is inserted without modification into an SQL query, then the application becomes vulnerable to [SQL injection][1], like in the following example:

&lt;!-- language: lang-php --&gt;

    $unsafe_variable = $_POST[&#39;user_input&#39;]; 

    mysql_query(&quot;INSERT INTO `table` (`column`) VALUES (&#39;$unsafe_variable&#39;)&quot;);

That&#39;s because the user can input something like `value&#39;); DROP TABLE table;--`, and the query becomes:

    INSERT INTO `table` (`column`) VALUES(&#39;value&#39;); DROP TABLE table;--&#39;)

What can be done to prevent this from happening?

  [1]: https://stackoverflow.com/a/332367/

How can I prevent SQL injection in PHP?

Is there a catchall function somewhere that works well for sanitizing user input for SQL injection and XSS attacks, while still allowing certain types of HTML tags?

How can I sanitize user input with PHP?

Just looking at:

![XKCD Strip][1]
*(Source: https://xkcd.com/327/)*

What does this SQL do:

    Robert&#39;); DROP TABLE STUDENTS; --


I know both `&#39;` and `--` are for comments, but doesn&#39;t the word `DROP` get commented as well since it is part of the same line?

 [1]: https://i.stack.imgur.com/G0ifh.png &quot;Her daughter is named Help I&#39;m trapped in a driver&#39;s license factory.&quot;

How does the SQL injection from the &quot;Bobby Tables&quot; XKCD comic work?

Is there an SQL injection possibility even when using `mysql_real_escape_string()` function?

Consider this sample situation. SQL is constructed in PHP like this:

    $login = mysql_real_escape_string(GetFromPost(&#39;login&#39;));
    $password = mysql_real_escape_string(GetFromPost(&#39;password&#39;));
    
    $sql = &quot;SELECT * FROM table WHERE login=&#39;$login&#39; AND password=&#39;$password&#39;&quot;;

I have heard numerous people say to me that code like that is still dangerous and possible to hack even with `mysql_real_escape_string()` function used. But I cannot think of any possible exploit?

Classic injections like this:

    aaa&#39; OR 1=1 --

do not work.

Do you know of any possible injection that would get through the PHP code above?

SQL injection that gets around mysql_real_escape_string()

Let&#39;s say I have code like this:

    $dbh = new PDO(&quot;blahblah&quot;);
    
    $stmt = $dbh-&gt;prepare(&#39;SELECT * FROM users where username = :username&#39;);
    $stmt-&gt;execute( array(&#39;:username&#39; =&gt; $_REQUEST[&#39;username&#39;]) );

The PDO documentation says:

&gt; The parameters to prepared statements don&#39;t need to be quoted; the driver handles it for you.

**Is that truly all I need to do to avoid SQL injections?  Is it really that easy?**

You can assume MySQL if it makes a difference.  Also, I&#39;m really only curious about the use of prepared statements against SQL injection.  In this context, I don&#39;t care about XSS or other possible vulnerabilities.


Are PDO prepared statements sufficient to prevent SQL injection?

How do [prepared statements][1] help us prevent [SQL injection][2] attacks?

Wikipedia says:

&gt; Prepared statements are resilient against SQL injection, because
&gt; parameter values, which are transmitted later using a different
&gt; protocol, need not be correctly escaped. If the original statement
&gt; template is not derived from external input, SQL injection cannot
&gt; occur.

I cannot see the reason very well. What would be a simple explanation in an easy English and some examples?

  [1]: http://en.wikipedia.org/wiki/Prepared_statement
  [2]: http://en.wikipedia.org/wiki/SQL_injection



How can prepared statements protect from SQL injection attacks?

I&#39;m trying to put some anti sql injection in place in java and am finding it very difficult to work with the the &quot;replaceAll&quot; string function. Ultimately I need a function that will convert any existing `\` to `\\`, any `&quot;` to `\&quot;`, any `&#39;` to `\&#39;`, and any `\n` to `\\n` so that when the string is evaluated by MySQL SQL injections will be blocked. 

I&#39;ve jacked up some code I was working with and all the `\\\\\\\\\\\` in the function are making my eyes go nuts. If anyone happens to have an example of this I would greatly appreciate it.

Java - escape string to prevent SQL injection

I realize that parameterized SQL queries is the optimal way to sanitize user input when building queries that contain user input, but I&#39;m wondering what is wrong with taking user input and escaping any single quotes and surrounding the whole string with single quotes. Here&#39;s the code:

    sSanitizedInput = &quot;&#39;&quot; &amp; Replace(sInput, &quot;&#39;&quot;, &quot;&#39;&#39;&quot;) &amp; &quot;&#39;&quot;

Any single-quote the user enters is replaced with double single-quotes, which eliminates the users ability to end the string, so anything else they may type, such as semicolons, percent signs, etc., will all be part of the string and not actually executed as part of the command.  

We are using Microsoft SQL Server 2000, for which I believe the single-quote is the only string delimiter and the only way to escape the string delimiter, so there is no way to execute anything the user types in.

I don&#39;t see any way to launch an SQL injection attack against this, but I realize that if this were as bulletproof as it seems to me someone else would have thought of it already and it would be common practice.  

What&#39;s wrong with this code? Is there a way to get an SQL injection attack past this sanitization technique?  Sample user input that exploits this technique would be very helpful.

&lt;hr/&gt;

UPDATE:

I still don&#39;t know of any way to effectively launch a SQL injection attack against this code. A few people suggested that a backslash would escape one single-quote and leave the other to end the string so that the rest of the string would be executed as part of the SQL command, and I realize that this method would work to inject SQL into a MySQL database, but in SQL&amp;nbsp;Server 2000 the only way (that I&#39;ve been able to find) to escape a single-quote is with another single-quote; backslashes won&#39;t do it.

And unless there is a way to stop the escaping of the single-quote, none of the rest of the user input will be executed because it will all be taken as one contiguous string.

I understand that there are better ways to sanitize input, but I&#39;m really more interested in learning why the method I provided above won&#39;t work. If anyone knows of any specific way to mount a SQL injection attack against this sanitization method I would love to see it.



Can I protect against SQL injection by escaping single-quote and surrounding user input with single-quotes?

I know that PreparedStatements avoid/prevent SQL Injection. How does it do that? Will the final form query that is constructed using PreparedStatements be a string or otherwise?

How does a PreparedStatement avoid or prevent SQL injection?

I am very new to working with databases. Now I can write `SELECT`, `UPDATE`, `DELETE`, and `INSERT` commands. But I have seen many forums where we prefer to write:

    SELECT empSalary from employee where salary = @salary

...instead of:

    SELECT empSalary from employee where salary = txtSalary.Text

Why do we always prefer to use parameters and how would I use them?

I wanted to know the use and benefits of the first method. I have even heard of SQL injection but I don&#39;t fully understand it. I don&#39;t even know if SQL injection is related to my question.

Why do we always prefer using parameters in SQL statements?

Earlier today a question was asked regarding [input validation strategies in web apps][1].

The top answer, at time of writing, suggests in `PHP` just using `htmlspecialchars` and `mysql_real_escape_string`. 

My question is: Is this always enough? Is there more we should know? Where do these functions break down?

  [1]: https://stackoverflow.com/questions/110458/what-percentage-of-my-time-will-be-spent-in-user-input-verfication-during-web-d

Do htmlspecialchars and mysql_real_escape_string keep my PHP code safe from injection?

In terms of [SQL injection](https://en.wikipedia.org/wiki/SQL_injection), I completely understand the necessity to parameterize a `string` parameter; that&#39;s one of the oldest tricks in the book. But when can it be justified to *not* parameterize an `SqlCommand`? Are any data types considered &quot;safe&quot; to not parameterize? 

For example: I don&#39;t consider myself anywhere *near* an expert in SQL, but I can&#39;t think of any cases where it would be potentially vulnerable to SQL injection to accept a `bool` or an `int` and just concatenate it right into the query.

Is my assumption correct, or could that potentially leave a huge security vulnerability in my program?

*For clarification, this question is tagged [tag:C#] which is a strongly-typed language; when I say &quot;parameter,&quot; think something like* `public int Query(int id)`.


Is it safe to not parameterize an SQL query when the parameter is not a string?

We are having another discussion here at work about using parametrized sql queries in our code. We have two sides in the discussion: Me and some others that say we should always use parameters to safeguard against sql injections and the other guys that don&#39;t think it is necessary. Instead they want to replace single apostrophes with two apostrophes in all strings to avoid sql injections. Our databases are all running Sql Server 2005 or 2008 and our code base is running on .NET framework 2.0. 

Let me give you a simple example in C#:

I want us to use this:

    string sql = &quot;SELECT * FROM Users WHERE Name=@name&quot;;
    SqlCommand getUser = new SqlCommand(sql, connection);
    getUser.Parameters.AddWithValue(&quot;@name&quot;, userName);
    //... blabla - do something here, this is safe

While the other guys want to do this:

    string sql = &quot;SELECT * FROM Users WHERE Name=&quot; + SafeDBString(name);
    SqlCommand getUser = new SqlCommand(sql, connection);
    //... blabla - are we safe now?

Where the SafeDBString function is defined as follows:

    string SafeDBString(string inputValue) 
    {
        return &quot;&#39;&quot; + inputValue.Replace(&quot;&#39;&quot;, &quot;&#39;&#39;&quot;) + &quot;&#39;&quot;;
    }

Now, as long as we use SafeDBString on all string values in our queries we should be safe. Right? 

There are two reasons to use the SafeDBString function. First, it is the way it has been done since the stone ages, and second, it is easier to debug the sql statements since you see the excact query that is run on the database. 

So then. My question is whether it really is enough to use the SafeDBString function to avoid sql injection attacks. I have been trying to find examples of code that breaks this safety measure, but I can&#39;t find any examples of it. 

Is there anybody out there that can break this? How would you do it?  

**EDIT:**
To summarize the replies so far:  

 - Nobody has found a way to get around the SafeDBString on Sql Server 2005 or 2008 yet. That is good, I think?
 - Several replies pointed out that you get a performance gain when using parametrized queries. The reason is that the query plans can be reused.
 - We also agree that using parametrized queries give more readable code that is easier to maintain
 - Further it is easier to always use parameters than to use various versions of SafeDBString, string to number conversions and string to date conversions. 
 - Using parameters you get automatic type conversion, something that is especially useful when we are working with dates or decimal numbers.
 - And finally: [Don&#39;t try to do security yourself][1] as JulianR wrote. The database vendors spend lots of time and money on security. There is no way we can do better and no reason we should try to do their job.

So while nobody was able to break the simple security of the SafeDBString function I got lots of other good arguments. Thanks!


  [1]: https://stackoverflow.com/questions/910465/avoiding-sql-injection-without-parameters/910694#910694

Avoiding SQL injection without parameters



Can someone explain SQL injection?  How does it cause vulnerabilities?  Where exactly is the point where SQL is injected?



  [1]: https://stackoverflow.com/search?q=sql+injection

What is SQL injection?

Is it possible to prevent SQL injections in Node.js (preferably with a module) in the same way that PHP had Prepared Statements that protected against them.

If so, how? If not, **what are some examples** that might bypass the code I&#39;ve provided (see below).

----------------
Some Context:

I&#39;m making a web application with a back-end stack consisting of Node.js + MySql using the [node-mysql][1] module. From a usability perspective, the module is great, but it has not yet implemented something akin to PHP&#39;s [Prepared Statements][2] (though I&#39;m aware it is on the [todo][3]).

From my understanding, PHP&#39;s implementation of prepared statements, among other things, [helped greatly][4] in the prevention of SQL injections. I&#39;m worried, though, that my node.js app may be open to similar attacks, [even with the string escaping provided by default][5] (as in the code snippet below).

node-mysql seems to be the most popular mysql connector for node.js, so I was wondering what other people might be doing (if anything) to account for this issue - or if it is even an issue with node.js to begin with (not sure how this wouldn&#39;t be, since user/client-side input is involved).

**Should I switch to [node-mysql-native][6] for the time being, since it does provide prepared statements?** I&#39;m hesitant to do this, because it does not seem to be as active as node-mysql (though that may just mean that it is complete).

Here is a snippet of user registration code, which uses the [sanitizer][7] module, along with node-mysql&#39;s prepared statement-like syntax (which, as I mentioned above, does character escaping), to prevent cross site scripting and sql injections, respectively:

    // Prevent xss
    var clean_user = sanitizer.sanitize(username);

    // assume password is hashed already
    var post = {Username: clean_user, Password: hash};
           
    // This just uses connection.escape() underneath
    var query = connection.query(&#39;INSERT INTO users SET ?&#39;, post,
       function(err, results)
       {
           // Can a Sql injection happen here?
       });


  [1]: https://github.com/felixge/node-mysql
  [2]: http://php.net/manual/en/pdo.prepared-statements.php
  [3]: https://github.com/felixge/node-mysql#todo
  [4]: https://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602
  [5]: https://github.com/felixge/node-mysql#escaping-query-values
  [6]: https://github.com/sidorares/nodejs-mysql-native
  [7]: https://github.com/theSmaw/Caja-HTML-Sanitizer

Preventing SQL injection in Node.js

I understand that you should NEVER trust user input from a form, mainly due to the chance of SQL injection. 

However, does this also apply to a form where the only input is from a dropdown(s) (see below)?

I&#39;m saving the `$_POST[&#39;size&#39;]` to a Session which is then used throughout the site to query the various databases (with a `mysqli` Select query) and any SQL injection would definitely harm (possibly drop) them. 

There is no area for typed user input to query the databases, only dropdown(s).  

    &lt;form action=&quot;welcome.php&quot; method=&quot;post&quot;&gt;
    &lt;select name=&quot;size&quot;&gt;
      &lt;option value=&quot;All&quot;&gt;Select Size&lt;/option&gt; 
      &lt;option value=&quot;Large&quot;&gt;Large&lt;/option&gt;
      &lt;option value=&quot;Medium&quot;&gt;Medium&lt;/option&gt;
      &lt;option value=&quot;Small&quot;&gt;Small&lt;/option&gt;
    &lt;/select&gt;
    &lt;input type=&quot;submit&quot;&gt;
    &lt;/form&gt;
  

Do I have to guard against SQL injection if I used a dropdown?

If yes, why are there still so many successful SQL injections? Just because some developers are too dumb to use parameterized statements?

Can parameterized statement stop all SQL injection?

I&#39;ve been preaching both to my colleagues and here on SO about the goodness of using parameters in SQL queries, especially in .NET applications. I&#39;ve even gone so far as to promise them as giving immunity against SQL injection attacks.

But I&#39;m starting to wonder if this really is true. Are there any known SQL injection attacks that will be successfull against a parameterized query? Can you for example send a string that causes a buffer overflow on the server?

There are of course other considerations to make to ensure that a web application is safe (like sanitizing user input and all that stuff) but now I am thinking of SQL injections. I&#39;m especially interested in attacks against MsSQL 2005 and 2008 since they are my primary databases, but all databases are interesting. 

Edit: To clarify what I mean by parameters and parameterized queries. By using parameters I mean using &quot;variables&quot; instead of building the sql query in a string.  
So instead of doing this: 

    SELECT * FROM Table WHERE Name = &#39;a name&#39;
 
We do this:

    SELECT * FROM Table WHERE Name = @Name

and then set the value of the @Name parameter on the query / command object.

Are Parameters really enough to prevent Sql injections?

To start this off, I am well aware that parameterized queries are the best option, but I am asking what makes the strategy I present below vulnerable. People insist the below solution doesn&#39;t work, so I am look for an example of why it wouldn&#39;t.

If dynamic SQL is built in code using the following escaping before being sent to a SQL Server, what kind of injection can defeat this?

    string userInput= &quot;N&#39;&quot; + userInput.Replace(&quot;&#39;&quot;, &quot;&#39;&#39;&quot;) + &quot;&#39;&quot;

A similar question was answered [here][1], but I don&#39;t believe any of the answers are applicable here.

Escaping the single quote with a &quot;\&quot; isn&#39;t possible in SQL Server.

I believe **SQL Smuggling** with Unicode (outlined [here][2]) would be thwarted by the fact that the string being produced is marked as Unicode by the N preceding the single quote. As far as I know, there are no other character sets that SQL Server would automatically translate to a single quote. Without an unescaped single quote, I don&#39;t believe injection is possible.

I don&#39;t believe **String Truncation** is a viable vector either. SQL Server certainly won&#39;t be doing the truncating since the max size for an `nvarchar` is 2GB [according to microsoft][3]. A 2 GB string is unfeasible in most situations, and impossible in mine.

**Second Order Injection** could be possible, but is it possible if:

1. All data going into the database is sanitized using the above method
2. Values from the database are never appended into dynamic SQL (why would you ever do that anyways, when you can just reference the table value in the static part of any dynamic SQL string?).

I&#39;m not suggesting that this is better than or an alternative to using parameterized queries, but I want to know how what I outlined is vulnerable. Any ideas?

  [1]: https://stackoverflow.com/questions/139199/can-i-protect-against-sql-injection-by-escaping-single-quote-and-surrounding-use
  [2]: https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf
  [3]: http://msdn.microsoft.com/en-us/library/ms186939.aspx

How can sanitation that escapes single quotes be defeated by SQL injection in SQL Server?

I was reading my trusty O&#39;Reilly book and came across a passage about how Mongo, by nature, avoids the morass of SQL injection-like flaws.

In my gut, I think I understand this. If unsanitized vars are passed into queries, they can&#39;t break out of the document-oriented query structure with a `UNION`, `JOIN`, query turned comment, etc.

How does MongoDB avoid the SQL injection mess? Is it just by nature of this query syntax?



How does MongoDB avoid the SQL injection mess?

What is the safest way to run queries on MySQL? I am aware of the dangers involved with MySQL and SQL injection.

However, I do not know how I should run my queries to prevent injection on the variables to which other users (webclients) can manipulate. I used to write my own escape function, but apparently this is &quot;not-done&quot;.

What should I use and how should I use it to query and do inserts safely on a MySQL database through python without risking MySQL injection?

Python: best practice and securest way to connect to MySQL and execute queries

I have the following code, using pscyopg2:

    sql = &#39;select %s from %s where utctime &gt; %s and utctime &lt; %s order by utctime asc;&#39;
    data = (dataItems, voyage, dateRangeLower, dateRangeUpper)
    rows = cur.mogrify(sql, data)

This outputs:

    select &#39;waterTemp, airTemp, utctime&#39; from &#39;ss2012_t02&#39; where utctime &gt; &#39;2012-05-03T17:01:35+00:00&#39;::timestamptz and utctime &lt; &#39;2012-05-01T17:01:35+00:00&#39;::timestamptz order by utctime asc;


When I execute this, it falls over - this is understandable, as the quotes around the table name are illegal.

Is there a way to legally pass the table name as a parameter, or do I need to do a (explicitly warned against) string concatenation, ie:

    voyage = &#39;ss2012_t02&#39;
    sql = &#39;select %s from &#39; + voyage + &#39; where utctime &gt; %s and utctime &lt; %s order by utctime asc;&#39;

Cheers for any insights.

Passing table name as a parameter in psycopg2

In PHP, I know that `mysql_real_escape` is much safer than using `addslashes`.
However, I could not find an example of a situation where `addslashes` would let an SQL Injection happen.

Can anyone give some examples?

Examples of SQL Injections through addslashes()?

If you do a search for:

http://www.google.co.uk/search?q=0x57414954464F522044454C4159202730303A30303A313527&amp;hl=en&amp;start=30&amp;sa=N

you will see a lot of examples of an attempted hack along the lines of:

    1) declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

What is exactly is it trying to do? Which db is it trying to work on? 
Do you know of any advisories about this?




What is this hacker trying to do?

User equals untrustworthy. Never trust untrustworthy user&#39;s input. I get that. However, I am wondering when the best time to sanitize input is. For example, do you blindly store user input and then sanitize it whenever it is accessed/used, or do you sanitize the input immediately and then store this &quot;cleaned&quot; version? Maybe there are also some other approaches I haven&#39;t though of in addition to these. I am leaning more towards the first method, because any data that came from user input must still be approached cautiously, where the &quot;cleaned&quot; data might still unknowingly or accidentally be dangerous. Either way, what method do people think is best, and for what reasons?

When is it best to sanitize user input?

I just inherited a project because the last developer left.   The project is built off of Code Igniter.  I&#39;ve never worked with Code Igniter before.

I took a quick look at the code and I see database calls in the controller like this:

    $dbResult = $this-&gt;db-&gt;query(&quot;SELECT * FROM users WHERE username = &#39;&quot;.$_POST[&#39;user_name&#39;].&quot;&#39;&quot;);

or calls like this:

    $dbResult = $this-&gt;db-&gt;query(&quot;SELECT * FROM users WHERE username = &#39;&quot;.$this-&gt;input-&gt;post(&#39;username&#39;).&quot;&#39;&quot;);

Does code igniter automatically sanitize these queries to prevent sql injection?

Does CodeIgniter automatically prevent SQL injection?

I have a lot of user inputs from `$_GET` and `$_POST`... At the moment I always write `mysql_real_escape_string($_GET[&#39;var&#39;])`..

I would like to know whether you could make a function that secures, escapes and cleans the `$_GET`/`$_POST` arrays right away, so you won&#39;t have to deal with it each time you are working with user inputs and such.

I was thinking of an function, e.g `cleanMe($input)`, and inside it, it should do `mysql_real_escape_string`, `htmlspecialchars`, `strip_tags`, `stripslashes` (I think that would be all to make it clean &amp; secure) and then return the `$input`.

So is this possible? Making a function that works for all `$_GET` and `$_POST`, so you would do only this:

    $_GET  = cleanMe($_GET);
    $_POST = cleanMe($_POST);

So in your code later, when you work with e.g `$_GET[&#39;blabla&#39;]` or `$_POST[&#39;haha&#39;]` , they are secured, stripped and so on?

Tried myself a little:

    function cleanMe($input) {
       $input = mysql_real_escape_string($input);
       $input = htmlspecialchars($input, ENT_IGNORE, &#39;utf-8&#39;);
       $input = strip_tags($input);
       $input = stripslashes($input);
       return $input;
    }




The ultimate clean/secure function

&gt; This is to create a **community learning resource**. The goal is to have examples of good code that do not repeat the awful mistakes that can so often be found in copy/pasted PHP code. I have requested it be made Community Wiki. 
&gt;
&gt; This is **not meant as a coding contest.** It&#39;s not about finding the fastest or most compact way to do a query - it&#39;s to provide a good, readable reference especially for newbies. 

Every day, there is a huge influx of questions with *really bad* code snippets using the `mysql_*` family of functions on Stack Overflow. While it is usually best to direct those people towards PDO, it sometimes is neither possible (e.g. inherited legacy software) nor a realistic expectation (users are already using it in their project).

Common problems with code using the `mysql_*` library include:

* SQL injection in values
* SQL injection in LIMIT clauses and dynamic table names
* No error reporting (&quot;Why does this query not work?&quot;)
* Broken error reporting (that is, errors always occur even when the code is put into production)
* Cross-site scripting (XSS) injection in value output

Let&#39;s write a PHP code sample that does the following using the [mySQL_* family of functions][1]:

* Accept two POST values, `id` (numeric) and `name` (a string)
* Do an UPDATE query on a table `tablename`, changing the `name` column in the row with the ID `id`
* On failure, exit graciously, but show the detailed error only in production mode. `trigger_error()` will suffice; alternatively use a method of your choosing 
* Output the message &quot;`$name` updated.&quot;

And does **not** show any of the weaknesses listed above.

It should be **as simple as possible**. It ideally doesn&#39;t contain any functions or classes. The goal is not to create a copy/pasteable library, but to **show the minimum of what needs to be done to make database querying safe.**

Bonus points for good comments.

The goal is to make this question a resource that a user can link to when encountering a question asker who has bad code (even though it isn&#39;t the focus of the question at all) or is confronted with a failing query and doesn&#39;t know how to fix it. 

 **To pre-empt PDO discussion:**

Yes, it will often be preferable to direct the individuals writing those questions to PDO. When it is an option, we should do so. It is, however, not always possible - sometimes, the question asker is working on legacy code, or has already come a long way with this library, and is unlikely to change it now. Also, the `mysql_*` family of functions is perfectly safe if used properly. So no &quot;use PDO&quot; answers here please.

  [1]: http://php.net/manual/en/book.mysql.php

Reference: What is a perfect code sample using the MySQL extension?

I have to program an application management system for my OJT company. The front end will be done in C# and the back end in SQL.

Now I have never done a project of this scope before; in school we had only basic lessons about SQL. Somehow our teacher completely failed to discuss SQL injections, something which I have only now come in contact with by reading about it on the net.

So anyway my question is: how do you prevent SQL injections in C#? I vaguely think that it can be done by properly masking the text fields of the application so that it only accepts input in a specified format. For example: an e-mail textbox should be of the format &quot;example@examplecompany.tld&quot;. Would this approach be sufficient? Or does .NET have pre-defined methods that handle stuff like this? Can I apply a filter to a textbox so it only accepts email-address format or a name textbox so it doesn&#39;t accept special chars?

What are good ways to prevent SQL injection?

I have a web application built on JSF with MySQL as DB. I have already implemented the code to prevent CSRF in my application.

Now since my underlying framework is JSF, I guess I don&#39;t have to handle XSS attack as it is already handled by `UIComponent`. I am not using any JavaScript in any of the view pages. Even if I use do I really need to implement code to prevent XSS attacks?

For DB we are using prepared statements and stored procedures in all DB interactions.

Is there anything else needs to be handled for preventing these 3 common attacks?
I have already been through the [OWASP][1] site and their [cheat sheets][2].

Do I need to take care of any other potential attack vectors?
            


  [1]: http://www.owasp.org/
  [2]: https://www.owasp.org/index.php/Java_Server_Faces

CSRF, XSS and SQL Injection attack prevention in JSF

Parameterized Queries in .Net always look like this in the examples:

    SqlCommand comm = new SqlCommand(@&quot;
       SELECT * 
       FROM   Products 
       WHERE  Category_ID = @categoryid
    &quot;, 
       conn);
    comm.Parameters.Add(&quot;@categoryid&quot;, SqlDbType.Int);
    comm.Parameters[&quot;@categoryid&quot;].Value = CategoryID;

But I&#39;m running into a brick wall trying to do the following:

    SqlCommand comm = new SqlCommand(@&quot;
       SELECT * 
       FROM   Products 
       WHERE  Category_ID IN (@categoryids) 
          OR  name LIKE &#39;%@name%&#39;
    &quot;, 
       conn);
    comm.Parameters.Add(&quot;@categoryids&quot;, SqlDbType.Int);
    comm.Parameters[&quot;@categoryids&quot;].Value = CategoryIDs;
    comm.Parameters.Add(&quot;@name&quot;, SqlDbType.Int);
    comm.Parameters[&quot;@name&quot;].Value = Name;

Where

 - CategoryIDs is a comma separated list of numbers &quot;123,456,789&quot; (without quotes)
 - Name is a string, possibly with single quotes and other bad characters

What&#39;s the right syntax for this?

All Sql Injection Solutions on Gang of Coders

Total of 31 Sql Injection Solutions