vADC Docs

Masking Social Security Numbers using Stingray TrafficScript

by on ‎03-12-2013 10:00 AM (462 Views)

Stingray's TrafficScript rules can inspect and modify an entire request and response stream. This provides many opportunities for securing content against unauthorized breaches.

For example, over a period of 9 months, a hacker named Nicolas Jacobsen used a compromised customer account on T-Mobile's servers to exploit a vulnerability and leach a large amount of sensitive information (see http://www.securityfocus.com/news/10271). This information included US Secret Service documents and customer records including their Social Security Numbers.

This article describes how to use a simple TrafficScript rule to detect and mask out suspicious data in a response.

The TrafficScript rule

Here is a simple rule to remove social security numbers from any web documents served from a CGI script:


if( string.contains( http.getPath(), "/cgi-bin/" ) ) {


   $payload = http.getResponseBody();



   $new_response = string.regexsub( $payload, "\\d{3}-\\d{2}-\\d{4}",


                            "xxx-xx-xxxx", "g" );



   if( $new_response != $payload )


      http.setResponseBody( $new_response );


}


Configure this rule as a 'Response Rule' for a virtual server that handles HTTP traffic.

How it works

How does this simple-looking TrafficScript rule work?  The specification for the rule is:

  • If the request is for a resource in /cgi-bin/, then:
    • mask anything in the response that looks like a social security number.

In this case, we recognize social security numbers as sequences of digits and '-' (for example, '123-45-6789') and we replace them with 'XXX-XX-XXXX'.

1. If the request is for a resource in /cgi-bin/:


if( string.contains( http.getPath(), "/cgi-bin/" ) ) {


The http.getPath() function returns the name of the HTTP request, having removed any %-encoding which obscures the request. You can use this function in a request or response rule.The string.contains() test checks whether the request is for a resource in /cgi-bin/.

2. Get the entire response:


$payload = http.getResponseBody();


The http.getResponseBody() function reads the entire HTTP response. It seamlessly handles cases where no content length is provided, and it dechunks a chunk-transfer-encoded response - these are common cases when handling responses from dynamic web pages and applications. It interoperates perfectly with performance features like HTTP Keepalive connections and Pipelined requests.

3. Replace any social security numbers:


$new_response = string.regexsub( $payload, "\\d{3}-\\d{2}-\\d{4}",


                            "xxx-xx-xxxx", "g" );


The string.regexsub() function applies a regular expression substitution to the $payload data, replacing potential social security numbers with anonymous data. Regular expressions are commonly used to inspect and manipulate textual data, and Stingray supports the full POSIX regular expression specification.

4. Change the response:


if( $new_response != $payload )


   http.setResponseBody( $new_response );


The http.setResponseBody() function replaces the HTTP response with the supplied data.

You can safely replace the response with a message of different length - Stingray will take care of the Content-Length header, as well as compressing and SSL-encrypting the response as required. http.setResponseBody() interoperates with keepalives and pipelined requests.

In action...

Here is the vulnerable application, before (left) and after (right) the TrafficScript rule is applied:

ssn.png

Masking social security numbers with a string of 'XXX'

Summary

Although Stingray is not a total application security solution (look to the Stingray Application Firewall for this), this example demonstrates how Stingray Traffic Manager can be used as one layer in a larger belt-and-braces system. Stingray is one location where security measures can be very easily added - perhaps as a rapid reaction to a vulnerability elsewhere in the network, patching over the problem until a more permanant solution can be deployed.

In a real deployment, you might do something more firm than masking content.  For example, if a web page contains unexpected, sensitive data it might be best just to forcibly-redirect the client to the home page of your application to avoid the risk of any sensitive content being leaked.