Sekuriti atau keselamatan adalah satu proses, bukan satu tindakan. Keselamatan adalah hasil kerjasama daripada semua komuniti. Keselamatan juga melibatkan keseluruhan sistem dan perisian, bukan hanya terhad kepada Drupal "core" sahaja (atau modul tambahan). Mencari masalah mengenai keselamatan dan menyelesaikannya adalah perkara yang perlu dilakukan.

Kemasukan tidak divalidasi

Apabila seorang pengguna menghantar input atau data kemasukan ke laman, ianya perlu dilakukan validasi dan diperiksa.

#10 Kegagalan untuk menghalang akses URL

Kebiasaanya, satu-satu sistem akan cuba untuk menyembunyikan dan menghalang fungsi sensitif daripada dipaparkan menerusi pautan atau URL kepada pengguna tidak berhak. Pengondam boleh menggunakan kelemahan ini untuk memasuki ruangan terhad dan menjalankan arahan tidak sah menggunakan akses menerusi URL secara terus.

http:/kripkornstudios.com.my/ahli-berdaftar/parasolx

Bagaimana Drupal mengatasi kegagalan untuk menghalang akses URL

  • Drupal menggunakan sistem pengawalan akses melalui integrasi ke semua URLnya. Setiap akses kepada URL perlu dikonfigurasikan untuk membenarkan kemasukkannya walaupun tetapan telah dilakukan sebagai "allow everyone".
  • Setiap akses kepada menu dalam Drupal berkaitan dengan paparan akses kebenaran. Oleh itu, kemasukan secara terus URL tidak akan berlaku sekiranya akses kepada menu tersebut telah dimansuhkan.

#9 Komunikasi yang tidak selamat

Kebanyakan perisian gagal untuk melakukan nyahkod dalam setiap trafik rangkaian yang sepatutnya ianya dilakukan apabila melibatkan hal-hal komunikasi yang sensitif.

http:/kripkornstudios.com.my/ahli-berdaftar/parasolx

Bagaimana Drupal mengatasi komunikasi yang tidak selamat

  • Sebagai sistem yang dibangunkan dengan kod dasar PHP, Drupal mampu untuk menggunakan kelebihan Apache sepenuhnya menerusi sokongan SSL.
  • Selain itu, konfigurasi boleh dilakukan untuk hanya membenarkan sesetengah bahagian dalam keseluruhan laman dijalankan pada sokongan SSL, bagi membolehkan pihak pentadbir mengendali, memasang dan menguruskan modul-modul. Log masuk, e-commerce dan ruangan pentadbiran selalunya dijalankan pada pelantar SSL.

#8 Ketidakselamatan simpanan kriptografik

Aplikasi web selalunya terlupa untuk menyimpan data-data berbentuk privasi, peribadi dan penting ke dalam bentuk kriptografik. Pengondam akan menggunakan kesempatan ini untuk mendapatkan maklumat sulit seperti nombor kad kredit atau akaun mana-mana bank.

http:/kripkornstudios.com.my/ahli-berdaftar/parasolx

Bagaimana Drupal mengatasi ketidakselamatan simpanan kriptografik

  • Kata laluan disimpan menggunakan teknik satu hala "hashing". Walaupun pengondam berjaya untuk melihat atau memuat turun keseluruhan pangkalan data, proses untuk menterbalikkan "hashing" tersebut adalah terlalu sukar.
  • Drupal menghasilkan secara rawak kunci peribadi pada setiap kali pemasangannya. Modul-modul tambahan akan menggunakan kekunci ini untuk menyahkodkan dan mengekod semula menerusi penyulitan data-data yang sensitif contohnya nombor kad kredit.
  • Untuk modul perniagaan, Drupal mengekalkan retensi terhadap data-data sulit yang telah dinyahkod ini pada tahap yang paling minimum.

#7 Kegagalan pengesahan kemasukan

Maklumat dan token sesi untuk setiap pengesahan kemasukan akaun selalunya tidak dilindungi dengan sempurna. Pengondam dapat mencapai maklumat seperti kata laluan, kekunci atau token pengesahan dari pengguna lain dan menyamar sebagai pengguna yang sah.

http:/kripkornstudios.com.my/ahli-berdaftar/parasolx

Bagaimana Drupal mengatasi kegagalan pengesahan kemasukan

  • "Cookies" pengesahan Drupal tidak boleh diubahsuai oleh pihak pengguna. Ini bagi menghalang pengguna bertindak untuk mengambil alih dan menukarkan kebenaran ke satu tahap yang lebih tinggi.
  • Sesi (sessions) pengguna (termasuk "cookies") sepenuhnya dimusnahkan dan dibina semula sewaktu proses log masuk dan log keluar.
  • Nama pengguna, ID dan kata laluan hanya dikendali di bahagian pelayan (server sided) tidak di dalam "cookies". Kata laluan juga tidak pernah dihantar menerusi emel.
  • Sesi untuk setiap "cookies" dibina dan dinamakan secara unik untuk setiap pemasangan Drupal dan semuanya terhad pada bahagian domain sahaja -- menghalang proses intaian secara "cross-site".

#6 Kebocoran maklumat

Satu-satu aplikasi berpotensi untuk secara tidak sengaja mempamerkan maklumat seperti konfigurasi, proses dalaman atau informasi yang terlalu sulit apabila berlakunya paparan ralat dari mana-mana aspek aplikasi. Pengondam akan menggunakan informasi ini untuk mencuri maklumat sulit atau menjalankan serangan yang lebih tinggi.

http:/kripkornstudios.com.my/ahli-berdaftar/parasolx

Bagaimana Drupal mengatasi kebocoran maklumat

  • Pihak pentadbir berupaya untuk menentukan konfigurasi paparan ralat (termasuk ralat dari PHP) ditunjukkan secara tertutup, menghalangnya daripada dipaparkan terus kepada pengguna
  • Drupal TIDAK PERNAH sesekali memaparkan informasi berkaitan dengan kata laluan apabila menghadapi isu dan permasalahan berkaitan dengan sambungan pangkalan data
  • Drupal didatangkan dengan pakej .htaccess (konfigurasi untuk web Apache) yang menghalang pelbagai teknik mengintai maklumat menerusi penghantaran borang kemasukan (forms input)
  • Ianya TIDAK MUNGKIN untuk melihat kata laluan sebenar mana-mana pengguna

#5 Pemalsuan permintaan menerusi "cross-site"

Ia merupakan satu serangan yang dilakukan terhadap perisian pelayar pengguna (user's web browser) menerusi pemalsuan permintaan ketika proses pengesahan kemasukan ke laman yang tidak sah, yang kemudiannya memaksa mangsa memberikan segala kebenaran kepada penyerang untuk laman yang dituju. Serangan ini membolehkan penyerang menggunakan sepenuhnya aplikasi web tersebut.

Bagaimana Drupal mengatasi pemalsuan permintaan menerusi "cross-site"

  • Sekiranya satu-satu laman membolehkan pengguna untuk memuatkan segala isi kandungan luaran, serangan boleh dikesan dari tempat asalnya ia dilakukan. Dan yang penting ianya boleh dikonfigurasi menerusi Drupal.
  • Drupal menapis ke semua variasi skrip serangan dan melepaskan dalam bentuk ringkasan sahaja (permintaan GET)
  • Serangan dalam bentuk ini yang cuba dilakukan kepada Drupal akan terbatal kerana Form API memisahkan frasa operasi permintaan menerusi permintaan sembunyi POST
  • Form API juga memerlukan penghantaran permintaan borang perlu dibuka dan dibina terlebih dahulu yang menyebabkan serangan ini lebih sukar dilakukan.

#4 Ketidakselamatan rujukan objek secara terus

Masalah ini timbul apabila pihak pembangunan laman secara tidak sengaja mempamerkan rujukan kepada objek dalaman seperti fail, direktori, rekod pangkalan data atau kekunci yang digunakan sebagai pemboleh ubah dalam URL atau borang. Pengondam berupaya untuk memanipulasi data-data ini bagi mengakses maklumat yang memerlukan pengesahan.

Bagaimana Drupal mengatasi ketidakselamatan rujukan objek secara terus

  • Menu dan Form API Drupal menggalakkan validasi dan pengesahan penghantaran data daripada pengguna
  • Apabila satu-satu objek dirujuk menerusi From API, Drupal "core" akan melindungi nilai-nilai tersebut daripada diintai oleh pengguna
  • Drupal dan PHP menyediakan fail dan sesi API yang hanya membenarkan fail yang selamat dan sesuai sahaja dilakukan rujukan

#3 Pelaksanaan fail-fail berbahaya

Kod berbahaya yang dijalankan menerusi Remote File Inclusion (RFI) membolehkan pengondam untuk memasukkan kod dan data yang berlawanan, mengakibatkan serangan teruk seperti kelumpuhan pelayan secara total. Pelaksanaan fail-fail berbahaya akan memberi kesan kepada PHP, XML atau sebarang kerangka sistem yang mengendalikan fail-fail daripada pengguna.

Bagaimana Drupal mengatasi pelaksaan fail-fail berbahaya

  • PHP mempunyai konfigurasi untuk menentukan direktori asas untuk dihadkan. Menerusi pilihan ini akan menghadkan serangan yang dilakukan kepada direktori Drupal sahaja dan tidak keseluruhan struktur dalam pelayan
  • Modul dalam Drupal hanya membenarkan titik akses dilakukan menerusi URL/menu Drupal "core" sahaja. Jadi, seandainya penyerang berupaya untuk mengakses dan membuka arbitari fail PHP mana-mana fail, serangan ini akan dibatalkan.
  • Pembatalan serangan "#4 ketidakselamatan rujukan objek secara terus" juga dilakukan di sini.

#2 Suntikan kecacatan

Suntikan kecacatan selalunya dikenali sebagai suntikan SQL adalah masalah rutin untuk aplikasi web. Suntikan berlaku apabila pengguna memasukkan data yang dihantar dalam bentuk penterjemahan sebagai sebahagian arahan atau kueri. Serangan sebegini akan diinterpretasi ke bentuk arahan yang tidak dijangka atau perubahan data.

Bagaimana Drupal mengatasi suntikan kecacatan

  • Drupal menyediakan API pangkalan data yang terbina di dalamnya penghalang suntikan SQL. Secara teorinya, ianya adalah mustahil untuk menjalankan arbitary suntikan SQL
  • Drupal 7 mempunyai API pangkalan data yang menyukarkan penulisan kod pangkalan data yang tidak selamat
  • Drupal menyediakan set fungsi untuk memproses setiap pemboleh ubah URL dan SQL, yang menyebabkan keselamatan adalah pilihan utama bagi pihak pembangun

#1 Cross-site scripting

Suntikan XSS berlaku pada satu aplikasi yang menerima dan menghantar maklumat yang dimasukkan oleh pengguna tanpa melalui proses tapisan, validasi atau nyahkod kandungan tersebut. XSS membolehkan pengondam melancarkan pelbagai skrip berbahaya kepada pelayar pengguna yang seterusnya membolehkan perampasan terhadap sesi pengguna, kerosakan laman dan penanaman perisian berbahaya dilakukan.

Bagaimana Drupal mengatasi Cross-site scripting

  • Drupal mempunyai sistem untuk menapis setiap kemasukan dan membuang sebarang kod yang berpotensi sebagai XSS menerusi "Input filter".
  • Form API melakukan verifikasi supaya pengguna perlu membuka atau membina borang kemasukan terlebih dahulu sebelum dihantar. Proses verifikasi ini menyebabkan serangan XSS lebih sukar untuk dilakukan terhadap Drupal.
Penilaian: 
5
Your rating: None Average: 5 (3 votes)

Komen

yed's picture

para, nape notification email sampai 15?

------

signature? ape tu..

parasolx's picture
Admin

ade masalah dengan email sistem tadi.. dia sampai half, dia repeat balik..
sekrang dah ok dah..

------

Hadafi Solution & Resources: http://parasolx.net
Professional in Drupal web development, theme designing, consultation and training

juassehn9's picture

aku suke degan tajuk nih...pe pon x dak sisten yg scure 100%...aku x pernah lg building web pakai drupal...so x boleh nk comen lebih pasal scurity drupal..cume aku dh lame dh dok balajar pasal building website pakai drupal..agak komplicated skt..berbanding degan cms lain ex :wordpress...yg lebih mudah dan stabil dia punya scurity...bg aku building web pakai drupal lbh kurg dgn joomla jer..coz banyak pakai css...penig pala nk paham..2 bg aku lah pendapat seorg budak hingusan...tapi kalo abg admin mempunyai pendapat yg berbeza degan aku @ budak hingusan...boleh lah bg bimbingan kt aku tok terus belajar pakai drupal... nih website yg aku building pakai wordpress mungkin abg admin boleh komen skt tok bg pendapat atau mungkin nasihat kan aku tok terus building pakai drupal jer?.. http://www.ohlyric.com

parasolx's picture
Admin

mana-mana sistem pun boleh. Drupal kehebatannya dari segi fleksibelitinya. yang mana kita boleh buat apa sahaja yang kita mahu. berbeza dengan sistem lain yg kdg2 dia ada limitation. tp banyak setting yang kena buat dgn drupal untuk dapatkan hasil yang memuaskan.

jadi kalu lebih mengejar kepada masa, cuba guna sistem lain, mcm Wordpress yg mmg lebih mudah. tapi kalu ingin mencuba Drupal, boleh terus gunakan Drupal 7. lebih hebat dan senang digunakan.

------

Hadafi Solution & Resources: http://parasolx.net
Professional in Drupal web development, theme designing, consultation and training

suzie80's picture

tak pernah cuba lagi