Forum Discussion
Jason_105955
Nimbostratus
NimbostratusObfuscate URI's?
Greetings!
Has anyone any ideas on ways to create an iRule that will obfuscate URI's used (and returned in the HTTP payload)?
We've inherited a problem with a very badly written app, where a form page takes data such as username/password and generates a URI such as https://www.website.org/login.asp?username=x&password=y
It's worse than that since the app has failed a pen test where it allows data leakage by manipulating the URI manually, so by changing the record= parameter in the URI below, other records can be accessed.
https://www.website.org/getdata.asp?record=100001
I know it's terrible coding, but for various reasons it's not an option to recode and fix all the problems in the short term, so I'm trying to find a way to mangle the URI's invisibly.
If the URI could be mangled to show
https://www.website.org/gH4yrh499skjfdjs
or some other equally meaningless string, it'll be virtually impossible for the URI to be manipulated.
We've a way of doing this through another route, but unfortunately it only mangles the first part of the URI and not the second, so we're seeing for example:
https://www.website.org/gH4yrh499skjfdjs?record=100001
Of course the website is also returning payload with a series of links in the same form which need to be obfuscated in the same way!
Any insights would be appreciated!!
Oh, and ASM isn't an option right now!
Nicolas_MenantEmployee
Hi,
I'm afraid it's not really be possible to protect this
I explain: since the parameters are within the URI it means the form uses GET method to send the data.
Then between the client and the BIGIP, the URI will always contain the different parameter and their value, you won't be able to hide it since it is send by the client.
You may want to rename the parameter but it would be useless since the client will know what it is in the URI based on the value that will be assigned to each parameter.
Ex: let's say you hash in the form received by the client the username and password header. When the client will enter his credential he will see something like this in his browser:
http://www.test.com/index.php?sidjfsoidjf=thisistheuser&sfjsdoijfoif=thisismypassword
So the client will be able to know which parameter to modify after.
If you want to hide the parameter from the URI, you will need to use POST method and it will only hide the data into the http payload. If the client is smart he'll be able to find those data and modify it then using software like paros.
In your case you won't be able to do anything with iRules only.
HTH- I agree with nmenant, and I do not see a way you cannot accomplish what you want to in the manner you want.
However, it might be possible to change the form method from GET to POST in the HTML page as it is sent to the client. This would force the POST behavior which is what you really want. It looks like you are using HTTPS, so the username/password are not longer in the clear.
You could use something similar to the SSN Scrubbing rule in the Code Share section of the site.
http://devcentral.f5.com/wiki/default.aspx/iRules/SocialSecurityNumberScrubbing.html
Instead of looking for SSNs in the response you would look for method=get and replace it with method=post.
When the client sent the POST to login, you know the URI they will be posting to and it would be a matter of extracting the POST data and crafting the GET URI the back end node expects.
It is at least worth considering.
AFA you data leakage, you might consider taking a look at our ASM product. It is specifically designed to prevent those kinds of attacks. - So, scratch my last comment about ASM. I just read the last line of your post.
hoolioCirrostratus
Well, after ~500 lines and a few long nights, we have a working first version of a rule which enforces a session in the app and encrypts the links in response headers/content. This prevents attackers from exploiting most of the vulnerabilities through forceful browsing. The next thing we're looking at is encrypting vulnerable parameter values in response content to really lock it down. ASM would have been nice here, but it wasn't an option in the time frame.
Aaron