Transparency in Ajax Applications / Page 2

Transparency in Ajax Applications

Example: MyLocalWeatherForecast.Com "Ajaxified"

Now that we have seen how much of the internal workings of a black box system can be uncovered, let's examine the same weather forecasting application after it has been converted to Ajax. The new site is shown in Figure 6-4.

The new Web site looks the same as the old when viewed in the browser. We can still see that PHP is being used because of the file extension, but there is no new information yet. However, when we view the page source, what can we learn?

Figure 6-4 The Ajax-based weather forecast site

<html>
  <head>
    <script type="text/javascript">
      var httpRequest = getHttpRequest();
      function getRadarReading() {
        // access the web service to get the radar reading
        var zipCode = document.getElementById('ZipCode').value;
        httpRequest.open("GET",
        "weatherservice.asmx?op=GetRadarReading&zipCode=" + zipCode, true);
        httpRequest.onreadystatechange = handleReadingRetrieved;
        httpRequest.send(null);
      }
      function handleReadingRetrieved() {
        if (httpRequest.readyState == 4) {
          if (httpRequest.status == 200) {
            var radarData = httpRequest.responseText;
            // process the XML retrieved from the web service
            var xmldoc = parseXML(radarData);
            var weatherData =
              xmldoc.getElementsByTagName("WeatherData")[0];
            var cloudDensity = weatherData.getElementsByTagName
            ("CloudDensity")[0].firstChild.data;
            getForecast(cloudDensity);
          }
        }
      }
      function getForecast(cloudDensity) {
        httpRequest.open("GET",
        "forecast.php?cloudDensity=" + cloudDensity, true);
        httpRequest.onreadystatechange = handleForecastRetrieved;
        httpRequest.send(null);
      }
      function handleForecastRetrieved() {
        if (httpRequest.readyState == 4) {
          if (httpRequest.status == 200) {
            var chanceOfRain = httpRequest.responseText;
            var displayText;
            if (chanceOfRain >= 25) {
              displayText = "The forecast calls for rain.";
            } else {
              displayText = "The forecast calls for sunny skies.";
            }
            document.getElementById('Forecast').innerHTML =
            displayText;
          }
        }
      }
      function parseXML(text) {
        if (typeof DOMParser != "undefined") {
          return (new DOMParser()).parseFromString(text,
          "application/xml");
        }
        else if (typeof ActiveXObject != "undefined") {
          var doc = new ActiveXObject("MSXML2.DOMDocument");
          doc.loadXML(text);
          return doc;
        }
      }
    </script>
  </head>
</html>

Aha! Now we know exactly how the weather forecast is calculated. First, the function getRadarReading makes an asynchronous call to a Web service to obtain the current radar data for the given ZIP code. The radar data XML returned from the Web service is parsed apart (in the handleReadingRetrieved function) to find the cloud density reading. A second asynchronous call (getForecast) passes the cloud density value back to the server. Based on this cloud density reading, the server determines tomorrow's chance of rain. Finally, the client displays the result to the user and suggests whether she should take an umbrella to work.

Just from viewing the client-side source code, we now have a much better understanding of the internal workings of the application. Let's go one step further and sniff some of the network traffic.

Sniffing the initial response from the main page didn't tell us anything that we didn't already know. We will leave the sniffer attached while we make an asynchronous request to the radar reading Web service. The server responds in the following manner:

This response gives us some new information about the Web service. We can tell from the X-Powered-By header that it uses ASP.NET, which might help an attacker as described earlier. More interestingly, we can also see from the response that much more data than just the cloud density reading is being retrieved. The current temperature, wind chill, humidity, and other weather data are being sent to the client. The client-side code is discarding these additional values, but they are still plainly visible to anyone with a network traffic analyzer.

Comparison Conclusions

Comparing the amount of information gathered on MyLocalWeatherForecast.com before and after its conversion to Ajax, we can see that the new Ajax-enabled site discloses everything that the old site did, as well as some additional items. The comparison is presented on Table 6-1.

Figure 6-4 The Ajax-based weather forecast site

Figure 6-5 Client visibility of (non-Ajax) MyLocalWeatherForecast.com

The Web Application as an API

The effect of MyLocalWeatherForecast.com's shift to Ajax is that the client-side portion of the application (and by extension, the user) has more visibility into the server-side components. Before, the system functioned as a black box. Now, the box is becoming clearer; the processes are becoming more transparent. Figure 6-5 shows the visibility of the old MyLocalWeatherForecast.com site.

In a sense, MyLocalWeatherForecast.com is just an elaborate application programming interface (API). In the non-Ajax model (see Figure 6-5), there is only one publicly exposed method in the API, "Get weather forecast".

Figure 6-6 Client visibility of Ajax MyLocalWeatherForecast.com

In the non-Ajax model (see Figure 6-6), not only did our API get a lot bigger (three methods instead of one), but its granularity increased as well. Instead of one, big "do it" function, we can see the individual subroutines that combine to calculate the result output. Furthermore, in many real-world scenarios, the JavaScript client-side code is not defined in each individual page on an as-needed basis. Instead, all of the client-side JavaScript functions used on any page are collected into a single, monolithic script library that is then referenced by each page that uses it.

This architecture makes it easier for the site developers to maintain the code, because they now only have to make changes in a single place. It can save bandwidth as well, because a browser will download the entire library only once and then cache it for later use. Of course, the downside of this is that the entire API can now be exposed after only a single request from a user. The user basically asks the server, "Tell me everything you can do," and the server answers with a list of actions. As a result, a potential hacker can now see a much larger attack surface, and his task of analyzing the application is made much easier as well. The flow of data through the system is more evident, and data types and method signatures are also visible.

Data Types and Method Signatures

Knowing the arguments' data types can be especially useful to an attacker. For example, if an attacker finds that a given parameter is an unsigned, 16-bit integer, he knows that valid values for that parameter range from 0 to 65,535 (216-1). However, the attacker is not constrained to send only valid values. Because the method arguments are sent as strings over the wire, the attacker is not even constrained to send valid data types. He may send a negative value, or a value greater than 65,535, to try to overflow or underflow the value. He may send a nonnumeric value just to try to cause the server to generate an error message. Error messages returned from a Web server often contain sensitive information, such as stack traces and lines of source code. Nothing makes analyzing an application easier than having its server-side source code!

It may be useful just to know which pieces of data are used to calculate results. For example, in MyLocalWeatherForecast.com, the forecast is determined solely from the current cloud density and not from any of the other current weather variables such as temperature or dew point. The usefulness of this information can vary from application to application. Knowing that the current humidity does not factor into the weather forecast at MyLocalWeatherForecast.com may not help a hacker penetrate the site, but knowing that a person's employment history does not factor into a loan application decision at an online bank may.

Digg This Add to del.icio.us

URL:

Transparency in Ajax Applications / Page 2