Web Information Flow Control (WIFC) and Privacy in SWEPT

WIFC is a OSI layer 7 communication protocol based on HTTP and XML. It enables assessment of the business logic implementation of a web application backend, by probing it with certain combinations of parameter values and testing the response. These values can be either:

  • Parameters passed in the query component [1] of a URL in an HTTP GET request. These parameters come after the URL path and a ? sign, and have the form parameter=value. Several tuples are separated by a & sign.
  • Parameters passed in the entity of an HTTP POST request [2].
  • Form fields, such as those defined inside <form> tags in HTML code.

 

In SWEPT we do not intend to produce either an official draft or a standard. Instead, our aim is to develop a blueprint upon which a similar protocol could be built.

WIFC is intended to be implemented in a layer below the web application. In our sample implementation, we will use HDIV, but WIFC could equally effectively be built into a Web Application Firewall (WAF), proxy or similar device.

There are no ‘WIFC requests’ as such. There are only WIFC responses. The requests that trigger those WIFC responses are normal HTTP GET or POST requests, like those normally found on web servers and browsers. Whenever the middleware device sees a parameter  with a wrong value (we will explain what ‘wrong’ means shortly) it has two options:

  • Redirect the user agent to a generic error site.
  • Send a WIFC response with details of the error.

WIFC responses are also normal HTTP responses, but with a difference. Instead of having an HTML entity, they have an XML entity. That XML document is what constitutes our WIFC protocol.

The XML document returned in the response provides detailed information about the errors that have been detected in the previous HTTP request. These errors are mostly derived from wrong values in parameters. What constitutes ‘wrong’ depends entirely on the web application. According to the business logic, certain parameters editable by the user (such as form fields) will have an allowed range of values, any other value out of that range being invalid. Other values might be non-editable, such as CSRF tokens, usually embedded in forms in hidden fields, or appended to internal URLs in links. These values are created in the server side, sent on to the client, and expected to keep the same value when another request from the client comes in. If a non-editable parameter has a value other than the one generated by the server in a previous request, it is considered invalid.

WIFC pretends to fill the gap of business logic vulnerability testing. According to the business logic of the web application, a web master can feed the WIFC-aware middleware in with all the parameters present in every URL of the site and their allowed values. Then, automatic testing can be enabled by issuing HTTP requests and verifying the response. In order to avoid leaking this information to the outside, we propose some easy ways of limiting access to WIFC responses from outside by configuring the infrastructure to run WIFC tests in a controlled manner.

The objective is to design robust security countermeasures for web applications that provide strong security guarantees, without limiting the original functionality, by enforcing secure and integral information flows. An application contains only secure information flows if trusted, or private, information entered within an application, doesn’t leak to untrusted sources, a natural notion of security.

[1] See IETF RFC 3986, “Uniform Resource Identifier (URI) – Generic Syntax”, section 3.4.

[2] See IETF RFC 2616, “Hypertext Transfer Protocol – HTTP/1.1”.