sql-injection

I wanted to post this here as it is very much coding related and was something I had to clean up this week on one of my company's old ASP (classic) sites. We got hit with the SQL injection attack that was run just a few days ago, but I'm scratching my head WHAT exactly the 'damage' was to the SQL server (via these SQL queries). To be honest, I thought it was very ingenious the way this was carried out, and its my companies fault for having an old 10 year old site with little to no sanitized input. The attack: 122+declare+%40s+varchar%284000%29+set+%40s%3Dcast

I was reading my trusty O'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'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? MongoDB avoids the potential for problems by not parsing. Any API, anywhere, that involves encoding user data in formatted text that gets parsed has the potential for the caller

I'm writing some unit tests to ensure my code isn't vulnerable to SQL injection under various charsets. According to this answer , you can create a vulnerability by injecting \xbf\x27 using one of the following charsets: big5 , cp932 , gb2312 , gbk and sjis This is because if your escaper is not configured correctly, it will see the 0x27 and try to escape it such that it becomes \xbf\x5c\x27 . However, \xbf\x5c is actually one character in these charsets, thus the quote ( 0x27 ) is left unescaped. As I've discovered through testing, however, this is not entirely true. It works for big5 ,

What's exactly the difference between the two kinds of prepared statements ? I think real prepared statements require server side support wich accepts paramenters after parsing and compiling the schema/template of sql code, and , I suppose ,that's what guarantees us against sql-injection. In the case of emulated prepared statements ,with no server support, what does it guarantee us against it ? You are correct, real prepared statements must be supported by the server. A real prepared means querying the database in two steps. The fist step consists in sending a query template, that the server

I'm a beginner in ASP.NET so I have some questions about how to prevent SQL injection in ASP.NET. My programming language is VB.NET, not C#, and I'm using Microsoft Access as my database. My questions are: How to protect my database from SQL injection? I have been reading postings from other forums and they said using parameters with stored procedures, parameters with dynamic SQL. Can they be implemented in a Microsoft Access database? Here is a very simple ASP.NET example using a parameterized query via OleDb in VB.NET: Default.aspx <%@ Page Title="Home Page" Language="vb" MasterPageFile="~

LuaSQL , which seems to be the canonical library for most SQL database systems in Lua, doesn't seem to have any facilities for quoting/escaping values in queries. I'm writing an application that uses SQLite as a backend, and I'd love to use an interface like the one specified by Python's DB-API : c.execute('select * from stocks where symbol=?', t) but I'd even settle for something even dumber, like: conn:execute("select * from stocks where symbol=" + luasql.sqlite.quote(t)) Are there any other Lua libraries that support quoting for SQLite? ( LuaSQLite3 doesn't seem to.) Or am I missing

If I were to select a row from a table I basically have two options, either like this int key = some_number_derived_from_a_dropdown_or_whatever SqlCommand cmd = new SqlCommand("select * from table where primary_key = " + key.ToString()); or use a parameter SqlCommand cmd = new SqlCommand("select * from table where primary_key = @pk"); SqlParameter param = new SqlParameter(); param.ParameterName = "@pk"; param.Value = some_number_derived_from_a_dropdown_or_whatever; cmd.Parameters.Add(param); Now, I know the first method is frowned upon because of possible sql injection attacks, but in this

I am using stored procedures. In order to save time, I made some generic procedures that uses dynamic sqlin order to update. Such generic procedure is: CREATE PROCEDURE [dbo].[SetField] @company_id uniqueidentifier, @id bigint, @field_code nvarchar(50), @value nvarchar(50) AS BEGIN DECLARE @field_name nvarchar(50) SET @field_name = NULL SELECT @field_name=field_name FROM dbo.FIELD_DEFINITION WHERE field_code=@field_code IF @field_name IS NOT NULL BEGIN IF @value IS NULL OR @value='' BEGIN SET @value='NULL' END ELSE BEGIN IF @field_code='START_DATE' OR @field_code='END_DATE' BEGIN SET @value =

I have written this short function to protect against my_sql injection, because of its importance I just want to double check with other's that this will function as I intend. foreach($_REQUEST as $key => $value) { $_REQUEST[$key] = stripslashes($value); $_REQUEST[$key] = mysql_real_escape_string($_REQUEST[$key]); } Well, you use stripslashes() because the magic_quotes_gpc is set? So this code will only work when magic_quotes_gpc is set! I'd recommend you switch it off and dont use the strislashes() call. But note there is nothing like "universal sanitization". Let's call it just quoting ,