- Black Boxes Versus White Boxes
- The Web Application as an API
- Specific Security Mistakes
- Security through Obscurity
- Conclusions
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
)
Figure 6-5 Client visibility of (non-Ajax) MyLocalWeatherForecast.com
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".
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.
)
Figure 6-6 Client visibility of Ajax MyLocalWeatherForecast.com
<script src="ajaxlibrary.js"></script>
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.