OWASP - User contributions [en]

Bhopal

2019-10-20T06:58:33Z

Anant Shrivastava: added reference to the new website

= New Website =

'''We Are moving our webpage to new Website : https://www2.owasp.org/www-chapter-bhopal/'''

{{Chapter Template|chaptername=Bhopal|extra=The chapter leaders are [mailto:anant.shrivastava@owasp.org Anant Shrivastava] and [mailto:saurabh.chaudhary@owasap.org Saurabh Chaudhary].
|meetupurl=https://www.meetup.com/OWASP-Bhopal-Chapter/|region=Asia/Pacific/Middle East}}

Everyone is welcome to join us at our chapter meetings.

[[Category:OWASP Chapter]]

Anant Shrivastava

2019-08-30T13:31:22Z

Anant Shrivastava: Created page with "Test Page to claim User page"

Test Page to claim User page

User:Anant Shrivastava

2019-04-17T07:54:00Z

Anant Shrivastava: Revamping of my user page to clearly outline my current posture.

Anant Shrivastava is an information security professional with 10+ yrs of corporate experience with expertise in Network, Mobile, Application and Linux Security. He is Regional Director Asia Pacific for NotSoSecure Global Services, he has trained ~600 delegates at various conferences (Blackhat all 3 editions, Nullcon, g0s, c0c0n). Anant also leads Open Source project Android Tamer ([https://www.androidtamer.com www.androidtamer.com]) and CodeVigilant ([https://www.codevigilant.com www.codevigilant.com]). His work can be found at [https://anantshri.info anantshri.info]

As part of OWASP, Anant has worked at following:
# Currently Chapter leader OWASP Bhopal
# GSoC Mentor for OWASP OWTF Project
# Contributor OWASP Web Application Testing Guide
# Reviewer Mobile Security Testing Guide (MSTG)
# Reviewer Mobile Application Security Verification Standards (MASVS)

Besides OWASP Anant is also active in multiple other open communities such as [https://null.co.in Null], [https://garage4hackers.com Garage4Hackers], [https://reconvillage.org/ Recon village] to name a few.

Android Testing Cheat Sheet

2017-02-25T07:08:20Z

Anant Shrivastava: couple of tweaks

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =

This cheat sheet provides a checklist of tasks to be performed to do a penetration test of an Android application. It follows the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project OWASP Mobile Top 10 Risks] list.

== Testing Methodology ==
[[File:Andpen2.png]]

A complete android pen testing involves different areas such as the ones described in the above picture

===Application Mapping===
In this first phase, the focus relies on understanding the application logic and what exactly the application does.
This involves some manual test where we do some basic operations such as install the APK on the phone, login and comprehend the functionality of the app.

Map the application for possible security vectors such as:
# What is the application genre ? (Game, business, productivity etc)
# Does the application connect to backend web services?
# Is the application purely native or incorporates readymade frameworks?
# Does the application store data on the device?
# What all features of the device are used by the application? (camera, gyroscope, contacts etc)

===Client Attacks===
This is one of the most challenging and exciting parts of the pentest assessment. Android apps are packed as an APK, also known as Android Package Kit or Android Application Package. Our mission as Pen testers is to verify how well protected the application has been created and designed against known threat actors.Android Mobile applications are distributed through platforms like Google Play. Since the application is fully installed on the client, it becomes vulnerable to any attacks coming from the client.

===Network Attacks===
As we need to identify vulnerabilities in the Client, is also essential to verify how secure is the communication between the Client and the Server by evaluating the traffic. For this purpose, using tools like Attack proxies, evaluating potential SSL issues, and executing Wireshark Data package inspection is an essential part of the assessment.

===Server Attacks===
Last but not least, issues at the Server level will impact the security of the application. Insecure implementation such as misconfigurations , vulnerabilities and issues at API or Database level, affect also the security of an application

At the device level, there are 2 ways in which the application shall be tested. Reverse Engineering is an essential part of pen testing mobile applications. It also requires the use of rooted devices. If you have been wondering why do we need to Reverse Engineer an installed APK, the major reason relies on the client.

==Devices==

There are also different ways to pentest the application , and we should consider in which case we need to use one or the other

# With Android device running in a factory default or normal mode
# With Android device running in a rooted mode

At the application level, there are 2 ways in which it shall be tested
# Application running on the device (to take benefits of touch related features)
# Application running on the emulator (to ease the task of testing using wider screen of desktop or laptop)

= OWASP Step-by-step Approach =
(For each of the standards below, there shall be multiple steps for the tester to follow])
== M1 - Improper Platform Usage [Client Attacks]==
* Check AndroidManifest.xml permissions [https://developer.android.com/reference/android/Manifest.permission.html configurations] certain permissions can be [https://developer.android.com/guide/topics/permissions/requesting.html#normal-dangerous dangerous]
*If application uses fingerprinting, test against different vulnerabilities related to this [https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf feature]

== M2 - Insecure Data storage [Client Attacks] ==

This Section should be ideally tested after using the application for some time. This way application has time to store some data on the disk.
It will probably require the use of a rooted Android device in order to access files in Android such as '/sdcard'
Commonplaces to look at

* /data/data/app_folder
* /sdcard/
* /sdcard1/

Android applications need to store data locally in sqlite files or XML structures and hence need to performs either SQL/XML Queries or file I/O.

This gives rise to 2 major issues.

# SQL / XML injection, and if the reading intent is publicly exposed another application could read this.
# Local file read which can allow other application to read files of the application in question and if they contain sensitive data then data leakage via this media.

If the application is a HTML5 hybrid application then Cross Site Scripting (XSS) should also be considered.
XSS will expose the entire application to the attacker as HTML5 applications will have the ability to call native functionality and hence control over the entire application. (WebViews)

Additionally a backup of the application could be made using `adb backup` option and that can be analyzed to identify what the application stores and leaks when the client interacts with it.

== M3 - Insufficient Transport Layer [Network/Traffic attacks]==

Multiple layer of checks to be performed here

1. On Server side
* Identify all ssl endpoints.
* Perform SSL Cipher Scan using (sslscan)[https://github.com/rbsec/sslscan] or similar software.
* SSLv2, SSLv3 is disabled
* TLS 1.2, 1.1 and 1.0 is supported (1.2 is essential to ensure highest possible secure connection)
* RC4 and CBC Based Ciphers are disabled
* DH Params are >2048 Bits
* SSL Certificate is signed with atleast sha2 / sha256
* ECDHE Ciphers / Ciphers supporting Perfect forward secrecy are preferred
* SSL Certificate is from Trusted RootCA
* SSL Certificate is not expired
*[https://developer.android.com/training/articles/security-tips.html#IPC Verify Interprocess communication implementation]

2. On Device Side
* Ensure application is working correctly by navigating around.
* Put a proxy in between the application and remote server. If application fails to load. Application might be doing cert validation. Refer logcat if any message is printed.
* Place Proxy RootCA in trusted root CA list in device. (Burp)[https://support.portswigger.net/customer/portal/articles/1841101-configuring-an-android-device-to-work-with-burp] (OWASP-ZAP)[https://security.secure.force.com/security/tools/webapp/zapandroidsetup]
* Try using application again. If application still doesn't connect, application might be doing cert pinning.
* Install (Xposed Framework)[http://repo.xposed.info/module/de.robv.android.xposed.installer] and (Just Trust Me)[https://github.com/Fuzion24/JustTrustMe], enable JustTrustMe and then reboot device.
* Try again if everything works we have a application which employee's cert pinning and we have bypassed it using the xposed module.
* [https://developer.android.com/training/articles/security-gms-provider.html Android Security provider has been properly updated against SSL Exploits]

== M4 - Insecure Authentication [Client/Server attacks]==
For this part some of the tools necessary in order to carry on the assessment are,
*attack proxies such as ZAP, BURP or Charles
*Wireshark for Traffic analysis

By analyzing the traffic (HTTP request/response) between client and server, check the following items
*Analyze session management and workflow
*Analyze API authentication using an attack proxy
*Insecure WebViews
*Check if Credentials are being stored in the Datastore or Server side
* Misuse or access to [https://developer.android.com/reference/android/accounts/AccountManager.html Account Manager]
*[https://docs.box.com/docs/android-security-guidelines#section-authenticating-callers-of-components Authenticating Callers of Components]

Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application.
There are multiple things to look at
* Check and validate Sessions on the Backend
* Check for session Timeout Protection
* Check for improper Cookies configuration
* Insecure Token Creation
*Insecure implementation of [https://developer.android.com/training/articles/security-tips.html#WebView WebView]

== M5 - Insufficient Cryptography [Client/Network/Server attacks]==
For this part , you will need to perform a overall analysis where you can enumerate where encryption has been used. For example:
*Type SSL/TLS encryption used
*Retrieving files securely using HTTPS URI or a secure tunnel such as implementing HttpsURLConnection or SSLSocket
*Authentication Session Tokens
*Data storage containing sensitive information in clear text
*Access to encryption keys or improper key management
* Usage of known weak crypto algo's like Rot13, MD4, MD5, RC2, RC4, SHA1
* Do it Yourself / let me design my own algo for encryption
* Secret key hard coded in the application code itself.
*Implementation of own protocol
*Insecure use of Random Generators

== M6 - Insecure Authorization [Client/Server attacks] ==
After a proper Application mapping and understanding the data flow, you can verify the authorization mechanism for the following:
*Handling credentials: does the application make use of authorization tokens instead of asking Credentials all the time?
*Verify that the application allows access only to the allowed roles
*Storing username and password in the data storage instead of using [https://developer.android.com/training/articles/security-tips.html AccountManager]

== M7 - Client Code Quality [Client Attacks]==
There are 2 approaches for this part:
*if you have access to the source code, doing code review on the Client app and the server API.
*IF you don't, you could still check the code by decompiling the APK

We strongly recommend a Code Review in this case. This will definitely extract many potential vulnerabilities due to bad implementation

== M8 - Code Tampering [Client Attacks]==
For this part you will need a rooted device and reverse engineering techniques
*Decompile APK using tools such as apktool, dex2jar / enjarify, Bytecodeviewer or commercial tools such as JEB
*Analysze code using decompiler such as JD-GUI or Bytecodeviewer. Commercial version such as JEB allows you to even debug the decompiled application but not in all cases
* After analyzing the code, attempt to bypass functionalities whether by changing the Smali code or Hooking methods using Xposed or Frida frameworks
* Verify if the application has been obfuscated and verify the level of obfuscation searching for specific strings.
*Decompile APK and change Smali, (check this tool: https://github.com/voider1/a2scomp)
*Android Binaries are basically dex classes, which if not protected can result in an easy decompilation of source code. This could lead to code / logic leakage.
Following controls need to be checked for and validated:

* Jailbreak, Device Rooted- Detection Controls
* Checksum Controls
* Certificate Pinning Controls
* Debugger Detection Controls
*Xposed Detection Controls
*[https://developer.android.com/training/articles/security-tips.html#DynamicCode Dynamic loading code]
*[https://developer.android.com/training/articles/security-tips.html#Native use of Native code with Android NDK]

References

(OWASP M10-2014)[https://www.owasp.org/index.php/Mobile_Top_10_2014-M10]

== M9 -Reverse Engineering [Client attacks] ==
Reverse Engineering is an essential part of pen testing mobile applications. It also requires the use of rooted devices.
For this part make sure that you have prepared the following tools :
*Android Studio with SDK tools installed
*A rooted Android Device or Emulator
*For a rooted emulator you can use CuckoDroid which has Xposed installed
*Different tools installed for decompiling the APK such as apktool,Dex2Jar / enjarify or if you are looking for a total one use Bytecodeviewer or JEB
*IDA pro (for analyzing code flow)
* Smali decompiler/compiler and signer : https://github.com/voider1/a2scomp

Verify that:
*Has the application be obfuscated?
*Search for key strings and keywords with tools like Bytecodeviewer or JEB
*Search for implantation of SSL pinning , Device rooted or connections to API's (search for words like 'TrustManager' , 'SHA256', X509 ,SHA, SSL , for more info see [https://docs.box.com/docs/android-security-guidelines Android Security Guidelines]

== M10 - Extraneous Functionality ==
For testing this part, it will be necessary to do a code review or Reverse engineer the APK (if code is not available)

= Authors and Primary Editors =

* Jonathan Carter
* Prashant Phatak
* Milan Singh Thakur
* Anant Shrivastava
* Johanna Curiel

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Android Testing Cheat Sheet

2017-02-25T07:05:39Z

Anant Shrivastava: minor edit: added alternatives for dex2jar and changed capitilization

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =

This cheat sheet provides a checklist of tasks to be performed to do a penetration test of an Android application. It follows the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project OWASP Mobile Top 10 Risks] list.

== Testing Methodology ==
[[File:Andpen2.png]]

A complete android pen testing involves different areas such as the ones described in the above picture

===Application Mapping===
In this first phase, the focus relies on understanding the application logic and what exactly the application does.
This involves some manual test where we do some basic operations such as install the APK on the phone, login and comprehend the functionality of the app.

Map the application for possible security vectors such as:
# What is the application genre ? (Game, business, productivity etc)
# Does the application connect to backend web services?
# Is the application purely native or incorporates readymade frameworks?
# Does the application store data on the device?
# What all features of the device are used by the application? (camera, gyroscope, contacts etc)

===Client Attacks===
This is one of the most challenging and exciting parts of the pentest assessment. Android apps are packed as an APK, also known as Android Package Kit or Android Application Package. Our mission as Pen testers is to verify how well protected the application has been created and designed against known threat actors.Android Mobile applications are distributed through platforms like Google Play. Since the application is fully installed on the client, it becomes vulnerable to any attacks coming from the client.

===Network Attacks===
As we need to identify vulnerabilities in the Client, is also essential to verify how secure is the communication between the Client and the Server by evaluating the traffic. For this purpose, using tools like Attack proxies, evaluating potential SSL issues, and executing Wireshark Data package inspection is an essential part of the assessment.

===Server Attacks===
Last but not least, issues at the Server level will impact the security of the application. Insecure implementation such as misconfigurations , vulnerabilities and issues at API or Database level, affect also the security of an application

At the device level, there are 2 ways in which the application shall be tested. Reverse Engineering is an essential part of pen testing mobile applications. It also requires the use of rooted devices. If you have been wondering why do we need to Reverse Engineer an installed APK, the major reason relies on the client.

==Devices==

There are also different ways to pentest the application , and we should consider in which case we need to use one or the other

# With Android device running in a factory default or normal mode
# With Android device running in a rooted mode

At the application level, there are 2 ways in which it shall be tested
# Application running on the device (to take benefits of touch related features)
# Application running on the emulator (to ease the task of testing using wider screen of desktop or laptop)

= OWASP Step-by-step Approach =
(For each of the standards below, there shall be multiple steps for the tester to follow])
== M1 - Improper Platform Usage [Client Attacks]==
* Check AndroidManifest.xml permissions [https://developer.android.com/reference/android/Manifest.permission.html configurations] certain permissions can be [https://developer.android.com/guide/topics/permissions/requesting.html#normal-dangerous dangerous]
*If application uses fingerprinting, test against different vulnerabilities related to this [https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf feature]

== M2 - Insecure Data storage [Client Attacks] ==

This Section should be ideally tested after using the application for some time. This way application has time to store some data on the disk.
It will probably require the use of a rooted Android device in order to access files in Android such as '/sdcard'
Commonplaces to look at

* /data/data/app_folder
* /sdcard/
* /sdcard1/

Android applications need to store data locally in sqlite files or XML structures and hence need to performs either SQL/XML Queries or file I/O.

This gives rise to 2 major issues.

# SQL / XML injection, and if the reading intent is publicly exposed another application could read this.
# Local file read which can allow other application to read files of the application in question and if they contain sensitive data then data leakage via this media.

If the application is a HTML5 hybrid application then Cross Site Scripting (XSS) should also be considered.
XSS will expose the entire application to the attacker as HTML5 applications will have the ability to call native functionality and hence control over the entire application. (WebViews)

== M3 - Insufficient Transport Layer [Network/Traffic attacks]==

Multiple layer of checks to be performed here

1. On Server side
* Identify all ssl endpoints.
* Perform SSL Cipher Scan using (sslscan)[https://github.com/rbsec/sslscan] or similar software.
* SSLv2, SSLv3 is disabled
* TLS 1.2, 1.1 and 1.0 is supported (1.2 is essential to ensure highest possible secure connection)
* RC4 and CBC Based Ciphers are disabled
* DH Params are >2048 Bits
* SSL Certificate is signed with atleast sha2 / sha256
* ECDHE Ciphers / Ciphers supporting Perfect forward secrecy are preferred
* SSL Certificate is from Trusted RootCA
* SSL Certificate is not expired
*[https://developer.android.com/training/articles/security-tips.html#IPC Verify Interprocess communication implementation]

2. On Device Side
* Ensure application is working correctly by navigating around.
* Put a proxy in between the application and remote server. If application fails to load. Application might be doing cert validation. Refer logcat if any message is printed.
* Place Proxy RootCA in trusted root CA list in device. (Burp)[https://support.portswigger.net/customer/portal/articles/1841101-configuring-an-android-device-to-work-with-burp] (OWASP-ZAP)[https://security.secure.force.com/security/tools/webapp/zapandroidsetup]
* Try using application again. If application still doesn't connect, application might be doing cert pinning.
* Install (Xposed Framework)[http://repo.xposed.info/module/de.robv.android.xposed.installer] and (Just Trust Me)[https://github.com/Fuzion24/JustTrustMe], enable JustTrustMe and then reboot device.
* Try again if everything works we have a application which employee's cert pinning.
* [https://developer.android.com/training/articles/security-gms-provider.html Android Security provider has been properly updated against SSL Exploits]

== M4 - Insecure Authentication [Client/Server attacks]==
For this part some of the tools necessary in order to carry on the assessment are,
*attack proxies such as ZAP, BURP or Charles
*Wireshark for Traffic analysis

By analyzing the traffic (HTTP request/response) between client and server, check the following items
*Analyze session management and workflow
*Analyze API authentication using an attack proxy
*Insecure WebViews
*Check if Credentials are being stored in the Datastore or Server side
* Misuse or access to [https://developer.android.com/reference/android/accounts/AccountManager.html Account Manager]
*[https://docs.box.com/docs/android-security-guidelines#section-authenticating-callers-of-components Authenticating Callers of Components]

Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application.
There are multiple things to look at
* Check and validate Sessions on the Backend
* Check for session Timeout Protection
* Check for improper Cookies configuration
* Insecure Token Creation
*Insecure implementation of [https://developer.android.com/training/articles/security-tips.html#WebView WebView]

== M5 - Insufficient Cryptography [Client/Network/Server attacks]==
For this part , you will need to perform a overall analysis where you can enumerate where encryption has been used. For example:
*Type SSL/TLS encryption used
*Retrieving files securely using HTTPS URI or a secure tunnel such as implementing HttpsURLConnection or SSLSocket
*Authentication Session Tokens
*Data storage containing sensitive information in clear text
*Access to encryption keys or improper key management
* Usage of known weak crypto algo's like Rot13, MD4, MD5, RC2, RC4, SHA1
* Do it Yourself / let me design my own algo for encryption
* Secret key hard coded in the application code itself.
*Implementation of own protocol
*Insecure use of Random Generators

== M6 - Insecure Authorization [Client/Server attacks] ==
After a proper Application mapping and understanding the data flow, you can verify the authorization mechanism for the following:
*Handling credentials: does the application make use of authorization tokens instead of asking Credentials all the time?
*Verify that the application allows access only to the allowed roles
*Storing username and password in the data storage instead of using [https://developer.android.com/training/articles/security-tips.html AccountManager]

== M7 - Client Code Quality [Client Attacks]==
There are 2 approaches for this part:
*if you have access to the source code, doing code review on the Client app and the server API.
*IF you don't, you could still check the code by decompiling the APK

We strongly recommend a Code Review in this case. This will definitely extract many potential vulnerabilities due to bad implementation

== M8 - Code Tampering [Client Attacks]==
For this part you will need a rooted device and reverse engineering techniques
*Decompile APK using tools such as apktool, dex2jar / enjarify, Bytecodeviewer or commercial tools such as JEB
*Analysze code using decompiler such as JD-GUI or Bytecodeviewer. Commercial version such as JEB allows you to even debug the decompiled application but not in all cases
* After analyzing the code, attempt to bypass functionalities whether by changing the Smali code or Hooking methods using Xposed or Frida frameworks
* Verify if the application has been obfuscated and verify the level of obfuscation searching for specific strings.
*Decompile APK and change Smali, (check this tool: https://github.com/voider1/a2scomp)
*Android Binaries are basically dex classes, which if not protected can result in an easy decompilation of source code. This could lead to code / logic leakage.
Following controls need to be checked for and validated:

* Jailbreak, Device Rooted- Detection Controls
* Checksum Controls
* Certificate Pinning Controls
* Debugger Detection Controls
*Xposed Detection Controls
*[https://developer.android.com/training/articles/security-tips.html#DynamicCode Dynamic loading code]
*[https://developer.android.com/training/articles/security-tips.html#Native use of Native code with Android NDK]

References

(OWASP M10-2014)[https://www.owasp.org/index.php/Mobile_Top_10_2014-M10]

== M9 -Reverse Engineering [Client attacks] ==
Reverse Engineering is an essential part of pen testing mobile applications. It also requires the use of rooted devices.
For this part make sure that you have prepared the following tools :
*Android Studio with SDK tools installed
*A rooted Android Device or Emulator
*For a rooted emulator you can use CuckoDroid which has Xposed installed
*Different tools installed for decompiling the APK such as apktool,Dex2Jar / enjarify or if you are looking for a total one use Bytecodeviewer or JEB
*IDA pro (for analyzing code flow)
* Smali decompiler/compiler and signer : https://github.com/voider1/a2scomp

Verify that:
*Has the application be obfuscated?
*Search for key strings and keywords with tools like Bytecodeviewer or JEB
*Search for implantation of SSL pinning , Device rooted or connections to API's (search for words like 'TrustManager' , 'SHA256', X509 ,SHA, SSL , for more info see [https://docs.box.com/docs/android-security-guidelines Android Security Guidelines]

== M10 - Extraneous Functionality ==
For testing this part, it will be necessary to do a code review or Reverse engineer the APK (if code is not available)

= Authors and Primary Editors =

* Jonathan Carter
* Prashant Phatak
* Milan Singh Thakur
* Anant Shrivastava
* Johanna Curiel

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

OWASP Mobile Security Testing Guide

2016-12-13T17:43:39Z

Anant Shrivastava: masvs link correction as per https://github.com/OWASP/owasp-masvs/issues/63

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_MSTG_Header.jpg|link=]]</div>


{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==Our Vision ==

'''Create a comprehensive methodology that covers the processes, techniques, and tools used during a mobile app security test, and define an exhaustive set of test cases that enables testers to deliver consistent and complete results.'''

At least, that was the ''initial'' vision. However, we soon discovered that we had to ask some deeper questions on what mobile app security is about: Without a reasonable definition a "secure" mobile app, there wasn't really anything to test against. We therefore went back to the drawing board and wrote the MASVS, a "mobile security standard" that defines the baseline security requirements.

== Main Documents ==

{| cellpadding="5"
|-
| [[File:masvs-sample-mini.jpg|link=]]
| '''Mobile AppSec Verification Standard (MASVS)'''
A standard for mobile app security. It is meant to be used by mobile software architects and developers seeking to develop secure mobile applications and as a basis for mobile app security testing methodologies. The MASVS lists requirements for both security controls and software protection mechanisms, and defines four verification levels that can be applied to achieve different grades of security and resiliency.

The MASVS is in a pre-release state. A (slightly outdated) [https://github.com/OWASP/owasp-masvs/releases/tag/0.91 PDF release] is available. The most current set of requirements can be found in the master branch on [https://github.com/OWASP/owasp-masvs GitHub].
|-
| [[File:testing-guide-sample-mini.jpg|link=]]
| '''Mobile Security Testing Guide (MSTG)'''
A comprehensive guide for iOS and Android mobile security testers that includes the following content:
# Mobile platform internals
# Testing in the secure development lifecycle
# Basic white-box and black-box security testing
# Mobile reverse engineering and tampering
# Assessing software protections
# Detailed white-box and black-box test cases that map to the requirements in the MASVS.
The MSTG is a work-in-progress. Currently, we hope to be "feature-complete" in Q1 2017. You can access the existing content in the [https://github.com/OWASP/owasp-mstg GitHub Repo].
|-
| [[File:checklist.jpg|link=]]
| '''Mobile Security Testing Checklists'''
A basis of checklists will be made available in addition to the verification standard and testing guide.
|}

[[Category:OWASP Project]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]


| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="center" width="50%"| [[File:Owasp-breakers-small.png|link=https://www.owasp.org/index.php/Breakers]]
|
|-
| align="center" valign="center" width="50%"|
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

== Project Leaders ==

<span style="color:#ff0000">

[https://www.owasp.org/index.php/User:Bernhard_Mueller Bernhard Mueller]

[https://www.owasp.org/index.php/User:Sven_Schleier Sven Schleier]

== Project Initiator ==

[https://www.owasp.org/index.php/User:Milan_Singh_Thakur Milan Singh Thakur]

== Road Map ==

* Q2 2017: Beta release
* Q3 2017: Version 1.0
* Q4 2017: Produce A Printable Book

== Parent Project ==

[[OWASP_Mobile_Security_Project]]

==Licensing==

The guide is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

|}

=News=

== December 4th, 2016: Call for authors: The ultimate open-source mobile app reverse engineering guide ==

Reverse engineering is an art, and describing every available facet of it would fill a whole library. The sheer range techniques and possible specializations is mind-blowing: One can spend years working on a very specific, isolated sub-problem, such as automating malware analysis or developing novel de-obfuscation methods. For mobile app security testers, it can be challenging to filter through the vast amount of information and build a working methodology. Things become even more problematic when one is tasked to assess apps that are heavily obfuscated and have anti-tampering measures built in.

One of the main goals in the MSTG is to build the ultimate resource for mobile reverse engineers. This includes not only basic static and dynamic analysis, but also advanced de-obfuscation, scripting and automation. Obviously, writing all this content is a lot of work, both in terms of general content and OS-specific how-tos. We're therefore looking for talented authors that want to join the project early on. Topics include the following:

* Basic Hybrid Static/Dynamic Analysis
* Code Injection and Dynamic Instrumentation (Substrate, FRIDA)
* Dynamic Binary Instrumentation (Valgrind, PIE)
* Analysis Frameworks (Metasm / Miasm)
* Symbolic Execution
* DCA and DPA attacks on white-box crypto
* Dynamic analysis frameworks (PANDA / DroidScope,...)
* Anything else we might have missed

=== What is in for me? ===

All of this is unpaid, volunteer work. However, depending on your contribution, you will be named in the "lead authors" or "contributors" list, and you'll be able to point to the fact that you co-authored the guide. You'll also be contributing to the field, helping others who are just starting out, and in turn becoming a happier person yourself (reaping the full benefits of your altruism).

=== Where do I sign up? ===

First of all, have a look at the existing RE chapters outline:

* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06-Reverse-Engineering-and-Tampering.md Generic / Introduction]
* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06a-Reverse-Engineering-and-Tampering-Android.md Android]
* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06b-Reverse-Engineering-and-Tampering-iOS.md iOS]

You'll probably immediately have ideas on how you can contribute. If that's the case, read the [https://github.com/OWASP/owasp-mstg/blob/master/authors_guide.md author's guide] first.

Then contact [https://github.com/b-mueller Bernhard Mueller] - ideally directly on the [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel], where you'll find all the other project members. You can sign up for an account [http://owasp.herokuapp.com/ here].

=FAQs=

==How can I participate in your project?==
First of all, read the [https://github.com/OWASP/owasp-mstg/blob/master/authors_guide.md author's guide] and decide in what for you would like to contribute.
Then, contact the lead author responsible for the chapter you are interested in. You can find their name and GitHub handle in the project [https://github.com/OWASP/owasp-mstg/blob/master/README.md README]. Please always check with the responsible person first, or you might end up working on a chapter that's already being done by someone else.
In any case, we encourage you to join [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel], where you'll find all the other project members. You can sign up for an account [http://owasp.herokuapp.com/ here].

The home of the OWASP Mobile Security Testing Guide is on [https://github.com/OWASP/owasp-mstg GitHub.] The MASVS is hosted in a [https://github.com/OWASP/owasp-masvs separate repository].

==Where do you guys need help the most?==

There's a lot of areas where you can help out:

* Writing original content, such as describing testing processes and writing test cases. We're all doing this in our spare time, which unfortunately means that things sometimes slow down to a crawl. If you're knowledgeable in some area and have time available, we'd be incredibly thankful to anyone who contributes, even if it's only one or two test cases.

* Reviewing content and giving feedback. The proper channel for questions and feedback is the GitHub issues system of the respective repo, contacting us on [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel] is another possibility.

* Developing tools. For example, we still don't have an automated way of generating checklists out of the GitHub repo.

* Contributing to auxiliary projects: The [https://github.com/b-mueller/obfuscation-metrics obfuscation metrics project] is an auxiliary project that deals with specific forms of control flow and data obfuscation. This project needs experts in advanced obfuscation / de-obfuscation. Please contact us if you have experience in this area.

==If I am not a programmer can I participate in your project?==
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

==I contributed to the original Google Doc, but I'm not credited in the new version of the MSTG? ==
As we migrated some of the existing content, we did our best to backtrack the original authors and credit them appropriately. We also added a [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x02-Frontispiece.md revision history] that lists all the authors from old Google Docs. If you are not on that list but feel you should be, please contact [https://github.com/b-mueller Bernhard] or [https://github.com/sushi2k Sven] and they'll fix it. Or better yet, re-join the author's team and start contributing to the new guide.

= Acknowledgements =

==Contributors==

The Mobile Security Testing Guide was initiated by [https://www.owasp.org/index.php/User:Milan_Singh_Thakur Milan Singh Thakur] in 2015. The original document was hosted on Google Drive. Guide development was moved to GitHub in October 2016. Below is the full list of contributors for each revision.

=== MSTG in its current form ===

'''Lead Authors:'''

* Stephen Corbiaux
* Bernhard Mueller
* Sven Schleier
* Francesco Stillavato
* Stefan Streichsbier
* Abdessamad Temmar
* Stephanie Vanroelen
* Gerhard Wagner
* Jeroen Willemsen

'''Contributors:'''

* Davide Cioccia
* Bao Le
* Shiv Patel
* Prathan Phongthiproek
* Abhinav Sejpal
* Anant Shrivastava
* Pragati Singh
* Milan Singh Thakur
* Blessen Thomas
* Dennis Titze
* Bernard Wagner

=== MSTG "Beta 2" on Google Drive ===

'''Authors:'''

* Mirza Ali
* Stephen Corbiaux
* Ryan Dewhurst
* Mohammad Hamed Dadpour
* David Fern
* Bao Lee
* Anto Joseph
* Nutan Kumar Panda
* Rahil Parikh
* Julian Schütte
* Abhinav Sejpal
* Anant Shrivastava
* Pragati Singh
* Milan Singh Thakur
* Stephanie Vanroelen
* Gerhard Wagner

'''Reviewers:'''

* Andrew Muller
* Jonathan Carter
* Stephanie Vanroelen
* Milan Singh Thakur

=== MSTG "Beta 1" on Google Drive ===

'''Authors:'''

*Mirza Ali
*Mohammad Hamed Dadpour
*David Fern
*Rahil Parikh
*Abhinav Sejpal
*Pragati Singh
*Milan Singh Thakur

'''Reviewers:'''

*Andrew Muller
*Jonathan Carter

'''Top Contributors:'''

*Jim Manico
*Yair Amit
*Amin Lalji
*OWASP Mobile Team


__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Android Testing Cheat Sheet

2016-03-25T06:11:42Z

Anant Shrivastava: /* M10 - Lack of Binary Protection */

Android Testing Cheat Sheet

2016-03-25T06:11:13Z

Anant Shrivastava: /* M10 - Lack of Binary Protection */

Android Testing Cheat Sheet

2016-03-24T19:24:41Z

Anant Shrivastava: Restored M9 to correct place

Android Testing Cheat Sheet

2016-03-18T17:36:36Z

Anant Shrivastava: /* M7 - Client Side Injection */

Android Testing Cheat Sheet

2016-03-18T17:30:45Z

Anant Shrivastava: /* M6 - Broken Cryptography */

Android Testing Cheat Sheet

2016-03-17T07:12:57Z

Anant Shrivastava: /* M5 - Poor Authorization and Authentication */

Android Testing Cheat Sheet

2016-03-17T07:09:23Z

Anant Shrivastava: /* Authors and Primary Editors */

Android Testing Cheat Sheet

2016-03-17T05:44:07Z

Anant Shrivastava: /* M4 - Unintended Data Leakage */

Android Testing Cheat Sheet

2016-03-17T05:26:26Z

Anant Shrivastava: /* M3 - Insufficient Transport Layer */

Android Testing Cheat Sheet

2016-03-17T05:16:06Z

Anant Shrivastava: /* M2 - Insecure Data storage */

Certificate and Public Key Pinning

2016-01-17T18:50:45Z

Anant Shrivastava: /* References */ added a talk delivered by me covering SSL pinning and its bypasses.

[[Certificate and Public Key Pinning]] is a technical guide to implementing certificate and public key pinning as discussed at the ''[https://www.owasp.org/index.php/Virginia Virginia chapter's]'' presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]]. This guide is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability. Additional presentation material included [[Media:pubkey-pin-supplement.pdf|supplement with code excerpts]], [[Media:pubkey-pin-android.zip|Android sample program]], [[Media:pubkey-pin-ios.zip|iOS sample program]], [[Media:pubkey-pin-dotnet.zip|.Net sample program]], and [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]].

A cheat sheet is available at [[Pinning_Cheat_Sheet|Pinning Cheat Sheet]].

== Introduction ==

Secure channels are a cornerstone to users and employees working remotely and on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.

The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on untrusted input. The situation is somewhat of a paradox: entities such as DNS and CAs are trusted and supposed to supply trusted input; yet their input cannot be trusted. Relying on untrusted input for security related decisions is not only bad karma, it violates a number of secure coding principals (see, for example, OWASP's [[Injection Theory]] and [[Data Validation]]).

Pinning effectively removes the "conference of trust". An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making security decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning is nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.

Others who actively engage in pinning include Google and its browser Chrome. Chrome was successful in detecting the DigiNotar compromise which uncovered suspected interception by the Iranian government on its citizens. The initial report of the compromise can be found at ''[https://productforums.google.com/d/topic/gmail/3J3r2JqFNTw/discussion Is This MITM Attack to Gmail's SSL?]''; and Google Security's immediate response at ''[https://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html An update on attempted man-in-the-middle attacks]''.

== What's the problem? ==

Users, developers, and applications expect end-to-end security on their secure channels, but some secure channels are not meeting the expectation. Specifically, channels built using well known protocols such as VPN, SSL, and TLS can be vulnerable to a number of attacks.

Examples of past failures are listed on the discussion tab for this article. This cheat sheet does not attempt to catalogue the failures in the industry, investigate the design flaws in the scaffolding, justify the lack of accountability or liability with the providers, explain the race to the bottom in services, or demystify the collusion between, for example, Browsers and CAs. For additional reading, please visit ''[http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf PKI is Broken]'' and ''[http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html The Internet is Broken]''.

=== Patient 0 ===

The original problem was the ''Key Distribution Problem''. Insecure communications can be transformed into a secure communication problem with encryption. Encrypted communications can be transformed into an identity problem with signatures. The identity problem terminates at the key distribution problem. They are the same problem.

=== The Cures ===

There are three cures for the key distribution problem. First is to have first hand knowledge of your partner or peer (i.e., a peer, server or service). This could be solved with SneakerNet. Unfortunately, SneakerNet does not scale and cannot be used to solve the key distribution problem.

The second is to rely on others, and it has two variants: (1) web of trust, and (2) hierarchy of trust. Web of Trust and Hierarchy of Trust solve the key distribution problem in a sterile environment. However, Web of Trust and Hierarchy of Trust each requires us to rely on others - or '''confer trust'''. In practice, trusting others is showing to be problematic.

== What Is Pinning? ==

Pinning is the process of associating a host with their ''expected'' X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a ''pinset'' (taking from [https://developers.google.com/events/io/sessions/gooio2012/107/ Jon Larimer and Kenny Root Google I/O talk]). In this case, the advertised identity must match one of the elements in the pinset.

A host or service's certificate or public key can be added to an application at development time, or it can be added upon first encountering the certificate or public key. The former - adding at development time - is preferred since ''preloading'' the certificate or public key ''out of band'' usually means the attacker cannot taint the pin. If the certificate or public key is added upon first encounter, you will be using ''key continuity''. Key continuity can fail if the attacker has a privileged position during the first first encounter.

Pinning leverages knowledge of the pre-existing relationship between the user and an organization or service to help make better security related decisions. Because you already have information on the server or service, you don't need to rely on generalized mechanisms meant to solve the ''key distribution'' problem. That is, you don't need to turn to DNS for name/address mappings or CAs for bindings and status. One exception is revocation and it is discussed below in [[#Pinning_Gaps|Pinning Gaps]].

It is also worth mention that Pinning is not Stapling. Stapling sends both the certificate and OCSP responder information in the same request to avoid the additional fetches the client should perform during path validations.

=== When Do You Pin? ===

You should pin anytime you want to be relatively certain of the remote host's identity or when operating in a hostile environment. Since one or both are almost always true, you should probably pin all the time.

A perfect case in point: during the two weeks or so of preparation for the presentation and cheat sheet, we've observed three relevant and related failures. First was [http://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/ Nokia/Opera willfully breaking the secure channel]; second was [http://blog.malwarebytes.org/intelligence/2013/02/digital-certificates-and-malware-a-dangerous-mix/ DigiCert issuing a code signing certificate for malware]; and third was [http://krebsonsecurity.com/2013/02/security-firm-bit9-hacked-used-to-spread-malware/ Bit9's loss of its root signing key]. The environment is not only hostile, its toxic.

=== When Do You Whitelist? ===

If you are working for an organization which practices "egress filtering" as part of a Data Loss Prevention (DLP) strategy, you will likely encounter ''Interception Proxies''. I like to refer to these things as '''"good" bad guys''' (as opposed to '''"bad" bad guys''') since both break end-to-end security and we can't tell them apart. In this case, '''do not''' offer to whitelist the interception proxy since it defeats your security goals. Add the interception proxy's public key to your pinset after being '''instructed''' to do so by the folks in Risk Acceptance.

Note: if you whitelist a certificate or public key for a different host (for example, to accommodate an interception proxy), you are no longer pinning the expected certificates and keys for the host. Security and integrity on the channel could suffer, and it surely breaks end-to-end security expectations of users and organizations.

For more reading on interception proxies, the additional risk they bestow, and how they fail, see Dr. Matthew Green's ''[http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html How do Interception Proxies fail?]'' and Jeff Jarmoc's BlackHat talk ''[https://www.blackhat.com/html/bh-eu-12/bh-eu-12-archives.html#jarmoc SSL/TLS Interception Proxies and Transitive Trust]''.

=== How Do You Pin? ===

The idea is to re-use the existing protocols and infrastructure, but use them in a hardened manner. For re-use, a program would keep doing the things it used to do when establishing a secure connection.

To harden the channel, the program would take advantage of the <tt>OnConnect</tt> callback offered by a library, framework or platform. In the callback, the program would verify the remote host's identity by validating its certificate or public key. While pinning does not have to occur in an <tt>OnConnect</tt> callback, its often most convenient because the underlying connection information is readily available.

== What Should Be Pinned? ==

The first thing to decide is what should be pinned. For this choice, you have two options: you can (1) pin the certificate; or (2) pin the public key. If you choose public keys, you have two additional choices: (a) pin the <tt>subjectPublicKeyInfo</tt>; or (b) pin one of the concrete types such as <tt>RSAPublicKey</tt> or <tt>DSAPublicKey</tt>.

The three choices are explained below in more detail. I would encourage you to pin the <tt>subjectPublicKeyInfo</tt> because it has the public parameters (such as <tt>{e,n}</tt> for an RSA public key) '''and''' contextual information such as an algorithm and OID. The context will help you keep your bearings at times, and Figure 1 below shows the additional information available.

=== Encodings/Formats ===

For the purposes of this article, the objects are in X509-compatible presentation format (PKCS#1 defers to X509, both of which use ASN.1). If you have a PEM encoded object (for example, <tt>-----BEGIN CERTIFICATE-----</tt>, <tt>-----END CERTIFICATE-----</tt>), then convert the object to DER encoding. Conversion using OpenSSL is offered below in [[#Format_Conversions|Format Conversions]].

A certificate is an object which binds an entity (such as a person or organization) to a public key via a signature. The certificate is DER encoded, and has associated data or attributes such as ''Subject'' (who is identified or bound), ''Issuer'' (who signed it), ''Validity'' (''NotBefore'' and ''NotAfter''), and a ''Public Key''.

A certificate has a ''subjectPublicKeyInfo''. The subjectPublicKeyInfo is a key with additional information. The ASN.1 type includes an ''Algorithm ID'', a ''Version'', and an extensible format to hold a concrete public key. Figures 1 and 2 below show different views of the same RSA key, which is the subjectPublicKeyInfo. The key is for the site [https://www.random.org random.org], and it is used in the sample programs and listings below.

{| align="center"
| [[File:random-org-der-dump.png|thumb|375px|Figure 1: subjectPublicKeyInfo dumped with dumpans1]]
| [[File:random-org-der-hex.png|thumb|375px|Figure 2: subjectPublicKeyInfo under a hex editor]]
|}

The concrete public key is an encoded public key. The key format will usually be specified elsewhere - for example, PKCS#1 in the case of RSA Public Keys. In the case of an RSA public key, the type is ''RSAPublicKey'' and the parameters <tt>{e,n}</tt> will be ASN.1 encoded. Figures 1 and 2 above clearly show the modulus (''n'' at line 28) and exponent (''e'' at line 289). For DSA, the concrete type is DSAPublicKey and the ASN.1 encoded parameters would be <tt>{p,q,g,y}</tt>.

Final takeaways: (1) a certificate binds an entity to a public key; (2) a certificate has a subjectPublicKeyInfo; and (3) a subjectPublicKeyInfo has an concrete public key. For those who want to learn more, a more in-depth discussion from a programmer's perspective can be found at the Code Project's article ''[http://www.codeproject.com/Articles/25487/Cryptographic-Interoperability-Keys Cryptographic Interoperability: Keys]''.

=== Certificate ===

[[File:pin-cert.png|thumb|right|100px|Certificate]] The certificate is easiest to pin. You can fetch the certificate out of band for the website, have the IT folks email your company certificate to you, use <tt>openssl s_client</tt> to retrieve the certificate etc. When the certificate expires, you would update your application. Assuming your application has no bugs or security defects, the application would be updated every year or two.

At runtime, you retrieve the website or server's certificate in the callback. Within the callback, you compare the retrieved certificate with the certificate embedded within the program. If the comparison fails, then fail the method or function.

There is a downside to pinning a certificate. If the site rotates its certificate on a regular basis, then your application would need to be updated regularly. For example, Google rotates its certificates, so you will need to update your application about once a month (if it depended on Google services). Even though Google rotates its certificates, the underlying public keys (within the certificate) remain static.

=== Public Key ===

[[File:pin-pubkey.png|thumb|right|100px|Public Key]] Public key pinning is more flexible but a little trickier due to the extra steps necessary to extract the public key from a certificate. As with a certificate, the program checks the extracted public key with its embedded copy of the public key.

There are two downsides two public key pinning. First, its harder to work with keys (versus certificates) since you usually must extract the key from the certificate. Extraction is a minor inconvenience in Java and .Net, buts its uncomfortable in Cocoa/CocoaTouch and OpenSSL. Second, the key is static and may violate key rotation policies.

=== Hashing ===

While the three choices above used DER encoding, its also acceptable to use a hash of the information (or other transforms). In fact, the original sample programs were written using digested certificates and public keys. The samples were changed to allow a programmer to inspect the objects with tools like <tt>dumpasn1</tt> and other ASN.1 decoders.

Hashing also provides three additional benefits. First, hashing allows you to anonymize a certificate or public key. This might be important if you application is concerned about leaking information during decompilation and re-engineering.

Second, a digested certificate fingerprint is often available as a native API for many libraries, so its convenient to use.

Finally, an organization might want to supply a reserve (or back-up) identity in case the primary identity is compromised. Hashing ensures your adversaries do not see the reserved certificate or public key in advance of its use. In fact, Google's IETF draft ''websec-key-pinning'' uses the technique.

== What About X509? ==

PKI{X} and the Internet form an intersection. What Internet users expect and what they receive from CAs could vary wildly. For example, an Internet user has security goals, while a CA has revenue goals and legal goals. Many are surprised to learn that the user is often required to perform host identity verification even though the CA issued the certificate (the details are buried in CA warranties on their certificates and their Certification Practice Statement (CPS)).

There are a number of PKI profiles available. For the Internet, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)", also known as [http://tools.ietf.org/rfc/rfc5280.txt RFC 5280], is of interest. Since a certificate is specified in the ITU's X509 standard, there are lots of mandatory and optional fields available for validation from both bodies. Because of the disjoint goals among groups, the next section provides guidance.

=== Mandatory Checks ===

All X509 verifications must include:

* A path validation check. The check verifies all the signatures on certificates in the chain are valid under a given PKI. The check begins at the server or service's certificate (the leaf), and proceeds back to a trusted root certificate (the root).

* A validity check, or the <tt>notBefore</tt> and <tt>notAfter</tt> fields. The <tt>notAfter</tt> field is especially important since a CA will not warrant the certificate after the date, and it does not have to provide CRL/OCSP updates after the date.

* Revocation status. As with <tt>notAfter</tt>, revocation is important because the CA will not warrant a certificate once it is listed as revoked. The IETF approved way of checking a certificate's revocation is OCSP and specified in [http://tools.ietf.org/rfc/rfc2560.txt RFC 2560].

=== Optional Checks ===

<nowiki>[Mulling over what else to present, and the best way to present it. Subject name? DNS lookups? Key Usage? Algorithms? Geolocation based on IP? Check back soon.]</nowiki>
In the model which pre-dated PKIX RFC-5280, X.509v1 there was strong binding of the certificate Subject name to the X.500 Directory. With the update to X.509v3, the Directory is still the standard for authentication of caCertificate attributes, versus accepting a self signed root. Geo-location is important, the fake certificate for Google was given a location of Florida, instead of Mountain View, CA. The binding of the certificate to the Directory can anchor the root caCertificate, in effect "pin" it, to a valid entity that can have demonstrable attributes such as location. This is detailed in RFC-1255. Additional fields specified, such as the subject alternative field, for example a RFC-822 email address, or DNS name, can be located in the DNS, but the actual heavy lifting is done by the X.500 Directory, which is used currently as a cross-certificate trust conduit at the Federal Bridge between major communities of interest, that are not Internet focused. While those cross-certificates are valuable in validation between trust communities, a self-signed root, still needs to be either pinned, curated in trust bundle such as in web browser software secure storage or represented by a federated community. The Directory can play a role to fill in gaps to validate caCertificates, either locally, or nationally under an administrative domain such as c=US. By divorcing the subject from the Directory entry, problems begin to arise in which pinning plays a key role to ensure that client and server have the same reference points.

=== Public Key Checks ===

''Quod vide'' (''q.v.''). Verifying the identity of a host with knowledge of its associated/expected public key is pinning.

== Examples of Pinning ==

This section demonstrates certificate and public key pinning in Android Java, iOS, .Net, and OpenSSL. All programs attempt to connect to [https://www.random.org random.org] and fetch bytes (Dr. Mads Haahr participates in AOSP's pinning program, so the site should have a static key). The programs enjoy a pre-existing relationship with the site (more correctly, ''a priori'' knowledge), so they include a copy of the site's public key and pin the identity on the key.

Parameter validation, return value checking, and error checking have been omitted in the code below, but is present in the sample programs. So the sample code is ready for copy/paste. By far, the most uncomfortable languages are C-based: iOS and OpenSSL.

===HTTP pinning===
[http://www.rfc-editor.org/rfc/rfc7469.txt RFC 7469] introduced a new HTTP header that allows SSL servers to declare hashes of their certificates with time scope in which these certificates should not be changed. For example:

<code>
Public-Key-Pins: max-age=2592000;
pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
report-uri="http://example.com/pkp-report"
</code>

Please note that [http://www.rfc-editor.org/rfc/rfc7469.txt RFC 7469] is controversial since it allows overrides for locally installed authorities. That is, it allows an adversary or other party who successfully phishes the user to override a known good pinset with non-authentic or fraudulent information. Second, the reporting mechanism is suppressed from broken pinsets, so a complying user agent will be complicit in the cover up after the fact. That is, the reporting of the broken pinset is called out as '''MUST NOT''' report [https://en.wikipedia.org/w/index.php?title=HTTP_Public_Key_Pinning [1]].

=== Android ===

Pinning in Android is accomplished through a custom <tt>X509TrustManager</tt>. <tt>X509TrustManager</tt> should perform the customary X509 checks in addition to performing the pin.

Download: [[Media:pubkey-pin-android.zip|Android sample program]]

<pre>public final class PubKeyManager implements X509TrustManager
{
private static String PUB_KEY = "30820122300d06092a864886f70d0101" +
"0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85" +
"5a545b1f0cc8afb19e38213bac4d55c3f2f19df6dee82ead67f70a990131b6bc" +
"ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657" +
"2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8" +
"609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50" +
"c6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00" +
"33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38" +
"cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b" +
"e0b7a5bc860966dc84f10d723ce7eed5430203010001";

public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException
{
if (chain == null) {
throw new IllegalArgumentException("checkServerTrusted: X509Certificate array is null");
}

if (!(chain.length > 0)) {
throw new IllegalArgumentException("checkServerTrusted: X509Certificate is empty");
}

if (!(null != authType && authType.equalsIgnoreCase("RSA"))) {
throw new CertificateException("checkServerTrusted: AuthType is not RSA");
}

// Perform customary SSL/TLS checks
try {
TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509");
tmf.init((KeyStore) null);

for (TrustManager trustManager : tmf.getTrustManagers()) {
((X509TrustManager) trustManager).checkServerTrusted(chain, authType);
}
} catch (Exception e) {
throw new CertificateException(e);
}

// Hack ahead: BigInteger and toString(). We know a DER encoded Public Key begins
// with 0x30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0x00 to drop.
RSAPublicKey pubkey = (RSAPublicKey) chain[0].getPublicKey();
String encoded = new BigInteger(1 /* positive */, pubkey.getEncoded()).toString(16);

// Pin it!
final boolean expected = PUB_KEY.equalsIgnoreCase(encoded);
if (!expected) {
throw new CertificateException("checkServerTrusted: Expected public key: "
+ PUB_KEY + ", got public key:" + encoded);
}
}
}
}</pre>

<tt>PubKeyManager</tt> would be used in code similar to below.

<pre>TrustManager tm[] = { new PubKeyManager() };

SSLContext context = SSLContext.getInstance("TLS");
context.init(null, tm, null);

URL url = new URL( "https://www.random.org/integers/?" +
"num=16&min=0&max=255&col=16&base=10&format=plain&rnd=new");

HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());

InputStreamReader instream = new InputStreamReader(connection.getInputStream());
StreamTokenizer tokenizer = new StreamTokenizer(instream);
...</pre>

=== iOS ===

iOS pinning is performed through a <tt>NSURLConnectionDelegate</tt>. The delegate must implement <tt>connection:canAuthenticateAgainstProtectionSpace:</tt> and <tt>connection:didReceiveAuthenticationChallenge:</tt>. Within <tt>connection:didReceiveAuthenticationChallenge:</tt>, the delegate must call <tt>SecTrustEvaluate</tt> to perform customary X509 checks.

Download: [[Media:pubkey-pin-ios.zip|iOS sample program]].

<pre>-(IBAction)fetchButtonTapped:(id)sender
{
NSString* requestString = @"https://www.random.org/integers/?
num=16&min=0&max=255&col=16&base=16&format=plain&rnd=new";
NSURL* requestUrl = [NSURL URLWithString:requestString];

NSURLRequest* request = [NSURLRequest requestWithURL:requestUrl
cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
timeoutInterval:10.0f];

NSURLConnection* connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];
}

-(BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:
(NSURLProtectionSpace*)space
{
return [[space authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust];
}

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:
(NSURLAuthenticationChallenge *)challenge
{
if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust])
{
do
{
SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
if(nil == serverTrust)
break; /* failed */

OSStatus status = SecTrustEvaluate(serverTrust, NULL);
if(!(errSecSuccess == status))
break; /* failed */

SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0);
if(nil == serverCertificate)
break; /* failed */

CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate);
[(id)serverCertificateData autorelease];
if(nil == serverCertificateData)
break; /* failed */

const UInt8* const data = CFDataGetBytePtr(serverCertificateData);
const CFIndex size = CFDataGetLength(serverCertificateData);
NSData* cert1 = [NSData dataWithBytes:data length:(NSUInteger)size];

NSString *file = [[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"];
NSData* cert2 = [NSData dataWithContentsOfFile:file];

if(nil == cert1 || nil == cert2)
break; /* failed */

const BOOL equal = [cert1 isEqualToData:cert2];
if(!equal)
break; /* failed */

// The only good exit point
return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust]
forAuthenticationChallenge: challenge];
} while(0);

// Bad dog
return [[challenge sender] cancelAuthenticationChallenge: challenge];
}</pre>

=== .Net ===

.Net pinning can be achieved by using <tt>ServicePointManager</tt> as shown below.

Download: [[Media:pubkey-pin-dotnet.zip|.Net sample program]].

<pre>// Encoded RSAPublicKey
private static String PUB_KEY = "30818902818100C4A06B7B52F8D17DC1CCB47362" +
"C64AB799AAE19E245A7559E9CEEC7D8AA4DF07CB0B21FDFD763C63A313A668FE9D764E" +
"D913C51A676788DB62AF624F422C2F112C1316922AA5D37823CD9F43D1FC54513D14B2" +
"9E36991F08A042C42EAAEEE5FE8E2CB10167174A359CEBF6FACC2C9CA933AD403137EE" +
"2C3F4CBED9460129C72B0203010001";

public static void Main(string[] args)
{
ServicePointManager.ServerCertificateValidationCallback = PinPublicKey;
WebRequest wr = WebRequest.Create("https://encrypted.google.com/");
wr.GetResponse();
}

public static bool PinPublicKey(object sender, X509Certificate certificate, X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
if (null == certificate)
return false;

String pk = certificate.GetPublicKeyString();
if (pk.Equals(PUB_KEY))
return true;

// Bad dog
return false;
}</pre>

=== OpenSSL ===

Pinning can occur at one of two places with OpenSSL. First is the user supplied <tt>verify_callback</tt>. Second is after the connection is established via <tt>SSL_get_peer_certificate</tt>. Either method will allow you to access the peer's certificate.

Though OpenSSL performs the X509 checks, you must fail the connection and tear down the socket on error. By design, a server that does not supply a certificate will result in <tt>X509_V_OK</tt> with a '''NULL''' certificate. To check the result of the customary verification: (1) you must call <tt>SSL_get_verify_result</tt> and verify the return code is <tt>X509_V_OK</tt>; and (2) you must call <tt>SSL_get_peer_certificate</tt> and verify the certificate is '''non-NULL'''.

Download: [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]].

<pre>int pkp_pin_peer_pubkey(SSL* ssl)
{
if(NULL == ssl) return FALSE;

X509* cert = NULL;
FILE* fp = NULL;

/* Scratch */
int len1 = 0, len2 = 0;
unsigned char *buff1 = NULL, *buff2 = NULL;

/* Result is returned to caller */
int ret = 0, result = FALSE;

do
{
/* http://www.openssl.org/docs/ssl/SSL_get_peer_certificate.html */
cert = SSL_get_peer_certificate(ssl);
if(!(cert != NULL))
break; /* failed */

/* Begin Gyrations to get the subjectPublicKeyInfo */
/* Thanks to Viktor Dukhovni on the OpenSSL mailing list */

/* http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/d61858dae102c6c7 */
len1 = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), NULL);
if(!(len1 > 0))
break; /* failed */

/* scratch */
unsigned char* temp = NULL;

/* http://www.openssl.org/docs/crypto/buffer.html */
buff1 = temp = OPENSSL_malloc(len1);
if(!(buff1 != NULL))
break; /* failed */

/* http://www.openssl.org/docs/crypto/d2i_X509.html */
len2 = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &temp);

/* These checks are verifying we got back the same values as when we sized the buffer. */
/* Its pretty weak since they should always be the same. But it gives us something to test. */
if(!((len1 == len2) && (temp != NULL) && ((temp - buff1) == len1)))
break; /* failed */

/* End Gyrations */

/* See the warning above!!! */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fopen.html */
fp = fopen("random-org.der", "rx");
if(NULL ==fp) {
fp = fopen("random-org.der", "r");

if(!(NULL != fp))
break; /* failed */

/* Seek to eof to determine the file's size */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fseek.html */
ret = fseek(fp, 0, SEEK_END);
if(!(0 == ret))
break; /* failed */

/* Fetch the file's size */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/ftell.html */
long size = ftell(fp);

/* Arbitrary size, but should be relatively small (less than 1K or 2K) */
if(!(size != -1 && size > 0 && size < 2048))
break; /* failed */

/* Rewind to beginning to perform the read */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fseek.html */
ret = fseek(fp, 0, SEEK_SET);
if(!(0 == ret))
break; /* failed */

/* Re-use buff2 and len2 */
buff2 = NULL; len2 = (int)size;

/* http://www.openssl.org/docs/crypto/buffer.html */
buff2 = OPENSSL_malloc(len2);
if(!(buff2 != NULL))
break; /* failed */

/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fread.html */
/* Returns number of elements read, which should be 1 */
ret = (int)fread(buff2, (size_t)len2, 1, fp);
if(!(ret == 1))
break; /* failed */

/* Re-use size. MIN and MAX macro below... */
size = len1 < len2 ? len1 : len2;

/*************************/
/***** PAYDIRT *****/
/*************************/
if(len1 != (int)size || len2 != (int)size || 0 != memcmp(buff1, buff2, (size_t)size))
break; /* failed */

/* The one good exit point */
result = TRUE;

} while(0);

if(fp != NULL)
fclose(fp);

/* http://www.openssl.org/docs/crypto/buffer.html */
if(NULL != buff2)
OPENSSL_free(buff2);

/* http://www.openssl.org/docs/crypto/buffer.html */
if(NULL != buff1)
OPENSSL_free(buff1);

/* http://www.openssl.org/docs/crypto/X509_new.html */
if(NULL != cert)
X509_free(cert);

return result;
}</pre>

== Pinning Alternatives ==

Not all applications use split key cryptography. Fortunately, there are protocols which allow you to set up a secure channel based on knowledge of passwords and pre-shared secrets (rather than putting the secret on the wire in a basic authentication scheme). Two are listed below - SRP and PSK. SRP and PSK have [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 88 cipher suites assigned to them by IANA for TLS], so there's no shortage of choices.

{| align="center"
| [[File:pin-iana-assigned.png|thumb|450px|Figure 3: IANA reserved cipher suites for SRP and PSK]]
|}

=== SRP ===

Secure Remote Password (SRP) is a Password Authenticated Key Exchange (PAKE) by Thomas Wu based upon Diffie-Hellman. The protocol is standardized in [https://tools.ietf.org/rfc/rfc5054.txt RFC 5054] and available in the OpenSSL library (among others). In the SRP scheme, the server uses a verifier which consists of a <tt>{salt, hash(password)}</tt> pair. The user has the password and receives the salt from the server. With lots of hand waving, both parties select per-instance random values (nonces) and execute the protocol using ''g<sup>{(salt + password)|verifier} + nonces</sup>'' rather than traditional Diffie-Hellman using ''g<sup>ab</sup>''.

[[File:homer-p-np.jpg|thumb|right|150px|P=NP!!!]]Diffie-Hellman based schemes are part of a family of problems based on Discrete Logs (DL), which are logarithms over a finite field. DL schemes are appealing because they are known to be hard (unless ''P=NP'', which would cause computational number theorists to have a cow).

=== PSK ===

PSK is Pre-Shared Key and specified in [https://tools.ietf.org/rfc/rfc4279.txt RFC 4279] and [https://tools.ietf.org/rfc/rfc4764.txt RFC 4764]. The shared secret is used as a pre-master secret in TLS-PSK for SSL/TLS; or used to key a block cipher in EAP-PSK. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.

== Miscellaneous ==

This sections covers administrivia and miscellaneous items related to pinning.

=== Ephemeral Keys ===

Ephemeral keys are temporary keys used for one instance of a protocol execution and then thrown away. An ephemeral key has the benefit of providing forward secrecy, meaning a compromise of the site or service's long term (static) signing key does not facilitate decrypting past messages because the key was temporary and discarded (once the session terminated).

Ephemeral keys do not affect pinning because the Ephemeral key is delivered in a separate <tt>ServerKeyExchange</tt> message. In addition, the ephemeral key is a key and not a certificate, so it does not change the construction of the certificate chain. That is, the certificate of interest will still be located at <tt>certificates[0]</tt>.

=== Pinning Gaps ===

There are two gaps when pinning due to reuse of the existing infrastructure and protocols. First, an explicit challenge is '''not''' sent by the program to the peer server based on the server's public information. So the program never knows if the peer can actually decrypt messages. However, the shortcoming is usually academic in practice since an adversary will receive messages it can't decrypt.

Second is revocation. Clients don't usually engage in revocation checking, so it could be possible to use a known bad certificate or key in a pinset. Even if revocation is active, Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) can be defeated in a hostile environment. An application can take steps to remediate, with the primary means being freshness. That is, an application should be updated and distributed immediately when a critical security parameter changes.

=== No Relationship ^@$! ===

If you don't have a pre-existing relationship, all is not lost. First, you can pin a host or server's certificate or public key the first time you encounter it. If the bad guy was not active when you encountered the certificate or public key, he or she will not be successful with future funny business.

Second, bad certificates are being spotted quicker in the field due to projects like [http://www.chromium.org Chromium] and [https://addons.mozilla.org/en-us/firefox/addon/certificate-patrol/ Certificate Patrol], and initiatives like the EFF's [https://www.eff.org/observatory SSL Observatory].

Third, help is on its way, and there are a number of futures that will assist with the endeavors:

* Public Key Pinning (http://www.ietf.org/id/draft-ietf-websec-key-pinning-09.txt) – an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time.
* DNS-based Authentication of Named Entities (DANE) (https://datatracker.ietf.org/doc/rfc6698/) - uses Secure DNS to associate Certificates with Domain Names For S/MIME, SMTP with TLS, DNSSEC and TLSA records.
* Sovereign Keys (http://www.eff.org/sovereign-keys) - operates by providing an optional and secure way of associating domain names with public keys via DNSSEC. PKI (hierarchical) is still used. Semi-centralized with append only logging.
* Convergence (http://convergence.io) – different [geographical] views of a site and its associated data (certificates and public keys). Web of Trust is used. Semi-centralized.

While Sovereign Keys and Convergence still require us to confer trust to outside parties, the parties involved do not serve share holders or covet revenue streams. Their interests are industry transparency and user security.

=== More Information? ===

Pinning is an ''old new thing'' that has been shaken, stirred, and repackaged. While "pinning" and "pinsets" are relatively new terms for old things, Jon Larimer and Kenny Root spent time on the subject at Google I/O 2012 with their talk ''[https://developers.google.com/events/io/sessions/gooio2012/107/ Security and Privacy in Android Apps]''.

=== Format Conversions ===

As a convenience to readers, the following with convert between PEM and DER format using OpenSSL.

<pre># Public key, X509
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl rsa -in rsa-openssl.pem -pubout -outform DER -out rsa-openssl.der</pre>

<pre># Private key, PKCS#8
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl pkcs8 -nocrypt -in rsa-openssl.pem -inform PEM -topk8 -outform DER -out rsa-openssl.der</pre>

== References ==

* OWASP [[Injection_Theory|Injection Theory]]
* OWASP [[Data_Validation|Data Validation]]
* OWASP [[Transport_Layer_Protection_Cheat_Sheet|Transport Layer Protection Cheat Sheet]]
* IETF [http://www.ietf.org/id/draft-ietf-websec-key-pinning-09.txt Public Key Pinning]
* IETF [http://www.ietf.org/rfc/rfc5054.txt RFC 5054 (SRP)]
* IETF [http://www.ietf.org/rfc/rfc4764.txt RFC 4764 (EAP-PSK)]
* IETF [http://www.ietf.org/rfc/rfc1421.txt RFC 1421 (PEM Encoding)]
* IETF [http://www.ietf.org/rfc/rfc5280.txt RFC 5280 (Internet X.509, PKIX)]
* IETF [http://www.ietf.org/rfc/rfc4648.txt RFC 4648 (Base16, Base32, and Base64 Encodings)]
* IETF [http://www.ietf.org/rfc/rfc3279.txt RFC 3279 (PKI, X509 Algorithms and CRL Profiles)]
* IETF [http://www.ietf.org/rfc/rfc4055.txt RFC 4055 (PKI, X509 Additional Algorithms and CRL Profiles)]
* IETF [http://www.ietf.org/rfc/rfc2246.txt RFC 2246 (TLS 1.0)]
* IETF [http://www.ietf.org/rfc/rfc4346.txt RFC 4346 (TLS 1.1)]
* IETF [http://www.ietf.org/rfc/rfc5246.txt RFC 5246 (TLS 1.2)]
* IETF [http://www.ietf.org/rfc/rfc6698.txt RFC 6698, Draft (DANE)]
* EFF [http://www.eff.org/sovereign-keys Sovereign Keys]
* Thoughtcrime Labs [http://convergence.io/ Convergence]
* RSA Laboratories [http://www.rsa.com/rsalabs/node.asp?id=2125 PKCS#1, RSA Encryption Standard]
* RSA Laboratories [http://www.rsa.com/rsalabs/node.asp?id=2128 PKCS#6, Extended-Certificate Syntax Standard]
* ITU [http://www.itu.int/rec/T-REC-X.690-200811-I/en Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)]
* TOR Project [https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion Detecting Certificate Authority Compromises and Web Browser Collusion]
* Code Project [http://www.codeproject.com/Articles/25487/Cryptographic-Interoperability-Keys Cryptographic Interoperability: Keys]
* Google I/O [https://developers.google.com/events/io/sessions/gooio2012/107/ Security and Privacy in Android Apps]
* Trevor Perrin [https://crypto.stanford.edu/RealWorldCrypto/slides/perrin.pdf Transparency, Trust Agility, Pinning (Recent Developments in Server Authentication)]
* Dr. Peter Gutmann's [http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf PKI is Broken]
* Dr. Matthew Green's [http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html The Internet is Broken]
* Dr. Matthew Green's [http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html How do Interception Proxies fail?]
* Presentation: [http://www.slideshare.net/anantshri/ssl-pinning-and-bypasses-android-and-ios SSL Pinning implementation and bypasses for iOS and Android ]

= Authors and Primary Editors =

* Jeffrey Walton - jeffrey, owasp.org
* JohnSteven - john, owasp.org
* Jim Manico - jim, owasp.org
* Kevin Wall - kevin, owasp.org

[[Category:Control]]

SCG CMS Wordpress

2015-01-10T06:44:45Z

Anant Shrivastava: /* Common Misconfigurations */

{{Template:OWASP Secure Configuration Guide}}

== Summary ==
WordPress started in 2003 with a single bit of code to enhance the typography of everyday writing and with fewer users than you can count on your fingers and toes. Since then it has grown to be the largest self-hosted blogging tool in the world, used on millions of sites and seen by tens of millions of people every day.
WordPress is web software you can use to create a beautiful website or blog. We like to say that WordPress is both free and priceless at the same time.

== Common Misconfigurations ==

=== PHP Errors On : Server misconfiguration ===
==== Description ====

Wordpress CMS assumes that the server would have PHP Errors turned off and developers will rely on internal WP_DEBUG feature for Debugging the issues.

==== How to test ====

In order to test for PHP Errors setting, one can make a call to known Full path disclosing files. one such file is wp-includes/rss-functions.php (a list of such files was created for specific versions of wordpress example [https://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/wordpress_2.9.2 2.9.2] and [https://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/wordpress-3.0.4 3.0.4] )
if a call is made to http://%site%/wp-includes/rss-functions.php and a error message is obtained in the lines of

Fatal error: Call to undefined function _deprecated_file() in /home/ABCD_XYZ/public_html/wp-includes/rss-functions.php on line 8

==== Remediation ====

1. Using .htaccess file in webroot place
`php_flag display_errors off`

2. Using php.ini for the server
`display_errors off`

== Additional Hardening ==

=== Misconfiguration 1 ===
==== Description ====

%ProductName% allows unauthorized attacker to list all users of the system ...

// Detailed description of the impact. Is it enabled by default? Vulnerable versions.

==== How to test ====

In order to test for %Misconfiguration_1%, one should ...

// Proof-of-concept here. Please include the screenshots and widely known tools/scanners!

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== Checklist ==

define( 'WP_DEBUG_LOG', true ); // log to wp-content/debug.log

''' To be filled in in accordance to the template, some useful links: '''

http://codex.wordpress.org/Hardening_WordPress (consider writing only real security risks with good examples)

https://github.com/anantshri/wp-security (extract samples from here. keep them as code sections either for a plugin or for a theme functions.php, .htaccess or nginx config file)

SCG CMS Wordpress

2015-01-10T06:39:35Z

Anant Shrivastava: /* Server misconfiguration : PHP Errors On */

{{Template:OWASP Secure Configuration Guide}}

== Summary ==
WordPress started in 2003 with a single bit of code to enhance the typography of everyday writing and with fewer users than you can count on your fingers and toes. Since then it has grown to be the largest self-hosted blogging tool in the world, used on millions of sites and seen by tens of millions of people every day.
WordPress is web software you can use to create a beautiful website or blog. We like to say that WordPress is both free and priceless at the same time.

== Common Misconfigurations ==

=== PHP Errors On : Server misconfiguration ===
==== Description ====

Wordpress CMS assumes that the server would have PHP Errors turned off and developers will rely on internal WP_DEBUG feature for Debugging the issues.

==== How to test ====

In order to test for %Misconfiguration_1%, one should make a call to known Full path disclosing files. one such file is wp-includes/rss-functions.php
if a call is made to http://%site%/wp-includes/rss-functions.php and a error message is obtained in the lines of

Fatal error: Call to undefined function _deprecated_file() in /home/ABCD_XYZ/public_html/wp-includes/rss-functions.php on line 8

==== Remediation ====

1. Using .htaccess file in webroot place
`php_flag display_errors off`

2. Using php.ini for the server
`display_errors off`

== Additional Hardening ==

=== Misconfiguration 1 ===
==== Description ====

%ProductName% allows unauthorized attacker to list all users of the system ...

// Detailed description of the impact. Is it enabled by default? Vulnerable versions.

==== How to test ====

In order to test for %Misconfiguration_1%, one should ...

// Proof-of-concept here. Please include the screenshots and widely known tools/scanners!

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== Checklist ==

define( 'WP_DEBUG_LOG', true ); // log to wp-content/debug.log

''' To be filled in in accordance to the template, some useful links: '''

http://codex.wordpress.org/Hardening_WordPress (consider writing only real security risks with good examples)

https://github.com/anantshri/wp-security (extract samples from here. keep them as code sections either for a plugin or for a theme functions.php, .htaccess or nginx config file)

SCG CMS Wordpress

2015-01-10T06:37:21Z

Anant Shrivastava:

{{Template:OWASP Secure Configuration Guide}}

== Summary ==
WordPress started in 2003 with a single bit of code to enhance the typography of everyday writing and with fewer users than you can count on your fingers and toes. Since then it has grown to be the largest self-hosted blogging tool in the world, used on millions of sites and seen by tens of millions of people every day.
WordPress is web software you can use to create a beautiful website or blog. We like to say that WordPress is both free and priceless at the same time.

== Common Misconfigurations ==

=== Server misconfiguration : PHP Errors On ===
==== Description ====

Wordpress CMS assumes that the server would have PHP Errors turned off and developers will rely on internal WP_DEBUG feature for Debugging the issues.

==== How to test ====

In order to test for %Misconfiguration_1%, one should make a call to known Full path disclosing files. one such file is wp-includes/rss-functions.php
if a call is made to http://%site%/wp-includes/rss-functions.php and a error message is obtained in the lines of

Fatal error: Call to undefined function _deprecated_file() in /home/ABCD_XYZ/public_html/wp-includes/rss-functions.php on line 8

==== Remediation ====

1. Using .htaccess file in webroot place
`php_flag display_errors off`

2. Using php.ini for the server
`display_errors off`

== Additional Hardening ==

=== Misconfiguration 1 ===
==== Description ====

%ProductName% allows unauthorized attacker to list all users of the system ...

// Detailed description of the impact. Is it enabled by default? Vulnerable versions.

==== How to test ====

In order to test for %Misconfiguration_1%, one should ...

// Proof-of-concept here. Please include the screenshots and widely known tools/scanners!

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== Checklist ==

define( 'WP_DEBUG_LOG', true ); // log to wp-content/debug.log

''' To be filled in in accordance to the template, some useful links: '''

http://codex.wordpress.org/Hardening_WordPress (consider writing only real security risks with good examples)

https://github.com/anantshri/wp-security (extract samples from here. keep them as code sections either for a plugin or for a theme functions.php, .htaccess or nginx config file)

SCG CMS Wordpress

2015-01-10T06:34:48Z

Anant Shrivastava:

{{Template:OWASP Secure Configuration Guide}}

== Summary ==
WordPress started in 2003 with a single bit of code to enhance the typography of everyday writing and with fewer users than you can count on your fingers and toes. Since then it has grown to be the largest self-hosted blogging tool in the world, used on millions of sites and seen by tens of millions of people every day.
WordPress is web software you can use to create a beautiful website or blog. We like to say that WordPress is both free and priceless at the same time.

== Common Misconfigurations ==

=== Server misconfigurations ===
==== Description ====

Wordpress CMS assumes that the server would have PHP Errors turned off and developers will rely on internal WP_DEBUG feature for Debugging the issues.

==== How to test ====

In order to test for %Misconfiguration_1%, one should make a call to known Full path disclosing files. one such file is wp-includes/rss-functions.php
if a call is made to http://%site%/wp-includes/rss-functions.php and a error message is obtained in the lines of

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== Additional Hardening ==

=== Misconfiguration 1 ===
==== Description ====

%ProductName% allows unauthorized attacker to list all users of the system ...

// Detailed description of the impact. Is it enabled by default? Vulnerable versions.

==== How to test ====

In order to test for %Misconfiguration_1%, one should ...

// Proof-of-concept here. Please include the screenshots and widely known tools/scanners!

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== Checklist ==

define( 'WP_DEBUG_LOG', true ); // log to wp-content/debug.log

''' To be filled in in accordance to the template, some useful links: '''

http://codex.wordpress.org/Hardening_WordPress (consider writing only real security risks with good examples)

https://github.com/anantshri/wp-security (extract samples from here. keep them as code sections either for a plugin or for a theme functions.php, .htaccess or nginx config file)

SCG CMS Wordpress

2015-01-10T06:23:58Z

Anant Shrivastava:

SCG WS Apache

2015-01-10T06:22:11Z

Anant Shrivastava:

{{Template:OWASP Secure Configuration Guide}}

== Summary ==
The Apache HTTP Server Project is a collaborative software development effort aimed at creating a robust, commercial-grade, featureful, and freely-available source code implementation of an HTTP (Web) server. The project is jointly managed by a group of volunteers located around the world, using the Internet and the Web to communicate, plan, and develop the server and its related documentation. This project is part of the Apache Software Foundation. In addition, hundreds of users have contributed ideas, code, and documentation to the project. This file is intended to briefly describe the history of the Apache HTTP Server and recognize the many contributors.

== Common Misconfigurations ==

=== Misconfiguration 1 ===
==== Description ====

%ProductName% allows unauthorized attacker to list all users of the system ...

// Detailed description of the impact. Is it enabled by default? Vulnerable versions.

==== How to test ====

In order to test for %Misconfiguration_1%, one should ...

// Proof-of-concept here. Please include the screenshots and widely known tools/scanners!

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== Misconfigurations ==

'''Please also mention /server-status ! '''

1. Version details disclosed in headers
disable apache tokens

2. Proper SSL cipher selection
Cipher orders
Disable specific ciphers

3. Guidelines on how to store ssl private keys on server
stuff like not to store private keys on /var/www/

4. Detailing about various authentication types

basic, digest, X509, LDAP or others.

Detailing about authoentication types and which one to use in which situation.

== References ==

https://httpd.apache.org/docs/current/misc/security_tips.html

https://wiki.debian.org/Apache/Hardening

SCG D BIGIP

2015-01-10T06:19:48Z

Anant Shrivastava: added burp suite plugin by secureideas

{{Template:OWASP Secure Configuration Guide}}

== Summary ==
The BIG-IP family of products offers the application intelligence network managers need to ensure applications are fast, secure and available. All BIG-IP products share a common underlying architecture, F5's Traffic Management Operating System (TMOS), which provides unified intelligence, flexibility and programmability. Together, BIG-IP's powerful platforms, advanced modules, and centralized management system make up the most comprehensive set of application delivery tools in the industry.

BIG-IP devices work on a modular system, which enables to add new functions as necessary to quickly adapt to changing application and business needs. The following modules are currently available for the BIG-IP system:
* Application Acceleration Manager (AAM)
* Advanced Firewall Manager (AFM)
* Access Policy Manager (APM)
* Application Security Manger (ASM)
* Global Traffic Manager (GTM)
* Link Controller (LC)
* Local Traffic Manager (LTM)
* Protocol Security Module (PSM)

== Common Misconfigurations ==
=== BIG-IP persistence cookie information leakage ===
==== Description ====

An attacker can receive sensitive information about internal network via BIG-IP LTM persistence cookie.

To implement persistence sessions BIG-IP system inserts a cookie into the HTTP response, which well-behaved clients include in subsequent HTTP requests for the host name until the cookie expires. The cookie, by default, is named BIGipServer<pool_name>. The cookie is set to expire based on the time-out configured in the persistence profile. The cookie value contains the encoded IP address and port of the destination server [https://support.f5.com/kb/en-us/solutions/public/6000/900/sol6917.html] in the following format:
BIGipServer<pool name> = <coded server IP>.<coded server port>.0000

After decoding [https://blog.whitehatsec.com/f5-networks-big-ip-cookie-decoded/] value of the BIG-IP persistence cookie an attacker receives an internal IP address and port number of backend servers. In some cases an attacker can also retreive sensitive informaion via <pool_name> suffix of the cookie name. For example, if an administrator give meaningful name to server pool (e.g. Sharepoint, 10.1.1.0, AD_prod) an attacker will get some additional information about network. Besides, an attacker detects that BIG-IP system is used in network infrustructure.

==== How to test ====

# Run intercepting proxy or traffic intercepting browser plug-in, trap all responses where a cookie is set by the web application.
# If possible, log in to web application and inspect cookies.
# Find a cookie with name beginning with BIGipServer string or with value which has format as <coded server IP>.<coded server port>.0000 (e.g. 1677787402.36895.0000).
# Try to decode this value using available tools (e.g. [https://blog.whitehatsec.com/wp-content/uploads/F5BigIPCookieDecoder.html WhiteHat Security Big IP Cookie Decoder] [http://blog.secureideas.com/2013/08/burp-extension-for-f5-cookie-detection.html BurpSuitePro Plugin for Big IP Cookie Decoding]).
# Inspect suffix of BIGipServer cookie name and verify that it does not contain any sensitive information about network infrustructure.

This example shows a GET request to BIG-IP with LTM module and a response containing BIGipServer cookie.

==== Example 1 ====
GET /app HTTP/1.1
Host: x.x.x.x

'''Result Expected:'''

HTTP/1.1 200 OK
Set-Cookie: BIGipServerOldOWASSL=110536896.20480.0000; path=/

Here we can see that pool has the meaningful name OldOWASSL and get the following destination server address:
* IP Address = 192.168.150.6
* Port = 80

==== Remediation ====

Configuring secure cookie persistence by using the Configuration utility

* Log in to the Configuration utility.
* Navigate Local Traffic > Profiles > Persistence.
* Create new secure persistence profile with persistence type equals to "Cookie".
* Check the custom box for "Cookie Name" and enter a cookie name that does not conflict with any existing cookie names.
* Check the custom box for "Cookie Encryption Use Policy" and choose a "required" option. Enter a passphrase in "Encryption Passphrase" field.
* Click on "Finished" button.
* Assign created persistence profile to virtual server.

Configuring cookie persistence by using the TMSH

* Log in to TMSH.
* Run the following commands:
: create ltm persistense cookie <profile_name>
: modify ltm persistense cookie <profile_name> cookie-name <secure_cookie_name>
: modify ltm persistense cookie <profile_name> cookie-encryption required
: modify ltm persistense cookie <profile_name> cookie-encryption-passphrase <secure_passphrase>
: modify ltm virtual <virtual_server> persist replace-all-with { <profile_name> }

=== BIG-IP HTTP Server header information leakage ===
==== Description ====

An attacker can receive information that a web application is protected by BIG-IP system via HTTP Server header.

BIG-IP system uses different HTTP Profiles for managing HTTP traffic. In particular, BIG-IP system uses HTTP Profile that specifies the string used as the server name in traffic generated by LTM. The default values are equal to "BigIP" or "BIG-IP" and depended on BIG-IP system version. An attacker can detect that BIG-IP is used in network infrustructure and then know role, type, and version of the BIG-IP system.

==== How to test ====

# Run intercepting proxy or traffic intercepting browser plug-in, trap all responses from a web application.
# If possible, log in to web application and inspect HTTP responses.
# If Server header contains "BIG-IP" or "BigIP" value then BIG-IP is used.

This example shows a GET request to BIG-IP and a response containing Server header inserted by BIG-IP LTM.

==== Example 2 ====
GET / HTTP/1.1
Host: x.x.x.x

'''Result Expected:'''

HTTP/1.0 302 Found
Server: BigIP
Connection: Close
Content-Length: 0
Location: /my.policy
Set-Cookie: LastMRH_Session=05da1fc5;path=/;secure
Set-Cookie: MRHSession=03e47713f1a8ef1aaa71cd9d05da1fc5;path=/;secure
Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

==== Remediation ====

It is recommended to remove Server header from HTTP responses.

Removing Server header via Configuration Utility.

* Log in to the Configuration utility.
* Navigate Local Traffic > Profiles > Services > HTTP.
* Create new secure HTTP profile.
* Enter empry string in "Server Agent Name" field.
* Click on "Finished" button.
* Assign created HTTP profile to virtual server.

Removing Server header via TMSH

* Log in to TMSH.
* Run the following commands:
: create ltm profile http <profile_name>
: modify ltm profile http <profile_name> server-agent-name none

=== Administrative access to BIG-IP system via Internet ===
==== Description ====

An attacker can access to BIG-IP system via Internet.

The BIG-IP system uses the following two network connection entry points [https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7312.html]:

* TMM switch interfaces
* Management interface (MGMT)

Either the TMM switch interfaces or the MGMT interface can provide administrative access to the BIG-IP system. The TMM switch interfaces are the interfaces that the BIG-IP system uses to send and receive load-balanced traffic. The MGMT interface is the interface to perform system management functions. The MGMT interface is intended for administrative traffic and cannot be used for load-balanced traffic. It is recommended to connect MGMT interface to a secure, management-only network, such as one that uses an RFC1918 private IP address space. Otherwise an attacker can identify BIG-IP systems in your network and then [https://www.blackhat.com/html/webcast/07182013-hacking-appliances-ironic-exploits-in-security-products.html try to attack them] via management plane.

==== How to test ====

# Try to use the following googledorks:

* inurl:"tmui/login.jsp"
* intitle:"BIG-IP" inurl:"tmui"

# Try to use the following queries in [http://un1c0rn.net/ Un1c0rn]

* BIG-IP
* bigip
* BigIP

# Try to use the following queries in [http://www.shodanhq.com Shodan]

* F5-Login-Page
* WWW-Authenticate: Basic realm=BIG-IP

==== Remediation ====

# Connect MGMT interface to management network.
# Set ‘allow none’ on all Self IPs and only administer the BIG-IP using the Management Port. Setting ‘allow none’ on each Self IP will block all access to administrative IP addresses except for the Management Port. Access to individual ports can be selectively enabled, but this is not recommended in a secure environment.

== References ==

* [https://f5.com/products/big-ip F5 Networks Official Site]
* [https://www.f5.com/pdf/products/big-ip-modules-ds.pdf BIG-IP Modules Datasheet]

SCG WS nginx

2014-12-31T12:57:05Z

Anant Shrivastava:

{{Template:OWASP Secure Configuration Guide}}
'''NEEDS TO BE REVIEWED, SEE REFERENCES BELOW FOR A GOOD MATERIAL!'''

== Summary ==
A detailed description of the product (can be taken from the official website)

== Common Misconfigurations ==

=== Misconfiguration 1 ===
==== Description ====

%ProductName% allows unauthorized attacker to list all users of the system ...

// Detailed description of the impact. Is it enabled by default? Vulnerable versions.

==== How to test ====

In order to test for %Misconfiguration_1%, one should ...

// Proof-of-concept here. Please include the screenshots and widely known tools/scanners!

==== Remediation ====

Initial/common value of parameter "listUsers" from config.xml is set to "true".

To assess the vulnerability it is enough to change the value to false:

<pre>
<security>
<listUsers>false</listUsers>
</security>
</pre>

== References ==

https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/

http://ngx.readthedocs.org/en/latest/topics/tutorials/config_pitfalls.html

Secure Configuration Guide

2014-12-27T16:05:36Z

Anant Shrivastava: /* 6. Crypto misconfiguration */

Welcome on the page of Secure Configuration Guide!

Project description is available here: https://www.owasp.org/index.php/OWASP_Secure_Configuration_Guide

When editing the page, please follow the page structure, described in [[Template:OWASP Secure Configuration Guide]]

= Table of Contents =

== 1. Introduction ==

'''1.1. The OWASP Secure Configuration Guide'''

'''1.2. Misconfiguration. Defender's point'''

'''1.3. Misconfiguration. Attacker's point'''

== 2. Web servers misconfiguration ==

'''[[SCG_WS_Apache|2.1. Apache]]'''

'''[[SCG_WS_IIS|2.2. IIS]]'''

'''[[SCG_WS_nginx|2.3. nginx]]'''

'''[[SCG_WS_GWS|2.4. GWS]]'''

'''[[SCG_WS_IBM|2.5. IBM HTTP Server]]'''

== 3. Application servers misconfiguration ==

'''[[SCG_AS_Tomcat|3.1. Apache Tomcat]]'''

'''[[SCG_AS_Borland|3.2. Borland Enterprise Server]]'''

'''[[SCG_AS_ColdFusion|3.3. ColdFusion]]'''

'''[[SCG_AS_WebSphere|3.4. IBM WebSphere Application Server]]'''

'''[[SCG_AS_JBoss|3.5. JBoss Enterprise Application Platform]]'''

'''[[SCG_AS_Jetty|3.6. Jetty]]'''

'''[[SCG_AS_NetWeaver|3.7. SAP NetWeaver Application Server]]'''

'''[[SCG_AS_Oracle|3.8. Oracle Application Server]]'''

'''[[SCG_AS_WebLogic|3.9. Oracle WebLogic Server]]'''

'''[[SCG_AS_GlassFish|3.10. Oracle GlassFish Server]]'''

== 4. Web frameworks misconfiguration ==

'''[[SCG_WF_Struts|4.1. Apache Struts]]'''

'''[[SCG_WF_ASPNET|4.2. ASP.NET]]'''

'''[[SCG_WF_CakePHP|4.3. CakePHP]]'''

'''[[SCG_WF_CodeIgniter|4.4. CodeIgniter]]'''

'''[[SCG_WF_Django|4.5. Django]]'''

'''[[SCG_WF_Lithium|4.6. Lithium]]'''

'''[[SCG_WF_Rails|4.7. Ruby on Rails]]'''

'''[[SCG_WF_Spring|4.8. Spring]]'''

'''[[SCG_WF_Symfony|4.9. Symfony]]'''

'''[[SCG_WF_Zend|4.10. Zend]]'''

== 5. CMS misconfiguration ==

'''[[SCG_CMS_Bitrix|5.1. Bitrix]]'''

'''[[SCG_CMS_Drupal|5.2. Drupal]]'''

'''[[SCG_CMS_Joomla|5.3. Joomla]]'''

'''[[SCG_CMS_Magento|5.4. Magento]]'''

'''[[SCG_CMS_OpenCart|5.5. OpenCart]]'''

'''[[SCG_CMS_phpBB|5.6. phpBB]]'''

'''[[SCG_CMS_Shopify|5.7. Shopify]]'''

'''[[SCG_CMS_TYPO3|5.8. TYPO3]]'''

'''[[SCG_CMS_vBulletin|5.9. vBulletin]]'''

'''[[SCG_CMS_Wordpress|5.10. Wordpress]]'''

== 6. Crypto misconfiguration ==

'''6.1 SSL / TLS configuration'''

'''6.2 Cryptographic Password storage policy'''

'''6.3 to be complemented later'''

== 7. Services ==

'''7.1 to be complemented later'''

== 8. Devices ==

'''[[SCG_D_BIGIP|8.1. BIG-IP]]'''

'''8.2. Routers'''

'''8.3. Firewalls '''

'''8.4. to be complemented later'''

[[Category:OWASP Project]] [[Category:OWASP_Breakers]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

SCG CMS Wordpress

2014-12-23T06:05:50Z

Anant Shrivastava:

{{Template:OWASP Secure Configuration Guide}}
''' To be filled in in accordance to the template, some useful links: '''

http://codex.wordpress.org/Hardening_WordPress (consider writing only real security risks with good examples)

https://github.com/anantshri/wp-security (extract samples from here. keep them as code sections either for a plugin or for a theme functions.php, .htaccess or nginx config file)

SCG WS Apache

2014-12-23T06:03:10Z

Anant Shrivastava: basic template of stuff that will be added and expanded.

{{Template:OWASP Secure Configuration Guide}}

Details will be added in proper format.
right now cataloguing links which can be used as references.

== Misconfigurations ==

1. Version details disclosed in headers
disable apache tokens

2. Proper SSL cipher selection
Cipher orders
Disable specific ciphers

3. Guidelines on how to store ssl private keys on server
stuff like not to store private keys on /var/www/

4. Detailing about various authentication types

basic, digest, X509, LDAP or others.

Detailing about authoentication types and which one to use in which situation.

== References ==

https://httpd.apache.org/docs/current/misc/security_tips.html

https://wiki.debian.org/Apache/Hardening

Talk:Clickjacking Defense Cheat Sheet

2014-06-22T06:48:07Z

Anant Shrivastava:

== Javascript based solution : are they good now ==

Considering the fact that people can disable javascript in framed page should we be recommending Javascript based solution for Clickjacking or we should all bet for just XFO.

I can understand this (javascript based solution) could be a good option when the site can't function without javascript enabled however any site which has script enabled just for this feature can again be victimized using iframe property like sandbox="allow-forms allow-scripts"

--[[User:Anant Shrivastava|Anant Shrivastava]] ([[User talk:Anant Shrivastava|talk]]) 01:48, 22 June 2014 (CDT)

Talk:Clickjacking Defense Cheat Sheet

2014-06-22T06:47:49Z

Anant Shrivastava: Created page with " == Javascript based soultion : are they good now == Considering the fact that people can disable javascript in framed page should we be recommending Javascript based solutio..."

== Javascript based soultion : are they good now ==

Considering the fact that people can disable javascript in framed page should we be recommending Javascript based solution for Clickjacking or we should all bet for just XFO.

I can understand this (javascript based solution) could be a good option when the site can't function without javascript enabled however any site which has script enabled just for this feature can again be victimized using iframe property like sandbox="allow-forms allow-scripts"

--[[User:Anant Shrivastava|Anant Shrivastava]] ([[User talk:Anant Shrivastava|talk]]) 01:47, 22 June 2014 (CDT)

OWASP Installer Guidelines

2012-07-17T11:39:50Z

Anant Shrivastava: added suggestion on android location.

= OWASP Installer Guidelines =

This is a ''proposed'' set of guidelines for the installers of OWASP projects.

Please update this page with any suggestions for improvements you may have.

== Windows ==

OWASP projects should be installed into a project specific directory underneath:
<pre>
C:\Program Files (x86)\OWASP\
</pre>
or for older Windows versions:
<pre>
C:\Program Files\OWASP\
</pre>
On uninstallation the 'OWASP' directory should be deleted if there are no other files or directories left underneath it.

Installers should add programs to the 'All programs'/'Start Menu' list in a directory underneath an 'OWASP' directory.

If necessary the 'OWASP' directory should be created and a link to the OWASP home page added.

On uninstallation the OWASP 'Start Menu' directory should be deleted if there are no other files or directories left underneath it.

Project known to conform to these recommendations:
* [[OWASP Zed Attack Proxy Project]]

== Linux ==

OWASP projects should be installed into a project specific directory underneath:
<pre>
/opt/owasp/
</pre>
On uninstallation the 'owasp' directory should be deleted if there are no other files or directories left underneath it.

== Mac OS ==
TBA - please add suggestions

== iPhone ==
TBA - please add suggestions

== Android ==
package name :
<pre>
com.owasp.<name>
</pre>
Where <name> will be package name.
also on sdcard
<pre>
/sdcard/owasp/<name>
</pre>

Talk:OWASP Installer Guidelines

2012-07-17T11:38:01Z

Anant Shrivastava: added suggestion on android location.

== Android ==
for android all applications installed will go to /data/data/ so we can keep the applications in one cluster by using a common package name.

com.owasp.<name>

where <name> would be app name.
so this will have following filesystem layout.

/data/data/com.owasp.<name>

also if we want to keep content on sdcard then layout should be

/sdcard/owasp/<name>

--[[User:Anant Shrivastava|Anant Shrivastava]] 11:38, 17 July 2012 (UTC)

OWASP Mobile Security Project - Android/References

2011-10-17T00:07:56Z

Anant Shrivastava: added whitepaper on security issues in android custom roms

__NOTOC__
Here are a number of references related to [[Android]] Security

===Official documentation===
* Main websites: http://www.android.com , http://code.google.com/android , http://developer.android.com/
* [http://developer.android.com/guide/appendix/faq/security.html Android Security FAQ]
* [http://developer.android.com/guide/index.html Android Developer's Guide]
* [http://developer.android.com/guide/topics/security/security.html Security and Permissions]
* [http://developer.android.com/guide/topics/testing/testing_android.html Testing and Instrumentation]
* [http://developer.android.com/guide/topics/manifest/manifest-intro.html AndroidManifest.xml File] and [http://developer.android.com/reference/android/Manifest.permission.html Permissions list]
* [http://developer.android.com/guide/tutorials/notepad/index.html Notepad Tutorial] - Recomended starting point to understand Android

===Android Security Team===
* Report security vulnerabilities in Android: security@android.com (here is the [http://developer.android.com/security_at_android_dot_com.txt PGP Public] key)
* [http://groups.google.com/group/android-security-discuss Android Security Mailing list]
* [http://groups.google.com/group/android-security-discuss/browse_thread/thread/a2ab575dd0e5c27d Introduction from Android Security Team]

===Published Research and presentations ===
* '''Presentations'''
** [http://www.smartphonesdumbapps.com/ Smart Phones Dumb Apps] Presentation about how to unpack, disassemble/decompile, and analyze Android applications. Also has a link to some Perl code to automate parts of this process.
** [http://www.coverity.com/library/pdf/coverity-scan-2010-open-source-integrity-report.pdf Coverity SCAN 2010 Open Source Integrity Report] which contains information about 88 Kernel bugs in Android
** [https://www.isecpartners.com/files/iSEC_Android_Exploratory_Blackhat_2009.pdf Exploratory Android Security (iSEC Partners, Blackhat_2009)
** [https://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf Developing Secure Mobile Applications for Android]
** [http://www.blackhat.com/html/bh-ad-10/bh-ad-10-briefings.html Building Android Sandcastles in Android's Sandbox] at BlackHat Abu Dhabi (Nov 10 - 11 2010) (NOT PUBLISHED YET)
** [http://anantshri.info/articles/android_cust_rom_security.html Security Issues in android Custom ROMs] at c0c0n Kochi India (Oct 8 2011)
* '''Books'''
** [http://www.amazon.com/gp/product/0071633561/ Mobile Application Security]
*'''Blog posts'''
** [http://jack-mannino.blogspot.com/2010/09/reversing-android-apps-101.html Reversing Android Apps 101] and [http://jack-mannino.blogspot.com/2010/10/storing-data-on-mobile-devices-wrong.html Storing Data On Mobile Devices The Wrong Way] - Jack Mannino
** [http://carnal0wnage.blogspot.com/2010/04/android-emulators-with-android-market.html Android Emulators with Android Market] and [http://techdroid.kbeanie.com/2009/11/android-market-on-emulator.html Android Market on Emulator]

===Tools===
* '''Android Development'''
** [http://developer.android.com/sdk/index.html Android SDK]
* '''Android Security Review'''
** [http://www.smartphonesdumbapps.com/ Smart Phones Dumb Apps] Presentation about how to unpack, disassemble/decompile, and analyze Android applications. Also has a link to some Perl code to automate parts of this process.
** [http://code.google.com/p/dex2jar/ Dex2Jar] :'' "...Android mobile device runs applications which have been converted into a compact Dalvik Executable (.dex) format. Dex2Jar converts .dex files to Java .class files..." ''
** [http://code.google.com/p/android-apktool/ ApkTool] :'' "...It is a tool for reengineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step. Also it makes working with app easier because of project-like files structure and automation of some repetitive tasks like building apk, etc..." ''
** [http://java.decompiler.free.fr JD-GUI and JD-Eclipse], [http://www.neshkov.com/ DJ] and [http://www.varaneckas.com/jad JAD (mirror)] : Java Decompilers
** [http://code.google.com/p/android4me/downloads/list AXMLPrinter2] - Utility that decodes the Android XML files, such as Manifest.xml ().
** [[OWASP O2 Platform]] can be used to review the Android Java source code (create object model of compiled java code, search source-code files, model config files)
** Commercial tools (like Fortify, IBM AppScan Source) can parse Java files (the question is "Do they have Android Specific rules")
** iSec Partners have a number of Android related tools at https://www.isecpartners.com/mobile_application_tools.html

===Media Coverage===
* Storing data unencrypted: "Firm finds security holes in mobile bank apps": http://news.cnet.com/8301-27080_3-20021874-245.html
* Paypal has issue with lack of SSL in iPhope app: http://online.wsj.com/article/SB10001424052748703506904575592782874885808.html (more to iPhone page)

Talk:Testing for Web Application Fingerprint (OWASP-IG-004)

2011-10-12T11:19:25Z

Anant Shrivastava:

Even though this section is titled "web application fingerprint", the content focuses only of fingerprinting "web servers". I think either the title should be changed, or the content should be updated with similar techniques to fingerprint web applications.

[[User:Marco|Marco]] 18:57, 17 August 2008 (EDT)

:I agree. Though I'm curious what how you'd describe finger printing a "web application" ..... do you mean the technologies used? Do you mean building a tree or flow diagram of the site/app?<br>
:[[User:Rick.mitchell|Rick.mitchell]] 09:52, 3 September 2008 (EDT)

hi All I have recently wrote a paper on this topic hope that could help in expanding the section posting the link here before actually linking it in external links section [http://anantshri.info/articles/web_app_finger_printing.html <br>]

[http://anantshri.info/articles/web_app_finger_printing.html http://anantshri.info/articles/web_app_finger_printing.html]<br>

--[[User:Anant Shrivastava|Anant Shrivastava]] 08:01, 17 July 2011 (EDT)

after 3 months on non objection i have added the whitepaper in the related link sections under whitepaper category.

--[[User:Anant Shrivastava|Anant Shrivastava]] 07:19, 12 October 2011 (EDT)

Testing for Web Application Fingerprint (OWASP-IG-004)

2011-10-12T11:17:45Z

Anant Shrivastava: added whitepaper on web application fingerprinting. which should actually be the content of this page instead of http finger printing.

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

== Description of the Issue ==
There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Black Box testing and example ==
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html
</pre>

From the ''Server'' field, we understand that the server is likely Apache, version 1.3.3, running on Linux operating system.

Four examples of the HTTP response headers are shown below.

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>

From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is not so good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1 Forbidden
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
</pre>

In this case, the server field of that response is obfuscated: we cannot know what type of web server is running.

=== Protocol behaviour ===
More refined techniques take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

'''HTTP header field ordering'''

The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise, and IIS.

'''Malformed requests test'''

Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
Consider the following HTTP responses.

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. Similar observations can be done we create requests with a non-existent protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

=== Automated Testing ===
The tests to carry out in order to accurately fingerprint a web server can be many. Luckily, there are tools that automate these tests. "''httprint''" is one of such tools. httprint has a signature dictionary that allows one to recognize the type and the version of the web server in use.<br>
An example of running httprint is shown below:<br><br>

[[Image:httprint.jpg]]

=== OnLine Testing ===
An example of on line tool that often delivers a lot of information on target Web Server, is Netcraft. With this tool we can retrieve information about operating system, web server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S.<br>
An example is shown below:
<br><br>

[[Image:netcraft2.png]]

== References ==
'''Whitepapers'''<br>
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://net-square.com/httprint/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html
'''Tools'''<br>
* httprint - http://net-square.com/httprint/index.shtml
* httprecon - http://www.computec.ch/projekte/httprecon/
* Netcraft - http://www.netcraft.com

Talk:Enumerate Applications on Webserver (OTG-INFO-004)

2011-07-19T06:18:15Z

Anant Shrivastava:

__TOC__

== NMAP Changes? ==

Hi, what do you think to change the nmap command, and the nmap site?

Latest nmap change some parameters like -P0 to -PN. -P0 is obsolete.

Sample command should be now: nmap –PN –sT –sV –p1-65535 192.168.1.100

If fact, nmap has the abilily to scan port number 0, so we can do better with:

nmap –PN –sT –sV –p0-65535 192.168.1.100

And the nmap site is nmap.org now. But www.insecure.org is still there.

cheers
--[[User:Unusuario|Unusuario]] 15:36, 2 April 2008 (EDT)

== v3 Review Comments ==

Similar to the previous section this section seems more like Service discovery than application discovery. We're still learning things about the server and not as much about the application(s) we're assessing. IMHO.<br>
May this section should be renamed to something like "Discovery of web server services and web applications on a host".
[[User:Rick.mitchell|Rick.mitchell]] 09:55, 3 September 2008 (EDT)

== Merge with (OWASP-IG-004) ==
This article should be merged with 4.2.4 Testing for Web Application Fingerprint (OWASP-IG-004) and renamed to web server finger printing as both these pages talk about server level finger printing.

also if i may put forward I have tried to cover some steps of web application finger printing here : http://anantshri.info/articles/web_app_finger_printing.html
I hope this could be of some use in the correct page of web application finger printing.

--[[User:Anant Shrivastava|Anant Shrivastava]] 06:05, 18 July 2011 (EDT)

Talk:Enumerate Applications on Webserver (OTG-INFO-004)

2011-07-18T10:05:35Z

Anant Shrivastava:

__TOC__

== NMAP Changes? ==

Hi, what do you think to change the nmap command, and the nmap site?

Latest nmap change some parameters like -P0 to -PN. -P0 is obsolete.

Sample command should be now: nmap –PN –sT –sV –p1-65535 192.168.1.100

If fact, nmap has the abilily to scan port number 0, so we can do better with:

nmap –PN –sT –sV –p0-65535 192.168.1.100

And the nmap site is nmap.org now. But www.insecure.org is still there.

cheers
--[[User:Unusuario|Unusuario]] 15:36, 2 April 2008 (EDT)

== v3 Review Comments ==

Similar to the previous section this section seems more like Service discovery than application discovery. We're still learning things about the server and not as much about the application(s) we're assessing. IMHO.<br>
May this section should be renamed to something like "Discovery of web server services and web applications on a host".
[[User:Rick.mitchell|Rick.mitchell]] 09:55, 3 September 2008 (EDT)

== Merge with (OWASP-IG-004) ==
This article should be merged with 4.2.4 Testing for Web Application Fingerprint (OWASP-IG-004) and renamed to web server finger printing as both these pages talk about server level finger printing.

also if i pay put forward I have tried to cover some steps of web application finger printing here : http://anantshri.info/articles/web_app_finger_printing.html
I hope this could be of some use in the correct page of web application finger printing.
--[[User:Anant Shrivastava|Anant Shrivastava]] 06:05, 18 July 2011 (EDT)

Talk:Enumerate Applications on Webserver (OTG-INFO-004)

2011-07-18T10:04:44Z

Anant Shrivastava: merger request and content suggestion.

__TOC__

== NMAP Changes? ==

Hi, what do you think to change the nmap command, and the nmap site?

Latest nmap change some parameters like -P0 to -PN. -P0 is obsolete.

Sample command should be now: nmap –PN –sT –sV –p1-65535 192.168.1.100

If fact, nmap has the abilily to scan port number 0, so we can do better with:

nmap –PN –sT –sV –p0-65535 192.168.1.100

And the nmap site is nmap.org now. But www.insecure.org is still there.

cheers
--[[User:Unusuario|Unusuario]] 15:36, 2 April 2008 (EDT)

== v3 Review Comments ==

Similar to the previous section this section seems more like Service discovery than application discovery. We're still learning things about the server and not as much about the application(s) we're assessing. IMHO.<br>
May this section should be renamed to something like "Discovery of web server services and web applications on a host".
[[User:Rick.mitchell|Rick.mitchell]] 09:55, 3 September 2008 (EDT)

== Merge with (OWASP-IG-004) ==
This article should be merged with 4.2.4 Testing for Web Application Fingerprint (OWASP-IG-004) and renamed to web server finger printing as both these pages talk about server level finger printing.

also if i pay put forward I have tried to cover some steps of web application finger printing here : http://anantshri.info/articles/web_app_finger_printing.html
I hope this could be of some use in the correct page of web application finger printing.

Talk:Testing for Web Application Fingerprint (OWASP-IG-004)

2011-07-17T12:01:25Z

Anant Shrivastava: submitting request for link addition for page enhancement

Testing for Session Management

2010-11-18T22:11:10Z

Anant Shrivastava: correcting seq number

{{Template:OWASP Testing Guide v3}}

''' 4.5 Session Management Testing'''
----

At the core of any web-based application is the way in which it maintains state and thereby controls user-interaction with the site. Session Management broadly covers all controls on a user from authentication to leaving the application.
HTTP is a stateless protocol, meaning that web servers respond to client requests without linking them to each other. Even simple application logic requires a user's multiple requests to be associated with each other across a "session”. This necessitates third party solutions – through either Off-The-Shelf (OTS) middleware and web server solutions, or bespoke developer implementations. Most popular web application environments, such as ASP and PHP, provide developers with built-in session handling routines. Some kind of identification token will typically be issued, which will be referred to as a “Session ID” or Cookie.
<br>
There are a number of ways in which a web application may interact with a user. Each is dependent upon the nature of the site, the security, and availability requirements of the application.
Whilst there are accepted best practices for application development, such as those outlined in the [[OWASP Guide Project|OWASP Guide to Building Secure Web Applications]], it is important that application security is considered within the context of the provider’s requirements and expectations. In this chapter we describe the following items.<br>

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.5.1 Testing for Session Management Schema (OWASP-SM-001)]]<br>
This describes how to analyse a Session Management Schema, with the goal to understand how the Session Management mechanism has been developed and if it is possible to break it to bypass the user session. It explains how to test the security of session tokens issued to the client's browser: how to reverse engineer a cookie, and how to manipulate cookies to hijack a session.<br>
[[Testing for cookies attributes (OWASP-SM-002)|4.5.2 Testing for Cookies attributes (OWASP-SM-002)]]<br>
Cookies are often a key attack vector for malicious users (typically, targeting other users) and, as such, the application should always take due diligence to protect cookies. In this section, we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.<br>
[[Testing for Session Fixation (OWASP-SM-003)|4.5.3 Testing for Session Fixation (OWASP-SM-003)]]<br>
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known to the attacker.<br>
[[Testing for Exposed Session Variables (OWASP-SM-004)|4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)]]<br>
Session Tokens represent confidential information because they tie the user identity with his own session. It's possible to test if the session token is exposed to this vulnerability and try to create a replay session attack.
<br>
[[Testing for CSRF (OWASP-SM-005)|4.5.5 Testing for CSRF (OWASP-SM-005)]]<br>
Cross Site Request Forgery describes a way to force an unknowing user to execute unwanted actions on a web application in which he is currently authenticated. This section describes how to test an application to find this kind of vulnerability.<br>

Testing for authentication

2010-11-18T22:08:50Z

Anant Shrivastava: serial number correction

{{Template:OWASP Testing Guide v3}}

''' 4.4 Authentication Testing '''
----

Authentication (Greek: αυθεντικός = real or genuine, from 'authentes' = author ) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying her identity. Authentication depends upon one or more authentication factors.
In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the logon process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.

[[Testing for credentials transport (OWASP-AT-001)|4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)]]<br>
Here, the tester will just try to understand if the data that users put into the web form, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not.

[[Testing for user enumeration (OWASP-AT-002)|4.4.2 Testing for user enumeration (OWASP-AT-002)]]<br>
The scope of this test is to verify if it is possible to collect a set of valid users by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.

[[Testing for Default or Guessable User Account (OWASP-AT-003)|4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)]]<br>
Here we test if there are default user accounts or guessable username/password combinations (dictionary testing).

[[Testing for Brute Force (OWASP-AT-004)|4.4.4 Brute Force Testing (OWASP-AT-004)]]<br>
When a dictionary type attack fails, a tester can attempt to use brute force methods to gain authentication. Brute force testing is not easy to accomplish for testers because of the time required and the possible lockout of the tester.

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)]]<br>
Other passive testing methods attempt to bypass the authentication schema by recognizing that not all of the application's resources are adequately protected. The tester can access these resources without authentication.

[[Testing for Vulnerable Remember Password and Pwd Reset (OWASP-AT-006)|4.4.6 Testing for vulnerable remember
password and pwd reset (OWASP-AT-006)]]<br>
Here we test how the application manages the process of "password forgotten". We also check whether the application allows the user to store the password in the browser ("remember password" function).

[[Testing for Logout and Browser Cache Management (OWASP-AT-007)|4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)]]<br>
Here we check that the logout and caching functions are properly implemented.

[[Testing for Captcha (OWASP-AT-008)|4.4.8 Testing for CAPTCHA (OWASP-AT-008)]]<br>
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable. This section will help you to identify these kinds of attacks.

[[Testing Multiple Factors Authentication (OWASP-AT-009)|4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)]]<br>
Multiple Factors Authentication means to test the following scenarios: One-time password (OTP) generator tokens, Crypto devices like USB tokens or smart cards, equipped with X.509 certificates, Random OTP sent via SMS, Personal information that only the legitimate user is supposed to know [OUTOFWALLET].

[[Testing_for_Race_Conditions (OWASP-AT-010)|4.4.10 Testing for Race Conditions (OWASP-AT-010)]]<br>
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

User:Anant Shrivastava

2010-11-03T20:52:10Z

Anant Shrivastava:

Welcome to my User Page.

I also maintain a blog @ http://blog.anantshri.info

Certifications : RHCE and CEH

I work as a Server Admin on *nix Platform.
Interested in Ethical Hacking with focus on Web application Penetration Testing.

My Experience could be summarized as listed below.

* Operating Systems : Linux (RedHat/Fedora, Debian/Ubuntu), DOS, Windows(9X,XP,Vista)
* Servers : HTTP (Apache, IIS, Tomcat), SMB, NFS, FTP, DNS.
* Scripting : Shell Scripting, Batch File Scripting, VB Scripting (VBA).
* Web Development : PHP, ASP (classic), HTML, XHTML, CSS (introductory), JSP, and JavaScript.
* Programming : C/C++, VB 6.0, Java.
* Database : MySQL, Oracle 10 g (introductory level)
* VA / PT Tools : Wapiti, w3af

Don't Learn to hack, Hack to learn.

User:Anant Shrivastava

2010-11-03T20:50:55Z

Anant Shrivastava: adding intro about myself

Welcome to my User Page.

RHCE and CEH

I work as a Server Admin on *nix Platform.
Interested in Ethical Hacking with focus on Web application Penetration Testing.

My Experience could be summarized as listed below.

* Operating Systems : Linux (RedHat/Fedora, Debian/Ubuntu), DOS, Windows(9X,XP,Vista)
* Servers : HTTP (Apache, IIS, Tomcat), SMB, NFS, FTP, DNS.
* Scripting : Shell Scripting, Batch File Scripting, VB Scripting (VBA).
* Web Development : PHP, ASP (classic), HTML, XHTML, CSS (introductory), JSP, and JavaScript.
* Programming : C/C++, VB 6.0, Java.
* Database : MySQL, Oracle 10 g (introductory level)
* VA / PT Tools : Wapiti, w3af

Don't Learn to hack, Hack to learn.

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2010-11-03T20:02:25Z

Anant Shrivastava: Undo revision 52833 by KirstenS (Talk) as the edit reversed the meaning.

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Testing for credentials transport means to verify that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels you can refer to the chapter [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into web forms, for example, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not. To do this we will consider various examples.
<br>

== Description of the Issue ==
Nowadays, the most common example of this issue is the login page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log into a web site, usually, the user has to fill a simple form that transmits the inserted data with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the net with a sniffer tool.
<br>

== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' <br>

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the header of our request with WebScarab, we get something like this:<br>
<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password by simply sniffing the net with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through an encrypted channel and that they are not readable by other people.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data is transmitted in a secure way through encryption. This situation occurs, for example, when we are on a portal of a big company that offers various information and services publicly available, without identification, but which has also a private section accessible from the home page through a login. So when we try to login, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the referer field in the header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So, in this case, we have no lock inside our browser window that tells us that we are using a secure connection, but, in reality, we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead. This is because when the GET method is used, the URL that it requests is easily available from, for example, the server logs exposing your sensitive data to information leakage.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than HTTP, so the whole HTTP package is still encrypted and the URL is unreadable to an attacker. It is not a good practice to use the GET method in these cases, because the information contained in the URL can be stored in many servers such as proxy and web servers, leaking the privacy of the user's credentials.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the HTTPS for sensitive information transmissions.<br>
Then, check with them if HTTPS is used in every sensitive transmission, like those in login pages, to prevent unauthorized users to read the data.

== References ==
'''Whitepapers'''<br>
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html<br>
'''Tools'''<br>
* [[OWASP WebScarab Project|WebScarab]]