AppSec Blog

Logging Links to 3rd party provider

While web application spans over multiple sites boundary, it is essential to keep track of where the users are being directed. This is pretty much a basic logging and audit trail concept. While it is easy to understand in theory, it is not always easy to see where it should be implemented. Development communities sometimes have a harder time to understand why this is important, so let's examine why it is a good idea to do so. If you ever have to explain to others why you should do this, hope this info will become useful.

Internal redirection or links

While directing users on the same site (same server) using HTML links, it is easy to track where the user is visiting. Each of the link that the user followed will be in the web server log and it is not difficult to trace the footstep of a specific user (with IP address).

External redirection or links

When directing to an external site using HTML links, there is no way by default to track the user's activity. The webserver log doesn't track the user's visit to an external site, only the destination server logs it. The browser fetch page from another site and does not necessarily report back.

Why is this even important?

It is common for applications to be spread out in different servers or even different organizations. An online retailer may present products for user's selection and then let the user click on the checkout button to be directed to a payment processor for finishing the transaction. If the payment processor in this example is compromised, how do the retailer know who clicked on the checkout button if the button is a straight link to the payment processor? The chances of an audit trail is minimal.

On December 2nd, 2008, Checkfree Billpay site was compromised, this is the organization that owns about 70-80 percent of online bill payment in the US. A lot of the banks simply forward their clients to Billpay using HTML link for bill payment function. It is essentially an application service provider for a lot of the US banks. The attackers were able to hijack the DNS entry of Billpay's domain to a malicious site hosting malware awaiting to infect visiting users.

When performing incident handling on issues like this one, "who went to the compromised site" might be one of the first question to be answered. If a straight HTML link <a href=> style external link is used, there is not a whole lot of chance to be able to answer that question.

What's the right way to do it?

While directing user to an external service provider, make the link internal. The link should be targeted at a redirection script. The script uses a 301 redirection header to direct the user to external provider's site. This way, there is web server log (for IP logging) and also application log which is done by the redirection script. The application log should have user name information since it should be session aware.

For the redirection script, it is important to ensure the issue of open redirect does not exist. User should never be able to tell the script the exact URL to be redirected to.


More information on the Checkfree compromised can be found here and here

Post a Comment


* Indicates a required field.