Fais Lonelyman yang bergantung pada kehidupan cyber nya

Keamanan dalam pengembangan website

2 Men-bac

Mungkin terlintas di kepala kita tentang apakah website yang kita buat itu sudah aman dari genggaman orang ketiga tak bertanggung jawab dan berapa lama kah kita harus menambalnya ?


Kisah pertama

Pada suatu hari yang cerah, salah satu pekerja magang datang ke meja kami dan dia menunjukkan kepada kami bahwa dia telah mengintegrasikan proyeknya dengan dukungan SAML. Dia juga menerapkan kontrol akses sederhana untuk membatasi orang luar mengakses sistem ini. Selanjutnya, dengan menggunakan kerangka web cepat terik terbaru, situs web ini aman seperti sebelumnya. Sayangnya, tidak diketahui dia, itu tidak bekerja karena dia mengharapkannya untuk bekerja. Kami masih dapat mengakses situs web gemerlapnya tanpa mengisi formulir otentikasi apa pun. Di mana itu salah?

Untuk melewati formulir otentikasi, kami cukup menetapkan nilai cookie di situs web gemerlapnya. Dan voila, kami mendapatkan tiket masuk gratis!


Cookie sanik dapat diubah secara bebas oleh klien
Kami sering mencoba menerapkan keamanan dengan berbagai teknik state-of-art seperti OpenID Connect, tetapi kami sering mengambil aspek yang lebih kecil seperti yang diberikan. Ada lebih banyak orang di luar sana yang memahami apa itu OpenID Connect, tetapi mereka tidak benar-benar memahami gagasan dasar tentang cara kerja cookie. Dalam pengelolaan cookie, kami perlu memastikan bahwa cookie kami tidak dapat dirusak oleh data palsu dan cookie kami tidak dapat diubah oleh siapa pun. Kita perlu secara kriptografi menandatangani data dan memastikan bahwa itu tidak mudah dibuat dengan rahasia yang lemah.

Karena perusahaan saya saat ini memiliki beberapa pekerja magang baru setiap 2 bulan, kami belajar bahwa masalah ini adalah salah satu masalah umum yang paling sering terjadi pada proyek magang. Ini adalah kisah manajemen sesi yang tidak aman .

Kisah kedua

Saya menyesap kopi dan tiba-tiba ada ping kosong dengan “@here” yang menyertai pesan berikut: “Kami akan berhenti menggunakan layanan A dan kami akan mulai menggunakan layanan B untuk manajemen X kami.” Karena saya bosan, saya langsung melihat ke situs web layanan B dan UI terlihat lebih baik daripada layanan A. Pengembang adalah makhluk penasaran secara alami dan apa yang akan mereka lakukan mungkin sama: Klik kanan dan klik “Lihat Sumber Halaman”.


Dan oh, itu salah satu kerangka Javascript yang terkenal dengan semua rute URL yang ditulis dalam skrip!
Sebagai pengalaman dari kisah pertama, saya memeriksa cookie situs web dan situs web menyimpan token API di sana. Saya mencoba mengubah cookie dan sayangnya (atau untungnya), itu tidak berhasil. Dalam kode, ada baris khusus ini “$ rootScope.user.admin == true” yang memeriksa izin admin sebelum mengeksekusi kode batin berikut. Sekarang, Anda mungkin tahu di mana kesalahannya. Endpoint backend tidak benar-benar memeriksa hak istimewa admin!

TL; DR, kita perlu memastikan bahwa backend kita memiliki validasi yang tepat untuk fungsionalitas sementara validasi frontend diterapkan untuk meningkatkan pengalaman pengguna secara umum. Dengan kerangka kerja Javascript, masalah ini tidak jarang terjadi dan sebenarnya terjadi di banyak server produksi. Dalam kasus B layanan ini, mereka memiliki lebih dari 10 titik akhir dengan hak istimewa admin tetapi mereka gagal untuk mengamankan 1 dari mereka. Ini adalah kisah kontrol akses tingkat fungsi yang hilang .

Kisah ketiga

Di dunia InfoSec, CIA adalah singkatan terkenal yang merupakan singkatan dari Kerahasiaan, Integritas, dan Ketersediaan. Privasi pengguna adalah bagian dari kerahasiaan yang harus kita lindungi di semua biaya. Kisah ini sangat terkenal tetapi karena itu sangat penting, saya akan menceritakannya sekali lagi.

Kembali di universitas (3 tahun yang lalu), banyak situs web internal universitas dikerahkan tanpa dukungan HTTPS. Mahasiswa Informatika / Ilmu Komputer di Indonesia sangat “kreatif” dalam aspek-aspek khusus ini. Mereka hanya perlu mengunduh aplikasi bernama “WireShark” dan karena jaringan itu sendiri sering tidak terlindungi, kita bisa melihat pasangan nama pengguna / kata sandi terbang di sekitar jaringan.

Bergerak ke depan, saya belajar bahwa HTTPS dapat dilucuti / diturunkan ke HTTP melalui serangan man-in-the-middle (MITM). Situs web biasanya mendengarkan port HTTP dan HTTPS karena permintaan akan masuk ke port HTTP secara default. Pada port HTTP, situs web akan mengalihkan pengguna ke port HTTPS-nya, tetapi masalahnya di sini adalah bahwa SSL dapat dilucuti. Serangan ini, yang dikenal sebagai pengupasan SSL, dapat diimplementasikan dalam beberapa cara seperti melalui proxy untuk perutean lalu lintas, atau melalui hotspot berbahaya yang memungkinkan korban untuk menyambung ke sana.

Mulai dari Chrome 68 (Juli 2018), Chrome akan menandai semua URL HTTP sebagai “Tidak aman” ( Blog Google ).


Bagaimana itu akan terlihat setelah Chrome 68
Jika Anda belum menerapkan dukungan HTTPS ke situs web Anda, pastikan Anda menambahkannya sebelum Juli 2018! Selain itu, Anda harus menambahkan header HSTS jika memungkinkan. Untuk merangkumnya, ini adalah kisah HTTPS, HSTS, dan serangan man-in-the-middle .

Fais Lonelyman yang bergantung pada kehidupan cyber nya

Instalasi ReamJS

Fais
19 Det-Bac

Membuat Package Laravel

Fais
2 Men-bac

Installasi SSL di VPS

Fais
10 Men-bac