OWASP - User contributions [en]

OWASP PyTM

2019-08-28T19:15:19Z

Izar: /* Licensing */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==Project About==
{{Template:Project_About
| project_name=PyTM
| project_description=A Pythonic framework for threat-modeling-from-code
| project_license=MIT License
| leader_name1=Izar Tarandach
| leader_name2= Matthew J. Coles
| contributor_name1=Rohit Shambhuni
| contributor_name2=Nick Ozmore
| contributor_name3=Pooja Ahvad
| presentation_link=https://www.youtube.com/watch?v=VbW-X0j35gw AppSecCali 2019 - Threat Model Every Story: Practical Continuous Threat Modeling Work for Your Team -
}}

==OWASP PyTM==
PyTM is an effort to enable developers to create and maintain threat models in a way that is natural for them, using a familiar OO syntax (Python, but should be generic enough to enable any developer with minimal OO experience to use it) to describe a system in terms of its elements and their attributes, in a way that can be easily shared, version-controlled and collaborated on.

That description is a self-enclosed Python script that when run generates diagrams (DFDs and sequence), threats (based on a library of rules) and reports (joining diagrams and threats).

==Description==

This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.


==Licensing==

This program is free software: you can redistribute it and/or modify it under the terms of the [https://opensource.org/licenses/MIT MIT License] as published by the Massachusetts Institute of Technology. OWASP PyTM and any contributions are Copyright © by the Project Leader(s).

==Roadmap==

As of November, 2013, the highest priorities for the next 6 months are:

* Complete the first draft of the Tool Project Template
* Get other people to review the Tool Project Template and provide feedback
* Incorporate feedback into changes in the Tool Project Template
* Finalize the Tool Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project


Subsequent Releases will add

* Internationalization Support
* Additional Unit Tests
* Automated Regression tests


==Getting Involved==

Involvement in the development and promotion of Tool Project Template is actively encouraged!
You do not have to be a security expert or a programmer to contribute.
Some of the ways you can help are as follows:

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

== Project Resources ==

This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.


[https://github.com/SamanthaGroves Installation Package]

[https://github.com/SamanthaGroves Source Code]

[https://github.com/SamanthaGroves What's New (Revision History)]

[https://github.com/SamanthaGroves Documentation]

[https://github.com/SamanthaGroves Wiki Home Page]

[https://github.com/SamanthaGroves Issue Tracker]

[https://github.com/SamanthaGroves Slide Presentation]

[https://github.com/SamanthaGroves Video]

== Project Leader ==
Izar Tarandach

Matthew J. Coles

== Related Projects ==
* [[OWASP_Threat_Dragon]]
* [[OWASP_Automated_Threats_to_Web_Applications]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:MIT_License_Icon.png|85px|link=https://opensource.org/licenses/MIT|MIT License]]
|}
|}

__NOTOC__ <headertabs />

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

OWASP PyTM

2019-08-28T19:14:55Z

Izar:

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==Project About==
{{Template:Project_About
| project_name=PyTM
| project_description=A Pythonic framework for threat-modeling-from-code
| project_license=MIT License
| leader_name1=Izar Tarandach
| leader_name2= Matthew J. Coles
| contributor_name1=Rohit Shambhuni
| contributor_name2=Nick Ozmore
| contributor_name3=Pooja Ahvad
| presentation_link=https://www.youtube.com/watch?v=VbW-X0j35gw AppSecCali 2019 - Threat Model Every Story: Practical Continuous Threat Modeling Work for Your Team -
}}

==OWASP PyTM==
PyTM is an effort to enable developers to create and maintain threat models in a way that is natural for them, using a familiar OO syntax (Python, but should be generic enough to enable any developer with minimal OO experience to use it) to describe a system in terms of its elements and their attributes, in a way that can be easily shared, version-controlled and collaborated on.

That description is a self-enclosed Python script that when run generates diagrams (DFDs and sequence), threats (based on a library of rules) and reports (joining diagrams and threats).

==Description==

This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.


==Licensing==

A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.


This program is free software: you can redistribute it and/or modify it under the terms of the [https://opensource.org/licenses/MIT MIT License] as published by the Massachusetts Institute of Technology. OWASP PyTM and any contributions are Copyright © by the Project Leader(s).

==Roadmap==

As of November, 2013, the highest priorities for the next 6 months are:

* Complete the first draft of the Tool Project Template
* Get other people to review the Tool Project Template and provide feedback
* Incorporate feedback into changes in the Tool Project Template
* Finalize the Tool Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project


Subsequent Releases will add

* Internationalization Support
* Additional Unit Tests
* Automated Regression tests


==Getting Involved==

Involvement in the development and promotion of Tool Project Template is actively encouraged!
You do not have to be a security expert or a programmer to contribute.
Some of the ways you can help are as follows:

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

== Project Resources ==

This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.


[https://github.com/SamanthaGroves Installation Package]

[https://github.com/SamanthaGroves Source Code]

[https://github.com/SamanthaGroves What's New (Revision History)]

[https://github.com/SamanthaGroves Documentation]

[https://github.com/SamanthaGroves Wiki Home Page]

[https://github.com/SamanthaGroves Issue Tracker]

[https://github.com/SamanthaGroves Slide Presentation]

[https://github.com/SamanthaGroves Video]

== Project Leader ==
Izar Tarandach

Matthew J. Coles

== Related Projects ==
* [[OWASP_Threat_Dragon]]
* [[OWASP_Automated_Threats_to_Web_Applications]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:MIT_License_Icon.png|85px|link=https://opensource.org/licenses/MIT|MIT License]]
|}
|}

__NOTOC__ <headertabs />

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

User:Izar

2019-07-30T13:39:14Z

Izar: Updated bio

Izar Tarandach is Lead Product Security Architect at Autodesk inc.. Prior, he was the Security Architect for Enterprise Hybrid Cloud at Dell EMC, for long before a Security Consultant at the EMC Product Security Office. With more years than he’s willing to admit to in the information security arena, he is a member of SAFECode Technical Leadership Council and a founding contributor to the IEEE Center for Security Design. He holds a masters degree in Computer Science/Security from Boston University and has served as an instructor in Digital Forensics at Boston University and in Secure Development at the University of Oregon.

Projects/OWASP Mobile Security Project -2015 Scratchpad

2015-06-03T18:24:07Z

Izar: /* Proposed Timeline */

This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.

=Proposed Timeline=

The content of the Mobile Top 10 will be refreshed at some cadence, and most probably not a short one. In between there will be needed changes as appropriate, but major changes will happen sparsely between "official releases".

In order to keep interest in the project and to offer deeper and more complete content, there is a proposal to supply architectural and code samples that illustrate the Top 10 items.

As a first milestone it is suggested that 6 months after the Top 10 is released we are able to do a refresh launch offering the initial version of these samples.

A set cadence for further refresh/release later on needs to be established as well.

=What is It?=

This is the "Mobile Top Ten" ''what''? It's the top 10 "stuff people tend to screw up", but here are some important questions.

* Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."

* Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.

* What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps ''do'' care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
** If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
** If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
** If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
** If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.

=Who is it For?=

Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?

(''Paco's opinion'') We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.

=Comments on Submitted Data=

==General==

(Jason) By looking at some data sets it becomes clear there is a doctrine that some consultancies use to do mobile testing. Some did not contribute m1 data, because they consider mobile security client-only. The same applied to m10. In addition, a couple of datasets used CWE IDs. These were harder to parse because generic CWE's do not specify if the vuln is client or server (and in a lot of these cases the vuln could be either). As Paco stated, code quality, source level findings are hard to categorize as well.

==BugCrowd==
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).

I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.

We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?

==MetaIntelli==

They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.

=Other Questions=
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?

I can imagine a heuristic like this:
* did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
* Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.

Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?

=Conclusions Drawn From Data=
These are conclusions proposed from the 2014 data.
==At Least One New Category Is Needed==
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.

==The Bottom 5 Categories account for 25% Or Less==

The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):

# M8: Security Decisions Via Untrusted Inputs
# M7: Client Side Injection
# M9: Improper Session Handling
# M6: Broken Cryptography
# M1: Weak Server Side Controls

Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.

==The Existing Buckets are Hard To Use==

A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.

{|
! Description
! Contributor
! Categories
|-
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.
|MetaIntelli
|M3 and M9
|-
|Contains URLs with not valid SSL certificates and/or chain of trust
|MetaIntelli
|M3 and M5
|-
|Authentication cookies stored in cleartext in sqlite database
|BugCrowd
|M9 - Improper Session Handling
|-
|Blackberry app stores credentials in plaintext
|BugCrowd
|M2 - Insecure Data Storage
|-
|Credentials and sensitive information not secured on Windows Phone app
|BugCrowd
|M5 - Poor Authorization and Authentication
|}

==Some Topics that Show Up But Are Hard To Place==

There are a few things that show up in the contributed data that do not have a good category to go into.

===Code Level Findings===

If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).

Most of the Android developers use "printStackTrace" in their code, which is a bad practice. Even the Android APK is released in DEBUG mode.

=OWASP Category Elements=
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.

==Label (generic and audience-specific labels)==
This element is a unique identifier for the bucket of issues that belong together. In the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewform OWASP Mobile Top Ten 2015 Survey], we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.

==Overview Text==
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.

==Prominent Characteristics==
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.

==Risk==
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.

==Examples==
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.

== Audience Specific Guidance==
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.

="Test Drive" Category Element=
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.

==Insecure Data Transmission==

===Generic Label===
Owner(s): Jonathan Carter

===Audience-Specific Labels===
Owner(s): Jonathan Carter

===Overview Text===

Mobile devices and applications can be used to transmit data over many communication channels. These channels include, but are not limited to:
"Wireless Cellular Protocols (2G, 3G, 4G, 5G, etc.), WiFi(Ad-Hoc, Infrastructure, and Peer to Peer modes), Bluetooth (and it's variants), Infrared, RFID, NFC, etc.

Vulnerabilities in this category focus on weaknesses associated with "data in motion" when transmission occurs over the above noted communication channels. These vulnerabilities can arise as a result of one or more failures in adequately securing the communications channels including but not limited to: plain-text transmission of sensitive data (i.e. not utilizing adequate encryption over the communication channel), insufficient authentication of encrypted channel endpoints (i.e. Failing to confirm the identity of the remote end-point you are attempting secure transmissions with) and/or insufficiently/inadequately establishing the encryption communications protocol (i.e. using weak encryption secrets, ciphers and/or protocols).

Owner(s): Milan Singh Thakur, Amin Lalji

===Prominent Characteristics===
Owner(s): David Fern

The key differentiator of this vulnerability is that it is concerned about unencrypted or improperly encrypted data being stolen during transmission, not on the device but through the airwaves.

[[File:Data Transport.jpg]]

'''Insecure Data Transmission should not be confused with others in the top 10 such as:
'''

'''M3: Insufficient Transport Layer Protection''' – I DO NOT SEE ANT DIFFERENCE

'''M4: Unintended Data Leakage''' – Unintended data leakage is a result of insecure data transmission. Once data has been stolen and interpreted it may contain information that is valuable to attackers (leaked).

'''M6: Broken Cryptography''' – While broken cryptography does relate to data that has been improperly encrypted, and it may be an input or causes of insecure data transmission, it focuses on the encryption process/technique itself on the device transmitting the data.

===Risk===

The risk attributed to mobile applications that suffer from this category of vulnerabilities rely upon the "business" value of the data being transmitted - however from a technical perspective, exploitation of this vulnerability can lead to a loss of confidentiality (i.e. access to confidential/sensitive data by unauthorized individuals/systems) and possibly a loss of integrity (i.e. data may be changed in transit).

The ease of exploitation of this type vulnerability varies based on the communication channel, but generally speaking, is not an overly complex attack to successfully execute (i.e. when sensitive data is transmitted over WiFi in clear-text, it is trivial to intercept and review).

Mitigating the risks associated with this category of vulnerabilities can take various forms depending on the transmission protocol being used.

** Include examples here for protocol level security implemented with Layer 6/7 (TLS/HTTPS), WiFi, Bluetooth, NFC, RFID, etc.)

Owner(s): Rajvinder Singh, Milan Singh Thakur, Amin Lalji

===Examples===
Owner(s): Adam Kliarsky

===Audience-Specific Guidance===
Owner(s): Andi Pannell, Amin Lalji

From both a development and auditing stance, the easiest way to test this is to insert a proxy (such as burp) between the device running the mobile app and the wifi connection.
Looking for data being transferred over plain text, as well as identifying weak procotols (SSLv2, SSLv3) and ciphers (RC4, MD5) being used to transmit data.

=Top Ten Scratchpad=
These are proposed new categories for the 2015 Mobile Top Ten. Edit them. Discuss them. Include inline comments with attirbution where possible.

==Improper Platform Usage==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This category would cover misuse or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.

===Prominent Characteristics===
===Risk===
===Examples===

==Insecure Data ==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This new category will be a combination of M2 + M4 from Mobile Top Ten 2014.

===Prominent Characteristics===
===Risk===
===Examples===

==Insecure Communication (Owner: Andrew Blaich)==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

===Prominent Characteristics===
===Risk===
===Examples===

==Insecure Authentication==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
Broken notions of authenticating the end user or bad session management.

===Prominent Characteristics===
===Risk===
===Examples===

==Insufficient Cryptography==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
The code applies cryptography to a sensitive information asset. However, the cryptographic algorithm is flawed in some way.

===Prominent Characteristics===
===Risk===
===Examples===

==Insecure Authorization==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This used to be "Client Side Injection", one of our lesser-used categories. This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).

===Prominent Characteristics===
===Risk===
===Examples===

==Client Code Quality Issues==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This was "Security Decisions Via Untrusted Inputs", one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That's distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that's running on the mobile device.

===Prominent Characteristics===
===Risk===
===Examples===

==Code Tampering (Owner: Jonathan Carter)==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

===Prominent Characteristics===
===Risk===
===Examples===

==Reverse Engineering (Owner: Jonathan Carter)==
===Generic Label===
===Audience-Specific Label===
===Overview Text===
This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Think about using IDA Pro, Hopper, otool, and other binary inspection tools used to reverse engineer the application. This is valuable to a hacker on its own.

===Prominent Characteristics===
===Risk===
===Examples===

==Extraneous Functionality (Owner: Andrew Blaich)==
===Generic Label===
===Audience-Specific Label===

===Overview Text===
Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.

===Prominent Characteristics===
===Risk===
===Examples===

(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.

Certificate and Public Key Pinning

2015-05-27T16:38:17Z

Izar: /* What Is Pinning? */

[[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 exiting 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>

=== 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{(salt + password)|verifier} + nonces'' rather than traditional Diffie-Hellman using ''gab''.

[[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?]

= 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]]

Projects/OWASP Mobile Security Project -2015 Scratchpad

2015-04-02T17:32:37Z

Izar: wordsmithing

This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.

=What is It?=

This is the "Mobile Top Ten" ''what''? It's the top 10 "stuff people tend to screw up", but here are some important questions.

* Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."

* Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.

* What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps ''do'' care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
** If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
** If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
** If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
** If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.

=Who is it For?=

Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?

(''Paco's opinion'') We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.

=Comments on Submitted Data=

==General==

(Jason) By looking at some data sets it becomes clear there is a doctrine that some consultancies use to do mobile testing. Some did not contribute m1 data, because they consider mobile security client-only. The same applied to m10. In addition, a couple of datasets used CWE IDs. These were harder to parse because generic CWE's do not specify if the vuln is client or server (and in a lot of these cases the vuln could be either). As Paco stated, code quality, source level findings are hard to categorize as well.

==BugCrowd==
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).

I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.

We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?

==MetaIntelli==

They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.

=Other Questions=
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?

I can imagine a heuristic like this:
* did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
* Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.

Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?

=Conclusions Drawn From Data=
These are conclusions proposed from the 2014 data.
==At Least One New Category Is Needed==
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.

==The Bottom 5 Categories account for 25% Or Less==

The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):

# M8: Security Decisions Via Untrusted Inputs
# M7: Client Side Injection
# M9: Improper Session Handling
# M6: Broken Cryptography
# M1: Weak Server Side Controls

Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.

==The Existing Buckets are Hard To Use==

A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.

{|
! Description
! Contributor
! Categories
|-
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.
|MetaIntelli
|M3 and M9
|-
|Contains URLs with not valid SSL certificates and/or chain of trust
|MetaIntelli
|M3 and M5
|-
|Authentication cookies stored in cleartext in sqlite database
|BugCrowd
|M9 - Improper Session Handling
|-
|Blackberry app stores credentials in plaintext
|BugCrowd
|M2 - Insecure Data Storage
|-
|Credentials and sensitive information not secured on Windows Phone app
|BugCrowd
|M5 - Poor Authorization and Authentication
|}

==Some Topics that Show Up But Are Hard To Place==

There are a few things that show up in the contributed data that do not have a good category to go into.

===Code Level Findings===

If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).

Most of the Android developers use "printStackTrace" in their code, which is a bad practice. Even the Android APK is released in DEBUG mode.

=OWASP Category Elements=
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.

==Label (generic and audience-specific labels)==
This element is a unique identifier for the bucket of issues that belong together. In the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewform OWASP Mobile Top Ten 2015 Survey], we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.

==Overview Text==
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.

==Prominent Characteristics==
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.

==Risk==
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.

==Examples==
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.

== Audience Specific Guidance==
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.

="Test Drive" Category Element=
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.

==Insecure Data Transmission==

===Generic Label===
Owner(s): Jonathan Carter

===Audience-Specific Labels===
Owner(s): Jonathan Carter

===Overview Text===

This category focuses on the many available communication channels in the mobile environment and the secure transmission of data through them. If your application is using '''Wi-Fi, WiFi-direct, Bluetooth, Infra-red, RFIDs, POS devices (with NFC Tags)'''; then this category provides guidance in securing data while in transit. Included but not limited to are '''plaintext transmission of sensitive data, insufficient authentication of encrypted channel endpoints, insufficient regard to failures in building a properly encrypted channel, poor choice of security mechanisms over distinct networks''', etc.

Additionaly, this category applies in the same way to secure data transmission in the '''Internet Of Things (IoT)'''.

Owner(s): Milan Singh Thakur

===Prominent Characteristics===
Owner(s): David Fern

===Risk===
Confidential and sensitive data residing on the mobile devices if not fully SSL encrypted during transmission is highly susceptible to eavesdropping. As majority of wireless, mobile devices have capability to use and switch to various home Wifi and public unsecured Wifi. This could be disastrous while giving attackers a glimpse of your personal, non-shareable information which can lead to '''identity theft''' and '''social engineering attacks'''. Similarly, it applies to those mobile apps also where data transmission is not fully SSL encrypted and failed to perform a Valid SSL Certificate check. Additionally, this might lead further to '''man-in-the-middle attacks'''.

Even if the application uses encryption and the device is connected to a public WiFi, an attacker can easily capture all Wireless traffic (as in War-driving). Then attacker can perform '''offline decryption''' and possibly have all your sensitive data.
Consider the situation where your application server uses TLS1.0/SSLv3. You think it is secure? Nope, it is highly vulnerable to attacks like '''CRIME, POODLE and Handshake Re-negotiation'''.

Owner(s): Rajvinder Singh, Milan Singh Thakur

===Examples===
Owner(s): Adam Kliarsky

===Audience-Specific Guidance===
Owner(s): Andi Pannell

=Top Ten Scratchpad=
Here's some top-ten possible categories. This is a wiki. Edit them. Change them. Leave comments. Mark it up.

==M1: Weak Server Side Controls ==
Stuff

==M2: Insecure Data Storage ==
(Jason) As i look through the data I think more and more about how m2 and m4 might be combined.

==M3: Insufficient Transport Layer Protection ==
Stuff

==M4: Unintended Data Leakage ==

Stuff
==M5: Poor Authorization and Authentication ==

Stuff
==M6: Broken Cryptography ==

Stuff
==M7: Client Side Injection ==

Stuff
==M8: Security Decisions Via Untrusted Inputs ==

Stuff
==M9: Improper Session Handling ==

Stuff
==M10: Lack of Binary Protections ==

(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.