this attack exploits web servers that accept many HTTP verbs and methods. web servers are exploited by sending malicious requests using unexpected methods, which may lead to bypassing the web application's authorization mechanism or even bypassing its security controls against other web attacks. Insecure Web Server Configurations and insecure coding can allow the bypass of HTTP Basic Authentication prompt on certain pages.
#insecure configuration
<Limit GET POST>
Require valid-user
</Limit>
* although the configuration specifies both GET and POST requests for the
authentication method, an attacker may still use a different HTTP
method (like HEAD) to bypass this authentication mechanism altogether
- this eventually leads to an authentication bypass and allows attackers to access web pages and domains they should not have access to.
#apache {000-default.conf} or {.htaccess} web page configuration file
<Directory "/var/www/html/admin">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile /etc/apache2/.htpasswd
<Limit GET>
Require valid-user
</Limit>
</Directory>
* this configuration is setting the authorization configurations for the admin web directory
- the <Limit GET> keyword is being used, the Require valid-user setting will only apply to GET requests, leaving the page accessible through POST requests. Even if both GET and POST were specified, this would leave the page accessible through other methods, like HEAD or OPTIONS.
#tomcat {web.xml} configuration file
<security-constraint>
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
* limited only to the GET method with http-method. this leaves the page accessible through other HTTP methods
#asp.net {web.config}
<system.web>
<authorization>
<allow verbs="GET" roles="admin">
<deny verbs="GET" users="*">
</deny>
</allow>
</authorization>
</system.web>
* the allow and deny scope is limited to the GET method. this leaves leaves the web application accessible through other HTTP methods
#insecure coding
$pattern = "/^[A-Za-z\s]+$/";
if(preg_match($pattern, $_GET["code"])) {
$query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
...SNIP...
}
* as the sanitization filter is only being tested on the GET parameter, the $_REQUEST["code"] parameters
could contain a post request containing SQL injection attacks
- this could eventually lead to bypassing security filters
#
if (isset($_REQUEST['filename'])) {
if (!preg_match('/[^A-Za-z0-9. _-]/', $_POST['filename'])) {
system("touch " . $_REQUEST['filename']);
} else {
echo "Malicious Request Denied!";
}
}
* the preg_match filter only checks for special characters in POST parameters with $_POST['filename']. However, the final system command uses the $_REQUEST['filename'] variable, which covers both GET and POST parameters.
if an attacker sends malicious input through a GET request, it will not get stopped by the preg_match function
MITIGATION
INSECURE CONFIGURATION
it is not secure to limit the authorization configuration to a specific HTTP verb. it is recommended to always avoid restricting authorization to a particular HTTP method and always allow/deny all HTTP verbs and methods. if single method must be specified, use safe keywords, like LimitExcept in Apache, http-method-omission in Tomcat, and add/remove in ASP.NET
consider disabling/denying all HEAD requests unless specifically required by the web application
INSECURE CODING
minor inconsistencies in the use of HTTP methods can lead to critical vulnerabilities. be consistent with the use of HTTP methods and ensure that the same method is always used for any specific functionality across the web application
expand the scope of testing in security filters by testing all request parameters. this should avoid vulnerabilities and filter bypasses.
