0

I am using weblogic 10.3.6 with ATG 10.1.2

I want to make my JSESSIONID secure, I tried setting the weblogic.xml as follows, 

<session-descriptor>
    <cookie-name>JSESSIONID</cookie-name>
    <timeout-secs>1200</timeout-secs>
    <cookie-secure>true</cookie-secure>
    <url-rewriting-enabled>false</url-rewriting-enabled>
</session-descriptor>

I tried turning the auth-coookie-enabled to false, to see if it then honors the cookie-secure from weblogic.xml, but it doesn't.

<web-app-container>
    <x-powered-by-header-level>SHORT</x-powered-by-header-level>
    <auth-cookie-enabled>false</auth-cookie-enabled>
  </web-app-container>

spakred guys have posted a similar post earlier (httpOnly vulnerability fix), where they have highlighted the runAssembler command issue, the solution provided there also doesn't work with weblogic, (have left a comment there). Weblogic doesn't even check the context.xml (I tried putting an invalid XML, no errors on start up)

I have also noticed that if I change the cookie-name in weblogic.xml to another name, a JSESSIONID is still generated, and the new cookie becomes secure.

- Is there something else generating this cookie?
- Why isn't weblogic able to secure the JSESSIONID or even change its path (changing cookie-path results in two JESSIONID cookies being sent)?

Has anyone tried this earlier, Please share your thoughts.

boyintello
  • 326
  • 3
  • 14

2 Answers2

0

This might not answer all your questions but at least give you some more background on how ATG and Weblogic work together.

Suggest you take a look at /atg/dynamo/servlet/sessiontracking/GenericSessionManager component. The property singleSessionIdPerUser defaults to a different value depending on which application server you are running on WebLogic vs Websphere vs jBoss. Weblogic has this property set to false whereas jBoss and WebLogic have it set to true which is why I believe the vulnerability does not exist in Weblogic as there is a server-side lookup for ATG specific session id's based on the WebLogic session id (assuming you have secured the web logic jsessionid).

From the ATG help:

When the singleSessionIdPerUser value is true, the application server uses the same session ID for all web applications, so lookup is not required. Note that the application server hands out the same session id, but not the same HttpSession object.

When singleSessionIdPerUser is false, a lookup determines the session name context ID. This is done by the atg.nucleus.servlet.SessionNameContextServlet servlet (included in atg_bootstrap.war), using a RequestDispatcher.include() call. The SessionNameContextServlet does two things:

Sets the parent session ID as a request attribute that can then be used by the child web application to bind to the correct session context.

For application servers that do not allow request attributes to be shared between web applications, it also sets a cookie named ATG_SESSION_ID with the session ID. This behavior is controlled by the /atg/dynamo/servlet/sessiontracking/GenericSessionManager.useSessionTrackingCookie property, which is pre-configured with the correct value for each application server.

More information can be found here.

Also, see my answer to a question on SO about logging a user out programmatically on web logic/atg which I believe is related to the above mentioned singleSessionIdPerUser=false on weblogic

Community
  • 1
  • 1
bated
  • 960
  • 2
  • 15
  • 29
  • 1
    Thanks @bated for your insights. context.xml is not honored by weblogic at all, if you read my question "Weblogic doesn't even check the context.xml, putting an invalid xml doesn't throw any errors, it works on JBOSS though". I put a lot of effort in researching, and finally someone's comment on Oracle community gave me the direction, the weblogic.xml in my own war was not able to over ride the settings, coz I discovered the first war to load will make its settings stick, copying the same weblogic.xml to every war did the trick. – boyintello Sep 16 '14 at 02:54
  • Ok, will update answer. Will leave the rest as I believ it might be useful to others. – bated Sep 16 '14 at 14:20
0

If you look at the cookie that is being issued by ATG you will likely see that it is being issued to the root context path (e.g. Path=/;) rather then the context of the web-app that you have customized the web.xml for.

Your weblogic.xml settings are likely not being considered due to the way sessions are managed in ATG.

By default, sessions are generally shared across web-app's in ATG. This is a bit different than standard J2EE behavior where sessions are web-app specific, but it allows ATG to support some of the multi-site functionality that customers desire.

So whats going on here?

ATG has the concept of a 'parent' session context which will be created whenever you initiate a session on a web-app. So while you may hit different web-apps that have different context roots, ATG internally will only create a a single 'parent' session. This parent session is generally bound to the atg_bootstrap.war web-app by default.

Some options:

  1. After you build your EAR, try dropping a weblogic.xml file into the atg_bootstrap.war/WEB-INF folder with the 'cookie-secure' setting equal to true. Since this is the web-app that is ultimately creating the 'parent' session, the weblogic.xml settings should take affect here.
  2. Alternatively you can likely override the default ATG session sharing behavior and have it issue a session for a single web-app. For example, if you have a web-app with context '/store', you could have it bind sessions to this web-app context and not the parent ('/') context. To do this, try setting the 'cookie-path' element in the weblogic.xml to the context path of your web-app. For example, if your web-app context root is '/store':
<session-descriptor>
  <cookie-path>/store</cookie-path>
  <cookie-secure>true</cookie-secure>
</session-descriptor>

Note that this second option may break multi-site behavior if you intend to share sessions across different web-apps.

There is a good article within the Oracle KB (support.oracle.com) that describes the session management behavior in ATG:

  • Doc ID 1364857.1: How ATG Session Management Works on WebLogic, JBoss, and WebSphere
zmcmahon
  • 401
  • 4
  • 9