Mencegah XSS di ASP.NET

Indonesian (Bahasa Indonesia) translation by Yudha Zubair (you can also view the original English article)

Banyak masalah keamanan situs web karena terlalu mempercayai pengguna. Sebagian besar pengguna aplikasi web Anda hanya akan melakukan apa yang perlu mereka lakukan, pengguna yang ingin tahu atau jahat sering ingin mendorong tepi akses. Di tepi itu, lubang keamanan sering muncul di aplikasi Anda. Saya telah menulis tentang mencegah dua jenis kerentanan umum, SQL Injection dan Cross Site Request Forgery, di aplikasi ASP.NET sebelumnya. Artikel ini membahas cara mencegah Cross Site Scripting, jenis kerentanan umum ketiga di situs web.

Sementara kerangka kerja modern melakukan banyak hal untuk membuat serangan ini lebih sulit, saya percaya kita harus terlebih dahulu memiliki pemahaman tentang cara aplikasi rentan terhadap serangan. Pertama, mari kita lihat apa itu Cross Site Scripting dan bagaimana hal itu dapat dieksploitasi.

Apa Itu Cross Site Scripting

Cross Site Scripting (sering disingkat XSS) memungkinkan injeksi skrip berbahaya ke situs web yang dipercaya. Injeksi ini terjadi tanpa sepengetahuan pengguna. Script yang disuntikkan dijalankan seolah-olah itu berasal dari situs web asli. Dengan demikian skrip berbahaya dapat mengakses sumber daya apa pun dari situs web yang dihosting yang dapat diakses oleh pengguna, seperti cookie atau token sesi.

Pembukaan untuk serangan cross site scripting muncul ketika aplikasi web menampilkan input dari pengguna atau sumber daya luar tanpa memvalidasi atau menyandikannya dengan benar. Pada sebagian besar serangan cross site scripting, penyerang berupaya menyuntikkan JavaScript ke halaman web server tepercaya. Penyerang juga dapat mencoba menyuntikkan HTML, Flash, atau apa pun yang dijalankan oleh browser. Apapun skripnya, tujuannya tetap untuk membuat browser mengeksekusi kode pilihan penyerang.

Serangan XSS yang Bertahan

Ada tiga kategori serangan cross site scripting, dibagi dengan metode injeksi dan metode pencegahan serangan. Dalam jenis serangan pertama, skrip disimpan secara permanen di server target dan dengan demikian disebut serangan cross site scripting tetap. Serangan ini mencoba menyematkan skrip berbahaya ke dalam sesuatu seperti pos forum yang disimpan dalam database atau bidang yang tampaknya jinak seperti halaman beranda pengguna basis data. Dengan skrip tetap ada, setiap pengunjung ke situs yang melihat kiriman, pesan, atau item yang dikompromikan, menjadi calon korban serangan.

Penyerang mencoba jenis serangan ini umumnya menargetkan bidang komentar, forum, media sosial dan bidang lainnya di mana input pengguna akhir agak semaunya diharapkan dan merupakan bagian normal dari aplikasi. Penyerang dapat memasukkan skrip dalam posting forum di bagian percakapan yang valid. Setiap kali seseorang melihat posting, skrip akan dieksekusi.

Serangan XSS yang Tercermin

Dalam jenis kedua serangan cross site scripting, yang dikenal sebagai cross site scripting tercermin, penyerang mengirimkan script yang disuntikkan ke situs rentan sehingga akan segera dikembalikan kembali ke pengguna. Metode umum melakukan ini, halaman target di mana input pengguna menjadi bagian dari output halaman. Halaman pencarian dapat menampilkan istilah pencarian kepada pengguna dan dapat menyediakan outlet untuk serangan ini. Skrip yang disuntikkan pada input pengguna tidak boleh disimpan oleh aplikasi web.

Serangan Berbasis DOM

Serangan cross site scripting ketiga sepenuhnya terjadi di browser. Fungsi serangan dengan memanipulasi model internal halaman web dalam browser yang dikenal sebagai DOM dan disebut sebagai serangan berbasis DOM. Ini lagi, memungkinkan penyerang untuk mengeksekusi kode berbahaya, tetapi kode yang dikembalikan oleh server dimanipulasi menjadi JavaScript yang dapat dieksekusi oleh halaman web.

Pada akhirnya, serangan cross site scripting adalah cross site scripting , tidak peduli bagaimana itu disampaikan. Karena kode yang disuntikkan berasal dari server yang tepercaya, maka kode itu seringkali dapat dijalankan di bawah izin situs. Karena itu dapat bertindak seolah-olah itu kode asli di situs web.

Serangan cross site scripting berhasil dapat memungkinkan akses ke cookie pada halaman web. Cookie ini dapat berisi informasi sensitif termasuk pengidentifikasi sesi yang akan memungkinkan penyerang untuk menyamar sebagai pengguna yang diserang. Serangan itu juga dapat mengubah konten HTML pada halaman untuk menampilkan formulir login palsu dan mencuri kredensial login pengguna. Penyerang dapat memeriksa dan mengirim konten halaman apa pun yang memungkinkan penangkapan informasi sensitif seperti nomor akun. Akibatnya, serangan yang lebih lanjut dapat menginstal key logger yang mengirimkan informasi apa pun yang dimasukkan ke laman web ke penyerang.

Melindungi Dari Serangan Cross Site Scripting

Mengurangi cross site scripting tidak perlu mempercayai input dari pengguna atau sumber eksternal lainnya. Aplikasi web harus memperlakukan data ini sebagai berpotensi berbahaya, apa pun sumbernya. Mari kita lihat beberapa metode khusus untuk ASP.NET untuk mencegah serangan ini menggunakan komponen yang dibangun ke dalam kerangka kerja dan perpustakaan yang tersedia secara bebas.

Memvalidasi semua masukan

Aplikasi web harus memvalidasi input apa pun ke aplikasi sebelum digunakan. Sama seperti serangan injeksi lainnya seperti SQL Injection. Aplikasi sebaiknya memvalidasi input ini terhadap white list nilai yang dapat diterima. Validasi menghapus atau mengganti komponen input yang tidak diharapkan dengan nilai yang disandikan. Metode black list, yang hanya menghilangkan daftar karakter yang tidak diinginkan yang diketahui, dapat digunakan, tetapi lebih rentan terhadap metode serangan baru.

Jika kami tahu suatu nilai harus selalu berupa bilangan integer, maka Anda dapat memvalidasi input menggunakan kode seperti:

1	int memberId;
2	if (!int.TryParse(externalValue, out memberId)) {
3	return RedirectToAction("InputError");
4	}

Jika kerangka kerja tidak dapat menguraikan externalValue yang sebelumnya diambil sebagai integer, kode mengarahkan ke halaman yang akan menampilkan kesalahan. Kalau tidak, kita tahu bahwa memberId berisi nilai integer. Proses ini juga bekerja dengan tipe dasar lainnya. Beberapa tipe yang lebih umum juga menyediakan metode untuk memvalidasi informasi. Kelas .NET Uri berisi metode IsWellFormedUriString yang dapat memvalidasi URL. Ini akan memungkinkan validasi bahwa entri beranda pengguna berisi URL yang valid sebelum ditampilkan.

var userHomePage = userRecord["homepage"];
if (!Uri.IsWellFormedUriString(newUrl, UriKind.Absolute))
{
  Model.homepage = "none";
}
else
{
  Model.homepage = Html.Encode(userHomePage);
}

Tipe data lain yang lebih kompleks membutuhkan validasi yang lebih kompleks. Validasi bidang nomor kartu kredit dapat menghapus karakter apa pun dalam string yang bukan digit. Validasi string yang lebih kompleks dapat membutuhkan regular expressions. Validasi suatu kelas mungkin perlu pemeriksaan yang lebih kompleks juga.

ASP.NET Validasi Permintaan

ASP.NET memberikan perlindungan efektif terhadap serangan yang direfleksikan menggunakan validasi permintaan. Jika ASP.NET mendeteksi markup atau kode dalam permintaan, itu melempar exception "potentially dangerous value was detected" dan menghentikan pemrosesan permintaan.

Meskipun berharga, ada saatnya Anda perlu mengizinkan nilai-nilai ini dalam permintaan. Contoh umum datang dengan mengizinkan input teks dalam formulir. Dalam kasus ini, sayangnya, validasi permintaan terlalu sering dimatikan untuk seluruh situs. Solusi yang lebih baik mematikan validasi ini hanya jika diperlukan. Dalam versi ASP.NET yang lebih lama, menambahkan validateRequest="false" ke directif Page di Webforms akan mematikan validasi untuk sebuah halaman. Di ASP.NET MVC, menambahkan atribut [ValidateInput (false)] ke controller action mematikan validasi untuk tindakan itu, sementara menambahkan atribut [AllowHtml] mematikan validasi untuk bidang.

ASP.NET 4.0 mengubah validasi permintaan dalam beberapa cara. Versi kerangka ini dan yang lebih baru melakukan validasi di awal permintaan HTTP. Validasi juga berlaku untuk semua permintaan ASP.NET dan bukan hanya permintaan halaman .aspx. Ini termasuk modul HTTP kustom juga. Halaman yang mengandalkan perilaku asli dapat kembali ke metode yang lebih lama dengan mengatur atribut requestValidationMode di file web.config ke versi 2.0.

1	<httpRuntime requestValidationMode="2.0" />

Lebih baik lagi, adalah menonaktifkan ini hanya untuk halaman di mana diperlukan, menggunakan sintaks di file web.config:

<location path="novalidationpage.aspx">
  <system.web>
    <httpRuntime requestValidationMode="2.0" />
  </system.web>
</location>

ASP.NET 4.5 menambahkan kemampuan untuk menunda validasi hingga meminta data. Mengatur atribut requestValidationMode di file web.config Anda ke versi 4.5 mengaktifkan perilaku baru ini.

1	<httpRuntime requestValidationMode="4.5" />

ASP.NET 4.5 juga menambahkan properti HttpRequest.Unvalidated. Menggunakan properti ini memungkinkan akses yang lebih mudah ke nilai formulir yang tidak divalidasi jika diperlukan. Dengan menggabungkan validasi yang tertunda dan properti Unvalidated, Anda dapat mengakses nilai yang tidak divalidasi saat dibutuhkan, tetapi melindungi input formulir lainnya.

Pengkodean HTML

Sebelum menampilkan data luar pada halaman web, HTML Anda harus disandikan sehingga tidak diproses oleh browser. Sebagai contoh, ambil halaman ASP.NET yang ditulis sehingga sebuah pesan dapat dikirimkan untuk ditampilkan, seperti pembaruan status. Aplikasi dapat menggunakan halaman ini untuk menunjukkan kepada pengguna bahwa akun mereka telah dibuat tanpa kesalahan. URL untuk halaman ini biasanya akan terlihat mirip dengan https://appname/placeorder/Account+Created. Halaman yang dihasilkan menunjukkan pesan kepada pengguna dengan bidang, seperti:

1	<%= Html.Label("Message", Model.message) %>

... dan menampilkan sebagai:

Jika kami mengubah URL panggilan untuk http:/appname/placeorder/<script>alert('hello!');</script> , kita sekarang mendapatkan sesuatu yang berbeda.

Skripnya bisa apa saja dan bukan hanya kotak peringatan yang tidak berbahaya yang muncul di sini. Validasi Permintaan akan menangkap contoh-contoh di atas dan mengembalikan exception sebelum ditampilkan. Jika dimatikan, maka penyandian output mencegah serangan.

ASP.NET memudahkan untuk menyandikan data untuk mencegah serangan. Versi awal MVC menggunakan sintaks Webform sering mengandung kode seperti ini yang tidak menyandikan HTML.

1	<p id="status"><%= status ></p>

Anda harus secara manual menyandikan output sehingga HTML apa pun akan dikonversi menjadi format tampilan. Jadi < menjadi karakter string <. Fungsi Html.Encode menyediakan konversi ini. Bentuk kode yang lebih aman menjadi:

1	<p id="status"><%= Html.Encode(status) ></p>

ASP.NET MVC kemudian memperkenalkan sintaks untuk melakukan ini dalam satu langkah dengan mengganti <= dengan <: sehingga kode dapat disingkat menjadi:

1	<p id="status"><%: status ></p>

Menggunakan Razor view engine, semua output dikodekan HTML kecuali Anda secara khusus menggunakan metode untuk tidak menyandikannya. Dalam Razor, kode yang setara dengan yang di atas menjadi:

1	<p id="status">@status</p>

Razor secara otomatis menangani penyandian HTML apa pun yang berisi status string. Dalam kasus di mana Anda perlu merender data mentah, Anda dapat menggunakan metode HTML.Raw(). Untuk menampilkan hasil tanpa pengkodean, kita dapat menggunakan:

1	<p id="status">@Html.Raw(status)</p>

Dalam contoh ini, kode di atas akan membuat aplikasi kita rentan lagi. Jadi, ada beberapa keadaan di mana Anda tidak harus menyandikan output. Jika Anda menonaktifkan fitur ini di bidang, Anda harus berhati-hati untuk memastikan data dibersihkan sebelum ditampilkan. Untungnya, ada perpustakaan yang membantu dengan ini, sementara juga melakukan lebih banyak untuk melindungi aplikasi Anda dari cross site scripting.

Perpustakaan AntiXSS

Jika Anda menulis aplikasi ASP.NET, Anda harus menggunakan Perpustakaan AntiXSS untuk ASP.NET. Dari situs web proyek, "AntiXSS menyediakan segudang fungsi pengodean untuk input pengguna, termasuk HTML, atribut HTML, XML, CSS dan JavaScript."

Perpustakaan berisi metode yang difokuskan untuk membersihkan data luar berdasarkan tujuan penggunaan data itu. Metode ini menggunakan pendekatan berbasis white list yang disukai. Ini berarti bahwa data yang disandikan, dimaksudkan untuk atribut HTML, dapat disanitasi agar hanya berisi data yang valid untuk atribut HTML. Metode ASP.NET HtmlEncode tradisional menggunakan pendekatan black list yang hanya menyandikan karakter tertentu yang berpotensi berbahaya.

Microsoft mulai memasukkan rutinitas inti dari pustaka ini ke dalam ASP.NET 4.5 di namespace System.Web.Security.AntiXss yang baru. Anda juga dapat mengatur kerangka kerja untuk menggunakan metode AntiXSS ini sebagai pengganti rutin pengkodean bawaan. Anda melakukan ini dengan mengatur atribut encoderType dari httpRuntime di file web.config untuk aplikasi:

1	<httpRuntime ... encoderType="System.Web.Security.AntiXss.AntiXssEncoder,System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Jika aplikasi Anda menampilkan data luar secara signifikan, maka penggunaan AntiXSS akan banyak membantu melindungi aplikasi Anda dari cross site scripting. Jika menggunakan ASP.NET 4.5, maka mengubah aplikasi Anda untuk menggunakan metode AntiXSS baru untuk penyandian default bahkan memberikan perlindungan lebih untuk aplikasi web Anda.

Dalam ringkasan

Mencegah cross site scripting daripada yang tampak pada awalnya. OWASP mencantumkan lebih dari 80 vektor yang dapat ditargetkan menggunakan serangan cross site scripting. Organisasi itu juga mendaftar kerentanan ini sebagai yang ketiga dalam daftar sepuluh kerentanan web teratas pada 2013.

Jika Anda tidak memastikan bahwa semua data luar yang dimasukkan ke dalam aplikasi Anda lolos dengan benar atau tidak memvalidasi input sebelum menempatkannya pada halaman output, Anda membuat aplikasi web Anda rentan terhadap cross site scripting. Di ASP.NET, ini dapat dilakukan dengan:

Memvalidasi semua input eksternal ke aplikasi Anda sebelum ditampilkan pada halaman web.
Gunakan Validasi Permintaan di mana pun bahwa aplikasi Anda tidak perlu mematikannya secara khusus, seperti formulir yang memungkinkan input HTML. Jika Anda harus mengizinkan informasi yang tidak divalidasi, tinggalkan validasi di tempat lain di aplikasi Anda.
Sandikan HTML sebelum menampilkan data eksternal pada halaman web
Gunakan metode berbasis AntiXSS yang termasuk dalam ASP.NET 4.5 dan gunakan perpustakaan AntiXSS untuk versi ASP.NET yang lebih lama.