Vortrag: Mobile Security Testing am Beispiel von OWASP Mobile

Die Vienna Mobile Quality Crew und EBCONT proconsult laden zum 3. Meetup der Fachgruppe. Thema: Mobile Security Testing.

Mobile First – denken sich heutzutage nicht nur Developer sondern auch Hacker und Cyberkriminelle. Durch mobile Apps ändern sich auch die Sicherheitstests die im Rahmen einer umfassenden Teststrategie umgesetzt werden sollten.

Wir werden die wichtigsten Security Testkategorien (OWASP-Mobile-Top-10 ) kennenlernen und wie diese am effizientesten getestet werden.

Anhand von Beispielen bekannter Apps werden wir einige Beispiel durchgehen wie man es nicht machen sollte und wie man vermeidet dass seine App wegen einem Hack in der „Heute“ steht.


Ulrich Bayer, SBA Research

Ulrich has completed his Ph.D. in the beginning of 2010 under the guidance of Engin Kirda and Christopher Kruegel at the Vienna University of Technology. In this time Ulrich has performed research in the field of malware analysis and created and led the development of Anubis, a tool for the automated dynamic analysis of malware. He spent 1.5 years as a visiting scientist at the research center Eurecom in France. Ulrich is a CISSP and CEH. He regularly gives courses and talks on secure application development and penetration testing. He is an accredited auditor for ÖNORM A 7700, the official standard for web application security in Austria.

Zur Anmeldung geht es hier.

Mobile ATDD mit XAMARIN und SPECFLOW oder die Frage nach den 3-Amigos

20150423_190036Gestern war es wieder soweit. DIe Vienna Mobile Quality Crew organisierte einen Vortrag über Mobile Testautomation mit XAMARIN und SPECFLOW. Als Gastgeber fungierte SIXSENTIX und lud ins Palais Herberstein.

Im Vortrag präsentierte Christian Hassa (@chassa) und Andreas Willich (@sabotageandy) von TechTalk die Besonderheiten von Crossplattform-Entwicklung mit XAMARIN und im Kontext von ATTD die Testautomation mit SPECFLOW.

Der Bogen spannte sich über die Abstraktion der mobile Plattformen Android und IOS, dem Problem der iOS-UX-Jünger mit XAMARIN Forms und der Vorteile einer gemeinsamen Programmiersprache, hinüber in die Welt der Testautomation über das Mobile-UI als auch Testautomation auf dem Controller-Level.

2015-04-24 09_52_39-Tweets zum Hashtag #vmqc auf TwitterNeue CREW-Mitglieder (Dynatrace, Lomnido) waren auch an Board und machten sich vertraut mit CREW-Regel #3 “Mindestens 10 Minuten Networking, sonst gibt es einen Eintrag ins Captains-Logbuch”. Christian Hassa klärte – obwohl versprochen – die “3-Amigo Frage” bei Pizza und Bier nicht auf. Aber das ist eine andere Geschichte…

Mehr Fotos gibt es hier, die Folien hier, den Twitter-Feed hier.

#Testobject – stellt 20 Rabattcodes für die Mobile Testing Days zur Verfügung

mobiletestingdaysAm 28./29. 5. 2015 finden in Berlin die Mobile Testing Days statt. Die Mobile Testing Days vermitteln Ihnen in zwei Tagen tiefgehend, wie sie ihren Qualitätssicherungprozess passend zu ihrer App aufsetzen, welche Testing Frameworks Sie verwenden können und wie Sie diese kontinuierlich und zielgerichtet einsetzen. Das hochkarätige und umfangreiche Programm richtet sich an alle, die in Mobile-App-Projekten mit dem Thema Qualitätssicherung in Berührung kommen.

TestObject, der Mobile Device Cloud Anbieter und Gold Partner der Mobile Quality Night Vienna 2015, stellt den Mitgliedern der Vienna Mobile Quality Crew 20 Rabattcodes für die Mobile Testing Days zur Verfügung. Mit dem Code erhält man 15% Rabatt und er gilt zusätzlich zum Frühbucher- und Kollegenrabatt. Den Gutscheincode kann man während des Bestellprozesses auf http://mobile-testing-days.de/2015/ eingeben.

Eine E-Mail an vmqcrew@gmail.com reicht und der Gutscheincode kommt frei E-MailPostfach. Ein lesenswertes Interview mit Andreas Lüdeke, Gründer von TestObject, findet ihr hier.

Interview mit Dan Cuellar (@thedancuellar) – A closer look at Appium

dan1Bei der diesjährigen Mobile Quality Night Vienna wird Dan Cuellar (Bild) – der Erfinder von Appium – den Bring Your Own Testautomation (BYOT) Track mit einem Keytalk einleiten. Rudolf Grötz, der Organisator der Mobile Quality Night Vienna – traf sich mit Dan auf einen (virtuellen) Kaffee um ein wenig die Geschichte von Appium zu beleuchten.

RG: Dan, you are the creator of Appium. Tell us something about your inspiration to create a new mobile test automation solution!

DC: I had just started a new job at Zoosk in the autumn of 2011. One of the biggest challenges we were having at the time was the length of our mobile test passes. I couldn’t cut the amount of testing we were doing because of the cost of a mistake on iOS. If we shipped a bad bug, it could be a week until the App Store would allow us to push through a patch. Running manual tests on mobile devices was also much slower and more taxing than in a browser. Humans are not meant to use a mobile phone for 8 hours a day, several days a week.

I looked around and tried out everything that was available at the time. Nothing was without major drawbacks, so I asked my manager for a couple of weeks to try to build something viable. I figured if I could get the Apple-provided automation framework to accept commands in real time and over the wire, I’d have something we could use that was like what we were using for the web. I eventually wrote a loop in Javascript that called eval() on raw javascript commands that it would read as text from sequentially order files on the file system using the shell command utility method in Apple’s UIAutomation. We built a layer in .NET on top of this to use a Selenium like syntax in .NET to build these javascript commands and dump them to files.

RG: When did you realize that other testers are running into the same problems with mobile test automation?

DC: I was selected to speak at Selenium Conference in London in 2012 about an entirely different topic. As part of my presentation, I happened to show a demo of a test running on iOS and Chrome for OS X using the same exact test code. For the rest of the first day of the conference, someone approached me every 30 minutes or so asking how I got an iPhone test to run with Selenium-like syntax. Several people mentioned that I should sign up for a lightning talk on the last day of the conference and show it to all of the attendees.

On the last day of the conference, I got up to do my lightning talk and my laptop was malfunctioning. I remember Jason Huggins, the creator of Selenium, was moderating the lightning talks with a strict time limit of 10 seconds to get the projector working or the talk would be skipped. He started counting down and I think he had just said 1 when finally my screen clicked on and I was able to start the presentation. I’ve always enjoyed the irony that Jason, who eventually played a huge role in getting Appium going, also almost killed it before it ever got off the ground.

RG: Then Jason Huggins came onto stage?

DC: So, after I gave the lightning talk, I didn’t hear anything from anyone for several months. I sent out the source code in C# to a few people, but I don’t think anyone could comprehend it; in hindsight, probably because the open source community tends to not work with MS technologies too often. Eventually, I did get a call from Jason about 4 months later, who told me to meet him in a bar in SoMa in San Francisco. I showed up and explained to him and some of the developers at Sauce Labs how it worked and since they didn’t know C# either, I showed them the prototype version I had written in python way back when I was trying to figure out if it was possible.

Once Jason got the python code in his hands, things really started to happen. He posted it on GitHub and he got a few contributors form outside his company to join in. Things really started to move. Dante Briones, who had seen the demo in London, invited me to speak at the Mobile Test Summit in San Francisco later that year. I recall at that conference, meeting everyone who created most of the relevant tools today in Mobile Automation.

RG: After Mobile Summit 2014 you presented iOS Auto as Appium. Why did iOS Auto get a new name?

DC: Jason always told the story of how he regretted not getting to name Selenium what he actually wanted to call it. I believe he wanted to call it CheckEngine. The gist of the story is that the community went and ran with the name Selenium after a comment someone had made about his tool when comparing it to another tool called Mercury.

Anyways, he suggested that the project get a new name now because the current name was unlikely to stick, not SEO friendly, not available as a twitter handle, etc. Many ideas were thrown out and we settled on AppleCart. A day later, while Jason was reading some of Apple’s guideance on copyright and trademarks and noticed that under the section of examples for names Apple would defend its trademarks against, the first example was “AppleCart”. He called me and informed me of the situation, and we brainstormed for a bit before Jason hit the jackpot. Appium… Selenium for Apps.

RG: Why did you switch from Python to Node.js?

DC: The language history behind Appium is long story. It was first written in python because I was just tinkering and I needed a quick prototyping language. I later converted it to C# so that it could be easily integrated with the existing web automation that we had at Zoosk. I later gave the original python source to Jason and Sauce Labs when I was trying to explain to them how it worked because they didn’t have any .NET programmers. That version was open sourced and for a few months python was the language that people were using to contribute.

At some point once Sauce decided they really wanted to go all in on Appium, they assembled the main contributors behind appium at the time for a meeting to decide how to move forward. Out of this meeting came the decision to convert the project to node.js. I remember being involved in these discussions and thinking that the move to javascript was crazy. I was in the minority along with 2 or 3 other key contributors that felt that we should move the project to Java instead. We ended up losing a couple of really valuable people on the project, but in hindsight this was perhaps one of the most important and beneficial decisions we ever made. After switching to node, our contributions went through the roof almost overnight.

RG: How did Appium get traction after that?

DC: There were a number of different things. The conversion to Javascript, that we already talked about opened the floodgates for contributions. It might be because pretty much every developer at one point or another has had to do something in Javascript, so most people know it. Everyone tends to have a scripting language of choice, so many fewer people know Python because they may use another language for scripting like Ruby, Perl, or bash.

Jonathan Lipps and myself also spoke at a dozen or so conferences in 2013. I remember when Jonathan spoke at the Google Test Automation Conference right after we added Android support as being a huge bump. Writing the Appium Mac OS X app also gave us quite a bunch because it made Appium much simpler to use and install.

One of the funnier things I remember from the earlier days was getting a tweet from whomever runs the @bashooka twitter account, which has a very large following. It had taken us 4 or 5 months to get up to 25 or so stars on Github and the day of that tweet, our stars more than tripled in a couple of hours.

In my opinion, the thing that was most key from the get-go was answering everyone’s questions. Between Jonathan, Matt, myself, and a few others, we personally answered almost every question posted to the discussion group or github every day for the first year or so of the project. This was key. There were a lot of confusing and difficult issues with the earlier versions of Appium and had we not been so diligent with answering people, very few people would have been able to get the product working.

RG: Last year Appium 1.0 was released? What are the steps to hit the next level?

DC: You’ll get a different answer to this depending on who in the project you ask, but here’s mine. First off, there’s a lot of things that we already do with Appium that we need to do better. Installation is brutal and we lose a ton of people just trying to get the whole thing up and running. I’d like to see us do something similar to what Xamarin has done with their install and actually set up the necessary SDKs for iOS / Android if they are not already installed. I’d also like to see our Android implementation improve, and we are currently working on that by moving to newer Google Automation APIs. Id also like to see us find workarounds for the couple of things that are broken in the Apple Automation APIs (swipe since iOS7, video recording off a device, etc.)

My pie-in-the-sky vision for Appium 2.0 is that it automates all apps (desktop and mobile), and while I think it is going to be difficult, I believe it’s quite achievable. We have a working example of automating Mac OS X apps with the JSON wire protocol, but that’s largely held back due to the small Mac app developer community and the lack of OSX developers on the project. It’s possible to do for Windows Phone, but we haven’t integrated it yet due to the hefty requirement of having to have the $5,000 version of Visual Studio to use the Windows Phone Coded UI Test library. The same technique we are using for Windows phone will also work with automating Windows apps without the expensive Visual Studio version. I think I’ll take more of a look at this once Windows 10 is out so that we only have to write one version of it for both phone and desktop.

RG: Which role are you currently playing in the Appium-Universe?

DC: I spend most of my time trying to drum up interest and support by speaking at conferences and meetups and meeting with companies that work with Appium. On the code side of things, I maintain the GUI for Mac OS X and the bindings for Objective-C and (coming soon) Swift. I’m always experimenting with adding new functionality. I spent a week looking at Windows Phone last month for example. I also usually jump in whenever a new version of Xcode or iOS comes out to help solve all the things Apple will break. I’m one of a couple of people on the project that can code in Objective-C and Swift, so I usually end up filling the gaps in that space.

At the moment, I’m currently trying to improve the tapster integration with Appium. I’d like to get robot support fully functional sometime soon.

RG: Appium became a widespread open source test automation tool in mobile device clouds like Sauce Labs, Testobject, & Co. Why?

DC: There a few reasons for this. Setup of the Android and iOS SDKs can be quite difficult for people. There’s a market to take that out of the equation. iOS automation requires one machine per concurrent test you wish to run. The cost to purchase and maintain this infrastructure is something many people want to push off to someone else. Lastly, the fact that we use the same protocol as Selenium has made rolling this out quite simple as many of these providers already had existing browser in the cloud solutions.

RG: Will Selenium 3 be for mobile what “WebDriver” is for the web?

DC: I’m not sure. I don’t really keep as up to date as I probably should as to what’s going on with the Selenium project. Jonathan tends to handle that aspect of the Appium project.

RG: Regarding to a Google-Search-Graph Appium is the rising star of test automation tools. What are the USP’s of Appium making this happen?

2015-04-12 20_27_41-Dan Cuellar - Interview - Google DocsDC: If you look at the other tools on the graph, Appium differentiates itself in three big ways. The first is that Appium provides the familiar interface of the Selenium protocol to people and we’ve found that people latch on quite strongly to that analogy. The second is that Appium let’s you choose what language you want to write your tests in. That’s a huge advantage because you appeal to all developers because you aren’t choosing the language for them. Lastly, Appium does not require app modification, so you are not excluding the group of developers that only write tests and do not write mobile applications. Appium does not require you to be a mobile app developer to use it.

In addition to all of those reasons, Appium has an absolutely rabid community behind it with over 100 contributors and over 100,000 users. Appium has a discussion group with over a hundred posts a day coming in at some times. The contributors push out several dozen changes a week and several times a month one of them is out somewhere around the world speaking at a conference trying to engage more and more people. I’ve always felt that our biggest differentiator is our community. Many open source projects are cold and unresponsive. You can submit a patch or post a question and not hear back from weeks or months. That does not happen very often with the Appium project. We’re very approachable and we don’t have any bad apples in the project that are toxic to deal with or who cause problems or conflict.

RG: Dan, thank you for this interview!

Workshop Part 1: UX-Guideline entwickeln für mobi.senior.A

2015-04-04 21_07_40-Workshop Part 1_ UX-Guideline entwickeln für mobi.senior.A - Vienna Mobile QualiDas mobi.senior.A (www.mobiseniora.at) Projekt ist ein Forschungsprojekt, bei dem im Rahmen einer empirischen Erhebung (unter anderem mit Usability-Tests) die Anforderungen, Motivationen, Aneignungsstrategien, Hindernisse und Zugänge ältere Menschen zu Mobilgeräten und deren Applikationen untersucht wurden.

Wir möchten zum einen die gewonnen Erkenntnisse mit Interessierten (Tester, UX-Profis, App-Entwickler, Product Owner) teilen (hier geht es uns auch um eine Sensibilisierung für das Thema) und zum anderen in einer gemeinsamen Diskussion Input erhalten, wo es design-, usability- und plattformspezifische Hindernisse und Möglichkeiten gibt.

D.h. wir suchen Teilnehmer/innen, die sich auf diesen Gebieten auskennen und Input geben können.

Anmeldungen via Meetup.