You can see on the Community Forum that there is no session id in the URL. But that is actually an ugly hack:

    if (!inPWA()) {
       let orgUrl = new URL(window.location);
       window.addEventListener('DOMContentLoaded', (event) => {
           window.history.replaceState({}, '', `https://forums.oracle.com/ords/apexds/post/session-in-url-causes-problems-in-saved-bookmarks-6474${orgUrl.hash}`);
       });

You still see the original URL briefly when the page loads.

Hi Philipp,

Did you have a look at Rejoin Sessions?

https://docs.oracle.com/en/database/oracle/apex/24.2/htmdb/manging-instance-security.html#GUID-C676EF2F-2939-4EC3-9385-8FAEA99C8971

@menno.hoogendijk 

Hi Menno,
Yes, this solves part of the issue. But my main point is that having the session ID in the URL is more harmful than helpful. And I think rejoin session will put the session ID back after rejoining, right?

You could use Rejoin Sessions only on public pages for public facing apps. I believe it will not put the session ID back as long as you stay on public pages. 

Having the session ID in the URL is actually not harmful and improves app security as explained in the doc:

While supporting session joins is convenient, it does present some serious security risks:

Triggering malicious session state changes or other modifications.

If an attacker tricks the user into clicking an application link, this can trigger malicious session state changes or other modifications. Because of this risk, APEX requires a checksum that the attacker will not be able to guess when processing requests that alters data.

Triggering unintended changes between applications.

If a user has two applications open in separate tabs on the same APEX instance, one application could trigger unintended changes in the other one. The attacking application could be written by a hacker or it could have an XSS vulnerability that enables an attacker to inject code. This application could use Ajax calls that simulate user interactions with the other application.

Thanks @menno.hoogendijk for you explanation!

@menno.hoogendijk 

Thanks for your response! I just tested the “Rejoin Sessions - Enabled for All Sessions” option. I also set “Page Access Protection” and on the item level to unrestricted.

• It actually does not set the session ID in the URL when no page item is passed via the URL (great! )
• If you want to set a page item via the URL, it requires the session ID. If I remove the session parameter and reload it will redirect me to the log-in page so actually not rejoin.

Looks like a bug or am I misunderstanding how it should work? 

APEX requires a checksum that the attacker will not be able to guess

Completely agree. But you can pass the checksum without having to pass the session ID. The session secret is still in the cookie.

For the second paragraph I don't understand what this has to do with having a SID in the URL.

And I want to again point out that APEX is different from all other web applications I know. Banking websites, social media, etc., of course, also use sessions, but only store the information in the cookie and not additionally in the URL.

Not sure why setting an item requires the session ID. This works fine for me:
https://apex.oracle.com/pls/apex/r/citiest/public-app/home?P1_NEW=test

Another workaround is to use the x01 and grab that value to populate your page item:
https://apex.oracle.com/pls/apex/r/citiest/public-app/home?x01=lalalala

I think the second paragraph is about invoking an Application Process by name for example. The second app is capable of generating valid URLs for the first app because there is no SID.

I'll forward your questions to the team to check if they can provide more detailed answers.

The reason for having a session ID in the URL is because APEX can be run in a hosted environment. Consider apex.oracle.com. You and I both have workspaces on a.o.c. If you are currently running your application on a.o.c, and then you run my application on a.o.c, it is likely that your application session cookie(s) will get sent on your request to my application. If I can access your session cookies and your application does NOT require a session ID in the URL, I can use your session cookie information to hijack your application session.

If you have complete control over the application server and all associated applications, you don't need a session ID in the URL. If there is a chance someone (like me) could access this information (e.g. in a hosted environment), you need the session ID in the URL.

Awesome @anton nielsen that makes totally sense for me 😌

Thanks for the detailed explanation @anton nielsen . That makes perfect sense and is something I hadn't fully considered.

I still think it should be possible to get rid the SID in the URL (for people who want it, not everybody):

1: You can scope cookies to a specific path. And with the new URL syntax you have the workspace name in the URL. So APEX could create a cookie for a.o.com/…/**philipp** which will be sent to a.o.com/…/**philipp**/app/page but not a.o.com/…/**anton**/app/page.

2: There could be an environment setting in internal to enable/disable having the session in the URL like with persistant auth. And it should be disabled by default.

Taking advantage of the fact that you are talking about session and urls. When you copy your current url, close the browser ( without closing the session) then open a new browser, paste the url , the session is comming back …that behaviour is normal? can we prevent it? thanks

@philipp hartenfeller , I definitely want to be able to remove the SID from the URL…I want this feature for sure. But I still think in a shared/hosted environment you will continue to want to have it in the URL. Even with friendly URLs the APEX engine calls URLs that do not include the friendly URL path. Any time you submit a page it constructs a request to a URL like this:

https://apex.oracle.com/pls/apex/wwv_flow.accept?p_context=random-tests/emp-form/3864459571157

Could they rewrite APEX to construct a URL with the full friendly URL path? Probably…but I suspect it's a big lift and may have other security implications. I think in an environment where you do not have full control of the server associated with the host name, the URL should contain the SID.

But…most of us work in environments where we do have that control. In that case, I absolutely agree…ditch the SID from the URL.

@marcelo osorio kosky That will not (should not!) happen if you completely exit your browser and do not re-open previous sessions when you re-launch your browser. Browsers have become “smart” enough to retain session cookies and bring session back to life on a restart (if you indicate you want them to).

@anton nielsen 

Is Session ID required in the URL before the user authenticates?

@appex 

Depending on your application settings, APEX may or may not not require the SID in the url prior to authentication. If you want to be certain that someone else using the same server doesn’t hijack your APEX session, though, you should make sure it is in the URL. I know of many applications that don’t technically authenticate (as far as APEX “knows”) but the logically know who the user is and have session state about the user and session. 
 

For me, the deciding factor relating to having the SID in the url is really “am I certain nobody can run something on the same url and capture my cookies?” If I’m certain, then I don’t need or want it in the url.

@anton nielsen 

Even if someone is going to hijack APEX session, what are they going to do with it? What secure info does the session ID/cookie have inside it before authentication?

If public pages (available to guest users) are rendered without the session ID in the URL and the session ID is created and appended to the URL after authentication, that would strike a good balance and render public pages clean without session ID in their URLs - as expected behavior. Pages that are not public will require authentication anyway and session ID in the URL of private pages should not matter much as they cannot be bookmarked as-is, cannot be accessed by guest users or indexed by search engines.

I worked on some PHP projects in the past and they did not require a session ID in the URL prior to authentication.

@appex When I hijack a session I can fully enter into that session.  Many fully public applications allow users to do all kinds of things. You can purchase items from websites without authenticating. You can look up flight information without authenticating with the airline. If you are doing any of these kinds of things and I hijack your session I can ride along with you. Just before you submit your order I can change the shipping address. If you’ve entered your last name and flight confirmation number I can view (and possibly manage) your flight. 

And I can do all of this in a PHP application as well. It’s not an APEX issue, it’s the nature of using a shared url. If you and I can both run an application at

https://somemachine.com

My app can get information from your users’ browsers which I can then use to hijack their sessions…in PHP, Java, JavaScript, ruby, nodejs, etc.

@anton nielsen 

I was wondering what a hijacker could do with the guest user's unauthenticated session. Isn't a new session generated during login discarding the old guest session, if any? I'm fine with having session ID in the URL (even on public pages) after the user authenticates. While a guest user can access only public pages, i'm wondering about the session ID in the url of public pages for guest users.

How does Google index say, an APEX app's public home page (for guests) with a different session ID in the URL say, each day? Does it result in a different url indexed each day? Public pages in APEX don't really seem to be public if they have a session ID in their url (even for guests). Public pages could function like static+cached HTML pages with some bits of dynamic content injected into them using placeholders like links to Sign In (for guests), Sign Out (for users)…