Jerry Hoff - Getting a Handle on Mobile Security

### Overview In this presentation, Jerry Hoff addresses the growing industry obsession with mobile device security and contrasts it with the reality of application risk. Organizations and executives often overemphasize securing the physical mobile client—likely because it is a tangible, handheld item—while continuing to neglect vulnerable backend server infrastructure. Hoff argues that while mobile security matters, server-side flaws generally pose far greater organizational risk, and security teams must adopt a practical, risk-based approach rather than chasing extreme controls or relying blindly on top-ten compliance lists.

### Key Topics - **Client vs. Server Risk Allocation**: Evaluating where development time and security budget should actually be spent. Hoff notes that search trends and client demands focus heavily on mobile security, even though server backends remain brittle and harbor severe vulnerabilities. - **Mobile Development Frameworks & Attack Surfaces**: Mobile apps are built across diverse stacks, from native platforms (Objective-C, Swift, Java, C++) to web-container hybrids like PhoneGap using HTML5 and JavaScript. Technologies that wrap native phone APIs in JavaScript introduce unique risks. - **App Store Realities & Decompilation**: Exploring the false sense of security provided by app store review processes. Decompiling mobile apps is trivially easy (e.g., using `dex2jar` and `jad` on Android, or analyzing binaries and plist files on iOS), showing that client-side code cannot hide secrets or enforce security rules.

### Technical Details Hoff highlights three critical foundational areas developers must focus on before considering advanced controls like anti-jailbreaking mechanisms: 1. **Insufficient Transport Layer Protection**: Mobile traffic should strictly use TLS/HTTPS. Developers frequently fail to properly validate certificates or fail to prevent insecure connections in thick clients. Intercepting traffic using local proxies like OWASP ZAP demonstrates widespread insecure communication and data leakage to third parties. Hoff also mentions a PayPal vulnerability involving fetching JavaScript over non-HTTPS connections, which creates remote code execution risks when native wrappers interpret unencrypted scripts. 2. **Unsafe Data Storage on the Device**: Mobile apps routinely scatter data across local storage mechanisms—SQLite databases, SD cards, local file systems, iOS Keychain, user defaults, plist files, and log files. Tools like iFunBox reveal that apps often leave sensitive artifacts accessible on un-jailbroken devices. Hoff references the public reaction to Starbucks storing unencrypted passwords locally. Unless required by strict business models, sensitive data should not reside permanently on lost-prone mobile devices. 3. **Business Logic & Insecure Direct Object References (IDOR) on the Device**: Developers often trust client-side state, storing flags like `isPaid` locally in editable plist files or delegating access control choices to client requests. Because client parameters are easily altered via proxies or binary tampering, access control and business logic validation must remain on the server.

Hoff compares these issues against common web vulnerabilities, emphasizing that high-impact threats like SQL injection, broken authentication, and session flaws execute on the server. Cross-site scripting (XSS) is typically less prevalent in native mobile clients than web apps, though hybrid apps using PhoneGap can elevate XSS impacts.

### Takeaways Security programs should prioritize securing the backend server where the highest organizational damage occurs before over-engineering client-side protections. When developing mobile apps, teams should master the fundamentals—transport encryption, avoiding sensitive local storage, and enforcing business logic and authorization strictly on the server. Developers should view checklists like the OWASP Mobile Top 10 through a risk-based lens, tailoring defenses to their specific risk tolerance rather than treating generic lists as absolute dogma.