30
Security in Xamarin Mar/n Alderson Codified Security Twi9er: @getCodified

Xamarin security talk slideshare

Embed Size (px)

Citation preview

Security in XamarinMar/n Alderson Codified Security

Twi9er: @getCodified

Background✦ Mar/n Alderson

✦ CTO of Codified Security

✦ Been using Xamarin since the MonoTouch days

✦ Loves C#

✦ Care about security

Mobile app security is bad

Why is this?

Mobile app development is hard

Many compe/ng pressures:

✦ UI - users expect 60fps crazy precise animated interac/on even on low end

✦ Endless OS updates, API changes, etc

✦ New devices (iPad, iPhone6, iPhone 6+, Apple Watch…)

✦ Loads of different networks to worry about (3G, 4G, WiFi, VPN)

-Some tech CEO

“I want a feature release every week”

Security moves to bo9om of list

✦ Lots of code churn, refactoring, SDK integra/on

✦ Hard to audit when code is being released so quickly

✦ Tends to fall off bo9om of the list

✦ Isn’t obvious to the user - features, UI are

Know the threats.

Rule #1: You are shipping your code

✦ You are shipping a binary of all your code to all users that can download the

app

✦ Including gated features (premium features, admin features)

✦ This isn’t web development!

Protec/ng your code✦ Obfuscators sort of work, just make it harder for prying eyes, not impossible

✦ Don’t ship super secret business logic in the app

✦ Use enterprise distribu/on (iOS & Android) if you have versions for ‘VIP’,

‘backend’ users

✦ Consider using WebViews and render only to authen/cated users on server

if it needs to be public

SSL/TLS✦ Essen/al. Always use it.

✦ Public networks (WiFi, etc) are horribly insecure

✦ You owe it to your users to encrypt their traffic data & protect their privacy

✦ Not always obvious what has privacy implica/ons

✦ Don’t assume it’s “just for important stuff”

h9ps://

Dumb stuff:✦ Seen developers just ignoring SSL cert/hostname errors in code

✦ Be careful using CerBficateManager class or playing with internals of TLS.

✦ Probably because it doesn’t work in dev and was quick fix, forgo9en about

✦ This makes it totally pointless

✦ Please don’t.

✦ Makes me sad.

Don’t leave debug code in produc/on.

✦ Many terrible examples of this.

✦ It will s/ll get compiled into the app

✦ Onen leave debug/staging API environments in

✦ Makes it easy for your web & network infrastructure to get pwned

Don’t console log in produc/on✦ Especially on Android - other apps can read on certain Android versions.

✦ Worst example was a famous London FinTech co

✦ Logged to Android log every REST call

✦ Included plaintext passwords, ccv, cc#, exp, address

✦ See this a lot. Use proper remote logging, not system logs!

WebViews can be dangerous✦ Well sandboxed normally

✦ But is web code, same rules apply

✦ Same rules apply (XSS, CSRF, etc)

✦ Be careful adding C#->JS interfaces

✦ Allows XSS, MITM in WebView to start accessing the rest of your app

WebView.AddJavascriptInterface()

App files

✦ More applicable to Android (iOS is more sandboxed - at the moment)

✦ Encrypt SQLite databases

✦ Especially if you store important data there

✦ SQLCipher is good and OSS

AndroidManifest.xml

<application android:debuggable="true">

AndroidManifest.xml

<application android:allowBackup="true">

AndroidManifest.xml

WRITE_EXTERNAL_STORAGE

Conclusion

✦ This is a quick tour of some of the stuff involved in secure code

✦ Exploits quickly chain - be careful

✦ Most exploits are easy to protect against

✦ Haven’t covered backends here which is another world

Our tool✦ www.codifiedsecurity.com

✦ Scans for a lot of these problems automa/cally

✦ We’re based in London

✦ Integrates with CI/CD

✦ Happy to give free accounts, we just launched Xamarin support.