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.

Similar Messages

Best way of avoiding SQL injection?

Hey,
I was wondering what you guys would recommend to prevent SQL injections. Now, I know that you can use the PreparedStatement and setString for cases like this:
String userName = request.getParameter("username");
String sqlString = "SELECT * FROM UserTable WHERE USERNAME='" + userName ;but what can you do when you have cases like these:
String userdef_table = request.getParameter("userdef_table");
String userName = request.getParameter("username");
String sqlString = "SELECT * FROM "+ userdef_table +" WHERE USERNAME='" + userName ;Note: userdef_table can be created by the admin so I wont know what tables are around.
thanks,
domet

For Your First Question
1) using PreparedStatement is the best way, but yes you will have to catch the Table Not Found Exception very well in case the passed table deso not exist... Thats The Only Logical Answer For your Query
For Your Second Query
1) Create a String variable which will have the required reflex string ie the text you would liketo have after LIKE keyword and then pass the variable to the prepare statement
this
?% will not work for its wrong SQL query
String likeThis = "%Bill%"; <or what ever>
the Query part will be like this ".......like ?"
setString(....,likeThis);
Hope This Works
Bhaskar

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 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 & 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 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 on Oracle

Good night:
I'm trying to understand the use of oracleparameters in visual basic .net 2008. It is said that its goal is to avoid sql injection but as far as I know Oracle throws an exception every time you use a ;, so I assume it is not possible to inject malicious sql to oracle.
Does anybody knows if it's possible and how to do an sqlinjection to Oracle by means of an ado .net command?.
Thank you

Section Understanding SQL Injection Attacks in Securing a .NET Application on the Oracle Database:http://www.oracle.com/technology/pub/articles/mastering_dotnet_oracle/cook_masteringdotnet.html shows examples in VB .Net.

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

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

Dreamweaver CS3 and sql injection....

Any news if Dreamweaver CS3 will have the same "problems"
brought on by the
8.0.2 update to Dreamweaver 8?
Thanks!

Excellent...glad to hear it and I look forward to getting
CS3. I held off
on 8 because of the so called problems.
"Murray *ACE*" <[email protected]> wrote
in message
news:[email protected]...
> Yes, that's what I do. Honestly, I've not seen any
problems there.
>
> --
> Murray --- ICQ 71997575
> Adobe Community Expert
> (If you *MUST* email me, don't LAUGH when you do so!)
> ==================
>
http://www.dreamweavermx-templates.com
- Template Triage!
>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
> ==================
>
>
> "Pizza Good" <[email protected]> wrote in
message
> news:[email protected]...
>>I think it comes up more when you have a form and
pass the values to a
>>recordset which uses those values to query and filter
a recordset.
>>
>>
>> "Murray *ACE*"
<[email protected]> wrote in message
>> news:[email protected]...
>>>I am processing form input, which I believe is
where SQL injection comes
>>>in.
>>>
>>> --
>>> Murray --- ICQ 71997575
>>> Adobe Community Expert
>>> (If you *MUST* email me, don't LAUGH when you do
so!)
>>> ==================
>>>
http://www.dreamweavermx-templates.com
- Template Triage!
>>>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>>>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>>>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
>>> ==================
>>>
>>>
>>> "Pizza Good" <[email protected]> wrote
in message
>>> news:[email protected]...
>>>> That's good, or perhaps you are not building
the types of sites that
>>>> may encounter the so called problems?
>>>>
>>>>
>>>> "Murray *ACE*"
<[email protected]> wrote in message
>>>> news:[email protected]...
>>>>>I have to say that I've used 8.0.2 with
such things quite a bit and not
>>>>>encountered *any* of the posted problems.
>>>>>
>>>>> --
>>>>> Murray --- ICQ 71997575
>>>>> Adobe Community Expert
>>>>> (If you *MUST* email me, don't LAUGH
when you do so!)
>>>>> ==================
>>>>>
http://www.dreamweavermx-templates.com
- Template Triage!
>>>>>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>>>>>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>>>>>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
>>>>> ==================
>>>>>
>>>>>
>>>>> "Paul Whitham AdobeCommunityExpert"
<[email protected]> wrote in
>>>>> message
news:[email protected]...
>>>>>> Using stored procedures is a good
safe guard against SQL injection
>>>>>> because you have to define your
parameter types, in much the same way
>>>>>> that the parameters in the 8.0.2
worked.
>>>>>>
>>>>>> Yes it did break a number of
extensions because the underlying code
>>>>>> was completely rewritten but it is
my understanding that most of
>>>>>> these were subsequently patched to
work with it.
>>>>>>
>>>>>> --
>>>>>> Paul Whitham
>>>>>> Certified Dreamweaver MX2004
Professional
>>>>>> Adobe Community Expert - Dreamweaver
>>>>>>
>>>>>> Valleybiz Internet Design
>>>>>> www.valleybiz.net
>>>>>>
>>>>>> "Pizza Good"
<[email protected]> wrote in message
>>>>>>
news:[email protected]...
>>>>>>>I think what he is referring to
is the sql injection "prevention"
>>>>>>>code that was introduced in the
8.0.2 update. I read a bunch of
>>>>>>>issues related to the way
recordsets were coded and that a page that
>>>>>>>was coded lets say in ASP using
8.0.1 that had used QueryString
>>>>>>>values that were passed into the
recodset for filtering/searching no
>>>>>>>longer worked. I also read that
8.0.2 "broke" a lot of extensions
>>>>>>>because of the fix.
>>>>>>>
>>>>>>> I am still using MX2004, but I'm
curious if the supposed problems
>>>>>>> that came up with 8.0.2 could be
totally avoided if a programmer
>>>>>>> used Stored Procedures?
>>>>>>>
>>>>>>> Hopefully that makes sense.
>>>>>>>
>>>>>>>
>>>>>>> "Paul Whitham
AdobeCommunityExpert" <[email protected]> wrote in
>>>>>>> message
news:[email protected]...
>>>>>>>> Most of the change that was
made to the recordset in 8.0.2 was to
>>>>>>>> eliminate SQL injections.
What specifically are you refering to as
>>>>>>>> an issue now
>>>>>>>>
>>>>>>>> --
>>>>>>>> Paul Whitham
>>>>>>>> Certified Dreamweaver MX2004
Professional
>>>>>>>> Adobe Community Expert -
Dreamweaver
>>>>>>>>
>>>>>>>> Valleybiz Internet Design
>>>>>>>> www.valleybiz.net
>>>>>>>>
>>>>>>>> "Brendon"
<[email protected]> wrote in message
>>>>>>>>
news:[email protected]...
>>>>>>>>> Those that are beta
testing it would know - if they were doing
>>>>>>>>> serverside/sql related.
It wouldn't be speculation at all - in
>>>>>>>>> fact it would be pretty
straight forward to test.
>>>>>>>>> I'd be very surprised if
they havn't fixed the issue - in fact I
>>>>>>>>> thought it was fixed in
the 8.0.2 update, but I could be wrong.
>>>>>>>>>
>>>>>>>>> Brendon
>>>>>>>>>
>>>>>>>>> "Deaf Web Designer"
<[email protected]> wrote in
>>>>>>>>> message
news:[email protected]...
>>>>>>>>>> DW CS3 is not here
as yet.
>>>>>>>>>>
>>>>>>>>>> Only time will tell
once you have DW CS3 installed on your
>>>>>>>>>> platform and find
>>>>>>>>>> out if that is the
case.
>>>>>>>>>>
>>>>>>>>>> At this point, it is
all speculation without knowing the fact of
>>>>>>>>>> the problem.
>>>>>>>>>> Try to be a bit more
patient until official release of product
>>>>>>>>>> sometime this
>>>>>>>>>> spring.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

Similar Messages

Maybe you are looking for