Mobile Application Security

Mobile Security atau Keamanan seluler, adalah perlindungan ponsel cerdas, tablet, dan laptop dari ancaman yang terkait dengan komputasi nirkabel. Ini menjadi semakin penting dalam komputasi seluler. Yang menjadi perhatian khusus adalah keamanan informasi pribadi dan bisnis yang sekarang disimpan di smartphone.

I. Pengantar Mobile Security

Semakin banyak pengguna dan bisnis menggunakan smartphone untuk berkomunikasi, tetapi juga untuk merencanakan dan mengatur pekerjaan pengguna dan juga kehidupan pribadi. Di dalam perusahaan, teknologi ini menyebabkan perubahan besar dalam organisasi sistem informasi dan oleh karena itu menjadi sumber risiko baru.

Memang, ponsel cerdas mengumpulkan dan mengumpulkan semakin banyak informasi sensitif yang aksesnya harus dikontrol untuk melindungi privasi pengguna dan kekayaan intelektual perusahaan.

5 Trend dengan implikasi besar terhadap dunia usaha dan industry :

1. Mobile adalah kebutuhan primer, karna 91% pengguna mobile meletakkan divais mereka dalam jangkauan 100% setiap waktu
2. Insights dari data mobile membuka peluang baru, karna 75% pembeli mobile bereaksi setelah menerima location based messages
3. Mobile berarti bertransaksi, karna 96% peningkatan dari tahun ke tahun pada event khusus penjualan spt. Harbolnas
4. Mobile harus menghasilkan continuous brand experience, karna 90% pengguna memanfaatkan media sosial sebagai sarana berbagi pengalaman
5. Mobile memungkinkan Internet of Things, karna Koneksi Machine-to-machine global akan meningkat dari 2 milyar di 2011 hingga 18 milyar di akhir 2022

Tantangan Mobile Security

1. 1 dari 20 perangkat mobile mengalami pencurian
2. 70% spam pada perangkat mobile adalah penipuan terhadap layanan finansial
3. 350% peningkatan jumlah WiFi hotspots membuka kesempatan lebih besar terhadap serangan “man-in-the middle” (628 juta public Wi-Fi hotspots di tahun 2023)
4. 155% peningkatan 77% pertumbuhan Android malware per tahun mobile malware
5. 10 Milyar download Android app downloads – 90% dari 100 aplikasi teratas pernah di-hack.

Tantangan Mobile Security thd industry

1. Menjamin Separasi Data & Memberikan Perlindungan Data
• Personal vs korporat
• Data leakage dari dan ke dalam perusahaan
• Partial wipe vs. device wipe vs legally defensible wipe
• Data policies
2. Mendukung BYOD/ Konsumerisasi thd Trend TI
• Berbagai platform dan varian perangkat
• Berbagai provider
• Managed devices (B2E)
• Unmanaged devices (B2B,B2E, B2C)
• Endpoint policies
• Threat protection
3. Menyediakan secure access ke aplikasi & data bisnis/perusahaan
• Identitas user dan perangkat
• Autentikasi, Autorisasi dan Federasi Akses
• User policies
• Secure Connectivity
4. Mengembangkan Secure Application
• Siklus Hidup Aplikasi (App. life-cycle)
• Analisa Statik & Dinamik
• Analisa Call dan data flow
• Application policies
5. Disain & Membangun Postur Security yang adaptif
• Policy Management: Location, Geo, Roles, Responsetime policies
• Security Intelligence
• Mekanisme Pelaporan

Gambaran Mobile Security

Cara menghadapi Tantangan dan Ancaman Keamanan?

1. Device Management and Security
• Multiple device platforms and variants
• Managed devices (B2E)
• Data separation and protection
• Threat protection
2. Network and Data Management and Security
• Identity management & menjaga mobilitas
• Manajemen policy & pengawasan
• Secure connectivity
• Security intelligence and reporting
3. Application Management and Security
• Kinerja & lifecycle aplikasi
• Vulnerability & penetration testing
• Manajemen Policy: location, geo, roles, response-time

Tiga Aspek dalam Mobile Security

A. Device Security: Proteksi Data & Aplikasi pada Perangkat

1. Cegah bocor/hilang-nya Data
• Data Wipe
• Enkripsi Data Lokal
2. Batasi Akses ke Perangkat
• Device lock
3. Mitigasi terhadap ancaman vulnerabilities
• Anti-malware
• Push updates
• Deteksi jailbreak
• Deteksi non-compliance
4. Batasi Akses ke App.
• App disable
• Autentikasi User
5. Terapkan Kebijakan Korporasi

B. Network Security: Proteksi Sistem Perusahaan & Menyediakan Secure Access

1. Secure access ke sistem perusahaan
• VPN
2. Cegah unauthorized access ke sistem perusahaan
• Identitas
• Manajemen Sertifikat
• Autentikasi
• Autorisasi
• Audit
3. Lindungi user dari ancaman internet
• Threat protection
4. Tegakkan Kebijakan Korporat
• Deteksi Anomali
• Terapkan prosedur keamanan untuk akses ke data sensitive.

C. Application Security: Build, Test & Run Secure Mobile Apps

1. Development Best Practices
• Development tools yang memastikan security policies
2. Test App mobile terhadap threats
• Penetration Testing
• Vulnerability Testing
3. Pengaturan Akses Offline
• Enkripsi pada Penyimpanan Credentials lokal
4. Pendistribusian app mobile yg aman
• App Store Resmi
5. Cegah penggunaan app yang mengalami perubahan tidak resmi
• Deteksi dan nonaktifkan compromised apps

II. Mobile Device Security

Perangkat mobile

1. Mobile computers:
• Mayoritas smartphone, tablet
• Sensor: GPS, camera, accelerometer, dll.
• Computation: powerful CPUs (≥ 1 GHz, multi-core)
• Communication: cellular/4G, Wi-Fi, near field communication (NFC), dll.
2. Mayoritas terkoneksi ke jaringan seluler: billing sistem
3. >7 milyar smartphone terjual dalam 5 tahun terakhir (1,5 milyar per tahun)

Mobile Threats & Attacks

1. Perangkat Mobile adalah target yang sangat menarik:
• Banyak yang menyimpan informasi pribadi: email, calendar, daftar kontak, gambar/foto/video, dll.
• Juga informasi sensitive dari organisasi/tempat kerjanya…
• Muat di kantong, mudah hilang/dicuri
• Terhubung ke sistem pembayaran: SMS/MMS (mobile operator), in-app purchases (kartu kredit/fintech), dll.
• Banyak perangkat baru memiliki near field communications (NFC), dapat digunakan untuk pembayaran contactless, dll.
• Perangkat mobile menjadi alat pembayaran
• Masalah Location privacy
2. NFC-based billing sistem vulnerabilities

Kehilangan/Pencurian

Banyak perangkat mobile hilang, dicuri tiap tahun

1. 113 kasus kehilangan/pencurian tiap menit di A.S. (Indonesia?)
2. 56% pernah “ketinggalan” atau “lupa” tiap bulannya
3. Lookout Security pada Android Device manager menemukan smartphone senilai $2.5 milyar di tahun 2011 (sekarang?)
4. Symantec melakukan eksperimen dengan “menghilangkan” 50 smartphones di berbagai kota di A.S.:
• 96% di akses oleh yang menemukan.
• 80% dari penemu mencoba mengakses data “sensitive” dalam perangkat.

Device Malware

1. iOS malware: sangat jarang (namun malware baru tetap ada)
2. Statista: 10,5 juta malware (2019), 190 ribu malware baru per bulan.
3. Pertumbuhan Android malware terus meningkat ($$$)
4. Kategori malware utama:
• Trojans
• Monitoring apps/spyware
• Adware
• Botnets
5. Beberapa contoh malware telah

Penyitaan Perangkat

Penegakan hukum: bila anda ditahan/ditangkap, polisi akan mencari perangkat mobile anda tanpa surat penggeledahan

1. Alasan: mencegah tersangka menghancurkan bukti digital
2. Sangat mudah melanggar hukum (overcriminalization)
• Tingkat kejahatan: pembunuhan, penipuan, dll. vs. pembajakan/pelanggaran kecil.
• Konten-konten illegal (barang bajakan, pornografi, dll)
3. Mudah bagi penegak hokum untuk mengekstraksi data dari perangkat mobile (forensics)

Pelaporan Lokasi

1. MAC, Bluetooth Addresses, IMEI, IMSI dll. bersifat globally unique
2. Infrastruktur Mobile mampu menentukan lokasi anda (Location based service)
3. Peer-to-Peer ad hoc mobile communication (mis: digunakan untuk sistem pelacakan pandemic Covid-19)

Mobile Access Control

1. Sangat mudah bagi penyerang untuk mengendalikan perangkat mobile jika memiliki akses fisik
• Terutama jika tidak diterapkan sistem autentikasi pada perangkat
• Kemudian perangkat dapat digunakan untuk join botnet, kirim SMS spam, dll.
2. Perlu access controls pada perangkat mobile
• Authentication, Authorization, Accountability
• Alur Autentikasi:
• Request access
• Supplication (user memasukkan identitas, mis. Nama/no telp/email)
• Authentication (sistem memastikan user adalah ybs.)
• Authorization (sistem menentukan apa yang boleh/tidak boleh dilakukan user)

Kategori Autentikasi

Autentikasi umumnya didasarkan pada:

1. Sesuatu yang diketahui supplicant
• Password/passphrase
• Unlock pattern
2. Sesuatu yang dimiliki supplicant
• Kartu kunci magnetic
• Smart card
• Token device
3. Sesuatu bagian dari supplicant
• Sidik jari
• Scan Retina

Autentikasi: Passwords

1. Paling murah, paling sederhana
2. Berfungsi baik untuk banyak aplikasi
3. Tapi juga bentuk access control yang paling lemah
• Password users’ malas: 1234, password, rahasia, dll.
• Dapat dengan mudah dipecahkan menggunakan serangan dictionary, dan brute force
4. Diperlukan kendali administrative yang kuat agar lebih efektif
• Panjang minimum/kompleksitas simbol
• Umur password
• Pembatasan jumlah upaya password yang gagal (failed attempts)

Autentikasi: Smart Cards/Security Tokens

1. Lebih mahal, sulit untuk diimplementasikan
2. Kelemahan: rentan hilang atau dicuri
3. Sangat kuat bila dikombinasikand dengan bentuk autentikasi lain, mis. Password
4. Belum tentu cocok untuk semua aplikasi

Autentikasi: Biometrics

1. Lebih mahal/sulit diimplementasikan
2. Rentan kesalahan:
• False negatives: menolak user yg berhak
• False positives: menerima user yg tidak berhak
3. Autentikasi yang kuat apabila berfungsi baik
4. Tidak cocok untuk semua aplikasi:
• Namun Fingerprint readers mulai menjadi fitur umum untuk perangkat mobile.

Autentikasi: Pattern Lock

1. Alur Swipe sepanjang 4–9 pada grid 3 x 3
2. Mudah digunakan, cocok untuk perangkat mobile
3. Masalahnya:
• 389,112 pola yang mungkin; (masih kalah dengan 456,976 kemungkinan untuk karakter yang case-insensitive pada password alfabetik!)
• Penyerang dapat melihat pola berdasarkan residu lemak jari pada layer (atau pola goresan)

Autentikasi: Perbandingan

Kebocoran Informasi Pada Perangkat Mobile

1. Berbagai sumber informasi pada perangkat mobile:
• Internal (mis.: GPS location, IMEI, dll.)
• Eksternal (mis: Marketplace, Bank, Fintech, dll.)
2. Aplikasi mobile pihak ketiga dapat membocorkan informasi ke pihak luar:
• Mengirim device ID (IMEI/EID), daftar kontak, location, dll
• App meminta izin untuk mengakses informasi tsb.; users dapat mengabaikan!
• App dapat memotong alur (intercept) info yang dikirim, dan mengirimkannya ke tujuan berbeda!
3. Motif:
• Monitor aktivitas karyawan menggunakan accelerometers
• Ads, market research (meliputi user location, perilakunya, dll.)
• Malicious
4. Bagaimana cara kita memproteksi diri terhadap kebocoran informasi?

Information Flow Tracking (IFT)

1. IFT melacak tiap alur informasi dari internal ke eksternal
• Tiap flow diberi tag, mis. “untrusted”
• Tag terpropagasi sebagai aliran information antara sumber internal dan external
• Alarm terjadi bila data dikirim ke pihak ketiga
2. Permasalahan:
• Waktu eksekusi yg singkat, space overhead
• Sumber informasi yang banyak

TaintDroid

1. Enck et al., OSDI 2010
2. Sistem IFT pada Android 2.1
• firmware sistem (bukan app)
• Memodifikasi Android’s Dalvik VM, tracks info flows across methods, classes, files
• Informasi yang di-telusuri:
• Sensors: GPS, camera, accelerometer, microphone
• Internal info: contacts, phone #, IMEI, IMSI, Google acct
• External info: network, SMS
• Memberitahu user bila terjadi kebocoran info.

Proteksi Location Privacy

1. Regulasi yang kuat
• Korporat
• Individual
2. Alamat MAC dan Bluetooth yang dinamis?
• Masalah: Collision
• Seberapa sering berubah?
3. Komunikasi berbasis Proxy:
• Dummy device sebagai proxy
• Group communications

III. iOS Security

Arsitektur Sistem iOS

Boot sequence:

1. Bootloader, kernel, extensions, baseband firmware semua memiliki cryptographic signatures
2. Root of trust: sudah terpasang pada boot ROM saat fabrikasi
3. Tiap component’s signature terverifikasi
4. Bila ada signature yang tidak cocok, mis: “connect to iTunes” akan muncul di layer memberitahukan ke user

Software update:

1. Tidak dapat menginstall iOS dengan versi lebih lama pada sebuah iDevice; mis: jika device menjalankan iOS 5.1.1, maka tidak dapat menginstall iOS 4
2. Perangkat secara kriptografis mengecek komponen, mengirim ke Apple install server dgn nonce, device ID
• Nonce: nilai acak yang hanya digunakan 1 kali
• Mencegah penyerang untuk “mengulang” nilainya
3. Langkah pengecekan Server; jika diperbolehkan, server akan menambah device ID ke dalam daftar pemeriksaan, dan men-sign semuanya 

iOS Apps & App Store

1. Semua iOS apps di-signed oleh Apple (bukan oleh developer)
2. App pihak ke-tiga akan di-signed bila telah melewati:
• Developer ID verification (individual, company)
• Review: bugs, work correctly (program analysis)
3. Tiap app di-sandboxed pada direktori masing-masing:
• Tidak dapat berkomunikasi dengan app lain
• Apps membutuhkan signed “entitlements” agar dapat mengakses data user.
4. Proteksi App lain:
• Address Space Layout Randomization (ASLR) untuk semua app (mencegah heap-spraying yang umumnya dilakukan oleh malware)
• ARM eXecute Never (XN) bit set untuk semua memory pages

iOS Data Protection

1. Tiap iDevice memiliki hardware-accelerated crypto operations (AES-256)
2. Effaceable Storage: fitur keamanan dengan menghapus crypto keys dari flash memory
• “Erase all content and settings” akan menghapus semua data user menggunakan Effaceable Storage (baik secara local maupun remote)
• Berinteraksi dengan mobile device management (MDM), Exchange ActiveSync servers
• Developer dapat menggunakan API untuk mengamankan file, dan database storage
3. Passcodes
• Admins mengharuskan penggunaan numeric, alphanumeric, dll.
• Akan menghapus device (wipe) bila melampaui 10 failed login

iOS Security

1. Built-in support untuk SSLv3, TLS, VPNs
2. Extensive administrative controls:
• Password policies
• Disable device features, e.g., camera
• Disable Siri
• Remote wipe
3. Pernah terjadi: Apps can access contacts tanpa izin (telah diperbaiki pada iOS 6)

IV. Android Security

Android Security Architecture

Tujuan Pengamanan secara umum:

1. Proteksi data user
2. Proteksi system resources (hardware, software)
3. Melakukan isolasi aplikasi 

Foundations of Android Security    

Application Isolation and Permission Requirement:

1. Mandatory application sandbox for all applications
2. Secure inter-process communication
3. System-built and user-defined permissions
4. Application signing

5 lapisan dalam arsitektur android: Linux Kernel, Libraries, Android Runtime, Application Framework dan Application

1. Mobile app atau Mobile application adalah program komputer yang dirancang untuk berjalan pada peranti bergerak seperti ponsel/tablet atau jam tangan. Aplikasi mobil sering kali dianggap sebagai kebalikan dari aplikasi desktop yang berjalan di komputer desktop, dan dengan aplikasi web yang berjalan di browser web perangkat.
2. App Framework adalah layanan sistem untuk mendukung aplikasi. Mis: Location manager untuk data lokasi, Telephony manager untuk akses ke telefoni.
3. Libraries dalam ilmu komputer adalah koleksi dari rutin-rutin program yang digunakan untuk membangun dan mengembangkan perangkat lunak. Pustaka umumnya mengandung kode program dan data pembantu, yang menyediakan layanan-layanan kepada program-program independen
4. Android Runtime: Core libraries (semua library java), Dalvik VM (sandbox untuk menjalankan aplikasi dalam isolated environment)
5. Kernel Linux adalah kernel yang digunakan dalam sistem operasi GNU/Linux. Kernel ini merupakan turunan dari keluarga sistem operasi UNIX, dirilis dengan menggunakan lisensi GNU General Public License, dan dikembangkan oleh pemrogram di seluruh dunia.

Android software stack

1. Each component assumes that the components below are properly secured.
2. All code above the Linux Kernel is restricted by the Application Sandbox
3. Linux kernel is responsible sandboxing application
• “mutually distrusting principals”
• Default access to only its own data
4. The app Sandbox apps can talk to other apps only via Intents (message), IPC, and ContentProviders
5. To escape sandbox, permissions is needed

Security pada tingkat Linux kernel

1. Unix-based file/directory permission model
2. User-based permissions model
3. Isolasi proses: Tiap Aplikasi memiliki sandbox sendiri yang didasarkan pada separasi antar proses: agar sumber daya user dapat dilindungi dari satu proses terhadap yang lainnya; masing-masing jalan pada proses Linuxnya sendiri untuk memastikan hanya dapat melakukan Inter-Process communication (IPC)

Contohnya:

1. Mencegah user A untuk membaca file milik user B
2. Memastikan user A tidak mengakses CPU, memory dari user B.
3. Memastikan bahwa user A tidak dapat mengakses divais yang digunakan oleh user B (mis. telephony, GPS, Bluetooth)

Application Sandbox

1. The Android sistem assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process.
2. When launching a new Activity, the new process isn’t going to run as the launcher but with its own identity with the permission specified by the developer.
3. The developer of that application has ensured that it will not do anything the phone’s user didn’t intend. Any program can ask Activity Manager to launch almost any other application, which runs with that application’s UID.
4. application A is not allowed to do something malicious like to read application B's data or dial the phone without permission.
5. All libraries, application runtime, and all applications run within the Application Sandbox in the kernel.

Application Sandbox

1. Each application runs within its own UID and VM
2. Default privilege separation model
3. Instant security features
• Resource sharing
• CPU, Memory
• Data protection
• FS permissions
• Authenticated IPC
• Unix domain sockets
4. Place access controls close to the resource, not in the VM
5. /data/data directory is where to see all application’s data to be present.

Permissions

Application Defined but User Granted Permissions

1. Permission are declared by the Developers of the Application
2. xml file will have all the details related to the Permissions
3. The User will be asked to accept/deny the Permissions before the installation of the Application
4. Earlier, we could only Accept All/Deny All, but now we can select which permissions we want to give to the application.

Permissions

1. Whitelist model
• Allow minimal access by default
• Allow for user accepted access to resources
2. Ask users less questions
3. Make questions more understandable
4. 194 permissions
• More ⇒ granularity
• Less ⇒ understandability

Encryption

1. Encryption Android 3.0+ provides full filesystem encryption, so all user data can be encrypted in the kernel
2. For a lost or stolen device, full filesystem encryption on Android devices uses the device password to protect the encryption key, so modifying the bootloader or operating sistem is not sufficient to access user data without the user’s device password.

Android App Signature

1. Semua Aplikasi Android harus signed, tetapi umumnya self-signed
2. Mengapa self signed?
• App Market menyimpan identitas dari akun developer
• Tidak ada CA di Google, Google tidak memiliki kendali terpusat terhadap sertifikat pada app’s signature
• Tidak ada mekanisme trust pada aplikasi.  No "magic key"
3. Apakah makna dari signature pada Android App?
• Author-update
• Berdasarkan skema signature, private key milik developer digunakan untuk men-sign sebuah app atau sebuah pesan; siapapun dapat memeriksa signature menggunakan public key. 

V. Secure Design & Coding

Asumsi Keamanan

Security through obscurity: Mengandalkan fakta bahwa awalnya penyerang tidak memiliki pengetahuan yang dapat membahayakan kita.

1. Contoh: “Jika penyerang mengarahkan browsernya ke alamat http://foo.com/passwords.txt, maka mereka akan mendapatkan password. Namun tidak ada yang tahu file tersebut ada, sehingga kita aman."
2. Contoh: “Aplikasi kita menyimpan data sensitive menggunakan SQLite yang tersimpan pada sebuah file di file system lokal."
3. Contoh: “Database autentikasi kita mati selama 2 menit tiap malam pada jam 4am. Saat itu, user manapun dapat login tanpa autentikasi. Tetapi tidak ada yang tahu hal ini, dan kemungkinan ada orang mencoba login pada waktu tersebut sangat kecil. " 

Guessing files/directories

Security through obscurity: Many reachable files/resources are hidden only by the fact that there is no link to them.

Try common file/folder/commands to see what happens:

1. /etc/passwd , /etc/shadow , cat, ls, grep
2. guess file names based on others
• page11.php --> page12.php
• loginfailure.jsp -> loginsuccess.jsp
• accounts/fred.html --> accounts/sue.html
3. brute force / web spiders
4. port scanners

Secure authentication

1. Force users to log in to your system before performing sensitive operations
2. Use secure protocols (https, etc.) to prevent sniffing
• Some sites use HTTPS only for login page, then switch back to regular HTTP for future page views.  Is this bad?
3. Force users to use strong passwords
• not "password", or "abc", or same as their user name, etc.

Password cracking

Password cracking: Guessing the passwords of privileged users of your system.

1. How attack is performed:
• brute force attack: Attacker uses software that sequentially tries every possible password.
• dictionary attack: Attacker uses software that sequentially tries passwords based on words in a dictionary.
• every word in the dictionary
• combinations of words, numbers, etc.
2. What you can do about it:
• Force users to have secure passwords.
• Block an IP address from logging in after N failed attempts.

Principle of least privilege

Principle of least privilege: Granting just enough authority to get the job done (no more!).

1. Examples:
• Code should not "run as root" or as a highly privileged user unless absolutely necessary.
• A web server should only be given access to the set of HTML files that the web server is supposed to serve.
2. Turn off unnecessary services on your server
• disable SSH, VNC, sendmail, etc.
• close all ports except 80, and any
• others needed for web traffic

Sanitizing inputs

Sanitizing inputs: Encoding and filtering untrusted user input before accepting it into a trusted system.

1. Ensure that accepted data is the right type, format, length...
2. Disallow entry of bad data into a graphical form.
3. Remove any SQL code from submitted user names.
4. Encode/sanitize input text that is displayed back to the user.

SQL Injection

SQL injection: Causing undesired SQL queries to be run on your database.

1. Often caused when untrusted input is pasted into a SQL query
• PHP: "SELECT * FROM Users WHERE name='$name’ or 1 = 1;";
2. specify a user name of: x' OR 'a'='a
• SELECT * FROM Users WHERE name='x' OR 'a'='a';

Verifying code is secure

1. Before code is written:
• considering security in the design process
2. As code is being written:
• code reviews
• code security audits
• pair programming
3. After code has been written:
• walkthroughs
• system security audits
• system/functional security testing
• penetration tests

Security audits

1. Security audit: A series of checks and questions to assess the security of your system.
• can be done by an internal or external auditor
• best if done as a process, not an individual event
2. Penetration test: Targeted white-hat attempt to compromise your system's security.
3. Risk analysis: Assessment of relative risks of what can go wrong when security is compromised.

Security audit questions

1. Does your system require secure authentication with passwords?
2. Are passwords difficult to crack?
3. Are there access control lists (ACLs) in place on network devices?
4. Are there audit logs to record who accesses data?
5. Are the audit logs reviewed?
6. Are your OS security settings up to accepted industry levels?
7. Have all unnecessary applications and services been eliminated?
8. Are all operating systems and applications patched to current levels?
9. How is backup media stored? Who has access to it? Is it up-to-date?
10. Is there a disaster recovery plan? Has it ever been rehearsed?
11. Are there good cryptographic tools in place to govern data encryption?
12. Have custom-built applications been written with security in mind?
13. How have these custom applications been tested for security flaws?
14. How are configuration and code changes documented at every level? How are these records reviewed and who conducts the review?

Data classification

Data classification table: For each kind of data your app saves/uses, ask yourself:

1. Is this information personal or sensitive in nature?
2. What does my app do with this information?
3. Where and in what format is it saved?
4. Is it sent over the network?
5. (for all above) Does it need to be?  Can I reduce my use?

Data storage location

Where is your app storing its data, and why?  Is it secure?

Encryption

You can easily encrypt data in Android just before/after saving it to the device's SD card or local database.

private static byte[] encrypt(byte[] key, byte[] data) {

    SecretKeySpec sKeySpec = new SecretKeySpec(key, "AES");

        Cipher cipher;

    byte[] ciphertext = null;

    try {

        cipher = Cipher.getInstance("AES");

        cipher.init(Cipher.ENCRYPT_MODE, sKeySpec);

        ciphertext = cipher.doFinal(data);

        } catch (NoSuchAlgorithmException e) {

            Log.e(TAG, "NoSuchAlgorithmException");

        } catch (InvalidKeyException e) {

            Log.e(TAG, "InvalidKeyException");

        } catch (Exception e) {

            Log.e(TAG, "Exception");

        }

    return ciphertext;

}

Phishing/social engineering

Phishing: Masqueraded mails or web sites.

• Social engineering: Attempts to manipulate users, such as fraudulently acquiring passwords or credit card numbers.

Problems:

• If trusted users of your system are tricked into giving out their personal information, attackers can use this to log in as those users and compromise your system.

Mobile+web apps

OWASP Top 10 issues for mobile apps that talk to web apps:

1. Identify and protect sensitive data on the mobile device.
2. Handle password credentials securely on the device.
3. Ensure that sensitive data is protected in transit.
4. Implement user authentication and session management correctly.
5. Keep the back-end APIs (services) and the platform (server) secure.
6. Perform data integration with third party services/apps securely.
7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data.
8. Implement controls to prevent unauthorized access to paid-for resources (e.g., wallet, SMS, and phone calls).
9. Ensure secure distribution/provisioning of mobile applications.
10. Carefully check any runtime interpretation of code for errors.

Secure web (HTTPS)

Man-in-the-middle attack: unauthorized third party can hear web traffic on its hops between client and server.

For security, all web traffic in your app should use HTTPS secure protocol.

• built on Secure Socket Layer (SSL) 

Packet sniffing

Packet sniffing: Listening to traffic sent on a network.

1. Many internet protocols (http, aim, email) are unsecure.
2. If an attacker is on the same local network (LAN) as you, he can:
• read your email/IMs as you send them
• see what web sites you are viewing
• grab your password as it's being sent to the server
3. solutions:
• Use secure protocols (ssh, https)
• Encryption
• Don't let creeps on your LAN/wifi

Sumber Referensi

1. Evans Data Mobile Developer Survey Mobile Development Report 2012 Volume
2. Business Insider (September 2012)
3. http://www.nfl.com/
4. https://www.ibm.com/mobilefirst/sa/en/mobile-security.html