sql-injection

I'm currently using the mysqli php extension. Traditionally I have used mysqli_real_escape_string to escape user input. However I am looking at changing over the code (hopefully in as few steps as possible) to use prepared statements. I want to be clear on this - provided I use prepared statements to bind all of my variables, can I be confident that sql injection is impossible? (And dispense completely with mysqli_real_escape_string?) Thanks If you correctly bind all your variables you can dramatically reduce the risk of SQL injection. It is still possible to get an SQL injection if you create

Taking over some code from my predecessor and I found a query that uses the Like operator: SELECT * FROM suppliers WHERE supplier_name like '%'+name+%'; Trying to avoid SQL Injection problem and parameterize this but I am not quite sure how this would be accomplished. Any suggestions ? note, I need a solution for classic ADO.NET - I don't really have the go-ahead to switch this code over to something like LINQ. try this: var query = "select * from foo where name like @searchterm"; using (var command = new SqlCommand(query, connection)) { command.Parameters.AddWithValue("@searchterm", String

I scanned my login script using SQL Inject Me Firefox addon According to the Test Results, my script was vulnerable to SQL Injection. Result by example Results: Server Status Code: 302 Found Tested value: &#49&#39&#32&#79&#82&#32&#39&#49&#39&#61&#39&#49 Server Status Code: 302 Found Tested value: 1' OR '1'='1 Server Status Code: 302 Found Tested value: 1 UNI/**/ON SELECT ALL FROM WHERE Server Status Code: 302 Found Tested value: %31%27%20%4F%52%20%27%31%27%3D%27%31 My script login.php - Login form check-login.php - To check login detail and here is the code. $email = clean($_POST['username']);

public static bool TruncateTable(string dbAlias, string tableName) { string sqlStatement = string.Format("TRUNCATE TABLE {0}", tableName); return ExecuteNonQuery(dbAlias, sqlStatement) > 0; } Bill Karwin The most common recommendation to fight SQL injection is to use an SQL query parameter (several people on this thread have suggested it). This is the wrong answer in this case. You can't use an SQL query parameter for a table name in a DDL statement. SQL query parameters can be used only in place of a literal value in an SQL expression. This is standard in every implementation of SQL. My

If I remember correctly, I think Jeff has mentioned in the Stack Overflow podcast a possible weakness in SQL prepared statements. I'm wondering what kind(s) of weakness(es) did he refer to? Was it possibly just about inappropriate usage thereof, or something more sinister? The podcast, to my remembering, didn't go deeper into the subject, it was just a pass-by-remark. I think what he said was that, when you use Prepared Statements, SQL server could cache your query execution plan, so, even if you modify some of the parameters on the executing query, the server could pick the wrong (probably

Possible Duplicate: SQL injection that gets around mysql_real_escape_string() I havent seen any valuabe or not outdated info on this. So, there is this question: Does mysql_real_escape_string() FULLY protect against SQL injection? Yet it is very outdated(its from '09), so as of php 5.3 and mysql 5.5 in '12, does it protect fully ? Your Common Sense mysql_real_escape_string ALONE can prevent nothing. Moreover, this function has nothing to do with injections at all. Whenever you need escaping, you need it despite of "security", but just because it is required by SQL syntax. And where you don't