OWASP Top 10 Vulnerabilities in ADF

[Andreas Koop]

Hi *,

while looking for answers on how Oracle ADF/JSF adresses OWASP Vulnerabilities like SQL-Injection, Cross-Site-Scripting, Session- Hijacking, Cross-Site-Request-Forgery etc. I noticed that there is not really much on this or at least it is not easy to find.

What I have found so far is

- Existing EMG Thread https://groups.google.com/forum/?hl=en&fromgroups=#!topic/adf-methodology/Eji41I2lpuI

 => With the outcome "One of the "always getting postponed" papers for [..] to write is a list that explains how to address OWASP Top 10 vulnerabilities in ADF."

=> Hint on ADF Security Slides: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxvcmFjbGVlbWd8Z3g6MTE3YTg4ZjNiZDY4MDhlMg

- Article on "Building Secure ADF Applications" (2008) http://www.dulcian.com/papers/ODTUG/2008/2008_ODTUG_Rydzy1_ADF.htm

- OTN Thread on "Secure Coding Guidelines for ADF": https://forums.oracle.com/forums/thread.jspa?threadID=2205974

Beyond these findings I wonder if there is maybe some more documentation (from Oracle) which specifically documents how ADF helps / implements security features to protect against the OWASP Vulnerabilities. I don't think of the standard ADF Security (Sever) Features but some kind of:

A1: SQL-Injection

=> If using ADF BC SQL-injection is prohibited since ADF BC only uses Prepared-Statements..

A2: Cross-Site Scripting (XSS) 

=> Oracle ADF implements ...this....uses...that... so XSS is not possible ..... if used in .... manner.

...

Does such a blog article or doc exist? Are there any plans (from anybody) to write such guide? What do you think about that topic? I have the dim feeling more and more customers are asking how ADF helps to prevent the OWASP vulnerabilities.

Regards,

Andreas

[Jan Vervecken]

hi Andreas

- about "If using ADF BC SQL-injection is prohibited since ADF BC only uses Prepared-Statements.."
-- Although you most likely intend this to be an "example" of the kind of information you are looking for, I just want to point out the framework API methods like "ViewObject.setWhereClause()" [1] which, depending on how it is used, can still allow SQL-injection.

Possibly the information you are asking about could find a home on the "Oracle ADF Architecture Square" [2], if Oracle makes such available.

- [1] http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10653/oracle/jbo/ViewObject.html#setWhereClause%28java.lang.String%29
- [2] http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adfarchitect-1639592.html

regards
Jan Vervecken

[Steve Muench]

Regarding SQL Injection, I would say that if you use ADFBC in the normal way, then your conclusion is correct. But, I could envision a developer's shooting him/herself in the foot in this regard if they were:

• Programmatically creating a view object at runtime based on using the ApplicationModule.createViewObjectFromQueryStmt() API or createViewObjectFromQueryClauses() API.
• Concatentating into said string(s) some value passed in from a URL parameter that the view/controller layer had passed in as an argument when calling a client-exposed method on an application module containing the programmatic VO creation call above.

Imagine a method like, where somehow a value like "1=1) OR (1=1" got passed the application's view/controller-layer from a URL parameter down into its additionalUserSuppliedPredicateString argument. A developer would really have to go out of his/her way to create a situation like this, but just "using ADFBC" is not a 100% guarantee that such an issue could not possibly be present in the application as a whole.

// Example of incorrectly written custom method that could to subject to the risk of SQL-Injection

public void someMethod(Integer id, String additionalUserSuppliedPredicateString) {

    // NOTE: Not a best practice!!

    String query = "select deptno, dname from dept where id="+id;

    if (additionalUserSuppliedPredicateString != null) {

      query += " AND ("+additionalUserSuppliedPredicateString+")";

    }

    ViewObject vo = createViewObjectFromQueryStmt(null,query);

    // do something with VO here.

}

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andreas Koop]

Thanks for your comments on SQL-Injection. Actually that is what I thought about it. So to complete

A1: Injection 

we could say: If using ADF BC in declarative way SQL-Injection is - nearly (you never know) - impossible. Otherwise it is the responsibility of the developer to take care of preventing SQL-Injection by well known mechanisms: Use Prepared Statements where  ever possible, escape the input if constructing SQL from strings.

If there are experiences with some other OWASP vulnerabilities with ADF it would be great to hear from you. So if anyone has hints for any of the mentioned points please comment or point to relevant doc. As a result we could maybe get kind of community driven guide on "how to prevent nowadays web attacks in ADF Applications".

A2: Cross-Site Scripting (XSS)

A3: Broken Authentication and Session Management

A4: Insecure Direct Object References

A5: Cross-Site Request Forgery (CSRF)

A6: Security Misconfiguration

A7: Insecure Cryptographic Storage

A8: Failure to Restrict URL Access

A9: Insufficient Transport Layer Protection

A10: Unvalidated Redirects and Forwards

Regards, Andreas

[Chris Muir]

"As a result we could maybe get kind of community driven guide on "how
to prevent nowadays web attacks in ADF Applications".

Hear hear, great initiative.

As part of that guide you could steal some of the guidelines elaborated
in the ADF Code Guidelines (http://bit.ly/XQm651) for hardening your
application, partially addressing "A6" of the WASP vulnerabilities.
Obviously the Code Guidelines security rules are not a comprehensive
list, so it would be good to have guidelines to help elaborate what
everyone should do to secure their ADF applications.

I'd like to suggest this is a good opportunity for community members to
learn about the critical security issues that are plaguing web
development, and not to mention security experts are highly paid
consultants (hint hint).

As the EMG lead if I can provide assistance on the side, let me know
Andreas.

Regards,

CM.

[Andreas Koop]

"Hear hear, great initiative"

Do not expect anything, as you know

"The spirit is willing but the flesh is weak." 

;)

Andreas Koop

[steven davelaar]

A bit late, but here is a link to a nice presentation that discusses how to secure JSF apps against OWASP:

http://turbomanage.files.wordpress.com/2009/10/securing-jsf-applications-against-owasp-top-ten-color.pdf

Steven.

--

Steven Davelaar| Consulting Solutions Architect Oracle Webcenter | FMW Architecture Team (A-Team) Tel +31 30 669 8113 | Mobile +31 6 55 33 24 28 Twitter: @stevendavelaar

A-Team ADF/Webcenter Blog | JHeadstart

NEED A-TEAM SUPPORT? File your request here!