Cookie spoof

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

Cookie spoof

Stopinski, Thomas Thaddäus
Hey Folks,

first I want to describe our setup before I come to our problems. I will ask questions along the way, where Its seems suitable.

We have an Apache webserver and a SP running on a VM on Ubuntu 18.04 At the beginning we want to protect a asp .net core Webapp, that runs on Azure Cloud service. Everything is up-to-date.

1. Is this kind off setup recommendable or even possible?

We have configured the SP as a reverse proxy.

2. Is that even necessary?

We can successfully login at a test IP that our organization supplies for testing.

3. How can we make sure that the whole communication is actually SAML2 protected?

Now coming to our problem, we are not able to perform a route back to our Webapp.
We keep getting the following exception:
        "opensaml::SecurityPolicyException at (https://shibboletho urserver.com/)
        Attempt to spoof header (Shib-Cookie-Name) was detected.

We already tried almost every configuration that we could find, but they lead us nowhere.

Our Virtual Hosts configuration looks like this:

<VirtualHost *:80>
        UseCanonicalName On
        ServerName shibboleth-ourserver.com
        # https://serverfault.com/questions/743411/only-one-shibboleth-sp-on-reverse-proxy-for-different-sites :
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        ErrorLog ${APACHE_LOG_DIR}/error.log
RewriteEngine on
RewriteCond %{SERVER_NAME} =shibboleth-ourserver.com
RewriteRule ^ <a href="https://%">https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

<VirtualHost *:443>
        UseCanonicalName On
        ServerName shibboleth-ourserver.com
        ServerAdmin webmaster@localhost

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLEngine on
        SSLCACertificateFile /etc/shibboleth/sso-test.pem

<Location / >
        Order deny,allow
        Allow from all
        AuthType shibboleth
ShibRequestSetting requireSession 1
        ShibUseHeaders On
        Require shibboleth
</Location>

    SSLProxyEngine on
    ProxyRequests off
    ProxyPass / https://shibboleth-ourserver.com
    ProxyPassReverse / https://shibboleth-ourserver.com
    ProxyPreserveHost On


        SSLCertificateFile /etc/letsencrypt/live/shibboleth-ourserver.com/fullchain.pem
  SSLCertificateKeyFile    /etc/letsencrypt/live/shibboleth-ourserver.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Our shibboleth2.xml looks like follows:

<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config"
    xmlns:conf="urn:mace:shibboleth:3.0:native:sp:config"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
    clockSkew="180">
    <OutOfProcess tranLogFormat="%u|%s|%IDP|%i|%ac|%t|%attr|%n|%b|%E|%S|%SS|%L|%UA|%a" />

    <!--
    By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
    are used. See example-shibboleth2.xml for samples of explicitly configuring them.
    -->

<RequestMapper type="Native">
        <RequestMap applicationId="default">
<!--
            The example requires a session for documents in /secure on the containing host with http and
            https on the default ports. Note that the name and port in the <Host> elements MUST match
            Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element above.
            -->
            <Host name="https://ourwebapp.net">
                <Path name="SShTestApp" authType="shibboleth" requireSession="true" applicationId="SShTestApp"/>
            </Host>
           <!-- Example of a second vhost mapped to a different applicationId. -->
            <!--
            <Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true"/>
            -->
     </RequestMap>
    </RequestMapper>

    <!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
    <!--    <ApplicationDefaults id="default" policyId="default" entityID="https://onlineportalmedizinischefakultaet.azurewebsites.net/" -->
<ApplicationDefaults id="default" policyId="default" entityID="https://shibboleth-ourserver.com/shibboleth"
        homeURL="https://shibboleth-ourserver.com"
        REMOTE_USER="eppn subject-id pairwise-id persistent-id"
        cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">

        <!--
        Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
        Each Application has an effectively unique handlerURL, which defaults to "/Shibboleth.sso"
        and should be a relative path, with the SP computing the full value based on the virtual
        host. Using handlerSSL="true" will force the protocol to be https. You should also set
        cookieProps to "https" for SSL-only sites. Note that while we default checkAddress to
        "false", this makes an assertion stolen in transit easier for attackers to misuse.
        -->
        <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
                  checkAddress="true" handlerSSL="true" cookieProps="https">

            <!--
            Configures SSO for a default IdP. To properly allow for >1 IdP, remove
            entityID property and adjust discoveryURL to point to discovery service.
            You can also override entityID on /Login query string, or in RequestMap/htaccess.
            -->

              <SSO entityID="https://login-test.rz.rwth-aachen.de/shibboleth">
              SAML2
              </SSO>
             <!-- SAML and local-only logout. -->
            <Logout>SAML2 Local</Logout>

            <!-- Administrative logout. -->
            <LogoutInitiator type="Admin" Location="/Logout/Admin" acl="127.0.0.1 ::1" />

            <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
            <Handler type="MetadataGenerator" Location="/Metadata" signing="true"/>

            <!-- Status reporting service. -->
            <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>

            <!-- Session diagnostic service. -->
            <Handler type="Session" Location="/Session" showAttributeValues="true"/>

            <!-- JSON feed of discovery information. -->
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
        </Sessions>

        <!--
        Allows overriding of error template information/filenames. You can
        also add your own attributes with values that can be plugged into the
        templates, e.g., helpLocation below.
        -->
        <Errors supportContact="root@localhost"
            helpLocation="/about.html"
            styleSheet="/shibboleth-sp/main.css"/>

        <!-- Example of locally maintained metadata. -->
        <!--
        <MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>
        -->

        <!-- Example of remotely supplied batch of signed metadata. -->
        <!--
        <MetadataProvider type="XML" validate="true"
                    url="http://federation.org/federation-metadata.xml"
              backingFilePath="federation-metadata.xml" maxRefreshDelay="7200">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
            <MetadataFilter type="Signature" certificate="fedsigner.pem" verifyBackup="false"/>
            <DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
              attributeName="http://macedir.org/entity-category"
              attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
              attributeValue="http://refeds.org/category/hide-from-discovery" />
        </MetadataProvider>
        -->

        <!-- Example of remotely supplied "on-demand" signed metadata. -->
        <!--
        <MetadataProvider type="MDQ" validate="true" cacheDirectory="mdq"
                    baseUrl="http://mdq.federation.org" ignoreTransport="true">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
            <MetadataFilter type="Signature" certificate="mdqsigner.pem" />
        </MetadataProvider>
        -->

<!-- RWTH Aachen Metadaten -->
        <MetadataProvider type="XML" url="https://sso-test.rwth-aachen.de/metadata/rwth.metadata.xml" backingFilePath="/etc/shibboleth/rwth.metadata.xml" reloadInterval="7200">
           <MetadataFilter type="Signature" certificate="/etc/shibboleth/sso-test.pem"/>
        </MetadataProvider>

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
        <!-- Default filtering policy for recognized attributes, lets other data pass. -->
        <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

        <!-- Simple file-based resolvers for separate signing/encryption keys. -->
        <CredentialResolver type="File" key="/etc/shibboleth/sp-key.pem" certificate="/etc/shibboleth/sp-cert.pem"/>

<ApplicationOverride id="SShTestApp" entityID="https://ourwebapp.net/LogIn">
    <Sessions lifetime="28800" timeout="3600"
        handlerURL="/LogIn/EditUser" handlerSSL="true"
        cookieProps="https">
        <SessionInitiator type="Chaining" Location="/Login" isDefault="true"
                        relayState="cookie" entityID="https://login.rz.rwth-aachen.de/shibboleth">
                        <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                        <SessionInitiator type="Shib1" acsIndex="5" />
         </SessionInitiator>
    </Sessions>
</ApplicationOverride>
    </ApplicationDefaults>

    <!-- Policies that determine how to process and authenticate runtime messages. -->
    <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>

    <!-- Low-level configuration about protocols and bindings available for use. -->
    <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
</SPConfig>

As one can see we followed the rule:more is always better.
We  are not  even sure if we need the ApplicationOverride and the RequestMaper.

I know it's a lot, but we're have the feeling, we're stuck in a deadend.

So any kind of constructive suggestions are highly appreciated.

Thanks for your help in advance.

Greetings,

Thomas Stopinski


Medizinische Fakultät
Studiendekanat
RWTH Aachen University
Forckenbeckstraße 71
52057 Aachen
Tel.: Dipl.-Ing. (FH) Thomas Stopinski
 
 
 
Dekanat ...
 
 
 
Dienstort
 
Gebäude CT², Etage 6,    Raum 05
Forckenbeckstraße 71
52074 Aachen
Telefon: +49 241 80 89498
Email: [hidden email]
Büro: CT² Center for Teaching and Training, Etage 6, Raum 6.06
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cookie spoof

Cantor, Scott E.
If you're using headers with the SP, turn that off and any problem of this particular sort will go away. It also seems like you're possibly running an SP in two places/layers, which is also by definition not something you should do. I can't really imagine how you'd get such an error without an SP in front of another SP for the most part.

Any advice beyond that or looking at config files in that depth would be a member support thing for me.

> We  are not  even sure if we need the ApplicationOverride and the RequestMaper.

Nobody needs overrides for the most part anymore unless they're doing path-based rules for separating content.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cookie spoof

Peter Schober
In reply to this post by Stopinski, Thomas Thaddäus
* Stopinski, Thomas Thaddäus <[hidden email]> [2019-11-07 16:33]:
> We have an Apache webserver and a SP running on a VM on Ubuntu 18.04
> At the beginning we want to protect a asp .net core Webapp, that
> runs on Azure Cloud service. Everything is up-to-date.

It would be easier if you explained why you require the rewrite rule
and especially why you're proxying requests to yourself?
(You have a ProxyPass to https://shibboleth-ourserver.com within the
TLS-vhost for shibboleth-ourserver.com)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cookie spoof

Cantor, Scott E.
On 11/7/19, 10:55 AM, "users on behalf of Peter Schober" <[hidden email] on behalf of [hidden email]> wrote:

> It would be easier if you explained why you require the rewrite rule
> and especially why you're proxying requests to yourself?

That would of course guarantee the error. Again, turn off headers and that goes away, assuming it even makes sense to have such a proxy rule (I can't imagine why).

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

AW: Cookie spoof

Stopinski, Thomas Thaddäus
In reply to this post by Peter Schober
Dear Peter,

In our believe we need the rewrite rule because, we want all traffic to go over a secure SSL connection.

As I was trying to describe in my initial mail, we have the SP and the Webapp running on two different machines. Even more, we run them in different domains.
So we must switch from one SSL connection to another. Correct me if I am wrong on that.
What we keeping asking ourselves is, how is the SP supposed to know where to send me after a successful login?

        We did as suggested by Scott, we took the         ShibUseHeaders On and the ApplicationOverride out from our configuration, but that broad us only into a loop.

Greetings
 and thanks again. 

Thomas stopinski
-----Ursprüngliche Nachricht-----
Von: users <[hidden email]> Im Auftrag von Peter Schober
Gesendet: Donnerstag, 7. November 2019 16:55
An: [hidden email]
Betreff: Re: Cookie spoof

* Stopinski, Thomas Thaddäus <[hidden email]> [2019-11-07 16:33]:
> We have an Apache webserver and a SP running on a VM on Ubuntu 18.04
> At the beginning we want to protect a asp .net core Webapp, that runs
> on Azure Cloud service. Everything is up-to-date.

It would be easier if you explained why you require the rewrite rule and especially why you're proxying requests to yourself?
(You have a ProxyPass to https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-ourserver.com&amp;data=02%7C01%7C%7C880bf24a0efe4dd6f44808d7639af53f%7C5a6d5ee56edf4a26ba93f5872dbb9614%7C0%7C1%7C637087389496337159&amp;sdata=nuhy577jRnf%2BwwHxeyBOV%2FZVhJuUkOMOY6On%2B9QgaMQ%3D&amp;reserved=0 within the TLS-vhost for shibboleth-ourserver.com)

-peter
--
For Consortium Member technical support, see https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&amp;data=02%7C01%7C%7C880bf24a0efe4dd6f44808d7639af53f%7C5a6d5ee56edf4a26ba93f5872dbb9614%7C0%7C1%7C637087389496337159&amp;sdata=P6SGOnWOpX2PyEidXYZAsWzAbaVxq5Bwc1VtU8NR61M%3D&amp;reserved=0
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cookie spoof

Cantor, Scott E.
On 11/11/19, 5:40 PM, "users on behalf of Stopinski, Thomas Thaddäus" <[hidden email] on behalf of [hidden email]> wrote:


> What we keeping asking ourselves is, how is the SP supposed to know where to send me after a successful login?

The SP knows nothing about that second domain and must have no references to it, and no clients must ever talk to it. Reverse proxies *are* the app, full stop. That's the only URL that can be visible or used anyhere. All rules must be in terms of the external URL, all metadata, everything. Until you fix that, none of this will work.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cookie spoof

Peter Schober
In reply to this post by Stopinski, Thomas Thaddäus
* Stopinski, Thomas Thaddäus <[hidden email]> [2019-11-11 23:40]:
> In our believe we need the rewrite rule because, we want all traffic
> to go over a secure SSL connection.

A redirect directive in the non-TLS vhost should suffice:

  Redirect / https://${vhost}/

> As I was trying to describe in my initial mail, we have the SP and
> the Webapp running on two different machines. Even more, we run them
> in different domains.

Well, this is an except from the config you sent:

<VirtualHost *:443>
    UseCanonicalName On                                                                        
    ServerName shibboleth-ourserver.com
    # [...]    
    ProxyPass / https://shibboleth-ourserver.com
    ProxyPassReverse / https://shibboleth-ourserver.com

There the (local) ServerName and the (remote) proxied resource name
are represented by the same string. So did you simply mess up the
pseudonymization of the hosts when writing that email (and those
directives actually reference different server names) or is that a
fair representation of your configuration?

If the latter ServerName should be set to a name that maps (in DNS and
local configuration) to the proxy itself, and the ProxyPass(Reverse)
directices should point to the internal name of the proxied resource
server, which should never be accessed nor be accessible other than
going through the proxy. As such it doesn't even need a name in DNS.
(Though that might make things slightly easier wrt TLS client
configuration to the proxied resource.)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]