Summary
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged ac- tivities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
An application may require an administrator interface to enable a priv- ileged user to access functionality that may make changes to how the site functions. Such changes may include:
• user account provisioning • site design and layout • data manipulation • configuration changes
In many instances, such interfaces do not have sufficient controls to protect them from unauthorized access. Testing is aimed at discover- ing these administrator interfaces and accessing functionality intend- ed for the privileged users.
How to Test Black Box Testing
The following section describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used to test for related issues including privilege escalation, and are described elsewhere in this guide(for example Testing for bypassing authorization schema (OTG-AUTHZ-002) and Testing for Insecure Di- rect Object References (OTG-AUTHZ-004) in greater detail.
• Directory and file enumeration. An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting: /admin or /administrator etc.. or in some scenarios can be revealed within seconds using Google dorks.
• There are many tools available to perform brute forcing of server <Location ~ “.snapshot”>
Order deny,allow Deny from all </Location>
<input type=”hidden” name=”admin” value=”no”>
Cookie: session_cookie; useradmin=0
contents, see the tools section below for more information. * A tester may have to also identify the file name of the administration page. Forcibly browsing to the identified page may provide access to the interface.
• Comments and links in source code. Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.
• Reviewing server and application documentation. If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.
• Publicly available information. Many applications such as wordpress have default administrative interfaces .
• Alternative server port. Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat’s Administration interface can often be seen on port 8080.
• Parameter tampering. A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this include the presence of hidden fields such as:
or in a cookie:
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authenti- cation. If this fails, the tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for ad- ministrative account lockout if such functionality is present.
Gray Box Testing
A more detailed examination of the server and application compo- nents should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all compo- nents do not use default credentials or configurations.
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to en- sure clear separation between the drawing of such components and information leakage from such shared functionality.
Tools
• Dirbuster This currently inactive OWASP project is still a great tool for brute forcing directories and files on the server.
• THC-HYDRA is a tool that allows brute-forcing of many interfaces, including form-based HTTP authentication.
example the netsparker dictionary.
References
• Default Password list: http://www.governmentsecurity.org/articles/ DefaultLoginsandPasswordsforNetworkedDevices.php
• Default Password list: http://www.cirt.net/passwords
Test HTTP Methods (OTG-CONFIG-006)
Summary
HTTP offers a number of methods that can be used to perform ac- tions on the web server. Many of theses methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is mis- configured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the server’s HTTP TRACE method, is examined. While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the standard today) defines the following eight methods:
• HEAD • GET • POST • PUT • DELETE • TRACE • OPTIONS • CONNECT
Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:
• PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim’s server as a file repository.
• DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
• CONNECT: This method could allow a client to use the web server as a proxy.
• TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been dis- covered by Jeremiah Grossman (see links at the bottom of the page). If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.
Arbitrary HTTP Methods
Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen or arbitrary HTTP methods to by-
pass an environment level access control check:
• Many frameworks and languages treat “HEAD” as a “GET” request, albeit one without any body in the response. If a security constraint was set on “GET” requests such that only “authenticatedUsers” could access GET requests for a particular servlet or resource, it would be bypassed for the “HEAD” version. This allowed unauthorized blind submission of any privileged GET request. • Some frameworks allowed arbitrary HTTP methods such as “JEFF”
or “CATS” to be used without limitation. These were treated as if a “GET” method was issued, and were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.
In many cases, code which explicitly checked for a “GET” or “POST” method would be safe.
How to Test
Discover the Supported Methods
To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being exam- ined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OP- TIONS method represents a request for information about the com- munication options available on the request/response chain identi- fied by the Request-URI”.
The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
As we can see in the example, OPTIONS provides a list of the meth- ods that are supported by the web server, and in this case we can see that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section
Test XST Potential
Note: in order to understand the logic and the goals of this attack one must be familiar with Cross Site Scripting attacks.
The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users’ credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the HTTPOnly tag that Microsoft in- troduced in Internet Explorer 6 SP1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recur- ring attack patterns in Cross Site Scripting is to access the docu- ment.cookie object and send it to a web server controlled by the
$ nc www.victim.com 80 OPTIONS / HTTP/1.1 Host: www.victim.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS Content-Length: 0
attacker so that he or she can hijack the victim’s session. Tagging a cookie as httpOnly forbids JavaScript from accessing it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.
As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), the tester can proceed as shown in the following example:
The response body is exactly a copy of our original request, mean- ing that the target allows this method. Now, where is the danger lurking? If the tester instructs a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore be echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.
There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XM- LDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attack- er needs to combine the TRACE method with another vulnerability in order to mount the attack.
An attacker has two ways to successfully launch a Cross Site Trac- ing attack:
• Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet that contains the TRACE request in the vulnerable application, as in a normal Cross Site Scripting attack
• Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.
More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman.
$ nc www.victim.com 80 TRACE / HTTP/1.1 Host: www.victim.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT Connection: close Content-Type: message/http Content-Length: 39 TRACE / HTTP/1.1 Host: www.victim.com $ nc www.example.com 80 HEAD /admin HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post- check=0, pre-check=0
Testing for arbitrary HTTP methods
Find a page to visit that has a security constraint such that it would normally force a 302 redirect to a log in page or forces a log in directly. The test URL in this example works like this, as do many web applications. However, if a tester obtains a “200” response that is not a log in page, it is possible to bypass authentication and thus authorization.
If the framework or firewall or application does not support the “JEFF” method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.
If the tester feels that the system is vulnerable to this issue, they should issue CSRF-like attacks to exploit the issue more fully: • FOOBAR /admin/createUser.php?member=myAdmin • JEFF/admin/changePw.php?member=myAdmin&passwd= foo123&confirm=foo123
• CATS /admin/groupEdit.php?group=Admins&member=myAd min&action=add
With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin- istrator.
Testing for HEAD access control bypass
Find a page to visit that has a security constraint such that it would normally force a 302 redirect to a log in page or forces a log in directly. The test URL in this example works like this, as do many web applications. However, if the tester obtains a “200” response that is not a login page, it is possible to bypass authentication and thus authorization.
$ nc www.example.com 80 JEFF / HTTP/1.1
Host: www.example.com HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT Server: Apache
If the tester gets a “405 Method not allowed” or “501 Method Unimplemented”, the target (application/framework/language/ system/firewall) is working correctly. If a “200” response code comes back, and the response contains no body, it’s likely that the application has processed the request without authentication or authorization and further testing is warranted.
If the tester thinks that the system is vulnerable to this issue, they should issue CSRF-like attacks to exploit the issue more fully: • HEAD /admin/createUser.php?member=myAdmin
• HEAD /admin/changePw.php?member=myAdmin&passwd= foo123&confirm=foo123
• HEAD /admin/groupEdit.php?group=Admins&member=myAd min&action=add
With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin- istrator, all using blind request submission.
Tools
• NetCat - http://nc110.sourceforge.net • cURL - http://curl.haxx.se/
References Whitepapers
• RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1” • RFC 2109 and RFC 2965: HTTP State Management
Mechanism”
• Jeremiah Grossman: “Cross Site Tracing (XST)” -
http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_ XST_ebook.pdf
• Amit Klein: “XS(T) attack variants which can, in some cases,
eliminate the need for TRACE” - http://www.securityfocus.com/
archive/107/308433
• Arshan Dabirsiaghi: “Bypassing VBAAC with HTTP Verb
Tampering” - http://static.swpag.info/download/Bypassing_
VBAAC_with_HTTP_Verb_Tampering.pdf
Test HTTP Strict Transport Security
(OTG-CONFIG-007)
Summary
The HTTP Strict Transport Security (HSTS) header is a mechanism that web sites have to communicate to the web browsers that all traffic exchanged with a given domain must always be sent over
https, this will help protect the information from being passed over unencrypted requests.
Considering the importance of this security measure it is import- ant to verify that the web site is using this HTTP header, in order to ensure that all the data travels encrypted from the web browser to the server.
The HTTP Strict Transport Security (HSTS) feature lets a web application to inform the browser, through the use of a special response header, that it should never establish a connection to the the specified domain servers using HTTP. Instead it should automatically establish all connection requests to access the site through HTTPS.
The HTTP strict transport security header uses two directives: • max-age: to indicate the number of seconds that the browser
should automatically convert all HTTP requests to HTTPS. • includeSubDomains: to indicate that all web application’s sub-
domains must use HTTPS.
Here’s an example of the HSTS header implementation:
The use of this header by web applications must be checked to find if the following security issues could be produced:
• Attackers sniffing the network traffic and accessing
the information transferred through an unencrypted channel. • Attackers exploiting a man in the middle attack because of the
problem of accepting certificates that are not trusted.
• Users who mistakenly entered an address in the browser putting HTTP instead of HTTPS, or users who click on a link in a web application which mistakenly indicated the http protocol.
How to Test
Testing for the presence of HSTS header can be done by checking for the existence of the HSTS header in the server’s response in an interception proxy, or by using curl as follows:
Result expected:
References
• OWASP HTTP Strict Transport Security - https://www.owasp.
org/index.php/HTTP_Strict_Transport_Security
• OWASP Appsec Tutorial Series - Episode 4: Strict Transport
Security - http://www.youtube.com/watch?v=zEV3HOuM_Vw • HSTS Specification: http://tools.ietf.org/html/rfc6797 Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug- 2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug- 2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug- 2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN Connection: close
Content-Type: text/html; charset=ISO-8859-1
Strict-Transport-Security: max-age=60000; includeSubDomains
$ curl -s -D- https://domain.com/ | grep Strict
• Generating server responses that may be treated as cross- domain policy files.
• Using file upload functionality to upload files that may be treated as cross-domain policy files.
Impact of abusing cross-domain access
• Defeat CSRF protections.
• Read data restricted or otherwise protected by cross-origin pol- icies.
How to Test
Testing for RIA policy files weakness:
To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application’s root, and from every folder found.
For example, if the application’s URL is http://www.owasp.org, the tester should try to download the files http://www.owasp.org/ crossdomain.xml and http://www.owasp.org/clientaccesspolicy. xml.
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are neces- sary. Overly permissive policies should be avoided. Policies with “*” in them should be closely examined.
Example:
Result Expected:
• A list of policy files found. • A weak settings in the policies.
Tools
• Nikto
• OWASP Zed Attack Proxy Project • W3af
References Whitepapers
• UCSD: “Analyzing the Crossdomain Policies of Flash