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.