posted on Monday, January 05, 2009 5:58 AM
Over the holidays Marcin @ tssci security offered up a python script for brute forcing the HTTP OPTIONS on directories. One of the reasons someone would want this information is because if you're (accidentally, of course) allowing PUT methods on any directories, someone can upload something nasty and potentially execute an attack. The availability of PUT makes XSS attacks simple even for script kiddies, for example.
There may be legitimate reasons for enabling PUT on your servers, but you don't necessarily want the whole world to know that - just the applications that need the functionality. As with many pieces of information about your web architecture, you want (and need) to keep this secret.
Using network-side scripting you can easily intercept requests for HTTP OPTIONS and ensure that the information is not shared with just anyone. There are a plethora of ways in which you can deal with the request - from simply resetting the connection (rude, but effective) to determining who might be making the request, logging it, and deciding whether to provide the answer.
A similar solution can be implemented using configuration options in Apache and other web application servers to be sure, but using network-side scripting provides greater flexibility and simplicity in implementing a solution. A single network-side script can provide a solution that prevents the retrieval of HTTP OPTIONS for an entire site, while most server-side solutions require the configuration and deployment of multiple files and/or across multiple servers. Using network-side scripting also allows you the option to identify requests based on a variety of parameters not always available in a server-side solution that can make implementation easier if you have a legitimate need to allow some applications access to HTTP OPTIONS.
Network-side scripting also allows you to examine virtually any aspect of the request - from the HTTP headers to the data (if any) being exchanged - in order to make a determination whether the request should be honored or not. Basically, you need to:
- Intercept HTTP requests
- Examine the HTTP method
- If the method is OPTIONS, determine how to react
- Do it!
Here's the core of an iRule to stop folks from gathering this kind of information from your site.
when HTTP_REQUEST {
set method [HTTP::method]
if {$method eq "OPTIONS"} {
HTTP::respond 200 content "No. Not yours."
}
}
You could also specifically look for the methods you want to manage - PUT for example - and deal only with them in the case that some applications you have may need the functionality (unlikely, but possible).
Obviously you'll want something a bit more expansive to address how you - and your organization - want to deal with requests like this, but the core of the script offers you the foundation upon which to build out a solution more specific to your site and application needs.
Technorati Tags:
MacVittie,
F5,
network-side scripting,
iRules,
tscci security,
Marcin,
HTTP,
OPTIONS,
security,
web application security,
PUT,
brute force,
prevention,
internet,
web,
blog
