it-swarm.com.de

X-Frame-Optionen funktionieren nicht IIS web.config

Unsere Site ist derzeit nicht sicher vor Clickjacking, also ging ich in die web.config und fügte hinzu

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="X-Frame-Options" value="DENY" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

Dies ist ein sehr einfacher Code. Mein Problem ist, dass es funktioniert einfach nicht. Die Fragen, die ich habe, sind:

  1. Gibt es eine Möglichkeit für mich zu sehen, ob der X-Frame-Options in der Header-Antwort steht? Ich habe mit httpfox danach gesucht und nichts erhalten, daher kann ich nicht überprüfen, ob der web.config tatsächlich in die Kopfzeile einfügt.
  2. Warum funktioniert das nicht? Was kann ich tun, um zu testen oder voranzukommen? 

Ich habe versucht, es in Global.asax in der Application_Start-Methode hinzuzufügen, aber ich kann diese Methode nicht "treffen", wenn ich debugge; es trifft keine Haltepunkte. 

private void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    HttpContext.Current.Response.AddHeader("x-frame-options", "DENY");

    LogHelper.Info("Cost of Care Web Application Starting");
}

Ich möchte hinzufügen, dass ich versucht habe, es direkt in den Head-Tag einzufügen, und ich habe auch versucht, es in einem Meta-Tag hinzuzufügen 

<meta http-equiv="X-Frame-Options" content="deny">
16
Moi Hawk

Da meine Kommentare die Frage beantwortet haben, ist hier das Endergebnis:

Aus irgendeinem Grund scheint das Setzen von X-Frame-Options in web.config nicht wirklich zu funktionieren, auch wenn die Dokumentation dazu führt, dass es so klingt, wie es sollte.

Um dies zu umgehen, müssen Sie die Header manuell einstellen.

Response.AddHeader("X-Frame-Options", "DENY");

Wenn Sie dieses Set für jede Anforderung ohne Ausnahmen benötigen, können Sie den Application_BeginRequest zu Global.asax hinzufügen:

protected void Application_BeginRequest()
{
    Response.AddHeader("X-Frame-Options", "DENY");
}
18
siva.k

Mit dem X-Frame-Options-Header kann gesteuert werden, ob eine Seite in einem IFRAME platziert werden kann. Da die Framesniffing-Technik darauf beruht, dass die betroffene Site in einem IFRAME platziert werden kann, kann sich eine Webanwendung durch Senden eines entsprechenden X-Frame-Options-Headers schützen.

Gehen Sie folgendermaßen vor, um IIS zum Hinzufügen eines X-Frame-Options-Headers zu allen Antworten für eine bestimmte Site zu konfigurieren:

  1. Öffnen Sie den Internetinformationsdienste-Manager (IIS).
  2. Erweitern Sie im Bereich Verbindungen auf der linken Seite den Ordner Sites, und wählen Sie die Site aus, die Sie schützen möchten.
  3. Doppelklicken Sie auf das Symbol HTTP Response Headers in der Funktionsliste in der Mitte .  enter image description here
  4. Klicken Sie im Aktionsbereich auf der rechten Seite auf Hinzufügen.
  5. Geben Sie im angezeigten Dialogfeld X-Frame-Options in das Feld Name ein und geben Sie SAMEORIGIN oder DENY in das Feld Wert ein  enter image description here
  6. Klicken Sie auf OK, um Ihre Änderungen zu speichern.
15
Voltur

Die Antwort von siva.k funktioniert nicht in Verbindung mit MVC5, da der Header hier zweimal generiert wird. Der folgende Code sollte funktionieren:

protected void Application_Start()
{
  //  MVC5 generates the "X-Frame-Options SAMEORIGIN" header by default, the following line disables the default behaviour
  System.Web.Helpers.AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}

protected void Application_BeginRequest() 
{
  Response.AddHeader("X-Frame-Options", "DENY");
}

Das Flag SuppressXFrameOptionsHeader wurde hier erwähnt: https://stackoverflow.com/a/20262211/3936440

10
ViRuSTriNiTy

Hier ist noch etwas zu beachten: 

Wenn Sie über separate Back-End- und UI-Projekte verfügen (wie bei REST -basierten Websites üblich), stellen Sie sicher, dass Sie X-Frame-Options in die UI web.config einfügen. Ihre API lässt wahrscheinlich standortübergreifende Aufrufe zu, sodass das Hinzufügen des Headers zu Ihrem API-Projekt keinen Sinn macht.

3
MarzSocks
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Content-Security-Policy" value="default-src: https:; frame-ancestors 'self' X-Frame-Options: SAMEORIGIN" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

Ihr web.config-Eintrag muss sich unter content security policy befinden, um die aktuelle Codierung zu verwenden, die zuvor nicht abgeschrieben wurde. Der Wert unter der Inhaltssicherheitsrichtlinie von value="default-src: https: gilt nur für Ihre Website. 

Es kommt auf den Inhalt an, der nach 'value = "default-src: https:' steht, aber am wichtigsten ist die Inhaltssicherheitsrichtlinie.

1
Brian Kunick

Ich habe festgestellt, dass einige Dateitypen (ASP- und HTM-Dateien) den X-Frame-Options-Header erhalten, der durch diesen Mechanismus hinzugefügt wurde, andere (.js) nicht. Mit dem Verwaltungsdienstprogramm IIS entfernte ich den Header von der Anwendungsebene und fügte ihn auf Serverebene hinzu. Anschließend wurde bei allen Dateien der Header hinzugefügt.

1
BlueMonkMN