Problem

Wie verhindern wir die böswillige Umwandlung unserer URLs und den Download von Bildern mit hoher Auflösung?

Lösung

Wenn Sie sich über die Manipulation von URLs oder den Download von hochauflösenden Bildern Sorgen machen, gehen Sie wie folgt vor:

Regelsatzt-Konfiguration, um URL-Syntax zu ändern

Verwenden Sie einen auf dem Server konfigurierten Regelsatz, um die Syntax der Client-URLs zu ändern. Die URLs können ein weniger offensichtliches Format als eine dynamische Anfrage mit veränderbaren Parametern verwenden.

Grundsätzlich, wenn ein Bildaufruf von der typischen Scene7 Image-Server-Syntax geändert werden kann, die folgendermaßen aussieht:

http:///is/image//?

zu etwas, das statischer erscheint, wie dieses:

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

Es ist weniger leicht wahrnehmbar, dass es Parameter gibt, die in der URL-Anfrage geändert werden können, um die Antwort zu ändern. Tatsächlich sollte es möglich sein, einen Regelsatz so zu konfigurieren, dass jede Anfrage, die dieses Format oder diesen Mechanismus nicht durchläuft, abgelehnt wird.

URL-Obfuskation

Der Inhalt des gesamten Teils des Modifikators des Anfrage-Strings, einschließlich des optionalen Lock-Suffix kann verdeckt werden, indem Standard-Base64-Kodierung anwendet wird. Der Server versucht zu dekodieren, wenn attribut::RequestObfuscation gesetzt ist. Wenn die Dekodierung fehlschlägt, wird die Anfrage zurückgewiesen. Wenn sowohl Anfragesperre als auch Anfrage-Obfuskation angewendet werden, muss das Lock-Suffix vor der Base64-Kodierung generiert und angehängt werden.

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

kodiert zu:

http://server/myTemplate?dHh0PW15IHRleHQgc3RyaW5nJiRpbWc9bXlJbWFnZQ==

Um diese Kodierung zu erstellen, können Sie eine Website wie die folgende verwenden: http://www.base64encode.org/

Alle Vorkommen von „=“, „&“ und „%“ in Wertzeichenfolgen müssen mittels „%xx“-Kodierung maskiert werden, bevor die Anfrage verdeckt wird. Es ist nicht notwendig, den Teil des Modifikators der Anfrage vor oder nach der Obfuskation mit HTTP zu kodieren, selbst wenn das Sperren der Anfrage angewendet wird, da die Base64-Kodierung für die HTTP-Übertragung sicher ist.

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

III. Anfragesperre

Um die Möglichkeit von Manipulationen bei Anfragen zu reduzieren, ist eine einfache Sperrvorrichtung vorgesehen.

Wenn attribute::RequestLock gesetzt ist, muss an die Anfrage ein Sperrwert in Form von &xxxxxx angehängt werden, wobei xxxx ein vierstelliger Hex-Wert ist. Dieser Hex-Wert wird mit einem einfachen Hashing-Algorithmus erzeugt, der auf den Teil des Modifikators der Anfrage angewendet wird (nach dem „?“', der den URL-Pfad von den Modifikatoren trennt). Dies muss geschehen, nachdem die Anfrage vollständig HTTP-kodiert ist, aber bevor sie (optional) obfuskiert wird. Nach der Deobfuszierung der Anfrage verwendet der Server den gleichen Hashing-Algorithmus für den Modifikator-String (mit Ausnahme der letzten 5 Zeichen, die den Sperrwert enthalten). Stimmt der generierte Schlüssel nicht mit der Sperre überein, wird die Anfrage abgelehnt.

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

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie