1

At the moment I'm dealing with implementing everything is to be safe against the security risks of the Top 10 Project
For #4 of the Top 10 - Insecure Direct Object References the OWASP refers to the OWASP Application Security Verification Standard

So I was reading all the suff in V3, but I have now some questions implementing it.
I'm using JBoss-AS 7.0.1 with Java EE6 and JSF 2.0

V3.4 Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.

I read some articles here on stackoverflow how to avoid that the jesssion is in the URL for the first time a user is visiting the side... But many answers are like: use the URL rewriting ... what does this means in contrast to the does not support URL rewriting of session cookies

What is the normal way to deal with jsessions on the first entry? What is a save way to handle it?

V3.10: Verify that only session ids generated by the application framework are recognized as valid by the application.

How you do this in JSF2.0 / JavaEE?

V3.12: Verify that cookies which contain authenticated session tokens/ids have their domain and path set to an appropriately restrictive value for that site.

What does this mean? When i look with my Firebug into the the cookie, I run the webapp from the URL http://localhost:8080/projectname/
and in the cookie i get: Path: /projectname
is this what the OWASP means with have their domain and path set to an appropriately restrictive value for that site. ?

Thank you!

Joergi
  • 1,527
  • 3
  • 39
  • 82

1 Answers1

2

V3.4 Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.

The servlet container is by default configured to support session tracking by cookies and URLs. The session tracking by URL is also known as "URL rewriting" wherein you see the ;jsessionid=[session id] to appear in URLs. This will be triggered automatically when the client has cookies disabled. To disable tracking by URL, you need to explicitly specify a tracking mode by cookie only. Add this to the webapp's web.xml:

<session-config>
    <tracking-mode>COOKIE</tracking-mode>
</session-config>

Further you need to make sure that the JSF code is nowhere printing the session ID to the HTML output by among others <h:outputText value="#{session.id}" />.

V3.10: Verify that only session ids generated by the application framework are recognized as valid by the application.

The servlet container will by default already do that. Only Tomcat 6.x (and inherently thus also JBoss 5.x) had the security issue that when the server-wide session sharing is been enabled, then the server will use exactly the session ID as supplied by the client in the Cookie request header. Tomcat 7.x (and inherently thus also JBoss 6.x/7.x) will not do that anymore. See also among others the Tomcat 6.x <Connector> documentation for some more background information (check the emptySessionPath attribute description).

V3.12: Verify that cookies which contain authenticated session tokens/ids have their domain and path set to an appropriately restrictive value for that site.

The servlet container will by default already do that. Only when you configure the servlet container to use server-wide session sharing (thus, the same session is been shared between all deployed applications), then it violates the rule. See also the previous point.

Please note that most of those rules have very little to do with JSF. They have more to do with general server and webapp configuration. JSF is merely a component based MVC framework.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • **thx again for your great answers... ** V3.4: if the user has the cookies disabled in the browser, is there then a fallback-mode back to the URL jSession? Or is it then for these users just not working? (would be stupid, so i think the answer has to be yes, fallback to URL jSession, am i right?) V3.12: no, there is only application on my server - so this shouldn't be a problem and i know, that most of the rules are not really JSF relevant, but i have to understand how JSF is dealing with this stuff anyway ;) THANK YOU! – Joergi Mar 08 '12 at 12:21
  • 1
    1) No, there will be no fallback anymore. Show a warning message that the user needs to enable cookies. 2) It actually doesn't matter how many applications you have on the server. It matters whether the server and webapps are individually been configured to share the session. This is by default *not* the case. – BalusC Mar 08 '12 at 12:24
  • i was now implementing this into my web.xml: `10trueCOOKIE` The problem is, that now the jsession is in EVERY URL but not on the index.xhtml - but i thought i have now no jsession in the url at all? cookies are activated... (and i looked into thw war on the server, the web.xml was like the one i posted... – Joergi Mar 14 '12 at 09:59
  • and: i get now `javax.faces.application.ViewExpiredException` - but the Controller ist `@SessionScoped` - and it was working before i changed the web.xml – Joergi Mar 14 '12 at 10:10
  • This is odd. I don't have JBoss 7 at hands right now, but it works for me on Tomcat 7.0.23 and Glassfish 3.1.1. As to the view expired exception, this should only happen when the client has cookies disabled. – BalusC Mar 14 '12 at 11:19
  • ok, i will start a new question... here it makes no sense, thx anyway. – Joergi Mar 14 '12 at 11:50
  • i have started a [question](http://stackoverflow.com/questions/9702789/jboss-7-0-1-running-with-no-jessions-in-the-url), but no one can help... hopefully you see the problem? – Joergi Mar 20 '12 at 17:02
  • Didn't see that question before. It's not in any of my favourite tags. As to the problem, well, I bet it to be just JBoss 7 specific. As said, it works for me on Tomcat 7 and Glassfish 3. – BalusC Mar 20 '12 at 17:09