https://wiki.owasp.org/api.php?action=feedcontributions&user=Thunder-Son&feedformat=atomOWASP - User contributions [en]2024-03-28T16:58:08ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=OWASP_Cheat_Sheet_Series&diff=255006OWASP Cheat Sheet Series2019-09-29T10:23:51Z<p>Thunder-Son: Remove Dominique from the contact messages</p>
<hr />
<div>= Main = <br />
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div><br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |<br />
<br />
== Our goal == <br />
<br />
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics. These cheat sheets were created by various application security professionals who have expertise in specific topics. We hope that the OWASP Cheat Sheet Series provides you with excellent security guidance in an easy to read format.<br />
<br />
If you have any questions about the OWASP Cheat Sheet Series, please email the project leader [mailto:jim.manico@owasp.org Jim Manico], contact us on the project's Slack channel, or on our [https://groups.google.com/a/owasp.org/forum/#!forum/cheat-sheets-project Google Group] ('''Slack is highly preferred over the Google Group''').<br />
<br />
The archives of the old mailing list can be consulted [https://lists.owasp.org/pipermail/owasp-cheat-sheets/index here].<br />
<br />
== Official website ==<br />
<br />
The official website on which all the cheat sheets are hosted is https://cheatsheetseries.owasp.org .<br />
<br />
== Migration to GitHub ==<br />
<br />
Project has been fully migrated to [https://github.com/OWASP/CheatSheetSeries GitHub].<br />
<br />
This page is used as the OWASP homepage of the project, all the project content is hosted on the [https://github.com/OWASP/CheatSheetSeries GitHub repository] and we work '''only from''' this repository, '''wiki is not used anymore'''. <br />
<br />
The [https://github.com/OWASP/CheatSheetSeries GitHub] repository is used for the work on the cheat sheets and the released ones are deployed on the [https://cheatsheetseries.owasp.org official website].<br />
<br />
So, from now, only a GitHub account is needed to contribute :)<br />
<br />
== Bridge between the projects OWASP Proactive Controls/OWASP Application Security Verification Standard and OWASP Cheat Sheet Series ==<br />
<br />
A work channel has been created between these 2 projects and the Cheat Sheet Series using the following process (''OPC = OWASP Proactive Controls / OASVS = OWASP Application Security Verification Standard / OCS = OWASP Cheat Sheet''):<br />
<br />
* When a Cheat Sheet is missing for a point in OPC/OASVS then the OCS will handle the missing and create one. When the Cheat Sheet is ready then the reference is added by OPC/OASVS.<br />
* If a Cheat Sheet exists for an OPC/OASVS point but the content do not provide the expected help then the Cheat Sheet is updated to provide the content needed/expected.<br />
<br />
The reason of the creation of this bridge is to help the OCS/OASVS projects by providing them:<br />
<br />
* A consistent source for the requests regarding new Cheat Sheets.<br />
* Same approach about the update of the existing Cheat Sheets.<br />
* A usage context for the Cheat Sheet and a quick source of feedack about the quality and the efficiency of the Cheat Sheet.<br />
<br />
It is not mandatory that a request for a new Cheat Sheet (or for an update) come only from OPC/OASVS, it is just a extra channel.<br />
<br />
<pre>Requests from OPC/OASVS are flagged with a special label in the GitHub repository issues list in order to identify them and set them as a top level priority.</pre><br />
<br />
== Project leaders ==<br />
<br />
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:jim.manico@owasp.org @]<br />
<br />
== Core team ==<br />
<br />
* [https://github.com/ThunderSon Elie Saad]<br />
* [https://github.com/mackowski Jakub Maćkowski]<br />
* [https://github.com/rbsec Robin Bailey]<br />
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]<br />
<br />
== Contributors of the V1 of the project == <br />
<br />
Paweł Krawczyk, Mishra Dhiraj, Shruti Kulkarni, Torsten Gigler, Michael Coates, Jeff Williams, Dave Wichers, Kevin Wall, Jeffrey Walton, Eric Sheridan, Kevin Kenan, David Rook, Fred Donovan, Abraham Kang, Dave Ferguson, Shreeraj Shah, Raul Siles, Colin Watson, Neil Matatall, Zaur Molotnikov, Manideep Konakandla, Santhosh Tuppad and '''many more'''!<br />
<br />
== Contributors of the V2 of the project == <br />
<br />
See [https://github.com/OWASP/CheatSheetSeries/graphs/contributors here] for a complete list.<br />
<br />
| style="padding-left:25px;width:200px;" valign="top" |<br />
<br />
== Official website ==<br />
<br />
Website of the [https://cheatsheetseries.owasp.org here].<br />
<br />
== GitHub repository ==<br />
<br />
Repository is [https://github.com/OWASP/CheatSheetSeries here].<br />
<br />
== Offline Cheat Sheets collection ==<br />
<br />
A offline website of all Cheat Sheets can be obtained [https://github.com/OWASP/CheatSheetSeries#offline-website here].<br />
<br />
== Slack & Twitter ==<br />
<br />
Slack channel information:<br />
* Server <code>owasp.slack.com</code><br />
* Channel <code>cheatsheets</code><br />
<br />
Twitter hash tag: '''#[https://twitter.com/search?q=%23owaspcheatsheetseries&src=typd owaspcheatsheetseries]'''<br />
<br />
== Google Group ==<br />
<br />
[https://groups.google.com/a/owasp.org/forum/#!forum/cheat-sheets-project Project Google Group], click [https://groups.google.com/a/owasp.org/forum/#!forum/cheat-sheets-project/join here] to join it.<br />
<br />
Still used for technical discussion '''but we highly prefer''':<br />
* The Slack channel for announcement and technical discussion.<br />
* The Twitter hash tag for announcement only.<br />
<br />
== Project classifications ==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| rowspan="3" width="50%" valign="top" align="center" | [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]<br />
| width="50%" valign="top" align="center" | [[File:Owasp-builders-small.png|link=Builders]] <br />
|-<br />
| width="50%" valign="top" align="center" | [[File:Owasp-defenders-small.png|link=Defenders]]<br />
|-<br />
| width="50%" valign="center" align="center" | <br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]<br />
|}<br />
<br />
== Licensing ==<br />
<br />
The OWASP <i>Cheat Sheet Series</i> is free to use under the [https://creativecommons.org/licenses/by-sa/3.0/us/ Creative Commons ShareAlike 3 License].<br />
<br />
== Related Projects ==<br />
<br />
* [[OWASP Proactive Controls]]<br />
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard Project]<br />
<br />
|}<br />
<br />
= Roadmap =<br />
<br />
Roadmap is managed using the [https://github.com/OWASP/CheatSheetSeries/projects/1 GitHub feature] of the repository.<br />
<br />
= Project Logo =<br />
<br />
'''Project is now finished, we let the specification online for further evolution of the logo.'''<br />
<br />
Big thanks to Amélie Didion for the design work.<br />
<br />
== Logo files ==<br />
<br />
Logo files are hosted on the official OWASP dedicated [https://github.com/OWASP/owasp-swag/tree/master/projects/cheat-sheet-series Github repository].<br />
<br />
Logo n°1:<br />
<br />
[https://github.com/OWASP/owasp-swag/blob/master/projects/cheat-sheet-series/owasp-1.png]<br />
<br />
Logo n°2:<br />
<br />
[https://github.com/OWASP/owasp-swag/blob/master/projects/cheat-sheet-series/owasp-2.png]<br />
<br />
== Objective ==<br />
<br />
This section contains the information that we have gathered and plan to use for the creation of the project logo and related design materials.<br />
<br />
The first phase of the work is to commission a project logo.<br />
<br />
== Phase 1: Logo ==<br />
<br />
=== Introduction ===<br />
<br />
The project requires a logo which will comprise three components:<br />
<br />
* Graphical element indicating the idea or use of the cheat sheets<br />
* The project title<br />
* Motto/straplines.<br />
<br />
Not all of these will necessarily be shown together at the same time. Phase 1 requires the creation of a logo, which may be used with one, two or all three of these components.<br />
<br />
The logo will be used in many ways such as on a website banner, or just the graphical element on a bag, or the graphical element and a motto/strapline on a t-shirt. These other outputs are not included in the scope of Phase 1.<br />
<br />
=== Project Name ===<br />
<br />
The project name is ''OWASP Cheat Sheet Series project''. The project name will be positioned next to the graphical element in some outputs, and this layout must be provided. In other cases, the project name will not be included beside the logo.<br />
<br />
=== Motto/Strapline ===<br />
<br />
Three mottos/straplines will be used in the logo - they are context dependent:<br />
<br />
* ''Life is too short, AppSec is tough, Cheat!''<br />
* ''Its not cheating if you do it for the right reasons''<br />
* ''Sometimes the only good thing to do is cheat''.<br />
<br />
The logo layout must allow for any of these or none to be included.<br />
<br />
=== Layout, Media Formats and Colours ===<br />
<br />
Some media or placements may mean the motto/strapline does not fit or is not needed. Therefore the logo must be usable with, or without, the motto/strapline.<br />
<br />
The logo will need to be used at multiple scales. For example, if the logo is square excluding the motto/strapline, the following formats must work<br />
<br />
* Low-resolution use on web pages (e.g. as small as 100x100 pixels excluding moto/strapline) <br />
* Medium resolution use on fabric such as t-sirts or bags (e.g. 900x900 pixels at 150 dpi)<br />
* High-resolution use on large posters and banners (e.g. as large as 5,000x5,000 pixels at 300dpi).<br />
<br />
The logo may be printed in CMYK for physical media, but must also have RGB colours for screen use. Additionally the logo must also be available in grayscale, and separately as single colour (i.e. black and white without any tones).<br />
<br />
=== Deliverables Required ===<br />
<br />
All outputs must be provided digitally:<br />
<br />
# Logo demonstrating how it looks with just the graphical element, the graphical element with the project title, and the graphical element with each of the mottos/straplines, and everything together<br />
# Source layered vector graphic files created in Adobe Illustrator<br />
# Exported versions for quick use low, medium and high resolution full-colour PNG/JPEGs in RGB and CMYK<br />
# Colour and font specification.<br />
<br />
Rights/licensing:<br />
<br />
# The designer will not retain any rights - all design and use rights will be given to OWASP, who will publish the logo and files using am open source licence, and OWASP will be able to use the logo, source files, ideas, designs in any manner it desires in any media in any quantity, without any additional payments, commission or royalties to the designer or anyone else<br />
# All fonts used in the design must be provided to OWASP and comply with the above requirements<br />
<br />
<br />
<br />
== Future Phases: Other Graphical Elements ==<br />
<br />
Scope TBC - Banners, t-shirts, etc<br />
<br />
Background pictures (picture provider and designer will be cited on the project site):<br />
* ''A smart tech looking woman reading a piece of paper (the cheatsheet) while resting on a beach.''<br />
* ''A woman hand holding cards with an ace up the sleeve.''<br />
<br />
Pictures proposal (just a proposal as bootstrap, others pictures can be used):<br />
* Cards:<br />
** https://www.pexels.com/photo/woman-holding-queen-of-hearts-and-diamonds-922706/<br />
** https://www.pexels.com/photo/ace-card-gambling-hand-274373/<br />
** https://www.pexels.com/photo/ace-bet-business-card-262333/<br />
* Beach:<br />
** https://www.pexels.com/photo/laptop-mockup-notebook-outside-4778/<br />
** https://www.pexels.com/photo/apple-check-computer-female-7079/<br />
** https://www.pexels.com/photo/beach-beach-chair-blur-casual-319921/<br />
** https://www.pexels.com/photo/close-up-of-woman-typing-on-keyboard-of-laptop-6352/<br />
** https://www.pexels.com/photo/black-and-gray-computer-laptop-159784/<br />
<br />
<br />
__NOTOC__ <headertabs /><br />
<br />
[[Category:OWASP Project|OWASP Cheat Sheets Project]]<br />
[[Category:OWASP_Document]]<br />
[[Category:OWASP_Alpha_Quality_Document]]<br />
[[Category:SAMM-EG-1]]</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=OWASP_Mobile_Top_10&diff=253245OWASP Mobile Top 102019-07-23T04:59:33Z<p>Thunder-Son: Remove the New flag for the top ten 2016 final release</p>
<hr />
<div>=Main=<br />
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE --><br />
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: lab_big.jpg|link=OWASP_Project_Stages#tab.3DLab_Projects]]</div><br />
<br />
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE --><br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |<br />
<br />
== OWASP Mobile Security Top 10 project ==<br />
<br />
'''[https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10 Mobile Top Ten 2016 - Final Release]'''<center><br />
{| class="noprint" id="social_bookmarks" style="width:45%; background-color:#FFFFFF; border:1px solid #a7d7f9; -moz-border-radius: 9px;-webkit-border-radius: 9px; border-radius: 9px; padding:1px;" align="center"<br />
|-<br />
|<div class="plainlinks" align="center"><br />
'''Share this:'''&nbsp; <span title="Share via e-mail" class="plainlinks">[[File:social-email.png|E-mail this story|link=mailto:?subject=Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks&body=Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks:%0Ahttps://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on Facebook">[[File:social-facebook.png|Bookmark with Facebook|link=http://www.facebook.com/sharer.php?u=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on Digg">[[File:social-digg.png|Share on Digg.com|link=http://digg.com/submit?url=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on delicious">[[File:social-delicious.png|16px|Share on delicious|link=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on reddit">[[File:social-reddit.png|Share on reddit.com|link=http://reddit.com/submit?url=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on StumbleUpon">[[File:social-stumbleupon.png|16px|Share on stumbleupon.com|link=http://stumbleupon.com/submit?url=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on LinkedIn">[[File:social-linkedin.png|16px|Share on LinkedIn.com|link=http://www.linkedin.com/shareArticle?mini=true&url=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span> <span title="Share on Twitter">[[File:social-twitter.png|alt=Share on twitter.com|link=http://twitter.com/?status=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10|Share on twitter.com]]</span> <span title="Seed on Newsvine">[[File:social-newsvine.png|16px|Seed on Newsvine|link=http://www.newsvine.com/_wine/save?popoff=1&u=https://www.owasp.org/index.php?title=OWASP_Mobile_Top_10]]</span><br />
</div><br />
|}</center><br />
<br />
==The Mobile Top Ten 2016==<br />
Following a 90-day review and publication of the release candidate, we determined that the release candidate was ready for final publication. The 2016 list has now been published and can be found here: [https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10 OWASP Mobile Top Ten 2016]<br />
<br />
Feel free to visit [https://groups.google.com/a/owasp.org/forum/#!forum/owasp-mobile-top-10-risks the mailing list] as well!<br />
==2015 Mobile Top Ten Analysis Results==<br />
Are you interested in what the data collection for the 2015 list looks like? Check out the final synthesis... [[Media:2015 Data Synthesis Results.pptx]]<br />
<br />
We are fleshing out the new Mobile Top Ten at [[Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad]]. Have a look.<br />
<br />
Here is the original raw data: [[https://www.dropbox.com/sh/d143o6tbkdx4w4l/AAAQlpmnCpHCgiBqZkgXPSTKa?dl=0 Dropbox Data]]<br />
==Project Leads, Credit, and Contributions==<br />
*''' [[Mobile Top Contributions|Mobile Top Ten Contributions Page]] '''<br />
==How Did the List Get Made?==<br />
#We wanted to know what the community wanted in the next Mobile Top Ten list and what they thought about the last. We published a [http://bit.ly/1sihkkE survey] and shared the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewanalytics results] with everyone.<br />
#We issued a [https://www.owasp.org/index.php/File:MobileTopTen2015-CallForData.pdf Call for Data] and aggressively pursued many different vendors and consultants for raw data.<br />
#We had a huge response by vendors and consultants. We collected lots of data about the last years vulnerabilities from a number of different vendors and consultant. That raw data can be found [https://www.dropbox.com/sh/d143o6tbkdx4w4l/AAAQlpmnCpHCgiBqZkgXPSTKa?dl=0 here].<br />
#Over the coming months, we then analyzed the data. Lots of different contributors did their own analysis and compared results. [https://www.owasp.org/index.php/Mobile2015Commentary Here] is a sample of the color commentary on the data.<br />
#Ultimately, we agreed on the findings and published [https://www.owasp.org/images/9/96/OWASP_Mobile_Top_Ten_2015_-_Final_Synthesis.pdf key findings] from the data that we all agreed upon.<br />
#Next, we started coming up with a [https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad consensus] of what we wanted in the next revision of the Mobile Top Ten.<br />
#Results were collected and a release candidate got released.<br />
#We examined the results from the release candidate and concluded that we achieved what we set out to do for 2016<br />
#We published the list officially and moved it from release to final stage <br />
<br />
== Archive ==<br />
* The list below is the OLD release candidate v1.0 of the OWASP Top 10 Mobile Risks. &nbsp;This list was initially released on September 23, 2011 at Appsec USA. &nbsp;<br />
** The original presentation can be found here:&nbsp;[http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks SLIDES]<br> <br />
** The corresponding video can be found here: [http://www.youtube.com/watch?v=GRvegLOrgs0 VIDEO]<br />
** [[Mobile_Top_10_2012|2011-12 Mobile Top Ten for archive purposes]]<br />
<br />
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE -->| style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |<br />
<br />
== Project details ==<br />
<br />
=== Email List ===<br />
[[Image:Asvs-bulb.jpg]] [https://groups.google.com/a/owasp.org/forum/#!forum/owasp-mobile-top-10-risks Project Email List]<br />
==Project Leaders==<br />
* [mailto:jason.haddix@owasp.org Jason Haddix - HP Fortify]<br />
* [mailto:daniel.meissler@owasp.org Daniel Miessler - HP Fortify]<br />
* [mailto:jonthan.carter@owasp.org Jonathan Carter - Arxan Technologies]<br />
*[mailto:milan@owasp.org Milan Singh Thakur]<br />
|}<br />
<br />
= Top 10 Mobile Risks =<br />
<br />
Please visit the [https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks project page] for current information. <br />
<br />
== About this list ==<br />
In 2015, we performed a survey and initiated a Call for Data submission Globally . This helped us to analyze and re-categorize the OWASP Mobile Top Ten for 2016. So the top ten categories are now more focused on Mobile application rather than Server.<br />
<br />
Our goals for the 2016 list included the following:<br />
<br />
* Updates to the wiki content; including cross-linking to testing guides, more visual exercises, etc;<br />
* Generation of more data; and<br />
* A PDF release.<br />
<br />
This list has been finalized after a 90-day feedback period from the community. Based on feedback, we have released a Mobile Top Ten 2016 list following a similar approach of collecting data, grouping the data in logical and consistent ways.<br />
<br />
Feel free to visit [https://groups.google.com/a/owasp.org/forum/#!forum/owasp-mobile-top-10-risks the mailing list] as well!<br />
<br />
== Top 10 Mobile Risks - Final List 2016 ==<br />
*[[Mobile_Top_10_2016-M1-Improper_Platform_Usage|M1: Improper Platform Usage]]<br />
*[[Mobile_Top_10_2016-M2-Insecure_Data_Storage|M2: Insecure Data Storage]]<br />
*[[Mobile_Top_10_2016-M3-Insecure_Communication|M3: Insecure Communication]]<br />
*[[Mobile_Top_10_2016-M4-Insecure_Authentication|M4: Insecure Authentication]]<br />
*[[Mobile_Top_10_2016-M5-Insufficient_Cryptography|M5: Insufficient Cryptography]]<br />
*[[Mobile_Top_10_2016-M6-Insecure_Authorization|M6: Insecure Authorization]]<br />
*[[Mobile_Top_10_2016-M7-Poor_Code_Quality|M7: Client Code Quality]]<br />
*[[Mobile_Top_10_2016-M8-Code_Tampering|M8: Code Tampering]]<br />
*[[Mobile_Top_10_2016-M9-Reverse_Engineering|M9: Reverse Engineering]]<br />
*[[Mobile_Top_10_2016-M10-Extraneous_Functionality|M10: Extraneous Functionality]]<br />
<br />
== Top 10 Mobile Risks - Final List 2014 ==<br />
[[File:2014-01-26 20-23-29.png|right|550px]]<br />
*[[Mobile_Top_10_2014-M1|M1: Weak Server Side Controls]] <br />
*[[Mobile_Top_10_2014-M2|M2: Insecure Data Storage]]<br />
*[[Mobile_Top_10_2014-M3|M3: Insufficient Transport Layer Protection]]<br />
*[[Mobile_Top_10_2014-M4|M4: Unintended Data Leakage]]<br />
*[[Mobile_Top_10_2014-M5|M5: Poor Authorization and Authentication]]<br />
*[[Mobile_Top_10_2014-M6|M6: Broken Cryptography]]<br />
*[[Mobile_Top_10_2014-M7|M7: Client Side Injection]]<br />
*[[Mobile_Top_10_2014-M8|M8: Security Decisions Via Untrusted Inputs]]<br />
*[[Mobile_Top_10_2014-M9|M9: Improper Session Handling]]<br />
*[[Mobile_Top_10_2014-M10|M10: Lack of Binary Protections]]<br />
<br />
== Project Methodology ==<br />
<br />
* '''We adhered loosely to the [https://www.owasp.org/index.php/Top_10_2013/ProjectMethodology OWASP Web Top Ten Project methodology]. '''<br />
<br />
== Archive ==<br />
* The list below is the OLD release candidate v1.0 of the OWASP Top 10 Mobile Risks. &nbsp;This list was initially released on September 23, 2011 at Appsec USA. &nbsp;<br />
** The original presentation can be found here:&nbsp;[http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks SLIDES]<br> <br />
** The corresponding video can be found here: [http://www.youtube.com/watch?v=GRvegLOrgs0 VIDEO]<br />
** [[Mobile_Top_10_2012|2011-12 Mobile Top Ten for archive purposes]]<br />
<br />
=Acknowledgements =<br />
This page is a work in progress. If we have omitted you, or incorrectly affiliated you, please contact us right away.<br />
==Project Leads==<br />
*[mailto:jason.haddix@owasp.org Jason Haddix - HP Fortify]<br />
*[mailto:daniel.meissler@owasp.org Daniel Miessler - HP Fortify]<br />
*[mailto:jonthan.carter@owasp.org Jonathan Carter - Arxan Technologies]<br />
*[mailto:milan@owasp.org Milan Singh Thakur]<br />
==Strategic Roadmap==<br />
[[Media:OWASP Mobile Top Ten 2015 - Strategy.pdf|Strategy Document]]<br />
==Wiki Content==<br />
*[mailto:chad.butler@owasp.org Chad Butler - Concur Technologies]<br />
*[mailto:jonathan.carter@owasp.org Jonathan Carter - Arxan Technologies]<br />
*Ron Gutierrez - Gotham Digital Science<br />
*[mailto:jason.haddix@owasp.org Jason Haddix - HP Fortify]<br />
*[mailto:paco@owasp.org Paco Hope - Cigital]<br />
*Zach Lanier<br />
*[mailto:daniel.meissler@owasp.org Daniel Miessler - HP Fortify]<br />
*[mailto:andrew.pannell@owasp.org Andrew Pannell - Pentest Limited]<br />
*Rahil Parikh - Gotham Digital Science<br />
*Mike Zuzman<br />
*[mailto:milan@owasp.org Milan Singh Thakur]<br />
==Data Contributors==<br />
*[http://www8.hp.com/us/en/software-solutions/fortify-on-demand-application-security/mobile-application-security.html HP Fortify]<br />
*[https://twitter.com/andresitoath Andreas Athanasoulias & Syntax IT]<br />
*[http://www.espheresecurity.com/ Hemil Shah and eSphere Security]<br />
*[http://www.riis.com/ Godfrey Nolan and RIIS (Research Into Internet Systems)]<br />
*[http://www.arxan.com/ Arxan Technologies]<br />
*[http://www.cigital.com/ Cigital]<br />
*[http://www.bugcrowd.com/ Bugcrowd]<br />
*[http://www.hacklabs.com/ Hacklabs]<br />
*[http://www.ibm.com/security/xforce/ IBM X-Force Threat Intelligence]<br />
*[http://www.krvw.com/ KRVW Associates]<br />
*[http://www.metaintelli.com/ MetaIntelli]<br />
*[http://www.purehacking.com/ Pure Hacking]<br />
*[http://www.securenetwork.it/ Secure Network]<br />
*[https://aujas.com/ Aujas Networks]<br />
==Data==<br />
The 2015 data sets are stored at the below link:<br />
<br />
https://www.dropbox.com/sh/ts32chiqnglqvy4/AADVrJCV96xTsm_sxKILxF0La?dl=0<br />
==Synthesis==<br />
Key observations and trends from the data can be found in here:<br />
*[[Media:OWASP Mobile Top Ten 2015 - Final Synthesis.pdf|Synthesis Document]]<br />
==Additional Thanks==<br />
*Jim Manico<br />
<br /><br />
= Top 10 Mobile Controls =<br />
==OWASP/ENISA Collaboration==<br />
<br />
OWASP and the European Network and Information Security Agency (ENISA) collaborated to build a joint set of controls. ENISA has published the results of the collaborative effort as the "Smartphone Secure Development Guideline", which is published in 2011 at: https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines/at_download/fullReport. In 2017, an update was published by ENISA at https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines-2016.<br />
<br />
[[File:OWASP_Mobile_Top_10_Controls.jpg|center|800px]]<br />
<br />
==Contributors==<br />
<br />
This document has been jointly produced with ENISA as well as the following individuals:<br />
*Vinay Bansal, Cisco Systems<br />
*Nader Henein, Research in Motion<br />
*Giles Hogben, ENISA<br />
*Karsten Nohl, Srlabs<br />
*Jack Mannino, nVisium Security<br />
*Christian Papathanasiou, Royal Bank of Scotland<br />
*Stefan Rueping, Infineon<br />
*Beau Woods, Stratigos Security<br />
<br />
== Top 10 mobile controls and design principles==<br />
<br />
'''[[#section control_1|1. Identify and protect sensitive data on the mobile device]]'''<br />
<br />
'''Risks:''' Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on the device.<br />
<br />
*1.1 In the design phase, classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification. Validate the security of API calls applied to sensitive data.<br />
*1.2 Store sensitive data on the server instead of the client-end device. This is based on the assumption that secure network connectivity is sufficiently available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment (3) or the OWASP Cloud top 10 (4) for decision support).<br />
*1.3 When storing data on the device, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption APIs which use a secret key protected by the device unlock code and deleteable on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden on the end-user. It also makes stored data safer in the case of loss or theft. However, it should be born in mind that even when protected by the device unlock key, if data is stored on the device, its security is dependent on the security of the device unlock code if remote deletion of the key is for any reason not possible.<br />
*1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see control 2).<br />
*1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within 100m of car etc...).<br />
*1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see controls 1.7, 1.8).<br />
*1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:<br />
**Be aware of caches and temporary storage as a possible leakage channel, when shared with other apps.<br />
**Be aware of public shared storage such as address book, media gallery and audio files as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.<br />
**Do not store temp/cached data in a world readable directory.<br />
*1.8 For sensitive personal data, deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).<br />
*1.9 There is currently no standard secure deletion procedure for flash memory (unless wiping the entire medium/card). Therefore data encryption and secure key management are especially important.<br />
*1.10 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc)<br />
*1.11 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.<br />
*1.12 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (use a randomly generated number – see 4.3). Apply the same data minimization principles to app sessions as to http sessions/cookies etc.<br />
*1.13 Applications on managed devices should make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss. (A kill-switch is the term used for an OS-level or purpose-built means of remotely removing applications and/or data).<br />
*1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).<br />
<br />
'''2. Handle password credentials securely on the device'''<br />
<br />
'''Risks:''' Spyware, surveillance, financial malware. A user's credentials, if stolen, not only provide unauthorized access to the mobile backend service, they also potentially compromise many other services and accounts used by the user. The risk is increased by the widespread of reuse of passwords across different services.<br />
<br />
*2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device (as per the OAuth model). Encrypt the tokens in transit (using SSL/TLS). Tokens can be issued by the backend service after verifying<br />
Smartphones secure development guidelines for app developers the user credentials initially. The tokens should be time bounded to the specific service as well as revocable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire as frequently as practicable.<br />
*2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate hashing or encryption.<br />
*2.3 Some devices and add-ons allow developers to use a Secure Element e.g. (5) (6) – sometimes via an SD card module - the number of devices offering this functionality is likely to increase. Developers should make use of such capabilities to store keys, credentials and other sensitive data. The use of such secure elements gives a higher level of assurance with the standard encrypted SD card certified at FIPS 140-2 Level 3. Using the SD cards as a second factor of authentication though possible, isn't recommended, however, as it becomes a pseudo-inseparable part of the device once inserted and secured.<br />
*2.4 Provide the ability for the mobile user to change passwords on the device.<br />
*2.5 Passwords and credentials should only be included as part of regular backups in encrypted or hashed form.<br />
*2.6 Smartphones offer the possibility of using visual passwords which allow users to memorize passwords with higher entropy. These should only be used however, if sufficient entropy can be ensured. (7)<br />
*2.7 Swipe-based visual passwords are vulnerable to smudge-attacks (using grease deposits on the touch screen to guess the password). Measures such as allowing repeated patterns should be introduced to foil smudge-attacks. (8)<br />
*2.8 Check the entropy of all passwords, including visual ones (see 4.1 below).<br />
*2.9 Ensure passwords and keys are not visible in cache or logs.<br />
*2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration with the backend (like password embedded in code). Mobile application binaries can be easily downloaded and reverse engineered.<br />
<br />
'''3. Ensure sensitive data is protected in transit'''<br />
<br />
'''Risks:''' Network spoofing attacks, surveillance. The majority of smartphones are capable of using multiple network mechanisms including Wi-Fi, provider network (3G, GSM, CDMA and others), Bluetooth etc. Sensitive data passing through insecure channels could be intercepted. (9) (10)<br />
<br />
*3.1 Assume that the provider network layer is not secure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the Wi-Fi network will be appropriately encrypted.<br />
*3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information over the wire/air (e.g. using Strict Transport Security - STS (11)).This includes passing user credentials, or other authentication equivalents. This provides confidentiality and integrity protection.<br />
*3.3 Use strong and well-known encryption algorithms (e.g. AES) and appropriate key lengths (check current recommendations for the algorithm you use e.g. (12) page 53).<br />
*3.4 Use certificates signed by trusted CA providers. Be very cautious in allowing self- signed certificates. Do not disable or ignore SSL chain validation.<br />
*3.5 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with end-points having the trusted certificates in the key chain.<br />
*3.6 The user interface should make it as easy as possible for the user to find out if a certificate is valid.<br />
*3.7 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end-points.<br />
<br />
'''Reference:''' Google vulnerability of Client Login account credentials on unprotected wifi - [http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]<br />
<br />
'''4. Implement user authentication,authorization and session management correctly'''<br />
<br />
'''Risks:''' Unauthorized individuals may obtain access to sensitive data or systems by circumventing authentication systems (logins) or by reusing valid tokens or cookies. (13)<br />
<br />
*4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the sensitivity of the data being processed by the application and its access to valuable resources (e.g. costing money).<br />
*4.2 It is important to ensure that the session management is handled correctly after the initial authentication, using appropriate secure protocols. For example, require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).<br />
*4.3 Use unpredictable session identifiers with high entropy. Note that random number generators generally produce random but predictable output for a given seed (i.e. the same sequence of random numbers is produced for each seed). Therefore it is important to provide an unpredictable seed for the random number generator. The standard method of using the date and time is not secure. It can be improved, for example using a combination of the date and time, the phone temperature sensor and the current x,y and z magnetic fields. In using and combining these values, well-tested algorithms which maximise entropy should be chosen (e.g. repeated application of SHA1 may be used to combine random variables while maintaining maximum entropy – assuming a constant maximum seed length).<br />
*4.4 Use context to add security to authentication - e.g. IP location, etc...<br />
*4.5 Where possible, consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc.<br />
*4.6 Use authentication that ties back to the end user identity (rather than the device identity).<br />
<br />
'''5. Keep the backend APIs (services) and the platform (server) secure''' <br />
<br />
'''Risks:''' Attacks on backend systems and loss of data via cloud storage. The majority of mobile applications interact with the backend APIs using REST/Web Services or proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow attackers to compromise data on the mobile device when transferred to the backend, or to attack the backend through the mobile application. (14)<br />
<br />
*5.1 Carry out a specific check of your code for sensitive data unintentionally transferred, any data transferred between the mobile device and web-server back- ends and other external interfaces - (e.g. is location or other information included within file metadata).<br />
*5.2 All backend services (Web Services/REST) for mobile apps should be tested for vulnerabilities periodically, e.g. using static code analyser tools and fuzzing tools for testing and finding security flaws.<br />
*5.3 Ensure that the backend platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.<br />
*5.4 Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).<br />
*5.5 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.<br />
*5.6 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.<br />
*5.7 Web Services, REST and APIs can have similar vulnerabilities to web applications:<br />
**Perform abuse case testing, in addition to use case testing<br />
**Perform testing of the backend Web Service, REST or API to determine vulnerabilities.<br />
<br />
'''6. Secure data integration with third party services and applications'''<br />
<br />
'''Risks:''' Data leakage. Users may install applications that may be malicious and can transmit personal data (or other sensitive stored data) for malicious purposes.<br />
<br />
*6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, with maintenance supported, no backend Trojans)<br />
*6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.<br />
*6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing within the application.<br />
<br />
'''7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data'''<br />
<br />
'''Risks:''' Unintentional disclosure of personal or private information, illegal data processing. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII). (15) (16)<br />
<br />
*7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.<br />
*7.2 Consent may be collected in three main ways:<br />
**At install time<br />
**At run-time when data is sent<br />
**Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.<br />
*7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent unique identifiers linked to central data stores containing personal information?<br />
*7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).<br />
*7.5 Keep a record of consent to the transfer of PII. This record should be available to the user (consider also the value of keeping server-side records attached to any user data stored). Such records themselves should minimise the amount of personal data they store (e.g. using hashing).<br />
*7.6 Check whether your consent collection mechanism overlaps or conflicts (e.g. in the data handling practices stated) with any other consent collection within the same stack (e.g. APP-native + webkit HTML) and resolve any conflicts.<br />
<br />
'''8. Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc.)'''<br />
'''Risks:''' Smartphone apps give programmatic (automatic) access to premium rate phone calls, SMS, roaming data, NFC payments, etc. Apps with privileged access to such API’s should take particular care to prevent abuse, considering the financial impact of vulnerabilities that giveattackers access to the user’s financial resources.<br />
<br />
*8.1 Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a trusted server backend – with user consent) and make them available to the end-user for monitoring. Logs should be protected from unauthorised access.<br />
*8.2 Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g. when significant change in location occurs, user-language changes etc.<br />
*8.3 Consider using a white-list model by default for paid-for resource addressing - e.g. address book only unless specifically authorised for phone calls.<br />
*8.4 Authenticate all API calls to paid-for resources (e.g. using an app developer certificate).<br />
*8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.<br />
*8.6 Warn user and obtain consent for any cost implications for app behaviour.<br />
*8.7 Implement best practices such as fast dormancy (a 3GPP specification), caching, etc. to minimize signalling load on base stations.<br />
<br />
'''9. Ensure secure distribution/provisioning of mobile applications'''<br />
<br />
'''Risks:''' Use of secure distribution practices is important in mitigating all risks described in the OWASP Mobile Top 10 Risks and ENISA top 10 risks.<br />
*9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.<br />
*9.2 Most app-stores monitor apps for insecure code and are able to remotely remove apps at short notice in case of an incident. Distributing apps through official app- stores therefore provides a safety-net in case of serious vulnerabilities in your app.<br />
*9.3Provide feedback channels for users to report security problems with apps – e.g. a security@ email address.<br />
<br />
'''10. Carefully check any runtime interpretation of code for errors '''<br />
<br />
'''Risks:''' Runtime interpretation of code may give an opportunity for untrusted parties to provide unverified input which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls provided by app-stores. It can lead to injection attacks leading to Data leakage, surveillance, spyware, and diallerware.<br />
<br />
Note that it is not always obvious that your code contains an interpreter. Look for any capabilities accessible via user-input data and use of third party API’s which may interpret user-input - e.g. JavaScript interpreters.<br />
<br />
*10.1 Minimize runtime interpretation and capabilities offered to runtime interpreters: run interpreters at minimal privilege levels.<br />
*10.2 Define comprehensive escape syntax as appropriate.<br />
*10.3 Fuzz test interpreters.<br />
*10.4 Sandbox interpreters.<br />
<br />
''Appendix A- Relevant General Coding Best Practices'''<br />
<br />
Some general coding best practices are particularly relevant to mobile coding. We have listed some of the most important tips here:<br />
**Perform abuse case testing, in addition to use case testing.<br />
**Validate all input.<br />
**Minimise lines and complexity of code. A useful metric is cyclomatic complexity (17).<br />
**Use safe languages (e.g. from buffer-overflow).<br />
**Implement a security report handling point (address) security@example.com<br />
**Use static and binary code analysers and fuzz-testers to find security flaws.<br />
**Use safe string functions, avoid buffer and integer overflow.<br />
**Run apps with the minimum privilege required for the application on the operating<br />
system. Be aware of privileges granted by default by APIs and disable them.<br />
**Don't authorize code/app to execute with root/system administrator privilege<br />
**Always perform testing as a standard as well as a privileged user<br />
**Avoid opening application-specific server sockets (listener ports) on the client device.<br />
Use the communication mechanisms provided by the OS.<br />
**Remove all test code before releasing the application<br />
**Ensure logging is done appropriately but do not record excessive logs, especially those<br />
including sensitive user information.<br />
<br />
<br />
''Appendix B- Enterprise Guidelines''<br />
**If a business-sensitive application needs to be provisioned on a device, applications should enforce of a higher security posture on the device (such as PIN, remote management/wipe, app monitoring)<br />
**Device certificates can be used for stronger device authentication.'<br />
<br />
''References"''<br />
*1.ENISA. Top Ten Smartphone Risks . [Online] http://www.enisa.europa.eu/act/application-security/smartphone-security-1/top-ten-risks.<br />
*2. OWASP. Top 10 mobile risks. [Online] https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks.<br />
*3. Cloud Computing: Benefits, Risks and Recommendations for information security. [Online] 2009. http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment.<br />
*4. OWASP Cloud Top 10. [Online] https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project.<br />
*5. Blackberry developers documents. [Online] http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.h tml,.<br />
*6. Google Seek For Android. [Online] http://code.google.com/p/seek-for-android/.<br />
*7. Visualizing Keyboard Pattern Passwords. [Online] cs.wheatoncollege.edu/~mgousie/comp401/amos.pdf.<br />
*8. Smudge Attacks on Smartphone Touch Screens. Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M. Smith. s.l. : Department of Computer and Information Science – University of Pennsylvania.<br />
*9. Google vulnerability of Client Login account credentials on unprotected . [Online] http://www.uni- ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html.<br />
*10. SSLSNIFF. [Online] http://blog.thoughtcrime.org/sslsniff-anniversary-edition. 11. [Online] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02.<br />
Smartphones secure development guidelines for app developers<br />
*11. [Online] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02.<br />
*12. NIST Computer Security. [Online] http://csrc.nist.gov/publications/nistpubs/800-57/sp800- 57_PART3_key-management_Dec2009.pdf.<br />
*13. Google's ClientLogin implementation . [Online] http://www.uni- ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html.<br />
*14. [Online] https://www.owasp.org/index.php/Web_Services.<br />
*15. EU Data Protection Directive 95/46/EC. [Online] http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML.<br />
*16. [Online] http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11 _Spafford.pdf.<br />
*17. [Online] http://www.aivosto.com/project/help/pm-complexity.html.<br />
*18. [Online] http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html.<br />
**19. Google Wallet Security. [Online] http://www.google.com/wallet/how-it-works-security.htm.<br />
<br />
<br />
<br />
__NOTOC__ <headertabs /></div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=OWASP_Mobile_Security_Project&diff=252953OWASP Mobile Security Project2019-07-11T06:22:51Z<p>Thunder-Son: Improve Feedback Sentence</p>
<hr />
<div>=Main=<br />
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE --><br />
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: lab_big.jpg|link=OWASP_Project_Stages#tab.3DLab_Projects]]</div><br />
<br />
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE --><br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
== OWASP Mobile Security Project ==<br />
[[File:OWASP_Mobile_Logo_Milan.PNG|center ]]<br />
<br />
'''[https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10 **New** Mobile Top Ten 2016 - Final Release]'''<br />
<br />
<br />
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.<br />
The project is a breading ground for many different mobile security projects within OWASP. Right now, you can find the following active OWASP mobile security projects:<br />
{| class="wikitable"<br />
!Project/deliverable<br />
!More info:<br />
!Description:<br />
!Current leaders<br />
|-<br />
|Mobile Top Ten<br />
|[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Project Page]<br />
|The OWASP Mobile Security top 10 is created to raise awareness for the current mobile security issues.<br />
|<br />
* [mailto:jason.haddix@owasp.org Jason Haddix - HP Fortify]<br />
* [mailto:daniel.meissler@owasp.org Daniel Miessler - HP Fortify]<br />
* [mailto:jonthan.carter@owasp.org Jonathan Carter - Arxan Technologies]<br />
*[mailto:milan@owasp.org Milan Singh Thakur]<br />
|-<br />
|Mobile Security Testing Guide<br />
|[[OWASP Mobile Security Testing Guide|Project Page]]<br />
|A comprehensive manual for mobile app security testing and reverse engineering for iOS and Android mobile security testers as well as developers.<br />
|<br />
* [mailto:sven.schleier@owasp.org Sven Schleier]<br />
* [mailto:jeroen.willemsen@owasp.org Jeroen Willemsen]<br />
|-<br />
|Mobile Application Security Verification Standard<br />
|[[OWASP Mobile Security Testing Guide|Project Page]]<br />
|A standard for mobile app security which outlines the security requirements of a mobile application.<br />
|<br />
* [mailto:sven.schleier@owasp.org Sven Schleier]<br />
* [mailto:jeroen.willemsen@owasp.org Jeroen Willemsen]<br />
|-<br />
|Mobile Security Checklist<br />
|[[OWASP Mobile Security Testing Guide|Project Page]]<br />
|A checklist which allows easy mapping and scoring of the requirements from the Mobile Application Security Verification Standard based on the Mobile Security Testing Guide.<br />
|<br />
* [mailto:sven.schleier@owasp.org Sven Schleier]<br />
* [mailto:jeroen.willemsen@owasp.org Jeroen Willemsen]<br />
|-<br />
|iGoat Tool Project<br />
|[[OWASP iGoat Project|Project Page]]<br />
|A learning tool for iOS developers (iPhone, iPad, etc.). It was inspired by the WebGoat project, and has a similar conceptual flow to it.<br />
|<br />
* [mailto:swaroop.yermalkar@owasp.org Swaroop Yermalkar]<br />
|-<br />
|Damn Vulnerable iOS Application<br />
|[[OWASP DVIA|Project Page]]<br />
|An iOS application that is damn vulnerable. Its main goal is to provide a platform to mobile security enthusiasts/professionals or students to test their iOS penetration testing skills in a legal environment.<br />
|<br />
* [https://twitter.com/prateekg147 Prateek Gianchandani]<br />
|-<br />
|Android CK project<br />
|[[Projects/OWASP Androick Project|Project Page]]<br />
|A python tool to help in forensics analysis on android.<br />
| <br />
* [https://twitter.com/phonesec Florian Pradines]<br />
|-<br />
|Seraphimdroid<br />
|[[OWASP SeraphimDroid Project|Project Page]]<br />
|A privacy and security protection app for Android devices.<br />
|<br />
* [mailto:nikola.milosevic@owasp.org Nikola Milosevic]<br />
* [mailto:kartik.kholi@owasp.org Kartik Kholi]<br />
<br />
|}<br />
<br />
Not what you are looking for? Please have a look at the '''[https://www.owasp.org/index.php/Mobile_Security_Project_Archive Mobile Security Page Archive]''' <br />
<br />
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE -->| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
== Project details ==<br />
<br />
=== Email List ===<br />
[[Image:Asvs-bulb.jpg]] [https://groups.google.com/a/owasp.org/forum/#!forum/owasp-mobile-top-10-risks Project Email List]<br />
<br />
=== Other active OWASP mobile projects ===<br />
* [[OWASP Mobile Security Testing Guide|OWASP Mobile Security Testing Guide]]<br />
* [[OWASP Mobile Security Testing Guide|OWASP Mobile Application Security Verification Standard]]<br />
* [[OWASP iGoat Tool Project]]<br />
* [[OWASP DVIA|Damn Vulnerable iOS Application]]<br />
* [[Projects/OWASP Androick Project|AndroidCK project]]<br />
* [[OWASP SeraphimDroid Project|OWASP SeraphimDroid]]<br />
==Project Leaders==<br />
{{Template:Contact<br />
| name = Jonathan Carter<br />
| email = jonathan.carter@owasp.org<br />
}}<br />
<br />
{{Template:Contact<br />
| name = Milan Singh Thakur<br />
| email = milan@owasp.org<br />
| username = Milan Singh Thakur<br />
}}<br />
<br />
|}<br />
<br />
= Top 10 Mobile Risks =<br />
<br />
Please visit the [https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks project page] for current information. <br />
<br />
== About this list ==<br />
In 2015, we performed a survey and initiated a Call for Data submission Globally . This helped us to analyze and re-categorize the OWASP Mobile Top Ten for 2016. So the top ten categories are now more focused on Mobile application rather than Server.<br />
<br />
Our goals for the 2016 list included the following:<br />
<br />
* Updates to the wiki content; including cross-linking to testing guides, more visual exercises, etc;<br />
* Generation of more data; and<br />
* A PDF release.<br />
<br />
This list has been finalized after a 90-day feedback period from the community. Based on feedback, we have released a Mobile Top Ten 2016 list following a similar approach of collecting data, grouping the data in logical and consistent ways.<br />
<br />
Feel free to visit [https://groups.google.com/a/owasp.org/forum/#!forum/owasp-mobile-top-10-risks the mailing list] as well!<br />
<br />
== Top 10 Mobile Risks - Final List 2016 ==<br />
*[[Mobile_Top_10_2016-M1-Improper_Platform_Usage|M1: Improper Platform Usage]]<br />
*[[Mobile_Top_10_2016-M2-Insecure_Data_Storage|M2: Insecure Data Storage]]<br />
*[[Mobile_Top_10_2016-M3-Insecure_Communication|M3: Insecure Communication]]<br />
*[[Mobile_Top_10_2016-M4-Insecure_Authentication|M4: Insecure Authentication]]<br />
*[[Mobile_Top_10_2016-M5-Insufficient_Cryptography|M5: Insufficient Cryptography]]<br />
*[[Mobile_Top_10_2016-M6-Insecure_Authorization|M6: Insecure Authorization]]<br />
*[[Mobile_Top_10_2016-M7-Poor_Code_Quality|M7: Client Code Quality]]<br />
*[[Mobile_Top_10_2016-M8-Code_Tampering|M8: Code Tampering]]<br />
*[[Mobile_Top_10_2016-M9-Reverse_Engineering|M9: Reverse Engineering]]<br />
*[[Mobile_Top_10_2016-M10-Extraneous_Functionality|M10: Extraneous Functionality]]<br />
<br />
== Top 10 Mobile Risks - Final List 2014 ==<br />
[[File:2014-01-26 20-23-29.png|right|550px]]<br />
*[[Mobile_Top_10_2014-M1|M1: Weak Server Side Controls]] <br />
*[[Mobile_Top_10_2014-M2|M2: Insecure Data Storage]]<br />
*[[Mobile_Top_10_2014-M3|M3: Insufficient Transport Layer Protection]]<br />
*[[Mobile_Top_10_2014-M4|M4: Unintended Data Leakage]]<br />
*[[Mobile_Top_10_2014-M5|M5: Poor Authorization and Authentication]]<br />
*[[Mobile_Top_10_2014-M6|M6: Broken Cryptography]]<br />
*[[Mobile_Top_10_2014-M7|M7: Client Side Injection]]<br />
*[[Mobile_Top_10_2014-M8|M8: Security Decisions Via Untrusted Inputs]]<br />
*[[Mobile_Top_10_2014-M9|M9: Improper Session Handling]]<br />
*[[Mobile_Top_10_2014-M10|M10: Lack of Binary Protections]]<br />
<br />
== Project Methodology ==<br />
<br />
* '''We adhered loosely to the [https://www.owasp.org/index.php/Top_10_2013/ProjectMethodology OWASP Web Top Ten Project methodology]. '''<br />
<br />
== Archive ==<br />
* The list below is the OLD release candidate v1.0 of the OWASP Top 10 Mobile Risks. &nbsp;This list was initially released on September 23, 2011 at Appsec USA. &nbsp;<br />
** The original presentation can be found here:&nbsp;[http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks SLIDES]<br> <br />
** The corresponding video can be found here: [http://www.youtube.com/watch?v=GRvegLOrgs0 VIDEO]<br />
** [[Mobile_Top_10_2012|2011-12 Mobile Top Ten for archive purposes]]<br />
<br />
= Mobile Security Testing Guide =<br />
<br />
Please see the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide project page] for more details.<br />
<br />
=Acknowledgements =<br />
<br />
The OWASP Mobile Security project has a long history. It has been a source for many projects their predecessors as is clearly visible in [https://www.owasp.org/index.php/Mobile_Security_Project_Archive the archive]. <br />
== Project Leaders ==<br />
{{Template:Contact<br />
| name = Jonathan Carter<br />
| email = jonathan.carter@owasp.org<br />
}}<br /><br />
{{Template:Contact<br />
| name = Milan Singh Thakur<br />
| email = milan@owasp.org<br />
| username = Milan Singh Thakur<br />
}}<br /><br />
<br />
== Former Leaders ==<br />
{{Template:Contact | name = Mike Zusman<br />
| email = mike.zusman@owasp.org<br />
| username = schmoilito }}<br /><br />
{{Template:Contact<br />
| name = Tony DeLaGrange<br />
| email = mobisec@secureideas.net<br />
| username = Tony DeLaGrange<br />
}}<br /><br />
{{Template:Contact<br />
| name = Sarath Geethakumar<br />
| email = sarath.geethakumar@owasp.org<br />
| username = Sarath Geethakumar<br />
}}<br /><br />
{{Template:Contact<br />
| name = Tom Eston<br />
| email = teston@veracode.com<br />
| username = Tom Eston<br />
}}<br /><br />
{{Template:Contact<br />
| name = Don Williams<br />
}}<br /><br />
{{Template:Contact<br />
| name = Jason Haddix<br />
| email = jason.haddix@hp.com<br />
| username = Jason Haddix<br />
}}<br /><br />
<br />
== Top Contributors ==<br />
{{Template:Contact<br />
| name = Zach Lanier<br />
| email = zach.lanier@n0where.org<br />
| username = Zach_Lanier<br />
}}<br /><br />
{{Template:Contact<br />
| name = Ludovic Petit<br />
| email = ludovic.petit@owasp.org<br />
| username = Ludovic Petit<br />
}}<br /><br />
{{Template:Contact<br />
| name = Swapnil Deshmukh<br />
| email = sd.swapz@gmail.com<br />
| username = Swapnil Deshmukh<br />
}}<br /><br />
{{Template:Contact<br />
| name = Beau Woods<br />
| email = owasp@beauwoods.com<br />
| username = Beau Woods<br />
}}<br /><br />
{{Template:Contact<br />
| name = David Martin Aaron<br />
| email = davidmartinaaron@gmail.com<br />
| username = David Martin Aaron<br />
}}<br /><br />
{{Template:Contact<br />
| name = Luca De Fulgentis<br />
| email = luca@securenetwork.it<br />
| username = Daath<br />
}}<br /><br />
{{Template:Contact<br />
| name = Andrew Pannell<br />
| email = andrew.pannell@owasp.org<br />
| username = Andipannell<br />
}}<br /><br />
{{Template:Contact<br />
| name = Stephanie V<br />
| email = vanroelens@gmail.com<br />
| username = Stephanie V<br />
}}<br /><br />
<br />
= Secure M-Development =<br />
'''Secure Mobile Development Guidelines Objective'''<br />
<br />
The OWASP Secure Development Guidelines provides developers with the knowledge they need to build secure mobile applications. An extendable framework will be provided that includes the core security flaws found across nearly all mobile platforms. It will be a living reference where contributors can plug in newly exposed APIs for various platforms and provide good/bad code examples along with remediation guidance for those issues.<br />
<br />
== Mobile Application Coding Guidelines ==<br />
The purpose of this section is to provide application developers guidelines on how to build secure mobile applications, given the differences in security threat between applications running on a typical desktop as compared to those running on a mobile device (such as tablets or cell phones). <br />
<br />
Using the guidance provided here, developers should code their applications to mitigate these malicious attacks. While more general coding guidelines should still be followed as applicable, this page lists additional considerations and/or modifications to common guidelines and is written using the best knowledge available at this time.<br />
<br />
=== Authentication and Password Management ===<br />
This is a set of controls used to verify the identity of a user, or other entity, interacting with the software, and also to ensure that applications handle the management of passwords in a secure fashion.<br />
<ol type="a"><br />
<li> Instances where the mobile application requires a user to create a password or PIN (say for offline access), the application should never use a PIN but enforce a password which follows a strong password policy.<br />
<li> Mobile devices may offer the possibility of using password patterns which are never to be utilized in place of passwords as sufficient entropy cannot be ensured and they are easily vulnerable to smudge-attacks.<br />
<li> Mobile devices may also offer the possibility of using biometric input to perform authentication which should never be used due to issues with false positives/negatives, among others.<br />
<li> Wipe/clear memory locations holding passwords directly after their hashes are calculated.<br />
<li> Based on risk assessment of the mobile application, consider utilizing two-factor authentication.<br />
<li> For device authentication, avoid solely using any device-provided identifier (like UID or MAC address) to identify the device, but rather leverage identifiers specific to the application as well as the device (which ideally would not be reversible). For instance, create an app-unique “device-factor” during the application install or registration (such as a hashed value which is based off of a combination of the length of the application package file itself, as well as the current date/time, the version of the OS which is in use, and a randomly generated number). In this manner the device could be identified (as no two devices should ever generate the same “device-factor” based on these inputs) without revealing anything sensitive. This app-unique device-factor can be used with user authentication to create a session or used as part of an encryption key.<br />
<li> In scenarios where offline access to data is needed, add an intentional X second delay to the password entry process after each unsuccessful entry attempt (2 is reasonable, also consider a value which doubles after each incorrect attempt).<br />
<li> In scenarios where offline access to data is needed, perform an account/application lockout and/or application data wipe after X number of invalid password attempts (10 for example).<br />
<li> When utilizing a hashing algorithm, use only a NIST approved standard such as SHA-2 or an algorithm/library.<br />
<li> Salt passwords on the server-side, whenever possible. The length of the salt should at least be equal to, if not bigger than the length of the message digest value that the hashing algorithm will generate. <br />
<li> Salts should be sufficiently random (usually requiring them to be stored) or may be generated by pulling constant and unique values off of the system (by using the MAC address of the host for example or a device-factor; see 3.1.2.g.). Highly randomized salts should be obtained via the use of a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). When generating seed values for salt generation on mobile devices, ensure the use of fairly unpredictable values (for example, by using the x,y,z magnetometer and/or temperature values) and store the salt within space available to the application.<br />
<li> Provide feedback to users on the strength of passwords during their creation.<br />
<li> Based on a risk evaluation, consider adding context information (such as IP location, etc…) during authentication processes in order to perform Login Anomaly Detection.<br />
<li> Instead of passwords, use industry standard authorization tokens (which expire as frequently as practicable) which can be securely stored on the device (as per the OAuth model) and which are time bounded to the specific service, as well as revocable (if possible server side).<br />
<li> Integrate a CAPTCHA solution whenever doing so would improve functionality/security without inconveniencing the user experience too greatly (such as during new user registrations, posting of user comments, online polls, “contact us” email submission pages, etc…).<br />
<li> Ensure that separate users utilize different salts.<br />
</ol><br />
<br />
=== Code Obfuscation ===<br />
This is a set of controls used to prevent reverse engineering of the code, increasing the skill level and the time required to attack the application.<br />
<br />
<ol type="a"><br />
<li>Abstract sensitive software within static C libraries.<br />
<li> Obfuscate all sensitive application code where feasible by running an automated code obfuscation program using either 3rd party commercial software or open source solutions.<br />
<li> For applications containing sensitive data, implement anti-debugging techniques (e.g. prevent a debugger from attaching to the process; android:debuggable=”false”).<br />
<li> Ensure logging is disabled as logs may be interrogated other applications with readlogs permissions (e.g. on Android system logs are readable by any other application prior to being rebooted).<br />
<li> So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken advantage of to hide executable code which could be used to remotely exploit the application and hinder the dumping of application’s memory.<br />
</ol><br />
<br />
=== Communication Security ===<br />
This is a set of controls to help ensure the software handles the sending and receiving of information in a secure manner.<br />
<br />
<ol type="a"><br />
<li>Assume the provider network layer is insecure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee a Wi-Fi network (if in-use by the mobile device) will be appropriately encrypted.<br />
<li> Ensure the application actually and properly validates (by checking the expiration date, issuer, subject, etc…) the server’s SSL certificate (instead of checking to see if a certificate is simply present and/or just checking if the hash of the certificate matches). To note, there are third party libraries to assist in this; search on “certificate pinning”.<br />
<li> The application should only communicate with and accept data from authorized domain names/systems. It is permissible to allow application updates which will modify the list of authorized systems and/or for authorized systems to obtain a token from an authentication server, present a token to the client which the client will accept.<br />
<li> To protect against attacks which utilize software such as SSLStrip, implement controls to detect if the connection is not HTTPS with every request when it is known that the connection should be HTTPS (e.g. use JavaScript, Strict Transport Security HTTP Header, disable all HTTP traffic).<br />
<li> The UI should make it as easy as possible for the user to find out if a certificate is valid (so the user is not totally reliant upon the application properly validating any certificates). <br />
<li> When using SSL/TLS, use certificates signed by trusted Certificate Authority (CA) providers.<br />
</ol><br />
<br />
=== Data Storage and Protection ===<br />
This is a set of controls to help ensure the software handles the storing and handling of information in a secure manner. Given that mobile devices are mobile, they have a higher likelihood of being lost or stolen which should be taken into consideration here. <br />
<br />
<ol type="a"><br />
<li>Only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.<br />
<li> Classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification<br />
<li> Store sensitive data on the server instead of the client-end device, whenever possible. Assume any data written to device can be recovered.<br />
<li> Beyond the time required by the application, don’t store sensitive information on the device (e.g. GPS/tracking).<br />
<li> Do not store temp/cached data in a world readable directory. Assume shared storage is untrusted.<br />
<li> Encrypt sensitive data when storing or caching it to non-volatile memory (using a NIST approved encryption standard such as AES-256, 3DES, or Skipjack).<br />
<li> Use the PBKDF2 function to generate strong keys for encryption algorithms while ensuring high entropy as much as possible. The number of iterations should be set as high as may be tolerated for the environment (with a minimum of 1000 iterations) while maintaining acceptable performance.<br />
<li> Sensitive data (such as encryption keys, passwords, credit card #’s, etc…) should stay in RAM for as little time as possible.<br />
<li> Encryption keys should not remain in RAM during the instance lifecycle of the app. Instead, keys should be generated real time for encryption/decryption as needed and discarded each time.<br />
<li> So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken advantage of to limit the impact of attacks such as buffer overflows.<br />
<li> Do not store sensitive data in the keychain of iOS devices due to vulnerabilities in their cryptographic mechanisms.<br />
<li> Ensure that sensitive data (e.g. passwords, keys etc.) are not visible in cache or logs.<br />
<li> Never store any passwords in clear text within the native application itself nor on the browser (e.g. save password feature on the browser).<br />
<li> When displaying sensitive information (such as full account numbers), ensure that the sensitive information is cleared from memory (such as from the webView) when no longer needed/displayed.<br />
<li> Do not store sensitive information in the form of typical strings. Instead use character arrays or NSMutableString (iOS specific) and clear their contents after they are no longer needed. This is because strings are typically immutable on mobile devices and reside within memory even when assigned (pointed to) a new value.<br />
<li> Do not store sensitive data on external storage like SD cards if it can be avoided.<br />
<li> Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within 100m of car etc...).<br />
<li> Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier, use a randomly generated number instead.<br />
<li> Make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss.<br />
<li> Use a time based (expiry) type of control which will wipe sensitive data from the mobile device once the application has not communicated with its servers for a given period of time.<br />
<li> Automatic application shutdown and/or lockout after X minutes of inactivity (e.g. 5 mins of inactivity).<br />
<li> Avoid cached application snapshots in iOS: iOS can capture and store screen captures and store them as images when an application suspends. To avoid any sensitive data getting captured, use one or both of the following options: 1. Use the ‘willEnterBackground’ callback, to hide all the sensitive data. 2. Configure the application in the info.plist file to terminate the app when pushed to background (only use if multitasking is disabled).<br />
<li> Prevent applications from being moved and/or run from external storage such as via SD cards.<br />
<li> When handling sensitive data which does not need to be presented to users (e.g. account numbers), instead of using the actual value itself, use a token which maps to the actual value on the server-side. This will prevent exposure of sensitive information.<br />
</ol><br />
<br />
=== Paywall Controls ===<br />
This is a set of practices to ensure the application properly enforces access controls related to resources which require payment in order to access (such as access to premium content, access to additional functionality, access to improved support, etc…). <br />
<br />
<ol type="a"><br />
<li> Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a trusted server backend – with user consent) and make them securely available to the end-user for monitoring.<br />
<li> Warn users and obtain consent for any cost implications for application behavior.<br />
<li> Secure account/pricing/billing/item information as it relates to users. If client has made any purchases via the application for instance, we should ensure that what they bought, the size of purchase, the quantity of the purchase, etc… should all be treated as sensitive information.<br />
<li> Use a white-list model by default for paid-for resource addressing.<br />
<li> Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g. significant change in location occurs, user-language changes, etc...<br />
</ol><br />
<br />
=== Server Controls ===<br />
This is a set of practices to ensure the server side program which interfaces with the mobile application is properly safeguarded. These controls would also apply in cases where the mobile application may be integrating with vended solutions hosted outside of the typical network.<br />
<br />
<ol type="a"><br />
<li> Ensure that the backend system(s) are running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.<br />
<li> Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).<br />
<li> Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DoS type of attacks.<br />
<li> Carry out a specific check of your code for any sensitive data unintentionally transferred between the mobile application and the back-end servers, and other external interfaces (e.g. is location or other information included transmissions?).<br />
<li> Ensure the server rejects all unencrypted requests which it knows should always arrive encrypted.<br />
</ol><br />
<br />
=== Session Management ===<br />
This is a set of controls to help ensure mobile applications handle sessions in a secure manner.<br />
<br />
<ol type="a"><br />
<li> Perform a check at the start of each activity/screen to see if the user is in a logged in state and if not, switch to the login state.<br />
<li> When an application’s session is timed out, the application should discard and clear all memory associated with the user data, and any master keys used to decrypt the data.<br />
<li> Session tokens should be revocable (particularly on the server side).<br />
<li> Use lower timeout values to invalidate expired sessions (in contrast to the typical timeout values on traditional (non-mobile) applications).<br />
</ol><br />
<br />
=== Use of 3rd Party Libraries/Code ===<br />
This is a set of practices to ensure the application integrates securely with code produced from outside parties.<br />
<br />
<ol type="a"><br />
<li>Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, will continue to be supported, contain no backdoors) and ensure that adequate internal approval is obtained to use the code/library.<br />
<li> Track all third party frameworks/API’s used in the mobile application for security patches and perform upgrades as they are released.<br />
<li> Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before incorporating their use into an application.<br />
</ol><br />
<br />
== Mobile Application Provisioning/Distribution/Testing ==<br />
This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities, that there are mechanisms to report new security issues if they are found, and also that the software has been designed to accept patches in order to address potential security issues. <br />
<br />
<ol type="a"><br />
<li> Design & distribute applications to allow updates for security patches.<br />
<li> Provide & advertise feedback channels for users to report security problems with applications (such as a MobileAppSecurity@ntrs.com email address).<br />
<li> Ensure that older versions of applications which contain security issues and are no longer supported are removed from app-stores/app-repositories.<br />
<li> Periodically test all backend services (Web Services/REST) which interact with a mobile application as well as the application itself for vulnerabilities using enterprise approved automatic or manual testing tools (including internal code reviews).<br />
<li> Based on risk assessment of the application, have the application go through Security Assessment for a review of security vulnerabilities following the Team’s internal security testing of the application.<br />
<li> Utilize the Enterprise provisioning process (e.g. IDM) to request and approve access for users on the mobile application.<br />
<li> Ensure the application is sufficiently obfuscated prior to release by conducting tests which attempt to reverse engineer the obfuscated application.<br />
<li> Distribute applications via an app-store type of interface (when appropriate) as many app-stores monitor applications for insecure code which we may benefit from.<br />
<li> Digitally sign applications using a code signing certificate obtained via a trusted Certificate Authority (CA).<br />
</ol><br />
<br />
= Top 10 Mobile Controls =<br />
==OWASP/ENISA Collaboration==<br />
<br />
OWASP and the European Network and Information Security Agency (ENISA) collaborated to build a joint set of controls. ENISA has published the results of the collaborative effort as the "Smartphone Secure Development Guideline", which is published in 2011 at: https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines/at_download/fullReport. In 2017, an update was published by ENISA at https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines-2016.<br />
<br />
[[File:OWASP_Mobile_Top_10_Controls.jpg|center|800px]]<br />
<br />
==Contributors==<br />
<br />
This document has been jointly produced with ENISA as well as the following individuals:<br />
*Vinay Bansal, Cisco Systems<br />
*Nader Henein, Research in Motion<br />
*Giles Hogben, ENISA<br />
*Karsten Nohl, Srlabs<br />
*Jack Mannino, nVisium Security<br />
*Christian Papathanasiou, Royal Bank of Scotland<br />
*Stefan Rueping, Infineon<br />
*Beau Woods, Stratigos Security<br />
<br />
== Top 10 mobile controls and design principles==<br />
<br />
'''[[#section control_1|1. Identify and protect sensitive data on the mobile device]]'''<br />
<br />
'''Risks:''' Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on the device.<br />
<br />
*1.1 In the design phase, classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification. Validate the security of API calls applied to sensitive data.<br />
*1.2 Store sensitive data on the server instead of the client-end device. This is based on the assumption that secure network connectivity is sufficiently available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment (3) or the OWASP Cloud top 10 (4) for decision support).<br />
*1.3 When storing data on the device, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption APIs which use a secret key protected by the device unlock code and deleteable on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden on the end-user. It also makes stored data safer in the case of loss or theft. However, it should be born in mind that even when protected by the device unlock key, if data is stored on the device, its security is dependent on the security of the device unlock code if remote deletion of the key is for any reason not possible.<br />
*1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see control 2).<br />
*1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within 100m of car etc...).<br />
*1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see controls 1.7, 1.8).<br />
*1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:<br />
**Be aware of caches and temporary storage as a possible leakage channel, when shared with other apps.<br />
**Be aware of public shared storage such as address book, media gallery and audio files as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.<br />
**Do not store temp/cached data in a world readable directory.<br />
*1.8 For sensitive personal data, deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).<br />
*1.9 There is currently no standard secure deletion procedure for flash memory (unless wiping the entire medium/card). Therefore data encryption and secure key management are especially important.<br />
*1.10 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc)<br />
*1.11 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.<br />
*1.12 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (use a randomly generated number – see 4.3). Apply the same data minimization principles to app sessions as to http sessions/cookies etc.<br />
*1.13 Applications on managed devices should make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss. (A kill-switch is the term used for an OS-level or purpose-built means of remotely removing applications and/or data).<br />
*1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).<br />
<br />
'''2. Handle password credentials securely on the device'''<br />
<br />
'''Risks:''' Spyware, surveillance, financial malware. A user's credentials, if stolen, not only provide unauthorized access to the mobile backend service, they also potentially compromise many other services and accounts used by the user. The risk is increased by the widespread of reuse of passwords across different services.<br />
<br />
*2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device (as per the OAuth model). Encrypt the tokens in transit (using SSL/TLS). Tokens can be issued by the backend service after verifying<br />
Smartphones secure development guidelines for app developers the user credentials initially. The tokens should be time bounded to the specific service as well as revocable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire as frequently as practicable.<br />
*2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate hashing or encryption.<br />
*2.3 Some devices and add-ons allow developers to use a Secure Element e.g. (5) (6) – sometimes via an SD card module - the number of devices offering this functionality is likely to increase. Developers should make use of such capabilities to store keys, credentials and other sensitive data. The use of such secure elements gives a higher level of assurance with the standard encrypted SD card certified at FIPS 140-2 Level 3. Using the SD cards as a second factor of authentication though possible, isn't recommended, however, as it becomes a pseudo-inseparable part of the device once inserted and secured.<br />
*2.4 Provide the ability for the mobile user to change passwords on the device.<br />
*2.5 Passwords and credentials should only be included as part of regular backups in encrypted or hashed form.<br />
*2.6 Smartphones offer the possibility of using visual passwords which allow users to memorize passwords with higher entropy. These should only be used however, if sufficient entropy can be ensured. (7)<br />
*2.7 Swipe-based visual passwords are vulnerable to smudge-attacks (using grease deposits on the touch screen to guess the password). Measures such as allowing repeated patterns should be introduced to foil smudge-attacks. (8)<br />
*2.8 Check the entropy of all passwords, including visual ones (see 4.1 below).<br />
*2.9 Ensure passwords and keys are not visible in cache or logs.<br />
*2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration with the backend (like password embedded in code). Mobile application binaries can be easily downloaded and reverse engineered.<br />
<br />
'''3. Ensure sensitive data is protected in transit'''<br />
<br />
'''Risks:''' Network spoofing attacks, surveillance. The majority of smartphones are capable of using multiple network mechanisms including Wi-Fi, provider network (3G, GSM, CDMA and others), Bluetooth etc. Sensitive data passing through insecure channels could be intercepted. (9) (10)<br />
<br />
*3.1 Assume that the provider network layer is not secure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the Wi-Fi network will be appropriately encrypted.<br />
*3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information over the wire/air (e.g. using Strict Transport Security - STS (11)).This includes passing user credentials, or other authentication equivalents. This provides confidentiality and integrity protection.<br />
*3.3 Use strong and well-known encryption algorithms (e.g. AES) and appropriate key lengths (check current recommendations for the algorithm you use e.g. (12) page 53).<br />
*3.4 Use certificates signed by trusted CA providers. Be very cautious in allowing self- signed certificates. Do not disable or ignore SSL chain validation.<br />
*3.5 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with end-points having the trusted certificates in the key chain.<br />
*3.6 The user interface should make it as easy as possible for the user to find out if a certificate is valid.<br />
*3.7 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end-points.<br />
<br />
'''Reference:''' Google vulnerability of Client Login account credentials on unprotected wifi - [http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]<br />
<br />
'''4. Implement user authentication,authorization and session management correctly'''<br />
<br />
'''Risks:''' Unauthorized individuals may obtain access to sensitive data or systems by circumventing authentication systems (logins) or by reusing valid tokens or cookies. (13)<br />
<br />
*4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the sensitivity of the data being processed by the application and its access to valuable resources (e.g. costing money).<br />
*4.2 It is important to ensure that the session management is handled correctly after the initial authentication, using appropriate secure protocols. For example, require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).<br />
*4.3 Use unpredictable session identifiers with high entropy. Note that random number generators generally produce random but predictable output for a given seed (i.e. the same sequence of random numbers is produced for each seed). Therefore it is important to provide an unpredictable seed for the random number generator. The standard method of using the date and time is not secure. It can be improved, for example using a combination of the date and time, the phone temperature sensor and the current x,y and z magnetic fields. In using and combining these values, well-tested algorithms which maximise entropy should be chosen (e.g. repeated application of SHA1 may be used to combine random variables while maintaining maximum entropy – assuming a constant maximum seed length).<br />
*4.4 Use context to add security to authentication - e.g. IP location, etc...<br />
*4.5 Where possible, consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc.<br />
*4.6 Use authentication that ties back to the end user identity (rather than the device identity).<br />
<br />
'''5. Keep the backend APIs (services) and the platform (server) secure''' <br />
<br />
'''Risks:''' Attacks on backend systems and loss of data via cloud storage. The majority of mobile applications interact with the backend APIs using REST/Web Services or proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow attackers to compromise data on the mobile device when transferred to the backend, or to attack the backend through the mobile application. (14)<br />
<br />
*5.1 Carry out a specific check of your code for sensitive data unintentionally transferred, any data transferred between the mobile device and web-server back- ends and other external interfaces - (e.g. is location or other information included within file metadata).<br />
*5.2 All backend services (Web Services/REST) for mobile apps should be tested for vulnerabilities periodically, e.g. using static code analyser tools and fuzzing tools for testing and finding security flaws.<br />
*5.3 Ensure that the backend platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.<br />
*5.4 Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).<br />
*5.5 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.<br />
*5.6 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.<br />
*5.7 Web Services, REST and APIs can have similar vulnerabilities to web applications:<br />
**Perform abuse case testing, in addition to use case testing<br />
**Perform testing of the backend Web Service, REST or API to determine vulnerabilities.<br />
<br />
'''6. Secure data integration with third party services and applications'''<br />
<br />
'''Risks:''' Data leakage. Users may install applications that may be malicious and can transmit personal data (or other sensitive stored data) for malicious purposes.<br />
<br />
*6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, with maintenance supported, no backend Trojans)<br />
*6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.<br />
*6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing within the application.<br />
<br />
'''7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data'''<br />
<br />
'''Risks:''' Unintentional disclosure of personal or private information, illegal data processing. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII). (15) (16)<br />
<br />
*7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.<br />
*7.2 Consent may be collected in three main ways:<br />
**At install time<br />
**At run-time when data is sent<br />
**Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.<br />
*7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent unique identifiers linked to central data stores containing personal information?<br />
*7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).<br />
*7.5 Keep a record of consent to the transfer of PII. This record should be available to the user (consider also the value of keeping server-side records attached to any user data stored). Such records themselves should minimise the amount of personal data they store (e.g. using hashing).<br />
*7.6 Check whether your consent collection mechanism overlaps or conflicts (e.g. in the data handling practices stated) with any other consent collection within the same stack (e.g. APP-native + webkit HTML) and resolve any conflicts.<br />
<br />
'''8. Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc.)'''<br />
'''Risks:''' Smartphone apps give programmatic (automatic) access to premium rate phone calls, SMS, roaming data, NFC payments, etc. Apps with privileged access to such API’s should take particular care to prevent abuse, considering the financial impact of vulnerabilities that giveattackers access to the user’s financial resources.<br />
<br />
*8.1 Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a trusted server backend – with user consent) and make them available to the end-user for monitoring. Logs should be protected from unauthorised access.<br />
*8.2 Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g. when significant change in location occurs, user-language changes etc.<br />
*8.3 Consider using a white-list model by default for paid-for resource addressing - e.g. address book only unless specifically authorised for phone calls.<br />
*8.4 Authenticate all API calls to paid-for resources (e.g. using an app developer certificate).<br />
*8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.<br />
*8.6 Warn user and obtain consent for any cost implications for app behaviour.<br />
*8.7 Implement best practices such as fast dormancy (a 3GPP specification), caching, etc. to minimize signalling load on base stations.<br />
<br />
'''9. Ensure secure distribution/provisioning of mobile applications'''<br />
<br />
'''Risks:''' Use of secure distribution practices is important in mitigating all risks described in the OWASP Mobile Top 10 Risks and ENISA top 10 risks.<br />
*9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.<br />
*9.2 Most app-stores monitor apps for insecure code and are able to remotely remove apps at short notice in case of an incident. Distributing apps through official app- stores therefore provides a safety-net in case of serious vulnerabilities in your app.<br />
*9.3Provide feedback channels for users to report security problems with apps – e.g. a security@ email address.<br />
<br />
'''10. Carefully check any runtime interpretation of code for errors '''<br />
<br />
'''Risks:''' Runtime interpretation of code may give an opportunity for untrusted parties to provide unverified input which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls provided by app-stores. It can lead to injection attacks leading to Data leakage, surveillance, spyware, and diallerware.<br />
<br />
Note that it is not always obvious that your code contains an interpreter. Look for any capabilities accessible via user-input data and use of third party API’s which may interpret user-input - e.g. JavaScript interpreters.<br />
<br />
*10.1 Minimize runtime interpretation and capabilities offered to runtime interpreters: run interpreters at minimal privilege levels.<br />
*10.2 Define comprehensive escape syntax as appropriate.<br />
*10.3 Fuzz test interpreters.<br />
*10.4 Sandbox interpreters.<br />
<br />
''Appendix A- Relevant General Coding Best Practices'''<br />
<br />
Some general coding best practices are particularly relevant to mobile coding. We have listed some of the most important tips here:<br />
**Perform abuse case testing, in addition to use case testing.<br />
**Validate all input.<br />
**Minimise lines and complexity of code. A useful metric is cyclomatic complexity (17).<br />
**Use safe languages (e.g. from buffer-overflow).<br />
**Implement a security report handling point (address) security@example.com<br />
**Use static and binary code analysers and fuzz-testers to find security flaws.<br />
**Use safe string functions, avoid buffer and integer overflow.<br />
**Run apps with the minimum privilege required for the application on the operating<br />
system. Be aware of privileges granted by default by APIs and disable them.<br />
**Don't authorize code/app to execute with root/system administrator privilege<br />
**Always perform testing as a standard as well as a privileged user<br />
**Avoid opening application-specific server sockets (listener ports) on the client device.<br />
Use the communication mechanisms provided by the OS.<br />
**Remove all test code before releasing the application<br />
**Ensure logging is done appropriately but do not record excessive logs, especially those<br />
including sensitive user information.<br />
<br />
<br />
''Appendix B- Enterprise Guidelines''<br />
**If a business-sensitive application needs to be provisioned on a device, applications should enforce of a higher security posture on the device (such as PIN, remote management/wipe, app monitoring)<br />
**Device certificates can be used for stronger device authentication.'<br />
<br />
''References"''<br />
*1.ENISA. Top Ten Smartphone Risks . [Online] http://www.enisa.europa.eu/act/application-security/smartphone-security-1/top-ten-risks.<br />
*2. OWASP. Top 10 mobile risks. [Online] https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks.<br />
*3. Cloud Computing: Benefits, Risks and Recommendations for information security. [Online] 2009. http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment.<br />
*4. OWASP Cloud Top 10. [Online] https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project.<br />
*5. Blackberry developers documents. [Online] http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.h tml,.<br />
*6. Google Seek For Android. [Online] http://code.google.com/p/seek-for-android/.<br />
*7. Visualizing Keyboard Pattern Passwords. [Online] cs.wheatoncollege.edu/~mgousie/comp401/amos.pdf.<br />
*8. Smudge Attacks on Smartphone Touch Screens. Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M. Smith. s.l. : Department of Computer and Information Science – University of Pennsylvania.<br />
*9. Google vulnerability of Client Login account credentials on unprotected . [Online] http://www.uni- ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html.<br />
*10. SSLSNIFF. [Online] http://blog.thoughtcrime.org/sslsniff-anniversary-edition. 11. [Online] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02.<br />
Smartphones secure development guidelines for app developers<br />
*11. [Online] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02.<br />
*12. NIST Computer Security. [Online] http://csrc.nist.gov/publications/nistpubs/800-57/sp800- 57_PART3_key-management_Dec2009.pdf.<br />
*13. Google's ClientLogin implementation . [Online] http://www.uni- ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html.<br />
*14. [Online] https://www.owasp.org/index.php/Web_Services.<br />
*15. EU Data Protection Directive 95/46/EC. [Online] http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML.<br />
*16. [Online] http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11 _Spafford.pdf.<br />
*17. [Online] http://www.aivosto.com/project/help/pm-complexity.html.<br />
*18. [Online] http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html.<br />
**19. Google Wallet Security. [Online] http://www.google.com/wallet/how-it-works-security.htm.<br />
<br />
= M-Threat Model Project =<br />
==Mobile Application Threat Model - Beta Release==<br />
<br />
This is the first release (February 2013) of the Mobile Application Threat Model developed by the initial project team (listed at the end of this release). Development began mid-2011 and is being released in beta form for public comment and input. It is by no means complete and some sections will need more contributions, details and also real world case studies. It's the hope of the project team that others in the community can help contribute to this project to further enhance and improve this threat model.<br />
<br />
===Mobile Threat Model Introduction Statement===<br />
Threat modeling is a systematic process that begins with a clear understanding of the system. It is necessary to define the following areas to understand possible threats to the application:<br />
* '''Mobile Application Architecture''' - This area describes how the application is designed from device specific features used by the application, wireless transmission protocols, data transmission mediums, interaction with hardware components and other applications.<br />
* '''Mobile Data''' - What data does the application store and process? What is the business purpose of this data and what are the data workflows?<br />
* '''Threat Agent Identification''' - What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.<br />
* '''Methods of Attack''' - What are the most common attacks utilized by threat agents. This area defines these attacks so that controls can be developed to mitigate attacks.<br />
* '''Controls''' - What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.<br />
<br />
===Target Audience for the Mobile Threat Model===<br />
This model is to be used by mobile application developers and software architects as part of the “threat modeling” phase of a typical SDLC process. The model can also be used by Information Security Professionals that need to determine what typical mobile application threats are and provide a methodology for conducting basic threat modeling.<br />
<br />
===How to Use the Mobile Threat Model===<br />
This threat model is designed as an outline or checklist of items that need to be documented, reviewed and discussed when developing a mobile application. Every organization that develops mobile applications will have different requirements as well as threats. This model was designed to be as organizational and industry agnostic as possible so that any mobile application development team can use this as a guide for conducting threat modeling for their specific application. Real world case studies as examples will be integrated to this threat model in the near future.<br />
<br />
==Mobile Application Architecture==<br />
<br />
The mobile application architecture should, at the very least, describe device specific features used by the application, wireless transmission protocols, data transmission medium, interaction with hardware components and other applications. Applications can be mapped to this architecture as a preliminary attack surface assessment.<br />
<br />
===Architecture Considerations===<br />
<br />
Although mobile applications vary in function, they can be described using a generalized model as follows:<br />
<br />
Wireless interfaces<br />
<br />
Transmission Type<br />
<br />
Hardware Interaction<br />
<br />
Interaction with on device applications/services<br />
<br />
Interaction with off device applications/services<br />
<br />
Encryption Protocols<br />
<br />
<br />
<br />
* What is the design of the architecture (network infrastructure, web services, trust boundaries, third-party APIs, etc)<br />
** Carrier<br />
*** Data<br />
*** SMS<br />
*** Voice<br />
** Endpoints<br />
*** Web Services<br />
**** RESTful or SOAP based<br />
**** Third Party (Example: Amazon)<br />
*** Websites<br />
**** Does the app utilize or integrate the “mobile web” version of an existing web site?<br />
*** App Stores<br />
**** Google Play<br />
**** Apple App Store<br />
**** Windows Mobile<br />
**** BlackBerry App Store<br />
*** Cloud Storage<br />
**** Amazon/Azure<br />
*** Corporate Networks (via VPN, ssh, etc.)<br />
** Wireless interfaces<br />
*** 802.11<br />
*** NFC<br />
*** Bluetooth<br />
*** RFID<br />
** Device<br />
*** App Layer<br />
*** Runtime Environment (VM, framework dependencies, etc)<br />
*** OS Platform<br />
** Apple iOS<br />
** Android<br />
** Windows Mobile<br />
** BlackBerry<br />
*** Baseband<br />
* Common hardware components<br />
** GPS<br />
** Sensors (accelerometer)<br />
** Cellular Radios (GSM/CDMA/LTE)<br />
** Flash Memory<br />
** Removable Storage (i.e.- SD)<br />
** USB ports<br />
** Wireless Interfaces<br />
*** 802.11<br />
*** Bluetooth<br />
*** NFC<br />
*** RFID<br />
** Touch Screen<br />
** Hardware Keyboard<br />
** Microphone<br />
** Camera<br />
* Authentication<br />
** Method<br />
*** Knowledge based<br />
*** Token based<br />
*** Biometrics<br />
** Input Type<br />
*** Keyboard<br />
*** Touch screen<br />
*** Hardware peripheral<br />
** Decision Process<br />
*** Local (on device)<br />
*** Remote (off device)<br />
* Define app architecture relative to OS stack + security model<br />
** What should or shouldn't the app do?<br />
<br />
<br />
==Mobile Data==<br />
This section defines what purpose does the app serve from a business perspective and what data the app store, transmit and receive. It’s also important to review data flow diagrams to determine exactly how data is handled and managed by the application.<br />
<br />
* What is the business function of the app?<br />
* What data does the application store/process (provide data flow diagram)<br />
** This diagram should outline network, device file system and application data flows<br />
** How is data transmitted between third party API’s and app(s)<br />
** Are there different data handling requirements between different mobile platforms? (iOS/Android/Blackberry/Windows/J2ME) <br />
** Does the app use cloud storage APIs (Dropbox, Google Drive, iCloud, Lookout) for device data backups<br />
** Does personal data intermingle with corporate data?<br />
** Is there specific business logic built into the app to process data?<br />
* What does the data give you (or an attacker) access to<br />
** Data at Rest<br />
** Example: Do stored credentials provide authentication?<br />
** Data in Transit<br />
** Example: Do stored keys allow you to break crypto functions (data integrity)?<br />
* Third party data, is it being stored/transmitted?<br />
** What is the privacy requirements of user data<br />
** Example: UDID or Geolocation on iOS transmitted to 3rd party<br />
** Are there regulatory requirements to meet specific to user privacy?<br />
* How does other data on the device affect the app (sandboxing restrictions enforced?)<br />
** Example: Authentication credentials shared between apps<br />
* What is the impact of Jailbroken/Rooted vs Non Jailbroken/Rooted device and how this affects app data (can also relate to threat agent identification)<br />
<br />
<br />
==Threat Agent Identification==<br />
What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.<br />
<br />
===Identifying Threat Agents===<br />
<br />
The process of identifying a threat agent is very simple and have been mentioned in the below steps:<br />
<br />
'''S1''': Take the list of all sensitive data (or information to protect) listed down from Section 2 – Mobile Data<br />
<br />
'''S2:''' Make a list of all the ways to access this data<br />
<br />
'''S3:''' The medium used to access the same listed in S3 is the Threat Agent to be identified<br />
<br />
<br />
===Threat Agent Identification Example===<br />
<br />
Let us understand it in a better way using an example of a Financial Application (specifically a Banking Application). Following the process as mentioned above:<br />
<br />
'''S1:''' Sensitive data present in the application has been listed as: Beneficiary Details stored in some form in the Phone Application Memory and User Credentials used for authentication transmitted to the server.<br />
'''S2:''' List the various ways of accessing information:<br />
<br />
# Beneficiary Details:<br />
## A device user aiming to browse through the memory card / phone memory<br />
## An adversary using a jail broken phone; starts reading the content through putty/WinSCP via SSH<br />
## An adversary while sniffing the WiFi, traffic sniffs the content travelling through the network<br />
## Another malicious application while reading the phone memory contents, stumbles upon this data as the device is Jailbroken<br />
## Another application which is sending data through SMS sends this data.<br />
## A Web Application executing a script on the browser tries to get steal the phone memory and send it to its server.<br />
<br />
<br />
'''S3:''' From the above points, we list down the medium used:<br />
<br />
# Any user who has the device (Stolen device/ friend / etc)<br />
## Any malicious application (installed / Web based script)<br />
## An adversary sniffing the Wifi.<br />
## etc.<br />
<br />
<br />
From the above example you should have a clear picture on how to identify Threat Agents. Below is list of threat agents, which were identified while analyzing various commonly used applications.<br />
<br />
<br />
===Listing of Threat Agents - By Category===<br />
<br />
<br />
====Human Interaction====<br />
<br />
<br />
<br />
* '''Stolen Device User:''' A user who obtained unauthorized access to the device aiming to get hold of the memory related sensitive information belonging to the owner of the device.<br />
<br />
* '''Owner of the Device:''' A user who unwillingly has installed a malicious application on his phone which gains access to the device application memory.<br />
<br />
* '''Common WiFi Network User:''' This agent is aimed at any adversary intentionally or unintentionally sniffing the WiFi network used by a victim. This agent stumbles upon all the data transmitted by the victim device and may re-use it to launch further attacks.<br />
<br />
* '''Malicious Developer:''' A human user who has the intent of writing an application which not only provides a commonly known function like gaming / calculator / utility in the foreground but steal as much information from your device as possible in real-time and transmits it to the malicious user. This agent can also be looked at an angle from which he codes an app to perform DOS by using up all the device resources.<br />
<br />
* '''Organization Internal Employees:''' Any user who is part of the organization (may be a programmer / admin / user / etc). Anyone who has privileges to perform an action on the application.<br />
<br />
* '''App Store Approvers/Reviewers:''' Any app store which fails to review potentially dangerous code or malicious application which executes on a user’s device and performs suspicious/ malicious activities<br />
<br />
<br />
<br />
====Automated Programs====<br />
<br />
<br />
<br />
* '''Malware on the device''': Any program / mobile application which performs suspicious activity. It can be an application, which is copying real time data from the user’s device and transmitting it to any server. This type of program executes parallel to all the processes running in the background and stays alive performing malicious activity all the time. E.g. Olympics App which stole text messages and browsing history:[http://venturebeat.com/2012/08/06/olympics-android-app/]http://venturebeat.com/2012/08/06/olympics-android-app/<br />
<br />
* '''Scripts executing at the browser with HTML5''': Any script code written in a language similar to JavaScript having capability of accessing the device level content falls under this type of agent section. A script executing at the browser reading and transmitting browser memory data / complete device level data.<br />
<br />
* '''Malicious SMS''': An incoming SMS redirected to trigger any kind of suspicious activity on the mobile device. There are multiple services which keep running in the background. Each of these services have listeners which might be active to listen for the content of an incoming SMS. An SMS message may be a sort of trigger for the service to perform some suspicious activity.<br />
<br />
* '''Malicious App:''' Failure to detect malicious or vulnerable code and the likelihood of a compromise or attack against the app store itself, potentially turning legitimate code into hostile things including updates and new downloaded apps.<br />
<br />
<br />
<br />
Below is a diagram illustrated to understand the Threat Agents and Threats in a visual manner:<br />
<br />
<br />
[[image:Mobile-app-threat-agents.png|582x527px]]<br />
<br />
<br />
<br />
'''Figure 1 : Pictorial Representation of Threats and Agents'''<br />
<br />
<br />
<br />
==Methods of Attack==<br />
In this section, we will observe different methods an attacker can use to reach the data. This data can be sensitive information to the device or something sensitive to the app itself.<br />
<br />
<br />
<br />
===Attack’s Flowchart===<br />
<br />
Destruction of the asset is normally classified as attack. Attack can be further categorized as a planned attack or an unplanned one. Unintended attacks are normally caused due to some form of accidental actions.<br />
<br />
<br />
<br />
[[image:Mobile-app-attack-workflow.png]]<br />
<br />
'''Figure 2: Attack Workflow'''<br />
<br />
<br />
<br />
===Attack Scenario===<br />
<br />
'''“Method aimed to read the local application memory”'''<br />
<br />
<br />
<br />
The above mentioned attack methodology is the one in which the data which is targeted is application specific memory and the method used is memory based analysis. The attacker steals any sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory.<br />
<br />
<br />
<br />
We have listed down other methods below which can be mapped with the second section in a similar fashion:<br />
<br />
<br />
<br />
The classification of attacks based on the way data is handled:<br />
<br />
<br />
<br />
* Carrier Based Methods<br />
<br />
<br />
<br />
# Man in the middle (MiTM) attacks which can steal data packets including SMS or voice packets<br />
# Hijack wireless transmission.<br />
<br />
<br />
<br />
* Endpoints based methods<br />
<br />
<br />
<br />
# Inject code to tamper with web application or web services<br />
# Many of the OWASP Mobile Top 10/OWASP Web Application Top 10<br />
# Publishing Malwares in the app store<br />
# Stealing user sensitive phone contents using Malwares<br />
# Cloud storage<br />
# Targeting malicious corporate network. (e.g. VPN Keys, etc)<br />
<br />
<br />
<br />
* Wireless interfaces based methods<br />
<br />
<br />
<br />
# Stealing data when its in-transit using wireless channel like 802.11, NFC based data exchange or Bluetooth based data exchange. Application Level Attacks<br />
<br />
<br />
<br />
* OS and application level methods<br />
<br />
<br />
<br />
# Exploit the Input validation on client-side by by-passing the checks<br />
# An adversary steals sensitive data by reading SD Card based stored content<br />
# Exploiting vulnerabilities within an app or runtime environment. (VM, framework dependencies, etc)<br />
# An adversary exploits OS level functionalities steal data from device or server<br />
# Rooting or Jailbreaking the phone to access sensitive data from memory<br />
<br />
<br />
<br />
* Miscellaneous Methods<br />
<br />
<br />
<br />
# Method used to exploit and steal GPS based signals which falls in users personal information<br />
# Method used to exploit the flash memory<br />
# Method used to perform “tap jacking” based attacks.<br />
# Method used to steal keyboard cache or logs.<br />
# Method used to steal microphone recordings of a user<br />
# Method used to exploit and misuse the camera functionality.<br />
<br />
<br />
==Controls==<br />
What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.<br />
<br />
<br />
* What are the controls to prevent an attack?<br />
** Defined by platform<br />
*** Apple iOS<br />
*** Android<br />
*** Windows Mobile<br />
*** BlackBerry<br />
* What are the controls to detect an attack?<br />
** Defined by platform<br />
*** Apple iOS<br />
*** Android<br />
*** Windows Mobile<br />
*** BlackBerry<br />
* What are the controls to mitigate/minimize impact of an attack?<br />
** Defined by platform<br />
*** Apple iOS<br />
*** Android<br />
*** Windows Mobile<br />
*** BlackBerry<br />
* What are the controls to protect users private information (privacy controls)<br />
** Example: prompts for access to address book/geolocation<br />
* Create a mapping of controls to each specific method of attack (defined in Section 4 – Methods of Attack)<br />
** Create level of assurance framework based on controls implemented. This would be subjective to a certain point, but it would be useful in guiding organizations who want to achieve a certain level of risk management based on the threats and vulnerabilities<br />
* Case studies, control examples<br />
<br />
<br />
==Project Contributors==<br />
Special thanks to the following team members who contributed to the initial release of the threat model:<br />
<br />
<br />
Tom Eston (Project Lead)<br />
<br />
Jack Mannino<br />
<br />
Sreenarayan Ashokkumar<br />
<br />
Swapnil Deshmukh<br />
<br />
Brandon Knight<br />
<br />
Steve Jensen<br />
<br />
Shimon Modi<br />
<br />
Rodrigo Marcos<br />
<br />
Brandon Clark<br />
<br />
Yvesmarie Quemener<br />
<br />
Yashraj Paralikar<br />
<br />
Ritesh Taank<br />
<br />
<br />
<br />
__NOTOC__ <headertabs /></div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet&diff=247521XSS (Cross Site Scripting) Prevention Cheat Sheet2019-02-14T15:22:05Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.md XSS (Cross Site Scripting) Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Vulnerability_Disclosure_Cheat_Sheet&diff=247520Vulnerability Disclosure Cheat Sheet2019-02-14T15:20:38Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.md Vulnerability Disclosure Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Virtual_Patching_Cheat_Sheet&diff=247518Virtual Patching Cheat Sheet2019-02-14T15:13:10Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Virtual_Patching_Cheat_Sheet.md Virtual Patching Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=User_Privacy_Protection_Cheat_Sheet&diff=247516User Privacy Protection Cheat Sheet2019-02-14T14:51:26Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md User Privacy Protection Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Unvalidated_Redirects_and_Forwards_Cheat_Sheet&diff=247515Unvalidated Redirects and Forwards Cheat Sheet2019-02-14T14:50:27Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md Unvalidated Redirects and Forwards Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet&diff=247513Transport Layer Protection Cheat Sheet2019-02-14T14:47:56Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md Transport Layer Protection Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Transaction_Authorization_Cheat_Sheet&diff=247512Transaction Authorization Cheat Sheet2019-02-14T14:46:41Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transaction_Authorization_Cheat_Sheet.md Transaction Authorization Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Threat_Modeling_Cheat_Sheet&diff=247511Threat Modeling Cheat Sheet2019-02-14T14:45:26Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Threat_Modeling_Cheat_Sheet.md Threat Modeling Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=TLS_Cipher_String_Cheat_Sheet&diff=247508TLS Cipher String Cheat Sheet2019-02-14T14:41:54Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/TLS_Cipher_String_Cheat_Sheet.md TLS Cipher String Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Session_Management_Cheat_Sheet&diff=247503Session Management Cheat Sheet2019-02-14T14:13:13Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md Session Management Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Securing_Cascading_Style_Sheets_(CSS)_Cheat_Sheet&diff=247502Securing Cascading Style Sheets (CSS) Cheat Sheet2019-02-14T14:09:33Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.md Securing Cascading Style Sheets (CSS) Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=SQL_Injection_Prevention_Cheat_Sheet&diff=247501SQL Injection Prevention Cheat Sheet2019-02-14T14:08:11Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md SQL Injection Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=SAML_Security_Cheat_Sheet&diff=247500SAML Security Cheat Sheet2019-02-14T14:06:31Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SAML_Security_Cheat_Sheet.md SAML Security Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Ruby_on_Rails_Cheatsheet&diff=247499Ruby on Rails Cheatsheet2019-02-14T14:05:02Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Ruby_on_Rails_Cheatsheet.md Ruby on Rails Cheatsheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=REST_Security_Cheat_Sheet&diff=247498REST Security Cheat Sheet2019-02-14T14:04:19Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md REST Security Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=REST_Assessment_Cheat_Sheet&diff=247497REST Assessment Cheat Sheet2019-02-14T14:03:16Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md REST Assessment Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Query_Parameterization_Cheat_Sheet&diff=247496Query Parameterization Cheat Sheet2019-02-14T13:34:35Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Query_Parameterization_Cheat_Sheet.md Query Parameterization Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Protect_FileUpload_Against_Malicious_File&diff=247495Protect FileUpload Against Malicious File2019-02-14T13:33:49Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Protect_FileUpload_Against_Malicious_File.md Protect FileUpload Against Malicious File] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Pinning_Cheat_Sheet&diff=247494Pinning Cheat Sheet2019-02-14T13:21:37Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md Pinning Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Password_Storage_Cheat_Sheet&diff=247493Password Storage Cheat Sheet2019-02-14T13:16:27Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md Password Storage Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=OS_Command_Injection_Defense_Cheat_Sheet&diff=247491OS Command Injection Defense Cheat Sheet2019-02-14T13:11:00Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.md OS Command Injection Defense Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Mass_Assignment_Cheat_Sheet&diff=247489Mass Assignment Cheat Sheet2019-02-14T13:03:56Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Mass_Assignment_Cheat_Sheet.md Mass Assignment Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Logging_Cheat_Sheet&diff=247488Logging Cheat Sheet2019-02-14T13:03:03Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Logging_Cheat_Sheet.md Logging Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=LDAP_Injection_Prevention_Cheat_Sheet&diff=247486LDAP Injection Prevention Cheat Sheet2019-02-14T13:01:45Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.md LDAP Injection Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Key_Management_Cheat_Sheet&diff=247485Key Management Cheat Sheet2019-02-14T13:00:47Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Key_Management_Cheat_Sheet.md Key Management Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=JSON_Web_Token_(JWT)_Cheat_Sheet_for_Java&diff=247484JSON Web Token (JWT) Cheat Sheet for Java2019-02-14T12:58:50Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.md JSON Web Token (JWT) Cheat Sheet for Java] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=JAAS_Cheat_Sheet&diff=247483JAAS Cheat Sheet2019-02-14T12:57:27Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JAAS_Cheat_Sheet.md JAAS Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet&diff=247482Insecure Direct Object Reference Prevention Cheat Sheet2019-02-14T12:49:36Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md Insecure Direct Object Reference Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=247481Input Validation Cheat Sheet2019-02-14T12:41:00Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Input_Validation_Cheat_Sheet.md Input Validation Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Injection_Prevention_Cheat_Sheet_in_Java&diff=247476Injection Prevention Cheat Sheet in Java2019-02-14T11:51:30Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.md Injection Prevention Cheat Sheet in Java] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Injection_Prevention_Cheat_Sheet&diff=247475Injection Prevention Cheat Sheet2019-02-14T11:43:28Z<p>Thunder-Son: Undo revision 247474 by Thunder-Son (talk)</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
<br /><br />
__TOC__{{TOC hidden}}<br />
= Introduction =<br />
<br />
This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.<br />
<br />
Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws. <br />
<br />
Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.<br />
<br />
Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.<br />
<br />
= Application Types =<br />
<br />
Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.<br />
<br />
== A1: New Application ==<br />
<br />
A new web application in the design phase, or in early stage development.<br />
<br />
== A2: Productive Open Source Application ==<br />
<br />
An already productive application, which can be easily adapted. A Model-View-Controller (MVC) type application is just one example of having a easily accessible application architecture.<br />
<br />
== A3: Productive Closed Source Application ==<br />
<br />
A productive application which cannot or only with difficulty be modified.<br />
<br />
= Forms of Injection =<br />
<br />
There are several forms of injection targeting different technologies including SQL queries, LDAP queries, XPath queries and OS commands.<br />
<br />
== Query languages ==<br />
<br />
The most famous form of injection is SQL Injection where an attacker can modify existing database queries. For more information see the [[SQL Injection Prevention Cheat Sheet]].<br />
<br />
But also LDAP, SOAP, XPath and REST based queries can be susceptible to injection attacks allowing for data retrieval or control bypass.<br />
<br />
=== SQL Injection ===<br />
An SQL injection attack consists of insertion or "injection" of either a partial or complete SQL query via the data input or transmitted from the client (browser) to the web application. A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system or write files into the file system, and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.<br />
<br />
SQL Injection attacks can be divided into the following three classes:<br />
* '''Inband:''' data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.<br />
* '''Out-of-band:''' data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).<br />
* '''Inferential or Blind:''' there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server.<br />
{| class="wikitable"<br />
! How to test for the issue<br />
! Remediation<br />
! Example code - Java<br />
|- style="vertical-align:top;"<br />
|'''During code review''' <br />
please check for any queries to the database are not done via prepared statements.<br />
<br />
If dynamic statements are being made please check if the data is sanitized before used as par of the statement.<br />
<br />
Auditors should always look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors.<br />
<br />
'''Automated Exploitation'''<br />
<br />
Most of the situation and techniques below here can be performed in a automated way using some tools. In this article the tester can find information how to perform an automated auditing using SQLMap:<br />
<br />
[[Automated Audit using SQLMap|https://www.owasp.org/index.php/Automated_Audit_using_SQLMap]]<br />
<br />
Equally Static Code Analysis Data flow rules can detect of unsanitized user controlled input can change the SQL query.<br />
<br />
'''Stored Procedure Injection'''<br />
<br />
When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure.<br />
<br />
'''Time delay Exploitation technique'''<br />
<br />
The time delay exploitation technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. This technique consists in sending an injected query and in case the conditional is true, the tester can monitor the time taken to for the server to respond. If there is a delay, the tester can assume the result of the conditional query is true. This exploitation technique can be different from DBMS to DBMS (check DBMS specific section).<br />
<br />
<code><nowiki>http://www.example.com/product.php?id=10</nowiki></code> <code>AND IF(version() like ‘5%’, sleep(10), ‘false’))--</code><br />
<br />
In this example the tester if checking whether the MySql version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds.<br />
<br />
'''Out of band Exploitation technique'''<br />
<br />
This technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. The technique consists of the use of DBMS functions to perform an out of band connection and deliver the results of the injected query as part of the request to the tester’s server. Like the error based techniques, each DBMS has its own functions. Check for specific DBMS section.<br />
|<u>'''Defense Option 1: Prepared Statements (with Parameterized Queries)'''</u><br />
<br />
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.<br />
<br />
'''<u>Defense Option 2: Stored Procedures</u>'''<br />
<br />
The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you. Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely* which is the norm for most stored procedure languages. <br />
<br />
'''*Note:''' 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. <br />
<br />
'''<u>Defense Option 3: White List Input Validation</u>'''<br />
<br />
Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows.<br />
<br />
'''<u>Defense Option 4: Escaping All User-Supplied Input</u>'''<br />
<br />
This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations.<br />
<br />
This technique is to escape user input before putting it in a query. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost effective. <br />
<br />
|<br />
; Safe Java Prepared Statement Example<br />
The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.<br />
<syntaxhighlight lang="java"> String custname = request.getParameter("customerName"); // This should REALLY be validated too // perform input validation to detect attacks String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; '''PreparedStatement pstmt = connection.prepareStatement( query );''' '''pstmt.setString( 1, custname);''' ResultSet results = pstmt.executeQuery( ); </syntaxhighlight><br />
We have shown examples in Java, but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. <br />
; Safe Java Stored Procedure Example<br />
The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.<br />
<syntaxhighlight lang="java"> String custname = request.getParameter("customerName"); // This should REALLY be validated try { '''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");''' '''cs.setString(1, custname);''' ResultSet results = cs.executeQuery(); // … result set handling } catch (SQLException se) { // … logging and error handling } </syntaxhighlight><br />
<br />
|}<br />
<br />
=== LDAP Injection ===<br />
LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements through techniques similar to [[SQL Injection]]. LDAP injection attacks could result in the granting of permissions to unauthorized queries, and content modification inside the LDAP tree. For more information on LDAP Injection attacks, visit [[LDAP injection]].<br />
<br />
[[LDAP injection]] attacks are common due to two factors:<br />
# The lack of safer, parameterized LDAP query interfaces<br />
# The widespread use of LDAP to authenticate users to systems.<br />
{| class="wikitable"<br />
! style="width: 30%" |How to test for the issue<br />
!Remediation<br />
!Example code - Java<br />
|- style="vertical-align:top;"<br />
|<br />
|'''<u>Escape all variables using the right LDAP encoding function</u>'''<br />
<br />
The main way LDAP stores names is based on DN (distinguished name). You can think of this like a unique identifier. These are sometimes used to access resources, like a username.<br />
<br />
A DN might look like this<br />
cn=Richard Feynman, ou=Physics Department, dc=Caltech, dc=edu <br />
or<br />
uid=inewton, ou=Mathematics Department, dc=Cambridge, dc=com <br />
There are certain characters that are considered special characters in a DN. The exhaustive list is the following: ',','\','#','+','<','>',';','"','=', and leading or trailing spaces<br />
<br />
Each DN points to exactly 1 entry, which can be thought of sort of like a row in a RDBMS. For each entry, there will be 1 or more attributes which are analogous to RDBMS columns. If you are interested in searching through LDAP for users will certain attributes, you may do so with search filters. In a search filter, you can use standard boolean logic to get a list of users matching an arbitrary constraint. Search filters are written in Polish notation AKA prefix notation.<br />
<br />
Example:<br />
(&(ou=Physics)(| (manager=cn=Freeman Dyson,ou=Physics,dc=Caltech,dc=edu) (manager=cn=Albert Einstein,ou=Physics,dc=Princeton,dc=edu) )) <br />
When building LDAP queries in application code, you MUST escape any untrusted data that is added to any LDAP query. There are two forms of LDAP escaping. Encoding for LDAP Search and Encoding for LDAP DN (distinguished name). The proper escaping depends on whether you are sanitizing input for a search filter, or you are using a DN as a username-like credential for accessing some resource.<br />
<br />
|'''Safe Java for LDAP escaping Example:'''<br />
<syntaxhighlight lang="java"> public String escapeDN (String name) { //From RFC 2253 and the / character for JNDI final char[] META_CHARS = {'+', '"', '<', '>', ';', '/'}; String escapedStr = new String(name); //Backslash is both a Java and an LDAP escape character, so escape it first escapedStr = escapedStr.replaceAll("\\\\\\\\","\\\\\\\\"); //Positional characters - see RFC 2253 escapedStr = escapedStr.replaceAll("\^#","\\\\\\\\#"); escapedStr = escapedStr.replaceAll("\^ | $","\\\\\\\\ "); for (int i=0;i < META_CHARS.length;i++) { escapedStr = escapedStr.replaceAll("\\\\"+META_CHARS[i],"\\\\\\\\" + META_CHARS[i]); } return escapedStr; }</syntaxhighlight><br />
Note, that the backslash character is a Java String literal and a regular expression escape character. <br />
<syntaxhighlight lang="java"> public String escapeSearchFilter (String filter) { //From <nowiki>RFC 2254</nowiki> String escapedStr = new String(filter); escapedStr = escapedStr.replaceAll("\\\\\\\\","\\\\\\\\5c"); escapedStr = escapedStr.replaceAll("\\\\\*","\\\\\\\\2a"); escapedStr = escapedStr.replaceAll("\\\\(","\\\\\\\\28"); escapedStr = escapedStr.replaceAll("\\\\)","\\\\\\\\29"); escapedStr = escapedStr.replaceAll("\\\\"+Character.toString('\\u0000'), "\\\\\\\\00"); return escapedStr; } </syntaxhighlight><br />
|}<br />
<br />
=== XPath Injection ===<br />
== Scripting languages ==<br />
<br />
All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated and unescaped user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.<br />
<br />
Every time a scripting language is used, the actual implementation of the 'higher' scripting language is done using a 'lower' language like C. If the scripting language has a flaw in the data handling code 'Null Byte Injection' attack vectors can be deployed to gain access to other areas in memory, which results in a successful attack.<br />
<br />
== Operating System (OS) Commands ==<br />
<br />
OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications.<br />
{| class="wikitable"<br />
!How to test for the issue<br />
!Remediation<br />
!Example code - Java<br />
|- style="vertical-align:top;"<br />
|'''During code review''', check if any command execute methods are called and in unvalidated user input are taken as data for that command.<br />
<br />
Out side of that, appending a semicolon to the end of a URL query parameter followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon. This is because the ; is interpreted as a command separator.<br />
'''Example:''' http://sensitive/something.php?dir=%3Bcat%20/etc/passwd<br />
<br />
If the application responds with the output of the /etc/passwd file then you know the attack has been successful. Many web application scanners can be used to test for this attack as they inject variations of command injections and test the response.<br />
<br />
Equally '''Static Code Analysis''' tools check the data flow of untrusted user input into a web application and check if the data is then entered into a dangerous method which executes the user input as a command.<br />
<br />
|If it is considered unavoidable the call to a system command incorporated with user-supplied, the following two layers of defense should be used within software in order to prevent attacks<br />
# '''Parametrization''' - If available, use structured mechanisms that automatically enforce the separation between data and command. These mechanisms can help to provide the relevant quoting, encoding.<br />
# '''Input validation''' - the values for commands and the relevant arguments should be both validated. There are different degrees of validation for the actual command and its arguments:<br />
#* When it comes to the '''commands''' used, these must be validated against a whitelist of allowed commands.<br />
#* In regards to the '''arguments''' used for these commands, they should be validated using the following options:<br />
#** Positive or “whitelist” input validation - where are the arguments allowed explicitly defined<br />
#** White list Regular Expression - where is explicitly defined a whitelist of good characters allowed and the maximum length of the string. Ensure that metacharacters like & | ; $ > < ` \ ! and white-spaces are not part of the Regular Expression. For example, the following regular expression only allows lowercase letters and numbers, and does not contain metacharacters. The length is also being limited to 3-10 characters:<br />
^[a-z0-9]{3,10}$ <br />
|'''''incorrect Usage'''''<br />
<syntaxhighlight lang="java"><br />
ProcessBuilder b = new ProcessBuilder("C:\DoStuff.exe -arg1 -arg2");<br />
</syntaxhighlight><br />
In this example, the command together with the arguments are passed as a one string, making easy to manipulate that expression and inject malicious strings.<br />
<br />
'''''Correct Usage'''''<br />
<br />
Here is an example that starts a process with a modified working directory. The command and each of the arguments are passed separately. This make it easy to validated each term and reduces the risk to insert malicious strings. <br />
<br />
<syntaxhighlight lang="java"><br />
ProcessBuilder pb = new ProcessBuilder("TrustedCmd", "TrustedArg1", "TrustedArg2");<br />
<br />
Map<String, String> env = pb.environment();<br />
<br />
pb.directory(new File("TrustedDir"));<br />
<br />
Process p = pb.start();<br />
</syntaxhighlight><br />
|}<br />
<br />
== Network Protocols ==<br />
<br />
Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.<br />
<br />
= Injection Prevention Rules =<br />
<br />
=== Rule #1 (Perform proper input validation): ===<br />
<br />
Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but '''is not a complete defense''' as many applications require special characters in their input.<br />
<br />
=== Rule #2 (Use a safe API): ===<br />
<br />
The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.<br />
<br />
=== Rule #3 (Contextually escape user data): ===<br />
<br />
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.<br />
<br />
= Other Injection Cheatsheets =<br />
<br />
[[SQL_Injection_Prevention_Cheat_Sheet | SQL Injection Prevention Cheat Sheet]]<br /><br />
[[OS_Command_Injection_Defense_Cheat_Sheet | OS Command Injection Defense Cheat Sheet]]<br /><br />
[[LDAP_Injection_Prevention_Cheat_Sheet | LDAP Injection Prevention Cheat Sheet]]<br /><br />
[[Injection_Prevention_Cheat_Sheet_in_Java | Injection Prevention Cheat Sheet in Java]]<br />
<br />
= Other Cheatsheets = <br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Injection_Prevention_Cheat_Sheet&diff=247474Injection Prevention Cheat Sheet2019-02-14T11:42:29Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.md Injection Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=HTTP_Strict_Transport_Security_Cheat_Sheet&diff=247472HTTP Strict Transport Security Cheat Sheet2019-02-14T11:38:14Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.md HTTP Strict Transport Security Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=HTML5_Security_Cheat_Sheet&diff=247471HTML5 Security Cheat Sheet2019-02-14T11:36:10Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md HTML5 Security Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Forgot_Password_Cheat_Sheet&diff=247470Forgot Password Cheat Sheet2019-02-14T11:34:44Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md Forgot Password Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Error_Handling_Cheat_Sheet&diff=247469Error Handling Cheat Sheet2019-02-14T11:25:00Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md Error Handling Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=247468DRAFT Denial of Service Cheat Sheet2019-02-14T11:19:08Z<p>Thunder-Son: Undo revision 247467 by Thunder-Son (talk)</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* '''Threading''': Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
* identify resource intensive pages and plan ahead.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage:''' the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO (Develop text)'' Attacks where network bandwidth gets saturation. Volumetric in nature. Amplification techniques make these attacks effective.<br />
<br />
''TODO (list attacks)'' NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
== Rate limiting ==<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
== ISP-Level remediations: ==<br />
* '''Filter invalid sender addresses using edge routers''', in accordance with <nowiki>RFC 2267</nowiki>, to filter out IP-spoofing attacks done with the goal of bypassing block lists.<br />
* '''Check your ISP services in terms of DDOS beforehand''' (support for multiple internet access points, enough bandwidth (xx-xxx Gbit/s) and special hardware for traffic analysis and defence on application level<br />
<br />
== Global-Level remediations: Commercial cloud filter services: ==<br />
* Consider using a filter service in order to resist larger attacks (up to 500GBit/s)<br />
* '''Filter services''' support different mechanics to filter out malicious or non compliant traffic<br />
* '''Comply with relevant data protection/privacy laws''' - a lot of providers route traffic through USA/UK<br />
<br />
= Related Articles =<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=247467DRAFT Denial of Service Cheat Sheet2019-02-14T11:14:30Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md Denial of Service Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=DOM_based_XSS_Prevention_Cheat_Sheet&diff=247466DOM based XSS Prevention Cheat Sheet2019-02-14T11:12:38Z<p>Thunder-Son: Fix typo mistake</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.md DOM based XSS Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=DOM_based_XSS_Prevention_Cheat_Sheet&diff=247465DOM based XSS Prevention Cheat Sheet2019-02-14T11:12:05Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.md .NET DOM based XSS Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Deserialization_Cheat_Sheet&diff=247464Deserialization Cheat Sheet2019-02-14T11:04:28Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Deserialization_Cheat_Sheet.md Deserialization Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Denial_of_Service_Cheat_Sheet&diff=247463Denial of Service Cheat Sheet2019-02-14T11:01:36Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md Denial of Service Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Cryptographic_Storage_Cheat_Sheet&diff=247462Cryptographic Storage Cheat Sheet2019-02-14T11:00:32Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md Cryptographic Storage Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=247461Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet2019-02-14T10:58:50Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Credential_Stuffing_Prevention_Cheat_Sheet&diff=247417Credential Stuffing Prevention Cheat Sheet2019-02-13T09:44:29Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.md Credential Stuffing Prevention Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Clickjacking_Defense_Cheat_Sheet&diff=247416Clickjacking Defense Cheat Sheet2019-02-13T09:38:17Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Clickjacking_Defense_Cheat_Sheet.md Clickjacking Defense Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Sonhttps://wiki.owasp.org/index.php?title=Choosing_and_Using_Security_Questions_Cheat_Sheet&diff=247415Choosing and Using Security Questions Cheat Sheet2019-02-13T09:25:27Z<p>Thunder-Son: Migration to GitHub</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!<br />
<br />
Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.md Choosing and Using Security Questions Cheat Sheet] to see the latest version of the cheat sheet.</div>Thunder-Son