@Rafi1 That is definitely possible but keep in mind that while the client sees path "/abc/def" the server will see only "/" which is the root of the website. So if you decide to change all paths that the client sees to "/" just make sure that the path "/" has all the content that you're looking for. Again, this is another reason why obfuscating the path really isn't the path to go down to provide security for your website over something such as a login token or any other security measure you can take over obfuscation.
@Rafi1 As long as you will always change HTTP Path "/" to "/abc/def" this would work but purely based on how most websites function it seems like "/" is the default web page for the website so this will most likely cause issues for you. This would be easier to achieve if you had lets say path "/button" the hidden path for "/abc/def" and could be achieved using string map. What is the reason to hide the HTTP path from the end user?
Are you mean that "/button" will hide ""/abc/def" ? some kind of alias ?
Ithink it will be fine
The reason is security of course, the the web site is very sensitive and we need to "hide" some uri so attacker will not try to manipulate the site with the uri changes (The goal is to hide the web site paths)
I tried some irules like:
when HTTP_REQUEST { # Define your public path and your hidden path set public_path "/#ArchNew3" set hidden_path "/architecture-info/#ArchNew3"
# Check if the user is requesting the public path if { [HTTP::uri] contains $public_path } { # Internally rewrite the request to use the hidden path HTTP::uri $hidden_path } }
@Rafi1 If your intent is to require a user to follow button pushes on a website rather than skipping through by specifying the path themselves then this is not the way to achieve security on your site. If the end user has to check certain boxes or provide some sort of login before they can proceed to a different path you should be able to generate a login token that the F5 can then validate exists before sending them to the path in question. Typically when you have to perform a string map it's because the server is unable be configured to correct the path itself and you then have to make the correction on the F5 but not to obfuscate the path. You will achieve far better security with a token rather than obfuscation.
@Rafi1 Even with an alias you would still have an instance where they user can still get to the destination just using a different path. In this instance you are better off obfuscating this on the server side rather than the F5. I would be interested in knowing what CISO has listed as the policy that you are attempting to solve for. I can see stripping local device name or IP address if it's provided in the response to the client but other than that obfuscating the response rather than implementing security features such as login tokens and the like is not a superior security stance.
@Rafi1 That is definitely possible but keep in mind that while the client sees path "/abc/def" the server will see only "/" which is the root of the website. So if you decide to change all paths that the client sees to "/" just make sure that the path "/" has all the content that you're looking for. Again, this is another reason why obfuscating the path really isn't the path to go down to provide security for your website over something such as a login token or any other security measure you can take over obfuscation.
