Jetty configuration wiki page and configuration to help mitigate clickjacking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Jetty configuration wiki page and configuration to help mitigate clickjacking

Scott Koranda-2
Hi,

Would the development team consider edits to this wiki page


so that Jetty would add the headers

Content-Security-Policy: frame-ancestors 'none';
X-Frame-Options: DENY

to all responses?

I have the necessary changes to start.ini and a complimentary JETTY_BASE/etc/jetty-rewrite.xml and have tested them with Jetty 9.3. I suspect the same configuration would work for Jetty 9.2 but I do not immediately have access to a 9.2 based deployment to test.

If the team is amenable I am happy to make the edits directly, or I could send proposed edits along if the team would prefer to make edits directly.

Thanks for your consideration.

Scott K

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Jetty configuration wiki page and configuration to help mitigate clickjacking

Cantor, Scott E.
> If the team is amenable I am happy to make the edits directly, or I could send
> proposed edits along if the team would prefer to make edits directly.

There's native support in 3.4 for some of that using a filter but it's fine with me.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Jetty configuration wiki page and configuration to help mitigate clickjacking

Scott Koranda-2
> > If the team is amenable I am happy to make the edits directly, or I could send
> > proposed edits along if the team would prefer to make edits directly.
>
> There's native support in 3.4 for some of that using a filter but it's fine with me.
>

I have made the edit to the wiki.

Please let me know if you would like me to change anything or revert.

Thanks,

Scott K
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Jetty configuration wiki page and configuration to help mitigate clickjacking

Cantor, Scott E.
> Please let me know if you would like me to change anything or revert.

More to the point, I could use feedback or additional requirements around the feature in 3.4. It looks like I need to generalize or extend the CSP properties to allow that to be set more openly.

I did look at full CSP but as I noted in JIRA, that appeared to be a nightmare of ridiculous proportions based on what I could find on portability of non-inline JS.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Jetty configuration wiki page and configuration to help mitigate clickjacking

Scott Koranda-2
> > Please let me know if you would like me to change anything or
> > revert.
>
> More to the point, I could use feedback or additional requirements
> around the feature in 3.4. It looks like I need to generalize or
> extend the CSP properties to allow that to be set more openly.
>
> I did look at full CSP but as I noted in JIRA, that appeared to be a
> nightmare of ridiculous proportions based on what I could find on
> portability of non-inline JS.

I thik I found the JIRA:

https://issues.shibboleth.net/jira/browse/IDP-627

In that JIRA you write "I did some research on CSP which I summarized
for the committers." Are you able to share that information?

Also is the proposed 3.4 functionality documented? I apologize if it is
but I looked around and I cannot find it.

Thanks,

Scott K
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Jetty configuration wiki page and configuration to help mitigate clickjacking

Cantor, Scott E.
> In that JIRA you write "I did some research on CSP which I summarized for the
> committers." Are you able to share that information?

The summary was that it seemed like CSP in general was about to undergo a big shift and that the original spec was dead, but V2 wasn't going to be adopted, and V3 was the one that was likely to take over. That's from memory, I may have been wrong or may be misremembering. My impression was that the X-Frame-Options thing was superseded but that the replacement wasn't baked, so I wasn't sure what to do there.

The bulk of the CSP stuff seemed to be the move to ban inline JS, which turned portable, trivial one liner JS in the various forms into dozens of lines of non-portable insanity, or would force us to adopt JQuery everywhere, and my judgement was that it would be a huge step backward for the project and a net negative to security.

> Also is the proposed 3.4 functionality documented? I apologize if it is but I
> looked around and I cannot find it.

Possibly not, at the moment I think it's just a couple of additional properties I added. There's a filter added to web.xml and I put this in global-system, which defaults to setting X-Frame-Options and STS headers based on some properties, but allows additional headers from the deployer.

I misread it initially, I was thinking I had included a CSP header, but I was confusing that with STS. So in fact, I ran away screaming from CSP and I think what you wrote up doesn't really conflict with what I did, other than I provided a way to do it cross-container if you prefer.

If it's useful I could just add that CSP header in and define a property for that, I just didn't have much to default it to at the time. If the frame thing is baked, that would be a likely candidate.

-- Scott

    <bean id="shibboleth.DefaultResponseHeaderMap"
            class="org.springframework.beans.factory.config.MapFactoryBean">
        <property name="sourceMap">
            <map>
                <entry key="Strict-Transport-Security" value="max-age=%{idp.hsts.maxAge:0}" />
                <entry key="X-Frame-Options" value="%{idp.frameoptions:}" />
            </map>
        </property>
    </bean>

    <bean id="shibboleth.ResponseHeaderFilter"
        class="net.shibboleth.utilities.java.support.net.DynamicResponseHeaderFilter"
        p:headers="#{getObject('shibboleth.ResponseHeaderMap') ?: getObject('shibboleth.DefaultResponseHeaderMap')}"
        p:callbacks="#{getObject('shibboleth.ResponseHeaderCallbacks')}" />
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Jetty configuration wiki page and configuration to help mitigate clickjacking

Scott Koranda-2
> If it's useful I could just add that CSP header in and define a
> property for that, I just didn't have much to default it to at the
> time. If the frame thing is baked, that would be a likely candidate.
>
>     <bean id="shibboleth.DefaultResponseHeaderMap"
>             class="org.springframework.beans.factory.config.MapFactoryBean">
>         <property name="sourceMap">
>             <map>
>                 <entry key="Strict-Transport-Security" value="max-age=%{idp.hsts.maxAge:0}" />
>                 <entry key="X-Frame-Options" value="%{idp.frameoptions:}" />
>             </map>
>         </property>
>     </bean>

I think it would be useful to include the CSP header and default it to

frame-ancestors 'none';

and also to default X-Frame-Options to

DENY

Anybody wanting more sophisticated (or more permissive) CSP values could
then configure it as they see fit.

I realize there is a lot more that CSP could do, but this would allow
the project to "put a stake in the ground" and then ask the community
for help deciding on how best to evolve the CSP default(s).

Should I re-open that JIRA and add this suggestion?

Thanks,

Scott K
--
To unsubscribe from this list send an email to [hidden email]