General Countermeasures

As we have seen, much of the process of profiling a web application exploits functionality that is intended by application designersafter all, they do want you to browse the site quickly and easily. However, we have also seen that many aspects of site content and functionality that are inappropriately revealed to anonymous browsers due to some common site-design practices and misconfigurations. This section will recount steps that application designers can take to prevent leaks great and small.

A Cautionary Note

After seeing what information is commonly leaked by web applications, you may be tempted to excise a great deal of content and functionality from your site. We recommend restraint, or, put another way, "Careful with that axe, Eugene." The web administrator's goal is to secure the web server as much as possible. Most information leakage can be stopped at the server level by strong configurations and least-privilege access policies. Other methods require actions on the part of the programmer. Keep in mind that web applications are designed to provide information to users. Just because a user can download the application's local.js file doesn't mean the application has a poor design; however, if the local.js file contains the username and password to the application's database, then the system is going to be broken.

Protecting Directories

As we saw many times throughout this chapter, directories are the first line of defense against prying profilers. Here are some tips for keeping them sealed.

Location Headers

You can limit the contents of the Location header in the redirect so that it doesn't display the web server IP address, which can point attackers towards discrete servers with misconfigurations or vulnerabilities.

By default, IIS returns its IP address. To return its Fully Qualified Domain Name instead, you need to modify the IIS metabase. The adsutil .vbs script is installed by default in the Inetpub\adminscripts directory on Windows 2000 systems.

 D:\Inetpub\adminscripts\adsutil.vbs set w3svc/UseHostName True D:\Inetpub\adminscripts\  net start w3svc  

Apache can stop the directory enumeration. Remove the mod_dir module during compilation. The change is simple:

 [root@meddle apache_1.3.23]# ./configure --disable-module=dir Configuring for Apache, Version 1.3.23 

Directory Structure and Placement

Here are some further tips on securing web directories:

  • Different User/Administrator Roots   Use separate web document roots for user and administrator interfaces. This can mitigate the impact of source-disclosure attacks and directory traversal attacks against application functionality:

    /main/maps to D:\IPub\pubroot\
    /admin/maps to E:\IPub\admroot\

  • IIS   Place the InetPub directory on a volume different from the system root, e.g., D:\InetPub on a system with C:\WINNT. This prevents directory traversal attacks from reaching sensitive files like \WINNT\repair\sam and \ WINNT\System32\cmd.exe.

  • Unix Web Servers   Place directories in a chroot environment. This can mitigate the impact of directory-traversal attacks.

Protecting Include Files

The best protection for all types of include files is to ensure that they do not contain passwords. This might sound trivial, but anytime a password is placed into a file in clear text, expect that password to be compromised. On IIS, you can change the file extension commonly used for include files (.inc) to .asp, or remap the .inc extension to the ASP engine. This will cause them to be processed server-side and prevent source code from being displayed in client browsers. By default, .inc files are rendered as text in browsers. Remember to change any references within other scripts or content to the renamed include files.

Miscellaneous Tips

The following tips will help your web application to resist the surveying techniques we've described in this chapter.

  • Consolidate all JavaScript files to a single directory. Ensure that the directory and any files within it do not have "execute" permissions (i.e., they can only be read by the web server, not executed as scripts).

  • For IIS, place .inc, .js, .xsl, and other include files outside of the web root by wrapping them in a COM object.

  • Strip developer comments. A test environment should exist that is not Internet- facing where developer comments can remain in the code for debugging purposes.

  • If a file must call any other file on the web server, then use path names relative to the web root or the current directory. Do not use full path names that include drive letters or directories outside of the web document root. Additionally, the script itself should strip directory traversal characters (../../).

  • If site requires authentication, ensure authentication is applied to the entire directory and its subdirectories. If anonymous users are not supposed to access ASP files, then they should not be able to access XSL files either.



Hacking Exposed Web Applications
HACKING EXPOSED WEB APPLICATIONS, 3rd Edition
ISBN: 0071740643
EAN: 2147483647
Year: 2006
Pages: 127

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net