Verschleierung von Anfragen request-obfuscation
Der Inhalt des gesamten Modifikatorteils der Anforderungszeichenfolge, einschließlich des optionalen Suffixes für die Sperre, kann durch Anwendung der standardmäßigen Base64-Kodierung verdeckt werden.
Der Server versucht zu dekodieren, wenn attribute::RequestObfuscation festgelegt ist. Wenn die Dekodierung fehlschlägt, wird die Anfrage abgelehnt. Wenn sowohl die Sperrung von Anforderungen als auch die Verschleierung von Anforderungen angewendet werden, muss das Suffix "Sperren"vor der Base64-Kodierung generiert und angehängt werden.
- In der Dynamic Media-Benutzeroberfläche werden möglicherweise nicht die richtigen Details für das Feld Zuletzt veröffentlicht angezeigt. Dies wirkt sich jedoch nicht auf die Veröffentlichung aus.
- Derzeit funktioniert das HLS-Video-Streaming nicht, wenn die Verschleierung der Anfrage und die Sperrung der Anfrage aktiviert sind.
- Derzeit funktionieren einige Dynamic Media-Viewer nicht, wenn die Verschleierung von Anfragen und die Sperrung von Anfragen aktiviert sind.
Beispiel section-dd4bfab19aa040f8ba3f6e397c6b0941
http://server/myTemplate?$txt=my text string&$img=myImage
kodiert in:
http://server/myTemplate?dHh0PW15IHRleHQgc3RyaW5nJiRpbWc9bXlJbWFnZQ==
Alle Vorkommen von '=', '&' und '%' in Wertzeichenfolgen müssen mit '%xx'-Kodierung maskiert werden, bevor die Anfrage verschleiert wird. Es ist nicht erforderlich, den Teil Modifikatoren der Anforderung vor oder nach der Verschleierung durch HTTP zu kodieren, selbst wenn die Anforderungssperrung angewendet wird, da die Base64-Kodierung für die HTTP-Übertragung sicher ist.
Verwandte Themen section-7ea59724c97c4ee9a510dbbc1f79e564
HTTP-Kodierung, Anforderungssperrung, Attribut::RequestObfuscation