This content has been marked as final. Show 6 replies
This is what I was looking for....
-- New line below.... enquote_literal is to prevent SQL Injection
vTemp varchar2(4000) := dbms_assert.enquote_literal(apex_application.g_x01);
I don't understand your last post. Was that a resolution to this thread or an add-on to your original post. Please explain further.
originally you where talking about XSS attacks, but follow up posting was about how to prevent SQL injections.
1) About XSS attacks:
APEX follows the principal that it's much safer to prevent XSS attacks by escaping the output rather than filtering the input, because there are so many ways to bypass these checks. Keep also in mind that the data could be entered by another application, batch job, ... where you have no control. So it's much safer.
APEX automatically takes care of escaping special characters if you pick the appropriate item type or report column type. Look for those which include something like "escape special characters". In APEX 4.0 we have added a new attribute "Escape Special Characters" to page items where the developer can decide what to do. Note: This flag is not available for all item type, only a few allow provide it. For all other item types we will always escape to prevent XSS attacks.
In APEX 4.0 we have also changed a number of wizards to automatically pick "Escape Special Character" display types (like for example in Classic and Interactive Reports) as default to make the application more secure out of the box. In old applications you should check your reports for "Standard Report Column" and change that to "Display Text (escape special characters)" to make your application secure against XSS vulnerabilities.
2) About SQL Injection:
SQL injections can only occur if you do not use bind variables ( :P1_INPUT_VALUE) in your SQL or PL/SQL code and use substitution syntax ( &P1_INPUT_VALUE. ) instead.
Or if you create your own SQL statements on the fly and execute them with EXECUTE IMMEDIATE, DBMS_SQL or have a report based on "Function returning SQL". In those cases you have to be very careful if you concatenate user input to your SQL statement. To make those statements secure also try to use bind variables!
BTW, in APEX 4.0 the Advisor can also give you security advices about your application.
Hope that gives a little bit more information about this topic
My Blog: http://www.inside-oracle-apex.com
APEX 4.0 Plug-Ins: http://apex.oracle.com/plugins
Thank you for your reply and information.
Yes, thank you Patrick!
I've learned a lot more about security over the past few weeks.
We have a hacker working in our Security group so he hacked away at one of my apps.
I also found that in all of my SQL before using any arguments that come from the client, directly or indirectly, I use REGEXP_REPLACE to limit what characters to allow and then limit maximum length to only what is needed.
The hacker used firefox/firebug to change the html to allow as much text as he wanted in an argument and if I didn't limit it in my PL/SQL also it could be used to inject a good chunk of SQL.
He used tools that throw attacks at your app one after the other... it was interesting...
We passed the security audit finally!
Here are some links that were given to me in my exploration of security:
Can also check out this Oracle pdf that include a basic section "Using Regular Expression In Oracle" that introduces the functions that provide Oracle Regular Expressions support and shows some simple usage scenarios.
There are more specific expression below
E.g. Email -- ^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@[a-zA-Z][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z][a-zA-Z\.]*[a-zA-Z]$
But do note the Regex is not used properly may also creates gap inadvertently
As you said that Escape Special Characters attribute get enable if the item type is "Display Only" .
But in my case injection of special character is happening with item type text field, hidden, select list & radio.
So can you please suggest any solution for Escape Special Characters for this types of apex item?
Thanks & Regards,