Teks kaya anda boleh menjadi kelemahan skrip merentas tapak

Kenal pasti dan kurangkan kelemahan SXSS sebelum ia dieksploitasi

Oleh Luke Harrison

Artikel ini pada asalnya diterbitkan di IBM Developer.

Banyak aplikasi semasa perlu memaparkan teks kaya dalam HTML di tapak web mereka. Untuk menjana teks berformat ini daripada input pengguna, pembangun menggunakan komponen editor teks kaya. Masalahnya? Fungsi ini secara tidak langsung boleh membuka kedua-dua aplikasi dan data anda kepada kelemahan yang dikenali sebagai skrip rentas tapak tersimpan (SXSS).

Dalam artikel ini, anda akan mempelajari apa itu kerentanan SXSS dan menyemak beberapa "bau kod" yang boleh anda gunakan untuk menyemak sama ada aplikasi anda terjejas. Anda juga akan melihat contoh aplikasi yang terdedah dan mempelajari strategi pemulihan untuk kelemahan ini.

Apakah skrip rentas tapak yang disimpan?

Skrip rentas tapak yang disimpan ialah sejenis kerentanan yang boleh dieksploitasi oleh penyerang untuk menyuntik kod hasad ke dalam pangkalan data. Kod itu kemudiannya berjalan pada penyemak imbas mangsa selepas diambil dan diberikan oleh rangka kerja bahagian hadapan.

Kerentanan ini amat berbahaya kerana ia boleh membolehkan penyerang mencuri kuki, mencetuskan ubah hala atau menjalankan pelbagai skrip berbahaya dalam penyemak imbas mangsa. Ia memerlukan sedikit usaha di pihak penyerang untuk menyebarkan eksploitasi: mangsa tidak perlu mengklik pada pautan berniat jahat atau jatuh untuk skim pancingan data, mereka hanya menggunakan tapak dipercayai yang terjejas oleh SXSS. Semak pautan di bahagian bawah halaman untuk mendapatkan butiran lanjut tentang kelemahan skrip merentas tapak.

Bau kod: innerHTML dan dangerouslySetInnerHTML

bau kod hanyalah satu ciri dalam kod yang menunjukkan masalah yang lebih mendalam. Biasanya penyemak imbas tidak akan menjalankan skrip yang disuntik secara automatik, tetapi jika devoloper menggunakan beberapa API penyemak imbas atau sifat elemen yang berpotensi berbahaya, ia boleh membawa kepada situasi di mana skrip do dijalankan.

Sila lihat coretan kod berikut:

const someHTML = “<h1>Hello world</h1>“

const output = document.getElementById("rich-text-output");

output.innerHTML = someHTML

Dalam contoh ini, kami menyimpan beberapa HTML dalam pembolehubah, mengambil elemen daripada DOM dan menetapkan sifat HTML dalaman elemen itu kepada kandungan yang disimpan dalam pembolehubah. Sifat innerHTML boleh digunakan untuk memaparkan HTML daripada rentetan di dalam elemen HTML lain.

Apa yang berbahaya tentang sifat ini ialah ia akan memaparkan mana-mana HTML atau JavaScript yang anda masukkan ke dalamnya. Ini bermakna jika seseorang dapat mengawal data yang dihantar ke dalam harta itu, mereka secara teknikal boleh menjalankan sebarang JavaScript dalam penyemak imbas pengguna.

Satu lagi cara popular tetapi berbahaya untuk memaparkan HTML dinamik dalam penyemak imbas adalah dengan menggunakan sifat komponen dangerouslySetInnerHTML React. Sifat ini berkelakuan sama seperti sifat innerHTML dalam JavaScript dan HTML vanila.

Contoh berikut muncul dalam dokumen React:

const someHTML = “<h1>Hello world</h1>“

const output = document.getElementById("rich-text-output");

output.innerHTML = someHTML

Jika anda sedang menggunakan salah satu daripada sifat ini dalam aplikasi web bahagian hadapan, ada kemungkinan besar anda mempunyai beberapa jenis kerentanan skrip merentas tapak. Kami akan melihat cara sifat ini boleh dieksploitasi dan beberapa langkah yang boleh anda ambil untuk menyelesaikan isu ini kemudian dalam artikel ini.

Bau kod: Penyunting teks kaya

Satu lagi tanda bahawa aplikasi anda mungkin terdedah kepada SXSS ialah sama ada anda menggunakan editor teks kaya atau tidak, seperti TinyMCE atau CKEditor.

Kebanyakan editor teks kaya berfungsi dengan menukar teks berformat yang dijana oleh pengguna kepada HTML. Sebagai langkah keselamatan tambahan, kebanyakan editor ini menggunakan beberapa bentuk sanitasi untuk mengalih keluar JavaScript yang berpotensi berniat jahat daripada input mereka. Walau bagaimanapun, Jika anda tidak menggunakan teknik sanitasi yang sama ini pada perkhidmatan yang menerima dan menyimpan kandungan teks kaya, maka anda berkemungkinan menjadikan aplikasi anda terdedah kepada SXSS.

Walaupun anda tidak memaparkan kandungan di tapak anda sendiri, terdapat kemungkinan besar data ini boleh digunakan oleh aplikasi yang membuat dipaparkan. Untuk mereka bentuk aplikasi selamat, amat penting anda mempertimbangkan pengguna semasa dan akan datang bagi data anda. Jika data anda dipengaruhi oleh SXSS maka begitu juga semua aplikasi yang menggunakan data anda.

Contoh aplikasi dengan kerentanan SXSS

Mari kita lihat contoh kecil aplikasi web dengan kerentanan SXSS dan kemudian cuba mengeksploitasinya.

Untuk menjalankan aplikasi ini, mula-mula mengklon repo apl demo ini dan ikut arahan "Menjalankan aplikasi" dalam fail readme.md.

Selepas menjalankan aplikasi dan pergi ke http://localhost:3000/unsanitized.html, anda sepatutnya melihat halaman yang kelihatan seperti ini:

Aplikasi ini hanya mengambil beberapa input teks kaya daripada pengguna, menyimpannya pada pelayan web, dan kemudian memaparkannya dalam bahagian berlabel Output.

Sebelum kami mengeksploitasi kelemahan SXSS, luangkan masa untuk melihat aplikasi itu. Rujuk kepada bau kod yang disebutkan di atas dan imbas kod untuk melihat sama ada anda dapat melihat bahagian yang menyusahkan. Cuba buka tab rangkaian dalam penyemak imbas anda dan lihat permintaan yang dihantar apabila anda memasukkan dan menyerahkan beberapa teks kaya.

Dalam fail unsanitzed.html, anda akan melihat fungsi berikut, bernama renderPostByID:

const someHTML = “<h1>Hello world</h1>“

const output = document.getElementById("rich-text-output");

output.innerHTML = someHTML

Lihat fungsi ini dengan teliti. Anda akan perasan bahawa kami menggunakan sifat innerHTML yang dinyatakan untuk memaparkan beberapa teks kaya yang kami ambil daripada API dalam bentuk HTML.

Sekarang kita melihat bahagian kod yang terdedah, mari kita mengeksploitasinya. Kami akan memintas input editor teks kaya dan menekan titik akhir API yang menyimpan siaran ke pelayan web secara langsung. Untuk melakukan ini, anda boleh menggunakan arahan cURL berikut:

function createMarkup() {

  return {__html: 'First · Second'};

}

function MyComponent() {

  return <div dangerouslySetInnerHTML={createMarkup()} />;

}

Perhatikan muatan data yang kami hantar dalam permintaan. Ini ialah beberapa HTML yang direka bentuk secara berniat jahat yang termasuk teg imej dengan sifat onerror yang ditetapkan kepada beberapa JavaScript yang memaparkan dialog makluman. Penyerang akan menggunakan helah seperti ini untuk mengelakkan kaedah sanitasi yang dilaksanakan dengan buruk yang bertujuan untuk menanggalkan JavaScript daripada elemen HTML sebelum ia disimpan dalam pangkalan data.

Selepas menjalankan skrip di atas, anda akan menerima ID pos seperti berikut:

const renderPostByID = async (id) => {
    // setting url seach params
    let newURL = window.location.protocol + "//" + window.location.host + window.location.pathname + `?post=${id}`;
    window.history.pushState({ path: newURL }, "", newURL);

    // getting rich text by post id
    let response = await fetch(`/unsanitized/${id}`, { method: "GET" });
    let responseJSON = await response.json();
    console.log(responseJSON);

    // rendering rich text
    output.innerHTML = responseJSON.richText;
};

Tampal ID siaran ini ke dalam parameter pertanyaan URL siaran dan tekan Enter.

Apabila anda melakukan ini, anda akan melihat dialog makluman pada skrin anda yang mengesahkan tapak itu sememangnya terdedah kepada SXSS.

Bagaimana untuk mengelakkan SXSS

Sekarang kita telah melihat cara mengeksploitasi kelemahan SXSS, mari kita lihat bagaimana kita boleh membetulkan satu. Untuk melakukan ini, anda perlu membersihkan teks kaya berasaskan HTML di tiga tempat berbeza:

1. Sebelah pelayan, sebelum kandungan disimpan dalam pangkalan data anda.
2. Sebelah pelayan, apabila kandungan diambil daripada pangkalan data anda.
3. Pihak pelanggan, apabila kandungan dipaparkan oleh penyemak imbas.

Mungkin jelas mengapa anda ingin membersihkan kandungan sebelum menyimpannya dalam pangkalan data dan apabila memaparkannya di sisi pelanggan, tetapi mengapa membersihkannya apabila mendapatkannya semula? Baiklah, mari bayangkan seseorang memperoleh keistimewaan yang diperlukan untuk memasukkan kandungan terus ke dalam pangkalan data anda. Mereka kini boleh terus memasukkan beberapa HTML yang direka dengan berniat jahat, memintas sepenuhnya pembersih awal. Jika pengguna salah satu API anda tidak turut melaksanakan sanitasi ini pada pihak pelanggan, mereka boleh menjadi mangsa eksploitasi skrip merentas tapak.

Namun, perlu diingat, menambahkan sanitasi pada ketiga-tiga lokasi boleh menyebabkan kemerosotan prestasi, jadi anda perlu memutuskan sendiri jika anda memerlukan tahap keselamatan ini. Sekurang-kurangnya, anda harus membersihkan mana-mana data di sisi pelanggan sebelum memaparkan kandungan HTML dinamik.

Mari kita lihat cara kami melaksanakan sanitasi dalam versi selamat aplikasi mudah terjejas kami. Memandangkan aplikasi ini ditulis terutamanya menggunakan JavaScript, kami menggunakan perpustakaan dompurify untuk bahagian klien dan perpustakaan isomorphic-dompurify untuk sanitasi bahagian pelayan. Dalam program app.js yang bertindak sebagai pelayan web kami, anda akan menemui titik akhir ekspres /disanatkan dengan pelaksanaan GET dan POST:

const someHTML = “<h1>Hello world</h1>“

const output = document.getElementById("rich-text-output");

output.innerHTML = someHTML

Dalam pelaksanaan POST, kami mula-mula mendapatkan teks kaya daripada kandungan permintaan dan kemudian memanggil kaedah sanitasi perpustakaan isomorphic-dompurify sebelum menyimpannya dalam objek data kami. Begitu juga, dalam Pelaksanaan GET, kami memanggil kaedah yang sama pada teks kaya selepas mendapatkannya daripada objek data kami dan sebelum menghantarnya kepada pengguna kami.

Di sisi pelanggan, kami sekali lagi menggunakan kaedah yang sama sebelum menetapkan sifat innerHTML div output kami dalam sanitized.html.

function createMarkup() {

  return {__html: 'First · Second'};

}

function MyComponent() {

  return <div dangerouslySetInnerHTML={createMarkup()} />;

}

Sekarang anda telah melihat cara kami membersihkan HTML dengan betul untuk menghalang skrip merentas tapak, kembali ke eksploitasi asal untuk aplikasi ini dan jalankannya semula, kali ini menggunakan titik akhir yang telah dibersihkan. Anda seharusnya tidak lagi melihat pop timbul dialog amaran, kerana kami kini menggunakan teknik yang betul untuk menghalang kerentanan SXSS.

Untuk panduan penuh SXSS, termasuk amalan terbaik dan teknik lain untuk mencegah XSS, lihat helaian panduan Skrip Silang Tapak OWASP.

Ringkasan dan langkah seterusnya

Dalam artikel ini, kami telah melihat cara anda boleh meningkatkan postur keselamatan aplikasi anda dengan menghalang skrip merentas tapak yang disimpan, jenis kerentanan aplikasi web yang biasa. Anda kini sepatutnya dapat mengenali sama ada aplikasi anda sendiri terdedah, ciri yang perlu anda semak dan cara mengurangkan sebelum pelakon berniat jahat boleh mengeksploitasi kelemahan tersebut.

Keselamatan adalah yang terpenting bagi pembangun perusahaan. Gunakan sumber berikut untuk terus membina kesedaran anda tentang kemungkinan kelemahan dan cara anda boleh meningkatkan postur keselamatan anda.

• Pembangun IBM: Hab keselamatan
• Gambaran keseluruhan Skrip Rentas Tapak OWASP
• Video: Skrip Merentas Tapak — Ancaman 25 Tahun Yang Masih Berterusan

Atas ialah kandungan terperinci Teks kaya anda boleh menjadi kelemahan skrip merentas tapak. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!