alexa-tracking

Main Content

1024
1024
KASKUS
51
244
https://www.kaskus.co.id/thread/52e1e847c2cb17cc298b457c/sharing-web-defense
[SHARING] WEB DEFENSE
Sharing beberapa pendekatan yang TS gunakan untuk menyelesaikan masalah2 berkaitan dengan web secara umum dan REST pada khususnya.

* Front Controller (design pattern)
* Secure Login Mechanism
* Session Management
* User & Group Management
* Data Integrity
* Javascript Runtime (NOT LIBRARY)
* HTTPS/SSL

Prototype dan implementasi untuk semua topik pembahasan bisa didownload disini: [url]http://www.4*shared.com/file/sz7qC-9Dba/OSGiService_x86-13.html[/url]

Semoga trit ini bermanfaat dan cukup *rame* biar ada hiburan buat ngisi waktu luang emoticon-Smilie

--edit:
production ready

Front Controller (design pattern)

Design-pattern yang umum digunakan pada lingkungan web (mungkin yang terbaik untuk aplikasi berbasis web) adalah Front Controller. Wajar, karena tanpa single entry-poin, mustahil kita bisa meng-implementasi-kan pattern apapun pada rantai eksekusi request-response.

Yup, biar gak tersesat, kuncinya ada pada request-response. Kita tempatkan front controller pada bagian paling depan, kemudian chain-of-responsibility ditengah dan filter (atau bahkan coerce) tepat sebelum request kita dispatch, sesederhana itu emoticon-Big Grin

Contoh implementasi Front Controller (dengan chain-of-responsibility dan filter) menggunakan PHP5 bisa didownload disini: code.google.com/p/ufwk/source/browse/trunk/classes/Framework.php?spec=svn17&r=17

Dalam beberapa kasus, selama kita bisa menjamin thread-safety sebuah instance, Singleton (pattern) untuk handler bisa kita gunakan.

Sekian dulu, ntar update lagi emoticon-Cendol (S)
wkwkwk... daripada monolog, request tutup trit
wah menarik nih...ane baca" dlu gan....
Quote:Original Posted By badycool2
wah menarik nih...ane baca" dlu gan....


hihi, gak jd monolog kayaknya emoticon-Big Grin

silahkan bray

Secure Login Mechanism

OK, form login umumnya terdiri dari 3 elemen (username, password dan tombol). Jadi idenya (berdasarkan konfigurasi pengguna) adalah mengirim informasi penggunaan mouse pada saat focus pada elemen, klik kanan/kiri/tab, plus penggunaan enter sbg alternatif tombol submit.

Pada browser, info ini bisa didapat dari binding event click/contextmenu/focus, dengan preventDefault + stopPropagation untuk mencegah trigger dan bubble pada listener pihak ketiga (gak tau kl keylogger msh bisa ketrigger). Event-order disini penting.

Sampai disini, selain info 3 elemen, kita sudah punya 5 info tambahan, kl dipermutasikan, kombinasinya kan lumayan tuh?! emoticon-Big Grin

Karena SSL hanya terjadi dilevel socket, tetap sj dilevel entry-poin vulnerable, mau pake SSL 1024 bit pun kl kena keylogger hasilnya sama sj, maka one-time-password (via response-challenge) bisa menjadi alternative (murah meriah) dr device-token. Proses harus dilakukan secara sinkron tepat sebelum form bisa digunakan dan sebelum data dikirim.

Tanpa SSL, yang menarik sebenarnya bukan pada bisa/tidak data dilihat ditengah jalan, justru pada mampu/tidak aplikasi melindungi data dari tampering ditengah jalan.

Mungkin perlu ditambahkan bahwa regenerate cookie (untuk identifikasi session) tidak hanya dilakukan pada saat login berhasil tapi secara random pada saat browser melakukan full-request.
Ijin nyimak gan,,
btw ada pnjelasan versi nubie nya ga? emoticon-Malu
Quote:Original Posted By unknown24
Ijin nyimak gan,,
btw ada pnjelasan versi nubie nya ga? emoticon-Malu


Sorry, silahkan disampaikan dibagian mana yang agan masih kurang jelas emoticon-Smilie

Mengenai login, poin-nya bukan pada informasi/data (krn kl ini, user bisa saja langsung copas password pd elemen) tapi pada event yang kita tangkap.

Mengenai one-time-password, jelas model otentikasi digest lebih aman dari palin/text (dengan SSL sekalipun). Kl agan lihat prosesnya, pasti lebih mudah.

Untuk referensi, agan bisa lihat proses validasi digest menggunakan PHP: http://www.php.net/manual/en/feature....http-auth.php

Hanya sj, krn digest kurang user-friendly, jarang digunakan emoticon-Frown

Penjelasan lebih detail step-by-step untuk implementasi berbasis web, bisa agan baca pada file README.CHM (pada link download prototype).

off dl, ntar update lg.
Quote:Original Posted By wilaheng
OK, form login umumnya terdiri dari 3 elemen (username, password dan tombol). Jadi idenya (berdasarkan konfigurasi pengguna) adalah mengirim informasi penggunaan mouse pada saat focus pada elemen, klik kanan/kiri/tab, plus penggunaan enter sbg alternatif tombol submit.

Pada browser, info ini bisa didapat dari binding event click/contextmenu/focus, dengan preventDefault + stopPropagation untuk mencegah trigger dan bubble pada listener pihak ketiga (gak tau kl keylogger msh bisa ketrigger). Event-order disini penting.

Sampai disini, selain info 3 elemen, kita sudah punya 5 info tambahan, kl dipermutasikan, kombinasinya kan lumayan tuh?! emoticon-Big Grin

Karena SSL hanya terjadi dilevel socket, tetap sj dilevel entry-poin vulnerable, mau pake SSL 1024 bit pun kl kena keylogger hasilnya sama sj, maka one-time-password (via response-challenge) bisa menjadi alternative (murah meriah) dr device-token. Proses harus dilakukan secara sinkron tepat sebelum form bisa digunakan dan sebelum data dikirim.

Tanpa SSL, yang menarik sebenarnya bukan pada bisa/tidak data dilihat ditengah jalan, justru pada mampu/tidak aplikasi melindungi data dari tampering ditengah jalan.

Mungkin perlu ditambahkan bahwa regenerate cookie (untuk identifikasi session) tidak hanya dilakukan pada saat login berhasil tapi secara random pada saat browser melakukan full-request.



nice gann.....
Izin nyimak sekalian ninggalin jejak emoticon-Toast

Session Management

Session adalah titik paling kuat (sekaligus paling rapuh) dalam bertahan.

Setidaknya ada dua hal yang krusial dalam menejemen session. Pertama proteksi cookie, kedua entropy (random generator).

Untuk yang pertama, HttpOnly pada cookie adalah satu-satunya pilihan (plus Domain jika dibutuhkan).

Untuk yang kedua, high-entropy adalah pilihan bagus (java.security.SecureRandom misalnya). Penjelasan mengenai keharusan menggunakan high-entropy cukup panjang.

Agar semakin menarik, revalidate key-value pair cookie pada saat full-request adalah pilihan bijaksana.

Quote:Original Posted By badycool2

nice gann.....


thanks bray

Quote:Original Posted By hdcoder
Izin nyimak sekalian ninggalin jejak emoticon-Toast


silahkan bray emoticon-Toast

User & Group Management

Btw, ngomong2 masalah cookie sebelumnya, flag SECURE pada cookie bukanlah security boundary, kecuali kita memang ingin semuanya dilakukan melalui SSL. Tapi kl dipikir2 mungkin lebih kl mengunakan keduanya?! (correct me). Prototype terakhir menggunakan SSL hanya untuk transaksi yang sifatnya krusial seperti login dan config. Silahkan dicoba emoticon-Big Grin

Ok, kembali ke masalah user, gabungan antara RBAC (untuk resources secara keseluruhan) dan ACL untuk CRUD adalah deadly-combination.

Proses sebaiknya masuk pada Chain-of-responsibility (design-pattern) tepat sebelum sebuah resource/handler dipanggil agar tidak menjadi beban bagi developer.

emoticon-Toast

Data Integrity

Topik berat sebenarnya emoticon-Smilie

Dalam HTTP, integritas data adalah hal krusial, mengingat data harus ditransmisikan terlebih dahulu sebelum bisa diproses.

Dengan menggunakan tools seperti firebug, pengguna bisa dengan mudah melakukan modifikasi. Belum lagi kl data bisa dimanipulasi (atau dilihat) ditengah jalan.

Pernah terjadi pd aplikasi SIMAK sebuah univ swasta (di Bandung), karena konfigurasi wifi memungkinkan data (login) dilihat ditengah jalan, ada pengguna yang bisa masuk sebagai admin. Hanya dengan menambahkan checksum (CRC) pada saat login, masalah bisa diselesaikan, sesederhana itu, kebetulan TS diminta solusi oleh temen utk kasus itu emoticon-Big Grin

Menangani integritas data menjadi agak rumit untuk kebutuhan transaksi. Prioritas utama tetap ada pada sisi server (backend).

Jadi idenya adalah melakukan coerce (karena filter adalah metode kuno), konversi tipe data sesuai kebutuhan handler. Ingat, semua data yang diterima tidak boleh langsung digunakan kecuali telah melalui proses coerce.

Chain-of-responsibility (design-pattern) mungkin pilihan terbaik dalam hal ini.

selamat tidur kaskuser emoticon-Toast
Bisa bikin resume / article nya file pdf ga gan??
biar bisa baca2 emoticon-Request
nitip materi 3 factor authentication gan emoticon-Malu (S)
IJin menyimak mastah..
Lebih sip lagi kalo sekalian dijelasin gimana implementasinya emoticon-Angkat Beer

SQL

Kalo buat nangkis SQLi pake metode apa ya gan? emoticon-Bingung (S)
Quote:Original Posted By dayakdayak
Bisa bikin resume / article nya file pdf ga gan??
biar bisa baca2 emoticon-Request


sorry gan, kayaknya ga ada waktu buat bikin emoticon-Big Grin

Quote:Original Posted By pekoy154
nitip materi 3 factor authentication gan emoticon-Malu (S)


emoticon-Hammer gak kuat om, bank sj masih 2 factor, 3 factor kl mo masuk ke brankasnya kayak di pilem2 emoticon-Big Grin

Quote:Original Posted By omdjinmesem
IJin menyimak mastah..
Lebih sip lagi kalo sekalian dijelasin gimana implementasinya emoticon-Angkat Beer


ane pernah bikin impl pake PHP5
code.google.com/p/ufwk/source/browse/trunk/classes/Framework.php?spec=svn17&r=17

utk versi java gak open-source gan (sorry)

emoticon-Angkat Beer

Quote:Original Posted By rafi.rp
Kalo buat nangkis SQLi pake metode apa ya gan? emoticon-Bingung (S)


metode untuk memastikan tipe data mkn berguna.

Javascript Runtime

Browser (seperti mobile device) adalah lingkungan dengan sumber-daya terbatas. Untuk membuat aplikasi berbasis web yang responsive, TS sangat menyarankan untuk tidak menggunakan library.

Percayalah, JS adalah bahasa script yang paling mudah, selain fleksibel juga karena terbatas pada manipulasi DOM. Yup, harus memahami DOM, paling tidak sampe level 3.

Jadi idenya adalah membuat runtime, bukan fungsi2 yang ditulis untuk menyelesaikan satu kasus, tapi implementasi pattern untuk menyelesaikan semua kasus spesifik pada browser. Declarative (design-pattern) mungkin pilihan terbaik dalam hal ini (mengingat fungsi browser me-render dokumen HTML). Dengan ini kita tidak perlu lagi menulis fungsi2 tambahan pada setiap form. nice huh?!

Melihat cara kerja browser, setidaknya ada dua entry-poin yang bisa digunakan. Pertama pada saat dokumen diload, kedua pada saat manipulasi DOM atau pembuatan fragment.

Entry-poin ini kita gunakan sebagai routine-procedure untuk setiap elemen yang dibuat pada saat program berjalan. Factory (design-pattern) mungkin pilihan yang terbaik.

Untuk contohnya, akan TS cari ide yang mudah, besok dilanjut lagi emoticon-Big Grin
wah ijin baca-baca dulu gan emoticon-Jempol