Est-il sûr de passer des chaînes codées en base64 via les paramètres GET?
Est-il sûr de passer des chaînes codées en base64 via les paramètres GET?
Réponses:
Non, vous devrez le coder par URL, car les chaînes base64 peuvent contenir les caractères "+", "=" et "/" qui pourraient modifier la signification de vos données - ressembler à un sous-dossier.
Les caractères base64 valides sont ci-dessous.
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=
Il existe des spécifications supplémentaires en base64. (Voir le tableau ici pour les détails). Mais essentiellement, vous avez besoin de 65 caractères pour coder: 26 minuscules + 26 majuscules + 10 chiffres = 62.
Vous avez besoin de deux autres ['+', '/'] et un caractère de remplissage '='. Mais aucun d'entre eux n'est compatible avec les URL, alors utilisez simplement des caractères différents pour eux et vous êtes prêt. Les standards du graphique ci-dessus sont ['-', '_'], mais vous pouvez utiliser d'autres caractères tant que vous les décodez de la même manière, et que vous n'avez pas besoin de les partager avec les autres.
Je recommanderais simplement d'écrire vos propres assistants. Comme ceux des commentaires sur la page de manuel php pour base64_encode :
function base64_url_encode($input) {
return strtr(base64_encode($input), '+/=', '._-');
}
function base64_url_decode($input) {
return base64_decode(strtr($input, '._-', '+/='));
}
urlencode
comme suggéré par la réponse de rodrigo-silveira. Créer deux nouvelles fonctions pour enregistrer quelques caractères en longueur d'URL, c'est comme entrer dans votre maison en passant par la fenêtre au lieu d'utiliser simplement la porte.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
,
devrait être encodé en url %2C
, je suggère d'utiliser ._-
au lieu de -_,
comme la seule variante de en.wikipedia.org/wiki/Base64#Variants_summary_table qui garde le suivi =
@joeshmo Ou au lieu d'écrire une fonction d'assistance, vous pouvez simplement encoder la chaîne encodée en base64. Cela ferait exactement la même chose que votre fonction d'assistance, mais sans avoir besoin de deux fonctions supplémentaires.
$str = 'Some String';
$encoded = urlencode( base64_encode( $str ) );
$decoded = base64_decode( urldecode( $encoded ) );
/
caractère si vous le transmettez non pas comme paramètre GET, mais comme chemin d'accès dans l'URL. Cela changera votre chemin si vous ne remplacez pas /
par quelque chose d'autre des deux côtés.
Note introductive Je suis enclin à publier quelques clarifications car certaines des réponses ici étaient un peu trompeuses (sinon incorrectes).
La réponse est NON , vous ne pouvez pas simplement passer un paramètre codé en base64 dans une chaîne de requête URL car les signes plus sont convertis en un ESPACE dans le tableau global $ _GET. En d'autres termes, si vous avez envoyé test.php? MyVar = stringwith + sign to
//test.php
print $_GET['myVar'];
le résultat serait:
stringwith sign
Le moyen le plus simple de résoudre ce problème consiste simplement à urlencode()
insérer votre chaîne base64 avant de l'ajouter à la chaîne de requête pour échapper les caractères +, = et / aux codes% ##. Par exemple, urlencode("stringwith+sign")
renvoiestringwith%2Bsign
Lorsque vous traitez l'action, PHP se charge de décoder automatiquement la chaîne de requête lors du remplissage de la variable globale $ _GET. Par exemple, si j'ai envoyé test.php? MyVar = stringwith% 2Bsign to
//test.php
print $_GET['myVar'];
le résultat serait:
stringwith+sign
Vous ne voulez pas de urldecode()
la chaîne $ _GET retournée car les + seront convertis en espaces.
En d'autres termes, si j'ai envoyé le même test.php? MyVar = stringwith% 2Bsign to
//test.php
$string = urldecode($_GET['myVar']);
print $string;
le résultat est inattendu:
stringwith sign
Il serait sûr pour rawurldecode()
l'entrée, cependant, il serait redondant et donc inutile.
<br>
, donc pas besoin de taper beaucoup de code HTML. J'espère que cela aide, j'ai un peu modifié votre réponse pour encore plus l'améliorer.
Oui et non.
Le jeu de caractères de base de base64 peut dans certains cas entrer en collision avec les conventions traditionnelles utilisées dans les URL. Mais de nombreuses implémentations en base64 vous permettent de modifier le jeu de caractères pour mieux correspondre aux URL ou même de les accompagner (comme Python urlsafe_b64encode()
).
Un autre problème auquel vous pouvez être confronté est la limite de longueur d'URL ou plutôt - l'absence de cette limite. Parce que les normes ne spécifient aucune longueur maximale, les navigateurs, serveurs, bibliothèques et autres logiciels fonctionnant avec le protocole HTTP peuvent définir ses propres limites. Vous pouvez consulter cet article: FAQ WWW: Quelle est la longueur maximale d'une URL?
C'est un encodage base64url que vous pouvez essayer, sa juste extension du code de joeshmo ci-dessus.
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));
}
En théorie, oui, tant que vous ne dépassez pas la longueur maximale de l'url et / ou de la chaîne de requête pour le client ou le serveur.
En pratique, les choses peuvent devenir un peu plus compliquées. Par exemple, il peut déclencher une HttpRequestValidationException sur ASP.NET si la valeur contient un "on" et que vous laissez dans le dernier "==".
Pour un encodage sûr, comme base64.urlsafe_b64encode(...)
en Python, le code ci-dessous fonctionne à 100% pour moi
function base64UrlSafeEncode(string $input)
{
return str_replace(['+', '/'], ['-', '_'], base64_encode($input));
}
Oui, c'est toujours sûr. bien sûr, base64 contient:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=
mais une chaîne encodée en base64 n'en a généralement pas +
. +
sera converti en un espace vide, entraîne une chaîne décodée incorrecte. /
est sûr dans une paire de paramètres get. =
est toujours à la fin de la chaîne encodée en base64 et le côté serveur peut être résolu =
directement.