Forum Discussion

Jason_105955's avatar
Jason_105955
Icon for Nimbostratus rankNimbostratus
Feb 26, 2008

Obfuscate 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!
application delivery
dev
devops
iRules

4 Replies

Sort By
  • Nicolas_Menant's avatar
    Nicolas_Menant
    Icon for Employee rankEmployee
    Feb 27, 2008
    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
  • Lee_Orrick_5554's avatar
    Lee_Orrick_5554
    Historic F5 Account
    Feb 28, 2008
    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.

     

     

     

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 03, 2008
    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