Data Call for OWASP Mobile Security Guide - Ends 30 July 2015

[Milan Singh Thakur]

Hello Team,

We have planned to release "OWASP Mobile Security Guide" in coming months.

So this is a call for DATA (testcases) which will help us to shape the testing guide. I have attached a template for the same.

Requesting all Techies to revert on or before 30 July 2015.

Be Author...!!! Yes, if your submitted data is found to be useful (ofcourse it will be), you can be named as Author.

STEPS: 1. Fill the template with appropriate data
             2. Add your name to file name
             3. Mail me :) - milanth...@gmail.com

Lets Gear Up Team...!!!

For any queries mail me: milanth...@gmail.com
Suggestions are always welcome :)

[Milan Singh Thakur]

For additional help you can refer this:

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Mobile_Security_Testing

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Secure_Mobile_Development

Also points mentioned by Javi:

Verify that the code is obfuscated
Check that there are lock out mechanisms in place
Try to call a webservice/API without having generated an authentication token
Check that inputs that contain sensitive information don’t remember the information previously entered
Check that once you have logged off in an application, when clicking back you can't navigate to the application again (Android only)
Check that when you are inside the application and  click on back, no sensitive information remains in the forms
Try to setup as password something insecure(password, 1111111…).
Check if you cant access to somebody else data bypassing the front end validations (direct webservice/api call)
Check if you cant execute an operation bypassing authorisation (direct webservice/api call)
Check that after logoff, all data is cleared ( SSO tokens, cookies, etc…)
Check that after session timeout you are automatically logged off
Try to inject any script/sql/html... in the inputs of an application
Try to inject any script/sql/html... directly in the back end call (webservice/api)

Regards,
Milan

[Paco Hope]

I’m a little late to this, but I would argue that quite a few of these things are not “mobile” things at all. Primary principle: if you would change Android or iOS code to fix it, it is a mobile issue. If you can find the problem without owning the correct kind of mobile device, it isn’t a mobile problem. If you don’t need to have the binary installed on a device (or a simulator) to exploit the problem, then it isn’t a mobile problem.

When testing a mobile app that is backed by a web service, one should do 100% of all the normal web testing things against the back end. They don’t need to be restated here. Then, on top of that, one does some stuff that is unique to mobile apps. Things like session management, direct object reference, and password policies are absolutely bog standard web pen test issues. What we really need is a list of stuff you wouldn’t do at all, except that this is a mobile test and it needs to be done.

> Try to call a webservice/API without having generated an authentication token

This is pure web. It’s sad that this ever works. It works plenty often. But this is not a mobile app problem.

> Check that once you have logged off in an application, when clicking back you can't navigate to the application again (Android only)
> Check that when you are inside the application and click on back, no sensitive information remains in the forms

I’m not sure what “clicking back” means in the context of a mobile app. If it’s a mobile-aware web site, that’s one thing. But mobile apps (even webviews) don’t really have a concept of “back”.

> Try to setup as password something insecure(password, 1111111…).

Nope. That is anything but mobile. That has nothing to do with mobile.

> Check if you cant access to somebody else data bypassing the front end validations (direct webservice/api call)
> Check if you cant execute an operation bypassing authorisation (direct webservice/api call)

These are web tests, not mobile tests. You would test this on every web app you test, whether there is a mobile component or not.

> Check that after logoff, all data is cleared ( SSO tokens, cookies, etc…)

Maybe… if you’re checking app local storage on the device. I suspect it is more important to check that the server has really killed the session. Which, again, is important but not a mobile concern.

> Check that after session timeout you are automatically logged off

I suspect that this is referencing a server session. Which, again, has nothing to do with the mobile app.

> Try to inject any script/sql/html... in the inputs of an application
> Try to inject any script/sql/html... directly in the back end call (webservice/api)

Testing for XSS and SQL injection are standard web things. JavaScript, JSON, SQL, and HTML injection are pretty much a non-issue for most mobile apps (webviews being the notable exception). Most injections are not a test of the mobile code, but rather a test of the server code.

We need to focus on the genuinely mobile aspects of mobile apps. Nothing in this list covered things like use of Android or iOS security features (permissions, keychain, etc.). There was nothing genuinely mobile like location, bluetooth, NFC, TouchID, etc.

Paco

[Javi D R]

Hi

I agree that the points you highlight at the bottom are important, so would be great if you can add those to the list, but I still believe that the points i have raised are also important. I
have done this based on the Top 10 risks,(https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks)

Anyway, the goal here is to have the maximum information we can, and then, somebody will decide which tests are valid and which not.

Find below some explanation for the points raised

Thanks

> Try to call a webservice/API without having generated an authentication token

This is pure web. It’s sad that this ever works. It works plenty often. But this is not a mobile app problem.

This is not part of native code for a mobile app, but it is still part of a mobile application. In fact, this is the most exploited vulnerability -M1: Weak Server Side Controls

> Check that once you have logged off in an application, when clicking back you can't navigate to the application again (Android only)
> Check that when you are inside the application and  click on back, no sensitive information remains in the forms

I’m not sure what “clicking back” means in the context of a mobile app. If it’s a mobile-aware web site, that’s one thing. But mobile apps (even webviews) don’t really have a concept of “back”.

Android devices have back button. If it is not managed correctly, it could create a vulnerability. I agree this is a low risk thing.

> Try to setup as password something insecure(password, 1111111…).

Nope. That is anything but mobile. That has nothing to do with mobile.

It is. It is not exclusive for mobile, but mobile apps also have authentication process. In fact, it is M5 - M5: Poor Authorization and Authentication

> Check that after logoff, all data is cleared ( SSO tokens, cookies, etc…)

Maybe… if you’re checking app local storage on the device. I suspect it is more important to check that the server has really killed the session. Which, again, is important but not a mobile concern.

You have a good point here. Both are important. But what i mean is, for example, that if the device is stolen and SSO token is not killed, you can continue the execution from the previous user

> Check that after session timeout you are automatically logged off

I suspect that this is referencing a server session. Which, again, has nothing to do with the mobile app.

It has. This was referenced in the previous point

> Try to inject any script/sql/html... in the inputs of an application
> Try to inject any script/sql/html... directly in the back end call (webservice/api)

Testing for XSS and SQL injection are standard web things. JavaScript, JSON, SQL, and HTML injection are pretty much a non-issue for most mobile apps (webviews being the notable exception). Most injections are not a test of the mobile code, but rather a test of the server code.

Agree this is not as important as in web application, but it is still M7 - M7: Client Side Injection

Paco

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

[Paco Hope]

have done this based on the Top 10 risks,(https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks)

Ahh. Of course, we’re revamping those top 10. If you want to see the draft as it takes shape, take a look at:

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad 

You’ll see that some of the ones you reference (M1, M7) are being retired because they weren’t being used. And M1 (server-side stuff) was basically a pointer to the OWASP Web Top Ten. 

This is pure web. It’s sad that this ever works. It works plenty often. But this is not a mobile app problem.

This is not part of native code for a mobile app, but it is still part of a mobile application. In fact, this is the most exploited vulnerability -M1: Weak Server Side Controls

M1 doesn’t even come up in the top 5 as reported by security firms who shared their data with us.

> Try to setup as password something insecure(password, 1111111…).

Nope. That is anything but mobile. That has nothing to do with mobile.

It is. It is not exclusive for mobile, but mobile apps also have authentication process. In fact, it is M5 - M5: Poor Authorization and Authentication

I still disagree. Imagine someone brings you a mobile app and says “the mobile app makes sure you don’t pick a weak password.” What’s the first thing you do? You try setting a weak password directly through the server interface. And if the web service permits the weak password, you call it a finding and tell them “you can’t rely on the mobile device to prevent weak passwords.” Password policy and enforcement of password strength is the domain of server code, not mobile code. At best, the mobile device can hint at whether the password is good or not. But it is acceptable if the mobile code doesn’t do any enforcement at all. It is unacceptable if the server fails to enforce password quality.

Maybe… if you’re checking app local storage on the device. I suspect it is more important to check that the server has really killed the session. Which, again, is important but not a mobile concern.

You have a good point here. Both are important. But what i mean is, for example, that if the device is stolen and SSO token is not killed, you can continue the execution from the previous user

You are right. But that’s an operational response to an incident. That whole process is carried out by IT administrators, not mobile app code. It is true that the app has to make it possible to kill the SSO token. Again I say it’s server side code that makes it possible. Not app code. You give that to the server team to fix, not the guys writing for iOS and Android.

Testing for XSS and SQL injection are standard web things. JavaScript, JSON, SQL, and HTML injection are pretty much a non-issue for most mobile apps (webviews being the notable exception). Most injections are not a test of the mobile code, but rather a test of the server code.

Agree this is not as important as in web application, but it is still M7 - M7: Client Side Injection

Yep. And that’s the second-to-least referenced risk. It’s another one that will likely drop out of the mobile top ten in 2015. Of all the firms that are reporting on risks, few are reporting this at all. 

Paco

[Javi D R]

Ok... Sorry about that. I just tried to help

[Daniel Miessler]

On Jun 23, 2015, at 8:58 AM, Paco Hope <pa...@owasp.org> wrote:

Primary principle: if you would change Android or iOS code to fix it, it is a mobile issue. If you can find the problem without owning the correct kind of mobile device, it isn’t a mobile problem. If you don’t need to have the binary installed on a device (or a simulator) to exploit the problem, then it isn’t a mobile problem.

This is a really interesting way of seeing the list, Paco. I could definitely see dividing things up this way.

But let me put forth another idea.

Maybe the purity of this approach, which I absolutely love, doesn’t match how actual users will consume the project. In my experience I think it’s best not only start with a pure concept from the standpoint of ontology and such, but rather from the perspective of the consumer of the project.

In short, customers build and deploy mobile applications as a combined entity, i.e. it’s usually the same team doing the front and backend. And for this reason I think having two (or more) projects will significantly diminish the user’s experience of our project.

I think mobile (in this context) is the mobile ecosystem. It’s the whole package. It’s what gets built for the app, what gets deployed, and what can be insecure. And that means both the client components and the backend. I don’t see customers listing vulnerabilities separately as web and mobile if the backend side is there for the mobile app.

So that’s my concern. While you have a phenomenal point here, I don’t think it matches how people do (and will continue to) use the project.

Eager to hear your, and anyone else’s, thoughts.

Best,

Daniel Miessler

OWASP IoT Project Leader

Daniel....@owasp.org 

[Jim Manico]

+1 and very well said, Daniel.
 - Jim

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

-- 
Jim Manico
Global Board Member
OWASP Foundation
https://www.owasp.org
Join me at AppSecUSA 2015!

[Milan Singh Thakur]

Hi Javi,

This is a discussion, so no need of Sorry like stuff (unless you have insulted someone on personal grounds).

Regards,

Milan Singh Thakur

http://sec4app.blogspot.com/

https://blogs.dsci.in/

[Paco Hope]

Daniel,

Of course you’re right about the mobile ecosystem. The concern I have is that the mobile guidance must reflect the full breadth and depth of that ecosystem.

I worry that the “mobile" development guidance focuses too much on server-side stuff without any focus on the client side stuff. Moreover, it is repeating what we already know about secure web development, but only repeating a subset. The vast majority of what we know about web app development applies to the server side of a mobile app. It doesn’t all need to be repeated here. When it comes to best practices, we should do pass-by-reference, not pass-by-value. So if we and call it “mobile guidance” (not “server side of mobile” or whatever) we give the false impression that “mobile” has been covered by following the guide, when in fact a huge pile of client-side issues have not been covered at all. If someone says “I followed the owasp guidance” and that guidance was disproportionately geared towards the server side of the ecosystem, then we have misled the app owner. They think all their mobile issues were covered when in fact many concerns weren’t.

There’s even a third side to this that isn’t covered well, yet: the app store itself. Consider the following: imagine there is a major vulnerability in the client side code. Assume the app developer fixes it right and fixes it instantly. How long will end users be exposed? There’s a 2-week lead time (minimum) to get the new version into the appropriate app store. And how long until app end-users have that version? What is the app owner/developer doing (what capabilities have they included?) to force the non-vulnerable version onto end user devices? The new version might target a more recent version of the mobile platform. Some end users will be unable to upgrade to the new version of the app because they can’t upgrade their device to a new version of the platform. Will end users remain vulnerable?

We also need guidance on Google Play store certificates/private keys and Apple App Store distribution certificates/private keys. The app store side of this ecosystem is important to the security of the app, but needs more guidance. One of my clients committed their Google play store keys and passphrase to github. We need to tell them not to do that (among many other things).

The client side best practices and the app store best practices are significantly underrepresented at present. We don’t even have a subsection / framework that makes their absence obvious.

Paco

[Javi D R]

Hi

For me, both approaches are correct. In the test guide, there could be two sections. One for back end testing, and another one for the native app itself

Something similar happens in Web applications test guide (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents), where there is a section for business logic tests, and another for client side tests

Thanks

[Milan Singh Thakur]

Hi Team,

10 Days left for your contribution on OWASP Mobile Application Guide.
Awaiting your contribution Team.

We are still receiving data :)

Regards,
Milan Singh Thakur

[Milan Singh Thakur]

We are receiving good response from our Team :)

Hope our Team Work reflects in upcoming guide releases :)

Regards
Milan

[Milan Singh Thakur]

Hi Team,

DATE for Alpha Release: 25-Aug-2015

Thanks to all Contributors :)

We are working on segregating the Test Cases :)
Below are some specialized application categories that we are planning to add in Mobile Security Guide:
1. Online Banking/ Insurance
2. Commercial/Shopping
3. Messengers/IM/Mail
4. Gaming
5. Data Sharing

Any suggestion from your side Team??
Based  on these categories, additional test cases may be applicable.

Regards,
Milan

[Amin Lalji]

Hi Milan,

Looks good ... have we considered adding Health Care and Social?

Thanks

Amin

[Bao Le]

So amazing. The day im waiting for

[Milan Singh Thakur]

Hi David,

We having plan to add it in upcoming versions along with NFC and other mobile tech.

[David Fern]

I would like to add Point of Sale (POS) to the list of  segments.

Unless it is considered a subset or segment of the existing categories

 

Thanks,

David

On Monday, August 3, 2015 7:23 AM, David Fern <df...@verizon.net> wrote:

 

Thanks,

David

[David Fern]

 

Thanks,

David

On Friday, July 31, 2015 8:59 AM, Amin Lalji <amin....@gmail.com> wrote:

[David Fern]

I had another thought

Health care or health devices

Manufacturer Disclosure Statement for Medical Device Security

				Manufacturer Disclosure Statement for Medical Device Sec... The Association of Electrical Equipment and Medical Imaging Manufacturers
				View on www.nema.org	Preview by Yahoo

FDA approach to medical device security is a step backward | Government Health IT

				FDA approach to medical device security is a step backwa... The FBI agents on the CBS show CSI: Cybersecurity stop a hacker bent on infiltrating the data center where wearable Insulin pumps in the treatment of diabetes are c...
				View on www.govhealthit.com	Preview by Yahoo

Any thoughts?

 

Thanks,

David

[Milan Singh Thakur]

+1 David :)

Smart wearables is very big ocean.

Regards,

Milan Singh Thakur

http://sec4app.blogspot.com/

https://blogs.dsci.in/

[Milan Singh Thakur]

HI Team,

The countdown has begun....!!

Alpha Release Date: 25-Aug-2015-- The AppSec Approach

Reg

Milan

[Yair Amit]

That’s great, Milan. To all contributors - great job! :)

Best regards,

- Yair

Yair Amit
CTO & Co-founder, Skycure
ya...@skycure.com | +972.54.644.2448
www.skycure.com | @yairamit

Download Skycure for your device

[Milan Singh Thakur]

Thanks Yair :)

[Milan Singh Thakur]

Hi Team,

We have observed that most of the Mobile Application Security Engineer/Pen-tester look for hardly 10-15 security checks.

So we have decided the Guide to be SIMPLE and have AppSec approach i.e. we will provide test cases which can be used for regular AppSec.

The Alpha version will contain 20 checks out of Total 65 security checks....!!

Reg
Milan

[Paco Hope]

Is that not a good candidate for the OWASP IoT top ten? 

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project

On the one hand, all these things seem different. On the other hand, they’re all the same…

Paco

[Milan Singh Thakur]

Ryt Paco...!
The way of implementation matters. Most of the IoT top ten can also be integrated with Mobile Top Ten.

I think both the projects should go in parallel.

Reg
Milan
mi...@owasp.org

[Daniel Miessler]

Hey guys,

So the projects are quite different. 

First of all, we’ve recently updated the OWASP IoT project significantly, which I presented on at DEFCON’s IoT Village.

1. We’ve created an umbrella IoT Security Project located here: https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project 
2. That project will contain multiple other projects (similar to the Mobile project)
3. The IoT Top 10 Project has been changed and renamed to the OWASP IoT Attack Surfaces Project, which is located here: https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Attack_Surface_Areas
4. That project’s goal is quite distinct from a Top 10 list, which is specifically to describe UNIVERSAL ATTACK SURFACES for all IoT systems.

The Top 10 name was hurting the project in a number of ways. It limited what we could put in the list by types of content. It confused vulns with threats with risks (like many other OWASP lists), and it restricted us to just 10 items.

This new structure, with an overarching IoT Project, lets us have a surface area project, for example, and put what belongs in it—not just what fits in 10 items.

And we can do the same with other projects below the umbrella. We’re already working on a project that describes how to build a secure IoT update system, for example, or how to handle Disposition/EOL issues related to devices that may have sensitive data on them.

So, that was the long answer.

The short answer is no, the IoT project should not be combined with the mobile project. If you look at the Attack Surfaces project you’ll see that mobile is just one of like 16 surfaces. They’re extremely different beasts.

Great question though, and if you guys have any feedback on the Surface Areas project, like which surfaces should be combined, or broken out, or any that we missed, please let me know!

Best,

[Jim Manico]

*applause* Smart moves that add a lot of value. Thank you!

Aloha,
- Jim

[Paco Hope]

The original post in this thread was David Fern was asking if testing health care devices belonged in the Mobile Security TESTING Guide. It’s basically a cross-post from the security testing guide folks over here onto the mobile top ten list. My point was that health care devices probably belonged in the IoT project (whatever it is). On the one hand, health care devices are not just “things” á la the “Internet of Things.” On the other hand, they are.

I certainly didn’t intend to imply that IoT and mobile were the same, nor did I mean to imply that 2 big projects should be merged. Just that if someone wants to talk about security of health care devices, my opinion is that the conversation is a better fit for some OWASP IoT project than a mobile project.

Paco

[Daniel Miessler]

I certainly didn’t intend to imply that IoT and mobile were the same, nor did I mean to imply that 2 big projects should be merged. Just that if someone wants to talk about security of health care devices, my opinion is that the conversation is a better fit for some OWASP IoT project than a mobile project.

I see. Well I certainly agree with that. 

Daniel

[Jim Manico]

I agree with that today but I think we *may* give a different answer in 5/10 years. Medical devices, heath care tracking, health care data collection and mobile devices are all colliding to some degree.

Aloha,
Jim

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

[David Fern]

First, thanks for the great discussions, this is great!

My initial thoughts on mobile medical devices came from the FDA:

Mobile Medical Applications

				Mobile Medical Applications The FDA has a public health responsibility to oversee the safety and effectiveness of a small subset of mobile medical applications that present a potential risk to...
				View on www.fda.gov	Preview by Yahoo

Specifically:

"Mobile applications (apps) can help people manage their own health and wellness, promote healthy living, and gain access to useful information when and where they need it. These tools are being adopted almost as quickly as they can be developed. According to industry estimates, 500 million smartphone users worldwide will be using a health care application by 2015, and by 2018, 50 percent of the more than 3.4 billion smartphone and tablet users will have downloaded mobile health applications (http://www.research2guidance.com/500m-people-will -be-using-healthcare-mobile-applications-in-2015/). These users include health care professionals, consumers, and patients."

I think that the health care device like the heart monitor in the ER is included in the IoT, but an example of a "mobile application" would be one that enables a patient or caregiver to create and send an alert or general emergency notification to first responders. Other examples can be found here:

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf

As a final thought, I agree all of the comments so far and am not pushing to have healthcare specifically included anywhere (it was just a thought and it I did get a lot of great information from the discussions),as Jim say healthcare is coming very quickly.

Thanks,

David

[Milan Singh Thakur]

Hi Team,

Alpha release will be out in few hours :)

But we have added only 10 test cases out of 65.

Will add more in upcoming release.

Reg
MSTG-TEAM

[Milan Singh Thakur]

The Alpha release is out. Check the link for download.

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Guide_Development_Project

Reg,
MSTG Team

[Javi D R]

Hi

The first release looks very promising. Great job here!

Any idea about when will the second release be released?

Thanks

[Jonathan Carter]

We should now distribute the feedback link and gather feedback based on that. Has the guide been tweeted?

--

[Javi D R]

We should then make it public, maybe in owasp menu. I thought it was an internal version not to be disclosed

[Jonathan Carter]

The idea is that we give out an alpha release and then gather feedback via this link: https://goo.gl/t7NIU8

It would be a good idea to promote the alpha release along with the link for feedback. Milan, have you socialized the alpha release?

[Milan Singh Thakur]

Thanx Javi...

Yes Jonathan, i have made the link on OWASP Mobile page.
Indeed we need to publicize the alpha release of guide and gather feedback...

[Jonathan Carter]

Have you done the usual rounds with LinkedIn, OWASP Twitter feeds, project leader list?

[Milan Singh Thakur]

I have posted the release date information on LinkedIn in multiple groups.

I rarely use Twitter. I think we would need you and our team to spread the word even further.

[Jim Manico]

If you prep a message please send a copy to staff (Noreen?) and she can help use the OWASP accounts to pass your message around. :)

Aloha,
Jim

On 9/3/15 7:35 PM, Milan Singh Thakur wrote:

I have posted the release date information on LinkedIn in multiple groups.

I rarely use Twitter. I think we would need you and our team to spread the word even further.

--

You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

[Claudia Casanovas]

Hi Milan,

Please send me the information you posted in LinkedIn.  

I can work with Noreen to spread the word through Facebook and Twitter.

Regards,

Claudia Casanovas

Project Coordinator

[Milan Singh Thakur]

Hi Claudia,

Below is the information i have posted on LinkedIn:

The most awaited OWASP Mobile Security Testing Guide is coming soon...!!
The alpha version is already out. Check the link below to download it.

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Guide_Development_Project

Let us know your feedback at mi...@owasp.org..!!

Regards
Milan

[Javi D R]

Are you happy if i share it through linkedin as well?

[Milan Singh Thakur]

Yeah...!!
Spread the word as much as possible.
Thanx Javi...

[abhinav...@owasp.org]

Cool, I will share fork over the Bangalore OWASP social media accounts too. 

Sent from my iPhone

--

[Claudia Casanovas]

Hi Milan,

Noreen was able to post to facebook and twitter. 

@Noreen - Thank you for your help.

Check out the links below:

 

https://twitter.com/owasp/status/639779479825608704

• RETWEETS56
• FAVORITES40

https://www.facebook.com/groups/owaspfoundation/permalink/839140172873324/
43 likes 5 comments

Just realized I only posted to the FB group. Here's a link to the FB page, just now:

https://www.facebook.com/permalink.php?story_fbid=729012987228113&id=296236753839074

[Milan Singh Thakur]

Thanx Claudia...!!
This will surely catch attention of people :)

Regards
Milan

[Jonathan Carter]

Please include the goo.gl link to the feedback questionnaire 

[Jonathan Carter]

https://goo.gl/t7NIU8

[Milan Singh Thakur]

Thanx Jonathan... will include it in beta and final release.

[Milan Singh Thakur]

Hi Team,

We are set to release Beta Version of Guide on 15-Oct-2015.
Key Changes:

• Intercepting HTTP and HTTPS traffic of Mobile
  
• Emulators and VMs
• 30 Test cases
• Amplify with Drozer

Also please give your feedback by clicking on "Feedback Link on Page 3".
A Checklist for Mobile AppSec will be included in Final Release.

Reg
Milan

[Javi D R]

Hi Milan

Is this happening today?

Thanks

[Milan Singh Thakur]

Hi Team,

Download OWASP-Mobile Security Testing Guide BETA here

https://drive.google.com/file/d/0BxOPagp1jPHWczhwYjRQNzZIekU/view?usp=sharing

Regards
Milan Singh Thakur
OWASP Mobile

[Sina Manavi]

Hi Team,
Thanks for your effort, and thanks Milan as well :)
Best wishes
Sina

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

-- 
_______________________________________________________________
C|EH, C|HFI, Master of Computer Science
Security Advisor and Consultant, Penetration Tester  
Manav...@gmail.com
+601112274183
sinamanavi.wordpress.com

[Er Pragati Singh (IBM)]

Hi Team,

Thanks for success journey...
Thanks Sina Manavi, Milan,Jonathan for your best effort.

For any further concerns or communication Kindly feel free to touch base on
the following contact details. 

Have a great day!
 
 Thanks & Regards 
  Pragati Singh    
 cell: +91-99999-37921,+91-95557-16841
 E-mail- er.prag...@gmail.com
 LinkedIn :-in.linkedin.com/in/erpragatisingh/

 http://viz.me/erpragatisingh

 " Positive communication makes difference.  It may not guarantee success, but helps to achieve it. "

                                                  
                   "Print this mail only if absolutely necessary. Save Paper. Save Trees."

[Milan Singh Thakur]

Hi David,

We are looking for references that we can add in our guide which should help a Newbie to become an advanced penetration tester for Mobile security.

Topics which are focused on understanding mobile architecture, forensics, malware analysis, advanced reverse engineering and out of the box things can be useful.

[Milan Singh Thakur]

Thanks to All the Active and Silent contributors.

Now this is what We call The Owasp Mobile Team effort. :)

Special thanks to OWASP Mobile Team.
We still have long way to go.

Regards
Milan

[Dewhurst Security]

Great work and project!

[Dewhurst Security]

P.S. If there’s anyway I can get involved I’d love to contribute some cycles.

I have left some feedback via the feedback link. Main point being that Certificate Pinning is not yet discussed.

[Javi D R]

Amazing!! Great job

--

[Milan Singh Thakur]

Hi Dewhurst Team,

You can surely contribute...
Feel free to ping me.

Yes, we have not included SSL pinning. Can you help us with a writeup on it?
Details for SSL pinning are available on OWASP Mobile Security page.
We can add it in final release.

Regards
Milan

[Milan Singh Thakur]

Thanx Javi...

I think we should start preparation for cheat sheets for advanced pentest on Mobile based technology.

Regards
Milan

[Javi D R]

Let me know if i can help with that task

Thanks

[Milan Singh Thakur]

Sure Javi...

Anyone else from our Team wanna share hacks based on mobility? It can be related to any technology related to mobility platform.

Regards
Milan

[Jim Manico]

This is a great idea. These cheatsheets can link up to both the mobile and the cheat sheet project.

RIght now we have 2 cheat sheet about mobile. Could any of you take a look at these?

https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet

and

https://www.owasp.org/index.php/Mobile_Jailbreaking_Cheat_Sheet

Thanks all.

Aloha,
Jim

--

You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

[Dewhurst Security]

Hi Milan,

Sure! I will do a write up on Cert Pinning for the document.

Should be ready by the end of this week or beginning of next week.

Thanks,

Ryan 

[Dewhurst Security]

Hi,

Please find attached my initial draft on the Certificate Pinning section.

Page 1 contains the ‘write up’ and page 2 contains the test case.

Any feedback much appreciated.

Are there any other techniques I’ve missed? Or techniques I need to discuss in further detail?

https://docs.google.com/document/d/16sMdEmDk3cGR1qAZwFFCPu_M2t3t4g6sYydTzRu7274/edit?usp=sharing

Thanks,

Ryan

[Milan Singh Thakur]

Hi Ryan,

Thanx for sharing it so quickly.
Will go thru it and update you soon.

Regards
Milan

[Dewhurst Security]

Hi all,

Thank you for everyone’s feedback so far.

I have added a new section "Certificate Pinning Bypass Real World Example” which uses the Facebook Android app as a real world example.

I also wanted to document how to create a cert pinning testbed in the section titled "Certificate Pinning Test Environment” but the example app I wanted to use was not functioning. I have contacted the author who will hopefully be able to help. As I could not complete this section I decided to write the "Certificate Pinning Bypass Real World Example” section.

Feedback welcomed.

https://docs.google.com/document/d/16sMdEmDk3cGR1qAZwFFCPu_M2t3t4g6sYydTzRu7274/edit

Thanks,

Ryan

[Jim Manico]

Consider mentioning how locally installed authorities (vs internet facing authorities) always evade pinning.

http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

[Milan Singh Thakur]

Hi Team,

We are planning for Releasing Mobile AppSec Checklist.

Checklist will be generic for all applications. Depending on requirement Pentester can mark as Compliant/Non-compliant.

Regards
Milan

[Er Pragati Singh (IBM)]

Hi Milan,

Any dates we have decided for same.

--

You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

[Dewhurst Security]

Hi,

Are there any objections to me posting this on my blog to help generate more discussion and feedback?

Thanks,

Ryan

[Milan Singh Thakur]

Hi Ryan,

I dont think OWASP has any objection on reposting stuff from mailing-list/Owasp-site, till the time a reference to OWASP is made :)

Also dont let this stuff become proprietary material.. We are all about free knowledge :)

Regards
Milan

[Milan Singh Thakur]

Hello Geeks,

So we all have been working for long time and contributing to OWASP Mobile as Team.
We have mobile appsec checklist ready. You can download it on below given link.

https://drive.google.com/file/d/0BxOPagp1jPHWQjVxV3RaZ1k1WTg/view?usp=sharing

By following this checklist as Baseline for your Mobile Apps will ensure that your app at-least meet the Security Mark (:

Regards
Milan

[Milan Singh Thakur]

Hi Team,

The OWASP Mobile Guide Final release is going to be finalized and released soon.
Anyone who still wants to add their expertise can ping me on mi...@owasp.org

Regards
Milan
OWASP

[Dewhurst Security]

Hi Milan,

I would be interested in helping out, maybe reviewing or adding some more sections if time permits. Is there a way we can collaborate online?

The ASVS uses Google Docs and Github for collaboration. Could we do the same for the mobile guide?

My preference would be to use Markdown in Github like this PoC I did with the ASVS https://github.com/ethicalhack3r/owasp-asvs-markdown but that's just a suggestion.

Thanks,

Ryan

Ryan Dewhurst

BSc Ethical Hacking for Computer Security, CCNA

Tel: +33 695 321 773

www.dewhurstsecurity.com

--

[Anant Shrivastava]

Hey Ryan,

I had similar question that how can we contribute and collaborate. 

So milan has uploaded the beta docx on google drive. https://drive.google.com/open?id=1Z2nCRfe84D3t3IuEm9idX51lh51uzIerFaCV0Z74tbA this is the editable version of the same. If you could make a github markdown out of it that would be awesome. and i suppose would allow for quicker updates also.

I have made couple of notes today in form of comments and have added some details where i could quickly find but i seriously believe this needs a lot of polishing before going out as a final release.

-Anant

[Dewhurst Security]

Thanks Anant!

I think using Markdown on Github is the easiest way to collaborate, contribute and track changes. I think it should be on OWASP's official Github account though, I'm not sure how this can be done?

I can convert it to Markdown and create a Github repository under my Github account and then it could be forked to the official OWASP account, if this is possible and if the Milan agrees.

Ryan Dewhurst

BSc Ethical Hacking for Computer Security, CCNA

Tel: +33 695 321 773

www.dewhurstsecurity.com

[Anant Shrivastava]

Best way i suppose would be if we directly do it on the OWASP wiki itself just like we do for OWASP Web Testing Guide. But as you said its Milan's call.

-Anant

[Milan Singh Thakur]

Hi Ryan,

It would be better to use Google drive for now. Adding stuff to GitHub so late will require lot of time to be invested. Instead we can use that time in fine tuning the Guide.

Am sure for upcoming projects we can use GitHub from start :)

Regards
Milan

[Milan Singh Thakur]

On wiki...It would be too much content to add and manage.
But let me look into it. I will create a wiki page for it.

[Dewhurst Security]

Hi Milan,

No problem!

I noticed the Certificate Pinning section I wrote hasn't been intergraded yet. If you think it is good enough to be intergraded please do so, or I can do it if that's easier. If not, let me know if you need me to make any further changes.

https://docs.google.com/document/d/16sMdEmDk3cGR1qAZwFFCPu_M2t3t4g6sYydTzRu7274/edit

Thanks,

Ryan

Ryan Dewhurst

BSc Ethical Hacking for Computer Security, CCNA

Tel: +33 695 321 773

www.dewhurstsecurity.com

[Milan Singh Thakur]

Hi Ryan,

Your writeup on certificate pinning is great.
It is definitely going to be part of final release.

I will add you to shared drive.

[Raphael de Almeida]

Hi Milan,

Can you also share the final checklist? I sent you one months ago and would like to know if it was helpful on the creation of the final checklist.

Thanks in advance,

Raphael Denipotti.

--

[Milan Singh Thakur]

Hi Raphael,

Pfb
https://drive.google.com/file/d/0BxOPagp1jPHWQjVxV3RaZ1k1WTg/view?usp=sharing

[Raphael de Almeida]

Tks.

[Amit Lavi]

What about pharming and phishing? I think this should be included as well as apps are seems to be vulnerable to that as well 

Thanks 

Amit 

[Anant Shrivastava]

Hi Milan/Raphael,

Can you upload a editable version version of the Checklist PDF.

I suppose the test cases are jumbled up at best right now. we need to put it in a proper structure.

I propose following section

1) Static App Analysis Check (should cover stuff like can we decompile and if decompiled can we get secret key etc)

2) Dynamic Analysis Check (Run and evaluate this section will also cover business logic issues as well as internal storage and Data transmission issues.)

3) ServerSide Checks (All client server communication issues, TLS etc to be covered here)

4) Platform specific checks (iOS need to be checked for screenshot, android has its own backup issues and so on)

This will keep us focused on specific set of checks.

If you folks can upload excel i will try to sort out the issues in each section and then we can prepare generic issues targetting all platforms 

Note: Also we have not given any importance to hybrid applications in this guilde. stuff like apps made in html5 or webview specific stuff. We need to add checks around that too. (addJSinterface anyone remembers)

Please suggest if this will help or am i distracting others.

-Anant

[Amit Lavi]

Hi Agree with Anant and also we can consider to use risk level of each one with the level of threat or level of risk that it cause the app 

Amit

 

www.appdome.com

Amit Lavi VP Product Management M +972.54.442.3226 T +1.646.504.0962 E amit@appdome.com

[Essobi]

We may want to touch on the use of cross platform app frameworks and how that changes the process as well..

--Kyle

Essobi

[Bao Le]

Hi Milan and Everybody,

I would like to provide some information about Certificate Pinning in Android.

There are some cases i was facing when dealing this testcase:

+ Relying on System TrustManager -> Easy to bypass by import the Proxy CA Cert (i’m using BurpSuite) into Android System (the usual task people do when playing with android pentest to capture HTTPS traffic)

+ Implement custom TrustManager and release with *.BKS KeyStore in Raw Resource of Android Binary, It is not relied on System TrustManager, so we need additional task to break the pinning by using AndroidSSLTrustKiller (it’s a plugin for MobileSubstate)

I have implemented the second technique in my vuln app. Please take a look, but at this time i have disabled HTTPS support on my server. But the code to implement and reference is still available. This my apk, and for more information, please take a look at my Github, it’s my presented section in Vietnam Security Day 2015. I hope it could help to improve our Checklist and make it better. Thanks everyone to spend time with us.

My github: https://github.com/whitehatpanda/VN-SecurityDay-2015

---------------------------------

Thanks & Best regards,

 

LE QUOC BAO

Application Security Researcher

Email:      whiteha...@gmail.com

Mobile:      0915840284

Skype:      whitehat.panda

From: Dewhurst Security
Date: Tuesday, January 19, 2016 at 22:01
To: Milan Singh Thakur
Cc: Anant Shrivastava, OWASP Mobile Top 10 Risks
Subject: Re: Data Call for OWASP Mobile Security Guide - Ends 30 July 2015

[Milan Singh Thakur]

Hi Bao,

This is good and enlightening stuff on certificate pinning.
Will add you to drive, so that you can go thru current guide and add your inputs to it.

[Anant Shrivastava]

Hi All,

as per discussion i have added a basic section. lets try and put all sorts of chcks in that place once we have list of testcases added lets expand them with details. It would be awesome if screenshot used to explain details are either from public apps or from sample apps but refrain from putting any screenshot which reveals personal informations. On that note let me also remind that if a screenshot is taken with semitransparent window the background content could be visible by converting the image to negative.

Hi Bao,

Have you tested the application against : https://github.com/Fuzion24/JustTrustMe (its Xposed module as Substrate is not supported about 4.3)

[Milan Singh Thakur]

Right Anant...
Let's do it collaboratively... :)

[jeroen willemsen]

Hi all,

maybe we could add risks on dependencies/third party libraries in as well? It would be nice to refer to a cheatsheet on how to evaluate a library before you use it within your app.

Grz,

Jeroen

[Raphael de Almeida]

Hi Anant and Everybody,

Follow bellow is the link with the checklist I prepared for mobile app (client side analysis). The first tab contains all the development platforms I've been mapping. The checjlist is divided into 2 categories for client side analysis: Android and iOS. It's still missing Windows Phone and Blackberry which I'm preparing at this right moment.

Milan,

I'm confused about the current checklist you sent. Shouldn't session fixation be a server side check since it's the server that should generate its session token?

Should the final Mobile Security Guide contains specifics situations for Windows and Blackberry, to improve the completion of the document?

Link: https://docs.google.com/spreadsheets/d/1z10PYjpmESFngZpWVjjUooDBFYxKPMnPg8KPoEGfNu0/edit?usp=sharing

Best Regards!!

--