HTTP Security Header adalah salah satu hal paling fundamental dalam keamanan website. Sebagaimana kita tahu, saat kita membuka akses sebuah website, kita akan melalui berbagai rute dan jalan yang ada di internet untuk mencapai website tersebut. Selama proses perjalanan data dari dan ke server tersebut, bukan tidak mungkin kita akan menjumpai berbagai jenis serangan di jaringan.

Mengapa Harus Menggunakan HTTP Security Header?

HTTP Security Header berfungsi untuk mengamankan transaksi data dari website ke klien. Lho bukankah sudah ada mekanisme HTTPS/SSL? Yap betul. Betul, SSL dapat digunakan untuk melakukan enkripsi data selama perjalanan dari dan menuju server, namun, bagaimana jika website tujuan kita itulah yang sudah disusupi oleh malicius code?

Cara Menguji Security Header Website Kita

Ada banyak tipe serangan di jaringan internet, HTTP Security Header mampu melindungi serangan seperti Code injection, clickjacking, XSS dan lain sebagainya. Sebelum kita memulai untuk menguji apakah website kita telah menerapkan keamanan HTTP Security Header silahkan klik ke halaman Security Header checker.

Masukkan url blog/website kita disana, dan klik go. Setelah itu kita akan mendapatkan nilai keamanan header website kita.

Terdapat enam kategori security yang harus kita perbaiki untuk memperbaiki nilai HTTP Security Header. Yaitu

Komponen security header berjumlah enam, dan setiap komponen memiliki fungsi masing-masing. Komponen tersebut adalah

1. X Frame Options
2. Referrer Policy
3. Feature Policy
4. Strict Transport Security
5. X Content Type Options
6. Content Security Policy

Penjelasan mengenai setiap komponen security ini akan kita jelaskan secara lebih detail nanti di belakang.

Nilai HTTP Security Header

Nilai tingkat keamanan HTTP header dibagi menjadi 8 grade nilai, mulai dari yang paling atas hingga yang paling bawah. Nilai sempurna adalah A+ dimana sebuah website menerapkan secara penuh 6 komponen policy dari HTTP security header. Adapun penjelasan jika keamanan website/blog kamu mendapat nilai F adalah sebagai berikut

Penjelasan grade HTTP Security Header
A+	Menerapkan 6 policy security header
A	Menerapkan 5 setting keamanan header
B	Menerapkan 4 setting keamanan
C	Menerapkan tiga setting keamanan
D	Menerapkan dua dari 6 setting security
E	Hanya menerapkan 1 jenis keamanan
F	Tidak menerapkan satupun setting security header
R	Menerapkan redirect pada site

Cara Memperbaiki Security Header Website

Untuk memperbaiki nilai HTTP security header, kita akan mengupasnya satu persatu dari enam komponen yang sudah kita sebutkan di atas. Namun perlu diingat, kode yang aku gunakan nanti adalah kode untuk mesin Apache, dan dipasang di file .htaccess. Jika kalian menggunakan server NginX, IIS, LiteSpeed, dll kalian bisa mencari referensi tambahan ya. Oke, sekarang kita mulai dari X Frame Options.

X Frame Options

Kehadiran iframes atau lebih mudah dikenal dengan pop up dalam tampilan website memang menyebalkan. Di satu sisi, iframes memang menguntungkan para publisher adsense yang ingin bermain curang dengan mengharapkan pengunjung mereka tidak sengaja melakukan klik iklan agar penghasilan mereka meningkat.

Namun nyatanya, tak hanya para publisher nakal saja yang menggunakan teknik ini, hacker juga menggunakan iframe untuk membuat sebuah website palsu seolah-olah nampak sebagai sebuah website resmi. Di masa Orkut, teknik penyamaran clickjacking ini begitu populer, seseorang akan mengira dia ada di dalam website official, namun sebenarnya ada sebuah script yang berjalan dibaliknya, siap untuk menyerap informasi username dan password yang ia masukkan di halaman tersebut.

X-Frame-Options mencegah terjadinya teknik spoofing semacam itu di website kita. Sehingga tidak ada iframe yang muncul tanpa seijin kita. Kode yang harus kita masukkan di .htaccess adalah

Header set X-Frame-Options SAMEORIGIN

Hasil pengecekan saat kita telah selesai memasang HTTP Security Header X Frame Options adalah sebagai berikut

SAMEORIGIN akan mengijinkan sebuah halaman ditampilkan di sebuah frame yang berasal dari web itu sendiri, selain same origin juga ada dua setting lain yang bisa diterapkan yakni

1. SAMEORIGIN: mengijinkan sebuah halaman ditampilkan di sebuah frame yang berasal dari web itu sendiri
2. DENY: Mencegah sebuah halaman ditampilkan dalam sebuah iframe
3. ALLOW-FROM uri: Setting ini mengijinkan sebuah halaman ditampilkan hanya di website tertentu saja

Referrer Policy

Referrer Policy adalah sebuah kebijakan yang diterapkan sebuah website saat seseorang melakukan navigasi lewat link yang ada di dalam halaman tersebut. Kita tentu sering mengklik sebuah link, baik sebuah internal link atau external link. Di Sisi lain kita juga sering melakukan klik pada tautan yang berada di social media seperti Facebook dan Twitter.

Pada beberapa kondisi, sebuah website perlu melindungi keamanan dan privasi pengguna saat mereka melakukan klik ke tautan external. Apalagi jika mereka berasal dari website yang menerapkan enkripsi HTTPS seperti facebook, twitter, akun perbankan, e-commerce, ke website lain yang tidak menerapkan protokol HTTP.

Seseorang bisa dengan mudah mengetahui dari mana halaman sumber yang memicu klik ke website dia berasal tanpa adanya pengaturan lebih lanjut di bagian referrer policy. Bagaimana jika halaman tersebut adalah halaman yang cukup riskan untuk dihack atau diexploitasi? Tentu membahayakan pengguna. Oleh karenanya, Google, Facebook, Twitter dan website yang menerapkan protokol SSL umumnya juga menerapkan referrer policy

Referrer Policy options

• No-referrer — Tidak ada informasi referal disertakan
• No-referrer-when-downgrade — Ini adalah nilai default dimana URL sumber akan ditampilkan full path saat koneksi terjadi dari HTTPS > HTTPS tetapi tidak jika komunikasi terjadi downgrade dari HTTPS > HTTP.
• Origin — Hanya mengirimkan informasi domain saja (paling sering jika kita mendapati sumber rujukan dari facebook, twitter atau social media lain) bukan url full path
• Origin-when-cross-origin — Mengirimkan full path URL jika pengguna melakukan klik di internal link, tapi hanya menampilkan nama domain jika menuju tautan eksternal
• Same-origin — Menampilkan URL full path pada internal link, tapi memberikan nilai no-referrer pada eksternal link
• Strict-origin — mengirimkan informasi domain sumber jika menggunakan protokol setara HTTPS > HTTPS and HTTP > HTTP, tetapi tidak downgrade HTTPS > HTTP.
• Strict-origin-when-cross-origin — Mengirimkan full path pada internal link, domain info pada ekternal link secure HTTPS, tidak memberikan informasi perujuk jika eksternal link menuju halaman HTTP biasa
• Unsafe-url — Menampilkan URL full path pada semua kondisi

Cara Menambahkan Referrer Policy di WordPress

Jika kita menggunakan wordpress self hosting, kita bisa melakukan setting Referrer Policy di file .htaccess, caranya adalah sebagai berikut

1. Masuk cpanel dan menuju file manager
2. Edit file .htaccess
3. Cari module <IfModule mod_headers.c>
4. Letakkan kode Header set Referrer-Policy “same-origin” sebelum </IfModule>
5. Anda juga bisa mengubah policy “same-origin“ pada langkah 4 dengan policy yang kamu inginkan misalnya “Origin-when-cross-origin“
6. Simpan kembali file .htaccess
7. Silahkan cek menggunakan website HTTP Security Header Checker di bagian depan artikel ini.

Feature Policy

Nah sekarang kita lanjut ke komponen HTTP Security Header berikutnya yaitu Feature Policy. Feature Policy adalah sebuah aturan yang mengatur fitur apa saja yang diizinkan diload oleh sebuah browser dari website kita. Teknologi web browser saat ini memungkinkan banyak sekali penambahan fitur yang membantu pengguna, disisi lain, hal tersebut juga memiliki dampak terhadap keamanan pengguna.

Misalnya apa nih? Geolocation, seorang webmaster dapat mengetahui darimana pengunjung itu berasal, berapa ukuran layar yang digunakan, kelihatannya bukan masalah besar ya bagi pengguna? Dan justru merupakan keuntungan kita sebagai pemilik website karena bisa memetakan demografi user kita seperti apa.

Namun jangan lupa, saat ini kita berhadapan dengan GPDR, aturan tentang tidak dibolehkannya sebuah website menyimpan data pengguna (baik berupa data yang diinputkan pengguna maupun cookies, atau informasi seputar teknologi yang digunakan pengguna untuk berkunjung ke website kita) telah merubah banyak kebijakan di dunia internet. Meski hanya diterapkan untuk pengunjung dari Uni Eropa, bukan tidak mungkin kita kena getahnya jika memiliki banyak pengunjung dari sana.

Itu dari segi tidak berbahayanya ya, sekarang dari segi yang lebih berbahaya, fitur browser memiliki kemampuan untuk melakukan autoplay video, mengaktifkan kamera pengguna, dan lain sebagainya. Masih ingat betapa menyebalkannya portal berita jaman ini, sudah halaman dibuat berpaging-paging, selalu memutar video pop-up tanpa konfirmasi pengguna. Beneran deh maling paket data banget, karena paket data kita tersedot sia-sia hanya untuk meload video yang tidak kita inginkan. Someday aku yakin hal semacam ini bakal kena semprit sama Google.

Lalu gimana kalo yang diaktifkan kamera/mikrophone pengguna secara diam-diam? Nah banyak lho ternyata web yang melakukan spionase terhadap pengunjungnya. Web kita mungkin secara tidak sengaja pun melakukannya jika ada kode pihak ketiga yang tidak sengaja ikut nempel di halaman web kita. Bahaya banget. Lebih lanjut feature policy apa aja sih yang didukung oleh browser kita dan apa aja yang diatur disana bisa cek halaman dokumentasi Mozilla ini. Oleh karenanya, demi keamanan pengguna kita, kita bisa melakukan setting Feature Policy di website kita.

Contoh penggunaan Feature Policy

Feature policy dapat dimasukkan juga ke mod header pada .htaccess dengan perintah berikut

Header always set Feature-Policy “microphone ‘none’; payment ‘none’; camera ‘none’; autoplay ‘self’ https://mysiteURL.com”

Pada perintah feature policy tersebut, kita bisa menemukan bahwa website kita tidak mengijinkan fitur pengaktifan microphone, kamera, pembayaran, hanya mengijinkan autoplay video yang berasal dari web kita sendiri, fitur lain diijinkan jika berasal dari domain HTTPS spesifik mysiteURL.com

Strict Transport Security (HSTS)

HTTP Strict Transport Security adalah mekanisme yang mengatur keamanan website untuk menghadapi serangan man in the middle attacks, dimana data yang dikirimkan antara website dengan browser klien dicegat di perjalanan dan diubah oleh penyerang. Hal ini bisa terjadi karena website tidak menggunakan protokol HTTPS, atau terjadi serangan protocol downgrades attacks sebelumnya.

HSTS hanya mengijinkan sebuah koneksi hanya dilayani jika berjalan di protokol HTTPS, HSTS juga mengatur seberapa lama sebuah cookies, diijinkan disimpan oleh browser pengguna. Dengan adanya perlindungan semacam ini, user kita menjadi lebih aman dari kemungkinan serangan hacker yang ingin memanipulasi dan mengambil keuntungan dari akses mereka ke website kita

Memasang HSTS di WordPress

Nah untuk memasang HSTS di wordpress, kita tinggal menambahkan baris selanjutnya di .htaccess

Header set Strict-Transport-Security "max-age=31536000;includeSubDomains;"

Semua protokol koneksi yang menuju website kita (termasuk subdomainsnya) sudah diamankan dengan HTTP Security Header HSTS. Sekarang pengunjung bisa lebih aman (meski mereka tidak pernah tahu) dari kemungkinan serangan hacker

X-Content Type Options

X Content Type Options adalah salah satu komponen HTTP Security Header yang memberikan response terhadap permintaan Multipurpose Internet Mail Extensions atau MIME type. Opsi X Content Type Options digunakan untuk mengamankan data MIME dari kemungkinan sniffing.

Sniffing itu apa? Sniffing adalah aktifitas untuk memonitor dan mengcapture semua jenis konten yang melewati jaringan, beberapa contohnya adalah MIME type yang meliputi script, style serta mampu melakukan perlindungan Enables Cross-Origin Read Blocking (CORB) untuk beberapa MIME Type sebagai berikut

Kemampuan X Content Type Options

Melakukan blokir permintaan jika permintaan yang dituju adalah:

• “style” and the MIME type is not text/css, or
• “script” and the MIME type is not a JavaScript MIME type

Enables Cross-Origin Read Blocking (CORB) untuk MIME-types berikut:

• text/html
• text/plain
• text/json, application/json or any other type with a JSON extension: */*+json
• text/xml, application/xml or any other type with an XML extension: */*+xml (excluding image/svg+xml)

Mengaktifkan X Content Type Options

Untuk mengaktifkan X Content ini, cukup dengan menambahkan baris

Header set X-Content-Type-Options nosniff

All is done klo sudah begini. Selanjutnya kita tinggal ngebahas tentang Content Security Policy

Content Security Policy

Content Security Policy Header merupakan mekanisme untuk mencegah serangan Cross Site Scripting (XSS). Cross Site Scripting umumnya terjadi jika sebuah website disusupi oleh kode jahat. Kode tersebut akan ikut tampil di halaman browser user, dan terdownload oleh user. Umumnya Google memberikan perlindungan terhadap user dengan memberikan peringatan This Site Ahead Contains Malware dan menutup akses ke situs tersebut.

Jika kita hendak berkunjung ke situs tersebut, tentu kita akan berpikir seribu kali untuk mengaksesnya. Kita tidak tahu jenis malware apa yang ada disana dan apa dampak yang mungkin terjadi jika kita nekat melanjutkan membuka website tersebut. 98% user yang mendapat peringatan tersebut akan memilih menyingkir dari website tersebut demi keamanan.

Lalu bagaimana jika website/blog kita yang justru mendapat peringatan semacam itu? Bisa dipastikan traffic website tersebut akan menurun drastis karena Google akan selalu memberikan peringatan pada calon pengunjung kita.

Serangan tersebut bisa terjadi karena adanya kode yang disusupi oleh hacker ke dalam website kita. Sehingga pada saat proses komunikasi antara website kita dengan browser user, kode tersebut turut diminta oleh browser.

Dengan menerapkan content security policy, kita bisa memblokir permintaan akses terhadap script yang tidak berasal dari website kita, seperti nampak pada gambar diatas. Berikut ini adalah berbagai metode pengamanan yang diatur dalam content security policy

• default-src : Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),
• script-src : Define which scripts the protected resource can execute,
• object-src : Define from where the protected resource can load plugins,
• style-src : Define which styles (CSS) the user applies to the protected resource,
• img-src : Define from where the protected resource can load images,
• media-src : Define from where the protected resource can load video and audio,
• frame-src : Define from where the protected resource can embed frames,
• frame-ancestors : Specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>.
• font-src : Define from where the protected resource can load fonts,
• connect-src : Define which URIs the protected resource can load using script interfaces,
• form-action : Define which URIs can be used as the action of HTML form elements,
• sandbox : Specifies an HTML sandbox policy that the user agent applies to the protected resource,
• script-nonce : Define script execution by requiring the presence of the specified nonce on script elements,
• plugin-types : Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
• reflected-xss : Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
• report-uri : Specifies a URI to which the user agent sends reports about policy violation

Dalam penerapannya tidak selalu kita harus menerapkan semua script diatas, pilih yang paling sesuai dengan kebutuhan kita. Contoh penerapan Content Policy adalah sebagai berikut

Contoh Penerapan Content Security Policy di Apache

Header set Content-Security-Policy “

default-src ‘self’ www.google-analytics.com ajax.googleapis.com;

script-src ‘self’ www.google-analytics.com ajax.googleapis.com;

img-src ‘self’ *.wordpress.com;”

Kode diatas hanya mengijinkan sumber dan script url yang diload berasal dari 3 website, yaitu website kita, google analytics serta google apis. Jika terdapat script dari website lain maka tidak akan terload di browser pengguna. Sementara gambar hanya akan diload jika tersedia dalam hosting website kita atau website manapun yang berakhiran wordpress (simak simbol wildcard * di depan wordpress.com ~ demi menghemat space biasanya gambar emang aku taruh di wp.com hehe)

Kesimpulan

Nah setelah membaca dan menerapkan artikel panjang ini, semoga kalian sudah bisa mendapatkan nilai minimal A saat menguji kesehatan HTTP Security Header kalian. Apakah dengan menerapkan ini otomatis kita jadi lebih mudah naik di SERP? Atau DA nya terkatrol tinggi?

Well, I can’t assure that! Tapi dengan membuktikan bahwa website kalian aman, kelak, Google akan memberikan nilai positif lebih tinggi dibanding website kompetitor kalian. Who knows nantinya kalian bisa bersaing di SERP dengan website-website berauthority tinggi di internet.

 

source : https://anotherorion.com/amankan-website-dengan-http-security-header/

Posted on: November 25, 2021, by : Julian's | 424 views