0

I have a problem with iframes and cookies in a multi-domain web-application.

Just before I begin, I know very well that application1 on domain1 can't access or set a cookie of application2 on domain2. So it's not a beginner's problem.

The problem is as follows:
I have website1, located at https://test.xyz-abc.ch/FM_xyz/w8/index.html

and a reportserver (website2), located at https://www8.company-asp.ch/ReportServer

The narrowed-down version of the problem is this:

I put this content

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Test Page</title>
    </head>

<body>
    <iframe src="www8.company-asp.ch/ReportServer/login.aspx" width="1000" height="1000" ></iframe>
</body>
</html>

into file "ifrm.html" with URL
https://test.xyz-abc.ch/FM_xyz/w8/ifrm.html

Now no matter what I put as username/password on the reportserver form, it doesn't work (the username and password are 120% correct, and exist and have all necessary permissions).

If I do the same thing on Google Chrome or Firefox, then it works, I can login in the Report-Application contained in the iframe.

But in Internet Explorer, you can (attempt to) login, but always stay at the login screen, because for an unknown reason, it either doesn't create the cookie, or it doesn't send the cookie along.

If I run reportserver outside the iframe, i can login and open reports in Internet Exploder.
Note that ReportServer runs on Forms Authentication (with cookies), not Windows Authentication.

Also, the problem is not specific to ReportServer, I can put any application that uses cookies for authentication in there, and they also fail miserably - but only in Internet Exploder, everything works fine in Chrome and Firefox.

I find this strange, since - if I run the same application (site1) on
https://www6.company-asp.ch/FM_xyz/w8/index.html
and have reportserver on the same domain at
https://www8.company-asp.ch/ReportServer
, then it works.

Does anybody know what the problem is or might be (I mean apart from the fact that IE is a piece of sh*t software) ?
The only thing I can think of as difference between the working and non-working variant is that the main domain (the sub-domain is different in both examples) is different.

Is this a (by design) SSL problem in IE (= serious bug?), or might this be a problem with SSL/SSL-Certificate misconfiguration ?

Edit:
Yes, I know I can disable it as in <see below>, but that's not an acceptable solution. I can't tell the client to tell all his employees to alter this setting in their IE. First that never works, second they might not have permission to alter those settings, third the IT department might not allow it, for whatever reasons, and fourthly because it's stupid to ask the customer(s) to alter the settings of their browsers...
P3P

Edit 2:
It get's worse. It is P3P, I got it to work on my test-domain using a P3P header via web.config.
But one cannot add P3P headers in the web.config of ReportServer, because it runs on some kind of internal IIS6.

Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442

2 Answers2

0

Try this:

1.Open Internet Explorer, select Tools | Internet Options

2.Click the Security tab

3.Choose Internet zone

4.Scroll down to "Launching programs and files in an IFRAME"

5.Select Enable

6.Click OK

securecodeninja
  • 2,497
  • 3
  • 16
  • 22
  • Great, then it runs on my computer, but not on the customers ;) If you call this a solution, provide a zero-day exploit that one can put on the base page that does this. And actually, it's under "privacy" -> "Advanced" --> "Disable automatic cookie processing" – Stefan Steiger Dec 10 '14 at 10:21
0

This was indeed the work of P3P.
Superb IE troll-level.

The solution:

The sane way to fix this normally is to add a custom header to the system.webServer section of the web.config file.

<system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>


    <httpProtocol>
        <customHeaders>
          <add name="p3p" value="CP=&quot;IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT&quot;"/>
        </customHeaders>
    </httpProtocol>
</system.webServer>

However, since SSRS is in-sane, they use IIS6/Cassini internally (even when on an operating system with IIS 7.5). So you can't just add the headers in the web.config file, because system.webServer is IIS7+.

Putting the headers with inline-tags into the aspx pages isn't sufficient, either, doesn't work

<%
    System.Web.HttpContext.Current.Response.AppendHeader("P3P", "CP=\\\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\\\"");
 %>

So you need to write a custom-http-Module that adds the P3P-Header on every response...
This would be simple, if ASP.NET wouldn't be buggy and wouldn't call EndRequest before the end of the request and then again once after the request was sent...

So this is the final result:

namespace CustomHttpHeaders
{


    public class CustomHttpHeaderModule : System.Web.IHttpModule
    {


        public void Dispose()
        {
            // CustomHttpHeaders.CustomHttpHeaderModule mod = new CustomHttpHeaderModule();
        }


        public void Init(System.Web.HttpApplication context)
        {
            // context.BeginRequest += new System.EventHandler(context_BeginRequest);
            context.EndRequest += new System.EventHandler(context_EndRequest);
        }


        void context_BeginRequest(object sender, System.EventArgs e)
        {
            if (System.Web.HttpContext.Current != null && System.Web.HttpContext.Current.Request != null)
            {
                System.Web.HttpRequest request = System.Web.HttpContext.Current.Request;
                // request.Headers.Add("name", "value");
            } // End if (System.Web.HttpContext.Current != null && System.Web.HttpContext.Current.Response != null)
        }


        void context_EndRequest(object sender, System.EventArgs e)
        {
            if (System.Web.HttpContext.Current != null && System.Web.HttpContext.Current.Response != null)
            {
                System.Web.HttpResponse response = System.Web.HttpContext.Current.Response;

                try
                {
                    // OMG - WTF ??? non-redundant redundancy ^3 
                    // response.Headers["P3P"] = "CP=\\\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\\\"":
                    // response.Headers.Set("P3P", "CP=\\\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\\\"");
                    // response.AddHeader("P3P", "CP=\\\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\\\"");
                    response.AppendHeader("P3P", "CP=\\\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\\\"");
                }
                catch(System.Exception ex)
                {
                    // WTF ? 
                    System.Console.WriteLine(ex.Message); // Suppress warning
                }

            } // End if (System.Web.HttpContext.Current != null && System.Web.HttpContext.Current.Response != null)

        } // End Using context_EndRequest


    } // End Class myHTTPHeaderModule


} // End Namespace CustomHttpHeaders

And then you can add the CustomHttpHeaderModule in the web.config file of ReportServer.
Weeeee :O=

  [...]
  <httpModules>
    <clear />
    <add name="CustomHttpHeaders" type="CustomHttpHeaders.CustomHttpHeaderModule, CustomHttpHeaders" />
  </httpModules>

</system.web>

If you want to debug it in Visual Studio 2013 (IIS Express), you need this as well (in the web.config file)

<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>

<modules runAllManagedModulesForAllRequests="true" >
  <add name="CustomHttpHeaders" type="CustomHttpHeaders.CustomHttpHeaderModule, CustomHttpHeaders" />
</modules>


<!--
<httpProtocol>
  <customHeaders>
      <add name="p3p" value="CP=&quot;IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT&quot;"/>
  </customHeaders>
</httpProtocol>
-->
Community
  • 1
  • 1
Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442