Forum Discussion

2 Replies

  • Another thing to consider is that hashes are one-way. If you find a URL in a response, let's say "https://www.mysite.com/admin" and hash the URI on the way to the client: "https://www.mysite.com/182745", then when the client makes a request for /182745, you need to know that this is intended for /admin. A hash wouldn't allow this. You could optionally encrypt and base64-encode the URL, which would be reversible. I'd suggest perhaps a few other options:

     

    1. Don't do this - if the URI is giving away too much information about the application, consider modifying the application itself. Further, encrypting the URI is really nothing more than obfuscation anyway. If the payload of a request to /182745 is something that an admin would send, what difference does it make what the URI is?

       

    2. Only obfuscate the URIs that you're worried about - this could be as simple as a STREAM profile in the response event to capture and replace sensitive URIs like /admin with something else.

       

    when HTTP_RESPONSE { [CRYPTO::hash -alg sha384 [HTTP::path]] { } }

     

    Understand here that an HTTP response doesn't have a URI or path. These are properties of a request. Any given HTTP response could have HTTP headers or response payload that might contain URIs.

     

  • I don't think you can do this. At least not from the server side. Only way to modify the url address would be through javascript or sending a redirect to a "hashed" url.

     

    In an iRule, you could proxy requests from a hashed url to a different backend url. Difficulty there is that you'd need to do some custom rewriting of the response pages to make sure the links would point to the hashed url. Would be a little bit of a headache. If you wanted to consider this, you might want to check out the ProxyPass iRule.