Keselamatan Aplikasi Satu Halaman (SPA) Tidak Berfungsi Sama seperti Laman Web

Aplikasi satu halaman (SPA) dengan cepat mendapat kedudukan yang lebih kukuh sebagai antara muka yang mudah dibangunkan untuk penghantaran data digital dan penglibatan pelanggan.

Aplikasi satu halaman (SPA) menjadi semakin popular kerana kemudahan pembangunan dan keupayaan untuk menyediakan pengalaman pengguna yang menarik. Walau bagaimanapun, SPA juga datang dengan cabaran keselamatan yang unik. Dalam artikel ini, kami akan meneroka kesukaran mendapatkan SPA dan membincangkan penyelesaian yang menjanjikan yang dikenali sebagai corak pengendali token.

Tapak web tradisional mempunyai satu bahagian belakang yang menyajikan HTML dan data. Pengesahan pengguna biasanya berlaku pada pelayan bahagian belakang ini, yang dilindungi oleh tembok api rangkaian. Walau bagaimanapun, SPA disambungkan kepada berbilang perkhidmatan mikro melalui API, yang mewujudkan seni bina yang lebih terpencar. Walaupun persediaan ini memberikan kelebihan ringan kepada SPA, ia juga memperkenalkan risiko keselamatan yang ketara.

Salah satu cabaran utama ialah pengesahan pengguna mesti selalu berlaku dalam penyemak imbas dan bukannya berlaku dalam pelayan yang dilindungi di belakang tembok api rangkaian. Ini menjadikan SPA terdedah kepada pelbagai jenis serangan siber, seperti kecurian bukti kelayakan skrip silang tapak (XSS). Dalam kaedah serangan ini, pelaku berniat jahat boleh menyuntik kod ke dalam penyemak imbas yang mampu mencuri token akses dan bukti kelayakan pengguna, akhirnya memberikan mereka akses tanpa kebenaran kepada data dan sistem berharga.

Satu lagi cabaran timbul daripada bilangan kebergantungan yang besar pada data pihak ketiga yang biasanya disambungkan dengan API kepada aplikasi. Jumlah sambungan pihak ketiga yang tinggi boleh menimbulkan masalah dua kali ganda.

Pertama, pembangun tidak mempunyai kawalan ke atas keselamatan yang terbina dalam API yang dicipta oleh pengamal dan organisasi lain. Ini boleh menyebabkan kelemahan diperkenalkan ke dalam aplikasi tanpa pengetahuan pembangun.

Kedua, pengaturcaraan dalam persekitaran yang kompleks dan pelbagai ini boleh membosankan kerana sejumlah besar tetapan kod dan input yang terperinci dan tersuai yang terlibat. Ia boleh menjadi mudah untuk terlepas langkah penting dan tanpa disedari mewujudkan jurang keselamatan. Selain itu, risiko keselamatan tersembunyi boleh diperkenalkan apabila persekitaran berkembang dan menyesuaikan diri dengan perubahan permintaan perniagaan dari semasa ke semasa.

Untuk menggambarkan lagi cabaran, mari kita bandingkan persediaan untuk mendapatkan tapak web dan SPA.

Dalam melindungi tapak web, pembangun boleh menggunakan sesi berasaskan kuki untuk memberikan pengguna akses kepada aplikasi web. Pelanggan tapak web bahagian hadapan menyimpan kuki pada penyemak imbas yang dihantar ke pelayan data hujung belakang tunggal dengan setiap permintaan akses pengguna. Keputusan kebenaran boleh berdasarkan data sesi yang disimpan dalam storan supaya akses pengguna kekal terjamin di sebalik tembok api rangkaian.

Persediaan ini tidak boleh dilakukan untuk SPA kerana aplikasi satu halaman mempunyai bahagian belakang khusus. Rangkaian penghantaran kandungan (CDN) sering menyampaikan kod kepada SPA melalui fail statik. Fail ini dikembalikan melalui panggilan API ke aplikasi. Dalam konfigurasi SPA, sesi pengguna tidak boleh disimpan dalam kuki kerana tiada storan data hujung belakang. Sebaliknya, token akses boleh digunakan untuk memanggil API bagi pihak pengguna yang disahkan.

Kerentanan Keselamatan SPA

Cabaran keselamatan SPA bergantung pada fakta bahawa pengesahan berasaskan pelayar terdedah kepada pelbagai jenis serangan siber. Satu jenis ancaman ialah pencurian bukti kelayakan penskripan tapak (XSS). Dalam kaedah serangan ini, pelakon berniat jahat menyuntik kod yang mampu mencuri token akses dan bukti kelayakan pengguna ke dalam penyemak imbas untuk mendapatkan akses tanpa kebenaran kepada data dan sistem berharga.

Walaupun XSS adalah kelemahan biasa, ia bukan satu-satunya yang mesti dipertahankan oleh pembangun. Untuk menyukarkan lagi keadaan, membetulkan satu kelemahan selalunya membuka kelemahan baharu, yang menjadikan mengamankan SPA sebagai permainan perubahan objektif yang tidak berkesudahan. Sebagai contoh, menggunakan aliran OAuth untuk mengesahkan akses pengguna atau API dengan token OAuth dan bukannya kuki sesi kelihatan seperti cara yang baik untuk mengurangkan serangan XSS.

Walau bagaimanapun, jika token ini disimpan dalam storan tempatan, pelaku ancaman dengan mudah boleh mendapatkan akses kepada storan tempatan dan sesi untuk mengeluarkan token. Jika token boleh dimuat semula, masalah akan menjadi lebih teruk kerana penyerang boleh mendapatkan akses walaupun selepas sesi pengguna tamat.

Satu lagi contoh isu yang tidak diingini yang boleh datang dengan pembetulan keselamatan ialah membina dasar keselamatan yang kukuh ke dalam pengepala dasar keselamatan kandungan (CSP). Walaupun ini boleh menambah satu lagi lapisan kawalan keselamatan, sesetengah sumber mungkin boleh membuka dasar keselamatan kandungan dan melumpuhkannya.

Intinya ialah penyemak imbas adalah persekitaran yang bermusuhan apabila ia datang untuk mempertahankan daripada akses yang tidak dibenarkan dan berniat jahat kepada data dan sistem. Sebarang langkah keselamatan memerlukan ujian yang teliti dan kewaspadaan yang berterusan untuk memastikan penutupan satu vektor serangan tidak membuka jalan bagi yang lain.

Utiliser à la fois des cookies et des jetons

Une façon de sécuriser les SPA récemment développée pour protéger l'authentification des utilisateurs contre les acteurs malveillants est un modèle de gestionnaire de jetons qui fusionne la sécurité des cookies du site Web et les jetons d'accès. En mettant en œuvre une architecture de gestionnaire de jetons qui supprime l'authentification du navigateur et exploite une configuration backend pour frontend (BFF) utilisant des cookies et des jetons du même site, les organisations peuvent bénéficier des aspects légers des SPA sans sacrifier la sécurité.

Dans cette configuration, un agent OAuth hébergé en tant que composant backend se situe entre le SPA et le serveur d'autorisation. L'agent OAuth gère le flux OAuth pour le SPA et au lieu que le SPA reçoive un jeton, un cookie sécurisé HTTP uniquement est émis que le SPA peut utiliser pour accéder à ses API et microservices backend.

Un proxy OAuth hébergé dans une passerelle API hautes performances

Atas ialah kandungan terperinci Keselamatan Aplikasi Satu Halaman (SPA) Tidak Berfungsi Sama seperti Laman Web. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!