SQL Injection and cfqueryparam

I was told to look into <cfqueryparam> to assist in
fighting sql-injection
and it makes perfect sense, up until I thought of a different
scenario...
This tag seems great when you are dealing with numbers or
text that you can
restrict the number of characters, but what if you have a
textarea that
allows for a large amount of text to be entered? I.E. a
search field for
records that uses keywords.
How you stop someone from entering damaging sql into an area
that accepts
this?
Thanks for any education.
Wally Kolcz
MyNextPet.org
Founder / Developer
586.871.4126

WebDev wrote:
It works because <cfqueryparam ....> tells the DBMS
that this data is a
value NOT SQL. The DBMS will then never process it as SQL.
When you
write the SQL and Values straight into the code, then the
DBMS does not
know what is what and assumes it all must be SQL.
An Example...
<cfquery ....>
SELECT aField FROM aTable WHERE aField = '#aValue#'
</cfquery>
With this code, ColdFusion process the entire body of the
<cfquery...>
tag into a string and sends that entire string to the DBMS as
SQL. The
DBMS then processes what it was given. If somebody can modify
the
aValue variable to change the SQL string - that is what is
processed.
<cfquery ...>
SELECT aField FROM aTable WHERE aField = <cfqueryParam
value="#aValue#"...>
</cfquery>
With this code ColdFusion process the SQL and the queryParam
as separate
things. It sends the DBMS the SQL with parameters and a list
of values
to be used in those parameters. The DBMS knows the parameters
are not
SQL and will not process it as SQL and if the parameter
contains SQL it
will just be used as a value and not parsed.
FYI... That is how <cfqueryparam...> can improve
performance. By
knowing what parts of the SQL are variables, it can cache the
SQL and
just use different variables when they are passed to the
DBMS.
HTH
Ian

Similar Messages

XML Validation using java for SQL Injection and script validation

I have an input coming from xml file.
I have to read that input and validate the input against sql injections and scripts.
I require help now how to read this xml data and validate against the above two options.
I am a java developer.
in this context what is marshelling?

http://www.ibm.com/developerworks/library/x-javaxmlvalidapi.html?ca=dgr-lnxw07Java-XML-Val
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/package-summary.html
The following code validates the xml against a xml schema
// define the type of schema - we use W3C:
String schemaLang = "http://www.w3.org/2001/XMLSchema";
SchemaFactory factory = SchemaFactory.newInstance(schemaLang);
Schema schema = factory.newSchema(new StreamSource("sample.xsd"));
Validator validator = schema.newValidator();
// at last perform validation:
validator.validate(new StreamSource("sample.xml"));Message was edited by:
haishai

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 injection and SQLFury

We have recently had an SQL injection attack on our site. The web form in question was calling a second cfm with a post command. The second cfm did the actually db insert. After extensive research and revamping of the web form I believed that I had shut it down rather convincingly. I did the following to secure the form:
- implemented the cfqueryparam tag on all applicable fields being entered in the form
- introduced a hidden, random numeric variable for verification before completing the insert; it tests for its existence and if it is numeric
- consolidated the two cfms into one page so the entry and insert are done in one cfm (to eliminate injection going directly thru insert cfm)
However, I am still getting intermittent injection errors into my MS SQL table. I don't believe it is getting in through the revised web form and am at a loss as to how it's getting through.
I am now at the point that I am looking for a utility that will scan through my site or specific pages to identify SQL injection vulnerabilties. I found something called SQLFury and downloaded it; however, there is literally no documentation with it and I have no idea how to run it. I've researched the web and found no assistance on how to use this utility. Is anyone familiar with this utility or does anyone know of any other utility that will assist with validating ColdFusion methods?
Any assistance would be very much appreciated.

Ian:
Thanks for the information. The utility is helpful and confirmed for me that my page was secure from SQL injection. The additional insight you provided has lead me to discover that my issue was not an SQL injection, but a Cross Scripting attack. A web vulnerability utility from Acunetix helped me determine that.
Thanks again,
...Wes

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

[ask] about oracle sql injection and escalation

Hello,i'm student , i'm studying oracle,now i want to research about oracle sql injection,i had read some tuttorial such as *'Hacking Oracle From Web,Advanced SQL Injection In Oracle Databases,Oracle Hacker HandBook ...'* but when i try to demo on localserver (11.0.1.6) but not run,and this is my demo
-- first,i created table users
create table users (name nvarchar2(50),pass nvarchar2(50))
-- then i created procedure with system user
create or replace procedure system.adduser(u nvarchar2,p nvarchar2)
as
begin
insert into users values(u,p);
end;
-- grant execute privilege to oc user
grant execute on adduser to oc
-- login with user oc and create a procedure
create or replace procedure sqli
as
begin
execute immediate 'grant dba to oc';
end;
-- and then,i run system's procedure
declare
begin
system.adduser('admin','admin'' ; execute immediate ''declare begin sqli() end;');
end;
i hope oracle master help me to i can understand and improving my knowledge
Thanks

The best forum for this is probably Forum Home » Java » SQLJ/JDBC
Presumably you are refering to oracle.sql.TIMESTAMP. While this is intended to (and does) correspond to java.sql.Timestamp it can't be a subclass because it needs to be a subclass of oracle.sql.Datum.

SQL Injection and Java Regular Expression: How to match words?

Dear friends,
I am handling sql injection attack to our application with java regular expression. I used it to match that if there are malicious characters or key words injected into the parameter value.
The denied characters and key words can be " ' ", " ; ", "insert", "delete" and so on. The expression I write is String pattern_str="('|;|insert|delete)+".
I know it is not correct. It could not be used to only match the whole word insert or delete. Each character in the two words can be matched and it is not what I want. Do you have any idea to only match the whole word?
Thanks,
Ricky
Edited by: Ricky Ru on 28/04/2011 02:29

Avoid dynamic sql, avoid string concatenation and use bind variables and the risk is negligible.

SQL Injection - cfqueryparam and other techniques to stop abuse?

We have been having a lot of issues with SQL injection lately and so we are trying various methods to secure the data better.
First off we have been utlizing cfqueryparam on the queries that are being hit. I am also optimizing the data tables so that more maxlengths are in place.
What else can be done to improve security? I have looked up everything and anything on the internet and keep seeing the cfqueryparam.
Does changing the variables or table names make any difference? We are trying that, but I want to make sure it is not a waste of our time.
Thanks for any other suggestions.

CFqueryparam is a good fist step, though you should note that it will not protect some queries. For example if you have a sort by or order by that is dynamic, cfqueryparam wont help in that case. You will need to review data and validate for that.
You should also be checking for XSS vulnarabilities.
http://www.12robots.com/index.cfm/2008/8/4/Persistent-XSS-Attacks-and-countermeausures-in- ColdFusion
The blog above has a great number of CF sercurity related posts.
Pete Freitag has a nice security scanner that will look at your CF server and highlight any missing patches and some other issues
http://www.petefreitag.com/item/721.cfm
There are some open source projects that will also filter out common sql injection and xss attacks on a code level.
http://portcullis.riaforge.org/
Finally there are several conferences in the CF world coming up, and all surely have some security sessions. You may want to attend.

SQL injection hacking

Hello all,
Someone is telling me that a site of mine is vulnerable to a
hacking
technique called "SQL injection". They cited a URL such as
http://www.mydomain.com/gallery.cfm?VarCatID=29
as an example.
I Googled SQL injection, and found a lot of information,
which I'm in the
midst of reading.
What I really want to know is, how serious a risk is this?
Should I be
taking action, and if so, what?
Aren't there millions of sites that use that type of URL
string?? Are they
all unsafe too?
Patty Ayers | www.WebDevBiz.com
Free Articles on the Business of Web Development
Web Design Contract, Estimate Request Form, Estimate
Worksheet

Thank you, Tom!
Patty Ayers | www.WebDevBiz.com
Free Articles on the Business of Web Development
Web Design Contract, Estimate Request Form, Estimate
Worksheet
"Tom Muck" <[email protected]> wrote in
message
news:ecuu0f$dbn$[email protected]..
> If you are passing an integer on a querystring, make
sure you validate
> that an integer is being passed, either by using a
cfparm, cfqueryparam,
> or by using the val() function on the passed querystring
variable:
>
> <cfquery name="blah" datasource="#mydsn#">
> SELECT * FROM mytable WHERE catid =
> <cfqueryparam cfsqltype="cf_sql_integer"
value="#url.VarCatID#">
> </cfquery>
>
> The DW 8.0.2 update changed the way that DW does this so
injection is no
> longer a concern.
>
> --
> --
> Tom Muck
> co-author Dreamweaver MX 2004: The Complete Reference
>
http://www.tom-muck.com/
>
> Cartweaver Development Team
>
http://www.cartweaver.com
>
> Extending Knowledge Daily
>
http://www.communitymx.com/
>
>
> "P@tty Ayers"
<[email protected]> wrote in message
> news:ecut8j$cg6$[email protected]..
>> Hello all,
>>
>> Someone is telling me that a site of mine is
vulnerable to a hacking
>> technique called "SQL injection". They cited a URL
such as
>>
http://www.mydomain.com/gallery.cfm?VarCatID=29
as an example.
>>
>> I Googled SQL injection, and found a lot of
information, which I'm in the
>> midst of reading.
>>
>> What I really want to know is, how serious a risk is
this? Should I be
>> taking action, and if so, what?
>>
>> Aren't there millions of sites that use that type of
URL string?? Are
>> they all unsafe too?
>>
>>
>> --
>> Patty Ayers | www.WebDevBiz.com
>> Free Articles on the Business of Web Development
>> Web Design Contract, Estimate Request Form, Estimate
Worksheet
>> --
>>
>>
>>
>>
>
>

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 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 & CF code Attacks

One thing I've noticed with sites using CF is that many, many
programmers do not take into account SQL Injection and CF Form/URL
variable attacks. I've seen SO many CF pages that blow up when the
input varies in the slightest, displaying CF error messages,
datasources, variable names, etc.
Seems not enough programmers use CFTRY/CFCATCH or even know
about it. I've seen where SQL table names and datasources were
being passed in a URL!! It's frightening
Interested in everyone's BEST PRACTICES to avoid these type
of attacks.
I'll start it off with a few I use:
Use CFTRY / CFCATCH.
ALWAYS set the maxlength value on form input text boxes and
make sure the value matches the corresponding column length in your
DB. If you do not, someone can enter a huge amount of data in the
field, causing your CF routine or DB to choke.
Scope all variables, URL, Form, etc.
Use numbers/integers whenever possible for URL variable
values.
Avoid using varchar as the data type in your stored
procedures for passed URL or Form variables. Use INT instead.
Validate user input using CF before passing to your SQL, etc.
queries. Test for allowed/disallowed characters, blanks, length of
input value, etc.
Use stored procedures whenever possible.
Don't make URL or Form variable names too descriptive. ex.
?m=100 is better than ?memberID=100

In addition to the things listed above, you should never
expect the values sent from any form submission to be 100% as they
are coded. There are tons of programs out there that can be used to
intercept and alter the submitted data before it hits your server.
It is a slow process, but we are locking down any and all form
variables not just type="text" and textarea's.
If a user has the ability to alter submitted data, they can
change the values for all types of form fields (hidden, radio,
checkbox, select, button, etc...). A lot of our old code did not
take that into consideration and simply allowed the value entered
from a "predefind" (hard coded value) form type (radio, checkbox,
etc...) directly into the database without a check.
Another step is to turn off "Enable Robust Exception
Information" in the CF Administrator. This step will help in not
giving an attacker the complete SQL statement being used in your
code. Note: This is a recomended practice for all production CF
servers as it is, but it never hurts to say it. CFTRY/CFCATCH
blocks work as well to hid that info, but neither way will
prevent an attack.
You also can not rely on client side JavaScript for
validation.
CR

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".

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 and cfqueryparam

Similar Messages

Maybe you are looking for