SQL injection problem

hi
How can we solve SQL injection problem in JDBC ?
this means if we have a form with text field and the user must enter a number say 4 , instead he entered "4 or true" this will concatenated with the SQL query and return all records because of "or true"....
is there any solutions ?
i tried PreparedStatment and it words but not alwayes
good luck

i clearfied this in my first post
if u didnt got what i mean u can google it
http://www.google.com
thanksYou didn't gently provide keywords, like I always do, so I cannot learn from you.
Well, with a "reproduceable example" I mean that you have to post a short but complete working code snippet which reproduces the problem. So that we can copy'n'paste it in our environment here and test/debug it ourself and then eventually confirm the SQL injection.

Similar Messages

SQL Injection and variable substitutions

Hello helpful forum, I'm trying to understand what really goes on "behind" the scenes
with the variable substitutions in order to protect from sql injections.
I'm using apex 3.0.0.00.20
The trickiest component seems to be a Report of type "pl/sql returning sql", since
multiple dynamic sql interpretations are done there.
consider the following innocent looking disaster:
DECLARE
l_out VARCHAR2(2000);
BEGIN
l_out := 'select * from test_injection t where t.name like ''%' || :NAME || '%''';
RETURN l_out;
END;
if NAME is a single quote the report will return:
failed to parse SQL query: ORA-00911: invalid character
which hints to the fact that NAME is not escaped, and you are in fact able to access db functions
as in: '||lower('S')||'
I also tried to put there a function that runs in a autonomous transaction to log its calls, and
I see that it's called five times for each request.
consider now the similar solution (notice the two single quotes):
DECLARE
l_out VARCHAR2(2000);
BEGIN
l_out := 'select * from test_injection t where t.name like ''%'' || :NAME || ''%''';
RETURN l_out;
END;
with this second example nothing of the above is possible.
So my theory (please confirm it or refute it) is that there is a first variable substitution done
at the pl/sql level (and in the second case :NAME is just a string so nothing is substituted).
Then the dynamic sql is executed and it returns the following string:
select * from test_injection t where t.name like '%' || :NAME || '%'
now another substitution is done (at an "APEX" level) and then query is finally executed to return
the rows to the report.
The tricky point seems to be that the first substitution doesn't escape the variable (hence the error
with the single quote), while the second substitution does.
Please let me know if this makes sense and what are the proper guidelines to avoid sql injection with
the different kinds of reports and components (SQL, pl/sql returning sql, processes, ...)
Thanks

Giovanni,
You should build report regions like this using the second method so that all bind variables (colon followed by name) appear in the resultant varchar2 variable, l_out in your example, which will then be parsed as the report query. This addresses not only the SQL injection problem but the shared-pool friendliness problem.
Scott

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

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 protection help

In trying to help another user, I was reminded of a problem I
face
often. Trying to create a DW recordset using an IN clause (I
think this
got broken in the 8.0.2 update and seems to still be broken
in CS3).
I create a string held in a variable like this:
$ids = (1,5,9,23,6)
My advanced recordset is this:
SELECT * FROM tbl WHERE id IN varIds
Then I set the variable parameters to type=text,
default=(-1), and
runtime to $ids.
The generated SQL doesn;t work because DW puts single quotes
around my
variable and the SQL query becomes invalid. DW creates this:
SELECT * FROM tbl WHERE id IN '(1,5,9,23,6)'
It should be:
SELECT * FROM tbl WHERE id IN (1,5,9,23,6)
So, I edited the SWITCH block at the top of the document to
include a
"custom" type, which is the same as the TEXT type but without
the single
quotes.
case "custom":
$theValue = ($theValue != "") ? $theValue : "NULL";
break;
Then in my SQL statement, I manually changed "text" to
"custom".
This work fine, but does that open me up to SQL injection or
other bad
stuff?
Alec Fehl, MCSE, A+, ACE, ACI
Adobe Community Expert
AUTHOR:
Microsoft Office 2007 PowerPoint: Comprehensive Course
(Labyrinth
Publications)
Welcome to Web Design and HTML (Labyrinth Publications)
CO-AUTHOR:
Microsoft Office 2007: Essentials (Labyrinth Publications)
Computer Concepts and Vista (Labyrinth Publications)
Mike Meyers' A+ Guide to Managing and Troubleshooting PCs
(McGraw-Hill)
Internet Systems and Applications (EMC Paradigm)

It looks like you're using PHP ... to protect from SQL
injections I always
do this:
$query = "SELECT * FROM tbl WHERE col='%s' AND col2 IN
(%d,%d)"
$query = sprintf($query,"val",34,23);
$result = mysql_query($query);
This method ensures that if a user puts "DELETE FROM tbl" in
an input
field, it will not cause any deletions, instead the words
'DELETE FROM tbl'
will be inserted. Check out sprintf in the PHP manual - good
stuff!
One thing to remember about SQL injection, the injected SQL
has to be
entered somehow by the end-user (usually with a form); I may
be wrong, but
this sql statement looks like it is contained entirely within
your scripts
(i.e. it isn't getting getting a user-generated value to
build any part of
the SQL statement). Again, I'm guessing here - but it looks
that way.
Alex
"Alec Fehl" <[email protected]> wrote in message
news:[email protected]...
> In trying to help another user, I was reminded of a
problem I face often.
> Trying to create a DW recordset using an IN clause (I
think this got
> broken in the 8.0.2 update and seems to still be broken
in CS3).
>
> I create a string held in a variable like this:
> $ids = (1,5,9,23,6)
>
> My advanced recordset is this:
>
> SELECT * FROM tbl WHERE id IN varIds
>
> Then I set the variable parameters to type=text,
default=(-1), and runtime
> to $ids.
>
> The generated SQL doesn;t work because DW puts single
quotes around my
> variable and the SQL query becomes invalid. DW creates
this:
>
> SELECT * FROM tbl WHERE id IN '(1,5,9,23,6)'
>
> It should be:
>
> SELECT * FROM tbl WHERE id IN (1,5,9,23,6)
>
> So, I edited the SWITCH block at the top of the document
to include a
> "custom" type, which is the same as the TEXT type but
without the single
> quotes.
> case "custom":
> $theValue = ($theValue != "") ? $theValue : "NULL";
> break;
> Then in my SQL statement, I manually changed "text" to
"custom".
>
> This work fine, but does that open me up to SQL
injection or other bad
> stuff?
>
>
> --
> Alec Fehl, MCSE, A+, ACE, ACI
> Adobe Community Expert
>
> AUTHOR:
> Microsoft Office 2007 PowerPoint: Comprehensive Course
(Labyrinth
> Publications)
> Welcome to Web Design and HTML (Labyrinth Publications)
>
> CO-AUTHOR:
> Microsoft Office 2007: Essentials (Labyrinth
Publications)
> Computer Concepts and Vista (Labyrinth Publications)
> Mike Meyers' A+ Guide to Managing and Troubleshooting
PCs (McGraw-Hill)
> Internet Systems and Applications (EMC Paradigm)

SQL Injection Produces "Wrong Name" Errors

Hi all,
By now, you're familiar with the SQL Injection attacks
floatin' around out there, but what has me puzzled is how my
ColdFusion servers are responding to them. For each SQL Injection
attempt, CF throws an application error; this is from my
APPLICATION.LOG:
"Error","jrpp-953","09/19/08","13:27:04",,"Application (wrong
name: com/ms/asp/Application) The specific sequence of files
included or processed is: D:\MySite\web\product.cfm "
I've seen others complaining about this on ColdFusion MX 6,
ColdFusion MX 7 and ColdFusion 8, but every discussion terminates
mysteriously without a solution. It's an evil conspiracy....
Any help is greatly appreciated.

Hello,
Were you able to solve this problem and how?
Thanks

SQL Injection threat with APEX developed applications

We are using a tool, HP WebInspect, to scan some of our APEX developed applications for web application security testing and assessment. We are getting some critical and high vulnerabilities identified (see below) and would like to know if someone else has encoutered these and to determine a solution, whether it be a setting/settings within APEX or is it more related to the application and the way it was developed.
Critical:
Possible SQL Injection
File Names: • https://xxx.edu:443/pls/apex/f?p=4550:1:36080644498857::NO:4::&success_msg=If+7
77-777-1911form%40value777.com+exists+in+our+records'+OR%2cwe+will+send+the+workspace+name
s+associated+with+this+email+address.+If+you+are+having+problems+receiving+the+workspace+name
s%2cplease+contact+your+administrator.%2fC34A0EF5494AB92C95AA4D0F7BF52332%2f
• https://busaff-test.utdallas.edu:443/pls/apex/f?p=4550:1:36080644498857::NO:4::&success_msg=If+7
77-777-1911form%40value777.com+exists+in+our+records%2cwe%2bwill%2bsend%2bthe%2bworkspace
%2bnames%2bassociated%2bwith%2bthis%2bemail%2baddress.%2bIf%2byou%2bare%2bhaving%2bprob
lems%2breceiving%2bthe%2bworkspace%2bnames'%2bOR%2cplease+contact+your+administrator.%2fC3
4A0EF5494AB92C95AA4D0F7BF52332%2f
High:
Possible Username or Password Disclosure
File Names: • https://xxx.edu:443/pls/apex/f?p=104:101:1328157658320206:&notification_msg=Invali
d%20Login%20Credentials/156F2A38AC41E25732821ABED8AA98B6/
• https://xxx.edu:443/pls/apex/f?p=104:101:2360963243212364&notification_msg=Invali
d%20Login%20Credentials/156F2A38AC41E25732821ABED8AA98B6/

You can help us by telling us your first name, putting it into your profile, and by selecting a friendlier handle.
The details you showed indicate no SQL injection possibilites whatsoever. The "Critical" examples also are unrelated to Application Express applications that you may have developed (application 4550 is the login application for the product itself and should rarely be used by end users in production environments).
Scott

SQL Injections and XSS - Escaping Special Characters

Hi, hope someone can help in regards to security and SQL Injections and XSS.
We are using APEX 4.0.2 on Oracle 11.2.0.2.
1. It seems the special characters we have entered into normal 'Text Items' 'Text Areas' etc are not being escaped (ie <,>,&, '). If I enter them into the field (ie Surname) they are saved as is into session state and the database - no escaping. Am I missing something such as an environment setting as I thought the "smart" oracle escaping rules would cater for this.
Surely I don't have to manually do each of then.
Just to confirm, am I looking in the correct places to assess if the characters are escaped or not - ie should they show as '&<>' in session state and/or the database ?
2. Also, for the Oracle procedures such as '‘wwv_flow.accept’ , ‘wwv_flow.show’ , 'wwv_flow_utilities.show_as_popup_calendar' - do these escape special characters. If not, then they must be vulnerable to SQL Injections attacks.
Thx
Nigel

Recx Ltd wrote:
Just to pitch in, escaping values internally (either in the database or session state) is extremely problematic. Data searches, string comparison, reporting and double escaping are all areas which suffer badly when you do this.
Stripping characters on input can also cause problems if not considered within the context of the application. Names such as "O'Niel", statistical output such as "n < 300", fields containing deliberate HTML markup can be annoying to debug. In certain situations stripping is totally ineffective and may still lead to cross-site scripting.
Apex applications that share the database with other applications will also be affected.
The database should contain 'raw' unfettered data and output should be escaped properly, as Joel said, at render time. Either with Apex attributes or using PLSQL functions such as htf.escape_sc() as and when required.Do not needlessly resurrect old threads. After a couple of months watches expire and the original posters are not alerted to the presence of your follow-up.
Shameless plug: If you are in the game of needing to produce secure Apex code, you should get in touch.This crosses the line into spam: it violates the OTN Terms of Use—see 6(j).
Promotional posts like this are liable to be removed by the moderators.

SQL: Having problems passing a date value to dynamic SQL

SQL Version 2008 (not R2)
Problem: 1) I'm getting the following error message when trying to run the sql code below.
SQL "Messages" Returned when running code:
Msg 206, Level 16,
State 2, Procedure uspxc_WAWP_10_Get_VPData, Line 0
Operand type clash: int is incompatible with date
Loaded VP DATA for Month: 20121201
Problem Code Line:
SET @dynamicSQL = 'EXEC ' + @StoredProcedureName + ' ' + @DEVModeYN + ', ' + CAST(@WIPMonth as varchar);
Any help would be greatly appreciated. I've spent several hours trying to get around this error.
Full Code:
ALTER PROCEDURE [dbo].[uspxi_XIUD_98_DataConversionGET_VP_WIPJobHistory] (@DEVModeYN nchar(1) = 'D', @WIPMonth Date)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @returnCode AS INT ,
   @dynamicSQL AS VARCHAR(8000),
   @msg as varchar(60),
   @DEVModeYN nchar(1) = 'D',
   @WIPMonth date = '20121201',
   @StoredProcedureName AS VARCHAR(60)
SET @returnCode = 0
SET @StoredProcedureName = 'uspxc_WAWP_10_Get_VPData'
-- Check to see if @StoredProcedureName exists in the database.
IF EXISTS(SELECT name FROM sys.procedures WHERE name = @StoredProcedureName)
BEGIN
  -- RUN SP to Import VP Data for each WIPMonth parameter value
  SET @dynamicSQL = 'EXEC ' + @StoredProcedureName + ' ' + @DEVModeYN + ', ' + CAST(@WIPMonth as varchar);
  SELECT @dynamicSQL;
  -- RUN stored procedure for WIP Month
  EXEC (@dynamicSQL);
  SET @returnCode = 0;
  SELECT @returnCode;
  SET @msg = 'Loaded VP DATA for Month: ' + @WIPMonth;
  PRINT @msg;
  GoTo SPEND
END
ELSE
  SET @returnCode = 1;
  SET @msg = 'NO DATA IMPORTED for Month: ' + CAST(@WIPMonth as varchar(10))
  PRINT @msg
SPEND:
END
Bob Sutor

When you work with dynamic SQL, you should never build a full SQL string by concatenating values, because this is more difficult to get right and also has problems with SQL injection and efficient use of the SQL Server cache.
So the correct way to do this in dynamic SQL would be:
SET @dynamicSQL = 'EXEC ' + quotename(@StoredProcedureName) '@DEVModeYN, @WIPMonth';
EXEC sp_executesql @SQL, N'DEVModeYN nchar(1), @WIPMonth date',
   @DEVModeYN, @WIPMonth
A lot easier and cleaner! (Note that the variable @SQL must be declared as nvarchar.)
...however, in this particular case, this is still an overkill, and there is no need for dynamic SQL at all. EXEC accepts a variable for the procedure name, so:
EXEC @StoredProcedureName @DEVModeYN, @WIPMonth
...but it does not stop there. You can make all these changes, but you will get the same error. To wit, you get the error on Line 0, which means that it is the call to the procedure that fails. Apparently, you are passing an integer value, when you were
supposed to pass a date. Maybe you forgot to put the dates in quotes?
Erland Sommarskog, SQL Server MVP, [email protected]

Stored Procedure vs SQL Injection

Hello
I am workin in a migration project. In this project we are remaking a web application based in ASP classic to ASP.NET but there is a serious problem: the principal query is suprisingly slow in the ASP.NET application and I don't know why.
I'm using a stored procedure which contains the same query used in ASP classic, but it is slower than the query itself. I'd been doing some test and definitely the use of stored procedure with ASP.NET is slower than de sql injection in ASP classic and this seems very improbable theoretically.
I really need to improve the speed of that stored proceudre but I don't know how, and it is driving me crazy because the query is a simple select.
I'll thank every help/explanation about it.
sorry for my english.

I think you may have posted in the wrong section of the forum since this really doesn't sound like this is necessarily an issue with ODP.NET or even anything Windows / .NET-related.
That said, have you tried running the procedure using SQL-Plus? You should also check the explain plan to make sure that you're taking advantage of indexes, etc. although if the query by itself is fast, then there may be a problem with the way the procedure is written. Also, as far as I know it's almost impossible to figure out why a query is slow based on the info you've given thus far. You may want to post some or all of the procedure if you're able to do so without causing problems with your employer. Without any way to recreate the issue, it's hard to say what the problem might be. Again, though....try running the procedure using SQL-Plus directly and see how that works out.

SAP ABAP Secure Coding. Protection against SQL Injection

Dear community,
I've detected recently a problem with dynamic SQL queries. It seems to be security relevant. I'll be much appreciated, when you participate at my online survey to this topic at: http://de.surveymonkey.com/s/VC9CBVM It takes less than 1 min time. It is very important to understand, whether it is necessary to protect the coding against SQL injection? Or you can say from your expirience, that it isn't?
Thanks a lot!
Moderator Message: if you need a poll support from SCN, then there is an area http://scn.sap.com/poll-post!input.jspa?container=2015&containerType=14 to create such. Please use it and avoid external links.
Message was edited by: Kesavadas Thekkillath

Dear community,
I've detected recently a problem with dynamic SQL queries. It seems to be security relevant. I'll be much appreciated, when you participate at my online survey to this topic at: http://de.surveymonkey.com/s/VC9CBVM It takes less than 1 min time. It is very important to understand, whether it is necessary to protect the coding against SQL injection? Or you can say from your expirience, that it isn't?
Thanks a lot!
Moderator Message: if you need a poll support from SCN, then there is an area http://scn.sap.com/poll-post!input.jspa?container=2015&containerType=14 to create such. Please use it and avoid external links.
Message was edited by: Kesavadas Thekkillath

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> !!

CS3/CS4 protecting against SQL Injection

Hi:
I was wondering if the newer versions of Dreamweaver like CS3/CS4 do a good enough job to protect against SQL Injection when using the built in Insert/Update/Delete behaviors or should I use Commands with Stored Procedures (MS SQL)?
Thanks!
Mitch

David , Günter - many thanks for your help !
In my ignorance I appear to have been misled by my website host who, in response to a related problem, informed me as follows:
"your website's scripting does appear to be highly vulnerable to SQL injection attack, this can be easily seen via the following example:
/s-sub_detail.php?cat_id=TEST
As you can see, arbitrary data entered as the cat_id variable of the shopping cart script is being passed unchecked to the SQL server, which is then returning a notice relevant to the data passed (in the above example case this is an "unknown column" error) - This effectively demonstrates that your shopping cart script performs no validation on variables used within the script and passes them directly to the SQL server, which means arbitrary commands can potentially be added as variable data for the SQL server to execute.
In order to correct this all variables and any other posted data used by the shopping cart script must be fully validated by the script itself before being passed to the SQL server so that SQL commands cannot be executed by simply manually entering these as a script variable".
Thanks to David I understand the issue with the need for data validation but the response above appears to indicate that they believe there is more to it.
David and Günter - I would welcome your response to the above and perhaps recommendations for SQL injection vulnerability testing.
Kind regards
J

Combating SQL Injection

Using CFMX7:
In trying to block out SQL Injection we are implementing
‘<cfquery params’ on all related query statements
for our application, however this is an undertaking for several
queries that need to be validated with params.
In the meantime, we have been exploring methods which include
the ODBC statement lockouts in CF Admin for the database
connection.
What we have found is the following; setting the Allowed SQL
of ‘DROP’ to FALSE, will catch an injection of DROP
TABLE only if that statement is in the actual body of the query,
alone.
This is trapped as exception:
<cfquery
name="tryDrop" datasource="mydatasource">
DROP TABLE mytest
</cfquery>
However, the following is NOT caught:
<cfquery
name="tryDrop" datasource="mydatasource">
UPDATE mytest SET sortorder = 5; DROP TABLE mytest
</cfquery>
In this case, the ODBC still allows the DROP statement to be
executed.
We have also tested this case as shown above as well as a SQL
INJECT item using a variable for an INT field (below), which also
is allowed.
<cfset
myString = “1; DROP TABLE mytest;”> 
<cfquery name="tryDrop" datasource="mydatasource">
UPDATE mytest SET sortorder = #myString#
</cfquery>
Is there a patch or fix that will correct the ODBC level to
prevent this case?
Note: after the setting the SQL Command DROP to false, we
tried restarting CF Service and also tried suspending all ODBC
connections for that datasource and neither solved the problem.
Any information would be appreciated.

quote:
Originally posted by:
jb_aggie
Also, in MS SQL Server 2000 is there a way to restrict these
permissions for a database user on the database level? I can only
find this permission on the table level.
USE master
GO
-- run only if user account exists in master database
-- if it does you should probably remove it from master, it
should have access only to user created databases, not system
databases
IF EXISTS ( SELECT * FROM sysusers WHERE [name] = 'test' )
BEGIN
DENY
CREATE DATABASE,
CREATE DEFAULT,
CREATE FUNCTION,
CREATE PROCEDURE,
CREATE RULE,
CREATE TABLE,
CREATE VIEW,
BACKUP DATABASE,
BACKUP LOG
TO test
END
USE MyDatabase
GO
DENY
CREATE DEFAULT,
CREATE FUNCTION,
CREATE PROCEDURE,
CREATE RULE,
CREATE TABLE,
CREATE VIEW,
BACKUP DATABASE,
BACKUP LOG
TO test
Also remove the user from all roles except public and grant
only the permissions needed for your application and only the
database(s) used by your application.
As long as your account is not an administrative account or
owner of database objects it should not be able to DROP tables.
http://msdn.microsoft.com/en-us/library/aa258841(SQL.80).aspx

Is cfinsert and cfupdate open to SQL Injection

Hello All,
I'm looking for a real answer on if cfinsert and cfupdate are vulnerability to SQL Injection. The closest thing I can find from Adobe is Ben Forta's Personal recommendation. I was hoping to find some form of "official note" in the live docs to indicate there is a SQL Injection issue with cfinsert - cfupdate. (Other than someone's post to Ben's Blog)
http://www.forta.com/blog/index.cfm/2006/10/3/Use-CFINSERT-And-CFUPDATE
In this forum I have seen this question asked, and the only answer is "You should validate your inputs". Yes, you should, but that does not answer the question of if cfinsert and cfupdate is vulnerability to SQL Injection.
I have found this blog entry that if I interpret is correctly from his findings cfinsert and cfupdate where only vulnerability to SQL Injection IF you did not give cfinsert - cfupdate the list of fields to take action on. -Is this true?
http://blog.securityps.com/2009/05/demystifying-cfinsert-sql-injection.html
Also, on a closely related note, is cfinsert - cfupdate on ColdFusion 9 also vulnerable? If so, why? Seems like a BUG that could be easly addressed by the CF server team.
Thank you,

I do agree with you here. But to be devil's advocate for a second: the same could be said of <cfquery>. One has to take additional measures to ensure the same vulnerabilities are mitigated with that.
I'm not sure that it's really news that these two tags are not the most well-thought-out features in the CF arsenal, and if you listen to most opinions in the community regarding <cfinsert> and <cfupdate>, it's: "don't use them".
They're great for quick and dirty insert/update processes in internal or test code, but I'd never use them in production.
It also remains a fact that any external input (form fields, URL param) must be validated as being kosher and within expected margins before they're used in any way. That is just common sense. And if one neglects to do that: one brings any eventuality onto one's self. The problem here really is with people not doing their "due diligence" on externally sourced data, not specififcally with <cfinsert>, <cfupdate> or <cfquery>.
Still: I think Adobe should make it more clear in the docs that additional measures need to be take to make them safe. And by that time... one might as well use a <cfquery> to do the SQL.
Adam

SQL injection problem

Similar Messages

Maybe you are looking for