This chapter is from the book
This chapter is from the book
This chapter is from the book
3.8 TBS Case Study
This section demonstrates a few selected security verification examples from the I-View Previous Order use case in the TBS case study. Although not a complete test of this use case, these examples demonstrate how to execute some of the testing strategies in Section 3.7 on a concrete use case.
I-View Previous Order is implemented by several components in the TBS system:
ViewPreviousOrder.asp: The ASP page containing server-side JScript code that is executed by the Web server when the user attempts to load the page.
TBS.ViewPreviousOrder COM component: A C++ component that is called by the ASP page to retrieve the user's order. The component's ViewPreviousOrder method takes two arguments, userID and orderID and returns an XML string containing the order data.
Database tables needed to gather the data about the user's order: OrderInfo, OrderLineItem, and Item.
The following information is also necessary to accurately perform the tests:
ViewPreviousOrder URL: The full URL to gain access to the ViewPreviousOrder interface: http://TBSServer/TBS/ViewPreviousOrder.asp.
Sample data: Sample user IDs and orders created for the tests:
User IDs: testuser1 and testuser2
Order IDs: 10010 (belonging to testuser1) and 20020 (for testuser2)
Required input restrictions: For the order ID input, a maximum of ten characters containing only the digits 0–9. The user ID argument is not passed in from the Web browser and as such is not a candidate for testing from the I-ViewPreviousOrder interface.
Authorization
Because the I-ViewPreviousOrder interface is accessible only by registered TBS members, the user is prompted by TBS to log on prior to the display of the interface. The first part of the authorization test will determine whether the user is able to access the interface without logging in, which would be considered a serious security problem.
To perform the test, enter the following into the browser's address box:
http://TBSServer/TBS/ViewPreviousOrder.asp?orderID=10010
In this URL, one of the test order numbers has been supplied, which is required by ViewPreviousOrder.asp. It is important to note that this step was performed without logging in to the system—a fresh browser process was used, specifically avoiding the TBS system until the URL was entered into the address box.
TBS responded to this connection attempt with the message shown in Figure 3-9. From this message, we can tell that TBS properly intercepted our attempt to access the ViewPreviousOrder interface without logging on and denied access to the order information. Internally, TBS was able to do this by examining an ASP session variable that is set during the logon. If the variable was not set, TBS knows that the user has not been authenticated. The following ASP JScript code demonstrates this technique:
){kind=link}
// check login
if (Session("isAuthenticated") != true)
{
Response.Redirect("NotAuthorized.html");
}
Figure 3-9 Not Authorized Error Page
This check is performed as the very first step in all private components, so no code executes if this check fails.
The next part of the authorization test is to verify that we cannot use the ViewPreviousOrder interface to access data that belongs to another user. To perform this test, we log on as the first sample user, testuser1 and attempt to view the sample order, 20020, which belongs to the second sample user. This is accomplished by entering the following URL after a successful logon:
http://TBSServer/TBS/ViewPreviousOrder.asp?orderID=20020
When supplied with this URL, TBS did not retrieve the order and instead responded with the Web page shown in Figure 3-10.
){kind=link}
Figure 3-10 Data Retrieval Error Page
Internally, TBS stores the user ID in the record with the order ID. These two items are the primary key of the OrderInfo table, so they are used during database access to locate the order record. Because the user ID component of the key is not passed in from the browser but rather is stored in the Web server's session, the only component that can be manipulated is the order ID. The test URL entered attempted to access order number 20020, which belongs to testuser2. However, because the logon was performed with the testuser1 user ID, the ViewPreviousOrder component will attempt to use testuser1, 20020 as the key into the order table, which does not locate any records. Therefore, the error page is displayed.
Buffer Overflows
Any Web system component that accepts an input from the browser—or anywhere else, for that matter—must check the length of the input and restrict it to an appropriate length to prevent buffer overflow attacks. Buffer overflows are documented in detail in the section titled "Content Attacks," earlier in this chapter. To test the input length handling on the I-View Previous Order use case, a URL is entered into the browser's address box, using a length that exceeds the maximum input length. For the order ID input, the maximum length is 10 characters, so an input of 11 characters should be trapped as an error. As previously discussed, Web system components should return a predetermined input error page to indicate that they have successfully trapped an input error. This page should be different from other error pages so it can be used as a basis for the success or failure of input tests.
The following URL is used to test the input-length handling:
http://TBSServer/TBS/ViewPreviousOrder.asp?orderID= 12345678901
Note that a logon must occur prior to attempting to access this URL, as TBS will reject the attempt to access the script if the user is not authenticated. When this URL was used to access the TBS server, the error page illustrated in Figure 3-10 was displayed. This indicates a problem, as TBS tried to retrieve order number 12345678901 instead of rejecting that order ID with an input error as it should have, as the length exceeds ten characters. An investigation of the source code of the TBS.ViewPreviousOrder C++ COM component revealed that the component was not checking the length of the input. To correct this situation, the following code was added:
if (orderID.length() > 10)
{
return E_INVALIDARG;
}
In addition, the ASP page was modified to look for this error and to redirect the client to the input error page.