Preventing Sql Injection Attacks

Please see my posting on "Sql Injection" in the Technologies\Security forum. I am interested in preventing sql injection attacks on our server. It was difficult to decide where to post it as it is a security issue but it may be general server issue. Or is it???

It would have helpful if you had either repeated the text of your other post here, or else included a link Sql Injection.
Tom Best posted a link to an interesting sounding paper in Injection Attack. I haven't had the chance to read it yet, but it is probably the best best place to start (as no-one else posted to that thread).
Cheers, APC

Similar Messages

Preventing sql injection attack

string objConn9 = "Provider = MSDAORA;User ID=103109798;Password=password;Data Source=orabis;";
                              OleDbConnection myConnection9 = new OleDbConnection(objConn9);
                              string commandString9 = "INSERT INTO users(username,password)VALUES(:username,:password)";
                              OleDbCommand myCommand9 = new OleDbCommand(commandString9, myConnection9);
                              myCommand9.Parameters.Add(":username", txtUsername.Text);
                              myCommand9.Parameters.Add(":password", txtPassword.Text);
                              myConnection9.Open();
                              myCommand9.ExecuteNonQuery();
                              myConnection9.Close();
i'm using this code to try to remove the problem of
users entering a comma or an semi colon and throwing off my query, but its not working...
is there an easy way to insert text values into oracle 8i
that contain '; etc without throwing it off. I'm developing through c# and oracle 8i, the problem is most of the code examples are related to sql server and vb.net

I may be off here, but in this case you appear to be okay. The code snippet you include looks to me like it is using bind variables. If you are using bind variables you are not susceptible to sql injection attacks.
It is only when concatenating a string together to make a sql statement that injection attacks can occur.
See
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:668624442763#18067076079313
and search for injection.
Or just go to
http://asktom.oracle.com
and search for "sql injection bind variable" for lots of other references.

Preventing SQL injection - can't use cfqueryparam in this case

Hello. I have a form with a checkbox next to each row. If the user checks some boxes, then clicks the "Delete" button, I want to execute the following query, but I want to protect it from sql injection attacks:
    <cfquery datasource="#application.mainDS#">
        delete userMessages
        where messageID in (#form.messageID#)
    </cfquery>
As written above, it works fine. But if I try to protect this code with <cfqueryparam value="#form.messageID#" cfsqltype="cf_sql_varchar">, I get this error: "Conversion failed when converting the varchar value '7,21' to data type int" (7 and 21 are the messageID's to be deleted). Obviously the comma prevents conversion to an integer.
If I use cfsqltype="cf_sql_integer", then the string gets converted to a single integer (in this case 40015, which is nonsense).
I tried passing form.messageID to a stored procedure, but I seemed to have the same problem there. I could run the query in a loop where I just delete one row at a time, but I'd like to run just one query if I can do it safely. Any ideas?
Thanks.
PK

I agree that you should not do an SQL "DELETE" from a web page. Instead, use "soft deletes," where you contrive for there to be a deleted_flag (boolean), and maybe deleted_by (varchar) and deleted_timestamp. Then create an SQL "VIEW" which automagically omits the "deleted" records.
It is also a very good idea to refer to the records using a nonsensical, made-up "moniker" instead of actual record-IDs. You see, "if I am a nasty person and I know that there is a record #123456, then I'll bet I know the record-IDs of 123,455 other records, too." But if you refer to the record as "QZB0E9S" and the next record-id in the list is "4Q_9RJPEM2" then it won't take me long to realize that I can't get too far, not even by brute-force. (And if I see that the record-IDs seem to have verification tags, like "QZB0E9S:4E396", then I know that I am really scroo'd in my hacking-attempt because even if I did somehow million-monkeys my way into a valid record-ID, I've got no earthly idea how to come up with the tag.
It pays to code defensively, like this. And it doesn't really take more time. Without question, always use <cfqueryparam> !!

SQL Injection Attacks

Any Admins aware of possible SQL "injection" attacks like this?
For example in your web sites login.asp or similar:
select * from users
where uname='%value1%'
and pwd='%value2%'
where %value1% equals "garbage"
and %value2% equals "garbage' or TRUE or '"
select * from users
where uname='garbage'
and pwd='garbage' or TRUE or ''
Useful source of security info:
http://www.nextgenss.com/news.html
Get Oracle Security Patches:
http://otn.oracle.com/deploy/security/alerts.htm
Adeeva.

There was an excellent presentation on this and other database attacks at the recent SEOUC conference in Charlotte. You can see the slides by going to http://www.seouc.org. Select "Presentation Abstracts" from the menu and then choose the keynote address. There were a lot of open jaws in the presentation room.
One technique that we use is to package all SQL used in our websites using bind variables. So the login script you showed would be replaced by a packaged procedure something like this:
PROCEDURE validate_logon (id_in appusers.id%TYPE, pw_in appusers.password%TYPE)
RETURN INTEGER
IS
x INTEGER;
sqlstr := 'select count(*) from appusers where id = :1 and password = :2';
BEGIN
EXECUTE IMMEDIATE sqlstr INTO x USING id_in, pw_in;
RETURN x;
END;
This would return a positive integer (should always be 1) if the validation succeeds and 0 if it fails. They can't easily inject stuff into this. We used packaged dynamic SQL with bind variables for everything. Also, the account that logs onto the database never has access of any kind to the tables or views, only EXECUTE on the procedures.
Nothing is foolproof but at least it makes it harder for them.

SQL Injection attack

After an SQL injection attack I followed the advice to use
cfqueryparam in my cfquery statements. Unfortunatley this does not
seem to have worked as many records in my database have again been
appended with scripts linking to javascript files on another
website.
I haven't coded in Coldfusion in a while and would really
appreciate it if someone could take a look at the code of one of my
pages and let me know if I have missed anything or miss coded the
cfqueryparam tag.
Thanks in advance
Neil

You can add the following code to your application file.

<cfset sqlregex = "
(SELECT\s[\w\*\)$\,\s]+\sFROM\s[\w]+)|
(UPDATE\s[\w]+\sSET\s[\w\,\'\=]+)|
(INSERT\sINTO\s[\d\w]+[\s\w\d$$\,]*\sVALUES\s\([\d\w\'\,$]+)|
(DELETE\sFROM\s[\d\w\'\=]+)|
(DROP\sTABLE\s[\d\w\'\=]+)">

<cfloop collection="#form#" item="formelement">
<cfif isSimpleValue(evaluate(formelement)) AND
refindnocase(sqlregex, "#evaluate(formelement)#")>
<cflocation url="messages.cfm?message=Invalid Input.
Possible SQL Injection attack.">
<cfset StructClear(form)>
<cfabort>
</cfif>
</cfloop>

<cfloop collection="#url#" item="formelement">
<cfif isSimpleValue(evaluate(formelement)) AND
refindnocase(sqlregex, "#evaluate(formelement)#")>
<cflocation url="messages.cfm?message=Invalid Input.
Possible SQL Injection attack.">
<cfset StructClear(url)>
<cfabort>
</cfif>
</cfloop>
Good luck
Mamdoh
P.S: The credit for the script go to sys-con.com

Lightswitch Security, Protection against SQL Injection attacks etc.

Hi all,
I have been hunting around for some kind of documentation that explains how Lightwitch handles typical web application vunerabilities such as SQL injection attacks.
In the case of injection attacks it is my understanding the generated code will submit data to the database via names parameters to protect against such things but it would be good to have some official account of how Lightswitch handles relevant OWASP
issues to help provide assurance to businesses that by relying on a framework such as Lightswitch does not introduce security risks.
Is anyone aware of such documentation? I found this but it barely scratches the surface:
http://msdn.microsoft.com/en-us/library/gg481776.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1
There is this which describes best practices but nothing to say that these practices are adopte within Lightswitch
http://msdn.microsoft.com/en-us/library/gg481776.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1
Thanks for any help, I am amazed that it is so difficult to find?

LS is a tool built in top of other technologies including Entity Framework.
Here is a security doc about EF.
http://msdn.microsoft.com/en-us/library/vstudio/cc716760(v=vs.100).aspx
LS uses Linq to Entities and therefore is not susceptible to SQL injection.
HTH,
Josh
PS... the only vulnerability that I'm aware of is when a desktop app is deployed as 2-tier instead of 3-tier. In that case, the web.config which contains connection strings is on the client machine, which is a risk. Here is a discussion related
to db security & 2 vs 3-tier.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/93e035e0-0d2e-4405-a717-5b3207b3ccac/can-sql-server-application-roles-be-used-in-conjunction-with-lightswitch?forum=lightswitch

Preventing/securing against sql injection attacks

What's the best way to go about trying to secure/prevent from mysql injection attacks.
I guess this is not so good?
$JobTitle = $_POST['JobTitle'];
$sql = 'SELECT * FROM jobs WHERE JobTitle = "'.$JobTitle.'"';
So I'm currently using the mysqli real_escape_string:
$JobTitle = $_POST['JobTitle'];
$JobTitle = $conn->real_escape_string($JobTitle);
$sql = 'SELECT * FROM jobs WHERE JobTitle = "'.$JobTitle.'"';
or I could use:
$sql = 'SELECT * FROM jobs WHERE JobTitle = "$_POST['JobTitle'];"';
but I don't know about the above having not used it at all.
or I could use prepared statements which I dont particularly want to do because they are so long-winded especially when you have about 20 or so rows of data to insert/update into a database table
???????????????????? (ssssssssssssssss) I mean who the **** can keep track of that ****
Is there anything bad about using the below (no user input i.e., $_POST or $_GET)
$date = date('Y-m-d');
$sql = 'SELECT * FROM jobs WHERE jobDate < "'.$date.'"';
Just trying to get a handle on reasonable practices to use, when and where.
Any thoughts
Cheers
Os

Hi Ken,
Thanks for that. It seems as though this area is a bit of a grey one. I've searched just about everywhere and can't find any kind of difinitive answer.
I'm specifically exploring sqli as that is the way ahead now that sql is being dropped from future php releases.
I'm using prepared statements to insert and update the database and boy are they a pita to work with. My eyes can't cope with it....simply ridiculous to have to keep track of the binding method:
??????????????????????? and sssssssssssssssssss
Was looking for something simpler when selecting results to display on a page. Think for now I'll just go with the real_escape_string method and hope it provides some form of security.
$foo = $_POST['foo'];
$foo = $conn->real_escape_string($foo);
I'll just assume there is no risk if a user can't input any data i.e,
$variable = "foo";
SELECT * from table Where id = "'.$variable.'"

Sql injection attack - need help changing ASP code

Our web server was attacked yesterday by SQL injection. So I
quickly learned about the holes in the code that was generated by
Dreamweaver MX 2004.
I found the help article on the Adobe website to fix the ASP
code; however I need more information for my particular case. I
don't know how to get my cursor type and location settings into the
new code.
MY ORIGINAL CODE
<%
Dim Recordset1
Dim Recordset1_numRows
Set Recordset1 = Server.CreateObject("ADODB.Recordset")
Recordset1.ActiveConnection = MM_Oncology_STRING
Recordset1.Source = "SELECT * FROM dbo.Oncology_Dir WHERE
Oncology_ID = " + Replace(Recordset1__MMColParam, "'", "''") + ""
Recordset1.CursorType = 0
Recordset1.CursorLocation = 3
Recordset1.LockType = 1
Recordset1.Open()
Recordset1_numRows = 0
%>
THE NEW CODE, WHICH NEEDS TO BE FIXED TO REFLECT CURSOR TYPE
AND LOCATION ABOVE.
<%
Dim Recordset1
Dim Recordset1_cmd
Dim Recordset1_numRows
Set Recordset1_cmd = Server.CreateObject ("ADODB.Command")
Recordset1_cmd.ActiveConnection = MM_Oncology_STRING
Recordset1_cmd.CommandText = "SELECT * FROM dbo.Oncology_Dir
WHERE Oncology_ID = ?"
Recordset1_cmd.Prepared = true
Recordset1_cmd.Parameters.Append
Recordset1_cmd.CreateParameter("param1", 5, 1, -1,
Recordset1__MMColParam) ' adDouble
Set Recordset1 = Recordset1_cmd.Execute
Recordset1_numRows = 0
%>
What exactly is the 5,1,-1 in the code above?
Any help would be very much appreciated as my ASP page
(although secured from SQL injection) is not working properly.
Thanks,
--Jen
--Jen

The new snippet is not vulnerable to SQL injection. It uses a
command
object and actual defined parameters, so you're safe. You
cannot change the
cursor type or location on that object.
"jennday" <[email protected]> wrote in
message
news:f85omh$ngg$[email protected]..
> Our web server was attacked yesterday by SQL injection.
So I quickly
> learned
> about the holes in the code that was generated by
Dreamweaver MX 2004.
> I found the help article on the Adobe website to fix the
ASP code; however
> I
> need more information for my particular case. I don't
know how to get my
> cursor type and location settings into the new code.

How can I write this query In parameterize form so That I can prevent sql Injection

String strQry = "INSERT INTO tblVoucherType (VhrTypeCode,moduleCode,transCCode,"
+ "voucherType,OrderNumber,active,AccountId) "
+ " values('" + txtVhrCode.Text + "','" + ddlModule.SelectedValue.ToString() + "',"
+ "'" + ddlTrans.SelectedValue.ToString() + "','" + txtVhrName.Text + "','" + btnRadio.SelectedValue + "'"
+ ", '" + status.Checked + "', '" + txtAccount.Text + "')";

Basically it will look like:
String strQry = "INSERT INTO tblVoucherType (VhrTypeCode,moduleCode,transCCode, ...)"
+ " values(@VhrCode, @moduleCode, @transCCode, ....)";
sqlCommand.Parameters.AddWithValue("@VhrCode", txtVhrCode.Text );
sqlCommand.Parameters.AddWithValue("@moduleCode", ddlModule.SelectedValue.ToString() );
sqlCommand.Parameters.AddWithValue("@transCCode", ddlTrans.SelectedValue.ToString() );
.. and so on
sqlCommand.ExecuteNonQuery();
Olaf Helper
[ Blog] [ Xing] [ MVP]

SQL Injection detection with IDS/IPS on cisco ASA?

Hi
Is it possible to detect or prevent SQL injection attacks using Cisco IDS/ IPS on ASA or with regular expressions?
Is there any signature available in IDS/IPS for this? And how effective it is in terms of generating correct alarms?
Thanks in advance

Deepak,
We have several signatures that detect generic SQL injection attacks in the 5930-x family of signatures.

Sql injection

What is SQL Injection?
SQL Injection is a way to attack the data in a database through a firewall protecting it. It is a method by which the parameters of a Web-based application are modified in order to change the SQL statements that are passed to a database to return data. For example, by adding a single quote (‘) to the parameters, it is possible to cause a second query to be executed with the first.
An attack against a database using SQL Injection could be motivated by two primary objectives:
1. To steal data from a database from which the data should not normally be available, or to obtain system configuration data that would allow an attack profile to be built. One example of the latter would be obtaining all of the database password hashes so that passwords can be brute-forced.
2. To gain access to an organisation’s host computers via the machine hosting the database. This can be done using package procedures and 3GL language extensions that allow O/S access.
There are many ways to use this technique on an Oracle system. This depends upon the language used or the API. The following are some languages, APIs and tools that can access an Oracle database and be part of a Web-based application.
* JSP
* ASP
* XML, XSL and XSQL
* Javascript
* VB, MFC, and other ODBC-based tools and APIs
* Portal, the older WebDB, and other Oracle Web-based applications and API’s
* Reports, discoverer, Oracle Applications
* 3- and 4GL-based languages such as C, OCI, Pro*C, and COBOL
* Perl and CGI scripts that access Oracle databases
* many more.
Any of the above applications, tools, and products could be used as a base from which to SQL inject an Oracle database. A few simple preconditions need to be in place first though. First and foremost amongst these is that dynamic SQL must be used in the application, tool, or product, otherwise SQL Injection is not possible.
The final important point not usually mentioned in discussions about SQL injection against any database including Oracle is that SQL injection is not just a Web-based problem. As is implied in the preceding paragraph, any application that allows a user to enter data that may eventually end up being executed as a piece of dynamic SQL can potentially be SQL injected. Of course, Web-based applications present the greatest risk, as anyone with a browser and an Internet connection can potentially access data they should not.
While second article of this series will include a much more in-depth discussion of how to protect against SQL injection attacks, there are a couple of brief notes that should be mentioned in this introductory section. Data held in Oracle databases should be protected from employees and others who have network access to applications that maintain that data. Those employees could be malicious or may simply want to read data they are not authorized to read. Readers should keep in mind that most threats to data held within databases come from authorized users.
Protecting against SQL Injection on Oracle-based systems is simple in principle and includes two basic stages. These are:
1. Audit the application code and change or remove the problems that allow injection to take place. (These problems will be discussed at greater length in the second part of this series.)
2. Enforce the principle of least privilege at the database level so that even if someone is able to SQL inject an application to steal data, they cannot see anymore data than the designer intended through any normal application interface.
The “Protection” section, which will be included in the second part of this series, will discuss details of how to apply some of these ideas specifically to Oracle-based applications.
[http://www.securityfocus.com/infocus/1644]
how oracle prevent sql injections?

mango_boy wrote:
damorgan wrote:
And they do so using bind variables
http://www.morganslibrary.org/reference/bindvars.html
and DBMS_ASSERT
http://www.morganslibrary.org/reference/dbms_assert.html
do you have any suggestion for mysql users??Yes. Install Oracle.

SQL Injection Discussion

Hello, I have found a lot of discussion about the SQL Injection.
Seems like it is very famous issue nowadays.
I am currently doing some findings on the SQL injection and hopefully this thread may give some benefits to everyone.
1. has SQLIA been resolved nowadays?
2. where SQLIA can be launched? is it only from the front-end of the website (eg. login form) or can also attack directly the database? if can, how it can be done? How the type of attack can be determined whether i is launched form the application or anywhere else?
3. Which is better? whether to prevent the SQLIA at the application layer or database layer?
My focus is to prevent the SQLIA in the web application itself for example by using data validation.
That's all for this post. Thank you so much.
Regards, hus..

SQL statements that use bind variables are not vulnerable to SQL injection attacks (well, not practically vulnerable). There is a small risk that if the database is unpatched someone might be able to exploit a buffer overflow in some Oracle-delivered function that your query is using but that's not a realistic threat scenario.
There is plenty of documentation available online. For example a Google search on "bind variable" "sql injection" returns as the top result this PDF- An Introduction to SQL Injection Attacks in Oracle which discusses bind variables in some detail. In the top 5 results is this Oracle documentation on avoiding SQL injection in PL/SQL which discusses using bind variables.
Justin

SQL Injection concerns

I have been studying sql injection attacks and the
mysql_real_escape function.
I read the adobe technote about sql injection and it noted
that Dreamweaver 8.0 incorporates anti-sql injection code to
prevent attacks and it specifically refers to Add, Delete, and
Update; Filtered Recordsets, and Login User server behaviors. Can
anyone please confirm this to put my mind at ease?
The Search form and results page uses a filtered recordset,
so can I presume that it is guarded from attack?
Can you tell me of any areas that I need to add anti-sql
injection code myself?
Thank you so much for your help!

EviePhillips wrote:
> The code on this second page (the one where the form
posts to) ECHOs the form
> variables. Do I need to enter the
mysql_real_escape_string around each of the
> ECHOed posted form variables?
No, mysql_real_escape_string() is used only when inserting
user input
values into a database. You cannot use it without a database
connection.
However, you should pass the values to htmlentitities()
before
displaying them in your page. You can do this by accessing
the Format
menu in the Dynamic Text dialog box. After using the Bindings
panel to
insert the value, switch to the Server Behaviors panel, and
double-click
the Dynamic Text entry to open the dialog box.
> I am then going to use the ADD Record server behavior to
add the data to my
> database from this page, which based on your counsel is
fully protected from
> sql injection.
>
> You are very kind for sharing your knowledge!
> EP
>
David Powers, Adobe Community Expert
Author, "The Essential Guide to Dreamweaver CS4",
"PHP Solutions" & "PHP Object-Oriented Solutions"
http://foundationphp.com/

SQL Injection, replace single quote with two single quotes?

Is replacing a single quote with two single quotes adequate
for eliminating
SQL injection attacks? This article (
http://www.devguru.com/features/kb/kb100206.asp
) offers that advice, and it
enabled me to allow users to search name fields in the
database that contain
single quotes.
I was advised to use "Paramaterized SQL" in an earlier post,
but I can't
understand the concept behind that method, and whether it
applies to
queries, writes, or both.

Then you can use both stored procedures and prepared
statements.
Both provide better protection than simply replacing
apostrophes.
Prepared statements are simple:
Set myCommand = Server.CreateObject("ADODB.Command")
...snip...
myCommand.CommandText = "INSERT INTO Users([Name], [Email])
VALUES (?, ?)"
...snip...
myCommand.Parameters.Append
myCommand.CreateParameter("@Name",200,1,50,Name)
myCommand.Parameters.Append
myCommand.CreateParameter("@Email",200,1,50,Email)
myCommand.Execute ,,128 'the ,,128 sets execution flags that
tell ADO not to
look for rows to be returned. This saves the expense of
creating a
recordset object you don't need.
Stored procedures are executed in a similar manner. DW can
help you with a
stored procedure through the "Command (Stored Procedure)"
server behavior.
You can see a full example of a prepared statement by looking
at DW's
recordset code after you've created a recordset using version
8.02.
"Mike Z" <[email protected]> wrote in message
news:eo5idq$3qr$[email protected]..
>I should have repeated this, I am using VBScript in ASP,
with an Access DB.
>

SQL Injection on CallableStatement

I will try to post this all in one line, as the tags are not working today. I know that one should use PreparedStatement over Statement to obviate the thread of a SQL injection attack. Is CallableStatement vulnerable as well? For reference, this would be running against an Oracle RDBMS. Thanks!
- Saish

I guess there is no hard-and-fast rule.Well, I guess the hard and fast rule is "only use
bound variables". If you've got a sane database
design then that shouldn't cause you any problems.
Dave.I agree. I was approaching the issue mainly from a security perspective in locking down a legacy system against SQL injection attacks. Using Eclipse, I was able to zero-in on usages of Statement fairly easily. But the more I looked into CallableStatement, the more I realized that I woud have to inspect each invocation manually. (Just in case someone did not bind variables or built a dynamic SQL string).
- Saish

Preventing Sql Injection Attacks

Similar Messages

Maybe you are looking for