How can we prevent malicious transformation of our URLs, and prevent high-resolution images from download?
If you are concerned about URL tampering, or high-resolution image download, do the following:
Ruleset configuration to alter URL syntax
Use a ruleset configured on the server to alter the syntax of the clients' URLs. The URLs can use a format that is less obvious as a dynamic request with parameters that can be changed.
Essentially, if an image call can be changed from the typical Scene7 Image Server syntax that looks like this:
to something that appears more static like so:
It is less obvious that there are parameters that can be modified in the URL request to change the response. In fact, it should be possible to configure a ruleset so that any request that doesn't go through this format or mechanism is rejected.
The contents of the entire modifiers part of request string, including the optional lock suffix can be obscured by applying standard base64 encoding. The server attempts to decode if attribute::RequestObfuscation is set. If decoding fails, the request is rejected. If both request locking and request obfuscation are applied, the lock suffix must be generated and appended before base64 encoding.
Example http://server/myTemplate?$txt=my text string&$img=myImage
To generate this encoding, you can use a website like the following: http://www.base64encode.org/
Any occurrences of ‘=’, ‘&’, and ‘%’ in value strings must be escaped using ‘%xx’ encoding, before the request is obfuscated. It is not necessary to otherwise http-encode the modifiers part of the request either before or after obfuscation, even if request locking is applied, since base64 encoding is safe for http transmission.
See Request Obfuscation.
III. Request Locking
To reduce opportunity for tampering with requests, a simple locking facility is provided.
If attribute::RequestLock is set, a lock value must be appended to the request, in form of &xxxx, with xxxx being a four digit hex value. This hex value is generated using a simple hashing algorithm applied to the modifiers portion of the request (after the '?' which separates the URL path from the modifiers). This must be done after the request is fully http-encoded, but before it is (optionally) obfuscated. After de-obfuscating the request, the server will use the same hashing algorithm on the modifier string (excluding the last 5 characters, which contain the lock value). If the generated key does not match the lock, the request is rejected.
See Request Locking.