Same Origin Policy (SOP) Dalam Praktek Security

Pada bagian ini saya akan menjelaskan apa itu same origin policy (SOP) dan bagaimana penerapannya. SOP merupakan salah satu best practice dalam mekanisme hardening keamanan sebuah aplikasi.

Apa yang dimaksud dengan Same Origin Policy (SOP)?

Same origin policy (SOP) adalah mekanisme keamanan web yang dibangun di browser web yang mempengaruhi cara situs web dapat mengakses satu sama lain. Tanpa SOP, situs web atau aplikasi web jahat dapat mengakses yang lain tanpa batasan. Itu akan memungkinkan penyerang dengan mudah mencuri informasi sensitif dari situs web lain atau bahkan melakukan tindakan di situs lain tanpa persetujuan pengguna.

SOP tidak perlu diaktifkan, SOP diaktifkan secara otomatis di setiap browser yang mendukungnya. Pengembang harus mengetahui mekanisme ini saat membuat aplikasi web yang berkomunikasi satu sama lain, sehingga mereka tahu cara menonaktifkannya dalam keadaan khusus dengan aman.

Same origin policy sering disamakan dengan Content-Securiy Policy. Perbedaannya adalah Content-Securiy Policy mencegah panggilan ke sumber daya eksternal (keluar) sedangkan same origin policy mencegah panggilan dari sumber daya eksternal (masuk). Selain itu, Content-Securiy Policy tidak diaktifkan secara default dan harus ditentukan oleh pengembang.

Fungsi Same Origin Policy (SOP)

Mekanisme SOP dirancang untuk melindungi dari serangan seperti Cross-Site Request Forgery (CSRF) , yang pada dasarnya berupaya memanfaatkan kerentanan karena perbedaan asal. Namun, karena ini hanyalah kebijakan keamanan browser dan tidak pernah ditetapkan sebagai spesifikasi Internet permanen, setiap browser mengimplementasikannya sedikit berbeda. Oleh karena itu, Anda harus berhati-hati dalam mengandalkan SOP karena pengguna mungkin menjalankan browser dengan aturan SOP yang berbeda (misalnya, Internet Explorer).

Perhatikan bahwa SOP sama sekali tidak berguna sebagai metode perlindungan terhadap Cross-Site Scripting (XSS) karena harus membatasi pemuatan skrip dari situs yang berbeda, yang pada akhirnya menghambat fungsionalitas aplikasi web.

Cara Kerja Same Origin Policy (SOP)

Untuk memahami same origin policy, pertama-tama kita perlu memahami istilah origin .

Dalam istilah web, origin adalah sekumpulan karakteristik umum dari sumber daya web. Dalam kebanyakan kasus, origin adalah kombinasi dari tiga elemen: skema (protokol), nama host (domain/subdomain), dan port. Oleh karena itu, semua sumber daya yang diidentifikasi oleh skema yang sama: nama host: kombinasi port memiliki origin yang sama.

Namun, jika dua sumber daya berbeda dalam salah satu dari ketiga elemen ini, browser modern seperti Google Chrome atau Mozilla Firefox memperlakukan sumber daya ini sebagai sumber yang berbeda. Hanya dalam kasus Microsoft Internet Explorer, nomor port tidak dianggap sebagai bagian dari origin. Misalnya:

http://normal-website.com/example/example.html

URL diatas menggunakan skema http, domain normal-website.com, dan nomor port 80. Tabel berikut menunjukkan bagaimana same origin policy akan diterapkan jika konten di URL di atas mencoba mengakses origin lainnya:

URL   diakses	Akses diizinkan?
http://normal-website.com/example/	Ya: skema, domain, dan port yang   sama
http://normal-website.com/example2/	Ya: skema, domain, dan port yang   sama
https://normal-website.com/example/	Tidak: skema dan port berbeda
http://en.normal-website.com/example/	Tidak: domain yang berbeda
http://www.normal-website.com/example/	Tidak: domain yang berbeda
http://normal-website.com:8080/example/	Tidak: port yang berbeda*

*Internet Explorer akan mengizinkan akses ini karena IE tidak memperhitungkan nomor port saat menerapkan kebijakan asal yang sama.

Penerapan Same Origin Policy

Same origin policy umumnya mengontrol akses yang dimiliki kode JavaScript ke konten yang dimuat lintas domain. Pemuatan sumber daya halaman lintas sumber umumnya diizinkan. Misalnya, SOP memungkinkan penyematan gambar melalui <img> tag, media melalui <video> tag, dan menyertakan JavaScript dengan <script> tag. Namun, meskipun sumber daya eksternal ini dapat dimuat oleh laman, JavaScript apa pun di laman tersebut tidak akan dapat membaca konten sumber daya ini.

Ada berbagai pengecualian untuk kebijakan asal yang sama:

1. Beberapa objek dapat ditulis tetapi tidak dapat dibaca lintas-domain, seperti location objek atau location.href properti dari iframe atau jendela baru.
2. Beberapa objek dapat dibaca tetapi tidak dapat ditulis lintas-domain, seperti length properti window objek (yang menyimpan jumlah bingkai yang digunakan pada halaman) dan closed properti.
3. Fungsi replace umumnya dapat disebut lintas-domain pada location objek.
4. Anda dapat memanggil fungsi tertentu lintas domain. Misalnya, Anda dapat memanggil fungsi close, blur dan focus di jendela baru. Fungsi postMessage ini juga dapat dipanggil di iframe dan jendela baru untuk mengirim pesan dari satu domain ke domain lainnya.

Karena persyaratan lama, same origin policy lebih longgar saat menangani cookie, sehingga sering kali dapat diakses dari semua subdomain situs meskipun setiap subdomain secara teknis memiliki origin yang berbeda. Anda dapat mengurangi risiko ini sebagian dengan menggunakan HttpOnly flag cookie.

Dimungkinkan untuk mengendurkan same origin policy menggunakan document.domain. Properti khusus ini memungkinkan Anda untuk melonggarkan SOP untuk domain tertentu, tetapi hanya jika itu adalah bagian dari FQDN Anda (nama domain yang memenuhi syarat). Misalnya, Anda mungkin memiliki domain marketing.example.comdan ingin membaca konten domain tersebut di example.com. Untuk melakukannya, kedua domain perlu disetel document.domain ke example.com.

Kemudian SOP akan memungkinkan akses antara dua domain meskipun asalnya berbeda. Di masa lalu dimungkinkan untuk menyetel document.domainke TLD seperti com, yang memungkinkan akses antara domain mana pun di TLD yang sama, tetapi sekarang browser modern mencegahnya.

Kapan browser menggunakan Same Origin Policy ?

Pemeriksaan origin diterapkan oleh browser dalam setiap kasus interaksi potensial antara elemen dari origin yang berbeda, misalnya:

1. Kode JavaScript dan Model Objek Dokumen (DOM), seperti saat halaman tidak dapat mengakses konten iframe-nya kecuali berasal dari sumber yang sama.

2. Cookie, seperti cookie sesi Anda yang digunakan untuk autentikasi untuk situs tertentu dan tidak dapat dikirim ke halaman dengan asal yang berbeda. Perhatikan bahwa untuk cookie, skema dan port tidak dievaluasi, hanya domain/subdomain.

3. Panggilan AJAX ( XmlHTTPRequest ).

Namun, SOP tidak sepenuhnya menghilangkan interaksi antar asal yang berbeda. Browser mengevaluasi apakah interaksi tertentu dapat menimbulkan ancaman dan jika tidak, diizinkan. Misalnya:

• Anda biasanya dapat menulis di antara asal-usul. Misalnya, Anda dapat membuat tautan lintas asal dan mengirimkan formulir lintas asal.
  
  
• Anda biasanya dapat menyematkan di antara origin. Misalnya, Anda dapat menggunakan konten dari origin yang berbeda dalam iframe (jika X-Frame-Options mengizinkannya) atau menyematkan img , css , atau elemen skrip dari situs lain.
  
  
• Namun, akses baca antar origin biasanya diblokir. Ini sering kali berarti Anda dapat mengirim permintaan lintas asal tetapi tidak dapat membaca balasannya.

Mengatasi Pembatasan Same Origin Policy 

Dalam beberapa kasus, Anda mungkin ingin melonggarkan SOP yang ketat dan mengizinkan interaksi lintas asal tertentu, misalnya, antara domain berbeda yang keduanya milik Anda. Dalam kasus tersebut, ada beberapa cara untuk memastikan bahwa SOP tidak menghalangi kemampuan interaksi lintas domain aplikasi web Anda.

1. Menentukan Origin

Cara termudah untuk mengubah origin situs Anda adalah dengan mendeklarasikannya menggunakan JavaScript:

document.domain = "example.com";

Namun, ini hanya mungkin untuk situs dalam hierarki domain yang sama jika tidak, situs mana pun dapat berpura-pura memiliki asal Anda. Misalnya, Anda dapat menggunakan metode sederhana ini jika Anda memiliki beberapa situs mikro di bawah subdomain yang berbeda, seperti login.example.com , blog.example.com , dll.

2. Menggunakan metode postMessage

Jika Anda perlu berkomunikasi antara objek jendela seperti halaman dan sembulan dari halaman itu atau halaman dan iframe yang disematkan pada halaman itu, Anda dapat menggunakan metode window.postMessage() .

Misalnya, Anda bisa mendapatkan referensi ke jendela lain menggunakan newWindow = window.opener dan kemudian mengirim pesan acara melalui newWindow.postMessage(). Menggunakan objek acara untuk mengakses argumen yang newWindow diteruskan dengan metode ini.

3. Berbagi sumber daya lintas sumber

Berbagi sumber daya lintas asal (CORS) adalah mekanisme HTTP yang menggunakan header HTTP untuk menentukan izin asal. Dengan menggunakan header CORS, Anda dapat memberi tahu browser bahwa sumber daya dari sumber lain memiliki hak untuk mengakses sumber daya di halaman Anda.

Misalnya, permintaan GET ke sebuah situs dapat dikirim dengan header permintaan Asal yang menyatakan asal persisnya (mirip dengan document.domain):

4. Menggunakan WebSockets

Jika skrip Anda mencoba menyambung ke WebSocket , browser akan mengizinkan semua komunikasi semacam itu tanpa memeriksa kebijakan asal yang sama. Namun, browser menambahkan tajuk Origin ke permintaan, yang menentukan asal skrip dari mana koneksi berasal.

Dalam kasus seperti itu, bukan browser tetapi pengembang yang diharapkan untuk memastikan keamanan. Jika Anda menggunakan WebSockets dengan cara ini, Anda harus menyertakan fungsionalitas di server WebSocket untuk membandingkan data di header Asal dengan daftar putih asal yang aman untuk dibalas atau gunakan cara lain untuk mengonfirmasi bahwa sambungan dapat dipercaya.

5. Menggunakan JSONP (tidak disarankan)

Sebelum berbagi sumber daya lintas asal diperkenalkan pada tahun 2009, laman web dapat menggunakan JSONP (JSON dengan padding) untuk melewati kebijakan asal yang sama. Ini dilakukan dengan menggunakan <script>tag untuk mengambil dan mengeksekusi konten JSON dari sumber lain. Namun, saat menggunakan JSONP, penyerang mungkin dapat mengganti fungsi asli dengan fungsi jahat. Oleh karena itu, saat ini penggunaan JSONP tidak direkomendasikan.

Referensi :
1. https://portswigger.net/web-security/cors/same-origin-policy
2. https://www.invicti.com/learn/same-origin-policy-sop/