Thread by @omarqe

Dalam web security, ada satu 'hack' ni di mana dengan hanya melawati/membuka malicious email/web, boleh berlaku benda bahaya seperti transfer duit dari akaun anda ke akaun orang lain TANPA SEDAR.

But fret not, peluang berlaku kat korang agak tipis sekarang. Learn why👇🏻

[THREAD]

Lompong sekuriti ini dipanggil sebagai Cross-Site Request Forgery (CSRF).

Suatu masa dulu, CSRF disenaraikan dalam OWASP Top 10 di tangga ke-5 & ke-8 (A5:2007 & A7:2013).

Namun kini CSRF tidak lagi menjadi "main threat" dan dah dibuang dari OWASP Top 10 sejak tahun 2017.

Memetik kenyataan daripada OWASP, alasan kenapa mereka buang CSRF daripada senarai Top 10:

"A8-Cross-Site Request Forgery (CSRF), as many frameworks include CSRF defenses, it was found in only 5% of applications."

Maknanya, banyak framework moden dah implemen anti-CSRF ni.

Namun, kena ingat, ada juga aplikasi web yg tak guna framework. Dia buat koboi je, kekadang terlepas pandang isu CSRF ni sebab terlalu husnuzon penggunanya semua baik-baik belake.

Lompong sekuriti ini berlaku dalam sesuatu web itu kalau developer taktau atau cuai pasal benda ni.

Jadi, masih kena berhati-hati terutamanya pada laman web usang yang tak pernah dinaiktaraf sejak ia dibina 10 tahun lepas.

Maka dengan kombinasi laman web usang & outdated browser seperti IE 10, korang mungkin masih terdedah dengan risiko CSRF ini. Siapa pakai IE lagi ni??

Topik ini agak teknikal sebenarnya, tapi aku akan tulis dalam bahasa paling ringkas supaya orang bukan-IT baca pun mudah faham.

Bebenang ni akan dibahagikan kepada:

1. Bagaimana Internet befungsi?
2. Apa itu CSRF?
2. Selamatkah anda?
3. Pencegahan untuk orang awam & developer.

1. Bagaimana Internet berfungsi?

Sebelum kita pergi lebih lanjut tentang CSRF, elok kita fahamkan dulu bagaimana Internet berfungsi di balik tabir.

Asasnya, Internet yang kita duk guna hari-hari ni ditransfer daripada server kepada client (browser) melalui HTTP protocol.

1.1 Request

Setiap kali kita buka sesebuah laman web, browser kita sebenarnya akan hantar "request" kepada server laman web tersebut.

Bila request ni sampai kepada server, server akan check request tu dan bagi response kepada browser. Maka terteralah web yang kita nak bukak tu!

Kalau server tak jumpa apa yang korang nak, dia akan respon dengan that infamous HTTP status: "404 Not Found" 😂 otherwise dia bagi respon "200 OK"

Segala media di dalam website tu seperti files, gambar, video dan sebagainya juga akan ditransfer guna protokol yang sama.

Kalau korang pernah buka "Inspect Element" kat Chrome misalnya, korang akan dapati segala benda yang ada kat website tu ada Request & Response Headers (rujuk screenshot).

Headers ni penting, kita akan explain nanti dalam langkah pencegahan bagi para developer.

1.2 Request Methods

Request pula ada jenis-jenisnya, ia dipanggil sebagai methods (kekadang dipanggil verbs). Biasanya kita nampak GET, POST, PUT & DELETE.

GET - cth: retrieve gambar kat website, retrieve data
POST - cth: submit form

...

and the rest look at the table below.

2. Apa itu CSRF dan bagaimana nak buat?

Ok macamni, contohla korang login kat site.cōm. Nak dijadikan cerita, diorang develop site.cōm ni cincai je, putting you at risk.

Kemudian korang buka New Tab, pergi ke evil.cōm pulak. Tapi korang taktahu pun evil.cōm ni malicious.

Website evil.cōm ni nampak normal je, takde apa yang meragukan pun daripada luaran. Tapi di belakang, dia tengah buat kerja jahat.

Dia tengah forge request yang berisiko kepada site.cōm. Request yang macamana? Contohnya: funds transfer, delete account, change password dan etc.

Jadi, kalau evil.cōm hantar malicious request kepada site.cōm untuk delete akaun kau, maka habislahh. Tetiba nak nak login kat evil.cōm tak boleh, "user not found".

Bayangkan site.cōm tu web kerajaan, akaun kau pula akaun penting. Tup-tup kena delete, habis hilang data kau.

"Saya skrol je website tu, bukannya submit form ke apa pun?"

Itulah masalahnya, bila developer tadi abuse request methods. Contohnya, dia guna GET method untuk delete user. Gilaaa 🤣

Maka sesiapa saja yang buka site.cōm/user/delete.php?id=123 automatik akaun tu kena delete!

GET method ni sepatutnya guna untuk retrieve saja. Tapi ada juga new developer guna GET untuk submit form seperti login. Fuh bahaya! 😰

Apa-apa request berisiko, mengubah data dalam database seperti create, update dan delete; sepatutnya kena guna method POST, PUT dan DELETE.

Disebabkan developer tadi guna GET untuk delete account, maka evil.cōm boleh ambil kesempatan ini untuk buat jahat.

Cukup sekadar letak img tag seperti di bawah untuk delete akaun mangsa kat site.cōm.

Nota: setiap <img> di dalam HTML akan perform GET request kepada source (src)

Dia juga boleh letak <img> seperti di atas & hantar kepada mangsa di merata tempat seperti emel, forum, comment dan etc. Load je gambar tu automatik akaun kat site.cōm kena delete.

Sebab tula kekadang bila buka emel bergambar, dia tak tunjuk terus gambar tu. Lelagi emel spam.

Selain image, attacker juga boleh buat submit form kat website diorang untuk buat POST request kepada site.cōm.

POST request kena buat melalui form submission (klik submit button), tak boleh buat melalui image. Image hanya perform GET sahaja (rujuk gambar di bawah).

Nak buat POST secara senyap in the background? Boleh guna XMLHttpRequests (XHR) seperti AJAX (Javascript).

Dengan Javascript, mangsa evil.cōm tak perlu explicitly tekan submit button pun boleh je submit in the background tanpa mangsa sedar. Tahu-tahu je akaun dia kena delete :'3

3. Selamatkah anda?

Tak perlu risau sangat. Kalau korang masih hidup zaman moden ni dan dah tak guna Internet Explorer, inshaAllah korang selamat.

Sebagai orang awam, anda kena tahu komuniti cybersecurity dan developer juga komited untuk lindungi keselamatan anda di alam maya.

3.1 Modern Frameworks

Banyak website harini dibina menggunakan framework moden. Framework ini dah implement CSRF prevention siap-siap dah. Antaranya dengan penggunaan random CSRF token.

Token ni apa? Cerita pasal token ni agak teknikal, aku akan explain di bawah nanti.

3.2 Authentication

Jika request seperti /user/delete?id=123 di atas memerlukan korang untuk login ke Website A, maka korang selamat jika korang tak login ke Website A.

Contoh dlm tweet pertama aku melibatkan duit. Jangan risau, internet banking negara kita selamat dari CSRF ni.

Kalau perasan, website internet banking mesti ada timer untuk logout secara automatik kalau idle. Dan dia tak boleh remember cookies "Remember Me".

Tanpa authentication, CSRF takkan berjaya.

Lagipun diorang mestila dah implement banyak lapisan sekuriti, bukan senang nak tembus.

3.3 SameSite cookie 🍪

Mari kita refresh pengetahuan tentang kuki (walaupun semua orang dah tahu).

Disebabkan HTTP ini stateless protocol, maka sukar lah untuk server itu nak mengenali siapakah gerangan manusia yang request macam-macam kat dia tu 😟

Namun, ada web yang perlu mengenali siapa orang yang meminta tu, maka terciptalah seketul makhluk yang dinamakan sebagai kuki.

Bila adanya kuki, maka bolehlah server mengenali identiti peminta dan bolehlah anda login (authenticate) ke website tersebut.

Dan sudah menjadi sifat semulajadi seekor browser, apabila kita buat request (contoh evil.cōm nak load image dari site.cōm), dia akan semak dulu ada simpan kuki daripada site.cōm tak.

Kalau ada, dia akan kepilkan sekali kuki tu bersama-sama request tadi.

Contoh lain, bila ada website tu embed video YouTube di websitenya, korang boleh nampak button "Watch Later" kat embed tersebut.

Button "Watch Later" tu hanya muncul sekiranya korang dah login kat YouTube sebelum ni. Embed video juga adalah salah satu bentuk GET request (iframe)

Jika sekiranya kuki itu tak dikepilkan sekali dengan GET request, korang takkan nampak button "Watch Later".

Berbalik kepada CSRF tadi, apabila evil.cōm buat malicious request (seperti dalam gambar di atas) & kuki dikepilkan sekali bersama-sama request tu, maka terjadilah CSRF.

Disebabkan itu, browser moden kini implemen SameSite property untuk kuki, di mana developer boleh set sama ada nak bagi website lain hantar request sekali dengan kuki ke tak.

SameSite ni ada tiga value boleh set iaitu Strict, Lax dan None. Lihat jadual di bawah untuk rujukan.

Tapi tak semua developer set pun SameSite ni sebab nanti user experience jadi tak best dan leceh.. dan tak semua browser support SameSite property ni.

Mohon lihat jadual di bawah untuk tahu browser korang sapot ke tak. Kalau guna IE lagi, memang idok le. IE11 pun partial support

So ini adalah langkah yang browser developer buat untuk cegah CSRF? Adakah mencukupi sekadar bergantung kepada browser saja? Semestinya tidak! Ada kondisi boleh je bolos.

Biasanya untuk secure sesuatu web tu, kita akan saluti web itu dengan lapisan demi lapisan sekuriti.

Notis:

Point-point di bawah ini untuk bacaan developer atau aspiring developer.

Kalau anda bukan dari latarbelakang IT, point di bawah ni mungkin bosan sikit untuk anda. Tapi kalau nak baca baca jela sebagai ilmu tambahan meskipun dah pasang niat takkan pernah guna hahahahaa.

3.4 JSON Web Token (JWT)

Dunia web & mobile harini dihiasi dengan Application Program Interface (API), iaitu sejenis "perantara komunikasi" antara dua program.

Sebagai contoh, kalau korang nak load maps kat dalam web atau mobile app, mesti korang akan usha Google Maps API.

Itu hanya salah satu contoh yang biasa. Namun sejak beberapa tahun lepas, teknologi web ni melonjak secara mendadak.

Seiring dengan meluasnya penggunaan framework JS seperti Angular, Vue dan React (RVA). Cara kita develop web pun dah berubah beb.

Zaman sekarang, masing-masing buat 'headless web' iaitu memisahkan frontend dan backend. Bahagian frontend sekarang guna JS dan SASS sahaja, dah tak guna HTML dan CSS.

Kepala letak kat tempat lain, badan pulak letak tempat lain (server lain-lain).

Dulu kita embed PHP code terus dalam HTML. Lepastu muncul templating engine pulak, parse je HTML guna PHP.

Kalau tengok web moden harini yang guna framework RVA untuk frontend, diorang akan guna API untuk fetch data dari backend.

Kalau ikut logik la kan, bukankah bila letak frontend dan backend di server lain-lain bermakna ia cross-origin? Bukankah server lain pun boleh akses API kita? Bukankah ini membuka peluang kepada CSRF?!

Ya, jika tak ambik langkah keselamatan! Memperkenalkan JWT.

JWT ni adalah encrypted token yang terdiri daripada header, payload dan signature. Kalau belum tahu, boleh baca lebih lanjut kat jwt.io.

Tujuannya untuk authorization. Nak make sure client (frontend) yg akses API tu dari sek-sek kito jah, ore tak kenal takleh!

JWT ni (dalam encrypted format) akan dihantar kepada backend kita melalui request header seperti ini 👇🏻

Authorization: Bearer <token>

Backend akan decrypt token tersebut guna secret key untuk cek token tu sah ke tidak. Kalau sah, benarkan akses. Kalau sebaliknya, deny laa.

Tapi adakah cukup sekadar implemen JWT sahaja untuk lindungi API kita dari cengkaman CSRF?

Masih belum cukup. Kita kena tambah lagi lapisan sekuriti ekstra untuk lindungi setiap API endpoint kita yang kritikal di point ke-4.

P/s: aku akan share code sikit dalam point seterusnya

4. CSRF Token

Ini adalah solusi paling popular (terbaik?) untuk cegah CSRF. Macamana ia berfungsi? Okay macamni, tidak seperti JWT, CSRF token ini adalah hash, bukan encrypted.

Token ini tak perlu bawa apa-apa data pun seperti JWT, cukup ia sukar untuk diteka oleh orang jahat.

4.1 Sifat-sifat pada CSRF Token

Lightweight. Tak perlu guna string yang panjang-panjang sangat untuk generate token ni. Sebenarnya token 8 karakter huruf besar & huruf kecik pun dah susah untuk teka.

Sentiasa berubah-rubah. Token ni sepatutnya ada lifespan dia. Contohnya, setiap 6 jam token tu akan berubah. Jadi, dia hanya sah untuk 6 jam je la, lebih daripada itu jadi tak sah.

Mesti pantas untuk generate. Boleh guna MD5 untuk tujuan ni, ia antara algo yang terpantas.

Unik dan sukar diteka. Adalah lebih baik untuk jadikan dia berbeza untuk setiap sesi login, dan berbeza untuk setiap request. Elakkan guna token yang sama untuk setiap request!

Jadi, macamana nak capai syarat-syarat ni? Consider:

md5( endpoint . sessionID . timeTick . salt )

Haritu pernah terangkan, hashing algo ni ada sifat avalanche, iaitu kalau satu character dalam tu berubah, output dia akan berubah secara ketara dan menyeluruh.

Jika dilihat variable yang kita guna untuk hash di atas, ketiga-tiganya sentiasa berubah-rubah.

https://twitter.com/omarqe/status/1194244568092274689

Endpoint berubah untuk setiap request (API endpoint).

Variable sessionID berubah mengikut setiap sesi login.

Variable timeTick pula berubah setiap time interval (setiap 6 jam).

Salt hanya sebagai perisa tambahan. Kalau kantoi satu token kat attacker, ubah je salt ni.

4.2 The codes

Pertama sekali, kita kena buat satu counter dipanggil tick. Tick ni akan bertambah satu pada setiap time interval yang kita set.

Contohnya: kalau set 6 jam interval, maka nombor tu akan bertambah satu untuk setiap 6 jam la. Diinspirasikan dari WordPress.

Kemudian kita buat function generate token berdasarkan apa yang kita bincang di atas; genToken() akan generate token dalam bentuk MD5 hash.

Dan akhirnya mestilah kena ada function untuk sahkan token tu, barulah lengkap!

P/s: aku tak sempat test code ni, jadi pepandai la ye.

4.3 Penggunaan

Resepi token kita sudah siap! Sekarang masa untuk gunakannya! Cara guna yang paling mudah adalah dengan memasukkan token ini di dalam form seperti di bawah.

Tapi ini cara klasik la untuk pass token ni ke server. Rasanya WordPress masih lagi guna cara ni.

Bila submit form di atas, kita akan dapat value token daripada hidden input tu tadi. Sebelum nak execute code untuk /post/add, kita verify dulu sama ada token tu sah atau tak.

Kalau tak sah, bagi error response dalam bentuk JSON kepada klien dan exit code.

Code di atas adalah cara yang paling asas untuk mitigate masalah CSRF ni. Kalau lagi advanced, kita pass token tu melalui request header seperti:

X-CSRF-Token: <token>

But that's on you to figure it out. Goodluck.

Aku tak claim method aku ni method yang terbaik ye, banyak lagi cara lain untuk mitigate CSRF attack ni seperti enable CORS untuk server yang kita kenal sahaja.

Di dalam bebenang ni aku cuma terangkan asas. Sorry kalau code ada error, aku taip lelaju dan tak sempat test pun tu.

Rasanya sampai sini saja sharing kali ni. Peroleh sesuatu dari bebenang ini? Share dengan rakan korang! 🤩

---

Follow for more interesting topics in the future. Read my previous CSIT threads down below:

https://twitter.com/omarqe/status/1155346037013221377

Sumber:

OWASP Top 10 Release Note
owasp.org/www-project-to…

Can I Use SameSite cookie?
caniuse.com/#feat=same-sit…

Hypertext Transfer Protocol
en.wikipedia.org/wiki/Hypertext…

CSRF CheatSheet
github.com/OWASP/CheatShe…

More on SameSite cookie
netsparker.com/blog/web-secur…
web.dev/samesite-cooki…

JSON Web Token
jwt.io

HTTP Request Methods
restapitutorial.com/lessons/httpme…