Ist es sicher, rohe Base64-codierte Zeichenfolgen über GET-Parameter zu übergeben?
Ist es sicher, rohe Base64-codierte Zeichenfolgen über GET-Parameter zu übergeben?
Antworten:
Nein, Sie müssten es url-codieren, da base64-Zeichenfolgen die Zeichen "+", "=" und "/" enthalten können, die die Bedeutung Ihrer Daten ändern können - sehen Sie aus wie ein Unterordner.
Gültige base64-Zeichen sind unten aufgeführt.
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=
Es gibt zusätzliche base64-Spezifikationen. (Einzelheiten finden Sie in der Tabelle hier ). Im Wesentlichen benötigen Sie jedoch 65 Zeichen zum Codieren: 26 Kleinbuchstaben + 26 Großbuchstaben + 10 Ziffern = 62.
Sie benötigen zwei weitere ['+', '/'] und ein Füllzeichen '='. Aber keiner von ihnen ist url-freundlich, also benutze einfach verschiedene Zeichen für sie und du bist fertig. Die Standardzeichen aus der obigen Tabelle sind ['-', '_'], aber Sie können andere Zeichen verwenden, solange Sie sie gleich dekodiert haben und nicht mit anderen teilen müssen.
Ich würde empfehlen, nur Ihre eigenen Helfer zu schreiben. Wie diese aus den Kommentaren auf der PHP-Handbuchseite für base64_encode :
function base64_url_encode($input) {
return strtr(base64_encode($input), '+/=', '._-');
}
function base64_url_decode($input) {
return base64_decode(strtr($input, '._-', '+/='));
}
urlencode
wie in Rodrigo-Silveiras Antwort vorgeschlagen. Wenn Sie zwei neue Funktionen erstellen, um wenige Zeichen in der URL-Länge zu sparen, betreten Sie Ihr Haus durch das Fenster, anstatt nur die Tür zu benutzen.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
,
sollte urlencodiert werden, schlage %2C
ich vor, ._-
anstelle -_,
der einzigen Variante in en.wikipedia.org/wiki/Base64#Variants_summary_table zu verwenden , die das Trailing =
@joeshmo Oder anstatt eine Hilfsfunktion zu schreiben, können Sie einfach die base64-codierte Zeichenfolge urlencodieren. Dies würde genau das Gleiche tun wie Ihre Hilfsfunktion, jedoch ohne die Notwendigkeit von zwei zusätzlichen Funktionen.
$str = 'Some String';
$encoded = urlencode( base64_encode( $str ) );
$decoded = base64_decode( urldecode( $encoded ) );
/
Zeichen, wenn Sie es nicht als GET-Parameter, sondern als Pfad in der URL übergeben. Es wird Ihren Weg ändern, wenn Sie nicht /
auf beiden Seiten durch etwas anderes ersetzen .
Einleitende Anmerkung Ich bin geneigt, einige Erläuterungen zu veröffentlichen, da einige der Antworten hier etwas irreführend waren (wenn nicht falsch).
Die Antwort lautet NEIN . Sie können nicht einfach einen Base64-codierten Parameter innerhalb einer URL-Abfragezeichenfolge übergeben, da Pluszeichen in ein Leerzeichen innerhalb des globalen Arrays $ _GET konvertiert werden. Mit anderen Worten, wenn Sie test.php gesendet haben? MyVar = stringwith + sign to
//test.php
print $_GET['myVar'];
das Ergebnis wäre:
stringwith sign
Die einfache Möglichkeit, dies zu lösen, besteht darin, einfach urlencode()
Ihre base64-Zeichenfolge zu erstellen, bevor Sie sie zur Abfragezeichenfolge hinzufügen, um die Zeichen +, = und / in% ## -Codes zu maskieren. Gibt zum Beispiel urlencode("stringwith+sign")
zurückstringwith%2Bsign
Wenn Sie die Aktion verarbeiten, übernimmt PHP die automatische Dekodierung der Abfragezeichenfolge, wenn das globale $ _GET gefüllt wird. Zum Beispiel, wenn ich test.php? MyVar = stringwith% 2Bsign an gesendet habe
//test.php
print $_GET['myVar'];
das Ergebnis wäre:
stringwith+sign
Sie nicht wollen, urldecode()
die $ _GET String als + 's zurückgegeben werden in Leerzeichen umgewandelt werden.
Mit anderen Worten, wenn ich dieselbe test.php gesendet habe? MyVar = stringwith% 2Bsign to
//test.php
$string = urldecode($_GET['myVar']);
print $string;
Das Ergebnis ist unerwartet:
stringwith sign
Es wäre sicher für rawurldecode()
die Eingabe, jedoch redundant und daher unnötig.
<br>
, sodass Sie nicht viel HTML eingeben müssen. Ich hoffe das hilft, ich habe deine Antwort ein wenig bearbeitet, um sie noch weiter zu verbessern.
Ja und nein.
Der Basiszeichensatz von base64 kann in einigen Fällen mit herkömmlichen Konventionen kollidieren, die in URLs verwendet werden. Bei vielen Base64-Implementierungen können Sie den Zeichensatz jedoch so ändern, dass er besser mit URLs übereinstimmt, oder sogar mit einer (wie Pythons urlsafe_b64encode()
).
Ein weiteres Problem, mit dem Sie möglicherweise konfrontiert sind, ist die Begrenzung der URL-Länge bzw. das Fehlen einer solchen Begrenzung. Da Standards keine maximale Länge festlegen, können Browser, Server, Bibliotheken und andere Software, die mit dem HTTP-Protokoll arbeiten, ihre eigenen Grenzen definieren. Sie können sich diesen Artikel ansehen: WWW-FAQs: Was ist die maximale Länge einer URL?
Es ist eine base64url-Codierung, die Sie ausprobieren können. Es ist nur eine Erweiterung des obigen Codes von joeshmo.
function base64url_encode($data) {
return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
}
function base64url_decode($data) {
return base64_decode(str_pad(strtr($data, '-_', '+/'), strlen($data) % 4, '=', STR_PAD_RIGHT));
}
Theoretisch ja, solange Sie die maximale Länge der URL und / oder der Abfragezeichenfolge für den Client oder Server nicht überschreiten.
In der Praxis kann es etwas schwieriger werden. Beispielsweise kann es eine HttpRequestValidationException in ASP.NET auslösen, wenn der Wert zufällig ein "Ein" enthält und Sie das nachfolgende "==" belassen.
Für die URL-sichere Codierung, wie base64.urlsafe_b64encode(...)
in Python, funktioniert der folgende Code für mich zu 100%
function base64UrlSafeEncode(string $input)
{
return str_replace(['+', '/'], ['-', '_'], base64_encode($input));
}
Ja, es ist immer sicher. Natürlich enthält base64:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=
aber eine base64-codierte Zeichenfolge hat normalerweise keine +
. +
wird in ein Leerzeichen umgewandelt, führt zu einer falsch dekodierten Zeichenfolge. /
ist sicher in einem get-Parameter-Paar. =
befindet sich immer am Ende der Base64-codierten Zeichenfolge und die Serverseite kann =
direkt auflösen .