OWASP dan dosa dalam Web Application Security

OWASP dan dosa dalam Web Application Security

Materi oleh Satria Ady Pradana

Satria Ady Pradana akan sharing tentang OWASP dan dosa-dosa yang sering programmer lakukan terkait dalam security terutama web.

apa itu OWASP?

apa dosa yang sering dilakukan?

apakah kita juga termasuk sering berdosa?

Disini akan dibahas OWASP terlebih dahulu.

OWASP atau Open Web Application Security Project adalah komunitas yang berinisiatif untuk menghimpun resource dan mencerahkan orang lain terkait web application security. Yang paling terkenal dari OWASP adalah OWASP Top 10 project, dimana setiap beberapa tahun sekali mereka merilis 10 common security risks yang ada direntang waktu itu. Misal yang mau rilis bentar lagi adalah OWASP Top 10 2017, sebelumnya OWASP Top 10 2013. Di OWASP Top 10 2017 kita akan bisa melihat kira-kira apa aja sih yang menjadi tren security risk di dunia.

OWASP Top 10 bisa dilihat di sini:

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Untuk saat ini, versi 2017 mencapai RC2 yang bisa diunduh di sini:

https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010%202017%20RC2%20Final.pdf

10 peringkat ini sering menjadi acuan pentester untuk melakukan security awareness sekaligus juga panduan dalam pentesting.

1. Injection

2. Broken Authentication

3. Sensitive Data Exposure

4. XML External Entities (XXE)

5. Broken Access Control

6. Security Msiconfiguration

7. Cross-Site Scripting

8. Insecure Deserialization

9. Using COmponents with Known Vulnerabilities

10. Insufficient Logging & Monitoring

Tapi...

Kalau bisa kita rangkum dan ambil inti sarinya kita bisa berpedoman pada satu mantra:

“Jangan sembarang percaya kepada apa yang user berikan”.

Selain merilis 10 common security risk tadi, OWASP juga memberikan guideline juga bagaimana mengetes aplikasi dan bagaimana mendesain aplikasi web yang secure.

Misalnya disini, secure coding:

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

Code review:

https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

Testing (pentesting juga):

https://www.owasp.org/index.php/OWASP_Testing_Project

Ada banyak sebenarnya tapi kita bahas yang umum saja dan yang sering menjadi dosa, karena programmer mengabaikan itu. Seperti yang disinggung tadi, ada satu mantra yang perlu diingat: “Jangan sembarang percaya kepada apa yang user berikan”. Most of vulnerability yang terjadi akibat programmer tidak melakukan sanitasi atau filtrasi terhadap inputan user.

Ini bukan hanya tentang SQL injection, jenis vulnerability yang paling sering terdengar, tapi in general di security, pengamanan itu ada di 3 fase: data yang dikirim (transmit), data yang diproses, dan data yang disimpan.

Mungkin sebagian dari kita sering mendengar yang namanya SQL injection, tapi sebenernya bukan hanya itu saja injection yang ada. Point 1 di OWASP Top 10 merangkum banyak sekali injection seperti SQL query, LDAP query, dsb yang menjadi inputan user jika suatu input menjadi bagian / komponen suatu query maka kita harus melakukan sanitasi terhadap input tersebut. Hal-hal yang perlu diperhatikan adalah adanya komponen pembentuk query didalam inputan user, sehingga user bisa memanipulasi query sesuka hati. Masih ada yang melakukan pembentukan query seperti ini (misal disederhanakan):

sql = "SELECT kolom1, kolom2 FROM tabel WHERE userid='" + $id + "' ";

Dosa pertama dari programmer adalah seperti ini:

Dengan $id tanpa disanitasi terlebih dahulu, untuk fungsi sanitasi bisa ke bahasa masing-masing.

Tapi model yang lebih baik adalah dengan melakukan parameterized untuk pembentukan query tak hanya SQL query, inputan user pun harus disanitasi untuk komponen-komponen yang bisa membuat script seperti kode-kode javascript. Harus di-escape terlebih dahulu.

Yang cukup jarang ada dan kadang terlupa adalah LDAP atau Directory protocol seperti query Active Directory. Ada juga model pengembangan aplikasi menggunakan ORM. Kadang juga tetap ada yang berdosa dengan lalai melakukan sanitasi ini.

Di OWASP Testing Guide v4 juga terdapat panduan untuk mengetes SQL Injection pada ORM, jadi jika dalam pikiran kita "tinggal pake ORM udah aman" maka sebaiknya segera bertobat. Tadi dijelaskan juga, input bisa berupa javascript maupun html tag. Biasanya inputan yang rentan terhadap ini bisa dimanfaatkan untuk menginjeksi kode javascript sehingga mentrigger yang namanya Cross-Side Scripting. Inti dari kelemahan ini adalah user korban bisa menjalankan script yang diberikan oleh attacker. Dampaknya apa?

Yang klasik adalah mencuri session korban tersebut (mendapatkan session aktif = attacker bisa masuk ke sistem sebagai korban). Ada pula kemungkinan kedua, melakukan phising, misalnya menggunakan script untuk membuat layer, membuat halaman palsu untuk menjebak korban dan bisa juga sekedar me-redirect korban ke suatu tempat yang lain dan menyuruhnya untuk "login" untuk bertobat dari ini, lakukan sanitasi untuk inputan yang akan ditampilkan ke user, baik inputan yang akan disimpan di database, maupun yang lain.

Selanjutnya adalah mengenai sesi.

Jika dibeberapa kondisi diatas bisa diatasi dengan penggunaan fasilitas yang disediakan oleh platform maupun framework, kerentanan ini cukup banyak terjadi karena penerapan logic yang kurang. Beberapa aplikasi yang Satri uji sudah menerapkan user management, dimana setiap user punya kewenangan dan resource tertentu yang harusnya hanya dia dan orang-orang yang setingkat dengannya yang bisa memproses.

Ada beberapa dosa disini:

Pertama, tidak memeriksa / memvalidasi privilege yang sudah diterapkan.

Misal, setiap user memiliki id. Setiap user dapat membuat dan mengedit task, yang direpresentasikan dengan id pula. Terkadang ketika kita mau mengedit task / dokumen / apapun kita hanya melihat id dokumen tersebut. Mungkin diawal ketika kita menampilkan daftar dokumen kita sudah memfilter "hanya dokumen yang dimiliki oleh si A" yang dapat tampil. Tapi kemudian ketika request untuk edit dengan seperti ini:

GET /GetDokumen.php?id=1654

Dengan melakukan perubahan nilai id aku bisa mengedit dokumen milik orang lain. Katakanlah bukan GET tapi POST, tidak akan berpengaruh. Selama tidak ada pengecekan, maka aku akan bisa mengeditnya. Dulu kerentanan ini disebut sebagai IDOR (InDirect Object Reference), sekarang bernama Broken Access Control, modifikasi URL, state internal HTML, atau request yang dikirimkan adalah proses standard yang biasanya dilakukan.

Kedua, tidak memvalidasi apakah benar request ini berasal dari user yang sesungguhnya.

Pernah dengar CSRF? Cross-Site Request Forgery. Secara singkat, user akan ditipu untuk melakukan sesuatu / mengirimkan request, tanpa sepengetahuannya. Biasanya ini dilakukan dengan kombo XSS.

Misalnya ketika mengunjungi suatu halaman, user yang terjebak akan mengirimkan request ke endpoint tertentu untuk melakukan transfer dana. Untuk mengatasi hal ini, diperlukan suatu yang unik yang hanya valid untuk individual request yang memang dikirimkan oleh user, bukan hasil kerja script. Dan ini disebut CSRF token, sebuah token unik yang di-generate dan dikirimkan oleh system ke user, dan harus dikirimkan oleh user ketika dia melakukan request pada saat itu.

Ketiga, mengeluarkan semua data yang gak "penting". Maksudnya tidak penting ini bagaimana?

Misal kita hanya butuh kolom nama dan segala riwayat dalam operasi "cek profil", tapi kita mengeluarkan semua kolum dalam baris itu dan misal dalam baris tersebut ada juga kolom yang ikut dikeluarkan seperti "kategori user". Isi kolom-kolom ini diberikan begitu saja, dan akan dikembalikan ke sistem. Secara tampilan user hanya bisa mengedit kolom nama dan biodata saja, tapi request yang terkirim adalah semua kolom. Dan pernah kejadian, Satria mengedit kolom role ini bisa membuat berubah role dari pegawai biasa menjadi administrator (setelah menganalisis sistem penamaan role), kadang kita memaklumi bahwa untuk mendapatkan data terkadang kita gak ambil pusing dan lempar saja 1 objek (1 baris database) dan simpan perubahannya. Tapi ini cukup fatal, untuk mengatasinya adalah dengan mengeluarkan apa yang kita butuhkan. Jika tidak memungkinkan, hanya proses apa yang kita butuhkan.

Ketiga dosa diatas tidak bisa diatasi dengan solusi WAF atau parameterized query. Karena itu pure logic. Jadi selalu lakukan validasi.

Dosa yang berikutnya adalah terlalu mengandalkan validasi di sisi client.

Beberapa aplikasi yang Satria uji berupa web service dengan front-end adalah sebuah mobile application (android). Validasi input cukup bagus di mobile app, kami tidak bisa input macam-macam. Tapi ternyata setelah kami dapatkan endpoint, kami bisa tembak langsung request ke sana. File upload yang harusnya dibatasi hanya bisa png ternyata hanya bisa divalidasi di sisi app, ketika di sisi server tidak ada validasi. Akhirnya kami bisa upload shell ke sana dan btw, itu server bank yang gak bisa Satria sebutkan. Ini dosa yang cukup berat, hanya melakukan validasi di sisi client dan ada beragam dosa yang sudah dicontohkan diatas.

Intinya adalah jangan percaya begitu saja apa yang diberikan oleh client. Sebenarnya akan ada banyak sekali dosa-dosa yang bisa disampaikan, tapi Satria harap dengan beberapa contoh di atas kita bisa mengambil hikmah untuk "tetap memvalidasi inputan user" dan setelah ini, periksa code kita lagi, apakah ada dosa-dosa seperti itu.

Ada banyak sekali jenis-jenis vulnerability dan Satria menyarankan untuk baca-baca OWASP baik dari OWASP Top 10, OWASP Secure Coding Guide, dan OWASP Testing Guide. Masing-masing memberikan pemahaman berbeda tentang security, dari sisi pengembang dan sisi penyerang.

“Ngeri ya, sekelas Bank bisa seceroboh itu. Itu bank lokal Kak?”

“Kebetulan local.”

Kadang kita "memaklumi" bahwa deadline yang singkat membuat orang lebih fokus ke fungsionalitas. Yang penting jalan dulu. Oh ya, dampaknya kalo Satria bisa tanam webshell tadi, Satria bisa remote server-nya, jalankan command, hingga bisa gerak untuk manipulasi server dan kalau mau sebutin semua dosa mah banyak amat, batasi aja dengan contoh-contoh diatas. Yang penting kudu paham mantranya aja.

Satria pernah liat di HackerOne, tentang XSS. Kalau secara awam seperti XSS tidak terlalu parah. Tapi kenapa XSS banyak reward yang didapat dari XSS vuln. Sebenernya seberapa parah XSS itu efeknya?

Nah, ini yang menarik. Kadang report XSS cuman sekedar bisa nampilin alert('1') tapi jika diolah dengan benar, kita bisa melakukan apapun. Secara, javascript itu jalan di sisi client.

Misal Satria sisipin kode untuk download malware, bagaimana? Download malware dan jalankan. Terus nanti ada report bahwa situs X menyebarkan malware, bakal hilang tidak trust-nya? atau finansial ya tadi, kita membuat tampilan yang mengecoh, batas akhir hanyalah kreatifitas

Oh, ada satu quote (?) menarik.

“Orang yang lebih memahami sistem adalah developer atau pembuatnya, semua logic yang ada adalah buatan para developer. Jadi harusnya developer lebih tahu daripada penyerang. Tinggal bagaimana kita bisa mengetahui kesalahan yang umum terjadi.”

Pertanyaan:

Halo kak, mau tanya tentang sanitasi user input untuk mencegah xss misal studi kasusnya blog, yang ada kolom komentar. User kan bisa aja input kode js disitu kolom komentar. Lalu memblok kode js saja apakah cukup?

aku kasih reference deh, yang cukup bagus: The Web Application hacker's Handbook" in most case, cukup. Escape aja semua karakter pembentuk kodenya.

Wah berarti tag lain selain <script> tidak akan menyebabkan masalah xss?

Kalau tag html yang lain namanya bukan XSS tapi HTML injection jadinya. Dan ya harus disanitasi juga. Baiknya semua tag di-escape prevention XSS bisa dilihat di OWASP.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Utk ngehash password, md5 kan udah broken ya.

Penggantinya banyak, tapi yang direkomendasikan pakai apa ya kak?

Lalu, kan ada yang implementasi salt juga ya di password??

Sebenarnya sebaiknya kita simpan salt dimana kak? Di database kah atau di kode (hardcoded / conf file?)

Kalau di db, kena sql injection, bubar ketauan salt nya, best practice nya gimana yah kak?

*maaf klo pertanyaan nya trlalu cupu

Jadi gini, perlu dipahami dulu goal kita apa, kita perlu memproteksi password, jangan disimpan dalam bentuk plaintext atau terbaca begitu saja. Kenapa "hanya menggunakan hash saja" itu tidak disarankan? karena ada:

1. kemungkinan collision

2. ada banyak bertebaran kamus pasangan antara text dengan bentuk hash-nya

Nah yang dimaksud broken lebih ke arah "dimungkinkan untuk mencari A sedemikian hingga hash(A) = hash(password) dengan A != B". Jadi bukan nilai hash didapatkan kembali password-nya.

Ohh gitu, I see password yang berbeda hash nya bisa sama

Collision itu apa kak?

Collision itu tubrukan.

In this case kita perlu salt sehingga nilai yang akan di-hash bukanlah password doang tapi kombinasi antara salt dan password.

Misal, kalo cuman 1 salt dan 1 password bisa diperoleh kombinasi cara seperti ini:

salt+password

password+salt

pass+salt+word

Tapi salt ini tidak boleh statis atau sama terhadap semua user, kita harus bikin mekanisme generation salt yang cukup random tapi cukup mudah dibikin ulang menyimpan ke database juga gak aman, kenapa? ada kemungkinan ketika sudah berhasil SQL injection maka database di-dump termasuk salt. Nah kuncinya adalah "generate salt yang random tapi bisa didapatkan berulang-ulang" alais pseudorandom. Jadi gak perlu disimpan -> gak perlu khawatir kalo data jebol maka salt ketebak. Ya, selama aplikasi gak di-reverse sih.

Misal ada password, kita sebut B, ketika dioperasikan fungsi hash jadi hash(B). Kita berusaha menemukan tubrukan atau kondisi dimana sesuatu A di hash menjadi hash(A) memiliki nilai yang sama dengan hash(B). Padahal A dan B bukanlah nilai yang sama

https://en.wikipedia.org/wiki/Collision_attack

Selama ini aku bingung karena kalau orang tahu salt nya, nanti tahu password nya juga kan, kayak tubrukan motor lah, motor berbeda tapi mereka berada di lintasan yang sama, tempat yang sama, dan waktu yang sama maka tabrakan dong.

Abis ini aku baca2 dulu ttg pseudorandom itu.

Ini juga, hash(A) dan hash(B) nilainya sama, padahal A dan B beda

Oh ya, saran juga!! jangan pake encryption buat menyimpan password.

Selalu gunakan hash + salt

Password udah di hash+salt

Salt digenerate random. Tapi, Ketika login, gimana cara kirim "username+password" yg aman ya?

Kalau di sniff bukan kah ketauan juga "password" nya apa?

Semua hash pasti akan ada collision. Ingat prinsip pigeonhole aja di kuliah.

Hash itu kan nilai hasilnya selalu sama panjangnya. Dari data input yang tak terbatas panjangnya direduksi hasilnya jadi sekian bit, pasti akan ada input beda yang menghasilkan output sama, cuman yang jadi pertanyaan, bisa gak kita cari pattern supaya membuat collision itu practically happen. Ada beberapa yang mengandalkan komunikasi HTTPS ketika login sehingga jalur dienkripsi.

Ada yang mengandalkan transformasi dulu di sisi client sebelum dikirim ke server, regardless ada atau tidaknya saluran HTTPS. Idenya adalah server mengirimkan semacam "key" dan password ini diproses macam apapun dengan key itu sebelum dikirim. Pendekatan ini mencegah si pengendus atau orang ketiga untuk membaca password terang-terangan. Minimal dia harus tau bagaimana cara password itu dibentuk. But, selalu ada cara untuk mengakali sih.

Salah satu caranya yaitu enkripsi.

Misalnya kalau pakai php deh yang umum, tidak kebayang transformasi di client nya gimana

Javascript. Kebayangnya kirim data Nya ke server dulu, terus transformasi disana.

Javascript enkrip dulu sebelum dikirim, baru ketemu.

Salah satunya: https://code.google.com/archive/p/crypto-js/

Inilah materi dari Kak Satria tentang OWASP dan dosa-dosa yang sering programmer lakukan terkait dalam security terutama web. Saya akan kasih materi lain yang InsyaAllah bermanfaat untuk kalian semua. Tunggu Blogku SELANJUTNYA……………….

SIKUSTIK Bidadari Keseleo

VIRAL!!!! BOYBAND NGIK-NGIK DANCE

OWASP dan dosa dalam Web Application Security

OWASP dan dosa dalam Web Application Security

Materi oleh Satria Ady Pradana

Satria Ady Pradana akan sharing tentang OWASP dan dosa-dosa yang sering programmer lakukan terkait dalam security terutama web.

apa itu OWASP?

apa dosa yang sering dilakukan?

apakah kita juga termasuk sering berdosa?

Disini akan dibahas OWASP terlebih dahulu.

OWASP atau Open Web Application Security Project adalah komunitas yang berinisiatif untuk menghimpun resource dan mencerahkan orang lain terkait web application security. Yang paling terkenal dari OWASP adalah OWASP Top 10 project, dimana setiap beberapa tahun sekali mereka merilis 10 common security risks yang ada direntang waktu itu. Misal yang mau rilis bentar lagi adalah OWASP Top 10 2017, sebelumnya OWASP Top 10 2013. Di OWASP Top 10 2017 kita akan bisa melihat kira-kira apa aja sih yang menjadi tren security risk di dunia.

OWASP Top 10 bisa dilihat di sini:

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Untuk saat ini, versi 2017 mencapai RC2 yang bisa diunduh di sini:

https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010%202017%20RC2%20Final.pdf

10 peringkat ini sering menjadi acuan pentester untuk melakukan security awareness sekaligus juga panduan dalam pentesting.

1. Injection

2. Broken Authentication

3. Sensitive Data Exposure

4. XML External Entities (XXE)

5. Broken Access Control

6. Security Msiconfiguration

7. Cross-Site Scripting

8. Insecure Deserialization

9. Using COmponents with Known Vulnerabilities

10. Insufficient Logging & Monitoring

Tapi...

Kalau bisa kita rangkum dan ambil inti sarinya kita bisa berpedoman pada satu mantra:

“Jangan sembarang percaya kepada apa yang user berikan”.

Selain merilis 10 common security risk tadi, OWASP juga memberikan guideline juga bagaimana mengetes aplikasi dan bagaimana mendesain aplikasi web yang secure.

Misalnya disini, secure coding:

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

Code review:

https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

Testing (pentesting juga):

https://www.owasp.org/index.php/OWASP_Testing_Project

Ada banyak sebenarnya tapi kita bahas yang umum saja dan yang sering menjadi dosa, karena programmer mengabaikan itu. Seperti yang disinggung tadi, ada satu mantra yang perlu diingat: “Jangan sembarang percaya kepada apa yang user berikan”. Most of vulnerability yang terjadi akibat programmer tidak melakukan sanitasi atau filtrasi terhadap inputan user.

Ini bukan hanya tentang SQL injection, jenis vulnerability yang paling sering terdengar, tapi in general di security, pengamanan itu ada di 3 fase: data yang dikirim (transmit), data yang diproses, dan data yang disimpan.

Mungkin sebagian dari kita sering mendengar yang namanya SQL injection, tapi sebenernya bukan hanya itu saja injection yang ada. Point 1 di OWASP Top 10 merangkum banyak sekali injection seperti SQL query, LDAP query, dsb yang menjadi inputan user jika suatu input menjadi bagian / komponen suatu query maka kita harus melakukan sanitasi terhadap input tersebut. Hal-hal yang perlu diperhatikan adalah adanya komponen pembentuk query didalam inputan user, sehingga user bisa memanipulasi query sesuka hati. Masih ada yang melakukan pembentukan query seperti ini (misal disederhanakan):

sql = "SELECT kolom1, kolom2 FROM tabel WHERE userid='" + $id + "' ";

Dosa pertama dari programmer adalah seperti ini:

Dengan $id tanpa disanitasi terlebih dahulu, untuk fungsi sanitasi bisa ke bahasa masing-masing.

Tapi model yang lebih baik adalah dengan melakukan parameterized untuk pembentukan query tak hanya SQL query, inputan user pun harus disanitasi untuk komponen-komponen yang bisa membuat script seperti kode-kode javascript. Harus di-escape terlebih dahulu.

Yang cukup jarang ada dan kadang terlupa adalah LDAP atau Directory protocol seperti query Active Directory. Ada juga model pengembangan aplikasi menggunakan ORM. Kadang juga tetap ada yang berdosa dengan lalai melakukan sanitasi ini.

Di OWASP Testing Guide v4 juga terdapat panduan untuk mengetes SQL Injection pada ORM, jadi jika dalam pikiran kita "tinggal pake ORM udah aman" maka sebaiknya segera bertobat. Tadi dijelaskan juga, input bisa berupa javascript maupun html tag. Biasanya inputan yang rentan terhadap ini bisa dimanfaatkan untuk menginjeksi kode javascript sehingga mentrigger yang namanya Cross-Side Scripting. Inti dari kelemahan ini adalah user korban bisa menjalankan script yang diberikan oleh attacker. Dampaknya apa?

Yang klasik adalah mencuri session korban tersebut (mendapatkan session aktif = attacker bisa masuk ke sistem sebagai korban). Ada pula kemungkinan kedua, melakukan phising, misalnya menggunakan script untuk membuat layer, membuat halaman palsu untuk menjebak korban dan bisa juga sekedar me-redirect korban ke suatu tempat yang lain dan menyuruhnya untuk "login" untuk bertobat dari ini, lakukan sanitasi untuk inputan yang akan ditampilkan ke user, baik inputan yang akan disimpan di database, maupun yang lain.

Selanjutnya adalah mengenai sesi.

Jika dibeberapa kondisi diatas bisa diatasi dengan penggunaan fasilitas yang disediakan oleh platform maupun framework, kerentanan ini cukup banyak terjadi karena penerapan logic yang kurang. Beberapa aplikasi yang Satri uji sudah menerapkan user management, dimana setiap user punya kewenangan dan resource tertentu yang harusnya hanya dia dan orang-orang yang setingkat dengannya yang bisa memproses.

Ada beberapa dosa disini:

Pertama, tidak memeriksa / memvalidasi privilege yang sudah diterapkan.

Misal, setiap user memiliki id. Setiap user dapat membuat dan mengedit task, yang direpresentasikan dengan id pula. Terkadang ketika kita mau mengedit task / dokumen / apapun kita hanya melihat id dokumen tersebut. Mungkin diawal ketika kita menampilkan daftar dokumen kita sudah memfilter "hanya dokumen yang dimiliki oleh si A" yang dapat tampil. Tapi kemudian ketika request untuk edit dengan seperti ini:

GET /GetDokumen.php?id=1654

Dengan melakukan perubahan nilai id aku bisa mengedit dokumen milik orang lain. Katakanlah bukan GET tapi POST, tidak akan berpengaruh. Selama tidak ada pengecekan, maka aku akan bisa mengeditnya. Dulu kerentanan ini disebut sebagai IDOR (InDirect Object Reference), sekarang bernama Broken Access Control, modifikasi URL, state internal HTML, atau request yang dikirimkan adalah proses standard yang biasanya dilakukan.

Kedua, tidak memvalidasi apakah benar request ini berasal dari user yang sesungguhnya.

Pernah dengar CSRF? Cross-Site Request Forgery. Secara singkat, user akan ditipu untuk melakukan sesuatu / mengirimkan request, tanpa sepengetahuannya. Biasanya ini dilakukan dengan kombo XSS.

Misalnya ketika mengunjungi suatu halaman, user yang terjebak akan mengirimkan request ke endpoint tertentu untuk melakukan transfer dana. Untuk mengatasi hal ini, diperlukan suatu yang unik yang hanya valid untuk individual request yang memang dikirimkan oleh user, bukan hasil kerja script. Dan ini disebut CSRF token, sebuah token unik yang di-generate dan dikirimkan oleh system ke user, dan harus dikirimkan oleh user ketika dia melakukan request pada saat itu.

Ketiga, mengeluarkan semua data yang gak "penting". Maksudnya tidak penting ini bagaimana?

Misal kita hanya butuh kolom nama dan segala riwayat dalam operasi "cek profil", tapi kita mengeluarkan semua kolum dalam baris itu dan misal dalam baris tersebut ada juga kolom yang ikut dikeluarkan seperti "kategori user". Isi kolom-kolom ini diberikan begitu saja, dan akan dikembalikan ke sistem. Secara tampilan user hanya bisa mengedit kolom nama dan biodata saja, tapi request yang terkirim adalah semua kolom. Dan pernah kejadian, Satria mengedit kolom role ini bisa membuat berubah role dari pegawai biasa menjadi administrator (setelah menganalisis sistem penamaan role), kadang kita memaklumi bahwa untuk mendapatkan data terkadang kita gak ambil pusing dan lempar saja 1 objek (1 baris database) dan simpan perubahannya. Tapi ini cukup fatal, untuk mengatasinya adalah dengan mengeluarkan apa yang kita butuhkan. Jika tidak memungkinkan, hanya proses apa yang kita butuhkan.

Ketiga dosa diatas tidak bisa diatasi dengan solusi WAF atau parameterized query. Karena itu pure logic. Jadi selalu lakukan validasi.

Dosa yang berikutnya adalah terlalu mengandalkan validasi di sisi client.

Beberapa aplikasi yang Satria uji berupa web service dengan front-end adalah sebuah mobile application (android). Validasi input cukup bagus di mobile app, kami tidak bisa input macam-macam. Tapi ternyata setelah kami dapatkan endpoint, kami bisa tembak langsung request ke sana. File upload yang harusnya dibatasi hanya bisa png ternyata hanya bisa divalidasi di sisi app, ketika di sisi server tidak ada validasi. Akhirnya kami bisa upload shell ke sana dan btw, itu server bank yang gak bisa Satria sebutkan. Ini dosa yang cukup berat, hanya melakukan validasi di sisi client dan ada beragam dosa yang sudah dicontohkan diatas.

Intinya adalah jangan percaya begitu saja apa yang diberikan oleh client. Sebenarnya akan ada banyak sekali dosa-dosa yang bisa disampaikan, tapi Satria harap dengan beberapa contoh di atas kita bisa mengambil hikmah untuk "tetap memvalidasi inputan user" dan setelah ini, periksa code kita lagi, apakah ada dosa-dosa seperti itu.

Ada banyak sekali jenis-jenis vulnerability dan Satria menyarankan untuk baca-baca OWASP baik dari OWASP Top 10, OWASP Secure Coding Guide, dan OWASP Testing Guide. Masing-masing memberikan pemahaman berbeda tentang security, dari sisi pengembang dan sisi penyerang.

“Ngeri ya, sekelas Bank bisa seceroboh itu. Itu bank lokal Kak?”

“Kebetulan local.”

Kadang kita "memaklumi" bahwa deadline yang singkat membuat orang lebih fokus ke fungsionalitas. Yang penting jalan dulu. Oh ya, dampaknya kalo Satria bisa tanam webshell tadi, Satria bisa remote server-nya, jalankan command, hingga bisa gerak untuk manipulasi server dan kalau mau sebutin semua dosa mah banyak amat, batasi aja dengan contoh-contoh diatas. Yang penting kudu paham mantranya aja.

Satria pernah liat di HackerOne, tentang XSS. Kalau secara awam seperti XSS tidak terlalu parah. Tapi kenapa XSS banyak reward yang didapat dari XSS vuln. Sebenernya seberapa parah XSS itu efeknya?

Nah, ini yang menarik. Kadang report XSS cuman sekedar bisa nampilin alert('1') tapi jika diolah dengan benar, kita bisa melakukan apapun. Secara, javascript itu jalan di sisi client.

Misal Satria sisipin kode untuk download malware, bagaimana? Download malware dan jalankan. Terus nanti ada report bahwa situs X menyebarkan malware, bakal hilang tidak trust-nya? atau finansial ya tadi, kita membuat tampilan yang mengecoh, batas akhir hanyalah kreatifitas

Oh, ada satu quote (?) menarik.

“Orang yang lebih memahami sistem adalah developer atau pembuatnya, semua logic yang ada adalah buatan para developer. Jadi harusnya developer lebih tahu daripada penyerang. Tinggal bagaimana kita bisa mengetahui kesalahan yang umum terjadi.”

Pertanyaan:

Halo kak, mau tanya tentang sanitasi user input untuk mencegah xss misal studi kasusnya blog, yang ada kolom komentar. User kan bisa aja input kode js disitu kolom komentar. Lalu memblok kode js saja apakah cukup?

aku kasih reference deh, yang cukup bagus: The Web Application hacker's Handbook" in most case, cukup. Escape aja semua karakter pembentuk kodenya.

Wah berarti tag lain selain <script> tidak akan menyebabkan masalah xss?

Kalau tag html yang lain namanya bukan XSS tapi HTML injection jadinya. Dan ya harus disanitasi juga. Baiknya semua tag di-escape prevention XSS bisa dilihat di OWASP.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Utk ngehash password, md5 kan udah broken ya.

Penggantinya banyak, tapi yang direkomendasikan pakai apa ya kak?

Lalu, kan ada yang implementasi salt juga ya di password??

Sebenarnya sebaiknya kita simpan salt dimana kak? Di database kah atau di kode (hardcoded / conf file?)

Kalau di db, kena sql injection, bubar ketauan salt nya, best practice nya gimana yah kak?

*maaf klo pertanyaan nya trlalu cupu

Jadi gini, perlu dipahami dulu goal kita apa, kita perlu memproteksi password, jangan disimpan dalam bentuk plaintext atau terbaca begitu saja. Kenapa "hanya menggunakan hash saja" itu tidak disarankan? karena ada:

1. kemungkinan collision

2. ada banyak bertebaran kamus pasangan antara text dengan bentuk hash-nya

Nah yang dimaksud broken lebih ke arah "dimungkinkan untuk mencari A sedemikian hingga hash(A) = hash(password) dengan A != B". Jadi bukan nilai hash didapatkan kembali password-nya.

Ohh gitu, I see password yang berbeda hash nya bisa sama

Collision itu apa kak?

Collision itu tubrukan.

In this case kita perlu salt sehingga nilai yang akan di-hash bukanlah password doang tapi kombinasi antara salt dan password.

Misal, kalo cuman 1 salt dan 1 password bisa diperoleh kombinasi cara seperti ini:

salt+password

password+salt

pass+salt+word

Tapi salt ini tidak boleh statis atau sama terhadap semua user, kita harus bikin mekanisme generation salt yang cukup random tapi cukup mudah dibikin ulang menyimpan ke database juga gak aman, kenapa? ada kemungkinan ketika sudah berhasil SQL injection maka database di-dump termasuk salt. Nah kuncinya adalah "generate salt yang random tapi bisa didapatkan berulang-ulang" alais pseudorandom. Jadi gak perlu disimpan -> gak perlu khawatir kalo data jebol maka salt ketebak. Ya, selama aplikasi gak di-reverse sih.

Misal ada password, kita sebut B, ketika dioperasikan fungsi hash jadi hash(B). Kita berusaha menemukan tubrukan atau kondisi dimana sesuatu A di hash menjadi hash(A) memiliki nilai yang sama dengan hash(B). Padahal A dan B bukanlah nilai yang sama

https://en.wikipedia.org/wiki/Collision_attack

Selama ini aku bingung karena kalau orang tahu salt nya, nanti tahu password nya juga kan, kayak tubrukan motor lah, motor berbeda tapi mereka berada di lintasan yang sama, tempat yang sama, dan waktu yang sama maka tabrakan dong.

Abis ini aku baca2 dulu ttg pseudorandom itu.

Ini juga, hash(A) dan hash(B) nilainya sama, padahal A dan B beda

Oh ya, saran juga!! jangan pake encryption buat menyimpan password.

Selalu gunakan hash + salt

Password udah di hash+salt

Salt digenerate random. Tapi, Ketika login, gimana cara kirim "username+password" yg aman ya?

Kalau di sniff bukan kah ketauan juga "password" nya apa?

Semua hash pasti akan ada collision. Ingat prinsip pigeonhole aja di kuliah.

Hash itu kan nilai hasilnya selalu sama panjangnya. Dari data input yang tak terbatas panjangnya direduksi hasilnya jadi sekian bit, pasti akan ada input beda yang menghasilkan output sama, cuman yang jadi pertanyaan, bisa gak kita cari pattern supaya membuat collision itu practically happen. Ada beberapa yang mengandalkan komunikasi HTTPS ketika login sehingga jalur dienkripsi.

Ada yang mengandalkan transformasi dulu di sisi client sebelum dikirim ke server, regardless ada atau tidaknya saluran HTTPS. Idenya adalah server mengirimkan semacam "key" dan password ini diproses macam apapun dengan key itu sebelum dikirim. Pendekatan ini mencegah si pengendus atau orang ketiga untuk membaca password terang-terangan. Minimal dia harus tau bagaimana cara password itu dibentuk. But, selalu ada cara untuk mengakali sih.

Salah satu caranya yaitu enkripsi.

Misalnya kalau pakai php deh yang umum, tidak kebayang transformasi di client nya gimana

Javascript. Kebayangnya kirim data Nya ke server dulu, terus transformasi disana.

Javascript enkrip dulu sebelum dikirim, baru ketemu.

Salah satunya: https://code.google.com/archive/p/crypto-js/

Inilah materi dari Kak Satria tentang OWASP dan dosa-dosa yang sering programmer lakukan terkait dalam security terutama web. Saya akan kasih materi lain yang InsyaAllah bermanfaat untuk kalian semua. Tunggu Blogku SELANJUTNYA……………….

Data Mining

Materi oleh Anne Regina Nancy Toar

Kali ini membahas tentang konsep data mining dan bagaimana proses data mining secara garis besar. Kita awali dengan membahas tentang definisi data mining.

Data mining dikenal juga dengan knowledge discovery in database, atau istilah yang sedang tren belakangan ini adalah data science. Ini adalah cabang ilmu yang membahas tentang pemrosesan data untuk mendapatkan tren atau pola yang bermanfaat dari kumpulan data. Tren atau pola yang bermanfaat ini sering disebut dengan informasi.

Perlu kita pahami dulu apa itu data, informasi dan pengetahuan.

-       Data adalah fakta, angka, atau hal/kejadian tanpa konteks dan bersifat objektif.

-       Informasi adalah data yang telah diorganisasikan/dikelola/diproses sehingga mempunyai arti.

-   Pengetahuan adalah campuran dari pengalaman, nilai, informasi, dan wawasan, yang merupakan kerangka untuk memahami pengalaman dan informasi baru serta untuk mengambil tindakan yang tepat pada situasi yang bervariasi dan tak pasti.

Ilustrasi tentang data, informasi dan pengetahuan dalam gambar di atas mudah-mudahan memperjelas dan memberikan gambaran bagaimana tingkatan data, informasi dan pengetahuan.

Dari mana kita peroleh data?

Dalam era big data sekarang ini data bisa diperoleh dari mana-mana dengan bentuk yang bermacam-macam. Tetapi kumpulan data tanpa pemrosesan belum memiliki arti, sehingga salah satu ilmuwan mengatakan, “Today, we are drowning in data and starved for information.”

Berdasarkan sumbernya, data dapat digolongkan menjadi 3:

1. Data yang dihasilkan oleh mesin

2. Data yang dihasilkan oleh masyarakat atau individu secara personal

3. Data yang dihasilkan dalam suatu organisasi

Sumber data terbesar adalah data yang dihasilkan oleh mesin. Contohnya antara lain data yang didapat dari sensor, gambar satelit, jaringan mobile phone, dll. Dalam satu kali penerbangan pesawat terbang misalnya, dihasilkan sekitar setengah terabyte data dari segala sensor dan peralatan yang ada pada pesawat. Belum lagi data yang dihasilkan oleh smart device, contoh yang sederhana misalnya sport tracker yang dapat mendeteksi detak jantung, jumlah langkah, berapa km jarak yang sudah ditempuh. Tinggal dikalikan saja jumlah smart device di dunia dan besar data yang dikumpulkan, akan didapat volume data yang warbyasah besarnya.

Sementara itu, perkembangan teknologi web dan sosial media juga mendorong individu untuk menyumbang data dalam jumlah yang cukup besar. Data harian dari facebook misalnya, dikatakan volumenya lebih besar daripada data perpustakaan di seluruh amerika. Belum data dari sosial media lainnya (twitter, IG, linkedIn, dll), wiki, blog, email, dokumen, video, audio.

Data yang dihasilkan oleh masyarakat atau individu tersebut memiliki format yang tidak terstruktur (unstructured data) yang menimbulkan tantangan sendiri untuk menganalisisnya. Kemudian jenis data yang ketiga, data dalam organisasi. Jenis data ini yang paling sering kita temui jika biasa berkecimpung di dunia database. Data dari organisasi umumnya bentuknya terstruktur, berada dalam basis data, tetapi  tidak terintegrasi (data silos). Contohnya antara lain, data transaksi keuangan, e-commerce, data medical records, data hrd organisasi, dll.

Mengapa “menambang” data?

Data yang begitu banyak yang sudah dijelaskan tadi, sebagian besar tidak pernah dianalisis sama sekali. Seringkali informasi tersembunyi didalam data dan sulit untuk dibuktikan keberadaannya.

Istilah “data mining” sendiri dipakai pertama kali oleh para ahli statistik.

Awalnya istilah tersebut dipakai dalam konotasi negatif, karena dianggap sebagai upaya ekstraksi informasi yang tidak didukung oleh data. Namun dengan kemajuan ilmu komputer dan machine learning, cabang ilmu data mining semakin berkembang. Bahkan kini perkembangan teknologi big data membuka peluang-peluang baru untuk melakukan analisis terhadap data dengan jumlah yang besar. Banyak contoh pengaplikasian data mining dalam kehidupan sehari-hari. Dalam dunia bisnis dan ekonomi, terutama dipakai untuk mengenali konsumen dan memprediksi perilaku konsumen.

Bagaimana kerangka kerja dalam data mining?

Tahapan dalam proses data mining adalah sbb:

1.  Mengenali masalah yang akan dipecahkan

2.  Memahami data

3.  Pra pemrosesan data

4.  Pemodelan data

5.  Evaluasi

Tahap pertama adalah mengenali masalah yang akan dipecahkan.

Contoh: kita ingin mengaplikasikan teknik data mining untuk meningkatkan kualitas produk. Sebagai langkah awal, kita harus mendefinisikan pertanyaan atau masalah. Dapat dimulai dari pertanyaan yang umum seperti, kenapa sangat banyak keluhan dari konsumen? Bagaimana cara meningkatkan margin laba per unit? Bagaimana cara mengantisipasi dan memperbaiki kekurangan manufaktur untuk menghindari pengiriman produk yang cacat?

Dari sana, pertanyaan-pertanyaan yang lebih spesifik dapat dirumuskan. Sampai akhirnya semakin mengerucut dan masalahnya semakin tajam dan memungkinkan kita untuk melanjutkan ke tahap berikutnya.

Tahap kedua adalah memahami data.

Dari masalah yang telah dirumuskan tadi, kita telusuri lebih lanjut

Variabel-variabel apa yang terkait dengan pemecahan masalah?

Variabel apa yang perlu dipakai?

Siapa yang memiliki data yang diperlukan?

Dari mana data itu berasal?

Bagaimana data disimpan?

Bagaimana kita bisa mendapatkan data tersebut?

Apakah ada sesuatu dalam data tersebut yang tidak kita pahami? dll, dst.

Setelah kita benar-benar bisa mengidentifikasi dan memahami aset data yang kita punya, baru kita bisa lanjut.

Tahap ketiga adalah pra pemrosesan data.

Pada dasarnya semua data dapat dimining. Namun perlu kita sadari bahwa data memiliki tipe dan format yang berbeda-beda sehingga berbeda pula penangannya. Sumber data tidak hanya terbatas pada data terstruktur yang berada dalam basis data saja. Seringkali justru dalam data yang tidak terstruktur terkandung informasi yang sangat kaya. Tahap pra pemrosesan data meliputi banyak aktifitas. Antara lain, pembersihan data dari anomali (outlier) atau data yang hilang. Memperbaiki format data yang tidak konsisten. Atau dalam text mining dikenal aktifitas tokenisasi, stemming, pembobotan, dll.

Perlu kita ingat bahwa tahap kedua dan ketiga ini sangat penting dalam proses data mining.

Input data sampah hanya akan menghasilkan output sampah juga. Data yang tidak akurat atau tidak lengkap bisa jadi lebih buruk daripada tidak ada data sama sekali, karena keputusan berdasarkan sebagian data atau data yang salah akan menghasilkan keputusan yang salah atau tidak menyeluruh.

Tahap keempat adalah pemodelan data.

Dalam tahap ini data set yang didapat dari tahap sebelumnya diinputkan ke dalam algoritma sesuai dengan masalah yang ingin kita pecahkan. Ada banyak tipe algoritma dalam data mining. Beberapa di antaranya: regresi, klasifikasi, clustering, association rule, decision tree, recommender system, anomaly detection.

Kemudian masuk tahap berikutnya, yaitu evaluasi

Salah satu jebakan dalam data mining adalah bahwa pola yang kita temukan belum tentu bermakna. Penyebabnya bisa jadi karena teknik yang dipakai salah atau memang tidak ada pola yang menarik dalam data. Evaluasi bisa dilakukan dengan sejumlah metode, baik matematis maupun logis. Selain itu juga seringkali diperlukan pendapat ahli untuk menarik kesimpulan yang barangkali tidak dapat diukur secara matematis, tetapi tetap diperlukan untuk menilai model atau pengetahuan yang dihasilkan.

#ask metode matematikA itu maksdnya gmna kak

Jawab:

Pakek rumus. Misal dalam proses klasifikasi

akurasi = jumlah data yang diklasifikasikan secara tepat dibagi (jumlah data yang diklasifikasikan tepat + data yang salah diklasifikasi)

#ask kalau maksudnya pola tidak bermakna itu seperti apa kak? kita bisa menyadarinya kalau pola salah?

Jawab:

Contohnya mungkin bisa dilihat pada kasus Google Flu Trend. Jadi Google sekitar tahun 2009 berusaha memprediksi kondisi terjadinya flu berdasarkan keyword pencarian terkait flu. Pada awalnya sepertinya ada korelasi antara keyword pencarian dengan jumlah penderita flu. Asumsinya orang yang kena flu akan googling mengenai flu, algoritmanya menghasilkan hasil yang cepat dibandingkan dengan prediksi yang dikeluarkan oleh lembaga resmi. Namun lama kelamaan hasil prediksi dari google tersebut melenceng sangat jauh. Lembaga resmi mengeluarkan prediksi berdasarkan data pasien dari dokter. Sementara sumber data google adalah keyword pencarian. Lah yang googling terkait flu kan belum tentu penderita flu

Buat yang ingin coba2 bermain dengan data mining, ini beberapa tools open source yang dapat digunakan untuk data mining antara lain: RapidMiner, KNIME, Orange, WEKA. RapidMiner dan KNIME yang paling mudah dipakai katanya sih.

👆tampilan awal rapidminer

tersedia tutorial yg lumayan gampang diikuti

Bisa diunduh dari https://rapidminer.com/

Silahkan bagi yang ingin mencoba

Kalau bahasa pemrograman yang biasa dipakai java atau python. Tetapi yang sedang banyak dipakai sekarang python dengan scikit learn.

https://docs.rapidminer.com/downloads/DataMiningForTheMasses.pdf

referensi yg bagus utk belajar data mining 👆

sekian, terima kasih telah mengunjungi blog saya.