pengembangan web vulnerability assessment tool …

1

PENGEMBANGAN WEB VULNERABILITY ASSESSMENT TOOL PENDETEKSI SQL INJECTION BERBASIS OWASP CODE REVIEW

Fransiska Dyah Ayu Oktaviani1, Muhammad Salman.2

1. Departemen Teknik Elektro, Fakultas Teknik, Universitas Indonesia, Depok, 16424, Indonesia 2. Departemen Teknik Elektro, Fakultas Teknik, Universitas Indonesia, Depok, 16424, Indonesia

1. E-mail: [email protected]

2. Email: [email protected]

Abstrak

Seiring dengan semakin berkembangnya banyaknya aplikasi khususnya aplikasi berbasis website, semakin banyak pula serangan yang dapat mengancam aplikasi yang telah dibuat. Salah satu serangan yang paling sering dilakukan adalah SQL Injection. Sehingga pada skripsi ini akan membahas mengenai penerapan tool pendeteksi SQL Injection berbasis website dengan mengacu pada OWASP Code Review. Pengujian dilakukan dengan membandingkan file berisi kode html atau php dengan parameter yang telah ditentukan. Berdasarkan OWASP Code Review, terdapat parameter-parameter yang digunakan dalam pengujian ini yakni penggunaan hashing, ekstensi basis data, sanitasi dan validasi data, serta prepared statements. Hasil dari penelitian menunjukkan bahwa tool berupa website yang dibuat dapat menguji file yang diunggah secara akurat.

Kata Kunci: SQL Injection, OWASP Code Review

Development of Web Vulnerability Assessment Tool to Detect SQL Injection Based on OWASP Code Review

Abstract

Along with the growing of applications, especially website based application, there are also more attacks that can threaten applications that have been made. One of the most common attacks is SQL Injection. Therefor, this thesis will discuss about implementation and development of SQL Injection detection tool based on OWASP Code Review. Testing is done by comparing file containing html and php code with parameters that have been determined. Based on OWASP Code Review, parameters used in this test are the use of hashing, database extension, data sanitation and validation, as well as prepared statements. The result of this research indicate that the tool created can test uploaded file accurately. Keywords: SQL Injection, OWASP Code Review

1. Pendahuluan

1.1 Latar Belakang

Pada zaman ini, pertumbuhan internet terjadi dengan sangat pesat. Saat ini, hampir

semua kegiatan sehari-hari yang biasa dilakukan oleh manusia ditunjang oleh internet. Salah

satu hal yang menandai hal ini adalah munculnya beragam aplikasi website yang ada di

Pengembangan Web ..., Fransiska Dyah Ayu Oktaviani, FT UI, 2017

2

internet. Aplikasi website ini dapat digunakan sebagai sarana edukasi, hiburan, bisnis, dll.

Sehingga dengan banyaknya sarana penerapan aplikasi webiste ini, membuat orang-orang

mulai tertarik untuk mendalami cara mengembangkan aplikasi website itu sendiri. Terdapat

banyak tutorial yang bisa dipelajari untuk mengembangkan aplikasi website. Namun, seiring

dengan semakin berkembangnya penerapan aplikasi website, semakin berkembang pula

serangan-serangan yang dapat mengancam aplikasi website tertentu.

Open Web Application Security Project (OWASP) adalah salah satu organisasi yang

peduli terhadap keamanan aplikasi website. OWASP mempunyai proyek bernama “OWASP

Top Ten Project” dengan tujuan untuk menerbitkan sepuluh daftar resiko keamanan teratas

yang paling berbahaya untuk aplikasi website. Proyek “OWASP Top Ten Project” dirilis

pada tahun 2004[1], 2007[2], 2010[3] dan 2013[4]. Detail daftarnya dapat dilihat pada Tabel

1.1.

Dapat dilihat pada Tabel 1.1, bahwa pada tahun 2013, serangan yang mempunyai resiko

terbesar adalah Injection. Dapat diamati pula, semakin tahun resiko Injection pada aplikasi

website semakin meningkat. Salah satu jenis Injection adalah SQL Injection. SQL Injection

akan memasukkan SQL query melalui data masukan dari klien ke aplikasi. Tujuan dari SQL

Injection adalah membaca data, memodifikasi basis data, mengeksekusi operasi

administrator, dll[5]. Hal ini sangat berbahaya karena basis data yang telah dibuat dapat

diakses oleh pihak lain yang tidak sah.

Sehingga diperlukan suatu aplikasi untuk menguji apakah aplikasi website yang dibuat rentan terhadap SQL Injection atau tidak, khususnya bagi developer pemula.

Tabel 1. Daftar Sepuluh Resiko Keamanan Aplikasi Website Teratas Versi OWASP

No 2004 2007 2010 2013

A1 Unvalidated

Input

Cross-Site

Scripting (XSS)

Injection Injection

A2 Broken Access

Control

Injection Flaws Cross-Site Scripting

(XSS)

Broken

Authentication and

Session

Management

A3 Broken

Authentication

And Session

Management

Malicious File

Execution

Broken

Authentication and

Session

Management

Cross-Site Scripting

(XSS)

A4 Cross-Site

Scripting (Xss)

Flaws

Insecure Direct

Object Refrence

Insecure Direct

Object references

Insecure Direct

Object references


3

A5 Buffer Overflows Cross Site Request

Forgery (CSRF)

Cross-Site Request

Forgery (CSRF)

Security

Misconfiguration

A6 Injection Flaws Information

Leakage and

Improper Error

Handling

Security

Misconfiguration

Sensitive Data

Exposure

A7 Improper Error

Handling

Broken

Authentication and

Session

Management

Insecure

Cryptographic

Storage

Missing Function

Level Access

Control

A8 Insecure Storage Insecure

Cryptographic

Storage

Failure to Restrict

URL Access

Cross-Site Request

Forgery (CSRF)

A9 Denial Of Service Insecure

Communications

Insufficient

Transport Layer

Protection

Using Known

Variable

Components

A10 Insecure

Configuratin

Management

Failure to Restrict

URL Access

Unvalidated

Redirects and

Forwards

Unvalidated

Redirects and

Forwards

1.2 Tujuan Penelitian

Tujuan dari penelitian ini adalah:

1. Mengetahui metode SQL Injection yang dapat digunakan untuk menyerang aplikasi

website

2. Membuat aplikasi berbasis website untuk menguji kode yang diunggah dengan

membandingkannya dengan parameter yang ditentukan dan mengacu pada OWASP Code

Review Project

3. Menguji website yang telah dibuat dengan berbagai skenario yang ditentukan sebelumnya

1.3 Metode Penelitian

Metode penelitian yang digunakan pada penelitian ini adalah:

1. Studi literatur dengan melakukan pengamatan pada berbagai buku, jurnal, artikel, dan

referensi-referensi lainnya yang berhubungan dengan SQL Injection dan panduan

OWASP untuk menguji dan mengatasi SQL Injection

2. Perancangan dan implementasi untuk menguji kode yang dimasukkan rentan atau tidak

terhadap serangan SQL Injection


4

3. Uji coba dan analisis hasil dari implementasi website untuk menguji rentan atau tidak terhadap SQL Injection.

2. Dasar Teori

2.1 Panduan OWASP

Open Website Security Project (OWASP) merupakan komunitas terbuka yang

bertujuan untuk memfasilitasi agar siapapun dapat memahami, mengembangkan,

mendapatkan, mengoperasikan, dan mengelola aplikasi yang dapat dipercaya. Semua

dokumen, tools, dan forum OWASP tidak berbayar. OWASP merupakan organisasi yang

dipercaya dalam hal keamanan aplikasi[5].

Salah satu proyek yang ada pada OWASP adalah “OWASP Top Ten Project” yang

merupakan dokumen untuk meningkatkan kesadaran mengenai keamanan aplikasi. Dokumen

yang telah dirilis adalah OWASP Top Ten Project tahun 2004[1], 2007[2], 2010[3] dan

2013[4]. Telah dijelaskan juga pada subbab latar belakang bahwa dengan terbitnya dokumen

OWASP Top Ten Project, dapat dilihat bahwa serangan yang sering terjadi adalah SQL

Injection. Bahkan sampai pada tahun ini, serangan tersebut merupakan serangan yang paling

sering dilakukan.

Seiring dengan semakin banyaknya kasus SQL Injection, OWASP juga merilis

panduan untuk mencegah SQL Injection beserta cara pengujian untuk mengetahui apakah

website masih rentan pada serangan SQL Injection atau tidak.

2.2 Panduan Pencegahan OWASP

Selain mengeluarkan panduan pengujian, OWASP juga mengeluarkan panduan untuk

pencegahan SQL Injection. Ada dua jenis pencegahan yang dapat dilakukan yakni

perlindungan primer dan tambahan [7].

A. Perlindungan Primer

Terdapat dua pilihan untuk melakukan perlindungan primer, yakni:

a. Prepared Statements dengan Parameterized Queries

Dengan menggunakan prepared statements, pengembang aplikasi website

mendefinisikan semua kode SQL terlebih dahulu, kemudian melewatkan setiap

parameter ke query. Sehingga basis data dapat membedakan antara kode dan data,

tanpa memperdulikan masukan dari pengguna.

Keuntungan penggunaan prepared statements adalah orang lain tidak bisa

memasukkan perintah SQL karena perintah SQL yang dimasukkan akan mencari


5

string. Misalkan perintah SQL yang ingin dimasukkan pada kolom username

adalah “username’ or ‘1’ = ‘1”. Dengan menggunakan prepared statements, maka

akan dicari username dengan nama “username’ or ‘1’ = ‘1”.

Beberapa bahasa pemrograman yang direkomendasikan oleh OWASP

adalah sebagai berikut:

• JAVA EE – menggunakan fungsi PreparedStatement() dengan bind

variables

• NET – menggunakan fungsi SqlCommand() atau OleDbCommand() dengan

bind variables

• PHP – menggunakan PDO dengan fungsi bindParam()

• Hibernate – menggunakan fungsi createQuery() dengan named parameters

• SQLite – menggunakan fungsi sqlite3_prepare()

Contoh penggunaan prepared statements pada PHP dapat dilihat pada

Gambar 2.9 [7].

Gambar 2.9 Contoh Prepared Statement pada PHP

b. Meloloskan Masukan Pengguna

Cara ini merupakan cara yang paling tidak direkomendasikan. Karena bila

tidak diaplikasikan dengan benar, maka basis data tetap tidak bisa membedakan

masukan pengguna adalah “data” atau kode SQL.

B. Perlindungan Tambahan

Terdapat dua pilihan untuk melakukan perlindungan tambahan, yakni [7]:

a. Pemberian Hak Istimewa

Untuk meminimalkan adanya serangan SQL Injection, sebaiknya membatasi

hak akses basis data. Hal ini dapat dilakukan dengan cara tidak memberikan akses

admin ke aplikasi website. Misalkan sebuah akun hanya bisa melihat konten,

maka hanya bisa membaca konten itu saja.

b. Validasi Masukan dengan White List

Dengan melakukan validasi masukan pengguna, akan memastikan bahwa

masukan pengguna merupakan masukan yang diinginkan. Dengan menggunakan


6

validasi white list, maka pengembang mendefinisikan apa yang diperbolehkan.

Sehingga masukan yang tidak sesuai, tidak akan diproses [8].

3. Perancangan

3.1 Arsitektur Website

Pada website yang akan dibuat, terdapat arsitektur website dan direpresentasikan dalam

bentuk activity diagram. Pada Gambar 3.1 merupakan activity diagram awal website.

Pertama, pengguna akan mengunggah file yang ingin diuji. Sebelum diproses, akan dicek

terlebih dahulu ukuran dan ekstensi file yang diunggah. Ekstensi file yang diperbolehkan

adalah .html atau .php karena file yang diunggah berbentuk kode PHP. Ukuran file dibatasi

kurang dari 30 KB karena secara default, maksimum ukuran file yang boleh diunggah adalah

2 MB [22]. Hal tersebut terlalu besar untuk ukuran file kode PHP. Apabila dibiarkan seperi

itu, maka seseorang dapat mengunggah file yang berbahaya ke server. Kemudian setelah

dilakukan pengecekan ekstensi dan ukuran file, maka akan mulai dilakukan pengujian

terhdap parameter. Hal pertama yang akan diuji adalah pemakaian hashing dalam file yang

diunggah. Kemudian diteruskan dengan pengujian ekstensi basis data, sanitasi dan validasi,

serta prepared statements. Kemudian untuk menilai hasil pengujian, dicek terlebih dahulu

apakah ada variabel username dan password di dalamnya. Apabila ada, maka berlanjut ke

poin “A” yakni kategori otentikasi. Sebaliknya, bila tidak ada akan berlanjut ke poin “B”

yakni kategori lain.

Gambar 3.1 Activity Diagram Awal Website

Apabila menuju ke poin “A”, maka file yang diunggah termasuk dalam kategori

otentikasi. Sehingga activity diagram dapat dilihat pada Gambar 3.2. Setelah melakukan

pengujian pada file yang diunggah apakah cocok dengan parameter yang ditentukan, hal


7

selanjutnya adalah menilai parameter yang cocok. Parameter yang akan dinilai adalah

parameter hashing, ekstensi basis data, sanitasi dan validasi, serta prepared statements.

Kemudian dijumlahkan total nilai sehingga merepresentasikan persentase kerentanan file

terhadap SQL Injection. Selanjutnya, dilakukan pengelompokkan sesuai dengan total nilai

yang didapat. Kemudian, menampilkan detail hasil uji yang berisi parameter yang cocok

dengan parameter yang ditentukan sebelumnya. Terakhir, menampilkan solusi yang

dianjurkan sesuai detail hasil uji.

Gambar 3.2 Activity Diagram Kategori Otentikasi

Apabila menuju ke poin “B”, maka file yang diunggah termasuk dalam kategori lain.

Activity diagram dapat dilihat pada Gambar 3.3. Alurnya sama seperti kategori otentikasi.

Namun yang membedakan adalah parameter yang diuji yakni ekstensi basis data, sanitasi dan

validasi, serta prepared statements. Hal ini dikarenakan hashing biasanya digunakan untuk

password. Sehingga pada kategori ini tidak diperlukan.

Gambar 3.3 Activity Diagram Kategori Lain


8

3.2 Parameter dan Penilaian Pengujian

Parameter yang akan diuji akan diberikan poin tertentu sesuai dengan tingkat

keefektifannya untuk mencegah serangan SQL Injection. Poin-poin tersebut adalah sebagai

berikut:

a. Penggunaan hash pada password

• md5(): 5 poin

• sha(): 5 poin

• hash(): 10 poin

• crypt(): 15 poin

• password_hash(): 15 poin

Hashing sangat penting untuk melindungi password agar password yang

disimpan dalam basis data tidak dapat langsung diketahui. Terdapat beberapa fungsi

hashing yang disediakan oleh PHP. Salah satunya adalah fungsi md5() dan sha().

Dalam penelitian ini, penggunaan fungsi md5() dan sha() diberikan 5 poin karena

metode tersebut didesain untuk melakukan hashing dengan sangat cepat dan efisien.

Sehingga sangat mudah untuk mengetahui password asli dengan reverse hashing.

Selain itu, sudah terdapat banyak decryptor di internet sehingga metode tersebut tidak

efektif lagi. Kemudian, terdapat fungsi hash() juga diberikan 10 poin karena dapat

memilih algoritma hashing selain md5 dan sha, diantaranya adalah tiger dan ripemd.

Namun, metode tiger dan ripemd juga mudah dilakukan reverse hashing. Sedangkan

fungsi crypt() dan password_hash() diberikan 15 poin karena merupakan fungsi terbaru

untuk hashing dan masih efektif untuk digunakan hingga saat ini. Metode tersebut

menggunakan algoritma blowfish yang mempunyai kelebihan dalam waktu reverse

hashing yang lebih lama daripada metode lainnya sehingga jauh lebih aman apabila

digunakan [9].

b. Ekstensi PHP untuk mengakses basis data

Terdapat 3 ekstensi PHP yang dijadikan tolak ukur yakni MySQL, MySQLi, dan

PDO. Penilaian untuk ekstensi basis data MySQL adalah 5 poin karena saat ini ekstensi

MySQL kurang aman untuk digunakan dan sudah tidak berlaku di PHP 5.5.0 serta

dihapus pada PHP 7. Selain itu, apabila menggunakan ekstensi MySQL, maka tidak bisa

menggunakan prepared statements. MySQLi merupakan pembaruan dari MySQL dan

lebih aman. Sedangkan PDO merupakan ekstensi yang aman dan dapat menggunakan


9

beberapa basis data. Karena MySQLi dan PDO dapat menggunakan prepared

statements, sehingga penilaiannya mendapatkan nilai 15 poin [10].

c. Sanitasi dan validasi data

• FILTER_SANITIZE_NUMBER_INT dan FILTER_VALIDATE_INT: masing-masing

bernilai 1,5 poin

• FILTER_SANITIZE_SPECIAL_CHARS, atau htmlspecialchars: masing-masing 1,5

poin

• FILTER_SANITIZE_EMAIL dan FILTER_VALIDATE_EMAIL: masing-masing

bernilai 1,5 poin

• Mysql_real_escape_string: 0 poin

• Mysqli_real_escape_string: 2 poin

• Preg_match(): 2 poin

• FILTER_SANITIZE_STRING: 2 poin

Pemberian poin untuk masing-masing fungsi filter atau khusus dinilai

berdasarkan tingkat keefektifannya untuk mencegah serangan SQL Injection [11].

d. Prepared statement

Berdasarkan OWASP Code Review, penggunaan prepared statements sangat

disarankan karena dapat mencegah SQL Injection dengan lebih efektif dibandingkan

dengan parameter yang telah dijelaskan diatas. Karena apabila menggunakan prepared

statements, kode dan data dikirim ke basis data secara terpisah. Sehingga bila seseorang

ingin melakukan SQL Injection, maka tidak bisa dilakukan. Pada kategori otentikasi,

cara pemberian nilai adalah sebagai berikut: diasumsikan apabila file yang diunggah

menggunakan crypt() atau password_hash(), ekstensi basis data MySQLi atau PDO,

dan menggunakan seluruh fungsi sanitasi dan validasi data. Sehingga total nilainya

adalah 45 poin. Maka dari itu, apabila menggunakan prepared statements akan

mendapatkan nilai 55 poin. Sedangkan pada kategori otentikasi, cara pemberian nilai

adalah sebagai berikut: diasumsikan apabila file yang diunggah menggunakan ekstensi

basis data MySQLi atau PDO, dan menggunakan seluruh fungsi sanitasi dan validasi

data. Sehingga total nilainya adalah 30 poin. Maka dari itu, apabila menggunakan

prepared statements akan mendapatkan nilai 70 poin.

3.3 Pengelompokan Hasil Pengujian


10

Setelah selesai menilai file yang diuji, langkah selanjutnya adalah mengelompokkan

total hasil. Terdapat 3 kategori pengelompokan yakni:

a. Resiko Tinggi (High Risk) : rentang nilai antara 0 – 33

Hal ini karena dalam rentang nilai tersebut, file yang diunggah hanya menggunakan

hashing, ekstensi basis data, dan satu sanitasi atau validasi data. Sehingga file tersebut

beresiko tinggi untuk terkena serangan SQL Inejction.

b. Resiko Sedang (Medium Risk) : rentang nilai antara 34 – 67

Pada kategori ini, file yang diunggah menggunakan lebih dari satu sanitasi dan validasi

data serta menggunakan ekstensi basis data MySQLi atau PDO. Karena file yang

diunggah menggunakan hashing dengan metode crypt() atau password_hash(), ekstensi

basis data MySQLi atau PDO, dan menggunakan berbagai sanitasi dan validasi data,

maka keamanan kode terhadap serangan SQL Injection meningkat dan lebih aman.

c. Resiko Rendah (Low Risk) : rentang nilai antara 68 – 100

File yang diunggah dapat masuk ke kategori ini apabila menggunakan prepared

statements. Karena seperti yang telah dijelaskan sebelumnya, penggunaan prepared

statements sangat efektif untuk mencegah SQL Injection.

3.4 Skenario Pengujian

Untuk menguji apakah website yang telah dibuat memenuhi fungsi yang telah

ditentukan sebelumnya, maka diperlukan beberapa skenario pengujian yang akan digunakan,

yakni:

3.5.1 Kategori Otentikasi

Kategori ini digunakan ketika pengguna menggungah file otentikasi, yakni sign up atau

log in. Dalam kategori ini, terdapat lima skenario yang akan digunakan, yakni:

a. Skenario 1: pengguna hanya menggunakan ekstensi basis data

b. Skenario 2: pengguna menggunakan hashing dan ekstensi basis data

c. Skenario 3: pengguna menggunakan hashing, ekstensi basis data, dan sanitasi dan

validasi data

d. Skenario 4: pengguna menggunakan ekstensi basis data dan prepared statements

e. Skenario 5: pengguna menggunakan hashing, ekstensi basis data , sanitasi dan

validasi data, serta prepared statements


11

3.5.2 Kategori Lain

Kategori ini digunakan ketika pengguna mengunggah file selain otentikasi. Dalam

kategori ini terdapat skenario, yakni:

a. Skenario 1: pengguna hanya menggunakan ekstensi basis data

b. Skenario 2: pengguna menggunakan ekstensi basis data serta sanitasi dan validasi

data

c. Skenario 3: pengguna menggunakan ekstensi basis data dan prepared statements

d. Skenario 4: pengguna menggunakan ekstensi basis data, sanitasi dan validasi data

serta prepared statements.

4. Uji Coba dan Analisis

4.1 Analisis Hasil Pengujian Pertama

Pada kategori otentikasi, perbedaan setiap skenario terhadap penggunaan parameter

beserta presentase dan kategorinya terdapat pada Tabel 4.1. Dapat dilihat pada Tabel 4.1

bahwa bila menginginkan presentase keamanan yang lebih tinggi, maka harus menggunakan

prepared statements.

Tabel 4.1 Perbedaan Antar Skenario Pengujian Pertama pada Kategori Otentikasi

Sken

ario Hashing

Ekstensi

Basis

Data

Sanitasi

dan

Validasi

Prepared

Statements

Persentase

Keamanan

Kategor

i

1 - MySQLi - - 15 % Tinggi

2 Md5() MySQLi - - 20 % Tinggi

3 Crypt() MySQLi Filter string

Preg_match - 34 %

Sedang

4 - MySQLi - Object

Oriented 70%

Rendah

5 Password

_hash PDO

Filter string

Preg_match

Object

Oriented 89%

Rendah

Sedangkan untuk kategori lain, perbedaan setiap skenario terhadap penggunaan

parameter beserta presentase dan kategorinya terdapat pada Tabel 4.2. Sama seperti pada

kategori otentikasi, apabila menginginkan persentase keamanan yang besar, maka harus

menggunakan prepared statements.


12

Tabel 4.2 Perbedaan Antar Skenario Pengujian Pertama pada Kategori Lain

Skenario

Ekstensi

Basis

Data

Sanitasi

dan

Validasi

Prepared

Statement

s

Persentase

Keamana

n

Kategori

1 MySQLi - - 15% Tinggi

2 MySQLi Filter

string - 17% Tinggi

3 MySQLi - Object

Oriented 85% Rendah

4 MySQLi Filter

string

Object

Oriented 87% Rendah

4.2 Analisis Implementasi Solusi Pengujian Pertama

Pada kategori otentikasi, perbedaan setiap skenario terhadap penggunaan parameter

beserta presentase dan kategorinya setelah menerapkan solusi yang dianjurkan dapat dilihat

pada Tabel 4.3. Dapat dilihat bahwa setelah dilakukan perbaikan script, maka persentase

keamanan meningkat dan semua skenario sudah termasuk ke dalam kategori “Resiko

Rendah”.

Sedangkan untuk kategori lain, perbedaan setiap skenario terhadap penggunaan

parameter beserta presentase dan kategorinya setelah menerapkan solusi yang dianjurkan

dapat dilihat pada Tabel 4.4. Sama seperti pada kategori otentikasi, semua skenario

mengalami peningkatan persentase keamanan dan semuanya masuk ke kategori “Resiko

Rendah”.

Tabel 4.3 Perbedaan Antar Skenario Perbaikan Pengujian Pertama pada Kategori Otentikasi

Sken

ario Hashing

Ekstensi

Basis

Data

Sanitasi

dan

Validasi

Prepared

Statements

Persentase

Keamanan Kategori

1 Password MySQLi Filter string procedural 89 % Rendah


13

_hash() Preg_matc

h

2 Password

_hash() MySQLi

Mysqli

escape

karakter

Preg_matc

h

procedural 89 %

Rendah

3 Crypt() MySQLi

Filter string

Preg_matc

h

procedural 89 %

Rendah

4 Crypt() MySQLi

Mysqli

escape

karakter

Preg_matc

h

Object

Oriented 89% Rendah

5 Passwor

d_hash() PDO

Filter string

Preg_matc

h

Object

Oriented 89% Rendah

Tabel 4.4 Perbedaan Antar Skenario Perbaikan Pengujian Pertama pada Kategori Lain

Skenario

Ekstensi

Basis

Data

Sanitasi dan

Validasi

Prepared

Statements

Persentase

Keamanan Kategori

1 MySQLi Mysqli escape

karakter procedural 89% Rendah

2 MySQLi Filter string procedural 89% Rendah


karakter

Object

Oriented 89% Rendah

4 MySQLi Filter string Object

Oriented 89% Rendah


14

4.3 Analisis Hasil Pengujian Kedua

Pengujian kedua ini dilakukan dengan tujuan untuk mengetes kekonsistensian website

dalam menguji script. Script yang diuji berbeda dari pengujian pertama, namun parameter

yang ada digunakan sama.


File yang akan diuji merupakan file login website. Hasil pengujian kedua dapat dilihat

pada Tabel 4.5. Parameter yang digunakan sama seperti pengujian pertama dan menunjukkan

bahwa persentase keamanan dan kategori juga sama seperti pengujian pertama.

Tabel 4.5 Perbedaan Antar Skenario Pengujian Kedua pada Kategori Otentikasi

Skenario Hashing

Ekstensi Basis Data

Sanitasi dan Validasi

Prepared Statements

Persentase Keamanan Kategori

1 - MySQLi - - 15 % Tinggi 2 Md5() MySQLi - - 20 % Tinggi

3 Crypt() MySQLi Filter string Preg_match - 34 % Sedang

4 - MySQLi - Object Oriented 70% Rendah

5 Password_hash PDO Filter string

Preg_match Object

Oriented 89% Rendah

4.3.2 Kategori Lain

File yang akan diuji merupakan file untuk menampilkan hasil dari pencarian nama.

Hasil pengujian kedua untuk kategori ini dapat dilihat pada Tabel 4.6. Dengan menggunakan

parameter yang sama seperti pengujian pertama, persentase keamanan dan kategori yang

dihasilkan juga sama seperti pengujian pertama.

Tabel 4.6 Perbedaan Antar Skenario Pengujian Kedua pada Kategori Lain

Skenario Ekstensi Basis Data


Prepared Statements


1 MySQLi - - 15% Tinggi 2 MySQLi Filter string - 17% Tinggi

3 MySQLi - Object Oriented 85% Rendah

4 MySQLi Filter string Object Oriented 87% Rendah

4.4 Analisis Implementasi Solusi Pengujian Kedua

Setelah dilakukan pengujian kedua, hal selanjutnya yang akan dilakukan adalah

memperbaiki script sesuai dengan solusi yang danjurkan.


15


Hasil pengujian kedua setelah mengimplementasikan solusi yang dianjurkan dapat

dilihat pada Tabel 4.7. Terlihat bahwa persentase keamanan meningkat setelah dilakukan

perbaikan dan kategori setiap skenario merupakan “Resiko Rendah”. Hal ini sama seperti

hasil pengujian pertama. Tabel 4.7 Perbedaan Antar Skenario Perbaikan Pengujian Kedua pada Kategori Otentikasi

Skenario Hashing

Ekstensi Basis Data


Prepared Statements


1 Password_hash() MySQLi Filter string

Preg_match procedural 89 % Rendah

2 Password_hash() MySQLi

Mysqli escape karakter

Preg_match procedural 89 %

Rendah

3 Crypt() MySQLi Filter string Preg_match procedural 89 % Rendah

4 Crypt() MySQLi Mysqli escape

karakter Preg_match

Object Oriented 89%

Rendah

5 Password_hash() PDO Filter string

Preg_match Object

Oriented 89% Rendah

4.4.2 Kategori Lain

Hasil pengujian kedua setelah mengimplementasikan solusi yang dianjurkan dapat

dilihat pada Tabel 4.8. Sama seperti kategori otentikasi, terlihat bahwa persentase keamanan

meningkat dan kategori setiap skenario merupakan “Resiko Rendah”. Hal ini sama juga

seperti hasil pengujian pertama.

Tabel 4.8 Perbedaan Antar Skenario Perbaikan Pengujian Kedua pada Kategori Lain

Skenario Ekstensi Basis Data


Prepared Statements



karakter procedural 89% Rendah

2 MySQLi Filter string procedural 89% Rendah


karakter

Object Oriented 89% Rendah

4 MySQLi Filter string Object Oriented 89% Rendah

5. Kesimpulan

Berdasarkan keseluruhan rangkaian pelaksanaan skripsi ini mulai dari perancangan

hingga implementasi dan analisis, dapat diperoleh beberapa kesimpulan sebagai berikut:


16

1. Perancangan pendeteksi SQL Injection telah berhasil diimplementasikan dengan

menggunakan bahasa PHP.

2. Untuk menentukan hasil pengujian, digunakan parameter yang ditentukan yakni

hashing, ekstensi basis data, sanitasi dan validasi data, serta prepared statement.

3. Hasil pengujian pertama sama dengan hasil perhitungan manual. Hal ini menunjukkan

bahwa website yang telah dibuat dapat melakukan pengujian secara benar.

4. Apabila menggunakan prepared statements dalam file yang diunggah, maka akan

masuk ke kategori “Resiko Rendah” karena nilai untuk penggunaan ekstensi basis data

sebesar 15 poin ditambah dengan prepared statements sebesar 55 poin jika termasuk

kategori otentikasi dan 70 poin jika termasuk kategori lain.

5. Setelah mengubah script dengan mengacu pada semua solusi yang dianjurkan, akan

membuat persentase keamanan meningkat dan masuk ke kategori “Resiko Rendah”.

Hal ini menunjukkan bahwa solusi yang diajukan efektif untuk menaikkan persentase

keamanan.

6. Hasil pengujian kedua dengan menggunakan script yang berbeda, namun dengan

parameter yang sama memperlihatkan hasil yang sama seperti pada pengujian

pertama. Hal ini menunjukkan bahwa website yang telah dibuat konsisten dalam

melakukan pengujian.

6. Referensi

[1] OWASP (2004). OWASP Top 10 -2004. 23 May, 2017. <https://excellmedia.dl.

sourceforge.net/project/owasp/Top%20Ten/2004/OWASPTopTen2004.pdf>

[2] OWASP (2007). OWASP Top 10 -2007. 23 May, 2017. <https://www.owasp.org/

images/e/e8/OWASP_Top_10_2007.pdf>

[3] OWASP (2010). OWASP Top 10 -2010”. 23 May, 2017.

<https://storage.googleapis.com/ google-code-

archivedownloads/v2/code.google.com/owasptop10/OWASP%20Top %2010%20-

%202010.pdf>

[4] OWASP (2013). OWASP Top 10 -2013. 29 December, 2016. <https://www.owasp.org/

images/f/f8/OWASP_Top_10_-_2013.pdf>

[5] OWASP (2017, March 16). About The Open Web Application Security Project. 29

December, 2016. <https://www.owasp.org/index.php/About_OWASP>

[6] OWASP (2008). OWASP Testing Guide 4.0. 29 December, 2016.

<https://www.owasp.org/images/1/19/OTGv4.pdf>


17

[7] OWASP (2017, April 27). SQL Injection Prevention Cheat Sheet. 26 May,

2017.<https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet>

[8] OWASP (2017, May 16). Input Validation Cheat Sheet. 26 May, 2017.

<https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet>

[9] PHP.net. Safe Password Hashing. 18 June, 2017. <http://php.net/manual/en/faq.

password.php>

[10] PHP.net. Choosing an API. 18 June, 2017. <http://php.net/manual/en/mysqlinfo.api.

choosing.php>

[11] W3Programmers. Sanitize and Validate Data with PHP Filters. 18 June, 2017.

<http://www.w3programmers.com/sanitize-and-validate-data-with-php-filters/>


pengembangan web vulnerability assessment tool …

Documents