Inline Data With a Content Security Policy

     Hallo para pembaca….sekarang kami akan membahas tentang Content Security Policy. Content Security Policy dikirim melalui header respons HTTP, seperti HSTS, dan menetapkan sumber konten yang disetujui yang dapat dimuat peramban. Ini dapat menjadi tindakan pencegahan yang efektif terhadap serangan Cross Site Scripting (XSS) dan juga didukung secara luas dan biasanya mudah digunakan.

Mengapa kita membutuhkan CSP?
Ketika browser kalian memuat halaman, itu  tentu memuat banyak aset lain bersamanya. Ada stylesheet dan font untuk memuat bersama dengan beberapa file javascript. Satu untuk sistem komentar Disqus, satu untuk Google Analytics, tombol berbagi sosial saya di bagian bawah dan beberapa lagi untuk ukuran yang baik juga.  Tidak ada cara untuk mengetahui apakah file-file itu harus atau tidak boleh dimuat. Seorang penyerang dapat menempatkan komentar yang dibuat khusus di bagian komentar untuk memuat beberapa javascript berbahaya dari domain pihak ketiga dan ini juga akan dimuat oleh browser kalian karena disertakan bersama dengan halaman. Browser kalian tidak memiliki alasan untuk tidak mempercayai konten dari nastyhackers.com dan tidak tahu bahwa konten itu berbahaya. Di sinilah CSP masuk.

Apa yang bisa kita lindungi dengan CSP?
CSP hadir dengan berbagai arahan yang dapat digunakan untuk menegakkan kebijakan di seluruh muatan konten dan keadaan. Berikut adalah daftar semua arahan yang tersedia, bersama dengan deskripsi singkat, milik OWASP.

     CSP mendefinisikan header HTTP Content-Security-Policy yang memungkinkan Anda membuat daftar putih sumber materi yang dipercaya, dan memerintahkan browser agar hanya mengeksekusi atau merender sumber daya dari sumber-sumber itu. Bahkan jika seorang penyerang bisa menemukan lubang yang bisa digunakannya untuk menyuntikkan skrip, skrip tersebut tidak akan menyamai daftar putih, sehingga tidak akan dieksekusi.Karena kita mempercayai apis.google.com untuk menyerahkan kode yang valid, dan kita mempercayai diri sendiri untuk melakukan hal yang sama, mari kita definisikan kebijakan yang hanya akan memungkinkan skrip dieksekusi bila berasal dari salah satu dari dua sumber ini:

     Sederhana, bukan? Seperti yang mungkin Anda tebak, script-src adalah direktif yang mengontrol serangkaian skrip yang berkaitan dengan privilese untuk laman tertentu. Kita telah menetapkan ‘self’ sebagai satu sumber skrip yang valid, begitu pula https://apis.google.com. Browser dengan patuh mengunduh dan mengeksekusi JavaScript dari apis.google.com melalui HTTPS, juga dari sumber laman saat ini.

Dengan didefinisikannya kebijakan ini, browser tinggal melontarkan kesalahan sebagai ganti memuat skrip dari sumber lainnya. Bila penyerang yang pintar berusaha menyuntikkan kode ke dalam situs Anda, mereka langsung mendapatkan pesan kesalahan ketimbang berhasil dengan apa yang diharapkannya.

Related articles

Sistem Informasi POS

Sistem informasi Point Of Sale (POS) merupakan sebuah sistem...

Permohonan Surat

Surat permohonan berisikan sebuah permohonan atau permintaan tentang suatu...

Smart-School

Smart school adalah sistem yang dirancang untuk membantu siswa...

Pelacakan Nelayan

Perangkat teknologi berkembang dengan cepat. Tak terkecuali di sektor...

Case Studies

Google Map Maintenance

Compass Music Platform

A clothing brand wanted to launch a new e-commerce website that would allow customers to browse and purchase their products online. We developed a...
IOS Apps

NewsWeek Magazine

A clothing brand wanted to launch a new e-commerce website that would allow customers to browse and purchase their products online. We developed a...
Social Media Maintenance

Beauty & Makeup Shop

A clothing brand wanted to launch a new e-commerce website that would allow customers to browse and purchase their products online. We developed a...