Clickjacking Attack On Facebook

Clickjacking Attack On Facebook  - Serangan clickjacking yang diperkenalkan pada tahun 2002 adalah serangan Redressing UI di mana halaman web memuat halaman web lain dalam iframe opacity rendah, dan menyebabkan perubahan status ketika pengguna tanpa sadar mengklik tombol-tombol halaman web. Pada artikel ini, kami menjelaskan cara kerja serangan Clickjacking dan pentingnya header X-Frame-Options, termasuk diskusi tentang penemuan terbaru oleh seorang peneliti yang menemukan serangan Clickjacking di Facebook.

Clickjacking Attack On Facebook 

Introduction to Clickjacking

Jenis serangan ini diabaikan hingga 2008, ketika penemu serangan, Jeremiah Grossman dan Robert Hansen, memperoleh otorisasi pada komputer korban melalui Adobe Flash dengan menggunakan serangan Clickjacking. Grossman awalnya menamai serangan ini dengan menggabungkan kata 'klik' dan 'pembajakan'. Nama 'Clickjacking' melewati berbagai kategorisasi dan perubahan nama sejak saat itu. Sebagai contoh, serangan di mana penyerang mengumpulkan suka untuk posnya sendiri menggunakan metode Clickjacking kemudian dikenal sebagai 'Suka Pembajakan'.

Meskipun serangan Clickjacking telah dicegah dengan metode seperti Frame Busting, pertahanan paling efektif terhadap serangan ini diperkenalkan oleh Microsoft pada tahun 2009. Dengan rilis Internet Explorer 8, Microsoft merilis header respons HTTP X-Frame-Options (XFO) HTTP respon . Tepat setelah pengumuman tersebut, semua browser utama menerapkan tajuk ini, dan pada 2013 RFC 7034 dirilis.

How Does the Clickjacking Attack Work?

Metode serangan Clickjacking bekerja dengan memuat situs web target di dalam iframe opacity rendah dan melapisinya dengan tombol atau tautan yang tampak tidak berbahaya. Ini kemudian menipu pengguna untuk berinteraksi dengan situs web yang rentan di bawahnya dengan memaksa pengguna untuk mengklik elemen UI yang tampaknya aman, memicu serangkaian tindakan pada situs web yang disematkan dan rentan.

Dalam contoh ini, Amazon dimuat dalam iframe opacity rendah dan karenanya tidak terlihat oleh pengguna. Pengguna melihat tombol Klik Di Sini. Namun begitu mereka mengkliknya, hanya tombol Beli di Amazon yang benar-benar diklik, memicu serangkaian tindakan di Amazon. (Harap dicatat, bahwa Amazon tidak rentan terhadap clickjacking, dan ini hanyalah contoh bagaimana itu akan bekerja.)

Karena interaksi ini terjadi seolah-olah korban sengaja menjelajahi situs web, interaksi yang dipicu di Amazon juga akan mencakup kredensial korban (seperti Cookie).

The Clickjacking Bug on Facebook

Pada 21 Desember, seorang peneliti keamanan melaporkan penyelidikannya di mana ia melihat posting mencurigakan dibagikan di dinding Facebook teman-temannya dan menemukan kampanye penipuan. Ketika dia mengklik tautan yang mengarahkannya ke situs web komik, dia diminta untuk mengkonfirmasi umurnya. Setelah mengkonfirmasi usianya, ia dialihkan ke situs web komik, tetapi posting itu juga diterbitkan di dinding Facebook-nya tanpa ada tindakan apa pun dari pihaknya.

Peneliti menemukan iframe dan memperoleh kode sumber. Dia menemukan bahwa frame ini berakhir di URL Facebook ini:

https://mobile.facebook.com/v2.6/dialog/share?app_id=283197842324324&href=https://example.com&in_iframe=1&locale=en_US&mobile_iframe=1

Ketika Anda mengklik tautan ini, Anda diminta untuk membagikan konten di dinding Anda.

Yang menarik adalah bahwa peneliti menyadari bahwa header XFO diatur dengan benar di halaman. Itu biasanya akan menghentikan iframe apa pun (bahkan halaman Facebook) yang dimuat di halaman:

X-Frame-Options: DENY

Peneliti melanjutkan untuk memeriksa apakah header X-Frame-Options diimplementasikan dengan benar di semua browser utama. Dia membenarkan bahwa mereka semua bekerja seperti yang diharapkan. Selanjutnya, ia memeriksa apakah browser bawaan di aplikasi Android Facebook menerapkan header XFO dengan benar. Ternyata header respons XFO tidak disetel saat pengguna masuk ke Facebook dari perangkat seluler.

How Did Facebook Respond to the Clickjacking Attack?

Facebook menolak untuk memperbaiki masalah ini, tetapi sebagai tindakan pencegahan, Facebook membuat halaman prompt kedua untuk memberi pengguna kendali atas apakah mereka ingin melanjutkan pembagian tersebut.

Jadi, bagaimana cara kerja perbaikan Facebook? Setiap kali Anda mengklik tombol untuk berbagi posting, halaman konfirmasi kedua terbuka di tab baru. Ia bertanya apakah Anda ingin berbagi pesan dan memungkinkan Anda memilih orang yang ingin Anda bagikan tautan. Halaman baru terbuka karena nilai "_blank" ditambahkan ke atribut target di elemen href pada halaman pertama. Setiap kali diatur, halaman tertaut di belakang tautan dibuka di tab baru. Ini menghasilkan serangan clickjacking yang gagal. Ini karena, tab baru mengimplementasikan fitur X-Frame-Options: DENY dengan benar.

Sulit untuk mengatakan mengapa Facebook memutuskan untuk membuka tab yang sama sekali baru untuk berbagi pesan. Ini membuat berbagi sedikit lebih nyaman. Untuk perusahaan seperti Facebook, yang bertujuan untuk membuat berbagi konten semudah mungkin, ini terdengar seperti perbaikan yang mengerikan. Saya tidak akan terkejut jika ini hanya solusi sementara atau jika Facebook benar-benar menggunakan halaman kedua ini sebagai ruang iklan tambahan.

How to Properly Prevent Clickjacking Attacks in Your Web Applications

Untuk melindungi pengguna dari serangan Redressing UI seperti Clickjacking, taktik terbaik adalah mencegah situs web jahat membingkai halaman untuk di-render dengan iframe atau frame. Metode yang paling efektif adalah dengan menggunakan header keamanan HTTP X-Frame-Options.

X-Frame Options Directives

There are three X-Frame-Options directives available.

X-Frame-Options: DENY | SAMEORIGIN | ALLOW-FROM URL

Directive	Description
DENY:	The page must not be embedded into another page within an iframe or any similar HTML element.
SAMEORIGIN:	The website can only be embedded in a site that’s paired in terms of scheme, hostname and port. For example, https://www.example.com can only be loaded through https://www.example.com, while https://www.attacker.com, and even http://example.com, are not allowed to embed it. For further information about Same-Origin Policy, see Introducing the Same-Origin Policy Whitepaper.
ALLOW-FROM URL:	The website can only be framed by the URL specified or whitelisted here. There are two important points to remember with X-Frame-Options: Chromium based browsers only partially support X-Frame-Options (the ALLOW-FROM directive is unavailable) Using the ALLOW-FROM URL instruction, we can whitelist only one domain and allow our website to be loaded in an iframe.

Important Points About the X-Frame-Options HTTP Header

• The X-Frame-Options header must be present in the HTTP responses of all pages
• Instead of X-Frame-Options, the Content-Security-Policyframe-ancestors directive can be used:

Content-Security-Policy: frame-ancestors 'none'; // No URL can load the page in an iframe.

Content-Security-Policy: frame-ancestors 'self'; // Serves the same function as the SAMEORIGIN parameter.

Content-Security-Policy: frame-ancestors https://www.example.com;

Ini melayani fungsi yang sama dengan instruksi ALLOW-FROM. Yang paling penting adalah Anda dapat membuat daftar putih lebih dari satu URL dengan menggunakan instruksi ini.

Content-Security-Policy: frame-ancestors https://www.example.com https://another.example.com;

Source : https://dpsvdv74uwwos.cloudfront.net/statics/img/blogposts/clickjacking_attack_example.png