Shibboleth IDP appspider scan results and questions

Cantor, Scott cantor.2 at osu.edu
Wed Jul 3 14:26:14 EDT 2019


On 7/3/19, 1:22 PM, "users on behalf of Crawford, Jeffrey" <users-bounces at shibboleth.net on behalf of jcrawford at it.ucla.edu> wrote:

> 1. Session fixation – Server accepts fixed Session ID in cookie == I believe this is a component of SSO and that the
> idp.session.consistentAddress = true offers the mitigation. 

It's not that simple, there are multiple sesssions, some ours, some up to the container. We use address binding. Nobody else does, and Tomcat and Jetty definitely don't. Our session only has SSO relevancy, it has no impact on conversation and per-request state.

As for CSRF and the like, that's a complex topic, and the main mitigation for some of them is blocking use of JSESSIONID on the URL using web.xml, which has been a default shipped for a while. But web.xml is the deployer's responsibility since we can't ever update it after install. There are many useful things it can do.

Phil has been studying CSRF vectors for a while, I don't know what more we're going to do, if anything, about it. I tend to think implementing some kind of address binding filter for the container session would be the best thing we could do.
 
> 3. Document Encoding – Explicitly set document encoding to UTF-8 == I hadn’t heard of this one, any input on this?

There are multiple layers of encoding. The parts we pay close attention to are the XML, the rest is up to web servers and how people choose to configure things but all the defaults we have control over are, AFAIK, set to UTF-8.

>4. Disable TRACE == Any problem with doing this?

I added a security-constraint including TRACE a while ago also.

> 5. Add HttpOnly in the response header == If Javascript requires access to  the cookie, then this will break things, not
> sure if it does.

That's the default and controllable with properties.

-- Scott




More information about the users mailing list