Pertimbangan pembangunan keselamatan aplikasi


Jabatan Keselamatan Sina telah komited untuk mempromosikan keselamatan produk pada platform terbuka supaya aplikasi Weibo mempunyai pengalaman pengguna yang lebih baik dan fungsi yang lebih selamat. Berdasarkan situasi semasa, kami mendapati bahawa sesetengah aplikasi mempunyai kelemahan atau kecacatan keselamatan yang biasa berikut Selain menjejaskan aplikasi itu sendiri, kelemahan keselamatan ini juga akan menyebabkan kerugian kepada pengguna.

aplikasi rahsia bocor

app_secret adalah satu-satunya pengesahan untuk aplikasi meminta platform terbuka untuk menjana access_token Tujuan menggunakan app_secret adalah untuk memastikan aplikasi itu digunakan oleh pembangun sendiri.


Aplikasi yang berbeza mempunyai sumber panggilan antara muka yang berbeza dan kebenaran API pada platform terbuka. Jika sumber antara muka aplikasi disalahgunakan dan operasi berniat jahat seperti menyiarkan maklumat spam dan menambah perhatian dilakukan, platform terbuka akan menyekat sumber dan kebenaran aplikasi, yang akan menjejaskan panggilan API biasa aplikasi secara langsung. Oleh itu, pembangun adalah perlu untuk melindungi keselamatan aplikasi mereka sendiri dan menghalang sumber keselamatan yang sepadan daripada digunakan secara haram, untuk memastikan operasi biasa aplikasi.


Adalah disyorkan untuk menyimpan rahsia aplikasi pada pelayan aplikasi Untuk melindungi keselamatan aplikasi anda dengan lebih baik, adalah disyorkan untuk mengikat IP pelayan aplikasi dalam tetapan pusat pengurusan/keselamatan.


anquan1.png


Jika anda mendapati rahsia aplikasi aplikasi anda telah dibocorkan, sila pergi ke pusat pengurusan aplikasi untuk menetapkan semula dengan segera http://open.weibo.com/apps/


Sebab biasa kebocoran rahsia apl:

1 Rahsia apl muncul dalam kod sumber halaman atau URL, yang boleh diperoleh dengan melihat terus kod sumber.

2. app_secret disimpan dalam program klien itu sendiri, dan semua aplikasi asli (seperti aplikasi desktop iOS, Android atau Windows) boleh diperoleh melalui kod yang dinyahkompilasi.

3 Protokol penghantaran selamat HTTPS tidak digunakan, dan penyerang memperolehnya melalui penghidu rangkaian.

access_token bocor

access_token ialah ID sesi yang digunakan oleh pengguna untuk mengakses platform terbuka melalui aplikasi Aplikasi mesti dilindungi untuk mengelakkannya daripada dicuri oleh pihak ketiga.


Cara biasa membocorkan access_token:

1 Access_token disimpan dalam kuki atau kod halaman, dan penyerang mencuri token pengguna melalui kelemahan xss.

2 Pelayan aplikasi mempunyai kelemahan suntikan SQL, menyebabkan token pengguna bocor.


Kerentanan CSRF dalam mengikat pengguna Weibo

Jika aplikasi anda mempunyai sistem akaun sendiri dan mempunyai fungsi mengikat pengguna Weibo untuk log masuk, sila semak sama ada antara muka yang mengikat mempunyai fungsi untuk menghalang serangan CSRF. Parameter keadaan antara muka kebenaran boleh digunakan untuk menghalang serangan CSRF semasa proses kebenaran Untuk penggunaan terperinci, sila rujuk versi terkini kod SDK, https://github.com/ElmerZhang/WeiboSDK.

Ikuti dan siarkan kelemahan CSRF di Weibo

Untuk maklumat lanjut tentang kelemahan CSRF, sila rujuk di sini. http://baike.baidu.com/view/1609487.htm


Kerentanan CSRF dalam aplikasi Weibo biasanya ditemui dalam antara muka penulisan seperti menambah pengikut dan menyiarkan di Weibo. Perkara yang dilihat pengguna ialah terdapat beberapa perkara yang tidak dapat dijelaskan di Weibo . Mengikuti atau memajukan beberapa siaran Weibo.


Pembangun boleh menghalang serangan CSRF dengan menyemak sama ada perujuk itu sah atau menambah csrf_token pada borang.

Pemalsuan identiti pengguna

Selepas melengkapkan pengesahan keizinan OAuth 2.0, aplikasi boleh mendapatkan access_token yang melambangkan identiti pengguna, yang biasanya digunakan terus untuk panggilan antara muka. Walau bagaimanapun, sesetengah aplikasi perlu mendapatkan uid pengguna sebagai bukti kelayakan pengesahan yang dikaitkan dengan sistem akaun mereka sendiri untuk menyediakan lebih banyak kandungan perkhidmatan aplikasi itu sendiri. Situasi biasa termasuk aplikasi mudah alih dan aplikasi perkhidmatan storan rangkaian yang menggunakan Weibo SSO SDK.


Dalam senario ini, kelemahan biasa ialah:

1 Pelanggan secara langsung menggunakan uid yang dikembalikan oleh antara muka kebenaran atau mengekstrak uid dalam access_token, dan mengembalikan pelayan aplikasi sendiri sebagai bukti kelayakan pengesahan. Proses penghantaran ini boleh dipintas secara haram dan identiti pengguna boleh dipalsukan dengan mengganggu uid.

2. Pelanggan menghantar access_token kembali ke pelayannya sendiri, dan pelayan mengekstrak uid sebagai bukti kelayakan pengesahan, tetapi tidak mengesahkan kesahihan access_token. Pada masa ini, dengan menipu pengguna A untuk membenarkan aplikasi X, mendapatkan access_token dan menyerahkannya kepada pelayan aplikasi Y, kelayakan pengguna A untuk aplikasi Y boleh diperolehi dan kandungan perkhidmatan pengguna dalam aplikasi Y boleh diakses.


Cadangan pembaikan:

1 Jangan terus menggunakan uid tanpa maklumat kebenaran sebagai pertukaran untuk kelayakan pengesahan perkhidmatan anda sendiri. Anda hanya boleh menggunakan access_token.

2. Untuk mengekstrak uid dalam access_token di bahagian pelayan, anda perlu menghubungi antara muka OAuth2/get_token_info platform terbuka. Apabila menggunakan antara muka ini, anda juga perlu menyemak sama ada kunci aplikasi yang dimiliki oleh access_token ialah kunci aplikasi aplikasi klien anda sendiri. Hanya mereka yang mempunyai sumber Appkey yang konsisten dibenarkan menukar bukti kelayakan pengesahan untuk perkhidmatan mereka sendiri.

3. Periksa semua akses_tokens terikat yang disimpan dan ketahui bahawa uid Sina dalam token_akses tidak konsisten dengan uid Sina yang terikat, token_akses yang dibenarkan oleh kunci aplikasi aplikasi bukan pelanggan sendiri, token_akses tamat tempoh dan situasi luar biasa lain perlu dibatalkan untuk pengguna yang tidak normal ini.

Klik kerentanan rampasan

Tapak hasad membenamkan tapak aplikasi Weibo dalam iframe dan gunakan teknologi seperti tindanan telus HTML untuk merampas operasi klik pengguna. Untuk mencapai tujuan mendorong pengguna untuk melakukan tindakan berniat jahat dan menambah perhatian.


Cadangan pembaikan:


1 Untuk aplikasi yang tidak perlu di iframe, anda boleh memilih salah satu kaedah berikut.

. =locaiton;}
    • 2.

a. Tentukan sama ada tetingkap induk adalah halaman yang dibenarkan

b.
    • Keselamatan aplikasi meliputi julat yang luas Di samping memberi perhatian untuk mengelakkan isu keselamatan biasa di atas, pembangun juga harus memberi perhatian kepada trend keselamatan terkini, memahami kelemahan keselamatan produk mereka sendiri, dan yang lebih penting, menambah baik produk dan pembangun Hanya dengan cara ini masalah keselamatan dapat dikurangkan sebaik mungkin. Jika kelemahan keselamatan berlaku, anda boleh menghubungi kami tepat pada masanya dan kami akan memberikan penyelesaian secepat mungkin.


←
→