Modifier les obfuscations et verrouillages de requête URL

Comment empêcher la transformation malveillante de nos URL et empêcher le téléchargement des images haute résolution ?

Solution

Si vous êtes soucieux de l'altération d'URL ou du téléchargement des images haute résolution, procédez comme suit :

Configuration du jeu de règles pour modifier la syntaxe de l'URL.

Utilisez un jeu de règles configuré sur le serveur pour modifier la syntaxe des URL des clients. Les URL peuvent utiliser un format moins direct en termes de requête dynamique, avec des paramètres modifiables.

En règle générale, si un appel d'image peut être modifié de la syntaxe standard du Serveur d'image de Scene7, il ressemble à ceci :

http:///is/image//?

Il va s’afficher de manière plus statique donc :

http:///is/image///.jpg

Il est moins évident que des paramètres peuvent être modifiés dans la demande d’URL pour modifier la réponse. En fait, il peut être nécessaire de configurer un jeu de règles de sorte que toute requête ne passant pas par ce format ou ce mécanisme soit rejetée.

L'obfuscation des URL

Le contenu de la partie complète de modificateurs de chaîne de requête, y compris le suffixe facultatif de verrouillage, peut être masqué lors de l'application du codage base64 standard. Le serveur tente de décoder si l'attribut::RequestObfuscation est défini. Si le décodage échoue, la requête est rejetée. Si le verrouillage de requête et l'obfuscation de requête sont tous deux appliqués, le suffixe de verrouillage doit être généré et ajouté avant l'encodage base64.

Exemple : http://server/myTemplate?$txt=my text string&$img=myImage

code à :

http://server/myTemplate?dHh0PW15IHRleHQgc3RyaW5nJiRpbWc9bXlJbWFnZQ==

Pour générer ce codage, vous pouvez utiliser un site Web similaire à ce qui suit : http://www.base64encode.org/

Les occurrences de « = », « & » et « % » dans les chaînes de valeur doivent être sérialisées à l’aide du codage « %xx », avant que la requête ne soit interrompue. Il n'est pas nécessaire de coder en HTTP la partie de modificateurs de la requête avant ou après l'obfuscation, même si le verrouillage de la requête est appliqué, puisque le codage base64 est sécurisé pour la transmission HTTP.

http://microsite.omniture.com/t2/help/en_US/s7/is_ir_api/index.html#Request_Obfuscation

III. Demande de verrouillage

Pour réduire l’opportunité d'altération des requêtes, une simple opération de verrouillage est fournie.

Si attribute::RequestLock est défini, une valeur de verrouillage doit être ajoutée à la demande, sous forme de &xxxx, xxxx étant une valeur hexadécimale à quatre chiffres. Cette valeur hexadécimale est générée à l'aide d'un algorithme de hachage simple appliqué à la partie des modificateurs de la requête (après le ’?' qui sépare le chemin d’URL des modificateurs). Cette opération doit être effectuée après la fin du codage HTTP complet de la requête, mais avant son obfuscation (éventuelle). Après la désobfuscation de la requête, le serveur utilise le même algorithme de hachage sur la chaîne de modification (à l'exception des 5 derniers caractères, qui contiennent la valeur de verrouillage). Si la clé générée ne correspond pas au verrouillage, la requête est rejetée.

http://microsite.omniture.com/t2/help/en_US/s7/is_ir_api/index.html#Request_Locking