Pengodean sisi klien: Bagaimana mencegah penggunaan jahat?

60

Selama beberapa tahun terakhir, tren untuk aplikasi sisi-klien (browser) telah benar-benar hilang.

Untuk proyek terbaru saya, saya telah memutuskan untuk mencoba dan bergerak dengan waktu dan menulis aplikasi sisi klien.

Bagian dari aplikasi ini melibatkan pengiriman email transaksi kepada pengguna (misalnya, validasi pendaftaran, email atur ulang kata sandi, dll.). Saya menggunakan API pihak ketiga untuk mengirim email.

Biasanya saya akan menjalankan aplikasi di server. Saya akan memanggil API pihak ketiga dari kode di server saya.

Menjalankan aplikasi sisi klien berarti ini sekarang harus terjadi pada browser pengguna. API pihak ketiga menyediakan file JavaScript yang diperlukan untuk mencapai hal ini.

Masalah mencolok pertama yang bisa saya lihat adalah saya harus menggunakan kunci API. Ini biasanya disimpan dengan aman di server saya, tetapi sekarang mungkin saya perlu memberikan kunci ini ke browser klien.

Dengan asumsi saya bisa mengatasi masalah ini, masalah berikutnya adalah apa yang menghentikan pengguna yang mengerti teknologi memuat alat pengembang JavaScript di browser dan tetap menggunakan API email yang mereka suka, daripada mengatakan mematuhi aturan yang telah saya tetapkan dalam aplikasi .

Saya kira pertanyaan umum saya adalah - bagaimana kita bisa mencegah penggunaan berbahaya aplikasi sisi klien?

javascript web-applications browser client-side Gaz_Edge
sumber
24
Apa alasan Anda tidak memiliki Aplikasi ini berkomunikasi dengan server Anda sendiri dan kemudian server Anda meneruskan permintaan tersebut ke layanan eksternal apa pun yang perlu Anda gunakan? (Banyak layanan seperti itu akan melarang untuk menggunakannya dengan cara ini)
thorsten müller
11
Inilah mengapa kunci API pada akhirnya tidak ada gunanya. Server seharusnya tidak mencoba memercayai aplikasi yang mengirimkannya perintah; seharusnya hanya mempercayai pengguna.
Kevin Panko
42
Saya belum pernah melihat orang waras yang mendefinisikan "aplikasi sisi klien" sebagai "tidak pernah berkomunikasi dengan server" - yang sepertinya lebih seperti sebuah kesalahan daripada argumen yang masuk akal. Jelas ada beberapa hal yang harus Anda tangani di sisi server tetapi sebagian besar tindakan dapat dilakukan secara lokal tanpa masalah, yang pada gilirannya akan sangat meningkatkan daya tanggap dan skalabilitas ..
Voo
4
Di mana Anda melihat dorongan ke "Aplikasi Browser Saja?" Saya belum pernah melihat yang seperti yang Anda gambarkan, menyimpan rahasia dalam kode klien dalam ide yang sangat buruk, bahkan orang paling sulit yang saya tahu tidak akan pernah melakukan itu.
Wheeyls
2
Setiap upaya untuk melindungi sumber daya yang aman, pihak klien akan gagal karena melanggar beberapa hukum keamanan yang tidak dapat diubah. # 2/3 - jika perangkat lunak Anda berjalan di komputer lawan, itu bukan komputer Anda secara definisi dan Anda sudah kalah. # 7 yang berusaha melindungi sumber daya dengan enkripsi akan gagal karena Anda juga harus memberikan kunci dekripsi kepada klien. # 10 tidak ada teknologi yang dapat memperbaiki hal di atas. blogs.technet.com/b/rhalbheer/archive/2011/06/16/…
Dan Neely

Jawaban:

200

Anda tidak bisa, dan semakin banyak orang memahami hal ini, dan semakin dalam mereka memahami, semakin baik bagi dunia.

Kode yang berjalan pada perangkat di bawah kendali pengguna tidak dapat dikontrol. Ponsel cerdas dapat di-jailbreak. Kotak set-top dapat dipecahkan. Peramban biasa bahkan tidak berupaya mencegah akses ke kode JavaScript. Jika Anda memiliki sesuatu yang layak dicuri atau disalahgunakan, penyerang yang gigih akan dapat melakukannya kecuali Anda memvalidasi semua yang Anda hargai dari sisi server.

Kebingungan sangat sedikit membantu; jenis lawan yang akan Anda tarik segera setelah apa pun yang melibatkan keuangan jarak jauh membaca bahasa majelis seperti iklan baris. Enkripsi tidak dapat membantu Anda, karena perangkat yang akan menjaga kunci adalah perangkat yang sama dengan yang Anda anggap sudah retak. Ada banyak tindakan pencegahan lain yang tampaknya tidak berhasil, karena alasan yang sama.

Sayangnya, ini adalah kebenaran yang sangat tidak nyaman. Dunia ini penuh dengan operator kecil dan besar yang berpikir bahwa mereka dapat mengatasi kehancuran mendasar dari kepercayaan jarak jauh, hanya karena akan sangat bagus jika kita dapat berasumsi bahwa kode kita akan dijalankan seperti yang kita asumsikan. Dan ya, itu akan membuat segalanya jauh lebih mudah sehingga itu bahkan tidak lucu. Tetapi berharap tidak membuatnya demikian, dan berharap melawan harapan bahwa Anda adalah satu-satunya kue cerdas yang dapat menghindari ketidaknyamanan hanya akan membakar Anda dan klien Anda. Karena itu, masuklah ke dalam pola pikir bahwa Internet adalah wilayah musuh, sertakan biaya tambahan itu dalam perkiraan Anda, dan Anda akan baik-baik saja.

Yang mengatakan, tentu saja ada yang namanya pertahanan secara mendalam. Mengacaukan JavaScript Anda tidak menunda penyerang yang ditentukan, tetapi mungkin menunda beberapa penyerang yang kurang bertekad. Jika aset Anda cukup layak untuk dilindungi, tetapi tidak dengan biaya apa pun, tindakan apa pun itu dapat menambah nilai bisnis ke sistem Anda; itu tidak mungkin sempurna. Selama Anda sepenuhnya menyadari trade-off yang Anda buat, itu mungkin strategi yang masuk akal.

Kilian Foth
sumber
6
Tetapi untuk menempatkan ini dalam perspektif: Ini berlaku untuk SETIAP Perangkat Lunak, baik itu Sistem Operasi atau setelan transaksi. Pada akhirnya ada beberapa kode obfuscator yang sangat bagus di luar sana dan Anda dapat meningkatkan bilah yang kemungkinan besar cukup tinggi, jika tidak ada insentif keuangan langsung untuk meretas perangkat lunak Anda!
Falco
5
Saat ini, perusahaan telah mengambil tindakan hukum terhadap orang-orang yang meretas konten yang diterima dari mereka sebelum diproses (yaitu melalui pemblokir iklan). Itu hanya menunjukkan betapa tidak mungkinnya tindakan teknis .
Kilian Foth
62
Jika saya bisa menguraikan dua kalimat pertama, orang-orang halus yang sering terlewatkan adalah bahwa titik aplikasi browser sisi klien adalah untuk menurunkan beban berat. Server Anda masih bertanggung jawab atas operasi tepercaya, seperti mengirim email atau mengakses data. Namun, membuat klien membuat grafik dari data itu, menghemat waktu CPU Anda (dan uang) tanpa mengubah model keamanan.
ssube
11
@Gaz_Edge Penting untuk dicatat bahwa masalahnya di sini bukanlah aplikasi sisi klien secara inheren tidak aman. Masalahnya adalah menulis aplikasi sisi klien ini dengan cara yang membutuhkan kepercayaan klien dengan informasi yang Anda tidak ingin publik. Sangat mungkin untuk menulis aplikasi yang sangat berat bagi klien yang sama amannya dengan aplikasi di mana sebagian besar pemrosesan terjadi di server. (Untuk lebih lanjut tentang itu, lihat jawaban
jhocking
7
@ Ajedi32 Aplikasi sisi klien tidak aman. Tidak mungkin untuk merancang aplikasi yang aman jika logika yang dilakukan sisi klien tidak diperiksa sisi server. Pada saat itu, logika sisi-klien menjadi keramahtamahan UI atau cara untuk menurunkan pemeriksaan dasar, tetapi semuanya, harus selalu diperiksa di server !! .
69

Aturannya di sini adalah:

Lakukan segala sisi klien yang tidak memengaruhi orang lain jika pengguna merusaknya. Secara khusus, itu berarti efek grafis.

Lakukan semua sisi server yang perlu aman, dan cukup kirim acara UI dari klien (mis. Klien hanya mengatakan "pengguna mengetuk tombol Beli" sementara server benar-benar melakukan transaksi). Secara khusus, itu berarti transaksi keuangan.

jhocking
sumber
28

Inilah yang membuat aplikasi sisi klien sepenuhnya tidak tepat.

Anda dapat membuat logika dan validasi dasar formulir sisi-klien (Anda masih harus memvalidasi ulang di server, karena seseorang dapat mencoba memalsukan permintaan) untuk meningkatkan daya tanggap, Anda dapat melakukan permintaan HTTP dari JavaScript dengan mengirimkan data di sana dan kembali di JSON ke menghindari pengiriman ulang dekorasi halaman dan semacamnya, tetapi jika transaksi itu sendiri perlu diautentikasi dan diotorisasi, itu harus tetap terjadi di server.

Jan Hudec
sumber
11
Catatan: Meskipun bagus untuk memvalidasi bentuk sisi klien, jangan pernah lupa juga memvalidasi sisi server! Pada saat Anda mengirim kode klien ke browser, kode itu berhenti menjadi kode Anda! Anda harus memvalidasi setiap bit yang dikirim lagi!
Josef
17

Paragraf tengah Anda adalah inti masalahnya:

Menjalankan aplikasi sisi klien berarti ini sekarang harus terjadi pada browser pengguna. API pihak ketiga menyediakan file js yang diperlukan untuk mencapai hal ini.

Mengapa aplikasi sisi klien berarti Anda tidak dapat memiliki sisi server yang berfungsi? Dorongan terhadap pemrograman sisi klien bukan tentang menghilangkan server, tetapi meningkatkan teknologi yang lebih baru yang akhirnya didukung browser untuk membuat antarmuka pengguna yang lebih baik.

Sedangkan untuk .jsfile yang Anda terima, apakah Anda yakin itu dimaksudkan untuk browser? Mungkinkah itu perpustakaan node.js?

Brandon
sumber
4
+1 untuk saran yang sangat bagus bahwa file JS ditujukan untuk server NodeJS
Machinarius
11

Mari kita mundur dari sini dan melihat ke tingkat yang lebih tinggi .. akankah kita .. Apakah Eudora atau pandangan (aplikasi sisi klien, bahkan tidak memerlukan browser) pernah menyebabkan kerugian finansial bagi perusahaan mana pun? Tidak. Siapa pun dapat menulis ke API POP / SMTP dan menjadi klien. Tapi tidak ada kerugian ke server. Server tidak membatasi tindakan klien, perhitungan, penyimpanan, suhu, ukuran disk, ukuran ram, monitor DPI, GPU, FPU, dan yada klien, tetapi dengan tepat menentukan apa yang akan dijawab dan tidak lebih. Apakah Anda pernah mendengar tentang MS-Money yang digunakan untuk masuk ke bank?

Aplikasi browser Anda (yaitu sisi klien) dapat menggunakan arsitektur yang sama.

  1. Anda membangun server Anda dengan API (yang BTW, selalu bermuara pada turunan dari GET POST HEAD, dll.).
  2. Di server, pastikan bahwa API hanya berbicara dengan klien yang diverifikasi dan diverifikasi identitasnya untuk setiap panggilan.
  3. Maka Anda tidak peduli siapa kliennya.
  4. Dan kemudian Anda tidak peduli apakah itu peramban, perangkat yang di-jailbreak, Google glass, DOS 3.1, atau Nexus baru di tangan kakek buyut teknopob-buyut-buyut yang punya waktu bepergian ke 2014 dan melewatkan semua teknologi yang telah membanjiri kehidupan kita dalam 15 dekade terakhir.
  5. Sekarang Anda dapat mulai memuat semua yang lain ke sisi klien.

SoapBoxBegin

@KilianFoth memunculkan titik kesadaran penting bagi orang yang naif dan ceroboh, terutama mereka yang membaca berita utama sepanjang waktu tetapi tidak pernah berpikir itu akan terjadi pada aplikasi mereka, kode mereka, majikan mereka, klien mereka, rekening bank mereka sendiri. Yang lebih gegabah adalah majikan mereka (terutama CTO) yang akan memungkinkan aplikasi untuk keluar yang mengekspos sistem apa pun untuk eksposur yang tidak terkelola / tidak terkendali. Namun saya selalu bingung bagaimana tampaknya "kita tidak pernah belajar".

Kotak Sabun

Jadi untuk meringkas. Buat API sisi server yang solid dan kencang. Turunkan segala sesuatu yang lain ke klien berdasarkan apa pun yang dapat ditangani klien.

LMSingh
sumber
6

Saya berpendapat bahwa Anda benar-benar tidak bisa. Jika Anda ingin mengirim data ke klien, Anda harus berharap bahwa itu akan disalahgunakan - namun mungkin. Contoh Anda mengenai kunci API adalah ilustrasi dari poin tersebut, dan saya tidak akan memasukkannya di sisi klien Anda JS - itu akan dicuri dan disalahgunakan.

Anda pasti masih membutuhkan sejumlah kode server untuk menjaga keamanannya. Bahkan sesuatu yang sederhana seperti mengambil hanya data yang terkait dengan pengguna yang masuk. Otentikasi itu tidak dapat dilakukan semua sisi klien atau lagi Anda akan dimanfaatkan dan data Anda tidak aman.

Saya akan selalu melihat pengalaman sisi klien JS sebagai tambahan untuk kode server. Validasi pada klien memberikan pengalaman pengguna yang menyenangkan, tetapi jika Anda tidak memverifikasi bahwa data POST di server penerima juga, Anda membuka diri untuk menyerang. Apa pun dari klien harus dianggap tersangka.

Matt Klinker
sumber
4

Cukup sederhana, sungguh. Asumsikan bahwa komputer klien dan semua perangkat lunak yang menjalankannya di bawah kendali penuh peretas jahat yang pandai.

Itu berarti bahwa setiap informasi yang Anda kirim dari server ke klien akan diketahui oleh peretas jahat, jadi Anda harus memastikan untuk tidak mengirimkan informasi kepada klien yang dapat digunakan untuk menyerang server Anda atau bisnis Anda.

Ini juga berarti bahwa apa pun yang dikirim dari klien ke server telah dihasilkan oleh peretas jahat, jadi kode server Anda harus memastikan bahwa tidak ada yang dapat dikirim oleh klien yang dapat berhasil menyerang server Anda.

Memang, implementasi adalah masalah, tetapi yang penting adalah sikap mental, asumsi bahwa "klien" yang Anda pikir server Anda ajak bicara bukanlah klien tetapi penyerang aktif.

(Anda juga harus menganggap bahwa pengguna adalah penipu pintar yang akan mencoba menyerang metode bisnis Anda, tetapi itu tidak ada hubungannya dengan pemrograman sisi klien).

gnasher729
sumber
0

Aplikasi Sisi Klien, menurut saya, sebagian besar tentang UI. Misalnya, semua sistem UI Anda akan dikirim satu kali ke klien, dan kemudian klien akan melakukan apa pun yang diinginkannya.

Biasanya saya akan menjalankan aplikasi di server. Saya akan memanggil API pihak ketiga dari kode di server saya.

Menjalankan aplikasi sisi klien berarti ini sekarang harus terjadi pada browser pengguna. API pihak ketiga menyediakan file JavaScript yang diperlukan untuk mencapai hal ini.

Jika Anda memiliki Kunci API, maka itu tidak dimaksudkan untuk bekerja di sisi klien. Jika Anda memberikan Kunci API di sisi klien, maka siapa pun dapat mengaksesnya, dan kemudian dapat menggunakannya untuk tujuan itu sendiri. Simpan dan gunakan sisi server ketika klien membutuhkannya, lalu kirim hasilnya menggunakan Ajax / WebSockets.

Ini seperti jika bank Anda mengatakan: "Yah, saya akan meletakkan kata sandi dari sisi klien basis data utama sehingga klien dapat memintanya sendiri dan dia tidak akan mengganggu server kami lagi."

Depado
sumber