Signaturen für kritische WWW-Elemente

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.

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.

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:

1. 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)

2. Hashtyp

   • l: unveränderter Text (die URL, der Code) bei kurzen Elementen

   • r: regulärer Ausdruck

   • Name der Hashfunktion

3. 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)