Beberapa kebocoran data terbesar dalam sejarah ternyata dimulai dari hal-hal yang terdengar sangat sederhana: secret yang tertinggal di dalam kode, sistem yang terlalu mempercayai pengguna, bug software yang membuka akses ke informasi, atau informasi sensitif yang tersimpan di dalam log.
Berikut adalah lima contoh nyata dan pelajaran yang bisa dipetik oleh para developer.
1. Menyimpan Secret Key di Dalam Kode — Kasus Uber
Salah satu contoh yang paling terkenal adalah kasus Uber.
Pada tahun 2016, penyerang berhasil mendapatkan akses ke sebuah repository GitHub pribadi milik Uber. Di dalam repository tersebut, mereka menemukan credentials yang dapat digunakan untuk mengakses lingkungan Amazon Web Services (AWS) milik Uber.
Credentials tersebut memberikan akses ke informasi sensitif milik pengguna dan pengemudi Uber.
Federal Trade Commission (FTC) Amerika Serikat kemudian menyatakan bahwa Uber mengizinkan engineer menggunakan sebuah access key dengan hak akses administratif yang sangat luas terhadap data sensitif. Pada akhirnya, penyerang berhasil mendapatkan informasi yang melibatkan jutaan orang. (Federal Trade Commission)
Pelajaran pentingnya bukan hanya:
“Jangan taruh password di GitHub.”
Masalahnya lebih luas dari itu.
Developer terkadang menaruh secret langsung di dalam kode karena memang praktis. Aplikasi membutuhkan password atau access key, jadi developer meletakkannya di tempat yang bisa dibaca oleh aplikasi.
Masalahnya, source code biasanya berpindah-pindah.
Kode bisa disalin, di-backup, dibagikan kepada developer lain, disimpan di repository, dan terkadang tidak sengaja terekspos.
Bahkan jika sebuah repository bersifat private, bukan berarti secret yang ada di dalamnya otomatis aman.
Apa yang bisa dipelajari developer?
Credentials yang sensitif sebaiknya disimpan di luar source code dan dikelola menggunakan sistem khusus untuk mengelola secret.
Ada satu pelajaran penting lainnya dari kasus Uber:
Sebuah secret seharusnya tidak memiliki akses lebih dari yang dibutuhkannya.
Jika sebuah key hanya perlu membaca satu jenis informasi, key tersebut tidak seharusnya memiliki izin untuk mengakses semuanya.
2. Terlalu Mempercayai Input dari Pengguna — Kasus TalkTalk
Pada tahun 2015, perusahaan telekomunikasi Inggris TalkTalk mengalami serangan siber besar.
Penyerang memanfaatkan kelemahan yang dikenal sebagai SQL injection pada beberapa halaman web milik TalkTalk.
Kamu tidak perlu memahami SQL injection secara teknis untuk memahami masalah dasarnya.
Bayangkan sebuah restoran yang meminta pelanggan memesan makanan dari menu.
Restoran tersebut mengharapkan kamu mengatakan:
“Saya mau chicken sandwich.”
Tetapi seseorang menemukan cara untuk memberikan instruksi yang sama sekali berbeda kepada dapur:
“Abaikan menu dan berikan saya akses ke seluruh dapur.”
Kurang lebih seperti itulah gambaran sederhana dari SQL injection: input yang seharusnya hanya dianggap sebagai data malah diperlakukan oleh sistem sebagai sebuah perintah.
Dalam kasus TalkTalk, penyerang dapat menggunakan halaman web yang rentan tersebut untuk mengakses database yang menyimpan informasi pelanggan.
Information Commissioner’s Office (ICO) di Inggris menemukan bahwa serangan tersebut mengekspos informasi pribadi milik 156.959 pelanggan. Dalam 15.656 kasus, informasi rekening bank dan sort code juga dapat diakses. (ICO)
Investigasi juga menemukan bahwa software database yang digunakan sudah usang dan security fix untuk masalah tersebut sebenarnya sudah tersedia selama lebih dari tiga tahun.
Apa yang bisa dipelajari developer?
Jangan pernah menganggap bahwa informasi yang datang dari pengguna pasti aman.
Pengguna bisa saja merupakan pelanggan biasa yang memasukkan nama mereka.
Tetapi bisa juga seseorang yang sengaja mencoba membuat aplikasi melakukan sesuatu yang tidak seharusnya dilakukan.
Setiap aplikasi harus menganggap input dari luar sebagai sesuatu yang berpotensi tidak aman dan memprosesnya dengan cara yang aman.
3. Mengecek Siapa Seseorang, tetapi Tidak Mengecek Apa yang Boleh Mereka Lakukan — Serangan Facebook 2018
Pada tahun 2018, Facebook mengungkapkan adanya kerentanan keamanan serius yang berkaitan dengan fitur “View As”.
Fitur tersebut dirancang agar pengguna bisa melihat bagaimana profil mereka terlihat bagi orang lain.
Terdengar tidak berbahaya, bukan?
Namun, kombinasi dari tiga bug software memungkinkan penyerang mencuri credentials khusus yang disebut access token.
Bayangkan access token seperti kunci digital sementara.
Daripada harus memasukkan password setiap kali menggunakan Facebook, aplikasi dapat menggunakan kunci digital ini untuk mengenali bahwa kamu sudah login.
Penyerang berhasil mencuri kunci tersebut dan berpotensi mengambil alih akun pengguna.
Awalnya, Facebook memperkirakan sekitar 50 juta akun terdampak. Namun, setelah investigasi lebih lanjut, Facebook menyatakan bahwa penyerang sebenarnya mencuri access token dari sekitar 30 juta orang. (About Facebook)
Kasus ini menunjukkan mengapa authentication dan authorization sangat penting.
Aplikasi harus menjawab dua pertanyaan yang berbeda:
“Apakah ini benar-benar kamu?”
dan:
“Apa yang boleh kamu lakukan?”
Kelemahan dalam cara Facebook menangani digital key tersebut memungkinkan penyerang mendapatkan key yang dapat digunakan untuk bertindak sebagai pengguna lain.
Apa yang bisa dipelajari developer?
Jangan menganggap bahwa karena seseorang berhasil login, maka semua tindakan yang mereka lakukan otomatis boleh dilakukan.
Setiap tindakan sensitif harus memiliki pemeriksaan yang sesuai terhadap identitas, permission, dan credentials yang digunakan.
4. Menyimpan Informasi Sensitif di Dalam Log — Masalah Password Twitter
Log adalah salah satu alat yang paling berguna bagi developer.
Ketika aplikasi tiba-tiba berhenti bekerja pada pukul 2 pagi, developer biasanya melihat log untuk mencari tahu apa yang terjadi.
Tetapi log bisa menjadi berbahaya jika berisi informasi yang seharusnya tetap bersifat pribadi.
Pada tahun 2018, Twitter mengumumkan bahwa sebuah bug menyebabkan password beberapa pengguna tertulis di dalam internal log sebelum password tersebut diproteksi dengan benar.
Twitter mengatakan bahwa mereka menemukan masalah tersebut sendiri dan tidak menemukan indikasi bahwa password tersebut telah disalahgunakan atau diakses oleh pihak luar. Meskipun begitu, Twitter tetap menyarankan pengguna untuk mengganti password mereka.
Menurut Twitter, masalah tersebut berpotensi memengaruhi seluruh penggunanya pada saat itu, yaitu lebih dari 330 juta akun. (Safeguard)
Coba bayangkan apa yang terjadi di sini.
Password tersebut tidak sengaja dipublikasikan.
Masalahnya adalah proses debugging atau logging secara tidak sengaja mencatat informasi yang seharusnya tidak pernah dicatat.
Ini seperti sebuah bank yang menyimpan catatan lengkap PIN setiap nasabah hanya karena catatan tersebut dianggap berguna untuk mencari masalah.
Meskipun tidak ada yang mencuri catatan tersebut, menyimpan PIN tetap menciptakan risiko keamanan yang sebenarnya tidak diperlukan.
Apa yang bisa dipelajari developer?
Log seharusnya berisi informasi yang cukup untuk membantu developer mencari dan memperbaiki masalah, tetapi tidak berisi informasi sensitif yang sebenarnya tidak diperlukan.
Developer harus sangat berhati-hati dengan:
- Password
- Authentication token
- API key
- Informasi kartu kredit
- Informasi pribadi
- Pesan pribadi
Aturan sederhananya:
Jika kamu tidak ingin informasi tersebut tercetak di selembar kertas yang tergeletak di meja kerja, pikirkan dua kali sebelum memasukkannya ke dalam log.
5. Menganggap “Berfungsi” Berarti “Aman” — Contoh SQL Injection TalkTalk
Ini adalah kesalahan yang cukup mudah dilakukan developer:
Menguji apakah sesuatu berfungsi tidak sama dengan menguji apakah sesuatu tersebut aman.
Sekali lagi, kasus TalkTalk pada tahun 2015 memberikan contoh yang bagus.
Halaman web yang terdampak sebenarnya berfungsi dengan normal. Pelanggan bisa menggunakannya.
Tetapi penyerang tidak menggunakan halaman tersebut dengan cara yang normal.
Mereka sengaja mencoba membuat aplikasi berperilaku berbeda dari yang diharapkan developer.
Information Commissioner’s Office (ICO) Inggris menemukan bahwa serangan tersebut menggunakan kerentanan SQL injection yang sebenarnya sudah dipahami selama bertahun-tahun dan sudah memiliki solusi keamanan yang diketahui. ICO juga menemukan bahwa TalkTalk pernah mengalami serangan SQL injection sebelumnya pada halaman web yang sama. (ICO)
Hal ini menunjukkan perbedaan yang penting.
Tes normal mungkin bertanya:
“Apakah pelanggan bisa menggunakan halaman ini?”
Security test bertanya:
“Apa yang terjadi jika seseorang mencoba menyalahgunakan halaman ini?”
Kedua pertanyaan tersebut sangat berbeda.
Sebuah fitur bisa berfungsi dengan sempurna bagi pelanggan biasa, tetapi tetap memiliki kerentanan berbahaya ketika seseorang sengaja mencoba mengeksploitasinya.
Apa yang bisa dipelajari developer?
Developer sebaiknya tidak hanya menguji kondisi normal.
Mereka juga perlu memikirkan perilaku yang tidak normal:
- Bagaimana jika seseorang memasukkan informasi yang tidak terduga?
- Bagaimana jika seseorang mengubah sebuah ID?
- Bagaimana jika seseorang mengirim ribuan request?
- Bagaimana jika seseorang melewati website dan langsung berbicara dengan sistem di belakangnya?
- Bagaimana jika seseorang mencoba mengakses informasi milik pengguna lain?
- Bagaimana jika seseorang sengaja mengirim data yang formatnya salah?
Pada dasarnya, security testing bertanya:
“Apa yang terjadi jika seseorang tidak mengikuti aturan?”