Qbi's Weblog

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag.

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

• Reddit
• Wikipedia
• Zoom
• Netflix
• Stackoverflow
• Apple
• und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

• Eintrag in der Wikipedia
• Homepage securitytxt
• Beitrag bei KrebsOnSecurity

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

GDPR & ePrivacy Regulations von Dennis van der Hejden. Original bei Flickr

Vor kurzem stellte ich mir hier im Blog die Frage, ob man noch Bilder des Dienstes Flickr einbinden kann. Nach meiner Prüfung kam ich zu dem Schluss, dass dies nicht mehr der Fall ist und entfernte die Bilder aus meinem Blog.

Heute hielt ich einen Workshop, der u.a. auch die Datenschutz-Grundverordnung zum Thema hatte. Dort fragte mich ein Teilnehmer, ob denn das Land Thüringen eine korrekte Datenschutzerklärung (DSE) hat. Der folgende Abschnitt brachte mich dann doch ins Staunen:

Flickr

Innerhalb unseres Onlineangebotes können Funktionen und Inhalte des Dienstes Flickr eingebunden sein. Flickr ist ein Foto- und Bilder-Dienst des amerikanischen Unternehmens SmugMug Inc. (67 E. Evelyn Ave, Suite 200
Mountain View, California, U.S.)Wenn Sie selber Flickr aktiv nutzen und ein Bild oder Video veröffentlichen, können wir ihn ebenfalls sehen, wenn Sie ihn jedermann zugänglich gemacht haben oder wenn wir Ihnen über Flickr folgen. Ebenfalls können wir Ihre Angaben auf Flickr sehen, wenn thueringen.de Ihrem Profil folgt. Einzelheiten zur Verarbeitung der Daten bei Flickr und den Sichtbarkeitseinstellungen entnehmen Sie bitte den Datenschutzbedingungen von Flickr bzw. Oath (ehemals Yahoo): policies.oath.com/ie/de/oath/privacy/index.html  

Das heißt, das Land Thüringen ist der Meinung, rechtmäßig Flickr-Bilder einbinden zu können. Wie kann das sein?

Weder Flickr noch Yahoo! noch eine der anderen Firmen steht bisher auf der Privacy-Shield-Liste. Und die Datenschutzbedingungen von Flickr gaben doch bisher auch nichts her. Aber: Unter anderen ist das Datenschutzcenter von Oath mit verlinkt. Dort steht gleich am Anfang:

Für Produkte oder Dienste von Oath, auf die ohne Anmeldung bei einem Account zugegriffen wird, gilt diese Datenschutzerklärung für diese Produkte und Dienste ab 25. Mai 2018.  

Flickr gehört mit zu Oath. Also gelten diese Bedingungen auch für Flickr. In der DSE steht drin, dass die Oath (EMEA) Limited in Dublin diese Dienste bereitstellt und damit wohl Verantwortlicher im Sinne der DS-GVO ist. Also werden die Daten von einem Unternehmen mit Sitz in der EU verarbeitet und die DS-GVO möchte ja den freien Verkehr personenbezogener Daten fördern (oder zumindest nicht einschränken).

Weiterhin erklärt Oath, dass sie die Standardvertragsklauseln der EU-Kommission verwenden bzw. nur Daten mit Unternehmen austauschen, die nach Privacy Shield zertifiziert sind.

Insgesamt scheint die Datenschutzerklärung den Anforderungen der Art. 13 und 14 DS-GVO zu entsprechen. Und auch inhaltlich ist es jetzt so, dass man wohl doch bedenkenlos Bilder von Flickr in seinem Blog einbinden kann.

In den letzten Beiträgen thematisierte ich die Verschlüsselung von Webseiten. Meine eigene Webseite läuft seit längerer Zeit über SSL/TLS. Das alte Zertifikat lief Ende Januar 2014 aus. Daher war es Zeit für eine Erneuerung. Das neue Zertifikat stammt von CACert. Vermutlich erzeugt das bei vielen eine Warnung im Browser. Daher solltet ihr unbedingt das Root-Zertifikat von CACert importieren. Dann funktionieren auch diese Seiten im Browser.

Mit dem neuen Zertifikat kommt ein neuer Fingerprint: 80:5B:82:22:9C:62:11:69:2E:92:69:9D:60:D1:DD:D3:C3:8C:D1:1A

Durch das fehlende Root-Zertifikat im Browser bewertet SSLLabs die Seite nur noch mit einem F. Bliebe der Fakt unberücksichtigt, würde die Webseite wieder ein A bekommen. Continue reading "Neues SSL-Zertifikat für kubieziel.de"

Ende letzten Jahres zog ich mit der Webseite auf einen anderen Server um. Der alte Server war etwas schwach auf der Brust. Einige Trafficspitzen bei meinen Seiten sorgten dafür, dass die Load sehr hoch ging. Der neue Webserver verträgt die Last sehr gut. Die Seiten werden daher schneller ausgeliefert und offensichtlich erzeugt, das jetzt mehr Traffic. Seit dem Umzug habe ich jeden Tag konstant mehr Traffic. In der Statistik ergibt sich folgendes Bild:

Die zweite gute Nachricht ist, dass Uberspace Server Name Indication (SNI) beim Webserver einsetzen. Das heißt, ich kann für die Seite ein eigenes SSL-Zertifikat nutzen. Daher könnt ihr ab sofort auf https://kubieziel.de/ aufrufen. Ich nutze hierfür ein Zertifikat von StartCOM. Im Gegensatz zu CAcert haben die den Vorteil, im Browser integriert zu sein. Der Nutzer muss sich also nicht durch eventuell unverständliche Meldungen quälen.

Ich werde versuchen, einen Eintrag in der Erweiterung HTTPS Everywhere zu bekommen. Wer also Firefox oder Chrome benutzt und das Plugn installiert hat, kommt dann automatisch zu den SSL-Seiten.

Im Februar 2013 wird hier also alles noch schöner, toller und überhaupt.

Da die Rezension etwas länger wurde, gibt es in der Artikelübersicht eine Zusammenfassung und in der erweiterten Ansicht alle Details.

Ich wurde kürzlich auf das Buch „Web-Sicherheit – Wie Sie Ihre Webanwendungen sicher vor Angriffen schützen“ von Sebastian Kübeck aufmerksam. Das Thema Web-Sicherheit spielt im Rahmen meiner Vorlesung zu IT-Sicherheit eine Rolle und daher war ich sehr daran interessiert, das Buch kennen zu lernen.

Der Aufbau des Buches gefiel mir sehr gut. Der Leser kann sich zuerst theoretisches Wissen erarbeiten, steigt dann in praktische Aspekte ein und lernt schließlich, wie er die Probleme umgeht.

Beim Lesen fiel mir dann auf, dass einige Teile meinen Erwartungen nicht gerecht werden. So wäre es bei einem Buch über Webanwendungen wünschenswert, dass es zumindest stichpunktartig auf die Techniken des Internet und des Web eingeht. Dieser Teil fehlt hier fast vollständig. Auch werden relevante Aspekte wie beispielsweise SSL zu kurz behandelt. Demgegenüber halte ich die Erwähnung des BTX-Hacks und anderer im Rahmen des Buches vernachlässigenswert.

Im ersten und zweiten Teil des Buches findet sich ein ausführliches Literaturverzeichnis. Das sollte dem Leser helfen, tiefer in die Thematik einzusteigen. Es wäre besser, dass die Zitierschlüssel geändert werden und mehr auf Fachliteratur statt auf Zeitschriftenartikel verwiesen wird.

Ich kann mich schlecht mit Java als Sprache für das Buch anfreunden. Aus verschiedenen Aspekten halte ich diese für weniger gut geeignet und Sprachen wie PHP, Python oder Ruby wären für mich eine bessere Wahl gewesen.

Im Buch selbst ist nach meiner Meinung zu viel Quellcode zu finden. Mindestens ein Fünftel besteht aus abgedrucktem Quellcode. Dabei ist zu viel Irrelevantes mit gedruckt. Für die Beispiele im Buch reichen oft wenige Zeilen. Code über viele Seiten finde ich zu unübersichtlich. Insbesondere auf Grund der Tatsache, dass sich der Autor auch die Arbeit gemacht hat und eine Demoanwendung mitliefert. Hier wäre es empfehlenswert, einfach die zur Erklärung des Beispiels relevanten Zeilen zu drucken und dann auf die betreffende Datei in der Demoanwendung zu verweisen.

Insgesamt bietet das Buch Licht und Schatten. Es hat viele gute Ansätze, die aber noch ausgearbeitet werden sollten. Wenn der Autor dies in einer nächsten Auflage schafft, so ist das Buch dann zu empfehlen. Derzeit bin ich unsicher, ob das Buch dem Publikum wirklich den erhofften Mehrwert bringt.

Rainer fragte sich und die identi.caer (später auch die Blogleser), ob denn die Webseite von Ilse Aigner gehackt ist. Der erste Blick auf die Seite liess mich in der Tat erstaunen:

Ich habe die Firefox-Erweiterung NoScript aktiviert und die Browserweiche der Webseite wurde aktiv. Aber bereits hier war das Problem im HTML-Code zu sehen. Eine enorme Menge JavaScript. Im erweiterten Teil des Beitrages findet ihr den kompletten Schnippsel. Ich habe da nur an jedem Semikolon einen Umbruch eingebaut.

Innerhalb des JavaScript-Teiles werden diverse Variablen angelegt und nie benutzt. Es gibt die merkwürdige Zeile eturn ’h3t)t|p3:3/3/)q)l)k|eJ.Jr)u$/|i|nJd)e|x).)h|t|m|l|’.qK(/[\|J\$3\)]/g, ’’); und andere Nettigkeiten. Ich habe dann mal versucht, das Puzzle sinnvoll wieder zusammen zu setzen. Nach meiner Meinung dient der Code dazu, innerhalb der Webseite einen Bereich zu öffnen (IFrame). Dort wird der Inhalt der Seite qlke.ru/index.html geladen. Im nächsten Schritt wäre es also von Interesse, was in dieser Datei steht.

Ich versuchte also zunächst ein GET /index.html HTTP/1.1 bei der Seite und erhielt als Antwort:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 18 Jun 2010 13:00:01 GMT
Content-Type: text/html
Connection: close
Last-Modified: Mon, 14 Jun 2010 15:01:58 GMT
ETag: “a6600e-2881-488fec52d6580”
Accept-Ranges: bytes
Content-Length: 10369
Vary: Accept-Encoding

404 Not found

Wie man sieht, habe ich den Abruf heute gemacht. Leider habe ich den kompletten HTTP-Header nicht gespeichert. Insofern könnte der Teil ab Last-Modified vorher anders gewesen sein. Sehr markant finde ich, dass der Webserver meint, es sei alles in Ordnung (200 OK), währenddessen eine nicht gefundene Seite vorgespiegelt wird. Das kann natürlich ein Fehler in der Konfiguration sein. Viel wahrscheinlicher hielt ich das jedoch für einen Platzhalter, der später durch Schadcode ersetzt wird. Mittlerweile hat sich diese Vermutung wahrscheinlich bestätigt. Denn diese Seite enthält jetzt HTML und wieder JavaScript. Das lädt dann Code von der Seite http@//bijitersto@com/cgibin/index@php (Ich habe mal Doppelpunkt und Punkt durch @ ersetzt) nach. Firefox meldet diese Seite sofort als attackierende Seite. Also seit vorsichtig beim Betreten.

Der Server auf dem qlke.ru läuft, steht derzeit in Österreich. Die zweitgenannte Seite läuft derzeit auf einem Rechner in der Ukraine. Also insgesamt sieht das Ganze nicht unbedingt so aus, als ob das die Verbraucherschutzministerin ihren Besuchern anbieten will.

Ich frage mich, wie der Quellcode überhaupt auf die Seite von ilse-aigner.de gekommen ist. Hat da jemand den Rechner gehackt bzw. die Software, die die Webseiten ausliefert? Offensichtlich hatten die Besucher der Webseite von Ilse Aigner viel Glück. Denn die Angreifer hatten ihre Munition noch nicht an den Start gebracht. Ein erster Kontaktversuch zu den Betreibern der Webseite von Ilse Aigner lief leider ins Leere, da E-Mails an den Webmaster als unzustellbar zurückkamen. Ich werde eventuell Frau Aigner direkt um Stellungnahme bitten. Falls ich Rückmeldung erhalte, werde ich nochmal ein paar Zeilen dazu schreiben.

Auf den Hinweis von Anofox habe ich mal ein wenig am CSS der Seite herumgespielt. Auch von den Identicaern gab es einige gute Hinweise. Das Ergebnis seht ihr. Gibt es dabei etwas, was euch (nicht) gefällt? Kommentare sind sehr erwünscht.