[Info] FRITZ!Box 7560 FRITZ!OS 6.92 vom 09.11.2017

Wotan-Box · 9 Nov 2017

Weitere Verbesserungen im FRITZ!OS 6.92

DSL:
Behoben - Syncabbrüche an manchen ADSL Annex-J Anschlüssen
Verbesserung - Darstellung optimiert für ADSL Anschlüsse mit G.INP
System:
Behoben - Darstellungsfehler beim Scrollen in der Benutzeroberfläche unter Android
WLAN:
Behoben - Schwäche in der WPA2-Schlüsselaushandlung bei Nutzung eines WLAN-Uplinks zu einem anderen Router
USB:
Behoben - Absturz bei Nutzung des USB-Fernanschlusses mit best. Multifunktionsgeräten

koyaanisqatsi · 12 Nov 2017

Moin

Eine kleine Änderung, die nirgends dokumentiert ist...
Die Fritz!Box überträgt keinen HTTP "Referer" mehr, wenn auf ein Heimnetzgerät geklickt/getapt wird dass auf HTTP Port 80 zu erreichen ist.
Das wären die Gerätelinks auf der Übersicht, Heimmetzübersicht und Netzwerkverbindungen.

Früher (z.B. 7360 SL mit 6.30) wurde im "Referer" sogar die SID mit übertragen, konnte so also abgefangen werden.
Klickt/Tapt mal im Webinterface oben Rechts auf FRITZ!NAS oder MyFRITZ! und schaut in die Adresszeile des Webbrowsers, dann wisst ihr was ich meine.

PeterPawn · 12 Nov 2017

Die Existenz und der Inhalt des "Referer"-Headers im HTTP-Protokoll ist aber eine Entscheidung des verwendeten Browsers - den kann die FRITZ!Box per se nicht wirklich beeinflussen.

Das geht nur indirekt über die Seite, welche tatsächlich der "Vorgänger" so eines Abrufs war und das dürfte auch der Grund sein, warum (schon länger) der Aufruf solcher Links zunächst mal über die FRITZ!Box (secure_link.lua) erfolgt, die dann in der Folge noch einen weiteren Aufruf über einen Fehlercode 303 (See Other) veranlaßt, wo die URL keine SID mehr enthält.

Das erfolgt auch mit einem kleinen "Statusspeicher" in Form einer temporären Datei (/var/tmp/gui_secureLink.txt), welche die URL für diesen "gesicherten" Abruf enthält. Zusätzlich kommt hier noch ein Mechanismus zum Einsatz (webuicookie), der für eine definierte Zeit auch den Abruf von eigentlich durch eine gültige Session geschützten Informationen ermöglicht. Hier besteht auch eine kleine Chance für eine Race-Condition (zumindest theoretisch), da es für alle aktiven GUI-Sessions nur eine gemeinsame Datei gibt. Das könnte ein Angreifer im LAN tatsächlich ausnutzen (sofern er durch das Mitlesen einer (unverschlüsselten) GUI-Session vom zu erwartenden Ablauf weiß), um einen anderen Client (also einen anderen Browser) auf eine Site seiner Wahl "umzuleiten" - die URL in so einem Request für "secure_link.lua" ist praktisch "wahlfrei".

Im Ergebnis dieses Aufrufs erhält jedenfalls der Client (also hier der Browser) dann eine HTML-Datei, in der über das "refresh"-Meta-Tag nach 0 Sekunden der Aufruf der eigentlichen URL angestoßen wird.

Damit ist der "Referer" am Ende die Seite "secure_link.lua?sid=" (aber ohne Wert für "sid") und der Browser hat keinen Grund, eine gültige SID an ein anderes Gerät im LAN oder gar an AVM selbst zu versenden, denn es gibt ja auch genug Links in so einer GUI-Seite, die am Ende bei AVM landen.

Das führt aber gleichzeitig dazu, daß ein automatischer Abruf solcher Links über ein Programm wie "wget" nicht mehr funktioniert, denn für die Auswertung des "refresh"-Tags muß man sich den HTML-Inhalt ansehen und kann sich nicht mehr nur auf die Abläufe im HTT(P)-Protokoll stützen - dann landet man immer bei dieser leeren Seite, die nur im (HTML-)Header das "refresh" enthält.

koyaanisqatsi · 12 Nov 2017

Stimmt, dass geht über die secure_link.lua, aber der HTTP-Referer ist wirklich komplett weg, bei der 6.90 wurde hingegen nur die SID aus dem Referer entfernt.
(Getestet mit der PHP Funktion getallheaders() in der index.php als Startseite)

Da bastel ich die Header mit PHP, weils kürzer ist...

Code:

<?php
$thisPage = "/";
header("content-type: text/html;charset=UTF-8");
header("cache-control: no-cache, must-revalidate")
header("expires: Sat, 26 Jul 1997 05:00:00 GMT");
header("robots: noindex, nofollow");
header("refresh:60;url='$thisPage'");
header("base: /");
echo '<!DOCTYPE HTML>
<html>
...
';

Im Browser tauchen die als Quelltext ( view-source: ) im <head> nicht auf, funktioniert, das Refresh zum Beispiel, aber trotzdem.

PeterPawn · 12 Nov 2017

HTML-Header sind keine HTTP-Header ... erstere sind Bestandteil der HTML-Seite (zwischen "<head>" und "</head>") und letztere werden "außerhalb" des Content übermittelt (im Browser nur mit den "Developer Tools" zu sehen oder in einem Mitschnitt des kompletten Traffic).

Wie gesagt ... die Entscheidung, ob und welcher "Referer"-Header gesendet wird, trifft der Browser. Schau z.B. mal in den Firefox bei "about:config" und beschränke die Anzeige auf alle Variablen mit "referer" ... da findest Du dann ein paar dieser Einstellungen. Zur Bedeutung und ggf. möglichen Änderungen gibt es dann andere Quellen (z.B. hier: https://www.pc-tweak.de/mozilla-firefox/referrer-anonymisieren/) und natürlich wird so ein "Referer"-Header in der Regel von Kommandozeilen-Programmen oder Seitenabrufen aus Skriptsprachen (von Shell bis PHP) eher selten verwendet, weil die ja meist so einen Abruf nicht als Resultat eines "Klicks" auf irgendeinen Link ausführen. Bei den ausführlicheren Versionen dieser CLI-Clients kann man aber meist noch festlegen, ob/daß ein solcher Header gesendet werden soll und mit welchem Inhalt.

Auch das "Durcheinanderwerfen" solcher Header in einigen Skript-Sprachen trägt natürlich nicht zur Übersichtlichkeit bei ... es ist halt ein Unterschied, ob ich ein "<meta>"-Tag in HTML erzeugen will oder wirklich einen HTTP-Header (z.B. "Content-Security-Policy"). Wobei PHP da meines Wissens sogar noch "vorbildlich" ist, denn aus dem oben gezeigten "header"-Aufruf dürfte gar kein passendes Meta-Tag im HTML-Text entstehen, sondern ein (nicht zum Standard gehörender und trotzdem von einigen (bzw. vielen) Browsern umgesetzter) HTTP-Header.

Da gibt es aber (eben dank des fehlenden Standards, jedenfalls soweit ich weiß) durchaus viele "Unklarheiten" bzgl. so eines HTTP-Headers ... z.B. die Frage, wie man sich eigentlich verhalten soll als "Empfänger", wenn so ein Header im HTTP-Protokoll für irgendeine "Nicht-HTML-Ressource" (z.B. ein Video oder ein Bild) auftaucht - soll man dann den betreffenden Request auch nach der angegebenen Anzahl von Sekunden starten oder nicht?

Ich weiß also nicht genau, was Du jetzt an dieser Stelle wirklich "vermißt" bzw. mit welcher Version (wirklich 06.30?) Du das jetzt vergleichst ... bei der 06.30 gab es (iirc) die Umleitung über "secure_link.lua" noch nicht.

PS: Es gibt natürlich auch einige "privacy extensions" für die diversen Browser, die ihrerseits den Inhalt eines HTTP-Referer-Headers beeinflussen können - auch das wäre eine Stelle, wo man noch einmal nachsehen kann, was sich ggf. geändert haben könnte.

Languages

Suche

Languages

Suche

[Info] FRITZ!Box 7560 FRITZ!OS 6.92 vom 09.11.2017

Wotan-Box

IPPF-Promi

koyaanisqatsi

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

koyaanisqatsi

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums