disinilah 'celah'/hole terbesar yg paling2 rentan di facebook...
dgn memanfaatkan 'facebook API key' atau aplikasi developer facebook, kita bsa aja mmbuat applikasi 'liar' yg komersial dgn tujuan menghibur (sprti games,fun,dll)...<-ini sebgai kedok/topeng....
dgn di beri ijin kuasa 'api key' dari pihak facebook, kita bsa dgn mudah mnghubungkn antara account facebook & email se2org.
celah ini kalau dimanfaatkan oleh org2 yg berniat jahat, bisa jadi berbahaya dan serius...
ringkasan temuan :
- banyak aplikasi facebook, bahkan banyak digunakan orang2 atau tampaknya yang dapat dipercaya, tpi kurangnya dasar keamanan.
- kerentanan ditemukan dalam berbagai aplikasi facebook.
- masing-masing kerentanan tersebut dapat "dieksploitasi" untuk mengeksekusi "JavaScript" berbahaya, seperti malware pengiriman.
- selain itu, lubang tersebut memungkinkan seorang penyerang untuk mengakses informasi profil, termasuk informasi pribadi, status update, dan foto, dari pengguna korban dan teman-teman mereka.
- kerentanan ini dapat digunakan untuk mengirimkan pemberitahuan atau feed posting cerita, memungkinkan untuk penyebaran virus..
- sementara lubang mempengaruhi setiap aplikasi pengguna yang telah diotorisasi aplikasi, "clickjacking" sering dapat menargetkan pengguna yang belum..
- seri berfokus pada kerentanan dalam aplikasi yang sah, tapi aplikasi berbahaya, yang dapat dengan mudah mengeksploitasi clickjacking, juga telah dicatat oleh orang lain.
- semua kerentanan yang dilaporkan dalam seri telah ditambal, "tetapi serangan yang mengeksploitasi lubang aplikasi tetap mungkin".
- mencegah masalah masa depan karena kerentanan aplikasi memerlukan tindakan dari kedua aplikasi pengembang dan pihak facebook. .
statistik :
- seri menunjukkan kerentanan yang mempengaruhi lebih dari 9.700 aplikasi facebook.
- lebih dari setengahnya dipengaruhi kerentanan aplikasi yang telah "lulus program aplikasi facebook verified".
- enam dari aplikasi hack peringkat di antara sepuluh oleh bulanan pengguna aktif di penerbitan.
- bulanan yang dipublikasikan pengguna aktif aplikasi penting untuk hacking total lebih dari 218 juta.
- sementara gambar sebelumnya termasuk tumpang tindih, setiap kerentanan terpengaruh semua pengguna yang telah diotorisasi aplikasi, apakah sedang aktif atau tidak.
- hampir dua pertiga dari kerentanan pada paruh pertama dari seri clickjacking diperbolehkan untuk serangan yang akan mempengaruhi semua pengguna facebook. (aplikasi pada paruh kedua dari seri "tidak diperiksa" hanya untuk clickjacking karena kendala waktu.)
- kerentanan dalam aplikasi populer yang memungkinkan untuk clickjacking berarti hampir semua pengguna facebook bisa menjadi mangsa ke FAXX hack.
- tujuh dari sepuluh saat ini pengembang aplikasi oleh gabungan bulanan pengguna aktif memiliki paling sedikit satu aplikasi rentan.
- sembilan dari pengembang dihubungi mengambil alih seminggu untuk membangun sebuah patch untuk kerentanan aplikasi..
sedikit pelajaran untuk developer/pengembang
- membersihkan semua masukan. Itu termasuk setiap bit data diproses oleh aplikasi tersebut, apakah diambil dari profil pengguna facebook, diambil dari database, disampaikan dengan bentuk, atau yang diterima dari string alamat. jangan pernah beranggapan bahwa parameter tertentu akan menjadi bersih atau dari tipe yg diharapkan.
- membersihkan semua keluaran. ketika menampilkan pemberitahuan atau pesan kesalahan, beban string yang telah ditentukan daripada menggunakan input dinamis. jgn pernah menggunakan kembali alamat halaman tanpa injeksi fitering untuk usaha. filter segala informasi yang anda output ke halaman aplikasi AJAX, atau melalui sebuah antarmuka.
- secara umum, pengguna tidak boleh diizinkan untuk masukan HTML, FBML, atau kaya-format teks. jika memungkinkan kaya-data teks, gunakan pre-built, kode diuji untuk memproses dan menampilkan itu, rathering daripada mencoba untuk membuat filter sendiri.
- banyak kelemahan muncul di halaman sekunder, seperti iklan loader atau interface AJAX. verifikasi tindakan pencegahan keamanan di setiap bagian dari aplikasi. jika memungkinkan, pertimbangkan untuk menyimpan file sekunder di dalam folder lain daripada aplikasi halaman kanvas.
- verifikasi sesi facebook. jangan pernah mengandalkan cookie, sebuah string kueri, atau data yang dihasilkan dalam aplikasi untuk memverifikasi pengguna saat ini. aplikasi facebook dengan sesi menyediakan informasi yang mereka dapat selalu memeriksa sebelum membuat permintaan atau pemuatan informasi.
- gunakan membolehkan akses server. jika permohonan anda tidak menggunakan AJAX atau sebaliknya tidak mengajukan permintaan menggunakan JavaScript Facebook API, mengambil keuntungan dari fitur whitelist server dalam aplikasi sifat-sifat dan hanya memperbolehkan permintaan dari server Anda.
- memahami kode pihak ketiga. luangkan waktu untuk memeriksa kode apapun yang diberikan oleh pengembang lain, seperti JavaScript tools atau jaringan periklanan penerima file, sebelum memasukkan mereka dalam aplikasi anda. secara khusus, kode pihak ketiga yang arnesses sesi pengguna rahasia melanggar aturan-aturan yang diberikan oleh facebook.
- jangan pernah mengandalkan JavaScript kebingungan atau kompresi untuk menyembunyikan kelemahan dalam halaman aplikasi. teknik dapat memperlambat penyerang untuk sementara waktu, tetapi mereka selalu dapat bekerja di sekitar atau terbalik.
- mendidik pengguna anda. hindari menggabungkan pola desain yang melatih pengguna untuk menerima praktek-praktek yang buruk, misalnya, memasukkan password pihak ketiga. berkomunikasi dengan jelas kebijakan privasi anda, penyimpanan data, dan informasi keamanan.
pelajaran facebook
- hentikan permainan. hampir semua pengguna contoh informasi dan konten pada dasarnya publik. banyak pengguna memiliki pemahaman mengenai privasi dan kontrol tidak tercermin oleh temuan-temuan dari seri ini dan lain-lain. entah mengambil tindakan yang diperlukan untuk mengatasi masalah ini, atau menjatuhkan ilusi kendali pribadi.
- bicaralah dengan pengembang. beberapa sumber daya yang ada untuk membantu para pengembang memulai platform, tetapi Facebook telah menerbitkan apalagi mengingatkan pengembang konten keamanan. jika anda mengaitkan merek anda dengan kode pihak ketiga , anda memiliki reponsibility untuk membantu menjamin keamanan kode tersebut.
- benar-benar memverifikasi aplikasi. verified program aplikasi saat ini tampaknya tidak membahas kelemahan keamanan dasar. ketika membuka pintu air untuk setiap aplikasi memiliki keuntungan, juga menimbulkan risiko serius yang dapat membenarkan menempatkan beberapa batasan atau cek di tempat.
- membatasi akses aplikasi. Meskipun menggembirakan mendengar bahwa facebook akan menambahkan kontrol akses granular untuk menanggapi privasi komisaris kanada,itu menyedihkan bahwa langkah-langkah seperti itu begitu lama dan masih hampir satu tahun lepas dari implementasi penuh.
- ambil clickjacking serius. serial ini hanya mulai menunjukkan implikasi dari clickjacking. 1x-klik otorisasi aplikasi, bahkan ketika satu mengecualikan dari platform, halaman.clickjacking hanya menambah bahaya di facebook.
- meningkatkan permintaan verifikasi. the facebook JavaScript API dapat menyediakan banyak fungsi yang berguna, tapi juga membuka pintu untuk permintaan API sederhana dengan hanya sebuah sesi rahasia. ada cara lain untuk memastikan bahwa permintaan datang secara sah dari suatu aplikasi bukan penyerang.
- membedakan merek anda. dengan platform facebook saat ini, setiap kerentanan dalam aplikasi pihak ketiga menjadi kerentanan facebook. entah pengguna harus dapat mempercayai aplikasi ke tingkat yang sama seperti facebook, atau facebook harus lebih jelas membedakan konten pihak ketiga.
- mendidik pengguna anda. orang-orang mengklik aplikasi tanpa memikirkan kedua risiko aplikasi berbahaya atau mungkin masalah keamanan. pengguna dapat mencari informasi pribadi untuk berbagi dengan teman-teman, tapi gagal menyadari betapa informasi yang digunakan oleh kode pihak ketiga.
anatomi attack
kini hadir penjelasan yang lebih rinci tentang bagaimana hacks FAXX memungkinkan untuk serangan virus dan mencuri informasi pengguna, bersama dengan sampel kode.
misalkan aplikasi facebook imajiner "faceplant" mencakup sebuah parameter "wasit" pada halaman muka, yaitu
lebih lanjut menganggap bahwa salah satu link di dalam halaman rumah kode ref ditambahkan parameter yang diberikan kepada "href" atribut, yaitu
akhirnya, misalkan aplikasi tidak menyaring "ref" parameter sama sekali, misalnya kode PHP echo '
anda mungkin dapat melihat, yang "ref" parameter memperkenalkan sebuah cross-site scripting lubang. misalnya, loading halaman
karena atribut sumber untuk iframe adalah sewenang-wenang, orang bisa memuat halaman yang mengeksekusi "skrip berbahaya", seperti malware pengiriman atau browser eksploitasi.
sejauh ini, kita sudah cukup menggambarkan standar lubang XSS. namun dalam aplikasi facebook, menambahkan fb: iframe tidak hanya memuat iframe standar. URI dari halaman iframe ditambahkan dengan serangkaian sesi parameter, seperti facebook user ID dan aplikasi saat ini API key. untuk membuat permintaan ke facebook API, bagaimanapun, memerlukan sesi rahasia, atau fb_sig_ss parameter. namun parameter ini hanya ditambahkan ke iframe jika URI berasal dari jalan yang sama aplikasi itu sendiri. jadi, dalam contoh di atas, http://eviluri/ tidak akan memiliki akses ke sesi rahasia.
di dalam FBML non-aplikasi, kita dapat cukup masukkan JavaScript yang memeriksa parameter halaman, karena halaman kanvas aplikasi akan memiliki sesi rahasia. untuk aplikasi FBML, hal-hal yang mendapat sedikit rumit - dimasukkan JavaScript tersaring sebagai FBJS dan mungkin tidak memungkinkan serangan yang dapat diandalkan. namun, dimakamkan di kode sumber dari setiap halaman aplikasi pada FBML apps.facebook.com adalah variabel JavaScript "source_url," yang memberikan URI langsung dari aplikasi yang load dari facebook FBML. mengakses URI ini secara langsung dengan menambahkan parameter sesi yang valid akan membuka sumber FBML ke browser web anda. sementara browser tidak akan mengerti semua FBML, itu akan tetap memuat elemen HTML sebagai HTML - termasuk elemen script.
ini membawa apa yang saya sebut sebagai trik injeksi ganda. jika anda menemukan sebuah lubang XSS di halaman di apps.facebook.com, anda sudah benar-benar menemukan sebuah lubang XSS di halaman yang FBML asli facebook load. dengan demikian anda dapat menerapkan XSS yang sama lubang ke halaman asli. trik bekerja seperti ini: gunakan XSS lubang di apps.facebook.com URI untuk memasukkan fb: iframe yang merujuk pada halaman asli URI. karena halaman ini di-host di jalan yang sama seperti aplikasi, ia akan menerima sesi rahasia. sebagai contoh,
(sekali lagi, ini harus dikodekan dengan benar, tapi saya meninggalkan unencoded contoh-contoh ini untuk membuat proses jelas lebih mudah.) JavaScript dapat dengan mudah memeriksa URI dari halaman yang akan terbuka untuk mengakses rahasia sesi.
tetapi bahkan metode ini tidak selalu bekerja. jika halaman aplikasi langsung mencakup naskah sebelum kode yang disisipkan, hal itu mungkin gagal untuk mengeksekusi dalam ketiadaan facebook pengolahan, dan dengan demikian kode yang dimasukkan tidak akan dimuat. jadi kita dapat menggunakan trik lain untuk mendapatkan sesi rahasia. daripada memasukkan langsung JavaScript, memasukkan iframe lain, seperti dalam
sekarang perhatikan bahwa iframe kedua ini adalah dimuat oleh halaman aplikasi, yang telah menerima sesi rahasia dari fb: iframe. oleh karena itu, pengarah iframe untuk kedua akan berisi sesi rahasia. halaman di load hanya dapat http://eviluri/ JavaScript yang memeriksa pengarah dan merebut sesi rahasia. kode ini kemudian dapat membuat permintaan API facebook bahwa aplikasi itu sendiri berwenang untuk membuat bawah sesi pengguna.
untuk informasi lebih rinci tentang bagaimana hal ini akan bekerja, download viraluri.txt dan download eviluri.txt.
ini adalah dua file teks dengan kode sumber HTML untuk dua file untuk digunakan dalam serangan terhadap flixster (film), memanfaatkan lubang sebelumnya dilaporkan dalam aplikasi (dan sekarang msh tetap). file pertama menggunakan clickjacking dan yang tak terlihat iframe untuk memuat sebuah apps.facebook.com URI yang menyisipkan http://eviluri/ seperti di atas. file kedua merupakan kode yang satu akan menjadi tuan rumah pada http://eviluri/ untuk kemudian mencuri informasi pengguna, memasang link ke http://viraluri/ (alamat di mana file pertama akan di-host) pada profil pengguna, dan mengirimkan pemberitahuan kepada pengguna tertentu dengan link ke http://viraluri/ juga. akhirnya, kode meneruskan user untuk http://innocenturi/ untuk menghindari kecurigaan. ..
...........so..intinya, dengan memanfaatkan celah ini, tidak mnutup kmungkinan bsa menjadi "Universal H4ck3d" besar2n pada smua pngguna fb...
dgn memanfaatkan 'facebook API key' atau aplikasi developer facebook, kita bsa aja mmbuat applikasi 'liar' yg komersial dgn tujuan menghibur (sprti games,fun,dll)...<-ini sebgai kedok/topeng....
dgn di beri ijin kuasa 'api key' dari pihak facebook, kita bsa dgn mudah mnghubungkn antara account facebook & email se2org.
celah ini kalau dimanfaatkan oleh org2 yg berniat jahat, bisa jadi berbahaya dan serius...
ringkasan temuan :
- banyak aplikasi facebook, bahkan banyak digunakan orang2 atau tampaknya yang dapat dipercaya, tpi kurangnya dasar keamanan.
- kerentanan ditemukan dalam berbagai aplikasi facebook.
- masing-masing kerentanan tersebut dapat "dieksploitasi" untuk mengeksekusi "JavaScript" berbahaya, seperti malware pengiriman.
- selain itu, lubang tersebut memungkinkan seorang penyerang untuk mengakses informasi profil, termasuk informasi pribadi, status update, dan foto, dari pengguna korban dan teman-teman mereka.
- kerentanan ini dapat digunakan untuk mengirimkan pemberitahuan atau feed posting cerita, memungkinkan untuk penyebaran virus..
- sementara lubang mempengaruhi setiap aplikasi pengguna yang telah diotorisasi aplikasi, "clickjacking" sering dapat menargetkan pengguna yang belum..
- seri berfokus pada kerentanan dalam aplikasi yang sah, tapi aplikasi berbahaya, yang dapat dengan mudah mengeksploitasi clickjacking, juga telah dicatat oleh orang lain.
- semua kerentanan yang dilaporkan dalam seri telah ditambal, "tetapi serangan yang mengeksploitasi lubang aplikasi tetap mungkin".
- mencegah masalah masa depan karena kerentanan aplikasi memerlukan tindakan dari kedua aplikasi pengembang dan pihak facebook. .
statistik :
- seri menunjukkan kerentanan yang mempengaruhi lebih dari 9.700 aplikasi facebook.
- lebih dari setengahnya dipengaruhi kerentanan aplikasi yang telah "lulus program aplikasi facebook verified".
- enam dari aplikasi hack peringkat di antara sepuluh oleh bulanan pengguna aktif di penerbitan.
- bulanan yang dipublikasikan pengguna aktif aplikasi penting untuk hacking total lebih dari 218 juta.
- sementara gambar sebelumnya termasuk tumpang tindih, setiap kerentanan terpengaruh semua pengguna yang telah diotorisasi aplikasi, apakah sedang aktif atau tidak.
- hampir dua pertiga dari kerentanan pada paruh pertama dari seri clickjacking diperbolehkan untuk serangan yang akan mempengaruhi semua pengguna facebook. (aplikasi pada paruh kedua dari seri "tidak diperiksa" hanya untuk clickjacking karena kendala waktu.)
- kerentanan dalam aplikasi populer yang memungkinkan untuk clickjacking berarti hampir semua pengguna facebook bisa menjadi mangsa ke FAXX hack.
- tujuh dari sepuluh saat ini pengembang aplikasi oleh gabungan bulanan pengguna aktif memiliki paling sedikit satu aplikasi rentan.
- sembilan dari pengembang dihubungi mengambil alih seminggu untuk membangun sebuah patch untuk kerentanan aplikasi..
sedikit pelajaran untuk developer/pengembang
- membersihkan semua masukan. Itu termasuk setiap bit data diproses oleh aplikasi tersebut, apakah diambil dari profil pengguna facebook, diambil dari database, disampaikan dengan bentuk, atau yang diterima dari string alamat. jangan pernah beranggapan bahwa parameter tertentu akan menjadi bersih atau dari tipe yg diharapkan.
- membersihkan semua keluaran. ketika menampilkan pemberitahuan atau pesan kesalahan, beban string yang telah ditentukan daripada menggunakan input dinamis. jgn pernah menggunakan kembali alamat halaman tanpa injeksi fitering untuk usaha. filter segala informasi yang anda output ke halaman aplikasi AJAX, atau melalui sebuah antarmuka.
- secara umum, pengguna tidak boleh diizinkan untuk masukan HTML, FBML, atau kaya-format teks. jika memungkinkan kaya-data teks, gunakan pre-built, kode diuji untuk memproses dan menampilkan itu, rathering daripada mencoba untuk membuat filter sendiri.
- banyak kelemahan muncul di halaman sekunder, seperti iklan loader atau interface AJAX. verifikasi tindakan pencegahan keamanan di setiap bagian dari aplikasi. jika memungkinkan, pertimbangkan untuk menyimpan file sekunder di dalam folder lain daripada aplikasi halaman kanvas.
- verifikasi sesi facebook. jangan pernah mengandalkan cookie, sebuah string kueri, atau data yang dihasilkan dalam aplikasi untuk memverifikasi pengguna saat ini. aplikasi facebook dengan sesi menyediakan informasi yang mereka dapat selalu memeriksa sebelum membuat permintaan atau pemuatan informasi.
- gunakan membolehkan akses server. jika permohonan anda tidak menggunakan AJAX atau sebaliknya tidak mengajukan permintaan menggunakan JavaScript Facebook API, mengambil keuntungan dari fitur whitelist server dalam aplikasi sifat-sifat dan hanya memperbolehkan permintaan dari server Anda.
- memahami kode pihak ketiga. luangkan waktu untuk memeriksa kode apapun yang diberikan oleh pengembang lain, seperti JavaScript tools atau jaringan periklanan penerima file, sebelum memasukkan mereka dalam aplikasi anda. secara khusus, kode pihak ketiga yang arnesses sesi pengguna rahasia melanggar aturan-aturan yang diberikan oleh facebook.
- jangan pernah mengandalkan JavaScript kebingungan atau kompresi untuk menyembunyikan kelemahan dalam halaman aplikasi. teknik dapat memperlambat penyerang untuk sementara waktu, tetapi mereka selalu dapat bekerja di sekitar atau terbalik.
- mendidik pengguna anda. hindari menggabungkan pola desain yang melatih pengguna untuk menerima praktek-praktek yang buruk, misalnya, memasukkan password pihak ketiga. berkomunikasi dengan jelas kebijakan privasi anda, penyimpanan data, dan informasi keamanan.
pelajaran facebook
- hentikan permainan. hampir semua pengguna contoh informasi dan konten pada dasarnya publik. banyak pengguna memiliki pemahaman mengenai privasi dan kontrol tidak tercermin oleh temuan-temuan dari seri ini dan lain-lain. entah mengambil tindakan yang diperlukan untuk mengatasi masalah ini, atau menjatuhkan ilusi kendali pribadi.
- bicaralah dengan pengembang. beberapa sumber daya yang ada untuk membantu para pengembang memulai platform, tetapi Facebook telah menerbitkan apalagi mengingatkan pengembang konten keamanan. jika anda mengaitkan merek anda dengan kode pihak ketiga , anda memiliki reponsibility untuk membantu menjamin keamanan kode tersebut.
- benar-benar memverifikasi aplikasi. verified program aplikasi saat ini tampaknya tidak membahas kelemahan keamanan dasar. ketika membuka pintu air untuk setiap aplikasi memiliki keuntungan, juga menimbulkan risiko serius yang dapat membenarkan menempatkan beberapa batasan atau cek di tempat.
- membatasi akses aplikasi. Meskipun menggembirakan mendengar bahwa facebook akan menambahkan kontrol akses granular untuk menanggapi privasi komisaris kanada,itu menyedihkan bahwa langkah-langkah seperti itu begitu lama dan masih hampir satu tahun lepas dari implementasi penuh.
- ambil clickjacking serius. serial ini hanya mulai menunjukkan implikasi dari clickjacking. 1x-klik otorisasi aplikasi, bahkan ketika satu mengecualikan dari platform, halaman.clickjacking hanya menambah bahaya di facebook.
- meningkatkan permintaan verifikasi. the facebook JavaScript API dapat menyediakan banyak fungsi yang berguna, tapi juga membuka pintu untuk permintaan API sederhana dengan hanya sebuah sesi rahasia. ada cara lain untuk memastikan bahwa permintaan datang secara sah dari suatu aplikasi bukan penyerang.
- membedakan merek anda. dengan platform facebook saat ini, setiap kerentanan dalam aplikasi pihak ketiga menjadi kerentanan facebook. entah pengguna harus dapat mempercayai aplikasi ke tingkat yang sama seperti facebook, atau facebook harus lebih jelas membedakan konten pihak ketiga.
- mendidik pengguna anda. orang-orang mengklik aplikasi tanpa memikirkan kedua risiko aplikasi berbahaya atau mungkin masalah keamanan. pengguna dapat mencari informasi pribadi untuk berbagi dengan teman-teman, tapi gagal menyadari betapa informasi yang digunakan oleh kode pihak ketiga.
anatomi attack
kini hadir penjelasan yang lebih rinci tentang bagaimana hacks FAXX memungkinkan untuk serangan virus dan mencuri informasi pengguna, bersama dengan sampel kode.
misalkan aplikasi facebook imajiner "faceplant" mencakup sebuah parameter "wasit" pada halaman muka, yaitu
- Code: Select all
http://apps.facebook.com/faceplant/?ref=install
lebih lanjut menganggap bahwa salah satu link di dalam halaman rumah kode ref ditambahkan parameter yang diberikan kepada "href" atribut, yaitu
akhirnya, misalkan aplikasi tidak menyaring "ref" parameter sama sekali, misalnya kode PHP echo '
anda mungkin dapat melihat, yang "ref" parameter memperkenalkan sebuah cross-site scripting lubang. misalnya, loading halaman
- Code: Select all
http://apps.facebook.com/faceplant/?ref = ">
- Code: Select all
http://apps.facebook.com/faceplant/?ref = ">
karena atribut sumber untuk iframe adalah sewenang-wenang, orang bisa memuat halaman yang mengeksekusi "skrip berbahaya", seperti malware pengiriman atau browser eksploitasi.sejauh ini, kita sudah cukup menggambarkan standar lubang XSS. namun dalam aplikasi facebook, menambahkan fb: iframe tidak hanya memuat iframe standar. URI dari halaman iframe ditambahkan dengan serangkaian sesi parameter, seperti facebook user ID dan aplikasi saat ini API key. untuk membuat permintaan ke facebook API, bagaimanapun, memerlukan sesi rahasia, atau fb_sig_ss parameter. namun parameter ini hanya ditambahkan ke iframe jika URI berasal dari jalan yang sama aplikasi itu sendiri. jadi, dalam contoh di atas, http://eviluri/ tidak akan memiliki akses ke sesi rahasia.
di dalam FBML non-aplikasi, kita dapat cukup masukkan JavaScript yang memeriksa parameter halaman, karena halaman kanvas aplikasi akan memiliki sesi rahasia. untuk aplikasi FBML, hal-hal yang mendapat sedikit rumit - dimasukkan JavaScript tersaring sebagai FBJS dan mungkin tidak memungkinkan serangan yang dapat diandalkan. namun, dimakamkan di kode sumber dari setiap halaman aplikasi pada FBML apps.facebook.com adalah variabel JavaScript "source_url," yang memberikan URI langsung dari aplikasi yang load dari facebook FBML. mengakses URI ini secara langsung dengan menambahkan parameter sesi yang valid akan membuka sumber FBML ke browser web anda. sementara browser tidak akan mengerti semua FBML, itu akan tetap memuat elemen HTML sebagai HTML - termasuk elemen script.
ini membawa apa yang saya sebut sebagai trik injeksi ganda. jika anda menemukan sebuah lubang XSS di halaman di apps.facebook.com, anda sudah benar-benar menemukan sebuah lubang XSS di halaman yang FBML asli facebook load. dengan demikian anda dapat menerapkan XSS yang sama lubang ke halaman asli. trik bekerja seperti ini: gunakan XSS lubang di apps.facebook.com URI untuk memasukkan fb: iframe yang merujuk pada halaman asli URI. karena halaman ini di-host di jalan yang sama seperti aplikasi, ia akan menerima sesi rahasia. sebagai contoh,
- Code: Select all
http://apps.facebook.com/faceplant/?ref = ">
- Code: Select all
http://apps.facebook.com/faceplant/?ref = ">
(sekali lagi, ini harus dikodekan dengan benar, tapi saya meninggalkan unencoded contoh-contoh ini untuk membuat proses jelas lebih mudah.) JavaScript dapat dengan mudah memeriksa URI dari halaman yang akan terbuka untuk mengakses rahasia sesi.
tetapi bahkan metode ini tidak selalu bekerja. jika halaman aplikasi langsung mencakup naskah sebelum kode yang disisipkan, hal itu mungkin gagal untuk mengeksekusi dalam ketiadaan facebook pengolahan, dan dengan demikian kode yang dimasukkan tidak akan dimuat. jadi kita dapat menggunakan trik lain untuk mendapatkan sesi rahasia. daripada memasukkan langsung JavaScript, memasukkan iframe lain, seperti dalam
- Code: Select all
http://apps.facebook.com/faceplant/?ref = ">
sekarang perhatikan bahwa iframe kedua ini adalah dimuat oleh halaman aplikasi, yang telah menerima sesi rahasia dari fb: iframe. oleh karena itu, pengarah iframe untuk kedua akan berisi sesi rahasia. halaman di load hanya dapat http://eviluri/ JavaScript yang memeriksa pengarah dan merebut sesi rahasia. kode ini kemudian dapat membuat permintaan API facebook bahwa aplikasi itu sendiri berwenang untuk membuat bawah sesi pengguna.
untuk informasi lebih rinci tentang bagaimana hal ini akan bekerja, download viraluri.txt dan download eviluri.txt.
ini adalah dua file teks dengan kode sumber HTML untuk dua file untuk digunakan dalam serangan terhadap flixster (film), memanfaatkan lubang sebelumnya dilaporkan dalam aplikasi (dan sekarang msh tetap). file pertama menggunakan clickjacking dan yang tak terlihat iframe untuk memuat sebuah apps.facebook.com URI yang menyisipkan http://eviluri/ seperti di atas. file kedua merupakan kode yang satu akan menjadi tuan rumah pada http://eviluri/ untuk kemudian mencuri informasi pengguna, memasang link ke http://viraluri/ (alamat di mana file pertama akan di-host) pada profil pengguna, dan mengirimkan pemberitahuan kepada pengguna tertentu dengan link ke http://viraluri/ juga. akhirnya, kode meneruskan user untuk http://innocenturi/ untuk menghindari kecurigaan. ..
...........so..intinya, dengan memanfaatkan celah ini, tidak mnutup kmungkinan bsa menjadi "Universal H4ck3d" besar2n pada smua pngguna fb...
Author
hai saya farland.seseorang yg sedang memahami dan menikmati dunia blog... I'am Blogger and Javascript Programmer.
0 comments:
Post a Comment
komentar anda sangat penting utk kemajuan blog ini.trimakasih utk kunjungannya...