sql-injection

Does using parameterized SqlCommand make my program immune to SQL injection?

南笙酒味 提交于 2019-11-26 20:34:10
I'm aware that SQL injection is rather dangerous . Now in my C# code I compose parameterized queries with SqlCommand class : SqlCommand command = ...; command.CommandText = "SELECT * FROM Jobs WHERE JobId = @JobId;"; command.Parameters.Add("@JobId", SqlDbType.UniqueIdentifier ).Value = actualGuid; command.ExecuteNonQuery(); Will this automatically make my code immune to SQL injection? Do I have to do something extra? I'd say for your particular, and probably canonical, example for parametrized queries, yes it is sufficient. However, people sometimes write code like this cmd.CommandText =

Rails SQL injection?

与世无争的帅哥 提交于 2019-11-26 19:43:06
问题 In Rails, when I want to find by a user given value and avoid SQL injection (escape apostrophes and the like) I can do something like this: Post.all(:conditions => ['title = ?', params[:title]]) I know that an unsafe way of doing this (possible SQL injection) is this: Post.all(:conditions => "title = #{params[:title]}") My question is, does the following method prevent SQL injection or not? Post.all(:conditions => {:title => params[:title]}) 回答1: Yes, it does. Only the second one is dangerous

Does the preparedStatement avoid SQL injection? [duplicate]

我们两清 提交于 2019-11-26 18:57:49
This question already has an answer here: How does a PreparedStatement avoid or prevent SQL injection? 9 answers I have read and tried to inject vulnerable sql queries to my application. It is not safe enough. I am simply using the Statement Connection for database validations and other insertion operations. Is the preparedStatements safe? and moreover will there be any problem with this statement too? Using string concatenation for constructing your query from arbitrary input will not make PreparedStatement safe. Take a look at this example: preparedStatement = "SELECT * FROM users WHERE name

Is htmlspecialchars enough to prevent an SQL injection on a variable enclosed in single quotes?

别说谁变了你拦得住时间么 提交于 2019-11-26 18:30:34
问题 Although many sources quote the htmlspecialchars function with ENT_QUOTES to be not enough to prevent SQL injection, none of them provide a proof of the concept. I cannot think of any possibility myself. Let us consider the following example: $username = htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); $sql = "SELECT * from user WHERE name='$username'"; mysql_query($sql,...); Can any one provide an example, OTHER than ones covered by the case when SQL injection gets around mysql_real

Is mysqli_real_escape_string safe?

点点圈 提交于 2019-11-26 17:50:00
问题 I´m new in PHP and I´ve realised that my database connection, using a php form (with user and pass text inputs) was totally unsafe: This was working, but was unsafe: <?php $link=mysqli_connect('localhost','xx','xx','xx'); $sql=' SELECT * FROM usuarios WHERE username="'.$_POST['usuario'].'" AND pass="'.$_POST['usuario'].'" '; $rs=mysqli_query($link,$sql); mysqli_close($link); ?> So, I´ve read about mysqli_real_escape_string, and decided to try it out: <?php $link=mysqli_connect('localhost','xx

Passing table name as a parameter in psycopg2

本秂侑毒 提交于 2019-11-26 17:41:25
I have the following code, using pscyopg2: sql = 'select %s from %s where utctime > %s and utctime < %s order by utctime asc;' data = (dataItems, voyage, dateRangeLower, dateRangeUpper) rows = cur.mogrify(sql, data) This outputs: select 'waterTemp, airTemp, utctime' from 'ss2012_t02' where utctime > '2012-05-03T17:01:35+00:00'::timestamptz and utctime < '2012-05-01T17:01:35+00:00'::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

How to prevent a SQL Injection escaping strings

与世无争的帅哥 提交于 2019-11-26 16:38:24
I have some queries (to an acccess database) like this : string comando = "SELECT * FROM ANAGRAFICA WHERE E_MAIL='" + user + "' AND PASSWORD_AZIENDA='" + password + "'"; and I'd like to "escape" user and password, preventing an injection. How can I do it with C# and .NET 3.5? I'm searching somethings like mysql_escape_string on PHP... You need to use parameters. Well dont have to but would be preferable. SqlParameter[] myparm = new SqlParameter[2]; myparm[0] = new SqlParameter("@User",user); myparm[1] = new SqlParameter("@Pass",password); string comando = "SELECT * FROM ANAGRAFICA WHERE E_MAIL

What does mysql_real_escape_string() do that addslashes() doesn&#39;t?

只谈情不闲聊 提交于 2019-11-26 15:31:00
Why do we need a DB-specific functions like mysql_real_escape_string()? What can it do that addslashes() doesn't? Ignoring for the moment the superior alternative of parameterized queries, is a webapp that uses addslashes() exclusively still vulnerable to SQL injection, and if yes, how? Addslashes is generally not good enough when dealing with multibyte encoded strings. It adds slashes to: \x00, \n, \r, \, ', " and \x1a. characters. Where addslashes only adds slashes to ' \ and NUL Ilias article is also pretty detailed on its functionality gs's harshly downvoted answer is actually kinda right.

Can parameterized statement stop all SQL injection?

本秂侑毒 提交于 2019-11-26 15:19:11
问题 If yes, why are there still so many successful SQL injections? Just because some developers are too dumb to use parameterized statements? 回答1: The links that I have posted in my comments to the question explain the problem very well. I've summarised my feelings on why the problem persists, below: Those just starting out may have no awareness of SQL injection. Some are aware of SQL injection, but think that escaping is the (only?) solution. If you do a quick Google search for php mysql query ,

Does mysql_real_escape_string() FULLY protect against SQL injection?

假装没事ソ 提交于 2019-11-26 15:12:00
On http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this , there is a section that claims you can bypass mysql_real_escape_string with certain Asian character encodings Bypassing mysql_real_escape_string() with BIG5 or GBK "injection string" に関する追加情報: the above chars are Chinese Big5 Is this really true? And if so, how would you protect your website against this, if you had no access to prepared statements? According to Stefan Esser, " mysql_real_escape_string() [is] not safe when SET NAMES is used." His explanation, from his blog : SET NAMES is usually