OM, perbanyaakk video kek ginii dong om perluu bangett soalnyaa pengalaman darii senior gituu biar gaa ngulangin kesalahan yang samaa dann semogaa videoo yang impelemntasii project real bisaa cepet jadinyaaa aamiin, makasii om ilmunyaaa
kecerobohan menaruh logic validasi ternyata masih saja terjadi. sudah beberapa kali saya lihat dan bahkan nemu sendiri kasus seperti ini, terakhir paling parah saya nemu di salah satu kampus negeri di indonesia, sistem akademiknya pakai validasi berdasarkan input di view. sehingga bisa dengan mudah dimanupulasi dengan html untuk mendaftar di suatu kelas. bahkan sessionnya tidak ada validasi kita bisa login ke akun lain hanya dengan mengubah cookie nomor induk mahasiswanya, bahkan kalau tega kita bisa hapus daftar kelas mahasiswa lain. bahkan mencuri data penting seperti foto formal, scan ktp, nama orang tua dan ijazah 😂 tapi syukurlah kampusnya sekarang sudah berbenah, sekarang kecerobohan itu sudah diperbaiki.
Itu dia kenapa pas bikin project kita wajib memposisikan diri sebagai org jahat sejahat2nya. Jangan bikin aplikasi asal jadi ga ada bug, harus mikir jg gmn cara kita bobol/exploit aplikasinya.
alhamdulillah dari umur 19 gue paham dan kerja di backend, sesimple kek gini gue ga pernah lalai. pernah temen gue yang frontend gue maki-maki karna validasi di frontendnya lalai, walaupun di backendnnya udah gue validasi, tapi ga ada salahnya buat double validation baik di frontend dan backend.
validasi itu lebih baik satu arah, semua ada di backend. kalo antara backend dan frontend nya kurang komunikasi, bisa jadi ada miss match antara yang dilakukan frontend dan backend. Bayangkan juga aplikasinya adalah multiplatform, ada mobile ada website. Kalo melakukan validasi di frontend memungkinkan validasi yang dilakukan antara mobile dan website beda. so, ngga ada salahnya frontend ngga melakukan validasi, karena itu sudah jadi tanggung jawab dari backend. catatan: frontend boleh melakukan validasi untuk hal hal sepele saja, seperti required input, number input, email input. hal itu untuk meningkatkan UX agar tidak perlu melakukan submit dulu, menunggu dan menampilkan hasil error validasi. CMIIW
Untuk price biasa saya tetap kirimkan dari client ke backend, walaupun dari backend tetap retrieve price dari master product lagi. Lalu buat apa price dari client? Biasanya untuk alert ke user jika tiba2 ada harga yg berubah di backend, apakah mau melanjutkan dengan harga yang baru. Web yg menjual item dgn volatilitas harga yg tinggi, misal emas, valuta, kripto, dll akan sangat perlu menerapkan hal semacam ini.
Alhamdulillah ternyata sudah mengimplementasikan cara yang benar dari awal. selalu ngindari kirim data yang ga penting ke backend dan bikin validasi ganda. gegara setiap buat fitur selalu penasaran buat ngulik 'kalo saya buat fitur gini misal saya iseng gimana ya" dan ngetest.
Intinya jangan percaya data dari front end guys,Soalnya gampang di manipulasi, Saya si biasanya lanngsung aja kirim id,sama quantitynya kebackend Terus validasi dibackend,Dibackend tinggal select lagi aja ke database buat ambil pricenya
Kalau dari awal ngoding paham misahin mana front end mana backend, gk bakal kayak gini, tapi kan di indo banyak yg gelarnya "FULL STACK DEVELOPER PHP", rata rata kodingannya gini wkwk
@@indofiz1077Sebenernya bahasa apa bisa kena sih terutama ketika masih awam. Dulu saya awal awal belajar REST API langsung nyemplung NestJS FE nya NextJS juga banyak troubleshoot masalah seperti ini. Mulai dari AuthGuard sampe seperti yg ada di video. Setelah hampir 1 bulan punya pikiran "harus jadi secepat mungkin" dan cek Dev Tools ternyata banyak issue yang bisa di eksploitasi. Perlahan-lahan nanti akan bertambah jam terbang dan kesalahan seperti ini bisa berkurang. Learn path dan kecepatan belajar orang tiap orang berbeda, tapi saya selalu setuju kalo di tahapan belajar sebaiknya JOMO bukannya FOMO terutama terkait payment seperti ini 👍🏻
makasih banyak pak eko atas pembahasannya. soalnya saya butuh bgt pembahasan ini karena banyak bgt isu web top up game dimanipulasi datanya. sukses terus buat pak eko
Alhamdulillah jadi paham baru banget buat web penjualan setelah belajar baru sadar bisa aj itu emang kesalahan logic kita, btw yang udah nanya makasih banyak lope u sekebon
Betul, kalaupun misal ada multiple price , diskon, dll yg memberikan perbedaan dari suatu price cukup dikirim id price, id diskon, dan id id yang lain.
Untuk kasus terkait price tadi, bagaimana penanganan apabila ada perubahaan harga sesaat setelah produk dilihat oleh user? harga yang tertera pada kerangjang pasti berbeda dengan harga pada database
updateeee salahhhh jangan pakai data database, karena semisal harga awal 2 juta terus tiba2 naik jadi 5 juta terus diterusin prosesnya tanpa minta konfirmasi user dulu bisa-bisa diprotes user karena uangnya kepotong 5 juta bukan kehendaknya, paling parah kalau usernya ga terima bisa dituntut kasus penipuan. kirim response ke user bahwa harganya telah berubah menjadi sekian, apakah ingin lanjut atau batal? kalau user klik batal terus batalin prosesnya
@@nasimicinupdateeee salahhhh jangan pakai data database, karena semisal harga awal 2 juta terus tiba2 naik jadi 5 juta terus diterusin prosesnya tanpa minta konfirmasi user dulu bisa-bisa diprotes user karena uangnya kepotong 5 juta bukan kehendaknya, paling parah kalau usernya ga terima bisa dituntut kasus penipuan. kirim response ke user bahwa harganya telah berubah menjadi sekian, apakah ingin lanjut atau batal? kalau user klik batal terus batalin prosesnya
bener sih, mungkin temen2 bisa create table carts dan cart_items selain order dan order_items, dan ga perlu kirimin detail produk yang mau di order, cukup kirim id cart aja dan dia bisa proses dari situ. FYI si table carts dan cart_items ini datanya dihapus setelah masuk table orders, pastiin juga si carts ini dikasih expired yhh untuk diproses (kalo gak otomatis hapus misal dalam 2 jam)
Pak kalau datanya dari pihak ketiga gmn, misal data ongkir. Kan dari BE kita cuma lempar kode pos terus dpt resp biayanya. Nah di kitakan gk punya master datanya. Mohon penjelasannya pak 🙏
saya mencium adanya fail-validation, data ditampilkan ke client-side -> lalu user mengirim kembali data tersebut ke db. Dan saat diproses, yang diproses itu data usang (sebutan data yang sudah ditampilkan ke user). Misal saja, terkait masalah harga harusnya yang dikirim bukan data harganya tapi id/uuid dari produknya (jika harga ini dimiliki oleh sebuah data produk) lalu divalidasi ulang saat proses submit terjadi menggunakan id/uuid dari produk yang memiliki harga tersebut. Sebenarnya, cara ini sudah lama banget tapi ternyata masih banyak yang kena juga.
Menurut saya price dari FE tetap harus dikirim ke BE. Untuk apa? untuk referensi antara harga saat transaksi di FE dan BE. Jadi ketika price berbeda maka transaksi ditolak. Jangan sampai terjadi kasus seperti ini. Pada saat transaksi di FE price sebesar X namun ketika diproses di BE ternyata price sudah dinaikkan oleh admin sebesar Y. Hal ini akan menyebabkan komplain di user.
@@megasolusindo ga kebayang pas mencet checkout harganya 1 juta, eh pas di tengah-tengah proses di backendnya secara bersamaan terjadi update harga jadi 2.5 juta, auto saldo kepotong 2.5 juta pas lihat bammmmm!!! lah kok saldo aku kepotong 2.5 juta, anjirrr korupsi nih apk 🤣🤣🤣 bisa-bisa dituntut kasus penipuan 🤣🤣🤣🤣🤣🤣
12:24 saya biasanya pernah kena si id param di url nya di mainin wkwkwk jadi yg harus nya dia update user dia sendiri, eh malah user lain yang ke update
btw yang pake eko jelasin, mungkin lebih ke sistem backend yang memiliki master data yang dikirimkan client ada beberapa case, yg di hit memang ga punya master datanya beberapa case tersebut beberapa cara yang biasa digunakan : ada yang pakai header signature, dimana body request masuk dalam element dari signaturenya, klo ada yang ngerubah di jalan, signaturenya ga match ada yang di encrypt requestnya oleh client, di decrypt oleh server, dengan kunci asimetris antar server dan client ada yang ngirim uniqueRequestId oleh client, dan server ngehit api client untuk dapetin detail ordernya dll
Contohny : - Payment via google, beberapa flow ada encrypt decrypt antar request dan response, ada pertukaran asimetris key antar google dan penyedia jasa pembayaran digital - Standar Nasional Open Api (SNAP), penerapan signature, auth token, beberapa standar enkripsi sprti asimetris sha256 with rsa
Mau tanya bagaimana handle performance nya karena query bisa dibilang 2x fetching awal dan handle validasi, tapi emang security selalu berbanding terbalik dengan performance. Tapi best practicenya seperti apa supaya performance gak dikorbankan juga apalagi kalau data sudah sampai ribuan transaksi perdetiknya? Makasih
makasih pak sharingnya, pak gimana ya mengatasi request yang bersamaan, misal stok tinggal 1, lalu ada 2 client yang nge checkout secara bersamaan, itu gimana ya proses ngatasinya ?
ga mungkin bersamaan, di database ada fitur locking jadi pas 1 request ngedit data dalam hal ini stocknya maka request lain akan menunggu sampai request ini selesai edit data stock. dan ada jeda milidetik dan komputer bisa menangkap jeda milidetik itu jadi yang duluan checkout barangnya yang dapat, yang kalah cepat meski milidetik dapat respons barang udah habis
Cara tersebut efektif jika harga tidak memungkin kan nego, tapi jika memungkinkan harga berbeda dengan database maka harga transaksi memang perlu di insert di database orders_item, bagaimana jika dilakukan enkripsi pada field harga, apakah itu cukup aman ?
Kalau proses enkripsi dilakukan di FE keknya ya sama aja. Sepertinya si hacker tetep bisa encrypt price yang telah diubah lalu tinggal send/submit data ke BE.
Engga. Ini mah implementasi di BE-nya skill issue. Sebagai BE dev, ya harusnya jangan percaya mentah-mentah apa yang dikirimkan dari sisi client/FE. Implementasi BE yang bagus ya harus memvalidasi data yang dikirim dari FE. Terus juga harus filtering field/parameter mana aja yang dibutuhkan dari FE dan mana yang harusnya dari BE ataupun DB. Dan perlu diketahui, kalau app sudah deploy untuk publik, maka harus tahu bahwa user itu ada banyak macamnya dan dari kalangan mana aja. User app kita tidak melulu normies yang ga ngerti IT. Karena pada kenyataanya banyak orang iseng, orang jail, atau orang pure criminal aja di luar sana, termasuk yang biasa lagi mahir pakai dev tools, API Client (Postman, Insomnia, dsb), testing tools, dan yg lainnya. Sehingga mencegah dari sisi FE saja tidak akan memberikan jaminan keamanan yang lebih maksimal. Kalau emang mau lebih maksimal, ya proses keamanan juga harus dilakukan di BE. BE itu tugasnya bukan cuma sebagai pengantar data saja tapi juga validasi, mapping, dan pengamanan data. Kalau BE cuma dibuat sebagai pengantar/penyalur data dari DB ke FE, mending ga usah sekalian ada BE, langsung aja sekalian dari FE ke DB. Bocor data ya biar sekalian bocor dah semuanya 😅
Lebih ke arah "kebocoran informasi" gak sih? Kayak ID yg di expose sequence, bisa dimanipulasi juga pake tebak2 berhadiah. Setau saya best practice nya pake UUID atau ULID Dulu juga pernah ada 3rd party (gk terkenal), ada endpoint API dimana bisa update poin by token user 😂
OM, perbanyaakk video kek ginii dong om perluu bangett soalnyaa pengalaman darii senior gituu biar gaa ngulangin kesalahan yang samaa dann semogaa videoo yang impelemntasii project real bisaa cepet jadinyaaa aamiin, makasii om ilmunyaaa
noted
Setuju
setuju, masalah begini muncul dari pengalaman para expert, kita yang pemula kadang gk ngeh hal ini
Se7
@@ProgrammerZamanNow perbanyak bahas security diweb pak🙏🏻🙏🏻 saya was was jika bikin web payment gini bingung apa saja yang perlu diperhatikan😅🙏🏻
kecerobohan menaruh logic validasi ternyata masih saja terjadi. sudah beberapa kali saya lihat dan bahkan nemu sendiri kasus seperti ini, terakhir paling parah saya nemu di salah satu kampus negeri di indonesia, sistem akademiknya pakai validasi berdasarkan input di view. sehingga bisa dengan mudah dimanupulasi dengan html untuk mendaftar di suatu kelas. bahkan sessionnya tidak ada validasi kita bisa login ke akun lain hanya dengan mengubah cookie nomor induk mahasiswanya, bahkan kalau tega kita bisa hapus daftar kelas mahasiswa lain. bahkan mencuri data penting seperti foto formal, scan ktp, nama orang tua dan ijazah 😂 tapi syukurlah kampusnya sekarang sudah berbenah, sekarang kecerobohan itu sudah diperbaiki.
salah satu media besar saja ada kok, pernah beli course jurnalistik harga asli 1.5 jt jadi gratis wkwkwkw, gara2 param diskon
Itu dia kenapa pas bikin project kita wajib memposisikan diri sebagai org jahat sejahat2nya. Jangan bikin aplikasi asal jadi ga ada bug, harus mikir jg gmn cara kita bobol/exploit aplikasinya.
alhamdulillah dari umur 19 gue paham dan kerja di backend, sesimple kek gini gue ga pernah lalai. pernah temen gue yang frontend gue maki-maki karna validasi di frontendnya lalai, walaupun di backendnnya udah gue validasi, tapi ga ada salahnya buat double validation baik di frontend dan backend.
validasi itu lebih baik satu arah, semua ada di backend. kalo antara backend dan frontend nya kurang komunikasi, bisa jadi ada miss match antara yang dilakukan frontend dan backend. Bayangkan juga aplikasinya adalah multiplatform, ada mobile ada website. Kalo melakukan validasi di frontend memungkinkan validasi yang dilakukan antara mobile dan website beda.
so, ngga ada salahnya frontend ngga melakukan validasi, karena itu sudah jadi tanggung jawab dari backend.
catatan:
frontend boleh melakukan validasi untuk hal hal sepele saja, seperti required input, number input, email input. hal itu untuk meningkatkan UX agar tidak perlu melakukan submit dulu, menunggu dan menampilkan hasil error validasi.
CMIIW
masuk ni mas kalau bikin playlist troubleshoot dari case case yang pernah kejadian, nambah ilmu banget, terima kasi mas eko
Untuk price biasa saya tetap kirimkan dari client ke backend, walaupun dari backend tetap retrieve price dari master product lagi. Lalu buat apa price dari client? Biasanya untuk alert ke user jika tiba2 ada harga yg berubah di backend, apakah mau melanjutkan dengan harga yang baru. Web yg menjual item dgn volatilitas harga yg tinggi, misal emas, valuta, kripto, dll akan sangat perlu menerapkan hal semacam ini.
Alhamdulillah ternyata sudah mengimplementasikan cara yang benar dari awal. selalu ngindari kirim data yang ga penting ke backend dan bikin validasi ganda. gegara setiap buat fitur selalu penasaran buat ngulik 'kalo saya buat fitur gini misal saya iseng gimana ya" dan ngetest.
derita full stack
Intinya jangan percaya data dari front end guys,Soalnya gampang di manipulasi, Saya si biasanya lanngsung aja kirim id,sama quantitynya kebackend
Terus validasi dibackend,Dibackend tinggal select lagi aja ke database buat ambil pricenya
benar, senior ku bilang "tidak ada yang aman di frontend"
Kalau dari awal ngoding paham misahin mana front end mana backend, gk bakal kayak gini, tapi kan di indo banyak yg gelarnya "FULL STACK DEVELOPER PHP", rata rata kodingannya gini wkwk
@@indofiz1077Sebenernya bahasa apa bisa kena sih terutama ketika masih awam. Dulu saya awal awal belajar REST API langsung nyemplung NestJS FE nya NextJS juga banyak troubleshoot masalah seperti ini. Mulai dari AuthGuard sampe seperti yg ada di video. Setelah hampir 1 bulan punya pikiran "harus jadi secepat mungkin" dan cek Dev Tools ternyata banyak issue yang bisa di eksploitasi.
Perlahan-lahan nanti akan bertambah jam terbang dan kesalahan seperti ini bisa berkurang. Learn path dan kecepatan belajar orang tiap orang berbeda, tapi saya selalu setuju kalo di tahapan belajar sebaiknya JOMO bukannya FOMO terutama terkait payment seperti ini 👍🏻
Mantap pak, logic yang ada di video sama dengan yg saya lakukan pada project saat ini.
Akhirnya tahu soal case ini, mantap mas eko👍
makasih banyak pak eko atas pembahasannya. soalnya saya butuh bgt pembahasan ini karena banyak bgt isu web top up game dimanipulasi datanya. sukses terus buat pak eko
Alhamdulillah jadi paham baru banget buat web penjualan setelah belajar baru sadar bisa aj itu emang kesalahan logic kita, btw yang udah nanya makasih banyak lope u sekebon
Betul, kalaupun misal ada multiple price , diskon, dll yg memberikan perbedaan dari suatu price cukup dikirim id price, id diskon, dan id id yang lain.
Ilmu kelas❤
terima kasib pak eko.. 🙏
Untuk kasus terkait price tadi, bagaimana penanganan apabila ada perubahaan harga sesaat setelah produk dilihat oleh user? harga yang tertera pada kerangjang pasti berbeda dengan harga pada database
tinggal pakai harga yang didatabase, alias dianggap user telat ikut event diskon karena ikutnya mepet pas harga diskon mau balik ke harga normal
Selama belum proses payment, harga mengikuti harga terbaru 👍
Bisa dibiarkan dan pakai harga database, bisa juga dibikin validation error karena harga sudah berubah.
updateeee salahhhh jangan pakai data database, karena semisal harga awal 2 juta terus tiba2 naik jadi 5 juta terus diterusin prosesnya tanpa minta konfirmasi user dulu bisa-bisa diprotes user karena uangnya kepotong 5 juta bukan kehendaknya, paling parah kalau usernya ga terima bisa dituntut kasus penipuan. kirim response ke user bahwa harganya telah berubah menjadi sekian, apakah ingin lanjut atau batal? kalau user klik batal terus batalin prosesnya
@@nasimicinupdateeee salahhhh jangan pakai data database, karena semisal harga awal 2 juta terus tiba2 naik jadi 5 juta terus diterusin prosesnya tanpa minta konfirmasi user dulu bisa-bisa diprotes user karena uangnya kepotong 5 juta bukan kehendaknya, paling parah kalau usernya ga terima bisa dituntut kasus penipuan. kirim response ke user bahwa harganya telah berubah menjadi sekian, apakah ingin lanjut atau batal? kalau user klik batal terus batalin prosesnya
bener sih, mungkin temen2 bisa create table carts dan cart_items selain order dan order_items, dan ga perlu kirimin detail produk yang mau di order, cukup kirim id cart aja dan dia bisa proses dari situ. FYI si table carts dan cart_items ini datanya dihapus setelah masuk table orders, pastiin juga si carts ini dikasih expired yhh untuk diproses (kalo gak otomatis hapus misal dalam 2 jam)
Pak kalau datanya dari pihak ketiga gmn, misal data ongkir. Kan dari BE kita cuma lempar kode pos terus dpt resp biayanya. Nah di kitakan gk punya master datanya. Mohon penjelasannya pak 🙏
Makasih pak eko, ilmunya.
Sederhana dan mudah dimengertti
mantab, mudah2an bisa ketemu langsung sama pak eko
saya mencium adanya fail-validation, data ditampilkan ke client-side -> lalu user mengirim kembali data tersebut ke db. Dan saat diproses, yang diproses itu data usang (sebutan data yang sudah ditampilkan ke user). Misal saja, terkait masalah harga harusnya yang dikirim bukan data harganya tapi id/uuid dari produknya (jika harga ini dimiliki oleh sebuah data produk) lalu divalidasi ulang saat proses submit terjadi menggunakan id/uuid dari produk yang memiliki harga tersebut. Sebenarnya, cara ini sudah lama banget tapi ternyata masih banyak yang kena juga.
8:35 Bukan Security Issue tapi lebih ke Skill Issue pak 😂
sa ae
Padahal bang eko dah hati² dalam pemilihan katanya, dah diulti aja 😂
Menurut saya price dari FE tetap harus dikirim ke BE. Untuk apa? untuk referensi antara harga saat transaksi di FE dan BE. Jadi ketika price berbeda maka transaksi ditolak. Jangan sampai terjadi kasus seperti ini. Pada saat transaksi di FE price sebesar X namun ketika diproses di BE ternyata price sudah dinaikkan oleh admin sebesar Y. Hal ini akan menyebabkan komplain di user.
@@megasolusindo masuk akal
@@megasolusindo ga kebayang pas mencet checkout harganya 1 juta, eh pas di tengah-tengah proses di backendnya secara bersamaan terjadi update harga jadi 2.5 juta, auto saldo kepotong 2.5 juta pas lihat bammmmm!!! lah kok saldo aku kepotong 2.5 juta, anjirrr korupsi nih apk 🤣🤣🤣 bisa-bisa dituntut kasus penipuan 🤣🤣🤣🤣🤣🤣
Betul sih, berati emang salah logic aja di kasus ini karena tidak ada validasi tebaru
12:24 saya biasanya pernah kena si id param di url nya di mainin wkwkwk jadi yg harus nya dia update user dia sendiri, eh malah user lain yang ke update
Makanya gunakan validasi csrf token / current user session biar gak ketuker om..
btw yang pake eko jelasin, mungkin lebih ke sistem backend yang memiliki master data yang dikirimkan client
ada beberapa case, yg di hit memang ga punya master datanya
beberapa case tersebut beberapa cara yang biasa digunakan :
ada yang pakai header signature, dimana body request masuk dalam element dari signaturenya, klo ada yang ngerubah di jalan, signaturenya ga match
ada yang di encrypt requestnya oleh client, di decrypt oleh server, dengan kunci asimetris antar server dan client
ada yang ngirim uniqueRequestId oleh client, dan server ngehit api client untuk dapetin detail ordernya
dll
kurang aman
@@ryu-xd ampun, sungkem dulu sm suhu
Contohny :
- Payment via google, beberapa flow ada encrypt decrypt antar request dan response, ada pertukaran asimetris key antar google dan penyedia jasa pembayaran digital
- Standar Nasional Open Api (SNAP), penerapan signature, auth token, beberapa standar enkripsi sprti asimetris sha256 with rsa
@ ampun, sungkem sm suhu
saya kurang pengalaman hu, cuman baca dokumentasi integrasi dengan SNAP developer
@@nidhoggura 💩
dulu pas 2019-2020 pernah nemu bug seperti itu di web ikea yg dinamakan "parameter tampering" kalau di ranah security
masih gk expect sih zaman sekarang di backend gk ada validasi data, padahal library buat validasi udah berserakan di tiap bhs pemrograman
waduh, nah masalahnya saya pernah bikin api payment yang price nya memang bisa diedit langsung dari FE sama si kasir nya, itu gimana dong pa ?
dibuat aturan di BE berapa range harga yang boleh diubah oleh kasir.
@@megasolusindo nice thaks
Never trust user's input. Itu poinnya.
klo semisal harga diambil dari UID, lalu get dari model. scenario TS masih bisa terjadi kah ?
Mau tanya bagaimana handle performance nya karena query bisa dibilang 2x fetching awal dan handle validasi, tapi emang security selalu berbanding terbalik dengan performance. Tapi best practicenya seperti apa supaya performance gak dikorbankan juga apalagi kalau data sudah sampai ribuan transaksi perdetiknya? Makasih
09:32 berarti jadinya nge-query data 2x ya?
1x
@@novemberend4297 Bisa jelasin maksudnya gimana bisa 1x?
yaa kalau gak mau query 2 kali ke db, yaa saat dapet data di db, store data yang diperlukan ke Cache, nanti pas submit, ambil dari cache
ini mah emang udah ketara vulnerable nya, "never trust client" bukannya udah umum ?, biasanya cuma kirim id sama qty aja ke backend mah
pak mau nanya, itu pake aplikasi apa gambar diagramnya. 🙏🙏🙏🙏
excalidraw di web
makasih pak sharingnya, pak gimana ya mengatasi request yang bersamaan, misal stok tinggal 1, lalu ada 2 client yang nge checkout secara bersamaan, itu gimana ya proses ngatasinya ?
ga mungkin bersamaan, di database ada fitur locking jadi pas 1 request ngedit data dalam hal ini stocknya maka request lain akan menunggu sampai request ini selesai edit data stock. dan ada jeda milidetik dan komputer bisa menangkap jeda milidetik itu jadi yang duluan checkout barangnya yang dapat, yang kalah cepat meski milidetik dapat respons barang udah habis
Udh pernah dibahas tentang race condition
Kalo kasus FE nya kaya gini bisa di manipulasi apakah berlaku untuk mobile developer pak?
Cara tersebut efektif jika harga tidak memungkin kan nego, tapi jika memungkinkan harga berbeda dengan database maka harga transaksi memang perlu di insert di database orders_item, bagaimana jika dilakukan enkripsi pada field harga, apakah itu cukup aman ?
Kalau proses enkripsi dilakukan di FE keknya ya sama aja. Sepertinya si hacker tetep bisa encrypt price yang telah diubah lalu tinggal send/submit data ke BE.
@@masadamsahid Dengan enkripsi yg baru di padukan dengan key, dmn key nya diambil dari device id, atau imei, mungkin lebih sulit di dekrip
Kayak pernah denger, bug parameter tampering dimana request dimanipulasi atributnya
sering di eksploitasi sama hacker emang hal ini
Lanjutkan Pa, bahas keamanan
frontendnya skill issue itu mah pak masa user bisa manipulasi data gitu aja via dev tool🤔
Engga. Ini mah implementasi di BE-nya skill issue. Sebagai BE dev, ya harusnya jangan percaya mentah-mentah apa yang dikirimkan dari sisi client/FE. Implementasi BE yang bagus ya harus memvalidasi data yang dikirim dari FE. Terus juga harus filtering field/parameter mana aja yang dibutuhkan dari FE dan mana yang harusnya dari BE ataupun DB.
Dan perlu diketahui, kalau app sudah deploy untuk publik, maka harus tahu bahwa user itu ada banyak macamnya dan dari kalangan mana aja. User app kita tidak melulu normies yang ga ngerti IT. Karena pada kenyataanya banyak orang iseng, orang jail, atau orang pure criminal aja di luar sana, termasuk yang biasa lagi mahir pakai dev tools, API Client (Postman, Insomnia, dsb), testing tools, dan yg lainnya. Sehingga mencegah dari sisi FE saja tidak akan memberikan jaminan keamanan yang lebih maksimal. Kalau emang mau lebih maksimal, ya proses keamanan juga harus dilakukan di BE.
BE itu tugasnya bukan cuma sebagai pengantar data saja tapi juga validasi, mapping, dan pengamanan data. Kalau BE cuma dibuat sebagai pengantar/penyalur data dari DB ke FE, mending ga usah sekalian ada BE, langsung aja sekalian dari FE ke DB. Bocor data ya biar sekalian bocor dah semuanya 😅
mantap mas
baru tau ada yg input price dari depan
Pak tutor menghilangkan skill issue sebagai programmer
Lebih ke arah "kebocoran informasi" gak sih? Kayak ID yg di expose sequence, bisa dimanipulasi juga pake tebak2 berhadiah. Setau saya best practice nya pake UUID atau ULID
Dulu juga pernah ada 3rd party (gk terkenal), ada endpoint API dimana bisa update poin by token user 😂
PTEN SAM penting ga bang?
mantap
Masuk pak eko... Bisa belibet kalo sudah kacau datanya. Kita yang repot 😂😂😂😂
nahh, biasanya saya sering ngecoba pentest web web nya pake burpsuiteee buat mainin request nya
@@JokerakaMrDNM tutor saran nya dimana ya bang belajar pentest
salah satu alasan jangan asal jadi kalau bikin program
Mantap
guys ada yang tau ga buat coret coret kek diatas makai web apa?
excalidraw
@@InginBerSetiaHati thank u broo
Masih banyak yg katanya FULL stack php yang ngirim data ful gini wkwkwk, banyak gua ketemu
Dulu main ini di 2017, tapi gk tau kalau ini nyuri sih sebenernya.
Kerentanan idor ini bang.
saya langsung keinget website client 😅😅
burpsuite community edition, dulu dapet pas beli baju rucas wkwkwk
Hypermedia fixes this.
Seriusann dia bikin ecommerce tapi belom faham soal data tampering??? 😂
Jadi bayar pajak pak eko:V