During early development phases of ADF applications, developers tend to use built-in ADF Security role - TEST-ALL. While we can argue if its good or bad practice (myself I would think its bad practice), I will show you today one security related risky scenario, if you forget to do proper housekeeping for ADF applications.
Download sample application - TestAllSecurityAccess.zip. This scenario can be reproduced when enabling ADF Security with Grant to Existing Objects Only/All Objects option:
Once you will enable ADF Security with Grant to Existing Objects Only/All Objects, ADF assigns TEST-ALL role to every resource in the application:
When ADF application is completed and moving into testing or production phase - we are removing TEST-ALL role and providing proper roles. In my example, I will use Authenticated role - enable this role for Task Flow:
Also for the Web Page:
All works fine, only there is one hidden potential security hole for hackers. Let's say we will try to open home page, if username/password combination is not correct - authentication error will happen, thats correct:
What we can do now, is to type direct URL pointing to the page from bounded ADF task flow. For example: ApplicationContextRoot/faces/main.jspx, and this page will be loaded for Anonymous user - even only Authenticated users are allowed to view it:
Why this happens? Its because TEST-ALL role is granted to every resource available inside ADF application. In our case, it was granted automatically to the Page Definition of main.jspx page from bounded ADF task flow - we didn't noticed that when setting proper security roles. Even if bounded ADF task flow is granted with proper role, and if there is Page Definition with TEST-ALL role inside that task flow, page associated with that Page Definition still will be accessible:
You can reproduce same scenario with sample application for this post, I specifically didn't removed assigned TEST-ALL role for Page Definition of main.jspx.
Let's remove TEST-ALL from Page Definition of main.jspx:
Now all works correctly, authentication is enforced and direct access is prohibited:
Its recommended to remove TEST-ALL completely from ADF applications, when moving away from early development stages:
Download sample application - TestAllSecurityAccess.zip. This scenario can be reproduced when enabling ADF Security with Grant to Existing Objects Only/All Objects option:
Once you will enable ADF Security with Grant to Existing Objects Only/All Objects, ADF assigns TEST-ALL role to every resource in the application:
When ADF application is completed and moving into testing or production phase - we are removing TEST-ALL role and providing proper roles. In my example, I will use Authenticated role - enable this role for Task Flow:
Also for the Web Page:
All works fine, only there is one hidden potential security hole for hackers. Let's say we will try to open home page, if username/password combination is not correct - authentication error will happen, thats correct:
What we can do now, is to type direct URL pointing to the page from bounded ADF task flow. For example: ApplicationContextRoot/faces/main.jspx, and this page will be loaded for Anonymous user - even only Authenticated users are allowed to view it:
Why this happens? Its because TEST-ALL role is granted to every resource available inside ADF application. In our case, it was granted automatically to the Page Definition of main.jspx page from bounded ADF task flow - we didn't noticed that when setting proper security roles. Even if bounded ADF task flow is granted with proper role, and if there is Page Definition with TEST-ALL role inside that task flow, page associated with that Page Definition still will be accessible:
You can reproduce same scenario with sample application for this post, I specifically didn't removed assigned TEST-ALL role for Page Definition of main.jspx.
Let's remove TEST-ALL from Page Definition of main.jspx:
Now all works correctly, authentication is enforced and direct access is prohibited:
Its recommended to remove TEST-ALL completely from ADF applications, when moving away from early development stages:
No comments:
Post a Comment