Developer-Driven Mistakes

Up to this point, we've talked primarily about configuration issues that would normally fall under the purview of web application/site administrators. We're going to shift gears a bit now and discuss some configuration vulnerabilities that typically fall under the responsibility of web developers (although the line here can be a bit blurry, as you'll see in our discussion of include files coming up shortly).

Developer-driven configuration errors can be just as devastating as those caused by admins, if not more so. In fact, because web development is so tied up in the basic structure of the application/site itself (e.g., placement of files and access control configuration), web devs and admins are often one in the same person, or for larger commercial sites, people who work very closely in the same organization. This creates a sort of "collusion" effect where lax security gets perpetuated throughout a site/application. We'll show some examples of this in a moment.

Before we begin, we want to highlight the impact of web platform selection on vulnerabilities. We cite the example of Microsoft's ASP.NET ViewState method here to illustrate how the choice of development environment can leave a site or application open to any and all vulnerabilities common to that platform, especially the default configuration issues.

Include File Disclosure

Popularity:	8
Simplicity:	2
Impact:	7
Risk Rating:	8

 Attack    In IIS 5.x, the default behavior of the web server returns plain text files with unknown extension types back to the user . For example, if a file is created in the web root and named test.ars, whenever that file is requested from a browser, a download prompt will appear. This is because the extension ARS is not a known file type like ASP and HTML. This seemingly inconspicuous default can create serious information disclosure situations. One of the most common is the ability to download so-called include (.inc) files.

What are include files? When developers code in ASP they usually have a library of common functions that they place into include files so that they can be called efficiently from other parts of the site/application. The location of include files can often be found in HTML source or via file/ path disclosure vulnerabilities discussed earlier. Here's an example from a comment in HTML source code from a site we audited recently:

 <!-- #include virtual ="/include/connections.inc" --> 

Armed with the path- and filename, an attacker can now simply request the include file itself by browsing to http://www.site.com/include/connections.inc.

Voil ! The response contains all of the file's source code including the database username and password!

 <% ' FileName="Connection_ado_conn_string.htm" ' Type="ADO" ' DesigntimeType="ADO" ' HTTP="false" ' Catalog="" ' Schema="" Dim MM_Connection_STRING MM_Connection_STRING = "Driver={SQL Server};Server=SITE1;Database= Customers;  Uid=sa;Pwd=sp1Int3nze!*;  " %> 

Note 

The web server is logged in as SA. Bad practice!

Furthermore, the attacker also now knows the include file directory for this application/site and can start guessing at other potentially sensitive include file names in hopes of downloading even more sensitive information.

Include File Countermeasure

 Countermeasure    There are three ways to eliminate this pesky problem, rated as "Good," "Better," and "Best."

• Good   Move all .inc files out of the web app/site structure so that they are not available to standard requests . This solution may not be viable for large existing web applications, since all of the pathnames within the application's code would need to be changed to reflect the new location of the files. Furthermore, it doesn't prevent subsequent placement of .inc files in inappropriate places, whether through laziness or lack of awareness.

• Better   Rename all .inc files to .inc.asp. This will force the .inc files to run within the ASP engine and their source will not be available to clients .

• Best   Associate the .inc extension with asp.dll. This will again force the .inc files to run within the ASP engine and their source will not be available to clients. This is better than moving the files or renaming them to .asp because any file that is inadvertently named .inc will no longer be an issue, no matter what laziness or lack of awareness prevails in the future.

  Note 

  Microsoft's ASP engine has suffered from vulnerabilities in the past that resulted in information disclosure for some file types. While these issues have long since been fixed by Microsoft, you never really know what the effects of running code that is really not designed to be run directly could cause. It's probably best to use a combination of the approaches just described to ensure an in-depth defense.

Hacking ViewState

Popularity:	5
Simplicity:	5
Impact:	7
Risk Rating:	6

 Attack    ViewState is an ASP.NET method used to maintain the "state" information of all items located within an ASP.NET web page (see "References and Further Reading" for links to more information on ViewState). When a web form is submitted to a server in older versions of ASP, all of the form values get cleared. When the same form is submitted in ASP.NET, the status or "ViewState" of the form is maintained . We've all encountered the frustration, after completing and submitting a lengthy application or other web form, of receiving an error message and seeing that all of the information entered into the form has vanished. This typically occurs when a field was left blank or failed to comply with the structure the application expected. The application failed to maintain the "state" of the form submitted. The goal of ViewState is to eliminate this problem by maintaining the contents of the form just as it was submitted to the serverif there's an error or unexpected value in a field, the user is asked to correct only that information with the rest of the form remaining intact.

ViewState can also be used to hold the state of other application values. Many developers store sensitive information and entire objects in ViewState, but this practice can create serious security issues if ViewState is tampered with.

A good example of this is within the Microsoft reference application called Duwamish 7.0 (see "References and Further Reading" for a link). Duwamish Books is a sample online book-purchasing web application. Figure 9-6 shows the basic look and feel of Duwamish Books. Note that the book How to Win Friends and Influence People can be purchased for $11.99.

Figure 9-6: The Duwamish sample web application by Microsoft

Viewing the source of the page shown in Figure 9-6 reveals a hidden ViewState field that is sent when the "Add to Cart" button is pressed and the page form contents are submitted. The hidden ViewState field is shown in Figure 9-7, highlighted in black.

Figure 9-7: The ViewState is located in a hidden tag in the form.

As you can see, the ViewState value is encoded. Although it's difficult to tell what encoding algorithm is used simply from the value shown, most web technologies use Base64 encoding so it's probably a safe assumption that Base64 was used here. In order to see the properties of this ViewState, we run the value through a Base64 decoder. The result is shown in Figure 9-8.

Figure 9-8: The ViewState Base64 decoded

There are two things to notice with the decoded ViewState value shown in Figure 9-9.

Figure 9-9: The hacked request we send to the server

• The $11.99 price is being kept in ViewState.

• The ViewState is not being hashed . You can tell this by looking at the very end of the decoded string where you see a right-pointing angle bracket (>). A hashed ViewState has random bytes at the end of the string that look like this: <:Xy'y_w_Yy/FpP

Since this ViewState is not hashed, any changes made to the ViewState should be readily accepted by the web application. An attacker could modify the $11.99 price to $0.99, then encode the ViewState back to Base64 and submit the request to the server. Such a request might look like the one shown in Figure 9-9.

The server's response, shown here, indicates that the book was purchased at the $0.99 price set by the attacker!

Hacking ViewState Countermeasures

 Countermeasure    First off, don't ever store anything in ViewState. Let ViewState do its job and don't mess with it. This is the easiest way to prevent hackers from using it to mess with your users.

Microsoft provides the ability to apply a keyed hash to the ViewState tag. This hash is checked upon receipt to ensure the ViewState wasn't altered in transit. Depending on your version of ASP.NET, this ViewState integrity validation mechanism can be enabled by default. If not, you can enable integrity checking by adding these lines to the application's web.config file (the enabling of ViewState integrity checking is shown in bold text):

 <pages buffer="(truefalse)"  enableViewStateMac="true"/>  <machineKey validationKey="(minimum 40 char key)" decryptionKey= "AutoGenerate" validation="SHA1"/> 

The key can be manually added by entering the value in the web.config, or it can be auto-generated by entering "AutoGenerate" for the validationKey value. If you would like to have a unique key for each application, you can add the IsolateApps modifier to the validationKey value. More information on the <machineKey> element of the web.config can be found via the links included in the "References and Further Reading" section at the end of this chapter.

Tip 

If you have a web server farm, you may want to set the same ViewState validation key across all servers, rather than allowing each server to auto-generate one (which may break your app).