Apa itu CSRF

CSRF atau Pemalsuan Sumber Daya Lintas Situs adalah eksploitasi yang memanfaatkan token sesi pengguna ketika mereka masuk ke aplikasi untuk tanpa sepengetahuan pengguna, bertindak atas nama mereka.

Dengan kata lain. Umumnya agar pengguna dapat mengakses dan memodifikasi sumber dayanya, aplikasi membuat token untuk mereka saat masuk dan menyimpannya di penyimpanan browser. Token ini digunakan untuk mengotorisasi permintaan pengguna ke server untuk mengambil atau mengubah data yang aksesnya diberikan oleh aplikasi kepada mereka.

CORS

Secara historis browser mengikuti kebijakan asal yang sama yang merupakan konsep keamanan di mana browser web mengizinkan skrip yang terdapat di halaman web pertama untuk mengakses data di halaman web kedua, namun hanya jika kedua halaman web memiliki asal yang sama — artinya, keduanya memiliki asal yang sama. protokol, nama host dan nomor port.

Namun seiring berkembangnya web dan menjadi lebih saling terkait, kebijakan asal yang sama ternyata terlalu membatasi karena situs web menggunakan konten atau sumber daya untuk CSS atau font dari situs berbeda.

Sebagai standar, aplikasi web modern dipecah menjadi beberapa unit yang semuanya memiliki tujuan masing-masing. Biasanya ada setidaknya 2 server yang berjalan — satu yang melayani bit yang berinteraksi dengan pengguna dan yang kedua, yang bertukar informasi tentang keadaan database saat ini dengan dunia dan masing-masing memiliki asal masing-masing.

Sekarang, mengingat bahwa saya sebagai peretas yang sangat jahat memiliki potensi untuk mendapatkan akses ke token otorisasi pengguna untuk sumber daya yang sangat penting (misalnya — bank), saya dapat mengubah status data pengguna sumber daya tersebut melalui kejahatan saya sendiri. situs web.

Bagaimana cara penerapannya?

Katakanlah saya memiliki situs web yang memungkinkan pengguna terotentikasi untuk mengirim komentar tentang topik yang dipilih dengan cermat.
Bagian belakang aplikasi saya berjalan di url “api-of-opinions-about-very-important-things.com” dan front-end berjalan di server lain dengan url “opinions.com”

Ketika pengguna memposting komentar di situs web saya, komentar itu dikirim ke backend sebagai permintaan POST dengan muatan id pengguna, komentar dan id topik dan diotorisasi dengan token dari penyimpanan browser.

Jika pengguna tersebut memasuki situs web lain yang mengirimkan permintaan yang sama dengan komentar jahat ke backend, pengguna tersebut akan diberi otorisasi dan akan tampak seolah-olah pengguna tersebut telah memposting komentar tersebut.

Dalam contoh saya, saya tidak memiliki formulir tetapi beberapa masukan dan tombol, Ketika permintaan dikirim, dimungkinkan untuk melihat muatan permintaan ke server dari alat pengembang browser/Jaringan, yang dapat ditiru oleh penyerang dalam skrip jahat mereka.

Jika situs web menggunakan formulir untuk mengirim data, maka dimungkinkan juga untuk melihat apa yang dikirim dari alat pengembang/Jaringan, mendapatkan wawasan tentang basis data, menyalin formulir itu dan mengirimkannya dengan masukan yang diisi sesuai keinginan penyerang.

Sebagai contoh, saya memulai server asal lain (di port lain di localhost) dengan create-react-app dan menjalankan permintaan posting ke server aplikasi opini menggunakan token dari localStorage untuk otorisasi.

Oke, bagus, ini berhasil, komentar buruk itu muncul di situs saya tetapi bukan karena alasan yang tepat.

Pokoknya.. saat saya melihat kode back end saya, saya perhatikan bahwa pengontrol komentar tidak terlalu berbuat banyak dengan otorisasi (ini adalah proyek lama). Saya kemudian keluar dari token di “situs web jahat” .. itu nol! Tampaknya saya bingung dengan CSRF - ini hanya berfungsi dengan cookie, Gunakan JWT! mungkin masih aman.

Oke. Ayo mulai lagi. CSRF bekerja pada cookie dan jika cookie disimpan, Anda dapat mengirimkan formulir tersembunyi yang diisi ke situs web jahat Anda di mana Anda telah memikat korban yang tidak curiga menggunakan rekayasa sosial yang brilian.

Sekali lagi, formulir dapat dibuat berdasarkan formulir dari situs web asli (juga dapat disembunyikan), diisi dengan data apa pun dan diserahkan pada pemuatan halaman. Kemungkinan besar akan ada metode posting atau hapus dll. Apapun jenis kejahatan yang dirasakan penyerang.

Kesimpulannya adalah ini — dengan serangan CSRF, peretas tidak mendapatkan akses untuk membaca data pengguna Anda, yang bisa mereka lakukan hanyalah memodifikasinya dan karena ini terjadi di browser pengguna, sepertinya penggunalah yang membuat mengubah.

Hal lain yang dapat diambil - Jangan berikan id pengguna sebenarnya yang mengenkripsinya sedemikian rupa sehingga tidak ada orang yang dapat mengirim permintaan menggunakan kemungkinan id pengguna mulai dari 1 hingga apa pun.

Bagaimana cara melindunginya

  1. Minta pengguna mengautentikasi dirinya lagi dengan kata sandi sebelum mengirimkan formulir
  2. Konfigurasikan Kontrol Akses Izinkan header Asal.

Ketika klien mengirimkan permintaan ke asal lain untuk mendapatkan kembali beberapa data, browser menyertakan header permintaan Asal yang menunjukkan sumber informasi dari mana permintaan tersebut berasal.

Apakah data akan dikirim kembali atau tidak, terserah server. Misalnya secara default ketika backend ruby ​​​​dibuat dengan rails new — api, Rack di application.rb dikonfigurasi untuk mengizinkan semua asal secara default. Jika ini masalahnya, server mengirimkan backAccess-Control-Allow-Origin: * di header respons dan isi respons. Jika dalam contoh saya yang rusak hanya 'opinion.com' yang diizinkan, saya tidak akan dapat mengubah apa pun dari situs saya yang diretas.

Ada kalanya header Asal tidak ada, dalam hal ini, periksa header Referer, jika tidak ada, disarankan oleh OWASP untuk tidak membiarkan permintaan lewat.

3. Dengan setiap formulir yang dikirimkan atau permintaan untuk mengubah status aplikasi, kirimkan token individual yang merupakan nomor acak atau string karakter unik yang dihasilkan secara kriptografis untuk sesi

Ketika permintaan dikeluarkan oleh pengguna akhir, komponen sisi server harus memverifikasi keberadaan dan validitas token dalam permintaan dibandingkan dengan token yang ditemukan dalam sesi tersebut.

TODO :
* Cara kerja JWT
* Mengapa token localStorage tidak terlihat di tab lain vs cookie terlihat
* Cara benar-benar melindungi id pengguna