Dinamic Query SQL injection

I would like to do a dinamic query. I dont know the number of columns of the column and the table, and things like that. I�m worried about sql injection how can i avoid it.
For example,
select column1,column2,....
from tabla
where column1=columna2 and...
I know the format i must build it with Java.

PreparedStatement can avoid most of the standard SQL injection attacks. However, you should not allow a client to request arbitrary SQL statements to be executed unless you have some serious security in your network and are behind a very good firewall.
- Saish

Similar Messages

B1WS CompanyService Query SQL injection potential?

In the code below will I be opening up SAP B1 to SQL injection?
The string value email will be user entered.
If so how do I pass a parameter value without string concatenation?
Is there another way of returning the Bussines Partner / cardcode based on the email address?
// construct Query
string query = "SELECT cardCode FROM OCRD WHERE E_Mail = " + email;
// create input params
CompanyService.RecordsetParams recordesetParams = new CompanyService.RecordsetParams();
recordesetParams.Query = query;
// get record set
CompanyService.Recordset recordset = companyService.Query(recordesetParams);

Hi Dave,
You could use regular expressions to validate that the email address is a valid address and not an attempt at SQL injection before passing it to the service.
As the DI Server is a black box it's hard to tell whether there is any potential to use SQL injection to attack through this interface. I'd like to think that both the DI Server and B1WS developers have already bulletproofed these interfaces against this type of attack. Hopefully someone fromt the SAP SDN team can confirm that or not. I think the B1WS source code used to be downloadable so you could check whether they are parsing the recordesetParams.Query property before it is used to query the database.
Kind Regards,
Owen

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

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 when using Search by Example on a View Object

It seems that the SQL queries generated by "Search by Example" pattern (When you drop a view object as a Search Form) are not using bind parameters, and will be vulnerable to SQL injection attacks. This pattern is very handy and could be very useful to create search pages. Is there a way to avoid SQL Injection and still use this feature in ADF?
Chandresh

Hi,
from a training slide developed by Duncan Mills:
When the user is in Find mode and enters some information, he or she is constructing a ViewCriteria row. Each attribute in the View object exists in this row and any values that the user enters into the fields are mapped into these attributes.
In most circumstances, you will only ever have one criteria row, although the developer can allow multiple rows if the Create operation is called during Find mode.
To parse the entered query values, you need to look at each row, and then at each attribute. Calling getAttribute() returns the value the user entered (if any) for that field. You can then pass that string to a filter routine (shown in the next slide), which inspects this value for errors.
The filter routine can then change the example value if required and reset the criteria.
import java.util.regex.Matcher;
import java.util.regex.Pattern;
protected String detectInjection(String criteria) {
boolean reject = false;
String testPattern =       "^(>=|<=|=<|=>|<|>|<>|!=|=|BETWEEN|IN|LIKE|IS)";
String testCriteria = criteria.trim().toUpperCase();
    if (testCriteria != null && testCriteria.length() > 0) {
      Pattern pattern = Pattern.compile(testPattern);
      Matcher matcher = pattern.matcher(testCriteria);
      if (matcher.find())
        reject = true;
    return reject?null:criteria;
}Frank

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 with CF7 and MS SQL 2005

I looked through a bunch of SQL injection posts and couldn't
find a definitive answer to this...
Let me introduce this by saying that I know I should be using
CFQUERYPARAM with EVERY CF variable in a CFQUERY tag. No excuses.
But for a necessary quick fix, if I only use it for numeric
DB fields, is SQL injection still possible (using MS SQL 2005)?
I've yet to successfully perform SQL injection while manipulating a
variable surrounded by single quotes in the query.
Scenario 1) select * from users where user_id=#form.user_id#
...is a gimme to hack, but
Scenario 2) select * from users where
password='#form.password#' ...is another story
Has anyone ever heard of a successful SQL injection attack in
a Scenario 2 situation.
I'll fix everything up eventually, but I've got a Pen Test
coming up soon, and a lot of raw code to review.
Thanks

quote:
Originally posted by:
Dan Bracuk
What others can do is more relevent than what we think. When
in doubt, test.
very true, although my final solution went more like, "When
in doubt, manually add about 600 cfqueryparams in 406 cfquery
tags".

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.

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.

Using a string variable as a query SQL statement

I want to construct a custom SQL statement in a string var, then use that var in the cfquery statement. What is the proper syntax? Here is my feeble attempt:
<cffunction ...>
<cfset var sql_txt="">
        <cfquery name="qSBJs" datasource="cfBAA_odbc">
            "#sql_txt#"
        </cfquery>
    <cfreturn qSBJs>
I've tried using no " or # or just # or just " but nothing works.
what about:
        <cfquery name="qSBJs" datasource="cfBAA_odbc" sql="#sql_txt#">
        </cfquery>
nope. I wish there was a sql property I could fill *before* the execution of the query. Any suggestions?

Hi Adam, and/or anyone who may have a few minutes to check this... I got the following code to work. It calls the getSBJs function from Flash Builder 4. I get the correct result set back. Long table names are replaced with short abreviations. Note that some local vars are declared but not used in the following example. I will use them in the future versions of this same code. Since I will in the future, like a donkey, mindlessly use this same method for all my queries, it would be much appreciated if I could get a guru to check this code for:
-Pure idiocy
-Mild insanity
-SQL injection vulnerability
-Memory leakage
-Scope dangers
(ignore emoticons, see the underlying text)
    <cffunction name="AbrvTblNms" output="false" returntype="string" >
        <cfargument name="txt" type="string" required="true" />
        <cfset var qAbrvs="">
        <cfset var output_str="#ARGUMENTS.txt#">
        <cfquery name="qAbrvs" datasource="cfBAA_odbc" result="rsltAbrvs">
            SELECT TBL_NM, ABRV FROM BAA_TBL_ABRV ORDER BY 1
        </cfquery>
    <cfloop query="qAbrvs">
            <cfset output_str = Replace(output_str, '[' & qAbrvs.TBL_NM & ']', qAbrvs.ABRV, "ALL")>
    </cfloop>
        <cfreturn output_str>
    </cffunction>
    
    <cffunction name="getSBJs" output="false" access="remote" returntype="any" >
        <cfargument name="srch_val" type="string" required="true" />
        <cfset var qSBJs="">
        <cfset var sql_txt="">
        <cfset var whr="">
        <cfset var b=False>
        <cfset var in_txt="">
        <cfset var fm_dt="">
        <cfset var to_dt="">
        <cfset var on_dt="">
        <cfset var pht="">
        <cfset var srch_str="">
        <cfset var srch_trm="">
        
        <cfset srch_str = "#ARGUMENTS.srch_val#">
        
        <cfif Not (Len(srch_str))>
            <cfset srch_str = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">
        </cfif>
        <cfset srch_trm = "#srch_str#">
        <cfset sql_txt =
            "SELECT DISTINCT
              [BAA_SBJ].SRC_SYS_NM, [BAA_SBJ].SRC_SYS_GUID, [BAA_SBJ].OBJ_GUID, [BAA_SBJ].SBJ_NM, [BAA_SBJ].SBJ_DOB, [BAA_SBJ].SBJ_ID, [BAA_SBJ].NOTE, [BAA_SBJ].CDT, [BAA_SBJ].CTM, [BAA_SBJ].CBY, [BAA_SBJ].MDT, [BAA_SBJ].MTM, [BAA_SBJ].MBY
            FROM
              BAA_SBJ [BAA_SBJ]
              LEFT JOIN BAA_SES [BAA_SES] ON [BAA_SES].PAR_GUID = [BAA_SBJ].OBJ_GUID
              LEFT JOIN BAA_IMG [BAA_IMG] ON [BAA_IMG].PAR_GUID = [BAA_SES].OBJ_GUID
            WHERE [WHERE_CLAUSE] ORDER BY [BAA_SBJ].SBJ_NM">
        <cfset whr = "([BAA_SBJ].SBJ_NM CONTAINING TRIM( rm_srch_trm1 ) OR " &
                "[BAA_SBJ].NOTE CONTAINING TRIM(:prm_srch_trm2 ) OR " &
                "[BAA_SBJ].SBJ_DOB CONTAINING TRIM(:prm_srch_trm3 ) OR " &
                "[BAA_SES].SES_TYP CONTAINING TRIM(:prm_srch_trm4 ) OR " &
                "[BAA_SES].NOTE CONTAINING TRIM(:prm_srch_trm5 ) OR " &
                "[BAA_IMG].NOTE CONTAINING TRIM(:prm_srch_trm6 ))">
        <cfset sql_txt = Replace(sql_txt,"[WHERE_CLAUSE]", "#whr#", "ALL")>
        <cfset sql_txt = AbrvTblNms(sql_txt)>
    
        <cfscript>
        queryService = new query();
        queryService.setDatasource("cfBAA_odbc");
        queryService.setName("qSBJs");
        queryService.setAttributes(sql="#sql_txt#");
        queryService.addParam(name="prm_srch_trm1", value="#srch_trm#", cfsqltype="VARCHAR");
        queryService.addParam(name="prm_srch_trm2", value="#srch_trm#", cfsqltype="VARCHAR");
        queryService.addParam(name="prm_srch_trm3", value="#srch_trm#", cfsqltype="VARCHAR");
        queryService.addParam(name="prm_srch_trm4", value="#srch_trm#", cfsqltype="VARCHAR");
        queryService.addParam(name="prm_srch_trm5", value="#srch_trm#", cfsqltype="VARCHAR");
        queryService.addParam(name="prm_srch_trm6", value="#srch_trm#", cfsqltype="VARCHAR");
        result = queryService.execute();
        qSBJs = result.getResult();
        </cfscript>
        
        <cfreturn qSBJs>
    </cffunction>
THANKS TO ADAM AND DAN FOR HELPIMG ME GET THIS FAR! Now, don't let me embarass you by doing something dum and giving you "credit", if you see me doing something dum above. Thanks!

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

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

Sql injection question

This is about a stackoverflow question.
http://stackoverflow.com/questions/1267025/how-to-calculate-value-of-string-in-oracle
I (aka tuinstoel) have provided an answer how to protect against sql injection but I'm not completely sure I'm offering good advice.
My answer on stackoverflow:
http://stackoverflow.com/questions/1267025/how-to-calculate-value-of-string-in-oracle/1268243#1268243
Can anyone say whether my method is sound or provide one or more counterexamples?

how about parsing the dynamic SQL and getting an execution plan for it first - and then check that execution plan against a kind of predefined templateIsn't a nice xml output not much easier to parse?
SQL> declare
     cl clob;
begin
     dbms_lob.createtemporary (
          cl,
          true
     sys.utl_xml.parsequery (
          user,
          'select e.deptno from emp e where deptno = 10',
          cl
     dbms_output.put_line (cl);
     dbms_lob.freetemporary (cl);
end;
<QUERY>
<SELECT>
    <SELECT_LIST>
      <SELECT_LIST_ITEM>
        <COLUMN_REF>
          <SCHEMA>MICHAEL</SCHEMA>
          <TABLE>EMP</TABLE>
          <TABLE_ALIAS>E</TABLE_ALIAS>
          <COLUMN_ALIAS>DEPTNO</COLUMN_ALIAS>
          <COLUMN>DEPTNO</COLUMN>
        </COLUMN_REF>
        <COLUMN_ALIAS>DEPTNO</COLUMN_ALIAS>
      </SELECT_LIST_ITEM>
    </SELECT_LIST>
</SELECT>
<FROM>
    <FROM_ITEM>
      <SCHEMA>MICHAEL</SCHEMA>
      <TABLE>EMP</TABLE>
      <TABLE_ALIAS>E</TABLE_ALIAS>
    </FROM_ITEM>
</FROM>
<WHERE>
    <EQ>
      <COLUMN_REF>
        <SCHEMA>MICHAEL</SCHEMA>
        <TABLE>EMP</TABLE>
        <COLUMN>DEPTNO</COLUMN>
      </COLUMN_REF>
      <VALUE>10</VALUE>
    </EQ>
</WHERE>
</QUERY>
PL/SQL procedure successfully completed.;)

Sql injection avoiding

If someone enters sql commands into a text element for address or name, how does cfqueryparam help protect against sql injection ?
Would a regular expression or something checking for dangerous key words help at least as much ?

It protects by explicitly telling the database "the string I am about to send you is just a string, to be substituted into a query as a variable". That way the database doesn't try and execute part of that string as SQL as can happen without.
There is also the cfsqltype attribute - if you're sending a number, but with the value "DROP TABLE users" then CF can stop it before it even gets to the database, so basically makes your variables type-safe to a degree.
If you want a watertight solution, go for both. Regex so you can nicely tell the user they've inputted something invalid, and queryparam as a last resort to stop someone screwing over your data.

Dinamic Query SQL injection

Similar Messages

Maybe you are looking for