https://wiki.owasp.org/api.php?action=feedcontributions&user=Abian+Blome&feedformat=atomOWASP - User contributions [en]2024-03-29T08:14:12ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Test_HTTP_Methods_(OTG-CONFIG-006)&diff=146422Test HTTP Methods (OTG-CONFIG-006)2013-03-03T16:12:29Z<p>Abian Blome: Fixed references</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
== Brief Summary ==<br />
HTTP offers a number of methods that can be used to perform actions 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 misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the server's HTTP TRACE method, is examined.<br><br />
<br />
== Short Description of the Issue == <br />
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 today standard) defines the following eight methods:<br />
<br />
* HEAD<br />
* GET<br />
* POST<br />
* PUT<br />
* DELETE<br />
* TRACE<br />
* OPTIONS<br />
* CONNECT<br />
<br />
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:<br />
<br />
* 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<br />
* 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<br />
* CONNECT: This method could allow a client to use the web server as a proxy<br />
* 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 discovered by Jeremiah Grossman (see links at the bottom of the page)<br />
<br />
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.<br />
<br />
== Arbitrary HTTP Methods ==<br />
<br />
Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen and/or arbitrary HTTP methods to bypass an environment level access control check:<br />
<br />
* 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<br />
<br />
* 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 again 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.<br />
<br />
In many cases, code which explicitly checked for a "GET" or "POST" method would be safe. <br />
<br />
<br />
== Black Box testing and example ==<br />
'''Discover the Supported Methods''' <br><br />
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that, "The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI". <br />
<br />
The testing method is extremely straightforward and we only need to fire up netcat (or telnet):<br />
<pre><br />
icesurfer@nightblade ~ $ nc www.victim.com 80 <br />
OPTIONS / HTTP/1.1<br />
Host: www.victim.com<br />
<br />
HTTP/1.1 200 OK<br />
Server: Microsoft-IIS/5.0<br />
Date: Tue, 31 Oct 2006 08:00:29 GMT<br />
Connection: close<br />
Allow: GET, HEAD, POST, TRACE, OPTIONS<br />
Content-Length: 0<br />
<br />
icesurfer@nightblade ~ $ <br />
</pre><br />
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section<br><br><br />
'''Test XST Potential'''<br><br />
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[XSS |Cross Site Scripting attacks]].<br />
<br />
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 introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access 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.<br />
<br />
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), we can proceed as shown in the following example:<br />
<pre><br />
icesurfer@nightblade ~ $ nc www.victim.com 80<br />
TRACE / HTTP/1.1<br />
Host: www.victim.com<br />
<br />
HTTP/1.1 200 OK<br />
Server: Microsoft-IIS/5.0<br />
Date: Tue, 31 Oct 2006 08:01:48 GMT<br />
Connection: close<br />
Content-Type: message/http<br />
Content-Length: 39<br />
<br />
TRACE / HTTP/1.1<br />
Host: www.victim.com<br />
</pre><br />
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct 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.<br />
<br />
There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM 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 attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:<br />
<br />
# 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<br />
# 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.<br />
<br />
More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman.<br><br />
<br />
== Black Box Testing of HTTP method tampering ==<br />
<br />
Testing for HTTP method tampering is essentially the same as testing for XST. <br />
<br />
=== Testing for arbitrary HTTP methods ===<br />
<br />
Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization. <br />
<br />
<pre><br />
[rapidoffenseunit:~] vanderaj% nc www.example.com 80<br />
JEFF / HTTP/1.1<br />
Host: www.example.com<br />
<br />
HTTP/1.1 200 OK<br />
Date: Mon, 18 Aug 2008 22:38:40 GMT<br />
Server: Apache<br />
Set-Cookie: PHPSESSID=K53QW...<br />
</pre><br />
<br />
If your 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.<br />
<br />
If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:<br />
<br />
* FOOBAR /admin/createUser.php?member=myAdmin<br />
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123<br />
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add<br />
<br />
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.<br />
<br />
=== Testing for HEAD access control bypass ===<br />
<br />
Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization. <br />
<br />
<pre><br />
[rapidoffenseunit:~] vanderaj% nc www.example.com 80<br />
HEAD /admin HTTP/1.1<br />
Host: www.example.com<br />
<br />
HTTP/1.1 200 OK<br />
Date: Mon, 18 Aug 2008 22:44:11 GMT<br />
Server: Apache<br />
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly<br />
Expires: Thu, 19 Nov 1981 08:52:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com<br />
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com<br />
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com<br />
Content-Language: EN<br />
Connection: close<br />
Content-Type: text/html; charset=ISO-8859-1<br />
</pre><br />
<br />
If you get a "405 Method not allowed" or "501 Method Unimplemented", the 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. <br />
<br />
If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:<br />
<br />
* HEAD /admin/createUser.php?member=myAdmin<br />
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123<br />
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add<br />
<br />
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, all using blind request submission.<br />
<br />
== Gray Box testing and example == <br />
The testing in a Gray Box scenario follows the same steps of a Black Box scenario.<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1"<br />
* RFC 2109 and RFC 2965: "HTTP State Management Mechanism"<br />
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf<br><br />
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433<br />
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf<br />
<br />
<br />
'''Tools'''<br />
* NetCat - http://nc110.sourceforge.net<br />
<br></div>Abian Blomehttps://wiki.owasp.org/index.php?title=OWASP_Testing_Guide_v4_Table_of_Contents&diff=136725OWASP Testing Guide v4 Table of Contents2012-09-28T09:29:00Z<p>Abian Blome: Added Abian Blome as a contributor</p>
<hr />
<div>__NOTOC__<br />
<br />
'''This is DRAFT of the table of content of the New Testing Guide v4.'''<br><br />
<br>You can download the stable version [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br><br />
<br />
Back to the OWASP Testing Guide Project:<br />
http://www.owasp.org/index.php/OWASP_Testing_Project<br />
<br />
'''Updated: 31st August 2012'''<br />
<br />
[[ OWTGv4 Contributors list|'''Contributors List]]<br />
<br />
----<br />
<br />
The following are the main improvements we have to realize: <br><br />
<br />
(1) - Add new testing techniques and OWASP Top10 update: <br><br />
- Testing for HTTP Verb tampering<br><br />
- Testing for HTTP Parameter Pollutions<br><br />
- Testing for URL Redirection<br><br />
- Testing for Insecure Direct Object References<br><br />
- Testing for Insecure Cryptographic Storage<br><br />
- Testing for Failure to Restrict URL Access<br><br />
- Testing for Insufficient Transport Layer Protection<br><br />
- Testing for Unvalidated Redirects and Forwards.<br><br />
<br><br />
(2) - Review and improve all the sections in v3,<br><br />
<br><br />
(3) - Create a more readable guide, eliminating some sections that are not<br />
really useful, Rationalize some sections as Session Management Testing.<br />
<br />
(4) Pavol says: - add new opensource testing tools that appeared during last 3 years<br />
(and are missing in the OWASP Testing Guide v3)<br />
<br />
- add few useful and life-scenarios of possible<br />
vulnerabilities in Bussiness Logic Testing (many testers have no idea what<br />
vulnerabilities in Business Logic exactly mean)<br />
<br />
- "Brute force testing" of "session ID" is missing in "Session Management<br />
Testing", describe other tools for Session ID entropy analysis<br />
(e.g. Stompy)<br />
<br />
- in "Data Validation Testing" describe some basic obfuscation methods for<br />
malicious code injection including the statements how it is possible to<br />
detect it (web application obfuscation is quite succesfull in bypassing<br />
many data validation controls)<br />
<br />
- split the phase Logout and Browser Cache Management" into two sections<br />
<br><br />
The following is a DRAFT of the Toc based on the feedback already received.<br />
<br />
== Table of Contents ==<br />
<br />
==[[Testing Guide Foreword|Foreword by OWASP Chair]]== <br />
[To review--> OWASP Chair]<br />
<br />
==[[Testing Guide Frontispiece |1. Frontispiece]]== <br />
[To review--> Mat]<br />
<br />
'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]''' <br />
[To review--> Mat]<br />
<br />
'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]''' <br />
[To review--> ]<br />
<br />
<br />
==[[Testing Guide Introduction|2. Introduction]]==<br />
<br />
'''2.1 The OWASP Testing Project'''<br />
<br />
'''2.2 Principles of Testing'''<br />
<br />
'''2.3 Testing Techniques Explained''' <br />
<br />
2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]<br />
<br />
2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]<br />
<br />
==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==<br />
<br />
'''3.1. Overview'''<br />
<br />
'''3.2. Phase 1: Before Development Begins '''<br />
<br />
'''3.3. Phase 2: During Definition and Design'''<br />
<br />
'''3.4. Phase 3: During Development'''<br />
<br />
'''3.5. Phase 4: During Deployment'''<br />
<br />
'''3.6. Phase 5: Maintenance and Operations'''<br />
<br />
'''3.7. A Typical SDLC Testing Workflow '''<br />
<br />
==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==<br />
<br />
[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]<br />
<br />
[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]<br />
<br />
[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]<br />
<br />
[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]<br />
<br />
Infrastructure Configuration management weakness<br><br />
Application Configuration management weakness<br><br />
File extensions handling<br><br />
Old, backup and unreferenced files<br><br />
Access to Admin interfaces<br><br />
Bad HTTP Methods enabled, [new - Abian Blome]<br><br />
Informative Error Messages<br><br />
Database credentials/connection strings available<br><br />
Missing or weakly defined for Content Security Policy[New!]<br><br />
Missing HSTS header[New!]<br><br />
Missing or weakly defined RIA policy files[New!]<br><br />
Incorrect time[New!]<br><br />
Unpatched components and libraries (e.g. JavaScript libraries)[New!]<br><br />
Test data in production systems (and vice versa)[New!]<br><br />
<br />
[[Testing for authentication|'''4.4 Authentication Testing ''']] <br />
<br />
Credentials transport over an unencrypted channel [Robert Winkel]<br><br />
User enumeration (also Guessable user account) [Robert Winkel]<br><br />
Default or test accounts[New!]<br><br />
Default passwords [Robert Winkel]<br><br />
Weak lock out mechanism [New! - Robert Winkel] <br><br />
Account lockout DoS [New! - Robert Winkel]<br><br />
Bypassing authentication schema<br> <br />
Vulnerable remember password [Robert Winkel]<br><br />
Browser cache weakness [New! - Abian Blome]<br><br />
Weak or unenforced password policy [New! - Robert Winkel]<br><br />
Weak or unenforced username policy [New! - Robert Winkel]<br><br />
Weak security question/answer [New! - Robert Winkel]<br> <br />
Failure to restrict access to authenticated resource [New!]<br> <br />
Weak password change function [New! - Robert Winkel]<br><br />
Testing for CAPTCHA<br><br />
Weaker authentication in alternative channel (e.g. mobile app, IVR, help desk) [New!]<br><br />
<br />
<br />
[[Testing for Session Management|'''4.5 Session Management Testing''']] <br />
<br />
Bypassing Session Management Schema <br><br />
Weak Session Token <br><br />
Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity<br> <br />
Exposed sensitive session variables <br><br />
CSRF <br><br />
Session passed over http [New!] <br><br />
Session token within URL [New!]<br><br />
Session Fixation <br><br />
Session token not removed on server after logout [New!]<br><br />
Persistent session token [New!]<br><br />
Session token not restricted properly (such as domain or path not set properly) [New! - Abian Blome]<br><br />
Logout function not properly implemented <br><br />
Session puzzling[New! - Abian Blome]<br><br />
Missing user-viewable log of authentication events[New!]<br><br />
<br />
[[Testing for Authorization|'''4.6 Authorization Testing''']] <br />
<br />
Bypassing authorization schema <br><br />
Directory traversal/file include [Juan Galiana] <br> <br />
Privilege Escalation [Irene Abezgauz] <br><br />
Insecure Direct Object References [Irene Abezgauz] <br><br />
Failure to Restrict access to authorized resource [New!]<br><br />
Server component has excessive privileges (e.g. indexing service, reporting interface, file generator)[New!]<br><br />
Lack of enforcement of application entry points (including exposure of objects)[New!]<br><br />
<br />
[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]<br />
Business Logic<br><br />
<br />
Business logic data validation[New!]<br><br />
Ability to forge requests[New!]<br><br />
Lack of integrity checks (e.g. overwriting updates) [New!]<br><br />
Lack of tamper evidence[New!]<br><br />
Use of untrusted time source[New!]<br><br />
Lack of limits to excessive rate (speed) of use[New!]<br><br />
Lack of limits to size of request[New!]<br><br />
Lack of limit to number of times a function can be used[New!]<br><br />
Bypass of correct sequence[New!]<br><br />
Missing user-viewable log of actvity[New!]<br><br />
Self-hosted payment cardholder data processing[New!]<br><br />
Lack of security incident reporting information[New!]<br><br />
Defenses against application mis-use[New!]<br><br />
<br />
[[Testing for Data Validation|'''4.8 Data Validation Testing''']] <br />
<br />
Reflected XSS <br><br />
Stored XSS <br><br />
HTTP Verb Tampering [Brad Causey]<br> <br />
HTTP Parameter pollution [Brad Causey]<br><br />
Unvalidated Redirects and Forwards [Brad Causey]<br> <br />
SQL Injection [Brad Causey]<br><br />
LDAP Injection <br><br />
ORM Injection <br><br />
XML Injection <br><br />
SSI Injection <br><br />
XPath Injection <br><br />
SOAP Injection <br><br />
IMAP/SMTP Injection <br><br />
Code Injection <br><br />
NoSQL injection[New!]<br><br />
OS Commanding [Juan Galiana]<br><br />
Buffer overflow <br><br />
Incubated vulnerability <br> <br />
HTTP Splitting/Smuggling [Juan Galiana]<br><br />
Regular expression DoS[New!]<br><br />
<br />
[[Testing for Data Encryption (New!)]]<br />
<br />
Application did not use encryption <br><br />
Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection<br><br />
Cacheable HTTPS Response<br><br />
Cache directives insecure<br><br />
Insecure Cryptographic Storage [mainly CR Guide]<br><br />
Sensitive information sent via unencrypted<br />
channels <br><br />
<br />
[[ XML Interpreter? (New!)]]<br />
<br />
Weak XML Structure<br />
XML content-level<br />
WS HTTP GET parameters/REST<br />
WS Naughty SOAP attachments<br />
WS Replay Testing<br />
<br />
[[ Client Side Testing (New!) ]]<br />
<br />
DOM XSS<br><br />
HTML5 [Juan Galiana]<br/><br />
Cross Site Flashing<br><br />
ClickHijacking<br><br />
<br />
==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==<br />
<br />
[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]<br />
<br />
[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]<br />
<br />
==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==<br />
<br />
* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]<br />
<br />
==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==<br />
* Whitepapers [To review--> contributor here]<br />
* Books [To review--> contributor here]<br />
* Useful Websites [To review--> contributor here]<br />
<br />
==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==<br />
<br />
* Fuzz Categories [To review--> contributor here]<br />
<br />
<br />
==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==<br />
<br />
[To review--> contributor here]<br />
<br />
----<br />
<br />
<br />
[[Category:OWASP Testing Project]]</div>Abian Blome