"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
|
||||
|
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]