Warung Bebas

Saturday, February 25, 2012

courtesy of permatanet.com Hah? Apa nggak salah nih. Https kan secure, mana mungkin bisa dibajak. Benar, tidak ada yang salah kok. Kalau anda sudah membaca dua artikel saya sebelumnya, understanding https dan session hijacking basics , anda akan mengerti bahwa dalam sebuah koneksi https tidak mungkin dibajak. Namun dengan trik yang akan saya jelaskan ini kita akan bisa membajak session https. Cookie Basic Cookie merupakan teknik server untuk membuat browser “menyimpan” data di browser, dan meminta browser mengirimkannya kembali ke server berdasarkan kriteria tertentu. Cookie dikirimkan dari browser ke server atau dari server ke browser sebagai bagian dari request/response http yang disisipkan dalam header http. Cookie terdiri dari beberapa field: name, value, path, domain, secure bit,expired time. Dalam sebuah request, apakah browser akan mengirimkan suatu cookie tergantung dari field-field tersebut, apakah expired atau belum, apakah URL yang di-request cocok dengan domain+path, dan apakah koneksi melalui https atau tidak. Insecure Cookie Cookie yang secure bitnya diaktifkan bukan artinya cookie tersebut di-enkrip. Field secure pada cookie, digunakan untuk membatasi pengiriman kembali data di cookie ke server hanya melalui koneksi https. Bila field ini dikosongkan, maka artinya cookie tersebut boleh dikirim kembali ke server pada koneksi http maupun https (any type of connection). Sedangkan bila secure bit diaktifkan, maka cookie tersebut haram dikirimkan melalui http. Sniffing Cookie Session hijacking dilakukan dengan mencuri sessionid. Dalam kasus ini saya membahas sessionid yang disimpan dalam cookie. Kalau seorang attacker berhasil mencuri cookie yang mengandung sessionid, maka session korban telah sukses dibajak attacker. Salah satu cara mencuri cookie adalah dengan teknik sniffing, yaitu dengan menguping percakapan http yang dilakukan orang lain. Dengan sniffing paket http yang lalu lalang, maka orang bisa menjaring cookie. Namun sniffing cookie hanya bisa dilakukan pada koneksi yang tidak ter-enkrip, yaitu http biasa. Sniffing cookie tidak mungkin dilakukan pada koneksi https. CSRF Attack to Trigger Cookie Sending over HTTP Apabila cookie tidak di-set https only, artinya kita bisa memaksa korban membuat request http (bukan https) ke URL yang termasuk dalam domain+path cookie yang ditarget attacker sehingga dalam request tersebut cookie akan disertakan juga (naked, not encrypted). Jangan kuatir, request tersebut tidak harus ke URL yang valid, bahkan ke URL yang tidak ada sekalipun cookie tetap dikirimkan asalkan URLnya termasuk dalam domain dan path cookie. Di sini kita tidak peduli dengan response, terserah server mau jawab apa (200 OK, 404 Not Found, 403 Forbidden dsb), yang penting browser melakukan request yang mengandung cookie melalui koneksi yang tidak ter-enkrip. CSRF attack adalah serangan yang mirip dengan XSS. Serangan ini hanya menerang client, dan tidak berpengaruh pada server. Inti dari serangan ini adalah pada REQUEST, yaitu bagaimana bisa membuat korban melakukan request HTTP untuk memaksa korban berbuat sesuatu yang tidak diinginkannya. Salah satu metode yang populer dalam CSRF adalah dengan memanfaatkan tag image (saya gunakan tag ini juga dalam artikel saya menjaring password klikBCA ). Bila browser menemukan tag image, maka serta merta dia akan melakukan request ke isi dari attribut src, begitu juga bila javascript mengubah atribut src ini, maka browser juga akan melakukan request. Triknya adalah dengan mengisi atribut src dengan URL yang termasuk dalam domain+path cookie yang ditarget, lalu mengirimkan halaman html yang mengandung tag image tersebut ke korban. Begitu korban membuka halaman itu, maka browsernya akan mengirimkan request tanpa disadari korban, that’s it CSRF. Hijacking PermataNet Session warning PermataNet adalah situs internet banking bank permata. Web server PermataNet menerima koneksi yang masuk melalui http maupun https, namun setiap koneksi yang masuk melalui kanal http, akan diberi peringatan dan di-redirect menuju koneksi https. Ini bagus, mendidik user untuk selalu menggunakan https di situsnya. Namun bila tidak hati-hati justru ini menjadi celah. Kenapa saya sebut ini adalah celah? Karena dengan membuka dua kanal, maka memungkinkan bagi seseorang untuk mengirimkan http request (bukan https). Bila cookie tidak diset https only, maka ada peluang naked cookie terkirim melalui jaringan. Ketika browser membuka http://www.permatanet.com , maka server akan menjawab dengan HTTP 403 (Access Forbidden). Pada tahap ini tidak ada cookie yang diminta server untuk disimpan browser. Selanjutnya browser akan membuka koneksi ke URL: https://www.permatanet.com/login/login.asp . Berikut percakapan yang terjadi: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 https://www.permatanet.com/login/login.asp GET /login/login.asp HTTP/1.1 Host: www.permatanet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: id,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 200 OK Server: Microsoft-IIS/5.0 Date: Sat, 10 Jan 2009 07:54:35 GMT Content-Length: 18481 Content-Type: text/html Expires: Sat, 10 Jan 2009 07:54:36 GMT Set-Cookie: ASPSESSIONIDSSDCARRA=OJBNBHIDDICNKDOODCAKBPKJ; path=/ Cache-Control: private Perhatikan header Set-Cookie pada response yang artinya: “Hey browser! tolong simpan data ini, dan kirimkan kembali ke aku setiap kamu request ke host www.permatanet.com, lewat koneksi http atau https terserah.” Cookie ini adalah cookie yang menyimpan sessionid, jadi kalau ingin membajak session PermataNet, attacker harus mencuri cookie ini. Setelah saya login (saya memang nasabah permata), cookie itu tetap menjadi tempat penyimpanan session id saya. Oke, sekarang saya sudah login, itu artinya session established, dan isi cookie itu adalah kunci untuk membajak account saya. Untuk mencuri cookie tersebut, pertama attacker harus sudah siap men-sniff jaringan saya. Kemudian attacker harus menunggu sampai saya berbuat kesalahan fatal, yaitu mengirim request yang mengandung cookie tersebut tanpa ter-enkripsi. Sebagai contoh mari kita buat jebakan berupa tag image yang URLnya mengarah pada logo permatanet. Logo tersebut aslinya URLnya adalah: https://www.permatanet.com/login/images/logo_permatanet.jpg , namun karena server permatanet membuka juga koneksi ke http, maka URLnya bisa juga menjadi: http://www.permatanet.com/login/images/logo_permatanet.jpg (tanpa http). Setiap request dengan http ke server PermataNet selalu dijawab dengan Forbidden Error (403). Tapi itu tidak penting, yang penting adalah request, bukan response. Bila saya siapkan sebuah halaman html yang mengandung tag berikut: Lalu html ini saya kirim melalui email, atau korban terbujuk untuk membuka halaman itu, maka browser korban akan mengirimkan request ke server permatanet melalui koneksi http. Bila korban saat itu sedang login (session masih valid), maka sessionid korban akan terbang tanpa perlindungan. Kalau kita coba buka url tersebut di browser, kita lihat apa yang dikirimkan browser saya dan diresponse server PermataNet: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 http://www.permatanet.com/login/images/logo_permatanet.jpg GET /login/images/logo_permatanet.jpg HTTP/1.1 Host: www.permatanet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: id,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: ASPSESSIONIDSSDCARRA=OJBNBHIDDICNKDOODCAKBPKJ;HalJini=main HTTP/1.x 403 Access Forbidden Server: Microsoft-IIS/5.0 Date: Fri, 09 Jan 2009 07:10:03 GMT Connection: close Content-Length: 1873 Content-Type: text/html Benar kan, error 403 Forbidden. Itu artinya URL itu dilarang keras diakses. Tapi lihat header Cookie pada request yang dilakukan browser. Ternyata cookie ini tetap dikirimkan ke server melalui koneksi http biasa. Ya iya laah, request ini kan ke URL yang masuk dalam domain+path cookie, dan server PermataNet tidak mensyaratkan harus dengan https. Dengan terjadinya request ini, attacker dengan mudah mengkopi isinya, dan memasukkan ke browsernya sehingga ketika dia membuka halaman PermataNet maka yang terbuka adalah account saya. Sungguh berbahaya! Pencegahan Bagaimana cara mencegah agar cookie kita tidak tercuri? Kita harus mengubah cookie PermataNet di browser kita menjadi “Https Only”. Bagi pengguna Firefox ini mudah, dengan Addon Cookie Editor kita bisa bebas meng-edit cookie. Kesimpulan Anda telah melihat bahwa men-set bit cookie menjadi https only sangat-sangat penting. Hal ini berbeda bila server tidak membuka koneksi di port 80, sehingga walaupun cookie diset any connection, tetap hanya bisa di https karena port 80 closed. Selain PermataNet, situs PayPal.com juga mengalami masalah yang sama, silakan investigasi sendiri sebagai latihan dan tuliskan hasilnya sebagai komentar di sini. No related posts. Tagged with: cookie • csrf • hijacking • internet banking • permata If you enjoyed this article, please consider sharing it

Posted by Unknown at 10:11 AM

Kalau anda tanyakan pada nasabah bca, apa alamat internet banking bca. Pasti jawabannya adalah klikbca.com. Padahal yang benar bukan itu, yang benar adalah ibank.klikbca.com, bukan www.klikbca.com atau klikbca.com saja. Kelihatannya sepele, tapi ada konsekuensi security di sini. Web yang dilindungi dengan https (trusted) hanya ibank.klikbca.com, sedangkan www.klikbca.com tidak (untrusted).
HTTP is Untrusted
Sebelumnya saya sarankan anda membaca artikel saya tentang understanding https. Anda akan memahami bahwa halaman web yang tidak dilindungi dengan SSL, tidak bisa dipercaya, untrusted. HTTPS menjamin Authentication dan Confidentiality, sehingga anda bisa yakin telah berkomunikasi dengan server yang benar dan komunikasi anda dijamin tidak didengarkan orang lain.
Dalam kasus ini confidentiality tidak penting, karena memang www.klikbca.com tidak mengandung informasi yang confidential. Serangan yang efektif adalah pada aspek Authentication. HTTP tidak menjamin Authentication sehingga anda tidak bisa benar-benar yakin bahwa halaman www.klikbca.com yang tampak di browser anda adalah berasal dari server yang benar. Konsekuensinya adalah informasi yang anda baca dan link yang ada di sana juga tidak bisa dipercaya.
Screenshot di bawah ini adalah halaman klikBCA yang normal. Terlihat dari status bar yang memperlihatkan url link button Login yang mengarah pada https://ibank.klikbca.com .
Normal
Normal
Sekarang perhatikan juga screenshot di bawah ini yang merupakan halaman klikbca.com yang telah dideface dengan teknik man-in-the-middle sehingga bila user mengklik tombol Login akan membuka halaman ibank.klikbca.com yang telah diberi “racun” XSS (lihat artikel saya yang berjudul: menjaring password klikbca dengan XSS ). Screenshot ini hanyalah simulasi man-in-the-middle di komputer saya sendiri.
defaced
defaced
Kedua screenshot tersebut sama-sama mengakses URL yang sama, yaitu www.klikbca.com, namun hasilnya berbeda tergantung dari server siapakah yang diakses. Jangan menganggap kejadian pada gambar ke-2 sulit terjadi, karena bagi orang yang paham, dengan serangan man in the middle kejadian itu bukanlah hal yang aneh dan sulit.
HTTP Rentan Terhadap Man in The Middle Attack
Salah satu jenis serangan yang berbahaya pada http adalah man in the middle. Serangan ini terjadi karena tidak adanya fitur authentication pada http, sehingga browser mengira tengah berkomunikasi dengan server yang benar, padahal sebenarnya dia tengah berkomunikasi dengan orang ke-3. Orang ke-3 ini bisa dengan bebas membaca dan mengubah request yang dikirimkan ke server dan response yang akan dikirim ke browser. Salah satu contohnya adalah pada screenshot gambar ke-2 yaitu dengan memodifikasi URL untuk link ke ibank.klikbca.com.
Kenapa Serangan ini akan Efektif
Menyesatkan orang ke halaman login palsu dengan serangan ini saya yakin akan efektif. Karena orang sudah merasa benar dengan mengakses www.klikbca.com, dan mengikuti petunjuk resmi BCA untuk mengklik tombol Login. Hal ini berbeda dengan memberikan link phishing/palsu melalui email, karena orang mungkin tidak percaya dengan link yang dikirim melalui email. Tapi saya yakin semua orang akan percaya dengan link yang ada di halaman www.klikbca.com.
Kesimpulan
Seharusnya semua halaman yang mengandung link untuk masuk ke halaman login internet banking juga harus dilindungi dengan https. Karena orang akan mengira link yang ada pada halaman www.klikbca.com pasti bisa dipercaya, padahal tidak karena tidak dilindungi https. Perhatikan Paypal.com, setiap halaman yang mengandung link Login pasti dilindungi dengan https.
Link bisa diilustrasikan seperti orang yang menunjukkan jalan. Bayangkan anda sebagai orang yang tidak tahu jalan, lalu anda bertanya pada orang di jalan. Bila orang yang anda tanya untrusted, maka kemungkinan anda dalam bahaya. Namun bila ada bertanya pada orang yang trusted, maka anda akan selamat.
Tips saya kalau ingin mengakses klikbca, jangan masuk dengan mengklik link yang ada pada halaman yang untrusted. Ketik saja langsung di browser anda https://ibank.klikbca.com .
No related posts.
Tagged with:  •  • 
 
If you enjoyed this article, please consider sharing it

0 comments em “courtesy of permatanet.com Hah? Apa nggak salah nih. Https kan secure, mana mungkin bisa dibajak. Benar, tidak ada yang salah kok. Kalau anda sudah membaca dua artikel saya sebelumnya, understanding https dan session hijacking basics , anda akan mengerti bahwa dalam sebuah koneksi https tidak mungkin dibajak. Namun dengan trik yang akan saya jelaskan ini kita akan bisa membajak session https. Cookie Basic Cookie merupakan teknik server untuk membuat browser “menyimpan” data di browser, dan meminta browser mengirimkannya kembali ke server berdasarkan kriteria tertentu. Cookie dikirimkan dari browser ke server atau dari server ke browser sebagai bagian dari request/response http yang disisipkan dalam header http. Cookie terdiri dari beberapa field: name, value, path, domain, secure bit,expired time. Dalam sebuah request, apakah browser akan mengirimkan suatu cookie tergantung dari field-field tersebut, apakah expired atau belum, apakah URL yang di-request cocok dengan domain+path, dan apakah koneksi melalui https atau tidak. Insecure Cookie Cookie yang secure bitnya diaktifkan bukan artinya cookie tersebut di-enkrip. Field secure pada cookie, digunakan untuk membatasi pengiriman kembali data di cookie ke server hanya melalui koneksi https. Bila field ini dikosongkan, maka artinya cookie tersebut boleh dikirim kembali ke server pada koneksi http maupun https (any type of connection). Sedangkan bila secure bit diaktifkan, maka cookie tersebut haram dikirimkan melalui http. Sniffing Cookie Session hijacking dilakukan dengan mencuri sessionid. Dalam kasus ini saya membahas sessionid yang disimpan dalam cookie. Kalau seorang attacker berhasil mencuri cookie yang mengandung sessionid, maka session korban telah sukses dibajak attacker. Salah satu cara mencuri cookie adalah dengan teknik sniffing, yaitu dengan menguping percakapan http yang dilakukan orang lain. Dengan sniffing paket http yang lalu lalang, maka orang bisa menjaring cookie. Namun sniffing cookie hanya bisa dilakukan pada koneksi yang tidak ter-enkrip, yaitu http biasa. Sniffing cookie tidak mungkin dilakukan pada koneksi https. CSRF Attack to Trigger Cookie Sending over HTTP Apabila cookie tidak di-set https only, artinya kita bisa memaksa korban membuat request http (bukan https) ke URL yang termasuk dalam domain+path cookie yang ditarget attacker sehingga dalam request tersebut cookie akan disertakan juga (naked, not encrypted). Jangan kuatir, request tersebut tidak harus ke URL yang valid, bahkan ke URL yang tidak ada sekalipun cookie tetap dikirimkan asalkan URLnya termasuk dalam domain dan path cookie. Di sini kita tidak peduli dengan response, terserah server mau jawab apa (200 OK, 404 Not Found, 403 Forbidden dsb), yang penting browser melakukan request yang mengandung cookie melalui koneksi yang tidak ter-enkrip. CSRF attack adalah serangan yang mirip dengan XSS. Serangan ini hanya menerang client, dan tidak berpengaruh pada server. Inti dari serangan ini adalah pada REQUEST, yaitu bagaimana bisa membuat korban melakukan request HTTP untuk memaksa korban berbuat sesuatu yang tidak diinginkannya. Salah satu metode yang populer dalam CSRF adalah dengan memanfaatkan tag image (saya gunakan tag ini juga dalam artikel saya menjaring password klikBCA ). Bila browser menemukan tag image, maka serta merta dia akan melakukan request ke isi dari attribut src, begitu juga bila javascript mengubah atribut src ini, maka browser juga akan melakukan request. Triknya adalah dengan mengisi atribut src dengan URL yang termasuk dalam domain+path cookie yang ditarget, lalu mengirimkan halaman html yang mengandung tag image tersebut ke korban. Begitu korban membuka halaman itu, maka browsernya akan mengirimkan request tanpa disadari korban, that’s it CSRF. Hijacking PermataNet Session warning PermataNet adalah situs internet banking bank permata. Web server PermataNet menerima koneksi yang masuk melalui http maupun https, namun setiap koneksi yang masuk melalui kanal http, akan diberi peringatan dan di-redirect menuju koneksi https. Ini bagus, mendidik user untuk selalu menggunakan https di situsnya. Namun bila tidak hati-hati justru ini menjadi celah. Kenapa saya sebut ini adalah celah? Karena dengan membuka dua kanal, maka memungkinkan bagi seseorang untuk mengirimkan http request (bukan https). Bila cookie tidak diset https only, maka ada peluang naked cookie terkirim melalui jaringan. Ketika browser membuka http://www.permatanet.com , maka server akan menjawab dengan HTTP 403 (Access Forbidden). Pada tahap ini tidak ada cookie yang diminta server untuk disimpan browser. Selanjutnya browser akan membuka koneksi ke URL: https://www.permatanet.com/login/login.asp . Berikut percakapan yang terjadi: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 https://www.permatanet.com/login/login.asp GET /login/login.asp HTTP/1.1 Host: www.permatanet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: id,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 200 OK Server: Microsoft-IIS/5.0 Date: Sat, 10 Jan 2009 07:54:35 GMT Content-Length: 18481 Content-Type: text/html Expires: Sat, 10 Jan 2009 07:54:36 GMT Set-Cookie: ASPSESSIONIDSSDCARRA=OJBNBHIDDICNKDOODCAKBPKJ; path=/ Cache-Control: private Perhatikan header Set-Cookie pada response yang artinya: “Hey browser! tolong simpan data ini, dan kirimkan kembali ke aku setiap kamu request ke host www.permatanet.com, lewat koneksi http atau https terserah.” Cookie ini adalah cookie yang menyimpan sessionid, jadi kalau ingin membajak session PermataNet, attacker harus mencuri cookie ini. Setelah saya login (saya memang nasabah permata), cookie itu tetap menjadi tempat penyimpanan session id saya. Oke, sekarang saya sudah login, itu artinya session established, dan isi cookie itu adalah kunci untuk membajak account saya. Untuk mencuri cookie tersebut, pertama attacker harus sudah siap men-sniff jaringan saya. Kemudian attacker harus menunggu sampai saya berbuat kesalahan fatal, yaitu mengirim request yang mengandung cookie tersebut tanpa ter-enkripsi. Sebagai contoh mari kita buat jebakan berupa tag image yang URLnya mengarah pada logo permatanet. Logo tersebut aslinya URLnya adalah: https://www.permatanet.com/login/images/logo_permatanet.jpg , namun karena server permatanet membuka juga koneksi ke http, maka URLnya bisa juga menjadi: http://www.permatanet.com/login/images/logo_permatanet.jpg (tanpa http). Setiap request dengan http ke server PermataNet selalu dijawab dengan Forbidden Error (403). Tapi itu tidak penting, yang penting adalah request, bukan response. Bila saya siapkan sebuah halaman html yang mengandung tag berikut: Lalu html ini saya kirim melalui email, atau korban terbujuk untuk membuka halaman itu, maka browser korban akan mengirimkan request ke server permatanet melalui koneksi http. Bila korban saat itu sedang login (session masih valid), maka sessionid korban akan terbang tanpa perlindungan. Kalau kita coba buka url tersebut di browser, kita lihat apa yang dikirimkan browser saya dan diresponse server PermataNet: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 http://www.permatanet.com/login/images/logo_permatanet.jpg GET /login/images/logo_permatanet.jpg HTTP/1.1 Host: www.permatanet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: id,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: ASPSESSIONIDSSDCARRA=OJBNBHIDDICNKDOODCAKBPKJ;HalJini=main HTTP/1.x 403 Access Forbidden Server: Microsoft-IIS/5.0 Date: Fri, 09 Jan 2009 07:10:03 GMT Connection: close Content-Length: 1873 Content-Type: text/html Benar kan, error 403 Forbidden. Itu artinya URL itu dilarang keras diakses. Tapi lihat header Cookie pada request yang dilakukan browser. Ternyata cookie ini tetap dikirimkan ke server melalui koneksi http biasa. Ya iya laah, request ini kan ke URL yang masuk dalam domain+path cookie, dan server PermataNet tidak mensyaratkan harus dengan https. Dengan terjadinya request ini, attacker dengan mudah mengkopi isinya, dan memasukkan ke browsernya sehingga ketika dia membuka halaman PermataNet maka yang terbuka adalah account saya. Sungguh berbahaya! Pencegahan Bagaimana cara mencegah agar cookie kita tidak tercuri? Kita harus mengubah cookie PermataNet di browser kita menjadi “Https Only”. Bagi pengguna Firefox ini mudah, dengan Addon Cookie Editor kita bisa bebas meng-edit cookie. Kesimpulan Anda telah melihat bahwa men-set bit cookie menjadi https only sangat-sangat penting. Hal ini berbeda bila server tidak membuka koneksi di port 80, sehingga walaupun cookie diset any connection, tetap hanya bisa di https karena port 80 closed. Selain PermataNet, situs PayPal.com juga mengalami masalah yang sama, silakan investigasi sendiri sebagai latihan dan tuliskan hasilnya sebagai komentar di sini. No related posts. Tagged with: cookie • csrf • hijacking • internet banking • permata If you enjoyed this article, please consider sharing it”

Post a Comment

Subscribe to: Post Comments (Atom)
 

Indahnya Berbagi Copyright © 2012 Fast Loading -- Powered by Blogger