Ein Blick auf die von Cloudflare per AI geschriebene OAuth-Bibliothek

• Cloudflare hat unter Nutzung von Anthropics Claude LLM eine neue OAuth-Bibliothek entwickelt und auch die Prompts dazu veröffentlicht
• Die Codestruktur der Bibliothek ist sauber, weist aber deutliche Schwächen bei Tests und Sicherheitsvalidierung auf
• Bei CORS und der Implementierung einiger Authentifizierungsstandards wurden nicht standardkonforme oder riskante Entscheidungen gefunden
• Die kryptografische Implementierung hat zwar Stärken, offenbart aber schwerwiegende Sicherheitsbugs und Missverständnisse beim Protokoll
• LLM-basiertes automatisches Coding kann hilfreich sein, doch für Sicherheit auf Produktionsniveau ist eine gründliche Prüfung durch Expert:innen unverzichtbar

---

Überblick über die Cloudflare-OAuth-Bibliothek

• Cloudflare hat die OAuth-Provider-Bibliothek mithilfe von Anthropics Claude LLM größtenteils automatisch schreiben lassen
• Die Ausgaben von Claude wurden von erfahrenen Cloudflare-Ingenieur:innen auf Sicherheit und Standardkonformität geprüft, und im Commit-Verlauf wurde der Interaktionsprozess mit der AI transparent offengelegt
• Nach der ersten Implementierung wurde die Qualität durch zusätzliche Prompts an Claude und die Prüfung der Ergebnisse weiter verbessert
• Es wird ausdrücklich betont, dass man sich nicht nur auf AI verlässt, sondern mit RFC-Dokumenten gegenprüft und Schlüsselstellen von Expert:innen reviewen lässt

Erster Eindruck der Expert:innen und Codeanalyse

• Wie bei LLM-generiertem Code typisch, ist der Code in einer einzigen Datei konzentriert, die Struktur ist jedoch konsistent und enthält vergleichsweise wenig überflüssige Kommentare
• Es gibt Funktionstests, doch sie erreichen nicht das Niveau, das für kritische Authentifizierungsdienste wie OAuth erforderlich ist
  • An einigen Stellen fehlen Prüfungen auf obligatorische Spezifikationen (MUST/MUST NOT), außerdem wirken Parameterprüfungen zu schwach

Sicherheitsbedenken und Erläuterung des Übersetzers

1. Problem mit der CORS-Richtlinie ("YOLO CORS")

• Es wurde eine CORS-Header-Konfiguration gefunden, die fast alle Origins erlaubt und damit die Same-Origin-Policy faktisch aufhebt
• Dieser Teil wurde von einem Cloudflare-Ingenieur direkt von Hand entschieden und nicht vom LLM
• Da die Credentials-Funktion nicht aktiviert ist, ist die unmittelbare Browser-Sicherheitsgefahr begrenzt, doch Klarheit über Ursache und Zweck fehlt

2. Standard-Sicherheitsheader werden nicht angewendet

• In HTTP-Antworten fehlen X-Content-Type-Options: nosniff sowie HTTP Strict Transport Security und andere zentrale Sicherheitsheader
• Aufgrund der Natur einer JSON-API mag die Notwendigkeit einiger Header geringer erscheinen, für den Schutz vor Client-/Browser-Schwachstellen ist ihre Anwendung aber weiterhin wichtig

3. Spuren mangelnder Vertrautheit mit dem OAuth-Standard

• Zur Unterstützung von Public Clients wurde der in OAuth 2.1 abgeschaffte Implicit-Grant-Flow implementiert
  • Tatsächlich ließe sich diese Funktion ausreichend durch PKCE oder gelockerte CORS-Regeln ersetzen
  • Claude scheint den Implicit Grant empfohlen zu haben, validiert ihn in der eigentlichen Token-Ausgabephase jedoch nicht korrekt
• Unzureichende Basic-Auth-Verarbeitung: In OAuth ist eine spezielle URL-Codierung erforderlich, die hier ausgelassen wurde
  • Das ist ein sekundäres Sicherheitsproblem, das auftreten kann, wenn das Client-Secret einen Doppelpunkt enthält
  • Allerdings generiert diese Bibliothek Client-ID und Secret selbst, sodass das Format kontrolliert werden kann

4. Sicherheitsproblem im Code zur Erzeugung von Token-IDs

• Die Methode zur Erzeugung zufälliger Zeichenketten für Token-IDs weist eine statistische Verzerrung (bias) auf
  • Dadurch sinkt die Entropie und Angriffe könnten erleichtert werden, auch wenn die praktische Bedrohung begrenzt ist
• Anders als die Behauptung, „jede Codezeile sei von Expert:innen geprüft worden“, war der Bug bereits im ersten Commit unverändert vorhanden
  • Auch die Historie, dass ein Entwickler am ersten Tag 21-mal direkt in den Main-Branch commitete, deutet auf fehlendes systematisches Review hin

Kryptografische Funktionen und Beispiele für die Zusammenarbeit mit dem LLM

• Das Design zur Verschlüsselung des Token-Stores wurde von Menschen vorgegeben, die Implementierung dabei von Claude unterstützt
• Verwendet wird ein Ansatz, bei dem die Props pro Token verschlüsselt und für jedes Token ein symmetrischer Schlüssel gewrappt wird
• Als Claude zwischendurch ein fehlerhaftes Design vorschlug, korrigierte der Ingenieur dies, indem er Zielsetzung und Sicherheitsabsicht klar formulierte
  • Beispiel: Nach dem Hinweis auf die Schwachstelle, die entsteht, wenn ein SHA-256-Hash als Wrapping-Key verwendet wird, wurde auf eine HMAC-basierte Lösung umgestellt
  • Bei dem Vorschlag, PBKDF2 zu verwenden, wurde auf die Performance-Ineffizienz hingewiesen und stattdessen ein 32-Byte-HMAC-Schlüssel gewählt
• Dieser Prozess zeigt gut, dass für die Arbeit mit AI ein hohes Maß an Domänenwissen erforderlich ist
  • Kritische Mängel wären für Nichtfachleute womöglich nicht einmal erkennbar

Gesamtfazit und Implikationen

• Obwohl es sich um eine erste Version handelt, ist der Reifegrad solide, für den direkten Einsatz in einem Produktivservice ist das Risiko jedoch zu hoch
• Die Entwicklung eines OAuth-Providers erfordert grundsätzlich äußerst anspruchsvolle Sicherheits- und Funktionsvalidierung
  • Bei großen Unternehmen sind Hunderttausende automatisierte Tests und mehrschichtige Sicherheitsprüfungen üblich
  • Es ist kein Bereich, in dem sich LLM-basiertes automatisches Coding „einfach so“ anwenden lässt
• Der Commit-Verlauf des Projekts zeigt auf interessante Weise, bis zu welchem Grad ein LLM unterstützend arbeiten kann
  • Einige Mängel sind allerdings Fehler, die sowohl LLMs als auch Menschen häufig machen; ähnliche Probleme finden sich auch in bestehenden Community-Antworten wie auf Stack Overflow
  • In Codebereichen, in denen Sorgfalt und Genauigkeit entscheidend sind, brauchen AI und Menschen gleichermaßen höchste Aufmerksamkeit
• Wer Code mithilfe eines LLM prüfen oder dessen Ergebnisse vertrauen will, braucht eigene Implementierungserfahrung und System-2-Denken
  • Einfache oder nicht kritische Aufgaben lassen sich durchaus an LLMs delegieren, doch bei Authentifizierung und sicherheitsrelevanten Kernsystemen sind von Expert:innen geführtes Design und Implementierung vorzuziehen

[xguru]

Cloudflares mit KI geschriebenes OAuth-Framework ansehen

[GN⁺]

Hacker-News-Kommentare

• Dieser Fall zeigt sehr direkt, dass man für die Interaktion mit LLMs viel Domänenwissen braucht. Ein normaler Entwickler hätte den von Claude zwischendurch erfundenen „kritischen Fehler“ zum Beispiel vielleicht gar nicht bemerkt. Auch dass die Umstellung auf PBKDF2 seltsam wirkt, erkennt man nur dank fachlicher Expertise. Mein Fazit ist: Um LLMs effizient zu nutzen, braucht man einen fähigen Reviewer und einen „Lead“. Wenn man über das Thema nicht mindestens so viel weiß wie das LLM, sollte der Einsatz zwingend nur wenig Gewicht haben oder man muss genügend Zeit haben, um jede Ausgabe zu verifizieren

  • Ich frage mich, wo in dieser neuen Umgebung künftig solche Domänenexperten herkommen sollen. Wer wird am Ende überhaupt noch so tiefes Wissen aufbauen können?

  • Ich finde es immer seltsam, wenn Leute sagen: „LLMs nutzt man nur in Bereichen, die man nicht gut kennt; Experten schreiben den Code selbst.“ Eigentlich gilt doch eher das Gegenteil: Gerade Experten können die Ausgaben eines LLMs viel präziser prüfen, und je näher ich meine Wünsche in der Sprache eines Domänenexperten formulieren kann, desto besser wird das Ergebnis. Eigentlich ist das selbstverständlich, weil ein LLM nun einmal eine statistisch erzeugende Textmaschine ist

  • LLMs neigen stark dazu, Default-Werte, Exception-Handling und allerlei Workarounds allzu leicht einzubauen. Dadurch entsteht schnell Code, der scheinbar funktioniert, in Wirklichkeit aber Probleme hat oder bald scheitern wird. Ich habe in meiner CLAUDE.md mehrfach versucht, genau das zu betonen, und trotzdem kommt so etwas oft weiter heraus

  • Ich habe den Großteil meiner k8s-Deployments mit einem LLM erledigt. Es liefert schnell etwas Lauffähiges, aber ich musste es ständig daran erinnern, immer Secrets zu verwenden und keine Zugangsdaten im Klartext zu committen. Solche Fehler sind wirklich gefährlich. In Lern-Tutorials wird Sicherheit oft weggelassen, um sich auf die Grundlagen zu konzentrieren, und weil es davon so viele Beispiele in den Trainingsdaten gibt, scheint das LLM solche Ausgaben zu produzieren

  • Mit der Zeit werden AI-Coding-Tools Domänenwissen vermutlich selbst recherchieren können. Einige bereits erschienene „AI-Research“-Tools sind darin schon sehr stark, aber noch nicht sauber in Coding-Tools integriert. Solche Recherche könnte nicht nur das öffentliche Internet, sondern auch internes Firmenwissen aus Dokumentationen einbeziehen. Ein Teil des Wissens steckt allerdings nur in den Köpfen von Menschen und muss deshalb vom Nutzer direkt vermittelt werden

• Ich habe kürzlich mit Hilfe von AI einen Kafka-Consumer geschrieben und damit eine Datenmigration durchgeführt. Für so ein kurzfristiges, von Grund auf neu geschriebenes Projekt war der Nutzen von AI maximal: Ich kenne die Sprache (Go) ziemlich gut, hatte sie aber länger nicht benutzt. Alle Daten kamen in ein einziges Topic, und für genügend Performance musste ich recht komplexe Parallelisierung umsetzen. Insgesamt hatte ich den Eindruck, mit AI ungefähr doppelt so schnell gewesen zu sein. Besonders hilfreich war, dass ich gelegentlich vergessene Go-Syntax direkt bei der AI nachfragen konnte statt zu googeln. Allerdings steckten mindestens vier potenzielle Bugs darin, dazu noch deutlich mehr offensichtliche Fehler. Ohne Erfahrung mit Kafka oder Multithreading hätte ich das vermutlich direkt in Produktion gebracht. Bei großen oder langfristigen Projekten sehe ich eher Verbesserungen im Bereich von 10 bis 20 Prozent. So fühlt es sich mit den aktuellen Modellen an. Insgesamt erinnert mich das an den Produktivitätsschub beim Wechsel zu Speicher-verwalteten Sprachen. Mit der Vorstellung, dass PMs Entwickler ersetzen, hat das nichts zu tun, jedenfalls nicht nach dem Entwicklungstempo der letzten drei Jahre. Meine eigentliche Sorge ist eher, dass Entwickler auf mittlerem Niveau mit „10x“-Techniksturm-Energie durch AI zehnmal effizienter werden, aber subtile Bugs dann nicht finden oder handhaben können und dadurch gefährlicher werden. Senior- oder Staff-Engineers werden die Review-Flut kaum bewältigen können. Und ich frage mich auch, ob der Weg vom Junior zum Senior dadurch fragiler wird. Copy-paste-Programmierer sind schon jetzt ein Problem, und AI verstärkt dieses Muster noch. Am Ende wird der Markt das wohl regeln, aber es macht mir Sorgen, dass das Jahrzehnte dauern könnte

  • Die Bugs, die AI erzeugt, sind wirklich tückisch. Ich habe AI selbst Multithread-Code schreiben lassen und dadurch tatsächlich subtile Bugs in Produktion gebracht. Selbst mit Review und Tests erreicht man nicht dieselbe Konzentration wie bei Code, den man eigenhändig geschrieben hat. Vorerst sollte AI-generierter Code wohl nur dort eingesetzt werden, wo man typische Fehler vorab gezielt prüfen kann und wo ein Ausfall keine katastrophalen Folgen hat

  • Ich spüre bei „wichtiger Arbeit“ ebenfalls eher 10 bis 20 Prozent Verbesserung. Das ist schon eine echte Veränderung, aber es verändert nicht das Wesen der Softwareentwicklung. Am Ende bestätigt es nur wieder Brooks’ „No Silver Bullet“

  • Ich stimme dem Punkt mit dem „mittelstufigen Techniksturm“ ebenfalls zu. Gerade im Consulting werden Veteranen oft als zu teuer für ihren Gegenwert angesehen. Früher war ich selbst eher derjenige, der schnell liefert, und später musste ich viel Energie darauf verwenden, nicht-technischen PMs die Schwächen kurzfristiger Lösungen zu erklären. Große Tech-Konzerne werden solche Probleme schnell erkennen, aber in der Realität wird Code für Finanz- oder Gesundheitsdaten oft von billigen Kurzzeitkräften geschrieben. Das war schon vor den LLMs problematisch. Für sicherheitssensible Entwickler dürfte diese Zeit jetzt noch viel härter sein

  • Du sagst, du hättest subtile Bugs in generiertem Code gefunden; da frage ich mich, wie es wäre, wenn man solche Fehler automatisch mit ebenfalls AI-generiertem Testcode entdeckt. Natürlich kann auch Testcode Bugs haben, aber ich kann mir ein Szenario vorstellen, in dem wir künftig weniger den generierten Code selbst prüfen und uns stärker auf die Testergebnisse konzentrieren

  • Du hast von komplexer Parallelisierung gesprochen, aber wäre das nicht ein Bereich, den man mit Partitions und Consumer-Groups lösen könnte?

• Wenn ich sehe, wie Leute LLMs aktiv vertrauen und sich ihnen geradezu „wie von einer Klippe stürzend“ unkritisch ausliefern, wird mir richtig unwohl. Komplett von einer Blackbox abhängig zu sein und ihr sowohl die Arbeit als auch die Verifikation zu überlassen, ist gefährlich. Außerdem verbraucht das Ganze enorme Energie und wird dann noch als Vorwand benutzt, um Menschen zu ersetzen. Dass so eine Umgebung das Leben zehnmal besser machen soll, fällt mir ehrlich gesagt schwer zu glauben

• Wenn man selbst entwickelten Code mit der Prüfung von Ergebnissen anderer vergleicht, insbesondere von LLM-generiertem Code, dann lassen sich Menschen oft von einer plausiblen Oberfläche täuschen und akzeptieren Probleme weniger kritisch. Auch die „Optik“ von Code beeinflusst stark, wie gut man Bugs findet. Um das zu prüfen, könnte man absichtlich Fehler in Code einbauen und dann experimentell untersuchen, ob Reviewer sie entdecken. Wenn man etwas selbst von Hand implementiert, denkt man viel langsamer und sorgfältiger und achtet stärker auf Details, wodurch man auch unerwartete Bugs entdeckt. Deshalb wird für Lernzwecke oft empfohlen, Tools einmal selbst in einer „Toy-Version“ nachzubauen. Das hängt mit der menschlichen Kognitionsstruktur zusammen

  • Die Fähigkeit, subtile Bugs in oberflächlich sauber wirkendem Code zu finden, kommt aus dem Zynismus und Misstrauen, die man durch viel Review-Erfahrung entwickelt. Weil ich selbst sehr viel Zeit mit Reviews verbracht habe, gehe ich inzwischen bei jedem Code automatisch von potenziellen Problemen aus. Ob mein eigener Code weniger Bugs gehabt hätte, weiß ich nicht; ich habe auch selbst schon genug dumme Fehler gemacht. Wahrscheinlich hätte ich diese Library ohnehin nicht selbst benutzt, weil ich zu viel anderes zu tun habe und so etwas meist bei Junior-Engineers landet. Sicher bin ich mir nur in einem Punkt: Auch von Menschen geschriebener Code ist nicht bugfrei. Viele der Bugs, die Claude produziert hat, sind eher typische Fehler, die Menschen ebenfalls problemlos machen würden. Gleichzeitig glaube ich derzeit nicht, dass Entwickler bei Cloudflare wegen LLMs ersetzt werden. Ob mehr Leute eingestellt werden, hängt nicht von der Menge der Arbeit, sondern vom Budget ab. Wenn LLMs die Produktivität erhöhen, kann das den Umsatz steigern und damit auch mehr Einstellungen ermöglichen. (Das ist natürlich meine persönliche Meinung und nicht die offizielle Position des Unternehmens)

• Im Artikel hieß es, es gebe nicht viele unnötige Kommentare, aber im tatsächlichen Code stehen Dinge wie // Get the Origin header from the request, also bedeutungslose Kommentare

  • Solche Kommentare sind für mich ein eindeutiges Zeichen für LLM-Nutzung; sie sagen nichts aus und ich lösche sie immer

  • Für Menschen sind solche Kommentare nutzlos, aber aus Sicht eines LLM könnten natürlichsprachliche Beschreibungen der Funktion des folgenden Codes eine Art Rosetta-Stein sein, der beim Verständnis hilft. Das kostet zwar Tokens, aber ich würde gern einmal testen, ob LLMs Code mit übermäßig vielen Kommentaren tatsächlich besser bearbeiten

  • Ich kann aus Erfahrung sagen, dass Claude extrem oft solche nutzlosen, redundanten Kommentare schreibt

• Ich würde gern ein Experiment sehen, bei dem man einen Code-Branch einfriert und dann AIs gegeneinander antreten lässt: Die eine Seite versucht, Schwachstellen einzubauen und zu verstecken, die andere soll sie finden und beheben. Eine Art Übertragung der Evolution im Schach auf die Softwareentwicklung

• Ich bin tatsächlich der Autor dieser Library, genauer gesagt der Autor des Prompts. Ich bin zwar nicht ganz so sehr OAuth-Experte wie Neil, kenne mich damit aber durchaus aus, und ich war sehr froh, dass er den Code reviewt hat. Beim Thema „YOLO CORS“ gab es ein Missverständnis: Das war kein simpler Anfängerfehler. Diese CORS-Einstellungen waren bewusst und nach reiflicher Überlegung so gewählt. Ich deaktiviere CORS nur bei OAuth-API-Endpunkten (Token-Austausch, Client-Registrierung) und bei API-Endpunkten, die ein OAuth-Bearer-Token erfordern. Diese Endpunkte authentifizieren nicht über Browser-Credentials wie Cookies, deshalb schützt CORS dort aus meiner Sicht nichts Relevantes. Der Kern von CORS ist ein Sicherheitsmechanismus, der verhindert, dass Credentials automatisch angehängt werden; ein Bearer-Token muss der Client jedoch explizit mitsenden und ist daher auch Cross-Origin sicher. Tatsächlich habe ich schon früher mit Autoren der CORS-Spezifikation darüber gestritten und vertreten, dass echte Sicherheit nur mit Bearer-Tokens statt Browser-Credentials erreicht wird. Was die Kritik an der ineffizienten Token-ID-Erzeugung angeht, halte ich das nicht für „kritisch“. Es ist kein Sicherheitsproblem, und der Algorithmus lässt sich später jederzeit ändern. Dass an einem Tag 21 Commits von einer Person in main gelandet sind, liegt daran, dass die Git-Historie umgeschrieben wurde und GitHub die Daten dadurch verzerrt anzeigt. Und danke für das Lob zur Kryptografie-Implementierung. Die stammt nicht von der AI, sondern aus meinen expliziten Designvorgaben

  • Du sagst, du „deaktivierst CORS-Header bei OAuth-APIs“, aber technisch setzt du CORS-Header so, dass die CORS-Regeln deaktiviert werden. Aus dem Kontext wird das klar, aber man kann es missverstehen

  • Ich frage mich, ob Cloudflare plant, diese Library tatsächlich in Produktion einzusetzen

• Mich beunruhigt, dass in beliebten Stack-Overflow-Antworten dieselben Fehler massenhaft vorkommen und Claude so etwas vermutlich genau dort gelernt hat. Nicht einmal die einzelnen Sicherheitslücken oder Fehler machen mir am meisten Angst, sondern dass das gesellschaftliche Wissensniveau durch populäre Internetantworten aus der Zeit vor LLMs eingefroren werden könnte

  • Das beunruhigt mich ebenfalls. Es wäre ein großer Vertrauensgewinn, wenn manche von mir genutzten Services öffentlich erklären würden, dass sie LLMs nicht zum Schreiben von Code einsetzen

• Wenn man sieht, dass es bei OAuth-Implementierungen bei ForgeRock Hunderte Sicherheitsbugs gab und das trotz Hunderttausender automatisierter Tests, Threat Modeling, erstklassigem SAST/DAST und Experten-Reviews, merkt man wieder, wie schwierig OAuth wirklich ist. Manche nennen solche Implementierungen regelrecht einen „Dumpster Fire“. Ich selbst habe die Spezifikation allerdings nie gelesen oder implementiert

  • Jedes Mal, wenn ich in irgendeiner Form mit einer OAuth-Implementierung zu tun hatte, war sie schrecklich komplex

  • OAuth ist wirklich unerquicklich und voller Nischenfälle

  • Neu geschriebener Code hat in Wahrheit immer Bugs, und je komplexer er ist, desto sicherer. Deshalb setzen Unternehmen lieber auf „battle tested“ Code und Tools, die sich bereits im realen Einsatz bewährt haben. Scherz beiseite: Ich finde es interessant, wie Anthropic seine generative AI praktisch für den eigenen Code einsetzt. Ich frage mich, ob das künftig auch für die MCP-Authentifizierungs-API verwendet wird

  • „Hunderttausende Tests“ klingt fast so, als könne das nur quantitatives Wachstum sein oder als wären sie direkt von einem LLM erzeugt worden. Ich frage mich wirklich, wer so etwas am Ende pflegt

• Ich frage mich, ob es zum allgemeinen Trend wird, eigene Prompts in Git zu committen, oder ob das eher Showcase-Charakter hat

  • Ich habe meinen Prompt committet, weil es einfach ein enormer Erkenntnisgewinn war, direkt zu sehen, welche Ergebnisse ein LLM aus genau diesem Prompt erzeugt. Ich dachte, andere würden das ebenfalls interessant finden, und genau so war es. Übrigens wusste ich selbst nicht, wie man Prompts „gut“ schreibt; ich habe einfach ganz natürlich so geschrieben, wie ich es auch für Menschen tun würde, und das schien gut zu funktionieren