
CWE-642
CWE-642 ist die Kennnummer einer bekannten Sicherheitslücken-Art in Software: Ein Programm speichert wichtige Zustandsdaten dort, wo Nutzer sie verändern können, und vertraut ihnen später blind. Typische Folge sind manipulierte Preise, gefälschte Nutzerrollen oder unbezahlte Bestellungen.
CWE-642 ist ein Eintrag in einem öffentlichen Katalog von Programmierfehlern, die zu Sicherheitslücken führen. Dieser Katalog heißt Common Weakness Enumeration, kurz CWE, und wird von der US-Organisation MITRE gepflegt. Jede Fehlerart bekommt dort eine feste Nummer, damit Fachleute weltweit über dasselbe Problem reden können. Die Nummer 642 steht für folgenden Fehler: Ein Programm merkt sich wichtige Informationen an einem Ort, den der Nutzer selbst verändern kann. Später verlässt sich das Programm auf diese Informationen, als wären sie unantastbar. Der englische Titel lautet « External Control of Critical State Data », also externe Kontrolle über kritische Zustandsdaten.
Mit Zustandsdaten sind Angaben gemeint, die sich ein Programm zwischen zwei Schritten merken muss. Wer gerade eingeloggt ist, was im Warenkorb liegt, ob jemand Administrator ist. Wenn diese Angaben im Browser des Nutzers landen statt auf dem Server des Anbieters, kann der Nutzer sie umschreiben. Genau das beschreibt CWE-642.
Warum ein Preis von 1 Euro plötzlich echt aussieht
Der klassische Fall ist ein Online-Shop, der den Preis eines Artikels in einem versteckten Formularfeld mitschickt. Wer die Seite mit den Entwicklerwerkzeugen des Browsers öffnet, kann aus 899 Euro eine 1 machen. Schickt der Shop diesen Wert ungeprüft an die Bezahlung weiter, ist der Schaden real. Solche Fehler wurden in echten Shops immer wieder gefunden, auch bei großen Anbietern.
Noch schwerer wiegt der Fall bei Berechtigungen. Speichert eine Anwendung im Browser ein Datenfeld mit dem Inhalt « rolle=nutzer », genügt oft eine Änderung zu « rolle=admin ». Der Angreifer braucht dafür kein Passwort und keine besonderen Werkzeuge. Er muss nur Daten verändern, die ihm ohnehin gehören.
Wichtig ist die Abgrenzung zu Lücken, bei denen jemand von außen eindringt. Bei CWE-642 bricht niemand ein. Das Programm hat dem Nutzer die Schlüssel freiwillig in die Hand gedrückt und hofft, dass er sie nicht benutzt. Deshalb gilt die Schwachstelle als Denkfehler im Entwurf, nicht als Tippfehler im Code.
Vertrauen an der falschen Stelle
Webanwendungen sind auf zwei Seiten verteilt. Ein Teil läuft auf dem Server des Anbieters, ein Teil im Browser des Nutzers. Nur der Serverteil ist geschützt, der Browserteil gehört faktisch dem Nutzer. Alles, was dorthin geschickt wird, ist veränderbar: Formularfelder, Cookies, Adresszeilen, versteckte Parameter.
Entwickler lagern Zustandsdaten trotzdem gern in den Browser aus, weil es Serverspeicher spart und die Anwendung einfacher macht. Der Fehler entsteht im nächsten Schritt: Die zurückkommenden Daten werden nicht mehr geprüft. Man kann sich das wie eine Garderobe vorstellen, die keine Nummern vergibt, sondern jeden Gast selbst auf einen Zettel schreiben lässt, welche Jacke ihm gehört.
Die Gegenmaßnahme ist unspektakulär. Kritische Daten bleiben auf dem Server, der Browser bekennt höchstens eine zufällige Kennnummer. Muss man Daten doch nach außen geben, werden sie mit einer kryptografischen Signatur versehen, also einem fälschungssicheren Prüfstempel. Und selbst dann prüft der Server bei jeder Anfrage neu, ob der Nutzer die Aktion überhaupt ausführen darf.
Wo die Nummer in Berichten auftaucht
Begegnen wird man CWE-642 vor allem in Sicherheitsmeldungen. Wenn eine Software-Schwachstelle veröffentlicht wird, bekommt sie eine CVE-Nummer als Einzelfall-Kennung und zusätzlich eine CWE-Nummer für den zugrunde liegenden Fehlertyp. So lässt sich auswerten, welche Fehlerarten besonders häufig sind.
Auch automatische Prüfwerkzeuge nutzen den Katalog. Programme, die Quellcode nach Schwachstellen durchsuchen, melden ihre Funde mit CWE-Nummern. In Firmen landen diese Berichte bei Entwicklungsteams, die danach priorisieren müssen. Für Prüfungen nach Normen wie ISO 27001 oder für Sicherheitstests vor einem Produktstart ist das der übliche Weg.
Ein häufiger Irrtum: Manche halten das Problem für gelöst, weil die Verbindung verschlüsselt ist. Verschlüsselung schützt Daten aber nur auf dem Transportweg gegen Dritte. Gegen den Nutzer selbst, der die Daten vor dem Absenden ändert, hilft sie überhaupt nicht. Auch in modernen Apps und bei Schnittstellen zwischen Programmen tritt CWE-642 deshalb weiterhin regelmäßig auf.