Search: For:
Browsing Single Category

"hacking" APEX session model - WWV_CUSTOM-F WWV_FLOW_SESSIONS$

Topic ID: 2987
Created By: 2008-JAN-30 19:39:09 [Vitaliy]
Updated By: 2008-JAN-30 20:13:44 [Vitaliy]
Status: Open
Severity: Normal
Read Only: No
8858
2008-JAN-30 19:39:09
Moderator
 
 
Registered On: Mar 2006
Total Posts: 194
The first thing I did with Oracle Apex was installation obviously, then I 
imported a pre-packaged application to see how the framework was setup and what 
API's did what.  At this point I must say I was impressed.  Actually I would 
say that I was blown away by the simplicity and ease with which I was able to 
import a new application, setup workspaces, manage developers and provision new 
projects.  THUMBS UP Oracle Apex!  What I saw was a solid thought out product 
that didn't disappoint me a bit.
Then I saw the sessions...in the URL ...
And that is where the good news ended for me ...  Lets dig into it now to see 
what I am talking about:

###
### APEX URL
###

The basic (entry) URL is constructed in the following format:

   http://hostname.com:<PORT>/pls/apex/f?p=<APP_ID>:<PAGE_ID>:<SESSION_ID>

for example the following URL:

   http://hostname.com:7777/pls/apex/f?p=107:1:473434890933228

will take you to:

   APP_ID = 107
   PAGE_ID = 1
   SESSION_ID = 473434890933228

You can ZERO out the SESSION_ID and it will be carried from page to page in a 
COOKIE instead.  Zeroing out SESSION_ID only works for Public pages that do not 
require username/password protection.  As soon as you sign-in -- the session is 
put back into the URL -- don't know why but that's what I observed.

ZERO SESSION_IDs are obviously designed to ease the pain of dealing with 
dynamic URLs and their uselessness with bookmarks and the search engines.

The problem is that if I have a user-base consisting of registered and guest 
users and both groups can access the same content on a site where I implement 
MOD_REWRITE rules to increase my SEO I am now in big trouble ...

As soon as a registered user signs-in and his SESSION_ID gets put into the URL 
the MOD_REWRITE rules which depend on the ZERO session id are going to swallow 
his session and he will be back to viewing the site as a guest user loosing all 
of his account privileges.

Lets go further to better understand this issue ...

###
### SESSION_ID + WWV_CUSTOM-F cookie
###

We established that SESSION_IDs are integral part of APEX engine and that they 
inevitably end up in the URL as soon as user is signed in.  Now lets look at 
exactly how the sign-in process works and how APEX identified user session as 
authenticated.

On successful login APEX will create the following session based cookie:

   Name    WWV_CUSTOM-F_989808321597550_107
   Value   6B8177EF0BE4FA99
   Host    hostname.com
   Path    /
   Secure  No
   Expires At End Of Session

Where WWV_CUSTOM-F_989808321597550_107 can be further dissected as follows:

   WWV_CUSTOM-F_    = static prefix
   989808321597550  = security_group_id
   107              = application id

The cookie Value (6B8177EF0BE4FA99) + the SESSION_ID gives Apex everything 
there's needed to verify authentication for a user (browser really).  These two 
values are stored in WWV_FLOW_SESSIONS$ table.  Here's an example of a SQL 
query which can give you all you need to know to simulate(hack) a signed in 
user in Apex:

SQL> r
  1  select session_id_hashed, id, security_group_id, cookie
  2  from flows_030000.WWV_FLOW_SESSIONS$
  3* where cookie = 'DBA_APEX'

   SESSION_ID_HASHED                      ID    SECURITY_GROUP_ID COOKIE
   -------------------- -------------------- -------------------- ----------
1  FF83567809C75500         2718523561177285      989808321597550 DBA_APEX
2  A5AA827491355040          937758636540210      989808321597550 DBA_APEX
3  19B2FFBBAA4A4899         1562692339715762      989808321597550 DBA_APEX
4  6B8177EF0BE4FA99          473434890933228      989808321597550 DBA_APEX
5  B0FA932BD16FF84F         3976405981861287      989808321597550 DBA_APEX
6  A3286515CF1BE924          582584781717106      989808321597550 DBA_APEX
7  4E12C482F155947B         3805819597651902      989808321597550 DBA_APEX

7 rows selected.

If you remember in our example we had:

   security_group_id = 989808321597550
   SESSION_ID        = 473434890933228
   cookie-Value      = 6B8177EF0BE4FA99

Which matches up with row# 4 in the above query output. So all you have to do 
to sign into the application 107 as DBA_APEX is to create the following session 
cookie in your browser:

   Name    WWV_CUSTOM-F_989808321597550_107
   Value   6B8177EF0BE4FA99
   Host    hostname.com
   Path    /
   Secure  No
   Expires At End Of Session

which will successfully get into the following URL:

   http://hostname.com:7777/pls/apex/f?p=107:1:473434890933228
Conclusion
I would prefer to have an option of storing the SESSION_ID in the cookie rather 
than URL even for pages that require authentication for two reasons:

    1) this would greatly aid in building SEO sites where 
       the same content can be accessed by public and 
       private users.
   
    2) it would make Apex a little more secure because 
       a hacker would have to parse the SESSION_ID from 
       the cookie where now it's clearly seen in the URL.
[edited by: Vitaliy at 20:13 (CST) on Jan. 30, 2008]