Frage:
Interpolique: Was ist passiert, wenn SQL Injection und XSS mit Base64-Codierung transparent verhindert werden?
Indolering
2012-03-08 04:15:44 UTC
view on stackexchange narkive permalink

Für die Keynote bei The Next HOPE vor ein paar Jahren enthüllte Dan Kaminsky Interpolique (der Vortrag macht übrigens wirklich Spaß). Das Problem, das er ansprach, war die Abwehr von Injection-Angriffen, einschließlich SQL-Injection, Cross-Site-Scripting (XSS) und anderen Injection-Schwachstellen. Zum Beispiel macht Unicode das Entkommen von Zeichen unbrauchbar und vorbereitete Anweisungen sind eine PITA.

Sein Fix bestand darin, Zeichenfolgen während der Übertragung in base64 zu konvertieren. In SQL kann man beispielsweise den SQL-Aufruf einfach mit einem decode64 eval () auffüllen. Es ist viel einfacher als vorbereitete Anweisungen, hat nur geringe (wenn überhaupt) Auswirkungen auf die DB-Leistung, ist für Benutzer der DB transparent und die Implementierung in der Muttersprache könnte die Verwendung für den Programmierer transparent und in Bezug auf die Serverleistung nahezu genauso schnell machen. Ähnliche Techniken können angewendet werden, um sich gegen XSS zu verteidigen. Aber abgesehen von ein paar Blog-Artikeln, die zu dieser Zeit geschrieben wurden, kann ich nirgendwo eine Erwähnung finden.

Was ist passiert?

Beeindruckend. Ich kann das Video bei der Arbeit nicht ansehen, aber wenn ich mir den Code ansehe, bin ich erstaunt, dass Kaminsky jemals gedacht hat, dass dies eine praktikable Idee ist. Sabotiert die Zugänglichkeit und erhöht gleichzeitig die Komplexität, anstatt sie nur richtig zu machen. Die wirkliche Lösung für Injektionsprobleme bleibt wie immer: Verwenden Sie keine Tools mehr, die die Verkettung von Rohstrings fördern. Verwenden Sie eine Bibliothek, die parametrisierte Abfragen vereinfacht. Verwenden Sie eine Vorlagensprache, die standardmäßig HTML-Escapezeichen enthält, und so weiter.
Wenn Sie sich das Video ansehen, lautet seine These, dass Sicherheit mit dem Denken des Programmierers kompatibel sein muss und linear zu der Art und Weise ablaufen muss, wie er über seinen Code denkt. Außerdem drehte er für Programmiersprachenkompatibilität, Java, Perl, PHP usw. - nicht nur für SQL und JS.
Zwei antworten:
D.W.
2012-03-08 12:00:39 UTC
view on stackexchange narkive permalink

Zusammenfassung. Ich würde spekulieren, dass Interpolique aus mehreren Gründen nicht erfolgreich war. Ein wichtiger Grund ist, dass Interpolique möglicherweise nicht genau das richtige Problem gelöst hat, und es gibt eine Reihe anderer ähnlicher Ansätze im Raum mit ähnlichen oder besseren Eigenschaften. Ein weiterer möglicher Grund ist, dass es möglicherweise nicht optimal vermarktet wurde. Ich würde auch spekulieren, dass die Marktnachfrage und die Schwierigkeiten bei der Monetarisierung eine bedeutende Rolle gespielt haben könnten.

Hintergrund. Interpolique ist eine generische Idee zur Abwehr von Injektionsangriffen. Injektionsangriffe sind eine breite Klasse von Sicherheitslücken. Die bekanntesten Beispiele sind SQL-Injection und XSS.

Kaminskys Folien verbringen die meiste Zeit damit, über SQL-Injection zu sprechen, aber ich denke, es wäre ein Fehler anzunehmen, dass es bei Interpolique ausschließlich oder hauptsächlich um SQL-Injection geht. Kaminsky erklärt zunächst Interpolique im Kontext der SQL-Injection-Verteidigung. Nach der Einführung der Grundidee (im Kontext der SQL-Injection) erklärt er dann, wie sie auf XSS- und andere Injection-Angriffe angewendet wird. Ich würde spekulieren, dass er die Diskussion vielleicht so als pädagogisches Mittel gestaltet hat: weil es einfacher ist, die Ideen in einer einfachen Umgebung wie SQL Injection zu erklären, bevor er diskutiert, wie sie sich verallgemeinern.

Es Es ist auch nützlich zu wissen, dass Interpolique ein Schritt in einer Reihe von Arbeiten zur Verteidigung gegen Injektionsangriffe ist. Davor stehen BEEP (das stark beschädigt war) und dann Blueprint (das viele Ähnlichkeiten mit Interpolique aufweist und viele ähnliche Stärken und Schwächen aufweist).

Nicht genau das richtige Problem lösen. Auf der allgemeinsten Ebene versucht Interpolique, das Problem der sicheren Zeichenfolgeninterpolation zu lösen. Dies ist das richtige Problem. Sicherheitsprobleme bei der Zeichenfolgeninterpolation sind für eine Vielzahl von Sicherheitslücken bei der Injektion verantwortlich. Die Neuheit von Interpolique liegt jedoch in dem Teil, der wohl nicht der kritischste Teil ist.

Um das Problem der sicheren Zeichenfolgeninterpolation anzugehen, müssen einige Probleme behoben werden. Wie können wir den nicht vertrauenswürdigen Daten entkommen oder sie verschlüsseln, damit sie nicht aus dem Kontext herausbrechen können, auf den sie beschränkt sein sollen? Wie können wir feststellen, in welchen Kontext die nicht vertrauenswürdigen Daten eingefügt werden? Woher wissen wir, welche Escape- / Codierungsfunktion für diesen Kontext richtig ist? Wie integrieren wir die Lösung in Webanwendungs-Frameworks? Wie schulen wir Entwickler in der Verwendung?

Der neueste Aspekt von Interpolique ist die Methode, mit der nicht vertrauenswürdige Daten codiert werden, damit sie nicht aus ihrem Kontext herausbrechen können. Der Ansatz von Interpolique umfasst die Base64-Codierung, die in der Tat eine elegante und robuste Lösung für das Problem der Codierung von Daten darstellt, damit sie nicht aus ihrem Kontext entkommen können. Dieses Problem ist jedoch nicht das kritischste, das es zu lösen gilt. Die Standardmethode zur Lösung dieses Problems ist die Flucht. Und Escape scheint in der Praxis gut genug zu funktionieren, solange Sie die richtige Escape-Funktion für den Kontext verwenden, in den die nicht vertrauenswürdigen Daten eingefügt werden: z. B. encodeForHTML für Text, der in HTML eingeht, encodeForURL für Daten, die in einen URL-Kontext usw. gelangen. Die Escape-Funktionen sind standardisiert und scheinen ziemlich zuverlässig zu sein.

Es ist also nicht klar, dass Interpolique einen signifikanten Vorteil gegenüber konkurrierenden Ansätzen hat. Seine Neuheit konzentriert sich wohl auf einen der weniger wichtigen Aspekte des Problems. Es ist nicht klar, dass die spezielle Sauce von Interpolique (der Base64-Codierungsteil) den Benutzern einen so großen Vorteil gegenüber anderen möglichen Ansätzen bietet.

Die wichtigste Herausforderung, die angegangen werden muss, scheint die Integration und Reichweite des Frameworks zu sein : Integration dieses Materials in die von Entwicklern verwendeten Webanwendungs-Frameworks und Unterweisung der Entwickler in deren Verwendung. Die Technologie für die kontextsensitive automatische Flucht ist mittlerweile ziemlich gut verstanden, und die größte Herausforderung besteht darin, sie in weit verbreitete Frameworks zu integrieren.

Leider habe ich bei Interpolique keine großen Anstrengungen unternommen Projekt. Dies erfordert viel Fett für den Ellenbogen: Kommunikation mit den Leuten, die die einzelnen Frameworks warten, Formulierung der Vorteile, Schreiben von Code / Patches, um die Ideen in die Frameworks zu integrieren, Zusammenarbeit mit ihnen, um für sie akzeptable Lösungen zu entwickeln usw. I. Ich weiß nicht, ob das Interpolique-Projekt das wirklich sehr stark vorangetrieben hat.

Marketing. Ich weiß nicht, ob Interpolique auf eine Weise vermarktet wurde, die normale Webanwendungsentwickler verstehen würden seine Vorteile. Die Vorteile sind vielleicht für Sicherheitsforscher offensichtlich, aber für die Leute, die Webanwendungen erstellen, oder für die Leute, die Web-Frameworks pflegen? Nicht so klar.

Kaminskys Folien konzentrieren sich stark auf die SQL-Injection. Während dies aus pädagogischer Sicht sinnvoll sein mag, frage ich mich im Nachhinein, ob es aus kommunikativer Sicht ein taktischer Fehler gewesen sein könnte. Es gibt bereits "gut genug" Lösungen für die SQL-Injection. Der Fokus auf SQL-Injection hat möglicherweise eine Reaktion von einigen Entwicklern ausgelöst, die dachten: "Warum brauche ich dieses Zeug, wenn ich das Gefühl habe, dass ich SQL-Injection bereits einigermaßen unter Kontrolle habe?". Wenn die potenziellen Anwender die Vorteile nicht wahrnehmen, werden sie wahrscheinlich nicht sehr empfänglich für die Technologie sein.

Begrenzte Marktnachfrage. Für die meisten Entwickler Sicherheit ist eine zweitrangige Überlegung. Es ist nicht so einfach, ein Punkteschema zu verkaufen, das einen kleinen Teil der Sicherheit anspricht, wenn Sicherheit nicht ihr primäres Ziel ist. Wenn Sie eine umfassende Suite verkaufen könnten, die alle potenziellen Sicherheitsprobleme löst, könnten Entwickler viel mehr Interesse zeigen - aber das war Interpolique nicht.

Beitrag zu dieser Wahrnehmung, dass Sicherheit keine große Rolle spielt Der Deal ist, dass viele Anwendungsentwickler nicht glauben, dass sie ein Problem haben und keine Notwendigkeit für eine Lösung erkennen (viele von ihnen täuschen sich wahrscheinlich selbst, aber so geht es). Und von den Entwicklern, die XSS kennen kennen, denken viele, dass sie es vermeiden können, indem sie nur vorsichtig sind (das ist eine zweifelhafte Aussage, aber hey, wenn sie die Notwendigkeit eines Schemas nicht erkennen, sind sie es auch Ich werde es nicht kaufen.

Auf jeden Fall ist nicht klar, wie Sie mit so etwas wie Interpolique Geld verdienen würden. Es fällt nicht in eine der üblichen Kategorien. Es ist kein Werkzeug. Es ist kein Dienst. Es ist keine umfassende Sicherheitslösung. Es ist vielmehr eine Idee, wie verschiedene Web-Frameworks verbessert werden können. Um Interpolique in die Hände der Kunden zu bekommen, müssten Sie es in diese Frameworks integrieren. Diese Frameworks sind jedoch normalerweise kostenlos. Ich sehe also nicht ein, wie Sie damit Geld verdienen würden. Wie monetarisieren Sie eine Bibliothek oder eine Idee? Wo ist das Geschäftsmodell? Vielleicht hatten die Interpolique-Leute eine Möglichkeit, Geld zu verdienen, aber ich frage mich, ob ein Teil des mangelnden Erfolgs von Interpolique darin besteht, dass es keinen klaren Weg gab, mit der Idee Geld zu verdienen.

Interpoliques Beitrag: XSS. Kommen wir zurück zu dem, wofür Interpolique gut ist. Persönlich glaube ich, dass sein Hauptbeitrag darin besteht, sich gegen XSS zu verteidigen (möglicherweise auch gegen andere Injektionsangriffe, vor allem aber gegen XSS). Dafür ist es eine ziemlich clevere Technik - obwohl Entwickler immer noch verstehen müssen, wie man sie richtig verwendet, und daran denken, Interpolique überall dort zu verwenden, wo sie nicht vertrauenswürdige Daten in HTML interpolieren. Im Vergleich zu kontextsensitivem automatischem Escaping, das automatisch erfolgt, keine Entwickleraufmerksamkeit erfordert und nicht anfällig für Auslassungsfehler ist, bei denen Entwickler vergessen haben, die Escape-Funktion aufzurufen.

In Kaminskys Vortrag wird erläutert, wie Interpolique zu verwenden, um SQL-Injection zu verhindern, aber ich vermute, dass dies in erster Linie ein pädagogisches Gerät ist. Interpolique ist eine allgemeine Verteidigung gegen Injection-Angriffe, wofür SQL Injection und XSS zwei Beispiele sind. Die SQL-Injection ist einfacher zu verstehen und einfacher zu verstehen als XSS. Daher war es wahrscheinlich einfacher, die Ideen hinter Interpolique im Zusammenhang mit der SQL-Injection zu erklären als bei XSS.

Interpolique und SQL-Injection. Wie andere bereits gesagt haben, sind vorbereitete Anweisungen für praktische Zwecke eine "ausreichend gute" Lösung für die SQL-Injection (es gibt tatsächlich einige Fälle, die nicht von vorbereiteten Anweisungen behandelt werden). Aber sie können wahrscheinlich durch Escape / Validierung und sorgfältige Code-Audits behandelt werden. Daher ist Interpolique hier nicht besonders nützlich.

Mir ist klar, dass vorbereitete Anweisungen einige Einschränkungen aufweisen. Eine Einschränkung, die Dan Kaminsky gut erklärt, ist, dass die Syntax nicht ideal ist, wenn Sie mehrere dynamische Werte in eine lange Vorlage interpolieren: Es ist schwierig zu verfolgen, welcher Parameter wohin geht. In der Praxis scheint dies jedoch kein Showstopper zu sein: Entwickler scheinen damit fertig zu werden. Eine weitere Einschränkung vorbereiteter Anweisungen besteht darin, dass es seltene Fälle gibt, in denen sie nicht angewendet werden können, z. B. dynamische ORDER BY- oder LIMIT-Anweisungen. Keine dieser Einschränkungen scheint jedoch ein ernstes Problem mit vorbereiteten Aussagen in der Praxis zu sein, daher sehe ich Interpolique einfach nicht als viel besser als vorbereitete Aussagen. Und vorbereitete Aussagen haben den Vorteil, dass sie einfach sind, bereits in fast allen Frameworks unterstützt und bereits für Entwickler gut evangelisiert wurden.

Warum kritisierte Kaminsky die Flucht? Hier ist, was los ist. Wenn Sie nicht vertrauenswürdige Daten maskieren möchten, bevor Sie sie in eine Zeichenfolge interpolieren, müssen Sie wissen, wie der Empfänger der Zeichenfolge sie interpretiert, um zu bestimmen, welche Zeichen maskiert werden müssen. Wenn Sie glauben, dass der Empfänger es als ASCII interpretiert, der Empfänger es jedoch als UTF-8 behandelt, haben Sie ein Problem: Sie werden wahrscheinlich nicht alles entkommen, was Sie brauchen.

Diese Art von Dingen hat in der Vergangenheit Schwachstellen in PHP / MySQL-Webanwendungen eingeführt (hier ein weiteres Beispiel), als sie versuchten, nicht vertrauenswürdigen Daten zu entkommen, bevor sie interpoliert wurden eine SQL-Abfrage, aber nicht erkannt, dass die Datenbank eine andere Zeichenkodierung als erwartet verwendet. Dies ist besonders relevant für PHP / MySQL-Webanwendungen, da es keine Integration zwischen der PHP-App und der MySQL-Datenbank gibt: Es gibt keine einfache Möglichkeit für den PHP-Code, festzustellen, welche Zeichencodierung die MySQL-Datenbank für diese Verbindung verwendet Es gibt keine einfache Möglichkeit, festzustellen, welche Escape-Funktion verwendet werden muss.

Manuelles Escape ist daher möglicherweise fehleranfällig, da Entwickler manchmal die falsche Escape-Funktion verwenden, wodurch eine Sicherheitslücke entsteht.

Andererseits können diese Probleme zur XSS-Prävention bei ausreichender Integration in das Webframework behoben werden. Das Framework kann erkennen, in welchem ​​Zeichen das HTML-Dokument codiert ist (weil es die Header Content-Encoding: sendet und auch das HTML-Dokument selbst analysieren kann), und bei ausreichender Intelligenz kann es erkennen In welchen HTML-Kontext wird der nicht vertrauenswürdige Inhalt interpoliert (innerhalb eines HTML-Tags, innerhalb eines Attributs, einer URL usw.). Folglich kann das Framework bei einem ausreichend intelligenten Webframework automatisch bestimmen, welche Escape-Funktion verwendet werden muss, und sie automatisch anwenden. Dies ist die Voraussetzung für kontextsensitive automatische Flucht, und auf diese Weise wird Kaminskys Kritik angesprochen.

Die Zukunft dieses Bereichs. Die Sicherheitstechnologie in diesem Bereich, die am meisten genutzt wurde, ist kontextsensitive automatische Flucht, wie z. B. das in Googles ctemplate implementiert. Ich denke, dies ist die aufregendste und vielversprechendste Richtung für die Zukunft. Ich sehe keine große Geschäftsmöglichkeit, um Geld zu verdienen - aber ich denke, es könnte einen spürbaren Unterschied darin machen, Webanwendungen sicherer zu machen und Entwicklern dabei zu helfen, sichere Probleme zu vermeiden.

Kontextsensitive automatische Das Entkommen beinhaltet Framework-Unterstützung für die automatische Verteidigung gegen XSS , ohne zusätzliche Schritte oder das Bewusstsein des Entwicklers. Das geht einen Schritt über das hinaus, was Interpolique bietet. Folglich ist die kontextsensitive automatische Escape-Funktion für Entwickler sogar noch besser als Interpolique, da sie in den meisten Situationen keinen zusätzlichen Aufwand für Entwickler erfordert: Die Escape-Funktion wird für sie automatisch durchgeführt. Dies ist auch für die Sicherheit besser: Die Flucht erfolgt standardmäßig, sodass Sie ein System erhalten, das standardmäßig sicher ist.

Sie können die Ideen von Interpolique natürlich mit dem Kontext kombinieren -sensitive automatische Escape-Funktion (unter Verwendung der Base64-Codierung von Interpolique anstelle der Standard-Escape-Funktion), obwohl mir die Vorteile nicht ganz klar sind.

In den folgenden Fragen werden Interpolique und ähnliche Technologien beschrieben : Whitelisting von DOM-Elementen, um XSS zu besiegen, Escaping von JavaScript-Konstanten.

Fazit. Ich glaube, Interpolique war eine schöne, Eine elegante Idee, von der ich vermute, dass sie weiterhin Einfluss auf die Zukunft der Entwicklung von Webanwendungen hat - auch wenn sie nicht direkt übernommen wird. Zumindest kann dies im breiteren Kontext des Übergangs zu kontextsensitivem Auto-Escape und anderen Techniken verstanden werden, um Entwicklern dabei zu helfen, häufige Schwachstellen zu vermeiden.

Tolle Resonanz, aber es gibt eine Einschränkung, die die veröffentlichten Folien überspringen: Kaminsky behauptet, dass Unicodes Millionen von Zeichen und das am besten passende Zuordnungsschema das Entkommen von Zeichen unmöglich machen. Was dann? Ich denke nur, die Sprache würde sich selbst darum kümmern: P.
@Indolering Ich denke, das gilt nur, wenn ein Teil Ihrer Pipeline den Text auf dem Weg in eine Legacy-Codierung zerlegt. Ich würde erwarten, dass jede moderne Datenbank nativ in Unicode spricht.
rook
2012-03-08 11:07:23 UTC
view on stackexchange narkive permalink

Oh, großartig, jemand hat einen Weg gefunden, um alle Schwachstellen zu verhindern. Jetzt muss jede Anwendung von Grund auf neu geschrieben werden. Ich würde mich vor einer solchen Behauptung in Acht nehmen.

Lassen Sie uns dieses auseinander nehmen ...

Also wirklich, was ist ein base64? Es ist eine Möglichkeit, Daten binär sicher darzustellen. Sie stellen die Daten in einem begrenzten Zeichensatz dar, um Steuerzeichen wie ', ", \, 0x00 zu vermeiden. Um davon zu profitieren, wird diese Zeichenfolge jederzeit in einer Senke verwendet, z Bei einer SQL-Abfrage muss sie codiert werden, aber es ist nicht sinnvoll, alle Zeichenfolgen als base64 zu behandeln. Andernfalls wäre Ihr Code voller Unsinn und verschwenderischer Ressourcen: if ($ str == base64encode (' start ')) {...} . Okay, warum also nicht eine Desinfektionsfunktion wie addslashes () verwenden? Dies ist auch eine Möglichkeit, Daten binär sicher darzustellen Problem, diese beiden Funktionen sind ein schrecklicher Ansatz für die SQL-Injection, da parametrisierte Abfragen das Problem der SQL-Injection vollständig lösen.

Okay, was ist mit XSS? Nun, um a anzuzeigen Nachricht an den Benutzer es kann nicht base64 sein! . Diese Methode kann also nicht gegen XSS verhindern. Keine einzelne Funktion kann alle XSS verhindern, da XSS ein Ausgabeproblem ist und ist stark abhängig von wo Die Benutzerausgabe befindet sich im HTML-Code.

Allerdings kann base64 ein nützliches Werkzeug zum Codieren von Benutzereingaben sein, die in einer Vielzahl von Senkenfunktionen verwendet werden sollen. einschließlich, aber nicht beschränkt auf Dateivorgänge, Befehlszeilen- und SQL-Abfragen. Dies ist eines von vielen Tools, mit denen Benutzer regelmäßig Fehler in ihrer Anwendung beheben. base64 wird fast nie verwendet, um XSS zu verhindern. Ich habe noch nie gesehen, dass base64 in freier Wildbahn auf diese Weise verwendet wird.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...