OWASP - User contributions [en]

Testing for logout functionality (OTG-SESS-006)

2013-12-04T00:13:03Z

Thomas Skora: First version

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Session termination is an important part of the session lifecycle. Minimizing the life time of a sessions reduces the probability of the success of session hijacking and other attacks like Cross Site Scripting and Cross Site Request Forgery, which are often targeted against users to access sensible data or functionality which is available in the vulnerable application in authenticated sessions. A secure session termination requires at least the following components:

* Availability of user interface controls for manual logouts performed by the user.
* Session termination after a given amount of time without activity (session timeout).
* Proper invalidation of server-side session state.

== Description of the Issue ==
There are multiple issues which can prevent the effective termination of a session. At the first place the user should be able to terminate the session at every time while usage of the web application. Every page should contain a logout button on a place where it is directly visible. Unclear or ambiguous logout functions could cause that the user don't use it.

Another common mistake in session termination is, that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action.

Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.

The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to relogin back to the application where the logout was performed just before. On the other side a logout function in a SSO system does not necessarily causes session termination in connected applications.

== Black Box testing and example ==
'''Testing for logout user interface:''' 
Verify the appearance and visibility of the logout functionality in the user interface. For this purpose, view each page from the perspective of an user who has the intention to logout from the web application.

'''Result Expected:''' 
There are some properties which indicate a good logout user interface:
* A logout button is present on all pages of the web application.
* The logout button should be identified quickly by an user which wants to logout from the web application.
* After loading of a page the logout button should be visible without scrolling.
* Ideally the logout button is placed in an area of the page, which is fixed in the view port of the browser and not affected by scrolling of the content. 

'''Testing for server-side session termination:''' 
First, store the values of cookies which are used to identify a session. Invoke the logout function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page which is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the logout function causes that session cookies are set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application which are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.

'''Result Expected:''' 
No data which should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a login form while accessing authenticated areas after termination of the session.

It should be not necessary for the security of the application, but setting session cookies to new values after logout is generally considered as good practice. 

'''Testing for session timeout:''' 
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the logout behavior appears, the used delay matches approximately the session timeout value.

'''Result Expected:''' 
The same results as for server-side session termination testing described before are excepted by a logout caused by an inactivity timeout.

The proper value for the session timeout highly depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes normally no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary login requests. There timeouts of an hour and more can be acceptable. 

'''Testing for session termination in single sign-on environments (single sign-off):''' 
Perform a logout in the tested application. Verify if there is a central portal or application directory which allows the user to relogin to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested.

While logged in in the tested application, perform a logout in the SSO system. Then try to access an authenticated area of the tested application.

'''Result Expected:''' 
It is expected that the invocation of a logout function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after logout in the SSO system and connected application. 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T19:45:53Z

Thomas Skora: Incorporated suggestions from first reviews, thanks to Juliano Rizzo (@julianor), Ryan Dewhurst (@ethicalhack3r) and Marcin (@marcinw)

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext ''<tt>p</tt>'' and a cipher with a block size ''<tt>n</tt>'', the number of blocks will be ''<tt>b = ceil( length(b) / n)</tt>''. The length of the encrypted string will be ''<tt>y=(b+1)*n</tt>'' due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the second-to-last block ''<tt>b-1</tt>'' (the least significant bit of the byte at ''<tt>y-n-1</tt>''), re-encode and send. Next, decode the original string, flip the last bit of the block ''<tt>b-2</tt>'' (the least significant bit of the byte at ''<tt>y-2*n-1</tt>''), re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism, like HMAC or authenticated cipher operation modes like GCM or CCM.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster https://github.com/GDSSecurity/PadBuster]
* python-paddingoracle - [https://github.com/mwielgoszewski/python-paddingoracle https://github.com/mwielgoszewski/python-paddingoracle]
* Poracle - [https://github.com/iagox86/Poracle https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/ http://netifera.com/research/]
 
'''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/ http://erlend.oftedal.no/blog/poet/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-11T22:57:21Z

Thomas Skora:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. For this purpose, multiple requests should be issued, where one bit of the base value is flipped. At least the last two blocks should be tampered. The bit flipping must be performed on the decoded cipher text, while the tampered cipher text must be encoded as expected by the application. This tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 
== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-11T22:49:01Z

Thomas Skora: First (incomplete, inaccurate) description of testing for padding oracles

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. For this purpose, multiple requests should be issued, where one bit of the base value is flipped. At least the last two blocks should be tampered. The bit flipping must be performed on the decoded cipher text, while the tampered cipher text must be encoded as expected by the application. This tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

Examples:
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 
== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]