Ich baue eine kleine tokenbasierte Authentifizierungsbibliothek für meinen (rails-basierten) api-Server, der generierte Token mit redis speichert. Die Zeile, um die ich mir Sorgen mache, ist: user_id = $redis.get("auth:#{token}") , wobei token das ist, was an authenticate_or_request_with_http_token übergeben wird.
Wenn das SQL wäre, wäre das eine riesige rote Flagge - interpolierte String-SQL-Abfragen sind ziemlich unsicher. Soweit ich feststellen kann, ist die String-Interpolation bei einer Redis-Key-Abfrage jedoch nicht unsicher.
Meine Quelle für den obigen Anspruch ist die Redis-Dokumentation hier: Ссылка (unter dem string escaping und nosql injection header), aber ich wollte sicherstellen, dass dies der Fall ist, bevor ich einen Bobby Tables Angriff bekomme.
Die Dokumentation, auf die Sie verweisen, ist ziemlich explizit:
Das Redis-Protokoll hat kein Konzept für das Entkommen von Strings, daher ist eine Injektion unter normalen Umständen mit einer normalen Client-Bibliothek nicht möglich. Das Protokoll verwendet Zeichenfolgen mit fester Länge und ist vollständig binärsicher.
Es gibt einen kleinen Angriffsvektor für diese Art von String-Injektionen. Während die redis-Dokumentation über die Schwierigkeit der Ausführung mehrerer Befehle in der Datenbank klar ist, wird nicht erwähnt, dass das Schlüsseltrennzeichen (':' in Ihrem Beispiel) normalerweise maskiert werden muss, wenn es als Teil eines Schlüssels verwendet wird.
>Ich habe eine Redis-Datenbank mit diesen Schlüsseln gesehen:
oauth_token:123456 (enthält einen Hash der OAuth-Token-Parameter) und oauth_token:123456:is_temp (enthält eine boolesche Eigenschaft, um anzugeben, ob das OAuth-Token ein temporäres Token ist) Wenn Sie der Benutzereingabe vertrauen, ohne zu entkommen, kann GET oauth_token:#{token} versehentlich als GET oauth_token:123456:is_temp enden (wenn token vom Benutzer auf 123456:is_temp gesetzt wurde).
Ich empfehle daher, Doppelpunkte korrekt von potenziellen Benutzereingaben zu entfernen, um sicherzustellen, dass Ihre Schlüsselpfade nicht so ausgetrickst werden können.
HINWEIS: Jemand hat empfohlen, das obige Beispiel mit oauth_token:123456 und oauth_token:is_temp:123456 zu beheben, aber das ist fehlerhaft (für das vom Benutzer bereitgestellte Token is_temp:123456 ). Die richtige Lösung für dieses Problem (ohne zu entkommen) wäre, die Schlüssel oauth_token:info:123456 und oauth_token:is_temp:123456 zu verwenden, um sicherzustellen, dass diese Schlüssel sich nicht mit den vom Benutzer bereitgestellten Eingaben überlappen können (oder einfach Doppelpunkte entfernen).
Grundsätzlich ist Redis immun gegen ausgehende Probleme, wenn die Eingabezeichenfolge wörtlich verwendet wird. Zum Beispiel:
%Vor%Allerdings ist Redis nicht immun gegen Probleme, die durch die Verwendung nicht validierter Eingaben im Zusammenhang mit der String Interpolation entstehen, wie Sven Herzberg gezeigt hat. Um das Sven-Beispiel in ein sicheres Beispiel zu verwandeln, ist es möglich, einfach einen Hash zu verwenden und die Rückkehr zur Interpolation zu vermeiden. Andernfalls verwenden Sie entweder keine gemeinsamen Präfixe, die in Verbindung mit der Schlüsselinterpolation verwendet werden sollen, oder verwenden Sie eine einfache Form der Plausibilitätsprüfung der Eingabe, die das verwendete Trennzeichen wegfiltert oder besser validiert, dass die Eingabe tatsächlich eine Zahl ist Beispiel).
Während Redis nicht unter den typischen Angriffsangriffen von SQL leidet, sollten Sie bei der Verwendung nicht vertrauenswürdiger Eingaben im Kontext einer String-Interpolation, die zum Erstellen von Schlüsselnamen oder schlimmer Lua-Skripten verwendet wird, etwas Vorsicht walten lassen.
>Tags und Links ruby-on-rails redis