Vorschlag für eine Browser-Sicherheitstechnologie
Version 1.2/2.5+, 01.10.2009
Problembewusstsein
Nebenziele, positive Nebeneffekte, weitere Betroffene
Realisierung, mögliche Probleme, Entwicklungskosten und -dauer, Unsicherheit des Entwicklungserfolgs, Investitionsbedarf und variable Kosten
Vorteile der Innovation und ihr Gewicht, Aufwand-Nutzen-Verhältnis, Nachteile der Innovation
Durch die kryptografische Sicherung sicherheitstechnisch kritischer Webseiteninhalte soll die nach SSL/TLS verbleibende (praxisrelevante!) Lücke gestopft werden.
Technisch unbedarfte Internetnutzer bekommen immer wieder gesagt, dass ein Virenscanner allein kein Allheilmittel sei und man deshalb gewisse Grundregeln beherzigen müsse. Eine davon lautet, sich von unseriösen Webseiten fernzuhalten. Leider ist man auch auf seriösen Webseiten nicht vor Angriffen sicher.
Der beste Weg, eine Browsersicherheitslücke auszunutzen, was wegen der Unidirektionalität der Webbrowser nur passiv möglich ist, ist die Kompromittierung vieler Webseiten, (auch) "seriöser" Webseiten. Man knackt den Webserver und schummelt dann (in der Webseitendarstellung unauffälligen) Code in die ausgelieferten Seiten, der den Browser auf die eigentlichen gefährlichen Inhalte (auf dem geknackten oder einem anderen Webserver) lenkt.
Dies ist ein strukturelles Problem, denn man wird nie davon ausgehen können, dass
die eingesetzte Webserversoftware fehlerfrei ist
die eingesetzte Webserversoftware korrekt konfiguriert ist
eine brauchbare Webserversoftware eingesetzt wird.
Der Nutzer einer Webseite sollte auch dann noch die Möglichkeit haben, sich zu "verteidigen", wenn der Webserver bereits gegen den Angreifer verloren hat. Dafür muss der Browser/Nutzer sich solcher Elemente bedienen, die ein Angreifer unter normalen Umständen (wobei das Vorhandensein ausnutzbarer Softwarefehler in diesem Sinn als "normal" gilt) nicht unter seine Kontrolle bringen kann.
Der texliche Inhalt der Seiten (Quelltext und dargestellter Text) ist für einen Browser vergleichsweise harmlos; damit Softwarefehler auszunutzen, sollte vergleichsweise schwierig sein (d.h., solche Lücken sind selten). Die kritischen Elemente sind:
Code: Javascript (vor allem indirekt durch den Aufbau von Verbindungen zu anderen Rechnern), ActiveX
Links bzw. URLs im allgemeinen, vor allem externe (also solche, die nicht innerhalb der Webseite liegen)
Neben den offensichtlichen URLs, also den Links, sind das die "versteckten"/transparent wirkenden (=vom Browser ohne Zutun des Users aufgerufene) wie bei Frames und die "unauffälligen" wie bei Formularen
eingebundene Objekte: Bilder, Dateien mit Daten für Plug-ins (v.a. Flash, Videos)
Dass das Internet grundsätzlich und vor allem "diffus" gefährlich ist, ist den meisten Leuten bekannt und zumindest auf Nachfrage auch klar.
Das Problem, dass einem über einen geknackten Webserver gefährliche Inhalte untergeschoben werden können (auch über eine SSL-/TLS-geschützte Verbindung), kann man dadurch lösen, dass man diese kritischen Elemente signiert, und zwar nicht in der Sphäre des Webservers (dann hätte man das SSL-Problem nur verschoben), sondern in der Sphäre des Webdesigners.
Dadurch hätten sich Angriffe auf Webseiten, die indirekt auf die Browser zielen, für alle Ewigkeit erledigt, sofern der Browser wüsste, dass diese Seite die vorgeschlagene Technik nutzt, obwohl sie in dem Moment nicht angeboten wird, weil der Angreifer die entsprechenden Dateien gelöscht hat.
Der Schutz erstreckt sich über das Blocken unautorisierten Codes auch auf Cross-site-scripting-Attacken (XSS), die weit verbreitet sind.
Bei Verwendung von PGP für dieses System besteht die Chance, die Anwender auch bei E-Mails dafür zu interessieren.
Natürlich braucht dieses System eine PKI (public key infrastructure). Es reicht nicht, Inhalte mit einem beliebigen Schlüssel zu signieren (das könnte auch ein Angreifer), sondern man muss einen Schlüssel nehmen, dem der Browser(benutzer) für die jeweilige Domain vertraut. Dafür muss irgendwer diesen Schlüssel unterschreiben; und üblicherweise will niemand als Handlanger von Kriminellen oder Spammern dastehen, zumal demjenigen dann sofort das Signaturvertrauen entzogen würde.
Es ist sinnvoll, statt einer reinen Ja-nein-Entscheidung beim Signieren bzw. des wenig festgelegten certification level bei OpenPGP eine feinere Beurteilung des Vertrauens einzuführen. Statt einen Schlüssel direkt zu unterschreiben, sollten die Bewertungen in eine XML-Datei geschrieben werden, die dann signiert wird. Diese Datei enthielte dann folgende Informationen:
Erwähnenswert ist in diesem Zusammenhang ein anderer Vorschlag des Verfassers, der von dem vorliegenden fast vollständig erfasst wird.
Die Darstellung einer Webseite liefe dann in folgenden Schritten ab:
Feststellen, ob die Webseite das System nutzt; Einlesen und validieren der Signaturdatei
Ein Browser-Add-on würde an genormter Stelle (z.B. /websignatures.txt.asc und ./websignatures.txt.asc) eine Datei suchen, in der die Hashes der fraglichen Elemente befinden. Unter einer standardisierten Adresse wäre auch der public key zu finden (z.B. ./websignatures.key.asc).
Wird eine Datei gefunden, würde sie validiert. Sie muss korrekt signiert sein, und der Schlüssel muss die nötige Vertrauensstellung haben (s.u.); das ist quasi dasselbe wie bei der Verwendung von PGP bei E-Mails.
Um den Schutzmechanismus nicht dadurch auszutricksen, dass der Angreifer dem Browser vorspielt, die Seite nutze ihn gar nicht (indem er die Dateien löscht), sollte es externe Überprüfungsmöglichkeiten geben (s.u.).
Auswerten der Signaturdatei
Die Signaturdatei enthielte vor allem Hashwerte. URLs/URIs und sehr kurze Codesequenzen (onlick="foo();"
) könnte man dort auch direkt aufführen. Wenn Links oder kurze Codesequenzen dynamisch erzeugt werden, so dass es nicht praktikabel ist, alle Varianten aufzuführen, kann man statt dessen reguläre Ausdrücke – die natürlich das neue Sicherheitsproblem dummer Webmaster mit sich brächten – aufführen. Diese Textdatei wäre dann digital signiert (OpenPGP).
Überprüfung der Elemente
Vor dem Rendern einer Webseite prüfte das Add-on dann alle Elemente der fraglichen Kategorien (natürlich bevor sie zur "Ausführung" kommen) dahingehend, ob es für sie einen Eintrag in der Datei gibt. Wenn nicht, würde – je nach Konfiguration – entweder der Anwender gewarnt (wie heute schon üblich bei SSL-Seiten, die auch nicht-SSL-geschütze Elemente enthalten) und könnte entscheiden, wie mit diesen Elementen verfahren werden soll, oder die fraglichen Elemente würden ignoriert.
Da URLs auch dynamisch erzeugt werden können (wenn auch nur von signiertem Code), bietet es sich an, auch direkt vor dem Aufruf einer URL diese einer solchen Überprüfung zu unterziehen.
Eine ganz einfache Webseite:
<html ...> <head> ... <script ...> function tu_irgendwas () { lalala; } </script> </head> <body> <h1>this is a page with secured content</h1> <p><a href="http://irgend.ein.server/">this link is signed</a></p> <p>This image is signed; it could be a video, too: <img ... /></p> </body> </html>
Hervorgehoben sind die kritischen Elemente bzw. Textteile davon. Nicht markierbar ist natürlich die referenzierte Bilddatei, bei der nicht die URL geprüft wird, sondern der Dateiinhalt selber. Neben dieser Datei befindet sich auf dem Webserver eine Datei mit diesem Inhalt:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 68ec2bcf99f8ed4695d48fb145a89be1cc17c51c 65572e84bd20b9d3a527e32974763deb14bfc072 e412d084e8f2a73fa94650081d75067019bf392c -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFKedo6vX1tJ+zLWBQRAheNAJ9PUDKi12eQIWO02yp5LNpmUleN3QCdHfBt wJiApr6Ct6UEGeKGQRAmcBE= =mssF -----END PGP SIGNATURE-----
Hervorgehoben sind die Hashwerte. Der Rest gehört zur digitalen Signatur. Die Hashwerte kann man unter Linux in der Shell folgendermaßen erzeugen:
echo -n 'function tu_irgendwas () { lalala; }' | sha1sum
echo -n 'http://irgend.ein.server/' | sha1sum
sha1sum < 1.jpg
Das -n ist wichtig, weil echo sonst einen Zeilenumbruch hinterherschickt, der dann mitgehasht wird, was natürlich nicht gewünscht ist.
detaillierte Überprüfungsangaben in einer XML-Datei (private key auf einem getrennten System); Forenuser (anonyme Schlüssel); Spammer?
Die ganze Aktion hat natürlich nur dann überhaupt einen Sinn, wenn man davon ausgehen darf (was leider keine technische Kategorie und der sicheren Bestimmung von außen prinzipiell nicht zugänglich ist), dass der Signaturschlüssel des Betreibers des Webangebots sicher verwahrt wird.
Technische Voraussetzung ist, dass der Schlüssel auf einem anderen Rechner liegt, durch den die Inhalte auf den Webserver geschleust werden, die per Signatur freigegeben werden sollen. Das ist nicht immer leicht möglich.
Dieser Rechner sollte zudem so konfiguriert sein, dass die Gefährdung minimal wird, also etwa (auf Dienstebene) nicht von außen zugänglich sein (was schwierig ist, wenn mehrere Leute Inhalte für die Webseite bereitstellen, die nicht problemlos physisch auf den Rechner zugreifen können).
Bei einer theorielastigen Betrachtung der Sicherheit der vorgeschlagenen Maßnahme muss man fragen, wie verhindert werden soll, dass der Anbieter – unbewusst natürlich – kompromittierte Dateien signiert. In der Praxis wird er sich auf einen Virenscanner verlassen müssen, denn wenn der Angriff so subtil ist, dass nicht wenigstens der Bildbetrachter abstürzt, wird der Prüfer keinen Verdacht schöpfen und die Datei durchwinken. Trösten kann man sich allerdings damit, dass es sehr viel schwieriger ist (vor allem bei einer großen Zahl von Webservern quasi unmöglich), auf diese Weise eine kompromittierte Datei auf einen Webserver zu bekommen, als ihn zu hacken und sie selber dort zu platzieren.
Der dynamischen Generierung von Seiten sind durch diese Technik natürlich Grenzen gesetzt. Die Dynamik darf sich nicht auf signierte Elemente selber auswirken, nur auf deren Verwendung (Anordnung). Ausnahme sind reguläre Ausdrücke (für URLs und eventuell Code).
Positiv in bezug auf dynamische Inhalte ist, dass das CMS (oder, eine Nummer kleiner, der generierende Code) nichts von dieser Technik wissen muss; es können also problemlos alle bestehenden Systeme prinzipiell damit verwendet werden. Lediglich die signierte Datei muss das System unangetastet lassen. Der Webmaster muss natürlich wissen, welche URLs und Codesequenzen sein System (legitim) produzieren kann, damit er alle diese in die Signaturliste aufnehmen kann.
Man kann aber ein CMS (oder, unter Inkaufnahme des Verheizens einer Menge Rechenleistung, den Webserver – das wäre dann CMS-unabhängig, quasi als Notlösung) dahingehend an dieses System anpassen, dass es die generierten URLs und Codesequenzen (Javascript) mit der Signaturliste abgleicht und dadurch Konfigurationsfehler aufdecken und Alarm schlagen kann.
Den Signaturschlüssel auf dem Server zu hinterlegen, ist keine Option. Eine solche Umsetzung des Konzepts wäre kein Sicherheitsgewinn, sondern eine Sicherheitslücke, weil die Nutzer der Seite getäuscht würden (was Haftungsansprüche nach sich ziehen kann, wenn Clients auf diese Weise infiziert werden). Das System hätte SSL dann nichts mehr voraus. Es böte nur noch Schutz gegen das Knacken den Uploadzugangs, also vielleicht gegen die Manipulation von Bildern, Videos usw. Das typische Hacken eines Webservers geht aber mit der Kompromittierung der Schlüssel auf dem Rechner einher.
Weitere Probleme dieser Variante sind, dass die Performance des Webservers erheblich darunter leiden dürfte (ganznzu schweigen davon, dass die nötige Entropie für massenhafte Signaturen ohne Hardware-RNG gar nicht zur Verfügung steht) und dass von außen erkennbar wäre, dass der Schlüssel auf dem Rechner liegt, womit er ein bevorzugtes Angriffziel wäre. Letztlich müsste geklärt werden, wie die dynamischen Signaturen den Browser erreichen. Sinn der Sache ist natürlich nicht, dass der Zugriff auf jede einzelne Webseite, womöglich jede Ressource insgesamt, ein Neuladen der Signaturdatei nach sich zieht.
Fazit: Für CMS mag diese Variante Einschränkungen mit sich bringen, aber den Ansatz, diese durch dynamisches Signieren zu unterlaufen, kann man vergessen.
Man könnte es den Nutzern einer Seite erleichtern, den Webmaster auf Fehler (also v.a. fehlende Signaturen) hinzuweisen, indem in der Signatur die Kontaktadressen dafür vermerkt werden. Das sollte man nicht nur per E-Mail, sondern auch über ein "internes Formular" des Add-ons machen können, das dieses auch gleich selber ausfüllt, so dass der Nutzer nur noch Benachrichtigen: ja/nein?
anklicken muss. In dem Formular wären dann die URL der Seite, ggf. die abweichende URL des Objekts, der Hash des Objekts und – um der Versionierung der Signaturdatei Rechnung zu tragen – auch der Hash der Signaturdatei enthalten.
Manchmal bindet man externe Inhalte ein, die man nicht alle vorher prüfen kann. Das beste Beispiel sind Werbebanner. Natürlich haben weder die Webmaster noch die Werbetreibenden ein Interesse an einem System, das als Nebeneffekt die Werbung ausblendet (weil sie nicht signiert ist).
ein spezieller, besonders schwieriger Spezialfall externer Inhalte sind Daten (also vor allem Dateien: Bilder, Videos), die von den Usern eines Webdienstes bereitgestellt werden. Die können naturgemäß nicht vom Betreiber erfasst werden. Und sie von den Usern signieren zu lassen, ist aus formalen Gründen heikel: Privatleute haben im allgemeinen nicht die Infrastruktur, um die Signaturerzeugung von ihrem Arbeitsrechner zu trennen. Ein kompromittierter Rechner bedeutet damit automatisch, dass die Integrität des Schlüssels zumindest gefährdet ist. Es sollte also in den Schlüsseln vermerkt werden, welchen "Status" der Schlüssel hat (ähnlich den Nutzungsbeschränkungen in X.509-Zertifikaten), damit der Browserbenutzer sein Add-on entsprechend konfigurieren kann (private Inhalte ignorieren, akzeptieren, davor warnen – wie auch immer). Der Webserverbetreiber könnte allerdings das Alter der Datei garantieren. Je älter eine Datei, desto besser stehen die Chancen für einen (aktuellen) Virenscanner, falls sie kompromittiert ist, und für die angegriffene Anwendung, bereits gepatcht zu sein. Der Browserbenutzer könnte also Warnungen auf neue Inhalte beschränken. Davon gibt es zwar immer noch mehr als genug, aber so haben die User wenigstens die Wahl. Man könnte von geeigneten Anbietern auch das Alter seines gesamten (öffentlichkeitsrelevanten) Bilder-/Dateibestands bestätigen lassen, so dass eine gerade hochgeladene Datei nicht alleine deswegen als neu gilt, wenn sie nachweislich schon lange unverändert existiert.
Ziel dieser Technik ist nicht nur, Sicherheit für einen Teil der Inhalte des Web zu "garantieren", sondern auch, die – zwangsläufig – unsicheren Inhalte in ihrer Wirkung zu beschränken. Deshalb ist es sinnvoll, den Betreibern von Webseiten mit (kritischen) Userinhalten die Möglichkeit zu geben, in ihrer Signaturdatei Einschränkungen dafür vorzunehmen, wo Userinhalte auftauchen können. Wenn Schadsoftware sich schnell verbreiten soll, dann kommen dafür nur Webseiten (nicht im Sinne von Domain, sondern im Sinne von konkreter URL) in Frage, die sehr oft aufgerufen werden. Wenn es einem Angreifer gelingt, eine populäre Webseite zu knacken, dann ist möglicherweise einiges gewonnen, wenn ihn eine Begrenzung davon abhält, die Inhalte auf der Startseite zu manipulieren. Auch die Seiten, auf denen die User ihre Zugangsdaten eingeben, mag man auf diese Weise schützen. Dasselbe Prinzip kann man auf externe Signaturen (von vertrauenswürdigen Webseiten) anwenden. Diese Inhalte sind zwar im Prinzip sicher, aber auf Loginseiten u.Ä. will man sie wohl doch nicht haben. Dabei sollte man mit regulären Ausdrücken (mit implizitem ^ als Stringanfang) arbeiten, um flexibel zu sein.
deny_user_files : / deny_user_urls : / deny_user_code : / deny_external_files : /login.* deny_external_urls : /login.* deny_external_code : /login.* allow_user_files : /user allow_user_urls : /user allow_user_code : /user
Die Signatur allein ist natürlich wertlos, wenn die Authezität des Schlüssels nicht gesichert ist. Die könnte durch ein web of trust der Webseitenbetreiber geleistet werden. Jeder signiert fünf andere Betreiber ähnlicher Bedeutung und zehn kleinere. Ideal für die "erste Ebene" sind Unternehmen, die auch per Papier mit ihren Kunden kommunizieren: Zeitungen, Zeitschriften und Rechnungen können dann mit dem Hash des jeweiligen Schlüssels versehen werden. Das sollte hinreichend sicher sein.
Jeder Webseitenbetreiber sollte in der Signaturdatei für seine eigenen Seiten oder (zur Trafficreduktion) unter einer von mehreren festlegenten Adressen (innerhalb seiner Domain, also Pfad oder Subdomain) angeben, welche Keyserver seine "revocation list" füren, also die Liste seiner Signaturen für andere Schlüssel, die er zurückgezogen hat. Das Prüf-Add-on sollte solche Signaturen nicht anerkennen, zu deren Aussteller kein solcher Keyserver gefunden wird. Wenn man ein System dieser Art einfürt, dann sollte es von Anfang an Brauchbar sein und das CRL-Desaster bei SSL/X.509 nicht wiederholen.
Eine sinnvolle Ergänzung dieser Technik wäre, dass das Add-on sich merkt, für welche Webseiten es schon einmal so eine Sicherungsdatei gefunden hat, denn ansonsten müsste der Angreifer sie nur löschen, um jedweden Hinweis zu unterbinden – denn natürlich werden die meisten Seiten dieses System nicht verwenden (wie heute schon SSL), was kein konkreter Grund für Misstrauen ist.
Die dynamische Erzeugung von Javascript-Code ist ein Problem für diesen Ansatz. Lösen lässt es sich vermutlich über die Kombination aus Hashwerten (für die statischen Blöcke des Codes) und regulären Ausdrücken. Wegen der Performanceprobleme komplexer regulärer Ausdrücke sollten die dynamischen Teile klein gehalten werden. Sinnvoll ist vermutlich auch, nicht den ganzen Ausdruck auf einen mehrzeiligen Codeblock anzuwenden, sondern immer nur zeilenweise den jeweiligen Abschnitt des Ausdrucks auf den Code anzuwenden. Wegen der unterschiedlichen Konventionen bezüglich der Zeilenumbrüche ist außerdem zu überlegen, wie man diese handhabt (vor allem innerhalb der regulären Ausdrücke). Die benutzerfreundlichste Lösung wäre wohl, dass der Browser jeweils alle drei Varianten prüft.
Ziemlich unerfreulich ist das Problem, dass der dynamische Code unterschiedlich lang sein kann. Man hat zwar einen regulären Ausdruck, aber woher soll man wissen, auf wie viele Folgezeichen man den anwenden soll? Die einfachste Lösung ist, den dynamischen Code auf eine feste Länge zu zwingen und mit Füllzeichen auf die richtige Länge zu bringen. Das bringt den wohl überschaubaren Nachteil mit sich, dass man nicht jeden vorgegebenen Code darauf abbilden kann. Problematisch würde das nur, wenn man nicht beeinflussen kann, was für Code generiert wird. In dem Fall weiß man aber wohl sowieso nicht, was für Varianten des Codes auftreten können.
Man muss die Hashwerte mit zusätzlichen Informationen versehen, um Codeblöcke mit dynamischen Teilen sinnvoll bearbeiten zu können:
Bezugsobjekt
u: URL
f: Datei (z.B. Bild, aber auch eingebundene Javascript-Dateien)
c: Javascript-Code innerhalb der HTML-Datei (im Header oder im Body)
Hashtyp
l: unveränderter Text (die URL, der Code) bei kurzen Elementen
r: regulärer Ausdruck
Name der Hashfunktion
Länge des Blocks
(int) >0: Länge in Byte (könnte bei regulären Ausdrücken auch die maximale Länge sein)
Bei URLs und Dateien ist die Längenangabe nicht erforderlich, beschleunigt aber möglicherweise das Auffinden des passenden Hashs (wenn sehr viele vorhanden sind).
Wenn ein Codeblock dynamische Elemente enthält, dann sollten die zusammengehörigen Hashwerte und regulären Ausdrücke geklammert werden.
function foo () {
var init = "123" ;
alert (init) ;
}
wird abgebildet auf
(
c:sha1:18:2746be9a1972dd2bf1afab1b0412981bc38b24c5
c:r:24: var init = "[1-9][0-9]*" *;
c:sha1:19:81d06b71307b11a9e4ca95672c3c331aaf250e7f
)
oder auf
(
c:l:18:function foo () {
c:r:24: var init = "[1-9][0-9]*" *;
c:l:17: alert (init) ;
c:l:2:}
)
Über die Summe der Einzellängen in den geklammerten Komponenten kann zumeist direkt der zu einem Codeblock passende Klammerausdruck gefunden werden, da die Codeblöcke nur selten dieselbe Länge haben.
Reguläre Ausdrücke sind natürlich kein Allheilmittel. Sie eignen sich nur dann als Mittel zur Erhöhung der Sicherheit, wenn sie vernünftig eingesetzt werden. Ob ein Webmaster dazu gewillt und in der Lage ist, kann die Technik nicht wissen. Man kann allenfalls die Information ins web of trust einfließen lassen, inwieweit der Signierende sich von den diesbezüglichen Fähigkeiten des Signierten überzeugt hat. Das garantiert natürlich nicht, dass nie schlampig gearbeitet wird.
Man sollte aber Ausdrücke verbieten, die niemals akzeptabel sind. Das ist auf jeden Fall .*
. Je mehr man verbietet, desto besser ist man gegen Fehler geschützt; aber man verkompliziert damit möglicherweise Konfigurationen. Was genau gefährlich ist, hängt zudem von der Scriptsprache ab, wobei man sich auf Javascript beschränken könnte. Zwingend dynamisch müssen wohl nur Variablenbelegungen sein. Entscheidend ist, dass ein Angreifer da, wo der Webmaster nur einen Wert vorgesehen hat, nichts anderes einschleusen kann. Es sollte deshalb verhindert werden, dass die Trennzeichen der Sprache (also vor allem "
, ' und
) willkürlich verwenden werden können, also etwa unmaskiert. Um das zu vereinfachen, könnte man festlegen, dass die Begrenzungszeichen – "
, ' – Bestandteil des regulären Ausdrucks (also erstes und letztes Zeichen, abgesehen von Füllzeichen davor und dahinter) sein müssen. Wenn sie fehlen, sollten nur noch reguläre Ausdrücke für Zahlen und Literale (true
usw.) erlaubt sein.
Ausnutzen alter Fehlkonfigurationen: Gültigkeit der Datei begrenzen
effizientes Löschen alter Hashes
kann so was passieren? Etwa bei Festlegung einer Datenbank auf einen Zeichensatz?
Schlüsselrevoke; automatisches Signieren auf dem Redaktionssystem; Upload-Proxy
automatische Meldung von Fehlern, also nicht signierten Elementen; am besten an einen anderen Webserver
keine Leserechte für httpd
neue Bilder usw. durch Javascript
sehr viele kleine Bilder
Tools
Abfrage der Signaturateien; Trennung von Eingabe und Ausgabe (unterschiedliche Rechner)
Abfrage der Signaturateien; Trennung von Eingabe und Ausgabe (unterschiedliche Rechner)
Wenn signierter Input von vielen Usern kommt, hat man am Ende tausende von Signaturdateien. Die kann der Browser nicht alle präventiv einlesen. Deshalb sollte es eine Art Index geben, eine Liste aller Hashes, zu denen dann aufgeführt ist, in welcher Datei sie stehen, so dass diese gezielt gelesen werden kann.
Mit kritischem Aufwand ist nur die Entwicklung der Browser-Add-ons verbunden. Die Chancen stehen also am Besten, wenn sich dafür ein Sponsor findet.
Langfristig ist der Aufwand, den dieses System mit sich bringt, gering, weil dann nur noch neue Inhalte entsprechend qualifiziert werden müssen. Code ändert sich selten, und bei Fotos, Grafiken, Videos, Animationen usw. können die Ersteller die Signatur gleich mitliefern, sobald sie die Datei in die Welt setzen. Dieser Aufwand ist vernachlässigbar.
Der große Vorteil dieses System ist, dass es im Kern nicht zu überlisten ist. Ein Angreifer müsste entweder eine Sicherheitslücke über ungesicherte Elemente (Text, CSS) oder in dem Prüf-Add-on selber ausnutzen oder aber den jeweiligen Schlüssel kapern.
Damit bietet das System nicht nur einen statistische Schutz wie etwa die Virenscanner, der doch sehr weit von 100% entfernt ist, sondern tatsächlich Sicherheit, die diesen Namen verdient. Auch gegen zero day exploits.
Das System hat den Nachteil, dass alle mitmachen müssen, damit es lückenlos greift. Den "relevanten" Teil des Web könnte man damit wohl abdecken, und bei bestimmten Webseiten erschiene es albern, technische Garantien für die Inhalte zu erwarten. Die Kriminellen müssen ja auch irgendwovon leben, und der User wird es immer schaffen, sich in den Fuß zu schießen, wenn er das unbedingt will.
Naheliegende oder bereits vorgebrachte Einwände:
Sollte sich so ein System auf breiter Front durchsetzen, könnte es dazu beitragen, Webseiten von Spammern zu identifizieren, weil die (bzw. deren Autoren) eben keine Signaturen von anderen bekommen. Soweit die Theorie. Aber diejenigen, die Spammer signieren, würden schnell identifiziert und isoliert.
Wenn in Ihrem Browser Javascript aktiviert ist, können Sie die Änderungen von Version zu Version farblich markieren lassen, um sie schneller zu finden.
komplett überarbeitet