https://wiki.owasp.org/api.php?action=feedcontributions&user=Kcheng&feedformat=atomOWASP - User contributions [en]2024-03-28T15:48:06ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Talk:OWASP_Risk_Rating_Methodology&diff=16257Talk:OWASP Risk Rating Methodology2007-02-07T17:44:59Z<p>Kcheng: What about compensating controls?</p>
<hr />
<div>Just editing now... [[User:Vanderaj|Vanderaj]] 12:04, 22 December 2006 (EST)<br />
<br />
== What about compensating controls? ==<br />
<br />
I think it is worthwhile to factor in compensating controls into likelihood and impact. For example, if the organization implements an XML firewall, it can reduce like likelihood some data-based attacks. Alternatively, if they backup their data every hour, the impact is then reduced.</div>Kchenghttps://wiki.owasp.org/index.php?title=Talk:Testing_for_CSRF_(OTG-SESS-005)&diff=16234Talk:Testing for CSRF (OTG-SESS-005)2007-02-06T17:39:18Z<p>Kcheng: Point 3 needs to be clarified</p>
<hr />
<div>This chapter really should be called Cross site request forgeries. Session riding is becoming old skool. [[User:Vanderaj|Vanderaj]] 20:25, 15 January 2007 (EST)<br />
<br><br />
Good Call. Jeff has made the changes. [[User:Mmeucci|Matteo Meucci]] 20.00, 18 Janaury 2007<br />
<br />
== Point 3 needs to be clarified ==<br />
<br />
Point 3 states "Point 3) By “known by the browser” we mean information such as cookies or http-based authentication information (such as Basic Authentication; NOT form-based authentication)..."<br />
<br />
Form-based authentication in its generic sense, means that we initially perform authentication via a form. If we do this, our session ID can be stored in a non-persistent cookie (e.g., session cookie), which is still vulnerable to CSRF attacks since they are automatically sent along with every request. I think implying that form-based authentication is secure is inaccurate. The only time form-based authN is safe from CSRF is if session cookies are not used and the session ID is rewritten in the URL (though this is another vulnerability in itself).</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Session_Management_Schema_(OTG-SESS-001)&diff=16214Testing for Session Management Schema (OTG-SESS-001)2007-02-05T21:59:20Z<p>Kcheng: /* Gray Box testing and example */ spelling</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan.<br><br><br />
These mechanisms are known as Session Management and while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a pen tester to gain access to a user account without the need to provide correct credentials.<br />
<br><br />
<br />
== Description of the Issue == <br />
The session management schema should be considered alongside the authentication and authorization schema, and cover at least the questions below from a non-technical point of view:<br />
* Will the application be accessed from shared systems? e.g. Internet Café <br><br />
* Is application security of prime concern to the visiting client/customer? <br><br />
* How many concurrent sessions may a user have? <br><br />
* How long is the inactive timeout on the application?<br> <br />
* How long is the active timeout? <br><br />
* Are sessions transferable from one source IP to another? <br><br />
* Is ‘remember my username’ functionality provided? <br><br />
* Is ‘automatic login’ functionality provided? <br><br />
Having identified the schema in place, the application and its logic must be examined to ensure the proper implementation of the schema.<br />
This phase of testing is intrinsically linked with general application security testing. Whilst the first Schema questions (is the schema suitable for the site and does the schema meet the application provider’s requirements?) can be analysed in abstract, the final question (does the site implement the specified schema?) must be considered alongside other technical testing. <br><br />
<br />
The identified schema should be analyzed against best practice within the context of the site during our penetration test.<br />
Where the defined schema deviates from security best practice, the associated risks should be identified and described within the context of the environment. Security risks and issues should be detailed and quantified, but ultimately the application provider must make decisions based on the security and usability of the application.<br />
For example, if it is determined that the site has been designed without inactive session timeouts, the application provider should be advised about risks such as replay attacks, long-term attacks based on stolen or compromised Session IDs, and abuse of a shared terminal where the application was not logged out. They must then consider these against other requirements such as convenience of use for clients and disruption of the application by forced re-authentication.<br />
<br><br />
''' Session Management Implementation'''<br><br />
In this Chapter we describe how to analyse a Session Schema and how to test it. Technical security testing of Session Management implementation covers two key areas:<br />
* Integrity of Session ID creation<br />
* Secure management of active sessions and Session IDs<br />
The Session ID should be sufficiently unpredictable and abstracted from any private information, and the Session management should be logically secured to prevent any manipulation or circumvention of application security.<br />
These two key areas are interdependent, but should be considered separately for a number of reasons.<br />
Firstly, the choice of underlying technology to provide the sessions is bewildering and can already include a large number of OTS products and an almost unlimited number of bespoke or proprietary implementations. Whilst the same technical analysis must be performed on each, established vendor solutions may require a slightly different testing approach, and existing security research may exist on the implementation.<br />
Secondly, even an unpredictable and abstract Session ID may be rendered completely ineffectual should the Session management be flawed. Similarly, a strong and secure session management implementation may be undermined by a poor Session ID implementation.<br />
Furthermore, the analyst should closely examine how (and if) the application uses the available Session management. It is not uncommon to see Microsoft ISS server ASP Session IDs passed religiously back and forth during interaction with an application, only to discover that these are not used by the application logic at all. It is therefore not correct to say that because an application is built on a ‘proven secure’ platform its Session Management is automatically secure.<br />
<br />
<br />
== Black Box testing and example ==<br />
<br />
''' Session Analysis'''<br><br />
<br />
The Session Tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br><br />
* Token Structure & Information Leakage<br />
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.<br />
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:<br />
<pre><br />
192.168.100.1:owaspuser:password:15:58<br />
</pre><br />
<br />
If part or the entire Token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.<br />
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:<br />
<pre><br />
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538<br />
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=<br />
MD5 01c2fc4f0a817afd8366689bd29dd40a<br />
</pre><br />
<br />
Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.<br />
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:<br />
<pre><br />
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412<br />
</pre><br />
<br />
Having analysed a single Session Token, the representative sample should be examined.<br />
A simple analysis of the Tokens should immediately reveal any obvious patterns. For example, a 32 bit Token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.<br />
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the Token generation. See Examples.<br />
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the Session Token.<br />
The following areas should be addressed during the single and multiple Session ID structure testing:<br />
* What parts of the Session ID are static? <br />
* What clear-text proprietary information is stored in the Session ID? <br />
e.g. usernames/UID, IP addresses <br />
* What easily decoded proprietary information is stored? <br />
* What information can be deduced from the structure of the Session ID? <br />
* What portions of the Session ID are static for the same login conditions? <br />
* What obvious patterns are present in the Session ID as a whole, or individual portions? <br />
<br />
'''Session ID Predictability and Randomness'''<br><br />
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.<br />
These analysis may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.<br />
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g. the same username, password and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.<br />
Variable elements should be analysed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo random elements.<br />
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.<br />
In analysing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.<br />
* Are the Session IDs provably random in nature? e.g. Can the result be reproduced? <br />
* Do the same input conditions produce the same ID on a subsequent run? <br />
* Are the Session IDs provably resistant to statistical or cryptanalysis? <br />
* What elements of the Session IDs are time-linked? <br />
* What portions of the Session IDs are predictable? <br />
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs? <br />
<br />
'''Brute Force Attacks'''<br><br />
Brute force attacks inevitably lead on from questions relating to predictability and randomness.<br />
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.<br />
A long session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.<br />
* How long would a brute-force attack on all possible Session IDs take? <br />
* Is the Session ID space large enough to prevent brute forcing? e.g. is the length of the key sufficient when compared to the valid life-span <br />
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?<br />
<br />
== Gray Box testing and example == <br />
If you can access to session management schema implementation, you can check for the following:<br />
* Random Session Token<br />
It's important that the sessionID or Cookie issued to the client will not easly predictable (don't use linear algorithm based on predictable variables like as data or client IPArddr). It's strongly encouraged the use of cryptographic algorithms as AES with minumum key lenght of 256 bits.<br />
* Token length<br />
SessionID will be at least 50 characters length.<br />
* Session Time-out<br />
Session token should have a defined time-out (it depends on the criticality of the application managed data)<br />
* Cookie configuration<br />
** non-persistent: only RAM memory<br />
** secure (inviato solo su canale HTTPS): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure<br />
** HTTPOnly (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HttpOnly<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net<br />
* RFCs 2109 & 2965: "HTTP State Management Mechanism" - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt<br />
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1" - http://www.ietf.org/rfc/rfc2616.txt<br />
<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Session_Management_Schema_(OTG-SESS-001)&diff=16213Testing for Session Management Schema (OTG-SESS-001)2007-02-05T21:55:40Z<p>Kcheng: /* Black Box testing and example */</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan.<br><br><br />
These mechanisms are known as Session Management and while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a pen tester to gain access to a user account without the need to provide correct credentials.<br />
<br><br />
<br />
== Description of the Issue == <br />
The session management schema should be considered alongside the authentication and authorization schema, and cover at least the questions below from a non-technical point of view:<br />
* Will the application be accessed from shared systems? e.g. Internet Café <br><br />
* Is application security of prime concern to the visiting client/customer? <br><br />
* How many concurrent sessions may a user have? <br><br />
* How long is the inactive timeout on the application?<br> <br />
* How long is the active timeout? <br><br />
* Are sessions transferable from one source IP to another? <br><br />
* Is ‘remember my username’ functionality provided? <br><br />
* Is ‘automatic login’ functionality provided? <br><br />
Having identified the schema in place, the application and its logic must be examined to ensure the proper implementation of the schema.<br />
This phase of testing is intrinsically linked with general application security testing. Whilst the first Schema questions (is the schema suitable for the site and does the schema meet the application provider’s requirements?) can be analysed in abstract, the final question (does the site implement the specified schema?) must be considered alongside other technical testing. <br><br />
<br />
The identified schema should be analyzed against best practice within the context of the site during our penetration test.<br />
Where the defined schema deviates from security best practice, the associated risks should be identified and described within the context of the environment. Security risks and issues should be detailed and quantified, but ultimately the application provider must make decisions based on the security and usability of the application.<br />
For example, if it is determined that the site has been designed without inactive session timeouts, the application provider should be advised about risks such as replay attacks, long-term attacks based on stolen or compromised Session IDs, and abuse of a shared terminal where the application was not logged out. They must then consider these against other requirements such as convenience of use for clients and disruption of the application by forced re-authentication.<br />
<br><br />
''' Session Management Implementation'''<br><br />
In this Chapter we describe how to analyse a Session Schema and how to test it. Technical security testing of Session Management implementation covers two key areas:<br />
* Integrity of Session ID creation<br />
* Secure management of active sessions and Session IDs<br />
The Session ID should be sufficiently unpredictable and abstracted from any private information, and the Session management should be logically secured to prevent any manipulation or circumvention of application security.<br />
These two key areas are interdependent, but should be considered separately for a number of reasons.<br />
Firstly, the choice of underlying technology to provide the sessions is bewildering and can already include a large number of OTS products and an almost unlimited number of bespoke or proprietary implementations. Whilst the same technical analysis must be performed on each, established vendor solutions may require a slightly different testing approach, and existing security research may exist on the implementation.<br />
Secondly, even an unpredictable and abstract Session ID may be rendered completely ineffectual should the Session management be flawed. Similarly, a strong and secure session management implementation may be undermined by a poor Session ID implementation.<br />
Furthermore, the analyst should closely examine how (and if) the application uses the available Session management. It is not uncommon to see Microsoft ISS server ASP Session IDs passed religiously back and forth during interaction with an application, only to discover that these are not used by the application logic at all. It is therefore not correct to say that because an application is built on a ‘proven secure’ platform its Session Management is automatically secure.<br />
<br />
<br />
== Black Box testing and example ==<br />
<br />
''' Session Analysis'''<br><br />
<br />
The Session Tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br><br />
* Token Structure & Information Leakage<br />
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.<br />
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:<br />
<pre><br />
192.168.100.1:owaspuser:password:15:58<br />
</pre><br />
<br />
If part or the entire Token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.<br />
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:<br />
<pre><br />
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538<br />
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=<br />
MD5 01c2fc4f0a817afd8366689bd29dd40a<br />
</pre><br />
<br />
Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.<br />
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:<br />
<pre><br />
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412<br />
</pre><br />
<br />
Having analysed a single Session Token, the representative sample should be examined.<br />
A simple analysis of the Tokens should immediately reveal any obvious patterns. For example, a 32 bit Token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.<br />
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the Token generation. See Examples.<br />
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the Session Token.<br />
The following areas should be addressed during the single and multiple Session ID structure testing:<br />
* What parts of the Session ID are static? <br />
* What clear-text proprietary information is stored in the Session ID? <br />
e.g. usernames/UID, IP addresses <br />
* What easily decoded proprietary information is stored? <br />
* What information can be deduced from the structure of the Session ID? <br />
* What portions of the Session ID are static for the same login conditions? <br />
* What obvious patterns are present in the Session ID as a whole, or individual portions? <br />
<br />
'''Session ID Predictability and Randomness'''<br><br />
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.<br />
These analysis may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.<br />
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g. the same username, password and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.<br />
Variable elements should be analysed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo random elements.<br />
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.<br />
In analysing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.<br />
* Are the Session IDs provably random in nature? e.g. Can the result be reproduced? <br />
* Do the same input conditions produce the same ID on a subsequent run? <br />
* Are the Session IDs provably resistant to statistical or cryptanalysis? <br />
* What elements of the Session IDs are time-linked? <br />
* What portions of the Session IDs are predictable? <br />
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs? <br />
<br />
'''Brute Force Attacks'''<br><br />
Brute force attacks inevitably lead on from questions relating to predictability and randomness.<br />
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.<br />
A long session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.<br />
* How long would a brute-force attack on all possible Session IDs take? <br />
* Is the Session ID space large enough to prevent brute forcing? e.g. is the length of the key sufficient when compared to the valid life-span <br />
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?<br />
<br />
== Gray Box testing and example == <br />
If you can access to session management schema implementation, you can check for the following:<br />
* Random Session Token<br />
It's important that the sessionID or Cookie issued to the client will not easly predictable (don't use linear algorithm based on predictable variables like as data or client IPArddr). It's strongly encouraged the use of cryptographic algorithms as AES with minumum key lenght of 256 bits.<br />
* Token lenght<br />
SessionID will be at least 50 characters length.<br />
* Session Time-out<br />
Session token should have a defined time-out (it depends on the criticality of the application managed data)<br />
* Cookie configuration<br />
** non-persistent: only RAM memory<br />
** secure (inviato solo su canale HTTPS): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure<br />
** HTTPOnly (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HttpOnly<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net<br />
* RFCs 2109 & 2965: "HTTP State Management Mechanism" - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt<br />
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1" - http://www.ietf.org/rfc/rfc2616.txt<br />
<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Session_Management_Schema_(OTG-SESS-001)&diff=16212Testing for Session Management Schema (OTG-SESS-001)2007-02-05T21:53:02Z<p>Kcheng: /* Brief Summary */ spelling</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan.<br><br><br />
These mechanisms are known as Session Management and while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a pen tester to gain access to a user account without the need to provide correct credentials.<br />
<br><br />
<br />
== Description of the Issue == <br />
The session management schema should be considered alongside the authentication and authorization schema, and cover at least the questions below from a non-technical point of view:<br />
* Will the application be accessed from shared systems? e.g. Internet Café <br><br />
* Is application security of prime concern to the visiting client/customer? <br><br />
* How many concurrent sessions may a user have? <br><br />
* How long is the inactive timeout on the application?<br> <br />
* How long is the active timeout? <br><br />
* Are sessions transferable from one source IP to another? <br><br />
* Is ‘remember my username’ functionality provided? <br><br />
* Is ‘automatic login’ functionality provided? <br><br />
Having identified the schema in place, the application and its logic must be examined to ensure the proper implementation of the schema.<br />
This phase of testing is intrinsically linked with general application security testing. Whilst the first Schema questions (is the schema suitable for the site and does the schema meet the application provider’s requirements?) can be analysed in abstract, the final question (does the site implement the specified schema?) must be considered alongside other technical testing. <br><br />
<br />
The identified schema should be analyzed against best practice within the context of the site during our penetration test.<br />
Where the defined schema deviates from security best practice, the associated risks should be identified and described within the context of the environment. Security risks and issues should be detailed and quantified, but ultimately the application provider must make decisions based on the security and usability of the application.<br />
For example, if it is determined that the site has been designed without inactive session timeouts, the application provider should be advised about risks such as replay attacks, long-term attacks based on stolen or compromised Session IDs, and abuse of a shared terminal where the application was not logged out. They must then consider these against other requirements such as convenience of use for clients and disruption of the application by forced re-authentication.<br />
<br><br />
''' Session Management Implementation'''<br><br />
In this Chapter we describe how to analyse a Session Schema and how to test it. Technical security testing of Session Management implementation covers two key areas:<br />
* Integrity of Session ID creation<br />
* Secure management of active sessions and Session IDs<br />
The Session ID should be sufficiently unpredictable and abstracted from any private information, and the Session management should be logically secured to prevent any manipulation or circumvention of application security.<br />
These two key areas are interdependent, but should be considered separately for a number of reasons.<br />
Firstly, the choice of underlying technology to provide the sessions is bewildering and can already include a large number of OTS products and an almost unlimited number of bespoke or proprietary implementations. Whilst the same technical analysis must be performed on each, established vendor solutions may require a slightly different testing approach, and existing security research may exist on the implementation.<br />
Secondly, even an unpredictable and abstract Session ID may be rendered completely ineffectual should the Session management be flawed. Similarly, a strong and secure session management implementation may be undermined by a poor Session ID implementation.<br />
Furthermore, the analyst should closely examine how (and if) the application uses the available Session management. It is not uncommon to see Microsoft ISS server ASP Session IDs passed religiously back and forth during interaction with an application, only to discover that these are not used by the application logic at all. It is therefore not correct to say that because an application is built on a ‘proven secure’ platform its Session Management is automatically secure.<br />
<br />
<br />
== Black Box testing and example ==<br />
<br />
''' Session Analysis'''<br><br />
<br />
The Session Tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br><br />
* Token Structure & Information Leakage<br />
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.<br />
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:<br />
<pre><br />
192.168.100.1:owaspuser:password:15:58<br />
</pre><br />
<br />
If part or the entire Token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.<br />
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:<br />
<pre><br />
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538<br />
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=<br />
MD5 01c2fc4f0a817afd8366689bd29dd40a<br />
</pre><br />
<br />
Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.<br />
Hybrid Rokens may include information such as IP address or User ID together with an encoded portion, as the following:<br />
<pre><br />
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412<br />
</pre><br />
<br />
Having analysed a single Session Token, the representative sample should be examined.<br />
A simple analysis of the Tokens should immediately reveal any obvious patterns. For example, a 32 bit Token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.<br />
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the Token generation. See Examples.<br />
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the Session Token.<br />
The following areas should be addressed during the single and multiple Session ID structure testing:<br />
* What parts of the Session ID are static? <br />
* What clear-text proprietary information is stored in the Session ID? <br />
e.g. usernames/UID, IP addresses <br />
* What easily decoded proprietary information is stored? <br />
* What information can be deduced from the structure of the Session ID? <br />
* What portions of the Session ID are static for the same login conditions? <br />
* What obvious patterns are present in the Session ID as a whole, or individual portions? <br />
<br />
'''Session ID Predictability and Randomness'''<br><br />
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.<br />
These analysis may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.<br />
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g. the same username, password and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.<br />
Variable elements should be analysed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo random elements.<br />
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.<br />
In analysing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.<br />
* Are the Session IDs provably random in nature? e.g. Can the result be reproduced? <br />
* Do the same input conditions produce the same ID on a subsequent run? <br />
* Are the Session IDs provably resistant to statistical or cryptanalysis? <br />
* What elements of the Session IDs are time-linked? <br />
* What portions of the Session IDs are predictable? <br />
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs? <br />
<br />
'''Brute Force Attacks'''<br><br />
Brute force attacks inevitably lead on from questions relating to predictability and randomness.<br />
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.<br />
A long session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.<br />
* How long would a brute-force attack on all possible Session IDs take? <br />
* Is the Session ID space large enough to prevent brute forcing? e.g. is the length of the key sufficient when compared to the valid life-span <br />
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?<br />
<br />
== Gray Box testing and example == <br />
If you can access to session management schema implementation, you can check for the following:<br />
* Random Session Token<br />
It's important that the sessionID or Cookie issued to the client will not easly predictable (don't use linear algorithm based on predictable variables like as data or client IPArddr). It's strongly encouraged the use of cryptographic algorithms as AES with minumum key lenght of 256 bits.<br />
* Token lenght<br />
SessionID will be at least 50 characters length.<br />
* Session Time-out<br />
Session token should have a defined time-out (it depends on the criticality of the application managed data)<br />
* Cookie configuration<br />
** non-persistent: only RAM memory<br />
** secure (inviato solo su canale HTTPS): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure<br />
** HTTPOnly (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HttpOnly<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net<br />
* RFCs 2109 & 2965: "HTTP State Management Mechanism" - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt<br />
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1" - http://www.ietf.org/rfc/rfc2616.txt<br />
<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Talk:Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16211Talk:Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:32:49Z<p>Kcheng: Direct page request image</p>
<hr />
<div>Can't seem to delete sections 4. It is redundant. Also, there is a mispelling of the word Authentication in the image.<br />
<br />
== Direct page request image ==<br />
<br />
Is it possible to replace the image below Direct Page Request with one that is more intuitive? I'm not exactly sure what the intent of that image was.</div>Kchenghttps://wiki.owasp.org/index.php?title=Talk:Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16210Talk:Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:30:42Z<p>Kcheng: </p>
<hr />
<div>Can't seem to delete sections 4. It is redundant. Also, there is a mispelling of the word Authentication in the image.</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16209Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:29:40Z<p>Kcheng: /* References */</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
<br />
While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security. <br />
<br />
Negligence, ignorance or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.<br />
<br />
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions. <br />
<br />
== Description of the Issue == <br />
<br />
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.<br />
<br />
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more.<br />
<br />
Problems in the development phase are for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.<br />
<br />
In addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.<br />
<br />
== Black Box testing and example ==<br />
There are several methods to bypass the authentication schema in use by a web application:<br />
* Direct page request (forced browsing)<br />
* Parameter Modification<br />
* Session ID Prediction<br />
* Sql Injection<br />
<br />
<br><br />
'''Direct page request'''<br />
<br />
If a web application implements access control only on the login page, the authentication schema could be bypassed. For example, if a user directly requests different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.<br />
<br />
<br />
[[Image:basm-directreq.jpg]]<br />
<br />
<br />
'''Parameter Modification'''<br />
<br />
Another problem related to authentication design is when the application verifies a succesful login based on fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST.<br />
<br />
<pre>http://www.site.com/page.asp?authenticated=no </pre><br />
<br />
<pre>raven@blackbox /home $nc www.site.com 80 <br />
GET /page.asp?authenticated=yes HTTP/1.0 <br />
<br />
HTTP/1.1 200 OK <br />
Date: Sat, 11 Nov 2006 10:22:44 GMT <br />
Server: Apache <br />
Connection: close <br />
Content-Type: text/html; charset=iso-8859-1 <br />
<br />
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <br />
<HTML><HEAD> <br />
</HEAD><BODY> <br />
<br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore, if Session ID generation is predictable, a malicious user could find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
The tester can use a tool such as WebScarab to perform session ID analysis. In the following figure, cookies values increase linearly as each one is generated, making it easy for an attacker to guess a valid session ID. The guessed session ID can then be inserted into the cookie in the tester's browser.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure, cookies values change only partially, so it's possible to restrict a bruteforce attack to the fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore if Session ID generation is predictable a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
In the following figure values inside cookies increase linearly, so could be easy for an attacker to guess a valid session ID.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure values inside cookies change only partially, so it's possible to restrict a bruteforce attack to the defined fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16208Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:28:45Z<p>Kcheng: /* References */</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
<br />
While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security. <br />
<br />
Negligence, ignorance or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.<br />
<br />
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions. <br />
<br />
== Description of the Issue == <br />
<br />
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.<br />
<br />
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more.<br />
<br />
Problems in the development phase are for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.<br />
<br />
In addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.<br />
<br />
== Black Box testing and example ==<br />
There are several methods to bypass the authentication schema in use by a web application:<br />
* Direct page request (forced browsing)<br />
* Parameter Modification<br />
* Session ID Prediction<br />
* Sql Injection<br />
<br />
<br><br />
'''Direct page request'''<br />
<br />
If a web application implements access control only on the login page, the authentication schema could be bypassed. For example, if a user directly requests different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.<br />
<br />
<br />
[[Image:basm-directreq.jpg]]<br />
<br />
<br />
'''Parameter Modification'''<br />
<br />
Another problem related to authentication design is when the application verifies a succesful login based on fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST.<br />
<br />
<pre>http://www.site.com/page.asp?authenticated=no </pre><br />
<br />
<pre>raven@blackbox /home $nc www.site.com 80 <br />
GET /page.asp?authenticated=yes HTTP/1.0 <br />
<br />
HTTP/1.1 200 OK <br />
Date: Sat, 11 Nov 2006 10:22:44 GMT <br />
Server: Apache <br />
Connection: close <br />
Content-Type: text/html; charset=iso-8859-1 <br />
<br />
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <br />
<HTML><HEAD> <br />
</HEAD><BODY> <br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore, if Session ID generation is predictable, a malicious user could find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
The tester can use a tool such as WebScarab to perform session ID analysis. In the following figure, cookies values increase linearly as each one is generated, making it easy for an attacker to guess a valid session ID. The guessed session ID can then be inserted into the cookie in the tester's browser.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure, cookies values change only partially, so it's possible to restrict a bruteforce attack to the fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore if Session ID generation is predictable a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
In the following figure values inside cookies increase linearly, so could be easy for an attacker to guess a valid session ID.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure values inside cookies change only partially, so it's possible to restrict a bruteforce attack to the defined fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16207Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:27:09Z<p>Kcheng: /* Black Box testing and example */ Added more instructions on "how" rather than "what"</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
<br />
While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security. <br />
<br />
Negligence, ignorance or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.<br />
<br />
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions. <br />
<br />
== Description of the Issue == <br />
<br />
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.<br />
<br />
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more.<br />
<br />
Problems in the development phase are for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.<br />
<br />
In addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.<br />
<br />
== Black Box testing and example ==<br />
There are several methods to bypass the authentication schema in use by a web application:<br />
* Direct page request (forced browsing)<br />
* Parameter Modification<br />
* Session ID Prediction<br />
* Sql Injection<br />
<br />
<br><br />
'''Direct page request'''<br />
<br />
If a web application implements access control only on the login page, the authentication schema could be bypassed. For example, if a user directly requests different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.<br />
<br />
<br />
[[Image:basm-directreq.jpg]]<br />
<br />
<br />
'''Parameter Modification'''<br />
<br />
Another problem related to authentication design is when the application verifies a succesful login based on fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST.<br />
<br />
<pre>http://www.site.com/page.asp?authenticated=no </pre><br />
<br />
<pre>raven@blackbox /home $nc www.site.com 80 <br />
GET /page.asp?authenticated=yes HTTP/1.0 <br />
<br />
HTTP/1.1 200 OK <br />
Date: Sat, 11 Nov 2006 10:22:44 GMT <br />
Server: Apache <br />
Connection: close <br />
Content-Type: text/html; charset=iso-8859-1 <br />
<br />
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <br />
<HTML><HEAD> <br />
</HEAD><BODY> <br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore, if Session ID generation is predictable, a malicious user could find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
The tester can use a tool such as WebScarab to perform session ID analysis. In the following figure, cookies values increase linearly as each one is generated, making it easy for an attacker to guess a valid session ID. The guessed session ID can then be inserted into the cookie in the tester's browser.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure, cookies values change only partially, so it's possible to restrict a bruteforce attack to the fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore if Session ID generation is predictable a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
In the following figure values inside cookies increase linearly, so could be easy for an attacker to guess a valid session ID.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure values inside cookies change only partially, so it's possible to restrict a bruteforce attack to the defined fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16206Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:26:06Z<p>Kcheng: /* References */ Section was duplicated - removing redundancy</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
<br />
While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security. <br />
<br />
Negligence, ignorance or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.<br />
<br />
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions. <br />
<br />
== Description of the Issue == <br />
<br />
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.<br />
<br />
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more.<br />
<br />
Problems in the development phase are for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.<br />
<br />
In addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.<br />
<br />
== Black Box testing and example ==<br />
There are several methods to bypass the authentication schema in use by a web application:<br />
* Direct page request (forced browsing)<br />
* Parameter Modification<br />
* Session ID Prediction<br />
* Sql Injection<br />
<br />
<br><br />
'''Direct page request'''<br />
<br />
If a web application implements access control only on the login page, the authentication schema could be bypassed. For example, if a user directly requests different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.<br />
<br />
<br />
[[Image:basm-directreq.jpg]]<br />
<br />
<br />
'''Parameter Modification'''<br />
<br />
Another problem related to authentication design is when the application verifies a succesful login based on fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST.<br />
<br />
<pre>http://www.site.com/page.asp?authenticated=no </pre><br />
<br />
<pre>raven@blackbox /home $nc www.site.com 80 <br />
GET /page.asp?authenticated=yes HTTP/1.0 <br />
<br />
HTTP/1.1 200 OK <br />
Date: Sat, 11 Nov 2006 10:22:44 GMT <br />
Server: Apache <br />
Connection: close <br />
Content-Type: text/html; charset=iso-8859-1 <br />
<br />
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <br />
<HTML><HEAD> <br />
</HEAD><BODY> <br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore if Session ID generation is predictable a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
In the following figure values inside cookies increase linearly, so could be easy for an attacker to guess a valid session ID.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure values inside cookies change only partially, so it's possible to restrict a bruteforce attack to the defined fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&diff=16205Testing for Bypassing Authentication Schema (OTG-AUTHN-004)2007-02-05T21:22:13Z<p>Kcheng: /* Black Box testing and example */ Added more instructions on "how" rather than "what"</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
<br />
While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security. <br />
<br />
Negligence, ignorance or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.<br />
<br />
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions. <br />
<br />
== Description of the Issue == <br />
<br />
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.<br />
<br />
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more.<br />
<br />
Problems in the development phase are for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.<br />
<br />
In addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.<br />
<br />
== Black Box testing and example ==<br />
There are several methods to bypass the authentication schema in use by a web application:<br />
* Direct page request (forced browsing)<br />
* Parameter Modification<br />
* Session ID Prediction<br />
* Sql Injection<br />
<br />
<br><br />
'''Direct page request'''<br />
<br />
If a web application implements access control only on the login page, the authentication schema could be bypassed. For example, if a user directly requests different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.<br />
<br />
<br />
[[Image:basm-directreq.jpg]]<br />
<br />
<br />
'''Parameter Modification'''<br />
<br />
Another problem related to authentication design is when the application verifies a succesful login based on fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST.<br />
<br />
<pre>http://www.site.com/page.asp?authenticated=no </pre><br />
<br />
<pre>raven@blackbox /home $nc www.site.com 80 <br />
GET /page.asp?authenticated=yes HTTP/1.0 <br />
<br />
HTTP/1.1 200 OK <br />
Date: Sat, 11 Nov 2006 10:22:44 GMT <br />
Server: Apache <br />
Connection: close <br />
Content-Type: text/html; charset=iso-8859-1 <br />
<br />
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <br />
<HTML><HEAD> <br />
</HEAD><BODY> <br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore, if Session ID generation is predictable, a malicious user could find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
The tester can use a tool such as WebScarab to perform session ID analysis. In the following figure, cookies values increase linearly as each one is generated, making it easy for an attacker to guess a valid session ID. The guessed session ID can then be inserted into the cookie in the tester's browser.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure, cookies values change only partially, so it's possible to restrict a bruteforce attack to the fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<H1>You Are Auhtenticated</H1> <br />
</BODY></HTML></pre><br />
<br />
<br />
[[Image:basm-parammod.jpg]]<br />
<br />
<br />
'''Session ID Prediction'''<br />
<br />
Many web applications manage authentication using session identification values(SESSION ID). Therefore if Session ID generation is predictable a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.<br />
<br />
In the following figure values inside cookies increase linearly, so could be easy for an attacker to guess a valid session ID.<br />
<br />
<br />
[[Image:basm-sessid.jpg]]<br />
<br />
<br />
In the following figure values inside cookies change only partially, so it's possible to restrict a bruteforce attack to the defined fields shown below.<br />
<br />
<br />
[[Image:basm-sessid2.jpg]]<br />
<br />
<br />
<br />
'''Sql Injection (HTML Form Authentication)'''<br />
<br />
SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.<br />
<br />
<br />
[[Image:basm-sqlinj.jpg]]<br />
<br />
<br />
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.<br />
<br />
<br />
[[Image:basm-sqlinj2.gif]]<br />
<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Mark Roxberry: "PHPBB 2.0.13 vulnerability" <br />
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf<br />
<br />
<br><br />
'''Tools'''<br><br />
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Brute_Force_(OWASP-AT-004)&diff=16198Testing for Brute Force (OWASP-AT-004)2007-02-05T17:31:58Z<p>Kcheng: /* Discovery Authentication Methods */</p>
<hr />
<div>{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.<br />
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.<br />
<br />
== Description of the Issue == <br />
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.<br />
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.<br />
<br />
After a successful bruteforce attack, a malicious user could have access to:<br />
<br />
* Confidential information / data;<br />
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..<br />
<br />
* Administration panels;<br />
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..<br />
<br />
* Availability of further attack vectors;<br />
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.<br />
<br />
== Black Box testing and example ==<br />
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.<br />
<br />
=== Discovery Authentication Methods ===<br />
<br />
Unless an entity decides to apply a sophisticated web authentication, the two most commonly seen methods are as follows:<br />
<br />
* HTTP Authentication;<br />
** Basic Access Authentication<br />
** Digest Access Authentication<br />
* HTML Form-based Authentication;<br />
<br />
The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.<br />
<br />
<br />
'''HTTP authentication'''<br />
<br />
There are two native HTTP access authentication schemes available to an organisation – Basic and Digest. <br />
<br />
* Basic Access Authentication<br />
<br />
Basic Access Authentication assumes the client will identify themselves with a login name (e.g., "owasp") and password (e.g., "password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g., Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decoded should an attacker sniff the transmission.<br />
<br />
Request and Response Test:<br />
<br />
1. Client sends standard HTTP request for resource:<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
</pre><br />
<br />
2. The web server states that the requested resource is located in a protected directory.<br />
<br />
3. Server Sends Response with HTTP 401 Authorization Required:<br />
<br />
<pre><br />
HTTP/1.1 401 Authorization Required<br />
Date: Sat, 04 Nov 2006 12:52:40 GMT<br />
WWW-Authenticate: Basic realm="User Realm"<br />
Content-Length: 401<br />
Keep-Alive: timeout=15, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html; charset=iso-8859-1<br />
</pre><br />
<br />
4. Browser displays challenge pop-up for username and password data entry.<br />
<br />
5. Client Resubmits HTTP Request with credentials included:<br />
<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=<br />
</pre><br />
<br />
6. Server compares client information to its credentials list.<br />
<br />
7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.<br />
<br />
<pre><br />
If an attacker is able to intercept the request from step 5, the string<br />
b3dhc3A6cGFzc3dvcmQ= could simply be base64 decoded as follows:<br />
Base64 Decoded : owasp:password<br />
</pre><br />
<br />
If the tester is able to intercept the HTTP request of a basic authentication request, it is not necessary to apply brute-force techniques to uncover the credentials. Simply use a base64 decoder on the sniffed request. However, if the tester is unable to intercept the HTTP request, the tester should use brute force tools.<br />
<br />
* Digest Access Authentication<br />
<br />
Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.<br />
<br />
Request and Response Test:<br />
<br />
1. Here is an example of the initial Response header when handling an HTTP Digest target:<br />
<br />
<pre><br />
HTTP/1.1 401 Unauthorized<br />
WWW-Authenticate: Digest realm="OwaspSample", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
opaque="0000000000000000", \<br />
stale=false, <br />
algorithm=MD5, <br />
qop="auth"<br />
</pre><br />
<br />
2. The Subsequent response headers with valid credentials would look like this:<br />
<br />
<pre><br />
GET /example/owasp/test.asmx HTTP/1.1<br />
Accept: */*<br />
Authorization: Digest username="owasp", <br />
realm="OwaspSample", <br />
qop="auth", <br />
algorithm="MD5", <br />
uri="/example/owasp/test.asmx", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
nc=00000001, <br />
cnonce="c51b5139556f939768f770dab8e5277a", <br />
opaque="0000000000000000", <br />
response="2275a9ca7b2dadf252afc79923cd3823" <br />
</pre><br />
<br />
<br />
'''HTML Form-based Authentication'''<br />
<br />
However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.<br />
<br />
Source code taken from a HTML form:<br />
<br />
<pre><br />
<form method="POST" action="login"><br />
<input type="text" name"username"><br />
<input type="password" name="password"><br />
</form><br />
</pre><br />
<br />
=== Bruteforce Attacks ===<br />
<br />
After having listed the different types of authentication methods for a web application, we will explain several types of bruteforce attacks. <br />
<br />
* Dictionary Attack<br />
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. A dictionary file can be tuned and compiled to cover words probably used by the owner of the account that a malicious user is going to attack. The attacker can gather information (via active/passive reconnaissance, competitive intelligence, dumpster diving, social engineering) to understand the user, or build a list of all unique words available on the website. <br />
<br />
* Search Attacks<br />
Search attacks will try to cover all possible combinations of a given character set and a given password length range. This kind of attack is very slow because the space of possible candidates is quite big. For example, given a known user id, the total number of passwords to try, up to 8 characters in length, is equal to 26^(8!) in a lower alpha charset (more than 200 billion possible passwords!). <br />
<br />
* Rule-based search attacks<br />
To increase combination space coverage without slowing too much of the process it's suggested to create good rules to generate candidates. <br />
For example, "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask, words in the input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").<br />
<br />
'''Bruteforcing HTTP Basic Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-head on port 80<br />
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h<br />
[80][www] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34<br />
<br />
raven@blackbox /hydra $ <br />
</pre><br />
<br />
'''Bruteforcing HTML Form Based Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form<br />
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &<br />
<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-post-form on port 443<br />
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)<br />
[443] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34<br />
<br />
raven@blackbox /hydra $<br />
</pre><br />
<br />
== Gray Box testing and example == <br />
'''Partial knowledge of password and account details'''<br />
<br />
When an tester has some information about length or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. In fact, by limiting the number of characters and defining the password length, the total number of password values significantly decreases.<br />
<br />
[[Image:bf-partialknowledge.jpg]]<br />
<br />
'''Memory Trade Off Attacks'''<br />
<br />
To perform a Memory Trade Off Attack, the tester needs at least a password hash previously obtained by the tester exploiting flaws in the application (e.g. SQL Injection) or sniffing http traffic. Nowadays, the most common attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.<br />
<br />
Rainbowtable is an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.<br />
<br />
<pre>Tables are specific to the hash function they were created for e.g., MD5 tables can only crack MD5 hashes. <br />
The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety <br />
of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.</pre><br />
<br />
[[Image:bf-milworm.jpg]]<br />
<br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf<br />
'''Links'''<br><br />
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/<br />
* Rainbowcrack.com - http://www.rainbowcrack.com/<br />
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/<br />
* milw0rm - http://www.milw0rm.com/cracker/list.php<br />
'''Tools'''<br><br />
* THC Hydra: http://www.thc.org/thc-hydra/<br />
* John the Ripper: http://www.openwall.com/john/<br />
* Brutus http://www.hoobie.net/brutus/<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Brute_Force_(OWASP-AT-004)&diff=16197Testing for Brute Force (OWASP-AT-004)2007-02-05T17:31:02Z<p>Kcheng: /* Discovery Authentication Methods */ Added content on how to test basic authN</p>
<hr />
<div>{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.<br />
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.<br />
<br />
== Description of the Issue == <br />
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.<br />
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.<br />
<br />
After a successful bruteforce attack, a malicious user could have access to:<br />
<br />
* Confidential information / data;<br />
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..<br />
<br />
* Administration panels;<br />
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..<br />
<br />
* Availability of further attack vectors;<br />
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.<br />
<br />
== Black Box testing and example ==<br />
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.<br />
<br />
=== Discovery Authentication Methods ===<br />
<br />
Unless an entity decides to apply a sophisticated web authentication, the two most commonly seen methods are as follows:<br />
<br />
* HTTP Authentication;<br />
** Basic Access Authentication<br />
** Digest Access Authentication<br />
* HTML Form-based Authentication;<br />
<br />
The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.<br />
<br />
<br />
'''HTTP authentication'''<br />
<br />
There are two native HTTP access authentication schemes available to an organisation – Basic and Digest. <br />
<br />
* Basic Access Authentication<br />
<br />
Basic Access Authentication assumes the client will identify themselves with a login name (e.g., "owasp") and password (e.g., "password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g., Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decoded should an attacker sniff the transmission.<br />
<br />
Request and Response Test:<br />
<br />
1. Client sends standard HTTP request for resource:<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
</pre><br />
<br />
2. The web server states that the requested resource is located in a protected directory.<br />
<br />
3. Server Sends Response with HTTP 401 Authorization Required:<br />
<br />
<pre><br />
HTTP/1.1 401 Authorization Required<br />
Date: Sat, 04 Nov 2006 12:52:40 GMT<br />
WWW-Authenticate: Basic realm="User Realm"<br />
Content-Length: 401<br />
Keep-Alive: timeout=15, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html; charset=iso-8859-1<br />
</pre><br />
<br />
4. Browser displays challenge pop-up for username and password data entry.<br />
<br />
5. Client Resubmits HTTP Request with credentials included:<br />
<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=<br />
</pre><br />
<br />
6. Server compares client information to its credentials list.<br />
<br />
7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.<br />
<br />
<pre><br />
If an attacker is able to intercept the request from step 5, the string b3dhc3A6cGFzc3dvcmQ= could simply be base64 decoded as follows:<br />
Base64 Decoded : owasp:password<br />
</pre><br />
<br />
If the tester is able to intercept the HTTP request of a basic authentication request, it is not necessary to apply brute-force techniques to uncover the credentials. Simply use a base64 decoder on the sniffed request. However, if the tester is unable to intercept the HTTP request, the tester should use brute force tools.<br />
<br />
* Digest Access Authentication<br />
<br />
Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.<br />
<br />
Request and Response Test:<br />
<br />
1. Here is an example of the initial Response header when handling an HTTP Digest target:<br />
<br />
<pre><br />
HTTP/1.1 401 Unauthorized<br />
WWW-Authenticate: Digest realm="OwaspSample", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
opaque="0000000000000000", \<br />
stale=false, <br />
algorithm=MD5, <br />
qop="auth"<br />
</pre><br />
<br />
2. The Subsequent response headers with valid credentials would look like this:<br />
<br />
<pre><br />
GET /example/owasp/test.asmx HTTP/1.1<br />
Accept: */*<br />
Authorization: Digest username="owasp", <br />
realm="OwaspSample", <br />
qop="auth", <br />
algorithm="MD5", <br />
uri="/example/owasp/test.asmx", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
nc=00000001, <br />
cnonce="c51b5139556f939768f770dab8e5277a", <br />
opaque="0000000000000000", <br />
response="2275a9ca7b2dadf252afc79923cd3823" <br />
</pre><br />
<br />
<br />
'''HTML Form-based Authentication'''<br />
<br />
However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.<br />
<br />
Source code taken from a HTML form:<br />
<br />
<pre><br />
<form method="POST" action="login"><br />
<input type="text" name"username"><br />
<input type="password" name="password"><br />
</form><br />
</pre><br />
<br />
=== Bruteforce Attacks ===<br />
<br />
After having listed the different types of authentication methods for a web application, we will explain several types of bruteforce attacks. <br />
<br />
* Dictionary Attack<br />
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. A dictionary file can be tuned and compiled to cover words probably used by the owner of the account that a malicious user is going to attack. The attacker can gather information (via active/passive reconnaissance, competitive intelligence, dumpster diving, social engineering) to understand the user, or build a list of all unique words available on the website. <br />
<br />
* Search Attacks<br />
Search attacks will try to cover all possible combinations of a given character set and a given password length range. This kind of attack is very slow because the space of possible candidates is quite big. For example, given a known user id, the total number of passwords to try, up to 8 characters in length, is equal to 26^(8!) in a lower alpha charset (more than 200 billion possible passwords!). <br />
<br />
* Rule-based search attacks<br />
To increase combination space coverage without slowing too much of the process it's suggested to create good rules to generate candidates. <br />
For example, "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask, words in the input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").<br />
<br />
'''Bruteforcing HTTP Basic Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-head on port 80<br />
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h<br />
[80][www] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34<br />
<br />
raven@blackbox /hydra $ <br />
</pre><br />
<br />
'''Bruteforcing HTML Form Based Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form<br />
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &<br />
<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-post-form on port 443<br />
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)<br />
[443] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34<br />
<br />
raven@blackbox /hydra $<br />
</pre><br />
<br />
== Gray Box testing and example == <br />
'''Partial knowledge of password and account details'''<br />
<br />
When an tester has some information about length or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. In fact, by limiting the number of characters and defining the password length, the total number of password values significantly decreases.<br />
<br />
[[Image:bf-partialknowledge.jpg]]<br />
<br />
'''Memory Trade Off Attacks'''<br />
<br />
To perform a Memory Trade Off Attack, the tester needs at least a password hash previously obtained by the tester exploiting flaws in the application (e.g. SQL Injection) or sniffing http traffic. Nowadays, the most common attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.<br />
<br />
Rainbowtable is an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.<br />
<br />
<pre>Tables are specific to the hash function they were created for e.g., MD5 tables can only crack MD5 hashes. <br />
The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety <br />
of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.</pre><br />
<br />
[[Image:bf-milworm.jpg]]<br />
<br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf<br />
'''Links'''<br><br />
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/<br />
* Rainbowcrack.com - http://www.rainbowcrack.com/<br />
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/<br />
* milw0rm - http://www.milw0rm.com/cracker/list.php<br />
'''Tools'''<br><br />
* THC Hydra: http://www.thc.org/thc-hydra/<br />
* John the Ripper: http://www.openwall.com/john/<br />
* Brutus http://www.hoobie.net/brutus/<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Brute_Force_(OWASP-AT-004)&diff=16196Testing for Brute Force (OWASP-AT-004)2007-02-05T17:08:21Z<p>Kcheng: /* Gray Box testing and example */ Spelling, Grammar</p>
<hr />
<div>{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.<br />
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.<br />
<br />
== Description of the Issue == <br />
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.<br />
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.<br />
<br />
After a successful bruteforce attack, a malicious user could have access to:<br />
<br />
* Confidential information / data;<br />
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..<br />
<br />
* Administration panels;<br />
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..<br />
<br />
* Availability of further attack vectors;<br />
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.<br />
<br />
== Black Box testing and example ==<br />
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.<br />
<br />
=== Discovery Authentication Methods ===<br />
<br />
Unless an entity decides to apply a sophisticated web authentication, the two most commonly seen methods are as follows:<br />
<br />
* HTTP Authentication;<br />
** Basic Access Authentication<br />
** Digest Access Authentication<br />
* HTML Form-based Authentication;<br />
<br />
The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.<br />
<br />
<br />
'''HTTP authentication'''<br />
<br />
There are two native HTTP access authentication schemes available to an organisation – Basic and Digest. <br />
<br />
* Basic Access Authentication<br />
<br />
Basic Access Authentication assumes the client will identify themselves with a login name (e.g., "owasp") and password (e.g., "password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g., Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.<br />
<br />
Request and Response Test:<br />
<br />
1. Client sends standard HTTP request for resource:<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
</pre><br />
<br />
2. The web server states that the requested resource is located in a protected directory.<br />
<br />
3. Server Sends Response with HTTP 401 Authorization Required:<br />
<br />
<pre><br />
HTTP/1.1 401 Authorization Required<br />
Date: Sat, 04 Nov 2006 12:52:40 GMT<br />
WWW-Authenticate: Basic realm="User Realm"<br />
Content-Length: 401<br />
Keep-Alive: timeout=15, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html; charset=iso-8859-1<br />
</pre><br />
<br />
4. Browser displays challenge pop-up for username and password data entry.<br />
<br />
5. Client Resubmits HTTP Request with credentials included:<br />
<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=<br />
</pre><br />
<br />
6. Server compares client information to its credentials list.<br />
<br />
7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.<br />
<br />
<pre><br />
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:<br />
Base64 Decoded : owasp:password<br />
</pre><br />
<br />
* Digest Access Authentication<br />
<br />
Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.<br />
<br />
Request and Response Test:<br />
<br />
1. Here is an example of the initial Response header when handling an HTTP Digest target:<br />
<br />
<pre><br />
HTTP/1.1 401 Unauthorized<br />
WWW-Authenticate: Digest realm="OwaspSample", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
opaque="0000000000000000", \<br />
stale=false, <br />
algorithm=MD5, <br />
qop="auth"<br />
</pre><br />
<br />
2. The Subsequent response headers with valid credentials would look like this:<br />
<br />
<pre><br />
GET /example/owasp/test.asmx HTTP/1.1<br />
Accept: */*<br />
Authorization: Digest username="owasp", <br />
realm="OwaspSample", <br />
qop="auth", <br />
algorithm="MD5", <br />
uri="/example/owasp/test.asmx", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
nc=00000001, <br />
cnonce="c51b5139556f939768f770dab8e5277a", <br />
opaque="0000000000000000", <br />
response="2275a9ca7b2dadf252afc79923cd3823" <br />
</pre><br />
<br />
<br />
'''HTML Form-based Authentication'''<br />
<br />
However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.<br />
<br />
Source code taken from a HTML form:<br />
<br />
<pre><br />
<form method="POST" action="login"><br />
<input type="text" name"username"><br />
<input type="password" name="password"><br />
</form><br />
</pre><br />
<br />
=== Bruteforce Attacks ===<br />
<br />
After having listed the different types of authentication methods for a web application, we will explain several types of bruteforce attacks. <br />
<br />
* Dictionary Attack<br />
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. A dictionary file can be tuned and compiled to cover words probably used by the owner of the account that a malicious user is going to attack. The attacker can gather information (via active/passive reconnaissance, competitive intelligence, dumpster diving, social engineering) to understand the user, or build a list of all unique words available on the website. <br />
<br />
* Search Attacks<br />
Search attacks will try to cover all possible combinations of a given character set and a given password length range. This kind of attack is very slow because the space of possible candidates is quite big. For example, given a known user id, the total number of passwords to try, up to 8 characters in length, is equal to 26^(8!) in a lower alpha charset (more than 200 billion possible passwords!). <br />
<br />
* Rule-based search attacks<br />
To increase combination space coverage without slowing too much of the process it's suggested to create good rules to generate candidates. <br />
For example, "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask, words in the input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").<br />
<br />
'''Bruteforcing HTTP Basic Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-head on port 80<br />
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h<br />
[80][www] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34<br />
<br />
raven@blackbox /hydra $ <br />
</pre><br />
<br />
'''Bruteforcing HTML Form Based Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form<br />
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &<br />
<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-post-form on port 443<br />
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)<br />
[443] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34<br />
<br />
raven@blackbox /hydra $<br />
</pre><br />
<br />
== Gray Box testing and example == <br />
'''Partial knowledge of password and account details'''<br />
<br />
When an tester has some information about length or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. In fact, by limiting the number of characters and defining the password length, the total number of password values significantly decreases.<br />
<br />
[[Image:bf-partialknowledge.jpg]]<br />
<br />
'''Memory Trade Off Attacks'''<br />
<br />
To perform a Memory Trade Off Attack, the tester needs at least a password hash previously obtained by the tester exploiting flaws in the application (e.g. SQL Injection) or sniffing http traffic. Nowadays, the most common attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.<br />
<br />
Rainbowtable is an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.<br />
<br />
<pre>Tables are specific to the hash function they were created for e.g., MD5 tables can only crack MD5 hashes. <br />
The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety <br />
of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.</pre><br />
<br />
[[Image:bf-milworm.jpg]]<br />
<br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf<br />
'''Links'''<br><br />
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/<br />
* Rainbowcrack.com - http://www.rainbowcrack.com/<br />
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/<br />
* milw0rm - http://www.milw0rm.com/cracker/list.php<br />
'''Tools'''<br><br />
* THC Hydra: http://www.thc.org/thc-hydra/<br />
* John the Ripper: http://www.openwall.com/john/<br />
* Brutus http://www.hoobie.net/brutus/<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Brute_Force_(OWASP-AT-004)&diff=16195Testing for Brute Force (OWASP-AT-004)2007-02-05T17:03:54Z<p>Kcheng: /* Bruteforce Attacks */ Grammar</p>
<hr />
<div>{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.<br />
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.<br />
<br />
== Description of the Issue == <br />
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.<br />
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.<br />
<br />
After a successful bruteforce attack, a malicious user could have access to:<br />
<br />
* Confidential information / data;<br />
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..<br />
<br />
* Administration panels;<br />
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..<br />
<br />
* Availability of further attack vectors;<br />
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.<br />
<br />
== Black Box testing and example ==<br />
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.<br />
<br />
=== Discovery Authentication Methods ===<br />
<br />
Unless an entity decides to apply a sophisticated web authentication, the two most commonly seen methods are as follows:<br />
<br />
* HTTP Authentication;<br />
** Basic Access Authentication<br />
** Digest Access Authentication<br />
* HTML Form-based Authentication;<br />
<br />
The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.<br />
<br />
<br />
'''HTTP authentication'''<br />
<br />
There are two native HTTP access authentication schemes available to an organisation – Basic and Digest. <br />
<br />
* Basic Access Authentication<br />
<br />
Basic Access Authentication assumes the client will identify themselves with a login name (e.g., "owasp") and password (e.g., "password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g., Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.<br />
<br />
Request and Response Test:<br />
<br />
1. Client sends standard HTTP request for resource:<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
</pre><br />
<br />
2. The web server states that the requested resource is located in a protected directory.<br />
<br />
3. Server Sends Response with HTTP 401 Authorization Required:<br />
<br />
<pre><br />
HTTP/1.1 401 Authorization Required<br />
Date: Sat, 04 Nov 2006 12:52:40 GMT<br />
WWW-Authenticate: Basic realm="User Realm"<br />
Content-Length: 401<br />
Keep-Alive: timeout=15, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html; charset=iso-8859-1<br />
</pre><br />
<br />
4. Browser displays challenge pop-up for username and password data entry.<br />
<br />
5. Client Resubmits HTTP Request with credentials included:<br />
<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=<br />
</pre><br />
<br />
6. Server compares client information to its credentials list.<br />
<br />
7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.<br />
<br />
<pre><br />
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:<br />
Base64 Decoded : owasp:password<br />
</pre><br />
<br />
* Digest Access Authentication<br />
<br />
Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.<br />
<br />
Request and Response Test:<br />
<br />
1. Here is an example of the initial Response header when handling an HTTP Digest target:<br />
<br />
<pre><br />
HTTP/1.1 401 Unauthorized<br />
WWW-Authenticate: Digest realm="OwaspSample", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
opaque="0000000000000000", \<br />
stale=false, <br />
algorithm=MD5, <br />
qop="auth"<br />
</pre><br />
<br />
2. The Subsequent response headers with valid credentials would look like this:<br />
<br />
<pre><br />
GET /example/owasp/test.asmx HTTP/1.1<br />
Accept: */*<br />
Authorization: Digest username="owasp", <br />
realm="OwaspSample", <br />
qop="auth", <br />
algorithm="MD5", <br />
uri="/example/owasp/test.asmx", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
nc=00000001, <br />
cnonce="c51b5139556f939768f770dab8e5277a", <br />
opaque="0000000000000000", <br />
response="2275a9ca7b2dadf252afc79923cd3823" <br />
</pre><br />
<br />
<br />
'''HTML Form-based Authentication'''<br />
<br />
However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.<br />
<br />
Source code taken from a HTML form:<br />
<br />
<pre><br />
<form method="POST" action="login"><br />
<input type="text" name"username"><br />
<input type="password" name="password"><br />
</form><br />
</pre><br />
<br />
=== Bruteforce Attacks ===<br />
<br />
After having listed the different types of authentication methods for a web application, we will explain several types of bruteforce attacks. <br />
<br />
* Dictionary Attack<br />
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. A dictionary file can be tuned and compiled to cover words probably used by the owner of the account that a malicious user is going to attack. The attacker can gather information (via active/passive reconnaissance, competitive intelligence, dumpster diving, social engineering) to understand the user, or build a list of all unique words available on the website. <br />
<br />
* Search Attacks<br />
Search attacks will try to cover all possible combinations of a given character set and a given password length range. This kind of attack is very slow because the space of possible candidates is quite big. For example, given a known user id, the total number of passwords to try, up to 8 characters in length, is equal to 26^(8!) in a lower alpha charset (more than 200 billion possible passwords!). <br />
<br />
* Rule-based search attacks<br />
To increase combination space coverage without slowing too much of the process it's suggested to create good rules to generate candidates. <br />
For example, "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask, words in the input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").<br />
<br />
'''Bruteforcing HTTP Basic Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-head on port 80<br />
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h<br />
[80][www] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34<br />
<br />
raven@blackbox /hydra $ <br />
</pre><br />
<br />
'''Bruteforcing HTML Form Based Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form<br />
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &<br />
<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-post-form on port 443<br />
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)<br />
[443] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34<br />
<br />
raven@blackbox /hydra $<br />
</pre><br />
<br />
== Gray Box testing and example == <br />
'''Partial knowledge of password and account details'''<br />
<br />
When an tester has some information about lenght or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. Infact, limiting the number of characters and defining the password lenght, the total number of password values significantly decreases.<br />
<br />
[[Image:bf-partialknowledge.jpg]]<br />
<br />
'''Memory Trade Off Attacks'''<br />
<br />
To perform a Memory Trade Off Attack is needed at least a password hash previously obtained by the attacker exploiting flaws in the application (e.g. SQL Injection) or sniffing http traffic. Nowadays the most commond attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.<br />
<br />
Rainbowtable is an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.<br />
<br />
<pre>Tables are specific to the hash function they were created for e.g., MD5 tables can only crack MD5 hashes. <br />
The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety <br />
of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.</pre><br />
<br />
[[Image:bf-milworm.jpg]]<br />
<br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf<br />
'''Links'''<br><br />
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/<br />
* Rainbowcrack.com - http://www.rainbowcrack.com/<br />
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/<br />
* milw0rm - http://www.milw0rm.com/cracker/list.php<br />
'''Tools'''<br><br />
* THC Hydra: http://www.thc.org/thc-hydra/<br />
* John the Ripper: http://www.openwall.com/john/<br />
* Brutus http://www.hoobie.net/brutus/<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Brute_Force_(OWASP-AT-004)&diff=16194Testing for Brute Force (OWASP-AT-004)2007-02-05T16:55:24Z<p>Kcheng: /* Discovery Authentication Methods */ Spelling & Grammar</p>
<hr />
<div>{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.<br />
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.<br />
<br />
== Description of the Issue == <br />
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.<br />
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.<br />
<br />
After a successful bruteforce attack, a malicious user could have access to:<br />
<br />
* Confidential information / data;<br />
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..<br />
<br />
* Administration panels;<br />
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..<br />
<br />
* Availability of further attack vectors;<br />
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.<br />
<br />
== Black Box testing and example ==<br />
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.<br />
<br />
=== Discovery Authentication Methods ===<br />
<br />
Unless an entity decides to apply a sophisticated web authentication, the two most commonly seen methods are as follows:<br />
<br />
* HTTP Authentication;<br />
** Basic Access Authentication<br />
** Digest Access Authentication<br />
* HTML Form-based Authentication;<br />
<br />
The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.<br />
<br />
<br />
'''HTTP authentication'''<br />
<br />
There are two native HTTP access authentication schemes available to an organisation – Basic and Digest. <br />
<br />
* Basic Access Authentication<br />
<br />
Basic Access Authentication assumes the client will identify themselves with a login name (e.g., "owasp") and password (e.g., "password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g., Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.<br />
<br />
Request and Response Test:<br />
<br />
1. Client sends standard HTTP request for resource:<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
</pre><br />
<br />
2. The web server states that the requested resource is located in a protected directory.<br />
<br />
3. Server Sends Response with HTTP 401 Authorization Required:<br />
<br />
<pre><br />
HTTP/1.1 401 Authorization Required<br />
Date: Sat, 04 Nov 2006 12:52:40 GMT<br />
WWW-Authenticate: Basic realm="User Realm"<br />
Content-Length: 401<br />
Keep-Alive: timeout=15, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html; charset=iso-8859-1<br />
</pre><br />
<br />
4. Browser displays challenge pop-up for username and password data entry.<br />
<br />
5. Client Resubmits HTTP Request with credentials included:<br />
<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=<br />
</pre><br />
<br />
6. Server compares client information to its credentials list.<br />
<br />
7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.<br />
<br />
<pre><br />
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:<br />
Base64 Decoded : owasp:password<br />
</pre><br />
<br />
* Digest Access Authentication<br />
<br />
Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.<br />
<br />
Request and Response Test:<br />
<br />
1. Here is an example of the initial Response header when handling an HTTP Digest target:<br />
<br />
<pre><br />
HTTP/1.1 401 Unauthorized<br />
WWW-Authenticate: Digest realm="OwaspSample", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
opaque="0000000000000000", \<br />
stale=false, <br />
algorithm=MD5, <br />
qop="auth"<br />
</pre><br />
<br />
2. The Subsequent response headers with valid credentials would look like this:<br />
<br />
<pre><br />
GET /example/owasp/test.asmx HTTP/1.1<br />
Accept: */*<br />
Authorization: Digest username="owasp", <br />
realm="OwaspSample", <br />
qop="auth", <br />
algorithm="MD5", <br />
uri="/example/owasp/test.asmx", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
nc=00000001, <br />
cnonce="c51b5139556f939768f770dab8e5277a", <br />
opaque="0000000000000000", <br />
response="2275a9ca7b2dadf252afc79923cd3823" <br />
</pre><br />
<br />
<br />
'''HTML Form-based Authentication'''<br />
<br />
However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.<br />
<br />
Source code taken from a HTML form:<br />
<br />
<pre><br />
<form method="POST" action="login"><br />
<input type="text" name"username"><br />
<input type="password" name="password"><br />
</form><br />
</pre><br />
<br />
=== Bruteforce Attacks ===<br />
<br />
After having listed the different types of authentication methods for a web application, we will explain several types of bruteforce attacks. <br />
<br />
* Dictionary Attack<br />
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. A dictionary file can be tuned and compiled to cover words probably used by the owner of the account that a malicious user is going to attack. The attacker can gather information (via active/passive reconnaissance, competitive intelligence, dumpster diving, social engineering) to understand the user, or build a list of all unique words available on the website. <br />
<br />
* Search Attacks<br />
Search attacks will try to cover all possible combination of a given character set and a given password lenght range. This kind of attack is very slow because the space of possible candidates is quite big. For example given a known user id, the total number of passwords to try up to 8 characters in lenght is equal to 26^(8!) in a lower alpha charset (more than 200 billions of different passwords!). <br />
<br />
* Rule-based search attacks<br />
To increase combination space coverage without slowing too much the process it's suggested to create good rules to generate candidates. <br />
For example "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask words in input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").<br />
<br />
'''Bruteforcing HTTP Basic Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-head on port 80<br />
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h<br />
[80][www] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34<br />
<br />
raven@blackbox /hydra $ <br />
</pre><br />
<br />
'''Bruteforcing HTML Form Based Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form<br />
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &<br />
<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-post-form on port 443<br />
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)<br />
[443] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34<br />
<br />
raven@blackbox /hydra $<br />
</pre><br />
<br />
== Gray Box testing and example == <br />
'''Partial knowledge of password and account details'''<br />
<br />
When an tester has some information about lenght or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. Infact, limiting the number of characters and defining the password lenght, the total number of password values significantly decreases.<br />
<br />
[[Image:bf-partialknowledge.jpg]]<br />
<br />
'''Memory Trade Off Attacks'''<br />
<br />
To perform a Memory Trade Off Attack is needed at least a password hash previously obtained by the attacker exploiting flaws in the application (e.g. SQL Injection) or sniffing http traffic. Nowadays the most commond attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.<br />
<br />
Rainbowtable is an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.<br />
<br />
<pre>Tables are specific to the hash function they were created for e.g., MD5 tables can only crack MD5 hashes. <br />
The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety <br />
of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.</pre><br />
<br />
[[Image:bf-milworm.jpg]]<br />
<br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf<br />
'''Links'''<br><br />
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/<br />
* Rainbowcrack.com - http://www.rainbowcrack.com/<br />
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/<br />
* milw0rm - http://www.milw0rm.com/cracker/list.php<br />
'''Tools'''<br><br />
* THC Hydra: http://www.thc.org/thc-hydra/<br />
* John the Ripper: http://www.openwall.com/john/<br />
* Brutus http://www.hoobie.net/brutus/<br />
<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_Default_or_Guessable_User_Account_(OWASP-AT-003)&diff=16111Testing for Default or Guessable User Account (OWASP-AT-003)2007-02-02T19:56:31Z<p>Kcheng: /* Black Box testing and example */</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and require configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces.<br><br><br />
Often, these applications are not properly configured and the default credentials provided for authentication are never updated.<br><br />
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to the internal network infrastructure and/or to gain privileges and steal data.<br><br />
This problem applies to software and/or appliances that provide built-in non-removable accounts and, in fewer cases, uses blank passwords as default credentials.<br />
<br><br />
<br />
== Description of the Issue == <br />
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.<br />
<br />
== Black Box testing and example ==<br />
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username and/or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.<br />
<br />
When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.<br />
<br />
When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:<br />
* Try the following usernames - "admin", "administrator", "root", "system", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner.<br />
* Application administrative users are often named after the application. This means if you are testing an application named "Obscurity", try using obscurity/obscurity as the username and password.<br />
* When performing a test for a customer, attempt using names of contacts you have received as usernames.<br />
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names. <br />
* Attempt using all the above usernames with blank passwords.<br />
<br />
'''Result Expected:'''<br><br />
Authorized access to system being tested.<br><br><br />
<br />
== Gray Box testing and example == <br />
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.<br />
<br />
Talk to the IT personnel to determine which passwords they use for administrative access. <br />
<br />
Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system"). <br />
Note blank passwords.<br />
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.<br />
<br />
Examine the code for hard coded usernames and passwords.<br />
<br />
Check for configuration files that contain usernames and passwords.<br><br />
'''Result Expected:'''<br><br />
Authorized access to system being tested<br><br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* CIRT http://www.cirt.net/cgi-bin/passwd.pl<br />
* DarkLab http://phenoelit.darklab.org/cgi-bin/display.pl?SUBF=list&SORT=1<br />
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php<br />
* Virus.org http://www.virus.org/default-password/<br><br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Testing_for_business_logic&diff=16109Testing for business logic2007-02-02T19:27:16Z<p>Kcheng: /* Understanding the application */</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Brief Summary ==<br />
<br />
Business logic comprises: <br />
* Business rules that express business policy (such as channels, location, logistics, prices, and products); and<br />
* Workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.<br />
<br />
The attacks on the business logic of an application are dangerous, difficult to detect and specific to that application.<br />
<br />
==Description of the Issue==<br />
<br />
Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than is allowed? Or perhaps you are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently these business logic security checks simply are not present in the application.<br />
<br />
Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests.<br />
<br />
'''Business Limits and Restrictions'''<br><br />
<br />
Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.<br />
<br />
'''Example''': Setting the quantity of a product on an e-commerce site as a negative number may result in funds being credited to the attacker. The countermeasure to this problem is to implement stronger data validation, as the application permits negative numbers to be entered in the quantity field of the shopping cart.<br />
<br />
==Black Box Testing and Examples==<br />
<br />
Although uncovering logical vulnerabilities will probably always remain an art, one can attempt to go about it systematically to a great extent. Here is a suggested approach that consists of: <br />
* Understanding the application<br />
* Creating raw data for designing logical tests<br />
* Designing the logical tests<br />
* Standard prerequisites<br />
* Execution of logical tests<br />
<br />
===Understanding the application===<br />
<br />
Understanding the application thoroughly is a prerequisite for designing logical tests. To start with: <br />
* Get any documentation describing the application's functionality. Examples of this include:<br />
** Application manuals<br />
** Requirements documents<br />
** Functional specifications<br />
** Use or Abuse Cases<br />
* Explore the application manually and try to understand all the different ways in which the application can be used, the acceptable usage scenarios and the authorization limits imposed on various users<br />
<br />
===Creating raw data for designing logical tests===<br />
<br />
In this phase, one should ideally come up with the following data: <br />
* All application '''business scenarios'''. For example, for an e-commerce application this might look like,<br />
** Product ordering<br />
** Checkout<br />
** Browse<br />
** Search for a product<br />
* '''Workflows'''. This is different from business scenarios since it involves a number of different users. Examples include:<br />
** Order creation and approval<br />
** Bulletin board (one user posts an article that is reviewed by a moderator and ultimately seen by all users)<br />
* Different '''user roles'''<br />
** Administrator<br />
** Manager<br />
** Staff<br />
** CEO<br />
* Different '''groups or departments''' (note that there could be a tree (e.g. the Sales group of the heavy engineering division) or tagged view (e.g. someone could be a member of Sales as well as marketing) associated with this. <br />
** Purchasing<br />
** Marketing<br />
** Engineering<br />
* '''Access rights of various user roles and groups''' - The application allows various users privileges on some resource (or asset) and we need to specify the constraints of these privileges. One simple way to know these business rules/constraints is to make use of the application documentation effectively. For example, look for clauses like "If the administrator allows individual user access..", "If configured by the administrator.." and you know the restriction imposed by the application. <br />
* '''Privilege Table''' – After learning about the various privileges on the resources along with the constraints, you are all set to create a Privilege Table. Get answers to: <br />
** What can each user role do on which resource with what constraint? This will help you in deducing who cannot do what on which resource. <br />
** What are the policies across groups? <br />
<br />
<span style="display: block; margin-left: 16px;">Consider the following privileges: "Approve expense report", "Book a conference room", "Transfer money from own account to another user's account". A privilege could be thought of as a combination of a verb (e.g. Approve, Book, Withdraw) and one or more nouns (Expense report, conference room, account). The output of this activity is a grid with the various privileges forming the leftmost column while all user roles and groups would form the column headings of other columns. There would also be a “Comments” column that qualifies data in this grid.</span><br />
<br />
<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;"><br />
{| class="wikitable" style="margin: 1em auto 1em auto"<br />
| '''Privilege''' || '''Who can do this''' || '''Comment'''<br />
|-<br />
| Approve expense report || Any supervisor may approve report submitted by his subordinate || <br />
|-<br />
| Submit expense report || Any employee may do this for himself || <br />
|-<br />
| Transfer funds from one account to another || An account holder may transfer funds from own account to another account || <br />
|-<br />
| View payslip || Any employee may see his own || <br />
|-<br />
|}<br />
</blockquote><br />
<br />
This data is a key input for designing logical tests. <br />
<br />
===Developing logical tests===<br />
<br />
Here are several guidelines to designing logical tests from the raw data gathered. <br />
<br />
* '''Privilege Table''' - Make use of the privilege table as a reference while creating application specific logical threats. In general, develop a test for each admin privilege to check if it could be executed illegally by a user role with minimum privileges or no privilege. For example:<br />
** Privilege: Operations Manager cannot approve a customer order<br />
** Logical Test: Operations Manager approves a customer order<br />
<br />
* '''Improper handling of special user action sequences''' - Navigating through an application in a certain way or revisiting pages out of synch can cause logical errors which may cause the application to do something it's not meant to. For example:<br />
** A wizard application where one fills in forms and proceeds to the next step. One cannot in any normal way (according to the developers) enter the wizard in the middle of the process. Bookmarking a middle step (say step 4 of 7), then continuing with the other steps until completion or form submission, then revisiting the middle step that was bookmarked may "upset" the backend logic due to a weak ''state model''.<br />
<br />
* '''Cover all business transaction paths''' - While designing tests, check for all alternative ways to perform the same business transaction. For example, create tests for both cash and credit payment modes.<br />
<br />
* '''Client-side validation''' - Look at all client side validations and see how they could be the basis for designing logical tests. For example, a funds transfer transaction has a validation for negative values in the amount field. This information can be used to design a logical test such as "A user transfers negative amount of money".<br />
<br />
===Standard prerequisites===<br />
<br />
Typically, some initial activities useful as setup are: <br />
* Create test users with different permissions<br />
* Browse all the important business scenarios/workflows in the application<br />
<br />
===Execution of logical tests=== <br />
<br />
Pick up each logical test and do the following:<br />
* Analyze the HTTP/S requests underlying the acceptable usage scenario corresponding to the logical test<br />
** Check the order of HTTP/S requests<br />
** Understand the purpose of hidden fields, form fields, query string parameters being passed<br />
* Try and subvert it by exploiting the known vulnerabilities<br />
* Verify that the application fails for the test <br />
<br />
<br />
<br />
==References==<br />
'''Whitepapers'''<br><br />
* Business logic - http://en.wikipedia.org/wiki/Business_logic<br />
* Prevent application logic attacks with sound app security practices - http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1213424,00.html?bucket=NEWS&topic=302570<br><br />
<br />
'''Tools'''<br><br />
<br />
Automated tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a bank’s "fund transfer" page allows a user to transfer a negative amount to another user (in other words, it allows a user to transfer a positive amount into his own account) nor do they have any mechanism to help the human testers to suspect this state of affairs.<br />
<br />
'''Preventing transfer of a negative amount''': Tools could be enhanced so that they can report client side validations to the tester. For example, the tool may have a feature whereby it fills a form with strange values and attempts to submit it using a full-fledged browser implementation. It should check to see whether the browser actually submitted the request. Detecting that the browser has not submitted the request would signal to the tool that submitted values are not being accepted due to client-side validation. This would be reported to the tester, who would then understand the need for designing appropriate logical tests that bypass client-side validation. In our "negative amount transfer" example, the tester would learn that the transfer of negative amounts may be an interesting test. He could then design a test wherein the tool bypasses the client-side validation code and checks to see if the resulting response contains the string "funds transfer successful". The point is not that the tool will be able to detect this or other vulnerabilities of this nature, rather that, with some thought, it would be possible to add many such features to enlist the tools in aiding human testers to find such logical vulnerabilities.<br />
<br />
<br />
<br><br />
{{Category:OWASP Testing Project AoC}}</div>Kchenghttps://wiki.owasp.org/index.php?title=Talk:Testing:_Information_Gathering&diff=16105Talk:Testing: Information Gathering2007-02-02T18:54:25Z<p>Kcheng: </p>
<hr />
<div>4.2.1 points to Application Discovery when the title is Application Fingerprint. Was this intentional?</div>Kcheng