SECURE CODING

BEST PRACTICES

Draft
Version 0.1

Dokumen ini mengacu kepada metodologi yang digunakan pada

OWASP Top 10 Guidance 2013
dan dikompilasi dari berbagai sumber lain yang bersifat creative common

Drafted by
Indarko Wiyogo, CISSP
Semi Yulianto, CISSP

Security and Quallity Assurance

2013
Daftar Isi

1. Injection (A01) ........................................................................................................................................... 4

1.1 Pola Kerentanan ............................................................................................................................ 4
1.2 Kerentanan Selama Pengecekan Kode ............................................................................................... 4
1.3 PHP Code ............................................................................................................................................. 4
Contoh PHP Code yang Rentan ............................................................................................................. 4
Contoh PHP Code yang Disarankan ...................................................................................................... 5
1.4 SQL Code ............................................................................................................................................. 5
Contoh Query SQL yang Rentan............................................................................................................ 5
Contoh Query SQL yang Disarankan ..................................................................................................... 5
1.5 Java Code ............................................................................................................................................ 5
Contoh Java Code yang Rentan............................................................................................................. 5
Contoh Java Code yang Disarankan ...................................................................................................... 6
1.8 Rekomendasi ....................................................................................................................................... 7
2. Broken Authentication and Session Management (A02).......................................................................... 8
2.1 Pola Kerentanan .................................................................................................................................. 8
2.2 Contoh Kerentanan ............................................................................................................................. 8
2.4 Rekomendasi ....................................................................................................................................... 9
3. Cross Site Scripting (A03) ........................................................................................................................ 11
3.2 PHP Code ........................................................................................................................................... 11
Kerentanan (XSS)................................................................................................................................. 11
Kerentanan (Response Splitting)......................................................................................................... 11
Contoh PHP Code yang Disarankan ........................................................................................................ 11
3.6 Rekomendasi ..................................................................................................................................... 11
4. Insecure Direct Object References (A04) ................................................................................................ 13
4.1 Pola Kerentanan ................................................................................................................................ 13
4.2 Contoh Serangan............................................................................................................................... 13
4.3 Cara Mengecek Kerentanan Aplikasi ................................................................................................ 13
4.4 Rekomendasi ..................................................................................................................................... 13
5. Security Miss Configuration (A05) .......................................................................................................... 14
5.1 Pola Kerentanan ................................................................................................................................ 14
5.2 Contoh Serangan............................................................................................................................... 14
5.3 Cara Mengecek Kerentanan Aplikasi ................................................................................................ 14

Page 2 of 22
 5.4 Rekomendasi ..................................................................................................................................... 15
6. Sensitive Data Exposure (A06) ................................................................................................................ 16
6.1 Pola Kerentanan ................................................................................................................................ 16
6.2 Cara Mengecek Kerentanan .............................................................................................................. 16
6.3 Contoh Serangan............................................................................................................................... 16
6.4 Rekomendasi ..................................................................................................................................... 16
7. Missing Function Level Access Control (A07).......................................................................................... 17
7.1 Pola Kerentanan ................................................................................................................................ 17
7.2 Mengecek Kerentanan ...................................................................................................................... 17
7.3 Contoh Serangan............................................................................................................................... 17
7.4 Rekomendasi ............................................................................................................................... 17
8. Cross-Site Request Forgery (CSRF) (A08) ................................................................................................ 18
8.1 Pola Kerentanan ................................................................................................................................ 18
8.2 Contoh Kerentanan ........................................................................................................................... 18
8.3 Cara Mengecek Kerentanan Aplikasi ................................................................................................ 18
8.4 Rekomendasi ..................................................................................................................................... 18
9. Using Components with Known Vulnerabilities (A09) ............................................................................ 19
9.1 Pola Kerentanan ................................................................................................................................ 19
9.2 Contoh Kerentanan ........................................................................................................................... 19
9.3 Rekomendasi ............................................................................................................................... 20
10. Un-validated Redirects and Forwards (A10) ......................................................................................... 21
10.1 Pola Kerentanan .............................................................................................................................. 21
10.2 Contoh Kerentanan ......................................................................................................................... 21
10.3 Cara Mengecek Kerentanan Aplikasi .............................................................................................. 21
10.4 Rekomendasi................................................................................................................................... 22

Page 3 of 22
1. Injection (A01)

Kelemahan injeksi, seperti SQL, OS, dan LDAP injection terjadi ketika data yang tidak dapat
dipercaya dikirim ke aplikasi sebagai bagian dari suatu perintah atau query. Penyerang bisa
mengelabui aplikasi untuk mengeksekusi perintah yang tidak direncanakan atau mengakses
data yang tidak terotorisasi.

1.1 Pola Kerentanan

Setiap aplikasi yang memiliki pola untuk beresiko terkena injeksi SQL :
a. Mengambil input pengguna
b. Tidak memeriksa input pengguna untuk validitas
c. Menggunakan data input pengguna untuk query database
d. Menggunakan rangkaian string atau penggantian string untuk membangun query SQL
menggunakan exec perintah SQL (atau serupa)

1.2 Kerentanan Selama Pengecekan Kode

Ketika mengecek kode untuk serangan injeksi SQL, pertama carilah query yang langsung
berhubungan ke database karena setiap kode yang tidak melakukan koneksi ke database jelas
tidak dapat memiliki serangan injeksi SQL.

Bahasa Key Words to Look For

PHP mysql_connect, mysql_query, pg_query
SQL exec, execute, sp_executesql
Java (including JDBC) java.sql, sql

1.3 PHP Code

Contoh PHP Code yang Rentan
Contoh 1
<?php
// akses ke database tidak boleh hardcode harus memakai function/parameter
$db = mysql_connect("localhost","root","$$sshhh...!");
//nama db tidak boleh hardcode harus memakai parameter tidak boleh function
mysql_select_db("Shipping",$db);
$id = $HTTP_GET_VARS["id"];
//harus ada validasi inputan
$qry = "SELECT ccnum FROM cust WHERE id =%$id%";
//tidak boleh langsung melakukan eksekusi query
$result = mysql_query($qry,$db);
if ($result) {
echo mysql_result($result,0," ccnum");
} else {
echo "No result! " . mysql_error();
}
?>

Contoh 2
//tidak ada validasi input
$clas=$_POST['clas'];
$query="SELECT * FROM $clas ";

Page 4 of 22
 Contoh PHP Code yang Disarankan
Contoh 1
<?php
$db = mysqli_connect(getServer(),getUid(),getPwd());
$stmt = mysqli_prepare($link, "SELECT ccnum FROM cust WHERE id = ?");
$id = $HTTP_GET_VARS["id"];
// hanya dibolehkan IDs (1-8 digits)

if (preg_match('/^\d{1,8}$/',$id)) {
mysqli_stmt_bind_param($stmt, "s", $id);
mysqli_stmt_execute($stmt);
mysqli_stmt_bind_result($stmt, $result);
mysqli_stmt_fetch($stmt);
if (empty($name)) {
echo "No result!";
} else {
echo $result;
}
} else {
echo "Invalid ID. Try again.";
}
?>

Contoh 2
//menggunakan fungsi str_replace `','\\`
$clas = str_replace('`','\\`',$_POST['clas']);
$query = "SELECT * FROM \`{$clas}\`";

1.4 SQL Code

Contoh Query SQL yang Rentan
//tidak ada input filtering
CREATE PROCEDURE dbo.doQuery(@query nchar(128))
AS
exec(@query)
RETURN

Contoh Query SQL yang Disarankan

CREATE PROCEDURE dbo.doQuery(@id nchar(4))
AS
DECLARE @query nchar(64)
//menggunakan fungsi rtrim untuk menghilangkan spasi dan filtering karakter
IF RTRIM(@id) LIKE '[0-9][0-9][0-9][0-9]'
BEGIN
SELECT @query = 'select ccnum from cust where id = ''' + @id + ''''
EXEC @query
END
RETURN

1.5 Java Code

Contoh Java Code yang Rentan
import java.*;
import java.sql.*;
...
public static boolean doQuery(String Id) {
Connection con = null;
try
{
Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"");
con = DriverManager.getConnection("jdbc:microsoft:sqlserver: " +

Page 5 of 22
 "//localhost:1433", "sa", "$3cre+");
Statement st = con.createStatement();
ResultSet rs = st.executeQuery(
" SELECT ccnum FROM cust WHERE id = " + Id);
while (rs.next()) {
// Party on results
}
rs.close();
st.close();
}
catch (SQLException e)
{
// OOPS!
return false;
}
catch (ClassNotFoundException e2)
{
// Class not found
return false;
}
finally
{
try
{
con.close();
} catch(SQLException e) {}
}
return true;
}

Contoh Java Code yang Disarankan

public static boolean doQuery(String arg) {
// only allow valid IDs (1-8 digits)
Pattern p = Pattern.compile("^\\d{1,8}$");
if (!p.matcher(arg).find())
return false;
Connection con = null;
try
{
Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");
con = DriverManager.getConnection(getConnectionInfo());
PreparedStatement st = con.prepareStatement(
"exec pubs..sp_GetCreditCard ?");
st.setString(1, arg);
ResultSet rs = st.executeQuery();
while (rs.next()) {
// Get data from rs.getString(1);
}
rs.close();
st.close();
}
catch (SQLException e)
{
System.out.println("SQL Error: " + e.toString());
return false;
}
catch (ClassNotFoundException e2)
{
System.out.println("Class not found: " + e2.toString());
return false;
}
finally
{
try

Page 6 of 22
 {
con.close();
} catch(SQLException e) {}
}
return true;
}

1.8 Rekomendasi
Cara untuk mencegah injeksi mensyaratkan data yang tidak dapat dipercaya tetap terpisah
dari perintah-perintah dan queries.
1. Fungsi berikut bisa digunakan untuk membuat prepared statements. Hal ini
memungkinkan sebuah aplikasi untuk membuat SQL query yang mengandung
parameter dan men-set nilai parameter di tempat yang aman :
mysqli-> prepare
stmt-> prepare
stmt-> bind_param
stmt-> execute
odbc_prepare
2. Ada dua metode untuk memvalidasi input
a. Blacklisting, membiarkan semua karakter masukan kecuali yang secara eksplisit
didefinisikan didalam blacklist.
b. Whitelisting, memblok semua karakter masukan kecuali yang secara eksplisit
didefinisakan pada Whitelist.
3. Contoh ekspresi reguler alpanumerik di PHP,
preg_replace( "/[^a-zA-Z0-9_]/", "", $stringToFilter );
4. Jangan menggunakan user System Administrator seperti “sa” untuk web aplikasi.

Page 7 of 22
2. Broken Authentication and Session Management (A02)

Fungsi-fungsi aplikasi yang berhubungan dengan otentikasi dan pengelolaan sesi seringkali
tidak dimplementasikan dengan benar. Hal ini memungkinkan penyerang mendapatkan
password, key, dan token-token sesi, atau mengeksploitasi implementasi lainnya untuk
memperoleh identitas pengguna yang lain.

2.1 Pola Kerentanan

Penyerang menggunakan kelemahan atau cacat dalam fungsi-fungsi otentikasi atau
pengelolaan sesi. Contohnya akun, password, session, ID yang terekspos, dll untuk menyamar
sebagai pengguna lain.

2.2 Contoh Kerentanan

Contoh 1 :
Aplikasi reservasi tiket pesawat mendukung penulisan ulang URL, menempatkan session
id dalam URL
http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

seorang pengguna di konfirmasi oleh situs diatas untuk menyebarkan link tersebut
kepada teman-temannya tanpa mengetahui apabila mengklik situs tersebut, maka
session id dari pengguna akan terambil. Bayangkan apabila di session id tersebut ada
nomor kartu kredit yang tersimpan.

Contoh 2 :
Pengaturan timeout aplikasi tidak dilakukan dengan benar, pengguna menggunakan
komputer umum untuk mengakses aplikasi. Pada saat pengguna akan keluar dari aplikasi
seharusnya memilih tombol “Logout” tetapi pengguna tidak memilih tombol logout
tersebut malah hanya menutup tab dan langsung pergi. Penyerang menggunakan
browser yang sama dan browser masih ter-otentikasi.

Contoh 3:
Insider atau Penyerang Eksternal memperoleh akses ke sistem database password.
Password pengguna tidak terenkripsi, dan memperlihatkan seluruh isi database password
ke penyerang.

Contoh 4:
Untuk otentikasi di website , password yang dimasukan sangat sederhana untuk diingat,
yaitu misalnya tanggal lahir pemilik akun. Pemilik akun tersebut akan merubah password
menjadi tanggal lahir istrinya. Dan pemilik akun menerima email dari website sebagai
berikut :
Dear Pemilik Account,
Tanda pengenal Anda adalah: Pemilik Account
Password baru Anda adalah: 01021975
Salam,
Admin Website

Page 8 of 22
 Setiap penyerang dapat dengan mudah menebak password pemilik account. Jika
penyerang tahu situs website memerlukan sandi 8-digit, dengan social enginering, mudah
untuk memiliki tanggal lahir semua anggota keluarga pemilik akun (orangtua, pasangan,
anak, dll)
Dan bahkan jika password pemilik akun tidak mudah ditebak, seorang penyerang
berpengalaman juga bisa mencegat email pemilik akun dan mendapatkan tanda pengenal
dan password pemilik akun.

Contoh 5:
Berikut ini contoh kesalahan respon yang seharusnya tidak ditampilkan :

 “Login for user foo: invalid password”

 “Login failed : invalid user id”
 “Login failed : account disable”
 “Login failed : this user is not active“

Respon yang benar tidak menunjukan bahwa Id Pengguna atau password adalah parameter
yang salah dan menampilkan user id yang valid.

Berikut contoh kesalahan respon yang seharusnya ditampilkan :

 “Login failed : Invalid user id or password”

2.4 Rekomendasi
a. Password strength (Mengacu S.E. no 53/Dirtekjaskug/0711 tentang tatacara pengamanan
password pada sistem teknologi perusahaan)
Aplikasi harus memberikan level minimal dari keamanan sebuah password, dimana dapat dilihat
dengan cara melihat panjang dari password dan kompleksitasnya. Contohnya sebuah aplikasi
dimana terdapat user baru yang akan mendaftar, aplikasi tidak mengijinkan password dengan
panjang 3-4 karakter atau kata-kata simpel yang dapat mudah ditebak oleh hacker.

[ X ] Aman123
[ √ ] 64ruda@P4nc45il4

b. Penggunaan Password
Aplikasi harus membatasi user yang mengakses aplikasi dan melakukan login kembali ke
sistem pada tenggang waktu tertentu. Dengan cara ini aplikasi dapat dilindungi dari
serangan brute force dimana hacker bisa menyerang berulang kali untuk berhasil login ke
sistem. Selain itu, log in yang gagal sebaiknya dicatat sebagai informasi kepada
administrator untuk mengindikasikan kemungkinan serangan yang terjadi.

c. Penyimpanan Password
Password tidak boleh disimpan (Hardcode) di dalam aplikasi. Password harus disimpan
dalam format terenkripsi dan disimpan di file lain seperti file database atau file password.
Hal ini dapat memastikan bahwa informasi yang sensitif seperti password tidak
disebarkan ke dalam aplikasi.

d. Melindungi Session ID

Page 9 of 22
 Server biasanya menggunakan session ID untuk mengidentifikasi user yang masuk ke
dalam session. Akan tetapi jika session ID ini dapat dilihat oleh seseorang pada jaringan
yang sama, orang tersebut dapat menjadi seorang client. Salah satu cara yang dapat
digunakan untuk mencegah terlihatnya session ID oleh seseorang pada suatu jaringan
yang sama adalah menghubungkan komunikasi antara sever dan client pada sebuah SSL-
protected channel.

e. Upaya-upaya yang kuat juga harus dilakukan untuk menghindari kelemahan XSS yang
dapat digunakan untuk mencuri session ID.

f. Untuk pengguna yang memiliki akses ke informasi sensitif dan operasi, harus mempunyai
minimal 2 otentikasi (multi factor authentication). Contoh :
- password
- token
- fingerprint
- Penggunaan Captcha

Page 10 of 22
3. Cross Site Scripting (A03)

Kelemahan XSS terjadi ketika aplikasi mengambil data yang tidak dapat dipercaya dan
mengirimnya ke suatu web browser tanpa validasi yang memadai. XSS memungkinkan
penyerang mengeksekusi script-script di dalam browser korban, yang dapat membajak sesi
pengguna, mengubah tampilan website, atau mengarahkan pengguna ke situs-situs jahat.
3.1 Pola Kerentanan

Setiap aplikasi yang memiliki pola berikut ini beresiko terkena cross-site scripting:
a. Aplikasi web mengambil input dari suatu entitas HTTP seperti querystring, header, atau
from.
b. Aplikasi ini tidak memeriksa validitas input.
c. Aplikasi ini mengembalikan data ke browser, baik dalam HTML atau header HTTP.

3.2 PHP Code

Kerentanan (XSS)
//tidak ada validasi input
($name)) {
<?php
$name=$_GET['name'];
if (isset echo "Hello $name";
}
?>

Kerentanan (Response Splitting)

//tidak ada validasi input
<?php
$lcid = $_GET['lcid'];
...
header("locale: $lcid");
?>

Contoh PHP Code yang Disarankan

<?php
$name=$_GET['name'];
if (isset($name)) {
if (preg_match('/^\w{5,25}$/',$name)) {
echo "Hello, " . htmlentities($name);
} else {
echo "Go away!";
}
}
?>

3.6 Rekomendasi
1. Mem-filter semua data yang tidak dapat dipercaya dengan tepat berdasarkan konteks
HTML (body, atribut, JavaScript, CSS, atau URL) tempat diletakkannya data. Pengembang
perlu menyertakan filter ini dalam aplikasi mereka.
2. Seorang pengembang dapat mengatur karakter set untuk halaman web, terlepas dari
lingkungan server pemrograman web, dengan menambahkan kode berikut ke awal
halaman web:
Page 11 of 22
 <meta http-equiv="Content Type" content="text/html; charset=ISO-8859-1" />
ISO-8859-1 seringkali disebut juga dengan Latin-1, adalah standar character
encoding dari 191 karakter dalam tulisan latin.

3. Membatasi input hanya untuk inputan yang sudah divalidasi.

4. Setiap output harus di encode. Pengembang akan menggunakan salah satu antara
HTML encoding atau URL encoding, tergantung pada output form. (HTML body vs HTTP
headers)

Page 12 of 22
4. Insecure Direct Object References (A04)

Adalah suatu celah yang terjadi saat pembuat aplikasi web meng-ekspos referensi internal
penggunaan objek seperti file, direktori, database record, dan lainnya. Celah ini dapat
memaksa target browser yang sudah log-in untuk mengirimkan "pre-authenticated request"
terhadap suatu aplikasi website dan memaksa browser target untuk melakukan perintah
penyusup.

4.1 Pola Kerentanan

Penyerang yang merupakan pengguna sistem yang terotorisasi, cukup merubah nilai
parameter dari obyek sistem ke obyek lainnya yang tidak terotorisasi. Dampak dari serangan
tersebut adalah mengkompromikan seluruh data yang dapat diacu oleh parameter.

4.2 Contoh Serangan

Aplikasi menggunakan data tidak diverifikasi dalam sebuah panggilan SQL yang mengakses
informasi akun:

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt =
connection.prepareStatement(query , … );
pstmt.setString( 1, request.getparameter("acct"));

ResultSet results = pstmt.executeQuery( );

Penyerang cukup memodifikasi parameter ‘acct’ di browsernya untuk mengirim nomor akun
apapun yang diinginkan. Jika tidak diverifikasi, penyerang dapat mengakses sembarang akun
pengguna lain.

http://example.com/app/accountInfo?acct=notmyacct

4.3 Cara Mengecek Kerentanan Aplikasi

Cara terbaik untuk mengetahui apakah keamanan aplikasi rentan terhadap obyek referensi
adalah dengan memverifikasi bahwa seluruh obyek referensi telah memiliki pertahanan yang
sesuai. Untuk mencapai hal ini, perlu diperhatikan :
1. Untuk referensi yang dibatasi, aplikasi perlu memverifikasi apakah pengguna berhak
mengakses sumber daya yang dimintanya.
2. Jika referensi tidak dibatasi, akses user ke referensi harus dibatasi ke nilai yang ter-
otorisasi.

4.4 Rekomendasi
Seperti biasa , pengembang aplikasi web dapat mencegah serangan ini melalui perencanaan
yang baik. Pengembang harus menggunakan peta referensi tidak langsung, karena pemetaan
referensi secara langsung dapat dengan mudah ditebak oleh penyerang . Pengembang harus
menghindari mengekspos resource yang bersifat privat kepada pengguna. Nama file,
eksternal / internal URL, dan kunci basis data merupakan contoh hal-hal yang tidak boleh
ditampilkan kepada pengguna

Page 13 of 22
5. Security Miss Configuration (A05)

Keamanan yang baik mensyaratkan dimilikinya suatu konfigurasi keamanan (yang terdefinisi
dan diterapkan) untuk aplikasi, framework, server aplikasi, web server, server database, dan
platform. Semua pengaturan ini harus didefinisikan, diimplementasikan, dan dipelihara,
karena terdapat banyak aplikasi yang dirilis tanpa konfigurasi default yang aman. Hal ini juga
mencakup menjaga semua software up-to-date, termasuk semua pustaka kode yang
digunakan aplikasi tersebut.

5.1 Pola Kerentanan

Penyerang mengakses akun, halaman yang tidak terpakai, kelemahan sistem yang belum di-
patch, file dan direktori yang tidak dilindungi, dsb. Memperoleh akses tidak terotorisasi atau
informasi tentang sistem. Dampak dari serangan ini adalah seringkali memberi penyerang
akses ke data atau fungsionalitas sistem atau terkadang berakibat terkomprominya sistem
secara utuh.

Beberapa contoh kesalahan konfigurasi antara lain :

a. Menggunakan User dan Password default ( contoh user = ‘sa’ )
b. Akun Backdoor Hard-Coded
c. Mekanisme Akses Khusus
d. Ketergantungan pada Peralatan Keamanan

5.2 Contoh Serangan

Contoh 1 :
Aplikasi bergantung pada framework yang powerful contohnya Code Igniter. Kelemahan
XSS ditemukan dalam framework tersebut. Update telah dirilis untuk memperbaikinya
namun pengembang tidak mengupdate library. Penyerang dapat dengan mudah
menemukan dan mengeksploitasi kelemahan ini.

Contoh 2:
Konsol admin server aplikasi terinstalasi otomatis dan tidak dibuang. Akun standar tidak
diubah. Penyerang menemukan page admin, login dengan password standar, lalu
mengambil alih sistem.

Contoh 3:
Listing direktori ditampilkan. Penyerang dapat mendownload seluruh source kemudian
menemukan kelemahan dalam aplikasi.

5.3 Cara Mengecek Kerentanan Aplikasi

a. Apakah pengembang memiliki proses untuk membuat seluruh software up to date?
Termasuk OS, Server Web/App, DBMS, aplikasi, dan seluruh daftar pustaka kode.
b. Apakah yang tidak perlu telah di-disable, dihapus, atau diuninstall (contoh: port, layanan,
page, akun, privileges)?
c. Apakah password standar telah diubah atau di-disable?

Page 14 of 22
 d. Apakah penanganan kesalahan diset untuk mencegah stack traces dan pesan kesalahan
informatif bocor?
e. Apakah seting keamanan dalam pustaka dan framework pengembangan (misal Struts,
Spring, ASP.NET) telah dipahami dan dikonfigurasi?

Proses menyeluruh dan berulang dibutuhkan untuk memelihara konfigurasi keamanan yang
tepat.

5.4 Rekomendasi
a. Melakukan update patch yang terbaru untuk seluruh aplikasi, Termasuk OS, Server
Web/App, DBMS, dan seluruh referensi kode.
b. Menonaktifkan, menghapus, atau melakukan un-install untuk fasilitas port, layanan,
halaman, akun dan hak akses yang tidak diperlukan.
Sebagai contoh jika yang terbuka adalah port 23 (telnet), maka anda dapat mematikkan
service ini pada Start=>control panel=>administrative tool=>services=>telnet.. Pastikan
pada bagian service status menjadi stopped atau disable.
c. Mengubah Password default dan username bawaan aplikasi atau database.
d. Penanganan pesan error
e. Menghapus konfigurasi / Installer File
f. Lakukan audit terhadap Akses Kontrol
g. Secara rutin memantau log yang terdapat di web server

Page 15 of 22
6. Sensitive Data Exposure (A06)

Banyak aplikasi web yang tidak memberikan perlindungan terhadap data yang sensitif, seperti
kartu kredit, ID pajak, dan autentifikasi. Penyerang dapat mengambil atau memodifikasi data
yang tidak dilindungi untuk melakukan penipuan kartu kredit, pencurian identitas, atau
kejahatan lainnya. Data sensitif layak mendapatkan perlindungan ekstra seperti enkripsi saat
perpindahan data atau pada saat penyimpanan, serta tindakan pencegahan khusus bila dibuka
dengan browser yang berbeda.

6.1 Pola Kerentanan

Penyerang biasanya tidak melakukan serangan langsung terhadap kriptografi. Mereka
melakukan serangan yang lain seperti mencuri kunci kriptografi, man in the middle attack,
atau mencuri data clear teks di dalam server.
Feld-field penting dan rahasia dalam database menggunakan enkripsi otomatis database,
namun terdapat kelemahan mendekripsi data ini secara otomatis ketika diambil, sehingga
SQL injection dapat mengambil data dalam bentuk teks.
Situs menggunakan SSL, namun tidak untuk semua halaman, kelemahan ini mengakibatkan
penyerang dapat memonitor lalu lintas jaringan, membajak dan dapat akses data pribadi
pengguna.
Database password menggunakan hash (hasil enkripsi dari sebuah password atau informasi
yang dianggap penting) untuk menyimpan password semua orang menjadi bentuk
chiphertext, sayangnya tools enkripsi yang dipakai sudah tidak up to date, akibatnya
penyerang dapat melakukan dekripsi ke bentuk informasi plaintext kembali.

6.2 Cara Mengecek Kerentanan

a. Apakah ada data clear text yang disimpan, bersamaan data backup?
b. Apakah ada pertukaran data dalam bentuk clear text?
c. Apakah ada algoritma kriptografi lemah yang digunakan?

6.3 Contoh Serangan

Sebuah aplikasi mengenkripsi nomor kartu kredit di dalam database, menggunakan enkripsi
otomatis yang berada dalam database. Namun, ini berarti mendekripsi data secara otomatis
ketika diambil, celah ini memungkinkan ada kelemahan sql injection untuk mengambil nomor
kartu kredit didalam bentuk teks.

6.4 Rekomendasi
a. Hindari password plain-text atau data sensitif lainnya dalam file konfigurasi.
b. Enkripsi menggunakan kunci publik,
c. Hanya mengizinkan aplikasi back-end untuk mendekripsi mereka dengan kunci pribadi.
d. Minimalkan paparan rahasia dalam memori.
e. Gunakan Internet Protocol Security (IPSec) atau SSL untuk mengirimkan informasi penting
karena menambah perlindungan terhadap kesengajaan penyadapan dan modifikasi
selama data in transit.

Page 16 of 22
7. Missing Function Level Access Control (A07)

Sebagian besar aplikasi web memverifikasi fungsi tingkat hak akses sebelum membuat fungsi
yang terlihat di user interface. Namun, aplikasi perlu melakukan pemeriksaan kontrol akses
yang sama pada server ketika masing-masing fungsi diakses. Jika permintaan tidak diverifikasi,
penyerang akan dapat memaksa permintaan untuk mengakses fungsi tanpa otorisasi yang
tepat.

7.1 Pola Kerentanan

Penyerang yang memiliki otorisasi kedalam sistem dapat mengubah URL atau parameter ke
fungsi-fungsi yang penting. Pengguna anonym dapat mengakses fungsi-fungsi private yang
tidak dilindungi.

7.2 Mengecek Kerentanan

a. Apakah User Interface menunjukan navigasi untuk fungsi yang tidak terotorisasi?
b. Apakah server sudah dilakukan otentikasi dan otorisasi?
c. Apakah pemeriksaan dari sisi server dilakukan hanya mengandalkan informasi yang diberikan
oleh penyerang?

7.3 Contoh Serangan

Penyerang langsung memasukan URL yang seharusnya memerlukan otentifikasi kedalam browser
seperti contoh

http://example.com/app/changepasswd.php

7.4 Rekomendasi
Aplikasi yang dikembangkan harus memiliki konsistensi dan kemudahan untuk menganalisis
modul otorisasi yang di panggil dari keseluruhan fungsi bisnis aplikasi tersebut. Biasanya
beberapa proteksi adalah seperti menyediakan satu atau lebih komponen eksternal kedalam
script.
a. Buatlah proses untuk mengatur hak akses dan pastikan pengembang dapat melakukan
update dan audit tersebut dengan mudah.
b. Secara default, mekanisme user pada aplikasi seharusnya dapat menolak seluruh akses
yang masuk, maka dari itu berikan hak akses yang jelas untuk setiap role yang khusus
diseluruh fungsi.
c. Jika suatu fungsi terlibat dalam proses, lakukan pengecekan untuk memastikan kondisi
fungsi tersebut mendapatkan akses yang tepat.

Page 17 of 22
8. Cross-Site Request Forgery (CSRF) (A08)

Suatu serangan CSRF memaksa browser korban yang sudah log-on untuk mengirim HTTP
request yang dipalsukan, termasuk di dalamnya session cookie korban dan informasi otentikasi
lain yang otomatis disertakan, ke suatu aplikasi web yang rentan. Hal ini memungkinkan
penyerang untuk memaksa browser korban menghasilkan request yang dianggap sah oleh
aplikasi rentan tadi.

8.1 Pola Kerentanan

Penyerang membuat permintaan HTTP palsu dan mengelabui korban untuk menyerahkannya
melalui tag gambar, XSS, atau teknik lain. Jika pengguna terotentikasi, maka serangan
dinyatakan sukses.
8.2 Contoh Kerentanan
Aplikasi membolehkan pengguna menyerahkan permintaan perubahan status yang tidak
menyertakan sesuatu yang bersifat rahasia. Sebagai contoh:

http://example.com/app/transferFunds?amount=1500 &destinationAccount=4673243243

Penyerang dapat membuat permintaan yang akan mentransfer uang dari akun korban ke
akunnya, dan memasukkan serangan ini dalam sebuah permintaan image yang disimpan di
site dalam kendali penyerang.

<img src="http://example.com/app/transferFunds? amount=1500 &destinationAccount=attackersAcct#“

width="0" height="0" />

Jika korban mengunjungi site tersebut ketika sudah terotentikasi ke example.com, maka
sembarang permintaan palsu akan menyertakan info sesi pengguna, dan mengotorisasi
permintaan.

8.3 Cara Mengecek Kerentanan Aplikasi

Cara termudah untuk memeriksa apakah sebuah aplikasi rentan adalah dengan melihat
apakah setiap link dan form berisi unpredictable token untuk setiap pengguna. Tanpa token
tersebut, penyerang dapat memalsukan permintaan berbahaya.

8.4 Rekomendasi
Pencegahan CSRF membutuhkan penyertaan unpredictable token dalam body atau URL
setiap permintaan HTTP. Token tersebut harus unik untuk setiap sesi pengguna, atau juga
untuk setiap permintaan.
a. Opsi yang bisa dipilih adalah menyertakan token unik dalam field tersembunyi. Hal ini
membuat nilai yang akan dikirim dalam permintaan HTTP, tidak terdapat di dalam
URL, yang rentan terekspos.
b. Token unik dapat juga disertakan dalam URL, atau parameter URL. Namun,
penempatan tersebut berisiko karena URL akan terlihat oleh penyerang.
c. Mewajibkan pengguna untuk me-otentikasi ulang. Misalkan menggunakan Captcha

Page 18 of 22
9. Using Components with Known Vulnerabilities (A09)

Komponen-komponen tambahan yang dipakai untuk kelengkapan dalam pembuatan program

aplikasi, mempunyai kerentanan yang dapat menimbulkan risiko di kemudian hari, mulai dari
yang sepele hingga malware canggih yang dirancang untuk mentargetkan organisasi tertentu.
Komponen hampir selalu dijalankan dengan hak istimewa penuh dalam aplikasi, sehingga
kekurangan dalam setiap komponen bisa berakibat serius.

9.1 Pola Kerentanan

Penyerang mengidentifikasi komponen yang lemah melalui scanning atau melalui analisis
manual terhadap aplikasi. Penyerang akan melakukan perubahan terhadap celah atau
kelemahan sesuai kebutuhan dan mengeksekusi serangan. Hal ini akan lebih sulit jika
komponen yang digunakan berada jauh didalam aplikasi. Akibat dari serangan tersebut
adalah memungkinkan terjadi injeksi, kontrol akses yang rusak (broken authentication), XSS,
dll.

9.2 Contoh Kerentanan

Berikut beberapa contoh komponen yang rentan:
1. Apache CXF Authentication Bypass.
Gagal untuk memberikan tanda identitas, penyerang bisa memanggil setiap layanan web
dengan izin penuh.
2. Spring Remote Code Execution.
Penyalahgunaan eksekusi di komponen Spring memungkinkan penyerang untuk
mengeksekusi kode sesuai dengan yang dikehendaki, akibatnya dapat mengambil alih
server secara penuh.
3. Trojan: VBS / Small.E adalah sebuah trojan yang masuk dalam sistem bersama dengan
malware lain. Fungsi utamanya adalah untuk memulai mekanisme propaganda untuk
Worm: VBS / Agent.B.
Perintah pertama yang di jalankan virus ini, menambahkan paket perintah kedalam register
windows bagian "autorun.reg" yang mana ini merupakan lokasi dari file virus. Kemudian virus
mengirim isi dari "autorun.bin", yang lokasinya sama dengan direktori file virus, atau dalam
windows system direktori pada file "autorun.txt" yang lokasinya juga ada dalam root direktori
.\autorun.bin
%WinDir%\system32\autorun.bin
c:\autorun.txt
Bila tidak ada baris perintah dalam file direktori virus, atau direktori system windows, maka virus
akan mencari file yang bernama "autorun.vbs", jika file ini ditemukan dan di jalankan maka virus
akan mulai menyebar.
.\autorun.vbs
%Win
Dir%\system32\autorun.

Sebagian besar komponen tidak membuat patch kerentanan untuk versi lama, tetapi hanya
memperbaiki masalah dalam versi berikutnya. Maka sangat penting untuk melakukan update
ke versi yang terbaru.

Page 19 of 22
9.3 Rekomendasi
a. Identifikasi semua komponen dan versi yang digunakan, termasuk semua dependensi.
(misalnya, versi plugin)
b. Memantau keamanan komponen ini dalam database publik, milis proyek, dan milis
keamanan, dan menjaga agar tetap up to date.
c. Menetapkan kebijakan keamanan yang mengatur penggunaan komponen, untuk
pengembangan perangkat lunak tertentu, melewati tes keamanan, dan lisensi.
d. Apabila diperlukan, pertimbangkan untuk menambahkan fungsi keamanan.
e. Uninstall dan remove template, component, module, plugins dan extenstion yang tidak
digunakan
f. Jangan gunakan software bajakan atau trial, biasanya software tersebut telah disusupi
oleh kode jahat yang bisa digunakan untuk hack web dan server Anda.
g. Hapus file dan folder yang tidak dikenal di hosting. Anda bisa bandingkan file dan folder
tersebut dengan software yang asli atau dengan backup.
h. Pastikan permission (hak akses) file adalah 644 dan untuk folder adalah 755 (os linux)
i. Permission File config yang berisi informasi username dan password db (contoh :
configuration.php di Joomla, wp-config.php di WordPress) di set menjadi 444 (os linux)
j. Proteksi folder admin anda dengan password (Password Protect Directories) Tambahkan
rule ke robot.txt dan .htaccess supaya search engine tidak bisa mengakses ke direktori
admin atau direktori yang tidak diinginkan.

Page 20 of 22
10. Un-validated Redirects and Forwards (A10)

Aplikasi web seringkali mengarahkan (redirect) dan meneruskan (forward) pengguna ke

halaman dan website lain, dan mengunakan data yang tidak dapat dipercaya untuk
menentukan halaman tujuan. Tanpa validasi yang tepat, penyerang dapat mengarahkan
korban ke situs phishing atau malware, atau menggunakan forward untuk mengakses
halaman yang tidak terotorisasi.

10.1 Pola Kerentanan

Penyerang mengarahkan ke link yang seakan-akan tervalidasi dan mengelabui korban untuk
mengkliknya, sebab link tersebut bukan merupakan situs yang valid. Penyerang meneruskan
ke link yang tidak aman untuk mem-bypass pemeriksaan keamanan. Dampak dari serangan
tersebut adalah dapat menginstalasi malware atau mengelabui korban untuk membuka
password atau informasi sensitif lainnya. Penerusan yang tidak aman dapat memungkinkan
bypass kendali akses.

10.2 Contoh Kerentanan

Contoh 1:
Aplikasi memiliki halaman “redirect.jsp” yang menerima parameter tunggal bernama
“url”. Penyerang membuat URL berbahaya yang mengarahkan pengguna mengakses situs
yang melakukan phishing dan menginstalasi malware.

http://www.example.com/redirect.jsp?url=evil.com

Contoh 2:
Aplikasi menggunakan penerusan untuk membuat rute request antar bagian yang
berbeda dari suatu situs. Untuk memfasilitasi hal ini, beberapa halaman menggunakan
parameter untuk mengindikasikan ke mana pengguna harus dikirim jika transaksi
berhasil. Dalam kasus ini, penyerang membuat URL yang akan melewati pemeriksaan
kendali akses aplikasi dan kemudian meneruskan penyerang ke suatu fungsi administratif
yang tidak dapat diaksesnya dalam kondisi normal.

http://www.example.com/boring.jsp?fwd=admin.jsp

10.3 Cara Mengecek Kerentanan Aplikasi

Cara terbaik untuk mengetahui apakah suatu aplikasi mengandung redirect atau forward
yang tidak divalidasi sebagai berikut:
a. Mereview kode untuk semua redirect atau forward. Untuk setiap penggunaan,
identifikasi jika target URL disertakan dalam setiap nilai parameter. Jika demikian,
pastikan parameter divalidasi agar hanya berisi tujuan yang diperbolehkan untuk
diakses.
b. Telusuri situs untuk melihat apakah situs tersebut menghasilkan berbagai redirect
(HTTP response codes 300-307, biasanya 302). Lihat parameter yang diberikan sebelum
redirect untuk mengetahui apakah situs tersebut muncul sebagai target URL atau

Page 21 of 22
 bagian dari URL. Jika demikian, ubah URL target dan cek apakah situs tersebut mengarah
ke target baru atau tidak.

10.4 Rekomendasi
Semaksimal mungkin hindari penggunaan redirects dan forwards.
a. Jika digunakan, jangan tampilkan parameter pengguna dalam URL tujuan.
b. Jika parameter tujuan tidak dapat dihindari, pastikan nilai yang diberikan valid dan
terotorisasi untuk pengguna.
c. Direkomendasikan agar setiap parameter tujuan berupa nilai pemetaan, URL aktual
atau bagian dari URL, dan kode di sisi server menerjemahkan pemetaan ini ke URL
target.
d. Aplikasi dapat menggunakan ESAPI untuk meng-override metode sendRedirect() untuk
memastikan semua tujuan redirects aman. Kelemahan semacam ini sangatlah penting
untuk dihindari karena merupakan target favorit pelaku phishing untuk memperoleh
kepercayaan pengguna.

Page 22 of 22