Machine Translated by Google

The 10th International Conference for Internet Technology and Secured Transactions (ICITST-2015)

Analisis Keefektifan Black-Box Web

Pemindai Aplikasi dalam Deteksi SQL Tersimpan
Injeksi dan Kerentanan XSS Tersimpan
Muhammad Parvez1 , Pavol Zavarsky1 , Nidal Khoury2
1
Manajemen Keamanan Sistem Informasi
Concordia University of Edmonton, Edmonton, Alberta, Kanada
2
IBM Kanada, Toronto, Ontario, Kanada
parvezshahar@gmail.com, pavol.zavarsky@concordia.ab.ca, nkhoury@ca.ibm.com

Abstrak–Stored SQL injection (SQLI) dan Stored Cross Site
Scripting (XSS) adalah kerentanan aplikasi web paling kritis saat
ini. Penelitian sebelumnya telah menunjukkan bahwa pemindai
kotak hitam memiliki kinerja yang relatif buruk dalam mendeteksi
kedua kerentanan ini. Dalam makalah ini, kami menganalisis
kinerja dan kemampuan deteksi pemindai keamanan aplikasi web
kotak hitam terbaru terhadap SQLI tersimpan dan XSS tersimpan.
Analisis kami menunjukkan bahwa pemindai terbaru menunjukkan
peningkatan kinerja dalam mendeteksi SQLI tersimpan dan XSS
tersimpan. Kami mengembangkan test-bed khusus kami untuk
menantang kemampuan pemindai untuk mendeteksi SQLI yang
disimpan dan XSS yang disimpan. Analisis kami mengungkapkan
bahwa pemindai kotak hitam masih memerlukan peningkatan
dalam mendeteksi SQLI tersimpan dan kerentanan XSS tersimpan.
Selain hasil uji kinerja, makalah ini memberikan serangkaian
rekomendasi yang dapat meningkatkan kinerja pemindai dalam
mendeteksi SQLI tersimpan dan kerentanan XSS tersimpan.
Penelitian terbaru mengungkapkan bahwa pemindai kotak hitam berkinerja
relatif buruk dalam mendeteksi SQLI yang tersimpan dan kerentanan XSS yang
tersimpan [2,3,5,8]. Bau et al.[3] dan Doupe et al.[5] menyelidiki pemindai
keamanan aplikasi web kotak hitam sehubungan dengan pendeteksian SQLI
yang disimpan dan XSS yang disimpan. Bagian berikut memberikan wawasan
baru tentang kemampuan deteksi. Khoury et al.[8] melakukan analisis lanjutan
tentang keefektifan pemindai kotak hitam dalam mendeteksi SQLI yang
disimpan. Alassami et al. [2] melakukan penelitian serupa tetapi untuk kerentanan
XSS yang tersimpan. Makalah ini melaporkan temuan kami dari tes ulangan
yang awalnya dilakukan oleh Khoury et al.[8] dan Alassami et al.[2].
Tujuan keseluruhan dari makalah ini adalah sebagai berikut:
Saya. Untuk mengukur kinerja pemindai kotak hitam canggih dalam mendeteksi
kerentanan SQLI yang disimpan dan XSS yang disimpan.

Kata kunci-–Skripsi Lintas Situs tersimpan; injeksi SQL tersimpan;
kerentanan XSS; pemindai kotak hitam
I. PENDAHULUAN
Stored SQL Injection (SQLI) dan stored Cross-Site Scripting (XSS) adalah
kerentanan aplikasi web yang paling kritis. Jenis serangan SQLI tersimpan
melibatkan dua langkah untuk menyelesaikan serangan. Pada langkah pertama,
perintah SQL disimpan di back-end storage atau database. Pada langkah
selanjutnya, perintah SQL yang tersimpan dijalankan [8].
Injeksi XSS Tersimpan adalah bentuk serangan yang memungkinkan
pengguna jahat melewati aturan dan kebijakan aplikasi web yang ditentukan.
Serangan semacam ini berupa menyuntikkan kode berbahaya ke dalam
database yang digunakan oleh aplikasi web.
Setelah aplikasi web mengambil data dari penyimpanan untuk ditampilkan di
browser pengguna, kode jahat dijalankan oleh browser web.
ii. Untuk mempelajari alasan keterbatasan yang ada dari pemindai keamanan
aplikasi web kotak hitam dalam mendeteksi SQLI tersimpan dan
kerentanan XSS tersimpan.
aku aku aku. Untuk menyajikan beberapa rekomendasi tentang cara mendeteksi
tingkat dapat ditingkatkan.
II. PEKERJAAN TERKAIT
Kinerja pemindai kotak hitam telah menjadi perhatian untuk sementara
waktu. Khoury et al.[8] dan Alassami et al.[2] melakukan penelitian tentang SQLI
tersimpan dan XSS tersimpan. Tiga pemindai dievaluasi dalam [2] untuk
mendeteksi XSS yang disimpan. Hasil di [2] mendemonstrasikan bahwa
pemindai berhasil menyimpan skrip di database test-bed, tetapi gagal mendeteksi
kerentanan XSS yang tersimpan. Delapan pemindai digunakan dalam [8] dengan
tingkat deteksi yang dilaporkan untuk SQLI tersimpan sebesar 0% dan 15%
untuk XSS tersimpan.
Hasil serupa dilaporkan dalam [5] dengan menguji sebelas
scanner.

Untuk mengidentifikasi kerentanan aplikasi web yang ada termasuk SQLI
yang disimpan dan XSS yang disimpan, berbagai teknik digunakan untuk
meminimalkan kemungkinan serangan yang berhasil terhadap aplikasi web.
Pemindaian kerentanan web kotak hitam adalah salah satu teknik yang telah
diadopsi secara luas karena kemudahan penggunaan, otomatisasi, dan
kemandirian dari teknologi aplikasi web yang mendasarinya.
Penulis di [8] dan [2] melakukan analisis yang diperluas untuk SQLI yang
disimpan dan XSS yang disimpan dibandingkan dengan temuan eksperimental
di [3] dan [5]. Seiring dengan tes lainnya, dalam tes penilaian kinerja kami, kami
mereplikasi tes Khoury et al. [8] dan Alassami dkk. [2] dengan menggunakan
pemindai Black-Box yang canggih. Di test-bed kami, kami telah menyertakan
profil login untuk kerentanan XSS yang tersimpan dan mengujinya
Machine Translated by Google
The 10th International Conference for Internet Technology and Secured Transactions (ICITST-2015)
kinerja scanner melalui itu. Jason Bau et al [3] menulis, "Memang, beberapa
vendor menegaskan kesulitan mereka dalam merancang tes yang mendeteksi
kerentanan orde kedua". Dalam mendeteksi kerentanan urutan kedua
(tersimpan), banyak faktor yang harus dipertimbangkan untuk menentukan
validitas input.
AKU AKU AKU. CONTOH XSS TERSIMPAN
Untuk mengilustrasikan berbagai tahapan serangan XSS yang disimpan,
kami mempertimbangkan skenario mengeksploitasi kerentanan yang ada di
WackoPicko [9]. Ada kerentanan XSS yang tersimpan di halaman komentar
gambar. Bidang komentar tidak dibersihkan dengan benar, dan oleh karena
itu, penyerang dapat mengeksploitasi kerentanan XSS yang tersimpan ini
dengan langkah-langkah berikut:
Masuk dan kunjungi halaman yang berisi gambar;
Memilih gambar untuk dikomentari;
Ketikkan kode Java Script berbahaya di kolom komentar dan kirimkan
untuk pratinjau; dan Mengonfirmasi
komentar yang akan dikirimkan.
Saat halaman gambar dimuat, bagian komentar juga dimuat dan
serangan dijalankan. Penyerang dapat menggunakan Java Script jahat apa
pun di kolom komentar untuk disimpan di database untuk mencuri sesi atau
cookie pengguna.
IV. CONTOH SQLI TERSIMPAN
Tahapan berbeda dari SQLI yang disimpan dapat dijelaskan dengan skenario
mengeksploitasi kerentanan yang ada di WackoPicko. Di WackoPicko,
pengguna dapat melakukan pendaftaran di bawah /user/registration.php
dengan mengisi dan mengirimkan formulir. Dalam formulir pendaftaran ini,
bidang nama depan adalah bidang teks input yang tidak dibersihkan. Saat
mendaftar untuk pengguna, penyerang dapat menyimpan 'atau 1 = 1 atau "';
DROP TABLE pengguna;#" di basis data backend.
Ada halaman “similar.php” di WackoPicko di mana pengguna dapat mencari
pengguna lain dengan nama depan yang mirip. Otentikasi diperlukan untuk
mengunjungi halaman “similar.php” ini . Saat pengguna mengunjungi
"similar.php", kueri akan dipicu atas nama pengguna yang masuk dan kueri
tersebut menggunakan nama depan pengguna yang masuk sebagai
parameter kueri. Di bawah ini adalah kode kueri tersemat yang digunakan di
halaman “similar.php” dari aplikasi WackoPicko.
$query = "PILIH * dari `users` di mana `nama depan` seperti '%{$login}
%' dan nama depan != '{$login}'"; Setelah kueri di
atas dijalankan, variabel $login diganti dengan nama depan pengguna.
Jika kita menerapkan kode SQL penyerang 'atau 1 = 1' ke kueri di atas,
menjadi:
PILIH * dari `pengguna` di mana `nama depan` seperti '%' atau 1=1%'
dan nama depan != '' atau 1 = 1'; Kueri yang
dihasilkan mengembalikan semua baris dari tabel pengguna karena
memiliki pernyataan 'atau 1=1' yang selalu benar.
Alih-alih kode serangan 'atau 1 = 1', kode serangan SQL lain yang lebih
merusak dapat digunakan.
V. METODOLOGI PENGUJIAN
Untuk melakukan eksperimen kami, kami memilih tiga pemindai kotak
hitam dengan kemampuan yang diklaim untuk mendeteksi XSS yang tersimpan
dan menyimpan kerentanan SQLI. Pemindai yang digunakan dalam uji kinerja
kami tercantum dalam Tabel I.
TABEL I. DAFTAR PEMINDAI KOTAK HITAM YANG DIGUNAKAN DALAM PENGUJIAN
Pemindai Penjual Versi: kapan
Acunetix WVS [1] Acunetix 8.0
Perusahaan AppScan Rasional [7] IBM 9.0
ZAP [10] OWASP 2.3.1
Pemindai Black-Box memiliki profil pemindaian prasetel. Profil pemindaian
dapat digunakan untuk menentukan kategori kerentanan mana yang akan
ditargetkan selama pemindaian. Fase pemindaian yang dilakukan oleh
pemindai yang tercantum dalam Tabel 1 telah diverifikasi sama seperti yang
dijelaskan dalam [5] dan [8].
Performa dalam mendeteksi SQLI tersimpan dan XSS tersimpan dari
setiap pemindai dianalisis dalam dua test-bed: (i) WackoPicko [5] dan (ii)
Scan-bed buatan kami sendiri. Kedua tempat uji dirancang untuk menantang
berbagai fitur dan fungsi pemindai kotak hitam dan menghadirkan tingkat
kerumitan yang berbeda. Tabel II dan Tabel III menunjukkan jumlah
kerentanan SQLI dan XSS yang disimpan di setiap test-bed bersama dengan
jumlah kerentanan yang memerlukan login pengguna agar berhasil
dieksploitasi. Untuk mengeksploitasi kerentanan SQLI yang tersimpan di
WackoPicko [9], pemindai harus menjalankan beberapa langkah. Langkah-
langkahnya adalah pemindai harus (1) mendaftarkan akun pengguna, (2)
mengirimkan kode serangan yang valid di bidang nama depan untuk disimpan
basis data saat mendaftarkan pengguna, dan (3) masuk menggunakan akun
pengguna ini dan (4) lakukan post scan untuk mengeksploitasi dan (5)
mendeteksi kerentanan.
TABEL II. Kerentanan SQLI TERSIMPAN DI TEST-BED
Test-bed Stored SQLI Login diperlukan Tidak perlu login
WackoPicko 1 1 0
Tempat tidur pindai 1 0 1
TABEL III. KERENTANAN XSS TERSIMPAN DI TEST-BED
Tempat tidur percobaan
XSS Tersimpan Login diperlukan Tidak perlu login
WackoPicko 21 1
Pindai tempat tidur 11 0
Di WackoPicko, satu kerentanan XSS yang tersimpan ada di bagian
komentar semua gambar. Untuk mengeksploitasi dan mendeteksi kerentanan,
pemindai harus maju melalui serangkaian langkah yang rumit. Pemindai (1)
harus membuat akun pengguna dan login dengan kredensial pengguna, (2)
harus mengunjungi halaman "recent.php" untuk memilih gambar (3) harus
menempatkan kode JavaScript berbahaya di kolom komentar dan
mengirimkannya untuk pratinjau; (4) konfirmasi komentar; (5) melakukan
pemindaian pos untuk mengeksploitasi dan (6) mendeteksi kerentanan.
“Guestbook.php” memiliki kerentanan XSS tersimpan lainnya, meskipun
pemindai tidak perlu masuk untuk mendeteksi kerentanan ini. Eksploitasi dan
deteksi kerentanan XSS yang tersimpan di halaman “Buku Tamu.php”
memerlukan langkah-langkah berikut yang dilakukan oleh pemindai:
- Kunjungi halaman “Buku Tamu.php” ;
Machine Translated by Google
The 10th International Conference for Internet Technology and Secured Transactions (ICITST-2015)
- Untuk setiap profil pemindaian, kami melakukan dua pengujian: (1)
Suntikkan skrip yang salah format di kolom komentar dan
kirimkan untuk disimpan di database; dan -
Kunjungi kembali halaman dan analisis respons untuk mengonfirmasi
bahwa skrip yang disuntikkan berhasil dijalankan.
Build kustom "Scan-bed" berisi satu XSS tersimpan dan satu
kerentanan SQLI tersimpan. Halaman bernama "exploit.php" berisi dua
bidang teks bernama "subjek" dan "komentar" dengan bidang teks
komentar tidak dibersihkan. Jadi, penyerang dapat mengeksploitasi
serangan XSS yang tersimpan menggunakan kolom komentar. Halaman
"exploit.php" membutuhkan otentikasi untuk dikunjungi.
Pemindai dapat membuat pengguna melalui halaman “register.php” dan
kemudian mengunjungi halaman “exploit.php” untuk mengidentifikasi dan
mengeksploitasi kerentanan. Ini memungkinkan pengujian kinerja pemindai
dalam mendeteksi kerentanan XSS yang tersimpan pada halaman yang
memerlukan autentikasi.
Kami merancang kerentanan SQLI yang tersimpan di tempat tidur
pengujian Scan-bed kami. Halaman bernama "information.php"
memungkinkan tamu tanpa hak istimewa untuk mengirimkan info nama
depan, nama belakang, jenis kelamin, dan usia mereka. Bidang nama
belakang adalah bidang teks input yang tidak bersih. Saat mendaftarkan
informasi sebagai pengguna, penyerang dapat menyimpan kode serangan
seperti ' atau 1 = 1 atau "'; DROP TABLE pengguna;#" melalui bidang
nama belakang di database backend. Ada halaman lain bernama Kerentanan XSS yang disimpan dan SQLI yang disimpan di
WackoPicko
"names.php" di mana pengguna dapat mencari pengguna lain dengan nama belakang
yang sama.
Saat ada tamu yang mengunjungi “names.php”, halaman ini memicu kueri
atas nama tamu tersebut, dan kueri tersebut menggunakan nama
belakang pengguna tersebut sebagai parameter kueri. Test-bed
WackoPicko memiliki jenis kerentanan SQLI tersimpan yang serupa.
Untuk mengeksploitasi atau mendeteksi kerentanan di WackoPicko,
pemindai harus menyelesaikan pendaftaran pengguna. Skenario yang
disederhanakan dalam test-bed kami memungkinkan analisis kinerja
pemindai dalam mendeteksi kerentanan SQLI yang tersimpan pada
halaman dengan tidak memerlukan pemindai untuk melakukan tugas
rumit seperti pendaftaran atau autentikasi pengguna, yang dapat
mencegah pemindai mendeteksi kerentanan SQLI yang tersimpan.
A. Profil pemindaian aplikasi web kotak hitam
Untuk tujuan pengujian, kami menggunakan tiga profil pemindaian.
(i) Profil pemindaian lengkap yang menargetkan semua jenis kerentanan,
(ii) Profil pemindaian SQL menargetkan semua jenis kerentanan injeksi
SQL, dan (iii) profil pemindaian XSS yang menargetkan semua jenis
kerentanan XSS.
TABEL IV. LANGKAH UJI
1. Konfigurasikan aplikasi web ke status awalnya 2.
Atur database ke status default 3.
Konfigurasikan pemindai untuk menggunakan profil
Persiapan
tertentu dengan kredensial
masuk sesuai kebutuhan 4. Konfigurasikan Burp
suite untuk memantau lalu lintas antara pemindai dan server web
5. Mulai merekam lalu lintas 6. Awal
Mulai pemindai kotak hitam
7. Hentikan Burp Suite dan hemat lalu
lintas 8. Simpan hasil Pengumpulan data
pemindaian 9. Ekspor entri basis data untuk
analisis 10. Periksa laporan
pemindai 11. Analisis file Burp Suite dan catatan basis Analisis
data 12. Ulangi langkah sebelumnya untuk pengujian baru
pengujian tanpa memberikan kredensial login apa pun ke pemindai, dan
(2) pengujian dengan memberikan kredensial login. Kami melakukan
semua tes dengan mengikuti langkah-langkah yang dirangkum dalam Tabel IV.
Langkah pengujian ini diadaptasi dari penelitian Khoury et al. [8]. Kami
menangkap semua lalu lintas jaringan dari pengujian yang menargetkan
server web menggunakan Burp Suite [4]. Kami menganalisis semua lalu
lintas untuk mengidentifikasi vektor serangan yang digunakan oleh
pemindai. Balasan server juga dianalisis untuk menentukan apakah
pemindai menginterpretasikan balasan secara efisien atau tidak.
VI. HASIL DAN PEMBAHASAN
Hasil dan temuan disusun dalam empat subbagian sebagai berikut:
(A) kinerja pemindai kotak hitam tanpa autentikasi; (B) kinerja pemindai
kotak hitam dengan autentikasi; (C) temuan dengan test-bed khusus;
dan (D) solusi khusus, seperti bantuan interaktif untuk pemindai untuk
mendeteksi dan menjelajahi kerentanan.
A. Performa pemindai kotak hitam tanpa kredensial login
diuraikan dalam Bagian III dan Bagian IV.
Pemindai kotak hitam tidak memerlukan autentikasi untuk mendeteksi
kerentanan XSS yang tersimpan di “guestbook.php” WackoPicko.
Untuk mendeteksi XSS yang disimpan di bagian komentar gambar,
pemindai harus masuk sebagai pengguna. Selain itu, login diperlukan
oleh pemindai untuk mendeteksi kerentanan SQLI yang tersimpan di
“similar.php”.
Ketiga pemindai mampu mendeteksi XSS yang tersimpan di
“guestbook.php” saat menguji dengan profil lengkap dan profil XSS.
Semua pemindai mampu menyelesaikan ketiga fase pemindaian.
Pemindai merayapi halaman “guestbook.php” dan dengan benar
mengidentifikasi bidang input untuk komentar, menyuntikkan vektor
serangan yang tepat seperti skrip yang salah format melalui bidang input
untuk disimpan di backend dan menganalisis respons dari server dengan
cara yang benar untuk mendeteksi kerentanan XSS yang disimpan . Ini
bertentangan dengan temuan yang dilaporkan di [2] bahwa pemindai
berhasil mengidentifikasi bidang input, menyuntikkan vektor serangan
berbahaya dan menyimpannya di database backend tetapi tidak dapat
menganalisis respons kembali dari server secara efisien, yang [2]
mengakibatkan kegagalan untuk mendeteksi kerentanan XSS yang
tersimpan. Uji kinerja kami mengonfirmasi bahwa versi pemindai saat ini
mampu menganalisis respons server dan mendeteksi kerentanan XSS
yang tersimpan dari halaman rentan yang tidak memerlukan autentikasi
masuk.
Setelah menganalisis hasil pengujian Pemindai 1, lalu lintas yang
dihasilkan, dan menggunakan vektor serangan, kami mengamati dua
vektor serangan atau skrip java peringatan digunakan oleh Pemindai 1
untuk mendeteksi kerentanan XSS yang tersimpan dari “guestbook.php” .
Salah satu skrip peringatan tersebut berisi teks seperti 666. Ini dapat
diuraikan sebagai berikut. Saat pemindai mengunjungi "guestbook.php",
pemindai menyisipkan skrip alert(666) untuk disimpan dalam database,
dan saat mengunjungi kembali halaman dan menganalisis respons,
pemindai menemukan skrip alert(666) dalam respons, yang merupakan
skrip dimasukkan pada kunjungan pertama. Pemindai melaporkan ini
sebagai kerentanan XSS yang tersimpan.
Machine Translated by Google
The 10th International Conference for Internet Technology and Secured Transactions (ICITST-2015)
Gambar 1 menunjukkan jumlah pengguna yang dibuat oleh setiap
pemindai menggunakan profil lengkap dan berapa banyak akun pengguna
yang benar-benar digunakan untuk memindai halaman individual di mana ada
kerentanan. Seperti yang ditunjukkan pada gambar, pemindai yang diuji
mampu membuat pengguna menggunakan halaman “registration.php” .
Analisis paket dan lalu lintas untuk "registration.php" yang ditangkap oleh
Burp Suite [4] menegaskan bahwa sebagian besar pemindai waktu
memberikan input yang sama untuk bidang kata sandi dan lagi kata sandi
saat membuat pengguna. Pengujian kami memastikan bahwa pemindai
terbaru efisien dalam menciptakan pengguna, yang tidak terjadi pada
penelitian sebelumnya [8] dan [5] ketika setengah dari pemindai dari tidak
dapat membuat pengguna.
Gambar 1. Statistik aktivitas pemindai dengan total pengguna terdaftar untuk profil lengkap tanpa
kredensial login
Scanner 1 mendaftarkan tujuh pengguna dan dari tujuh pengguna
tersebut, hanya satu pengguna yang digunakan untuk mengunjungi halaman
“similar.php” sekali saja. Pemindai 1 berhasil merayapi "login.php",
menyuntikkan satu vektor serangan SQLI yang tersimpan melalui kolom input
nama depan di basis data backend saat mendaftarkan pengguna baru.
Kemudian, Pemindai 1 masuk dengan akun pengguna tersebut, merayapi
halaman “similar.php” dan mengeksekusi vektor serangan SQLI yang
tersimpan dari database. Analisis lalu lintas respons dari "similar.php"
mengungkapkan bahwa Pemindai 1 menerima pengecualian kesalahan
sintaks SQL tetapi tidak mengonfirmasi adanya kerentanan injeksi SQL. Fase
analisis respons server Pemindai 1 tidak efisien. Pemindai 1 berhasil
menyelesaikan serangan tetapi karena keterbatasan fase analisis server, ia
tidak dapat mendeteksi kerentanan SQLI yang tersimpan. Setelah memindai
test-bed yang sama dengan profil SQL, pemindai mendeteksi satu serangan
SQLI di halaman "login.php" berdasarkan pesan kesalahan yang sama
sebagai respons dari server web. Hal ini menjadi perhatian terkait kinerja
Scanner 1.
Seperti dijelaskan di atas, mirip dengan serangan XSS tersimpan yang
ada di halaman buku tamu, komentar pada gambar rentan terhadap serangan
XSS tersimpan. Namun, kerentanan ini lebih sulit untuk dieksploitasi karena
pemindai harus masuk untuk memilih gambar, mengirimkan skrip berbahaya
sebagai komentar untuk disimpan dalam basis data yang didukung, dan untuk
mengonfirmasi pratinjau komentar sebelum serangan benar-benar dipicu. Di
[2], semua pemindai yang digunakan gagal mendeteksi kerentanan XSS yang
disimpan multi-langkah karena pemindai kurang memahami interaksi antara
halaman "previewcomment.php" dan "comments.php" . Dalam pengujian
kami, kami mengalami peningkatan kinerja Pemindai 1
dan Pemindai 2 saat kredensial masuk disediakan oleh kami secara manual
untuk tujuan pengujian. Namun, tanpa memberikan kredensial masuk secara
manual, di antara ketiga pemindai, Pemindai 2 hanya merayapi
“previewcomment.php”. Pemindai 2 menggunakan akun pengguna terdaftar
untuk merayapi halaman ini. Saat menganalisis data yang dikumpulkan, kami
melihat bahwa sejumlah besar komentar, termasuk kode serangan XSS,
dikirimkan untuk pratinjau oleh Pemindai 2. Pemindai 2 tidak menyadari
bahwa pengiriman tersebut hanyalah pengalihan ke halaman untuk
mengonfirmasi komentar yang dimasukkan.
Akibatnya, tidak ada satu komentar pun yang dimasukkan oleh Scanner 2
melalui “previewcomment.php”.
Pemindai 1 hanya menggunakan satu akun untuk merayapi satu tautan
yang dilindungi "similar.php" sekali dan tidak ada akun yang digunakan untuk
merayapi halaman yang dilindungi seperti "previewcomment.php". Pemindai
2 tidak menggunakan akun apa pun untuk merayapi “similar.php”. Performa
Pemindai 3 sangat buruk terkait penggunaan akun terdaftar untuk tujuan
perayapan. Meskipun ketiga pemindai dapat membuat akun pengguna,
pemindai tidak menggunakan akun tersebut dengan cara yang akurat dan
efisien untuk masuk dan merayapi tautan yang dilindungi. Ini secara signifikan
memengaruhi hasil pemindaian. Selain membuat pengguna, pemindai harus
mengingat kredensial masuk dan menggunakan kredensial tersebut dengan
cara yang akurat untuk merayapi semua tautan pelindung masuk.
Setelah menyelesaikan pemindaian dengan profil lengkap, profil XSS
dan SQL tanpa kredensial masuk yang kami berikan digunakan secara
terpisah oleh ketiga pemindai untuk memindai. Tabel V dan VI masing-masing
menunjukkan hasil untuk profil XSS dan SQL. Satu fakta nyata untuk Scanner
2, antara profil lengkap dan profil XSS, hanya 9 pengguna di antara 127
pengguna yang dibuat mengunjungi halaman “previewcomment.php”
menggunakan profil lengkap, sedangkan 31 pengguna di antara 33 pengguna
yang dibuat mengunjungi halaman menggunakan profil XSS.
Namun, dalam kedua kasus tersebut, tidak ada satu komentar pun yang
dikonfirmasi melalui “previewcomment.php”. Tabel VI menunjukkan bahwa
menggunakan profil SQL, Pemindai 2 dan 3 masing-masing membuat 22 dan
3 pengguna, tetapi tidak ada pengguna yang merayapi halaman "similar.php" .
TABEL V. AKTIVITAS SCANNER DENGAN USER TERDAFTAR MENGGUNAKAN
PROFIL XSS TANPA LOGIN CREDENTIALS
Jumlah pengguna Jumlah pengguna yang digunakan dalam
Pemindai
terdaftar perayapan "Previewcomment.php"
Pemindai 1 1 0
Pemindai 2 33 31
Pemindai 3 2 0
TABEL VI. AKTIVITAS PEMINDAI DENGAN PENGGUNA TERDAFTAR MENGGUNAKAN
PROFIL SQL TANPA KREDENSIAL LOGIN
Jumlah Jumlah pengguna yang digunakan untuk
Pemindai
pengguna terdaftar merayapi "similar.php"
Pemindai 1 0 0
Pemindai 2 22 0
Pemindai 3 3 0
B. Kinerja pemindai kotak hitam dengan kredensial login
Meskipun kredensial masuk pengguna kami berikan kepada ketiga
pemindai sebelum pemindaian, pemindai juga mendaftarkan pengguna saat
memindai WackoPicko. Meskipun Pemindai 1 mendaftarkan 133 pengguna
dengan sendirinya, hanya pengguna yang disediakan secara manual oleh
kami yang digunakan untuk merayapi halaman perlindungan masuk. tidak seperti
Machine Translated by Google
The 10th International Conference for Internet Technology and Secured Transactions (ICITST-2015)

kinerja dari bagian sebelumnya, kali ini, dengan kredensial masuk yang kami TABEL VII. AKTIVITAS PEMINDAI DALAM DETEKSI SQLI TERSIMPAN
sediakan menggunakan profil lengkap dan profil XSS, Pemindai 1 berhasil Lalu lintas Lalu lintas Menyerang
Memindai
Pemindai
mengonfirmasi komentar melalui halaman "previewcomment.php" . Semua komentar profil toko Menjalankan Kode

berhasil dikonfirmasi dan disimpan di backend oleh Scanner 1 berisi teks 'abcd'. Penuh 734 229 0
Pemindai 1
Menariknya, menggunakan profil lengkap, Scanner 2 tidak mengonfirmasi komentar 216 76 0
SQL
apa pun melalui "previewcomment.php" tetapi dapat memberikan komentar melalui Penuh 657 321 0
Pemindai 2
profil XSS. Menggunakan profil XSS, Scanner 2 menggunakan 30 pengguna untuk SQL 124 58 0
mengirimkan komentar untuk pratinjau. Sejumlah besar komentar dikirimkan untuk Penuh 224 47 0
Pemindai 3
pratinjau oleh semua pengguna ini dan hanya satu pengguna yang berhasil SQL 67 23 0

mengonfirmasi satu komentar melalui halaman "previewcomment.php" . Menariknya,

single user ini dibuat oleh Scanner 2 sendiri. Di sini, kami mengamati profil XSS Pemindai 2 menunjukkan kinerja yang baik dalam mendeteksi XSS yang disimpan
berperforma lebih baik daripada profil lengkap. Sebagai komentar, Scanner 2 di tempat tidur Pindai. Ketiga pemindai mendaftarkan pengguna (seperti yang
menyimpan “1” yang bukan merupakan vektor serangan XSS. disajikan pada Tabel VIII), tetapi hanya delapan pengguna dengan pemindai 2 yang
digunakan untuk merayapi "comment.php" di mana terdapat kerentanan XSS yang tersimpan.
Setelah melakukan analisis lalu lintas dengan pemindai, kami mengonfirmasi bahwa
pemindai 2 dapat menyelesaikan ketiga fase pemindaian. Mereka merayapi halaman,
Pemindai 3 tidak menggunakan kredensial masuk yang disediakan untuk merayapi
menyuntikkan jumlah vektor serangan yang tepat dan nyaman, serta menganalisis
"previewcomment.php". Pemindai 1 dan 2 tidak mengirimkan vektor serangan XSS
respons server untuk mendeteksi XSS yang disimpan.
sebagai komentar yang dapat mengeksploitasi kerentanan. Jika Pemindai 1 dan 2
telah menggunakan skrip serangan XSS alih-alih teks default, mereka akan berhasil
mengeksploitasi XSS yang disimpan dan melaporkannya sebagai kerentanan XSS TABEL VIII. AKTIVITAS SCANNER DALAM DETEKSI XSS TERSIMPAN
yang tersimpan. Pemindai harus ditingkatkan untuk memicu vektor serangan yang
Pemindai Memindai Total Pengguna Tidak: pengguna Disimpan
tepat dalam situasi seperti ini untuk mengeksploitasi dan mendeteksi kerentanan yang XSS
profil terdaftar
yang tersimpan. merayapi “exploit.php” terdeteksi

Pemindai 1 Penuh 0 TIDAK

XSS 5 0 TIDAK
Analisis data lalu lintas mengungkapkan bahwa tidak ada pemindai
Pemindai 2 Penuh 0 Ya
mengunjungi “similar.php” dengan kredensial login yang kami sediakan.
XSS 121 32 8 29 Ya

Dari tiga pemindai, hanya Pemindai 1 yang menggunakan kredensial masuk Pemindai 3 Penuh 6 0 TIDAK

yang disediakan untuk merayapi halaman yang dilindungi "previewcomment.php" .
Kami dapat menyimpulkan bahwa pemindai tidak menggunakan kredensial masuk
yang disediakan secara efisien yang secara signifikan memengaruhi kinerja pemindai.
Pemindai perlu menggunakan kredensial login yang disediakan secara lebih efektif
untuk merayapi tidak hanya sedikit tetapi semua halaman aplikasi web yang dilindungi
login.
C. Temuan dengan "Scan-bed" yang dikembangkan secara khusus
XSS 3 0 TIDAK
D. Solusi khusus
Kami melakukan serangkaian eksperimen tambahan dengan WackoPicko dan
Scan-bed. Kami menggunakan solusi berikut, menggunakan "profil lengkap", untuk
membantu pemindai memilih vektor serangan yang tepat dan mengunjungi halaman
di mana terdapat kerentanan untuk mengeksploitasi dan mendeteksi kerentanan.

Di test-bed “Scan-bed”, kami menyertakan satu SQLI tersimpan dan satu
kerentanan XSS tersimpan. Seperti yang dibahas di Bagian V, login tidak diperlukan
untuk mengeksploitasi SQLI yang disimpan, berlawanan dengan kerentanan XSS
yang disimpan yang memerlukan autentikasi.
Untuk setiap pengujian dengan pemindai, kami memantau lalu lintas jaringan
perayapan untuk “information.php” untuk merekam vektor serangan. Lalu lintas
dilambangkan pada Tabel VII sebagai "Traffic disimpan". Demikian pula, lalu lintas
jaringan untuk "names.php" untuk mengeksekusi vektor serangan yang disimpan
dilambangkan sebagai "Traffic execution". Jumlah vektor serangan yang relevan dan
berbeda yang disimpan dalam database untuk bidang yang rentan terhadap SQLI
yang disimpan juga ditunjukkan pada Tabel VII.
1. Solusi ini dilakukan di WackoPicko. Kami mengonfigurasi Pemindai 2 untuk
mendaftarkan pengguna yang berisi kode serangan di bidang nama depan . Kami
memaksa pengguna untuk mengunjungi halaman “similar.php” yang akan
mengeksekusi kode serangan dari bidang nama depan . Pemindai berhasil
menyelesaikan fase serangan. Analisis lalu lintas mengungkapkan bahwa pemindai
menerima pengecualian kesalahan sintaks SQL sebagai respons dari server.
Berdasarkan pengecualian kesalahan sintaks SQL ini, Pemindai 2 melaporkan
kerentanan injeksi SQL. Hasil serupa dilaporkan di [8]. Namun, sementara di [8]
pemindai tidak melaporkan injeksi SQL apa pun untuk pengecualian kesalahan
sintaks SQL karena fase analisis respons server dari siklus pemindai, hasil pengujian
kami menunjukkan peningkatan fungsi pemindai terkait analisis respons server.

Tidak ada pemindai yang dapat mendeteksi kerentanan SQLI yang tersimpan
setelah memindai halaman "information.php" dan "names.php".
Kami melakukan tes yang sama juga dengan Scan-bed kami. Di halaman
Pemindai tidak menyimpan kode serangan yang nyaman (lihat Tabel VII) untuk
"information.php" , kami memasukkan vektor serangan yang sama di bidang nama
kerentanan SQLI yang disimpan. Jumlah lalu lintas yang cukup digunakan untuk belakang dan memaksa pemindai untuk memindai "names.php". Sebagai tanggapan,
menggunakan dan mengeksekusi vektor serangan, tetapi vektor serangan yang
pemindai menerima kesalahan Sintaks SQL yang sama tetapi, yang mengejutkan,
disimpan dalam database terutama digunakan untuk mengeksploitasi dan mendeteksi
kali ini pemindai tidak melaporkannya sebagai kerentanan SQLI. Kami memeriksa
kerentanan SQLI yang buta, tercermin, atau normal. Pemindai perlu ditingkatkan
kode sumber WackoPicko dan Scan-bed dan menemukan bahwa karena
untuk memuat vektor serangan yang sesuai untuk mendeteksi kerentanan SQLI yang menggunakan fungsi kesalahan mysql yang sama di bagian pengkodean, server
tersimpan.
menjadi
Machine Translated by Google
The 10th International Conference for Internet Technology and Secured Transactions (ICITST-2015)
menghasilkan kesalahan sintaks SQL yang sama sebagai respons.
Ambiguitas untuk kesalahan yang sama di dua test-bed yang berbeda
menimbulkan pertanyaan tentang kinerja pemindai.
2) Dalam solusi lain, kami mengonfigurasi browser kami untuk
menggunakan Scanner 3 sebagai proxy dan mulai menjelajahi
WackoPicko. Karena kami menggunakan Pemindai 3 sebagai proksi,
setiap permintaan dan respons saat menjelajah WackoPicko akan melalui
Pemindai 3 dan setiap kerentanan yang ditemui akan dilaporkan oleh
pemindai. Kami mengunjungi halaman “registration.php” dan membuat
pengguna yang berisi kode serangan yang sama dengan yang kami
gunakan dalam solusi sebelumnya. Setelah itu, kami mengunjungi
halaman yang akan mengeksekusi kode serangan. Menanggapi yang
satu itu, pengecualian kesalahan sintaks SQL ditampilkan di halaman itu.
Ini adalah kesalahan yang sama yang dihasilkan sebagai respons dalam
penyelesaian masalah sebelumnya. Namun, alih-alih melaporkan sebagai
kerentanan SQLI apa pun, Pemindai 3 melaporkannya sebagai pesan
kesalahan aplikasi dengan tingkat keparahan sedang. Kontradiksi dalam
hasil ini menimbulkan beberapa pertanyaan tentang kinerja dan integritas
hasil pemindai.
3) Di bagian VI A dan VI B, wawasan diberikan tentang mengapa
semua pemindai dengan dan tanpa kredensial login yang disediakan
gagal mendeteksi kerentanan XSS yang disimpan dalam beberapa
langkah di WackoPicko. Dalam solusi ini, kami membuat akun pengguna
terlebih dahulu. Kami mengonfigurasi Pemindai 1 untuk menggunakan
akun pengguna ini untuk proses login. Kami menginstruksikan pemindai
cara memasukkan kode serangan XSS berbahaya di bagian komentar
gambar bersama dengan cara mengonfirmasi pengiriman komentar
melalui halaman "previewcomment.php" . Pemindai 1 berhasil
menyelesaikan ketiga fase pemindaian dan mendeteksi kerentanan XSS
yang tersimpan. Kami dapat menyimpulkan bahwa bantuan tersebut
dapat membantu pemindai untuk mendeteksi XSS yang tersimpan.
VII. REKOMENDASI
A) Peningkatan diperlukan dalam fungsionalitas pemindai untuk
menggunakan vektor serangan XSS dengan cara yang lebih efisien
dalam mendeteksi kerentanan XSS yang tersimpan. Dalam pengujian
kami (Lihat bagian VIB), menggunakan "profil lengkap" dan "profil XSS"
untuk memindai WackoPicko, Pemindai 1 dan 2 berhasil mengonfirmasi
komentar melalui halaman "previewcomment.php" . Semua komentar
yang berhasil dikonfirmasi oleh Pemindai 1 dan 2 berisi teks normal.
Namun, pemindai tidak mengirimkan vektor serangan XSS apa pun yang
dapat mengeksploitasi kerentanan. Jika pemindai menggunakan skrip
serangan XSS alih-alih teks default, pemindai akan mengeksploitasi XSS
yang disimpan dan melaporkannya sebagai kerentanan XSS yang
tersimpan. Pemindai perlu ditingkatkan untuk menggunakan vektor
serangan yang tepat dalam situasi yang tepat.
B) Peningkatan diperlukan dalam fungsionalitas pemindai untuk
menganalisis respons server dengan cara yang lebih efisien untuk
melaporkan kerentanan injeksi SQL. Dalam pengujian kami (lihat Bagian
VIA), untuk pesan pengecualian kesalahan sintaks SQL yang serupa
sebagai respons server, Pemindai 1 berperilaku berbeda dalam profil
pemindaian yang berbeda. Saat memindai WackoPicko melalui "profil
lengkap", untuk pesan pengecualian kesalahan sintaks SQL sebagai
respons server untuk halaman "similar.php" , Pemindai 1 tidak melaporkan
kerentanan injeksi SQL apa pun. Setelah memindai test-bed yang sama
dengan profil SQL, Scanner 1 melaporkan satu kerentanan SQLI di
halaman "login.php" berdasarkan respons pesan kesalahan dari
server web. Ini juga menimbulkan kekhawatiran terkait kinerja pemindai
untuk menganalisis respons server.
C) Menambahkan opsi multilangkah interaktif untuk memindai. Dari
ketiga scanner tersebut, hanya satu scanner yang memiliki fitur tersebut.
Meskipun opsi untuk menyetel kredensial login membantu menyediakan
info login aplikasi untuk pemindaian, opsi ini tidak menginstruksikan
pemindai cara mengunjungi halaman dan di mana menempatkan vektor
serangan untuk dieksploitasi dan untuk mendeteksi kerentanan.
D) Pemindai perlu ditingkatkan untuk memuat kode serangan yang
efektif untuk mendeteksi kerentanan SQLI yang tersimpan.
E) Menggunakan kredensial masuk membantu pemindai bekerja
dengan cara yang lebih efisien. Kami dapat memverifikasi bahwa tanpa
memberikan kredensial masuk, pemindai dapat mendaftarkan akun
pengguna, tetapi dari pengguna terdaftar hanya sedikit yang benar-benar
digunakan untuk mengunjungi halaman yang memerlukan otentikasi.
VIII. KESIMPULAN
Dalam makalah ini, kinerja tiga pemindai kotak hitam di dua alas uji
dalam mendeteksi SQLI yang disimpan dan XSS yang disimpan dinilai.
Dibandingkan dengan laporan sebelumnya oleh peneliti lain, hasil kami
menunjukkan bahwa kinerja pemindai kotak hitam untuk mendeteksi XSS
yang disimpan baru-baru ini meningkat dan pemindai mampu memberikan
tingkat deteksi yang lebih tinggi untuk kerentanan XSS yang disimpan.
Namun, kami dapat mengonfirmasi bahwa fungsionalitas pemindai perlu
ditingkatkan untuk menganalisis respons server dengan benar pada
kesalahan sintaksis SQL dan untuk mendeteksi respons server sebagai
kerentanan injeksi SQL. Temuan eksperimental kami mengonfirmasi
bahwa memilih vektor serangan yang tepat untuk deteksi dan eksploitasi
XSS yang disimpan dan SQLI yang disimpan tetap menjadi tantangan
besar bagi kotak hitam
scanner.
REFERENSI
[1] Akunetix Pemindai Kerentanan. [On line]. Tersedia
https://www.acunetix.com/vulnerability-scanner/. 12 Oktober 2014.
[2] S. Alassmi, P. Zavarsky, “Analisis Keefektifan Pemindai Aplikasi Web Black-Box dalam
Deteksi XSSI Tersimpan”, 2011.
[3] J. Bau, E. Bursztein, D. Gupta, J. Mitchell, “Tercanggih: Pengujian Kerentanan Aplikasi
Web Kotak Hitam Otomatis”, 2010..
[4] Burp Suite, Tersedia https://portswigger.net/burp/ [5] A. Doup
´e, M. Cova, G. Vigna, “Mengapa Johnny Tidak Bisa Pentest: Analisis Pemindai Kerentanan
Web Blackbox” , 2010.
[6] Y. Huang, C. Tsai,, T. Lin, S. Huang, S. Kuo, “Kerangka pengujian untuk penilaian
keamanan aplikasi Web”, 2010.
[7] Pemindai Aplikasi Rasional IBM. [On line]. Tersedia http://www 03.ibm.com/software/
products/en/appscan/. 15 Oktober 2014.
[8] N. Khoury, P. Zavarsky, D. Lindskog, R. Ruhl, "Analisis Pemindai Keamanan Aplikasi
Web Kotak Hitam terhadap SQLI Tersimpan" Proc.
IEEE 3rd Int. Konf. Privasi, Keamanan, Risiko dan Kepercayaan, Boston, 2011.
On line. Tersedia
[9] Aplikasi WackoPicko TestBed.
https://github.com/adamdoupe/WackoPicko. Diakses: Nov.29, 2014].
[10] Pemindai Zed Attack Proxy (ZAP). On line. Tersedia
https://github.com/zaproxy/zaproxy. 19 Oktober 2014.
[11] T. Zhang, H. Chen, J. Sun, “Metode Berbasis Aliran Eksekusi untuk
Mendeteksi Pembuatan Skrip Lintas Situs”, 2010.