SQL Injection Blocker

Hello all-
I've got a server with a huge number of ColdFusion templates
(over 10,000) which I really need to protect agains SQL Injection.
I know that CFQUERYPARAM is the best way to do this. I'd love
to do it that way, but with so many pages, and so many queries it
would take weeks/months to fix the queries, then test to make sure
I didn't screw something up.
So, I've come up with a plan that I wanted to get some input
on.
Currently, I have a page on my server that is included in
almost every page that runs. It is a simple page that I can modify
to change the status of my systems in the event of a database
changeover, or some other sort of failure. (The pages still run,
but no updating is allowed, only reading)
Okay, so on this page which is always included, I was
thinking about analyzing the variables that come over. I was
thinking about looking for things that looked like a SQL injection
attack and blocking the page from running.
I wanted to know if this would work- anyone have ideas? This
would be great because I could protect the entire server in about
an hour. But, I don't want to give myself a false sense of security
if this won't really do the job.

First, here are some simple things you can do to protect all
pages before you follow the other advice and plans in this thread:
In CF administrator, click on your datasources and then the
"Advanced" button.
There you will uncheck all but the read and stored procedure
and (possibly) write permissions. "Drop", "Create", etc., are
definite no-nos here.
If you haven't already, make one data source read-permissions
only and refactor your code to use it everywhere except for
carefully segregated updates, inserts and deletes.
Now, in SQL Server itself, remove all permissions from the
users that CF uses except for data_reader and (selectively) data
writer and exec permissions on any procedures or functions you use.
In SQL server, setup at least two CF users. One, should have
only the data_reader permission (plus any read-only stored
procedures).
Find articles, such as this one:
http://www.sqlservercentral.com/columnists/bknight/10securingyoursqlserver.asp,
and follow their advice, start with locking down xp_cmdshell.
These measures require little or no CF code changes but will
block all but the most determined and skilled hackers. You still
need to follow Adam's advice though.
BTW, Dan is very wrong, ALL DB's are vulnerable to SQL
injection.
SQL server is not even the most vulnerable anymore (Studies
show that Oracle now has that "honor").

Similar Messages

Spry to block script characters to protect against sql injection

I am new so please be patient and I hope I am in the right forum. I would like to set up a Spry widget that I could apply to forms in my site for text area. This would block any code like <> * and only allow a-zA-Z and 0-9. I would like to be able to add this widget to Dreamweaver so that I can call it up any time I add a text area. I am hoping to use this to block SQL injection on my sites.
Can this be done by a rookie?
Thanks!

Sure it can be done, but there are some flaws in your idea. Having a client side validation is always good for the user experiance, but these validations are only executed client side, and when the user has javascript enabled. So when you users disable javascript they would probably still be able to create SQL injections.
So I wouldn't really use client side validations for you issue, but search for a server side alternative. Most server side languages already provide you with utilities you can use to prevent the most common SQL injection types. So you might want to digg in to that first.

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 & 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 hacks

Hi,
i am a bit disappointed by the ability of cisco IPS to block sql injections, even with the new added generic sql injection signatures not long ago, still websites hosted with us are being hacked.
i know its vulnerabilities in the sites, but the command update is a lot used to hack sites, i have created a custom signature that catches "update" in small and caps, but i was surprised yesterday that the hacker used "u%pdate" and it bypassed the sensor !!
any thoughts on the subject
thanks

Interesting. I'm so not a SQL expert, but I don't see how "u%pdate" is valid SQL. Why would the database interpret "u%pdate" as valid SQL? Is the application cleaning up the input before passing to the db?
IMHO, if your customers have vulnerable apps, then they need to fix them. A network based IDS simply isn't going to be the best at detecting every possible variation of injection (or anything else imo, but that's a whole different soap box). It just doesn't have the required context. Throw TLS into the mix, and most of the time coverage drops to zero.

Generic SQL Injection in HTTP Request

So our project allows Facebook interaction. Mars sends out this Incident Event type every time someone attaches to Facebook. Is this something I can just False Positive out or should I be concerned about it? What is Facebook sending back to our network so we get this message on Mars?

I get numerous alerts from our IDSMs and have mitigated this by
1: not allowing the IDSMs to block our outgoing traffic at all. Not worth the risk causing major outage.
2: created av drop in MARS that drops all SQL Injections destined for the Facebook subnets. (69.63.176.1-69.63.183.254, 66.220.144.1-66.220.159.255)
Regards
Fredrik

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

I am using dreamweaver cs6 is it protected from various hacker attacks such as sql injection,xss,?

i mean if i built a site using php and sql using dreamweaver cs 6 ...will it be protected from various hacker attacks such as sql injection,xss,spoofed form input,etc..?? if it is not protected...tell me where can i learn to protect my website using php and sql....from all types of hacker attacks...help needed.... thank you..:)

A couple more comments.
To guard against most of these security risks, you have to completely sanitize any user input whether processed further on subsequent pages or added to a database. That complete sanitization usually involves stripping out any HTML/JavaScript, and blocking SQL-crashing equalities/inequalities.
You can get alot of information about these and other methods on the Dreamweaver AppDev forum -
http://forums.adobe.com/community/dreamweaver/dreamweaver_development?view=discussions
which is where most server-scripting topics are discussed.

Reference value of an SQLPLUS variable in a PL/SQL anonymous block

All,
Is there a way of referencing an SQLPLUS variable within a PL/SQL anonymous block. See my example below........
sqlplus -s /@${L_DB_SID} <<-ENDOFSQL >> ${L_LOGFILE}
SET FEEDBACK OFF
SET PAGES 0
SET SERVEROUTPUT ON
WHENEVER SQLERROR EXIT SQL.SQLCODE
WHENEVER OSERROR EXIT 2
VARIABLE l_ret_sts NUMBER;
VARIABLE l_ret_msg VARCHAR2(300);
exec sh_plsql_owner.sh\$secure_batch.p\$set_role(p_ret_sts => :l_ret_sts);
begin
if :l_ret_sts > 0 then
dbms_output.put_line('l_ret_sts:'||:l_ret_sts||':SECURITY');
else
${L_PLSQL_PROG}(p_ret_type => 0, p_ret_sts => :l_ret_sts, p_ret_msg => :l_ret_msg);
dbms_output.put_line('l_ret_sts:'||NVL(:l_ret_sts,0));
dbms_output.put_line('l_ret_msg:'||:l_ret_msg);
end if;
end;
exit
ENDOFSQL
I need to be able to reference :l_ret_sts in the begin block using the if statement "if :l_ret_sts > 0 then"
:l_ret_sts is populated in a procedure call beforehand.
However it seems as though the begin block cannot reference the value returned to :l_ret_sts.
Any ideas.
Ian.

Managed to solve this. I put my call to the package that the role enables via dynamic sql....
sqlplus -s /@${L_DB_SID} <<-ENDOFSQL >> ${L_LOGFILE}
SET FEEDBACK OFF
SET PAGES 0
SET SERVEROUTPUT ON
WHENEVER SQLERROR EXIT SQL.SQLCODE
WHENEVER OSERROR EXIT 2
VARIABLE l_ret_sts NUMBER;
VARIABLE l_ret_msg VARCHAR2(300);
exec dbms_application_info.set_client_info('CONTROL-M');
exec sh_plsql_owner.sh\$secure_batch.p\$set_role(p_ret_sts => :l_ret_sts);
declare
v_text varchar2(500);
begin
if :l_ret_sts > 0 then
dbms_output.put_line('l_ret_sts:'||:l_ret_sts||':SECURITY');
else
v_text := 'begin ${L_PLSQL_PROG}(p_ret_type => 0, p_ret_sts => :1, p_ret_msg => :2);end;';
execute immediate v_text using in out :l_ret_sts, in out :l_ret_msg;
dbms_output.put_line('l_ret_sts:'||NVL(:l_ret_sts,0));
dbms_output.put_line('l_ret_msg:'||:l_ret_msg);
end if;
end;
exit
ENDOFSQL
Cheers
Ian.

HTML Form in a "PL/SQL (anonymour Block)"

Hello
I need a little ugent guidance
I have create a "form" within a "PL/SQL (anonymour Block)". The requirement is to show what a HTML form looks like as you build the code
The problem is I am "Up Setting" the APEX processing i.e. wwv_flow.accept ... I have added an example below .....
All help very welcome
Thanks
Pete
htp.prn('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">');
htp.prn( '<style type="text/css">');
htp.prn('#form{font-family: "Trebuchet MS", Verdana, sans-serif; width:25em;}');
htp.prn('h2{margin: 0 0 0 0; padding: 0;}');
htp.prn('p{margin: 0 0 1em 0; padding: 0; font-size:90%}');
htp.prn('fieldset{background:#C361D2; border:none; margin-bottom:1em; width:24em; padding-top:1.5em}');
htp.prn('p.legend{background:#DED983;
color:black;
padding: .2em .3em;
width:750px;
font-size:18px;
border:6px outset #DED980;
position:relative;
margin: -2em 0 1em 1em;
width: 20em;}');
htp.prn('fieldset{margin-bottom:1em; width:66em; padding-top:1.5em;}');
htp.prn('#company {background:#F3B4F5; border:outset #F3B4F5; width="700";}');
htp.prn('#company label{position:absolute;
font-family:arial;
font-size:16px;
padding:.2em;}');
htp.prn('input{margin-left:9em;margin-bottom:.2em; line-height:1.4em;}');
htp.prn('#message1 {background:#a3B4F5; border:outset #a3B4F5; width="700";}');
htp.prn('#message2 {background:#c3B4F5; border:outset #c3B4F5; width="700";}');
htp.prn('button1 {font:48px "Trebuchet MS", "Verdana", sans-serif;
background:#F0888A;
border:outset #6EC6F1}');
htp.prn('#buttons1 input {background:#DED983;
font:1.2em "Trebuchet MS", Verdana, sans-serif}');
htp.prn('p#buttons1 {white-space:nowrap}');
htp.prn('</style>');
htp.prn('<table width="760"><tr bgcolor="#D5EAE9">');
htp.prn('<BR><BR>');
htp.prn ('<form method="" action="">');
htp.prn ('<fieldset id="company"><p class="legend" >Company</p>');
htp.prn ('<label>Comapany Name: </label> <input name="company" type="Text" size="30"/>');
htp.prn ('<br><br>');
htp.prn ('</fieldset>');
htp.prn ('<br><br><br>');
htp.prn ('<fieldset id="message1"><p class="legend">Message One</p>');
htp.prn ('</fieldset>');
htp.prn ('<br><br><br>');
htp.prn ('<fieldset id="message2"><p class="legend">Message Two</p>');
htp.prn ('</fieldset>');
htp.prn ('<br><br>');
htp.prn ('</form>');
htp.prn('</tr></table>');
End;
______________________________________________________________________________________________________

Pete:
Remove the name attributes from all input elements defined by the pl/sql process. For example
<input name="company" type="Text" size="30"/> should be replaced by <input type="Text" size="30"/> or <input name="f01" type="Text" size="30"/>
The APEX accept process recognises a predefined set of HTML form input names. Any input with a name not from this set will cause the accept process to fail. f01 through f50 are valid names for the accept procedure.
varad

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

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 -- DBA role..

Hi all,
I'm working as a SQL Server DBA,Now a days we are facing issue with attacks(SQL Injection),most of attacks are taken care by Firewalls but still some attacks hitting Database.
As a DBA How to check whether database got effected
Please help me by providing hints and tips to analysis SQL injection.
Thanks in advance

There is no easy ways to detect sql injection. You should analyze activity against databases and work with developers to address it.
Basically, you can capture sql_completed/rpc_completed events in XEvent or SQL Trace and review them. Anything, which is not parameterized, could be the subject of injection attach (it depends on Client Code and implementation).
As the side note, script below provides you the list of the databases together with number of cached execution plans that were used just once. SQL Injection targets non-parameterized queries. So the databases with large number of single-used plans are more
likely to be affected. In any case, do not rely on output much - large number of single-used plans could be just the sign of bad design rather than being affected. As I said, you need to review client app code just to be sure.
select
epa.value as [DB ID],
db_name(convert(int,epa.value)) as [DB Name],
count(*) as [Single Use Plans]
from
sys.dm_exec_cached_plans p
cross apply sys.dm_exec_plan_attributes(plan_handle) AS epa
where
p.usecounts = 1 and
p.objtype in ('Adhoc','Prepared') and
epa.attribute = 'dbid'
group by
epa.value
option (recompile)
Thank you!
Dmitri V. Korotkevitch (MVP, MCM, MCPD)
My blog: http://aboutsqlserver.com

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 Blocker

Similar Messages

Maybe you are looking for