Tonight was already organized the second OWASP Belgium Chapter meeting of this year. Two great (should I say “as usual”?) speakers were invited: Ken van Wyk and Jim Manico. Jim already talked during a chapter meeting last year and I was happy to see it back in our small country. After the classic OWASP news and updates provided by Seba, Ken started the evening with a presentation about “Common iOS Pitfalls vs. OWASP’s iGoat“.
Nobody ignores that mobile devices are a hot topic in the security field today. That’s why OWASP started some projects targeting our favorite toys. Ken’s talk focused on iOS devices with a first part dedicated to the Top 10 Mobile Risks. Mobile devices would be useless without the huge amount of “apps” available. But an app is not only some piece of code running on your device, it uses remote web services. Honestly, apps running off-line are so boring! Could you imagine a game without live scoring system? Since iOS5, apps may use iCloud. The STRIDE principle (“Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privileges“) also applies to mobile devices. According to Ken, main issues are losing the device. And sometimes, the value of the data stored in it are much more valuable than the hardware itself. The second one is the lack of security while using Wi-Fi networks. And what about the Top-10?
- Insecure Data Storage
- Weak Server Side Controls
- Insufficient Transport Layer Protection
- Client Side Injection
- Poor Authorization and Authentication
- Improper Session Handling
- Security Decisions Via Untrusted Inputs
- Side Channel Data Leakage
- Broken Cryptography
- Sensitive Information Disclosure
As usual, most of those issues can be fixed by writing good code. Some best practices given by Ken: Store only the necessary data in your device (avoid like the pest the “remember me” features). Use provided secure containers, do not grant files world readable permissions. Some problems are common with regular web terminals or end-users: weak encryption or ignoring security warnings.
The next part of Ken’s talk focused on his own baby: the iGoat project. This tools is derived from the WebGoat project and is, basically, a learning tool for iOS developers. Based on lessons, security issues are explained, demonstration and details are given to perform remediation.
After a small break, Jim came on stage relaxed as usual and talked about “Access Control Design Best Practices“. Access control is a key component of web applications. He started with an introduction about the different type of attacks on access controls that web applications are facing:
- Vertical (ex: privilege escalation)
- Horizontal (ex: accessing other users data)
- Business logic (ex: abuse of work flow)
Then he detailed some aspects of access controls and why they fail. Example, RBAC (“Role Base Access Control“) is commonly deployed but does not protect against horizontal attacks. Some controls work in “fail open” mode. Some make use of “security by obscurity” for authentication logic. Complex systems with multiple permissions or rules may lead to conflicting permissions. Some systems implements hard coded controls, others have a lack of logic. A good example was provided by Jim: an e-commerce website lacking of logic. It could be possible to buy the most expensive item by paying the smallest amount of money using concurrent sessions in two browsers. A golden rule for authentication is to never depend on untrusted data: never make authentication based on cookies, hidden fields, forms or URL parameters.
Then Jim reviewed some best practices:
- Use RBAC for vertical access controls
- Implement data contextual access control to assign permissions to users in the context of some data items (horizon access control)
- Do not assign permissions on a per user basis
- Perform consistent authentication check routines on all applications pages
- Apply deny privileges last issue allow on a case by case
- Build a centralized authentication mechanism
- Code to the activity/permissions, not the role
- Centralize the access control logic
- Design access control as a filter
- Deny by default and failt securely
- Be able to change a user role in real time
The goal is to code the authentication mechanisms once and never need to change again and no need to redeploy the application every time. Of course, this requires more design / work up front to get right but if properly implemented, the application will remain safe, in case of an unsupported situation!
That’s all for this time. Special thanks to the OWASP team for the Pizza’s. Great idea!