Lebih Dalam tentang OpenID

Seperti yang saya janjikan sebelumnya, kali ini akan saya jelaskan lebih dalam lagi tentang OpenID. Apa saja yang akan saya bahas? Saya akan mengajak anda untuk melihat lebih dalam lagi komunikasi yang terjadi antara provider,consumer dan user browser. Jika pada artikel sebelumnya saya hanya menceritakan bahwa consumer berkomunikasi secara langsung atau tidak langsung dengan provider, kali ini saya akan tunjukkan data apa saja kah yang dipertukarkan di antara mereka untuk memastikan identitas seseorang?

Setup the Lab

Agar mudah melakukan sniffing, saya harus mensetup lab sederhana yang bisa saya kendalikan sepenuhnya. Dari ke-3 entitas yang terlibat dalam openid, lebih mudah bagi saya untuk membuat consumer website di komputer saya sendiri daripada membuat provider. Sebab sniffing di sisi consumer atau di sisi provider hasilnya akan sama saja, jadi buat apa merepotkan diri dengan membuat provider.

Dalam lab ini consumer adalah wordpress dengan plugin OpenID yang saya install di localhost dengan XAMPP (php+mysql+apache), sedangkan provider saya pakai provider yang sama dengan artikel sebelumnya, yaitu PIP.VerisignLabs.com. Lengkap sudah, consumer dan provider sudah ada, kini saya siap mensniff komunikasi antara consumer dan provider dari sisi consumer.

Untuk melakukan sniffing komunikasi langsung antara consumer dan provider saya menggunakan tools Wireshark. Sedangkan komunikasi yang melalui browser (tidak langsung), saya menggunakan addon Firefox Live HTTP Header sebagai sniffer (walaupun addon ini hanya bisa menampilkan header http). Diagram lab saya bisa dilihat pada gambar berikut ini:

my lab

Skenario Simulasi

Untuk memahami detil komunikasi dalam openid, saya akan mensimulasikan pemakaian openid. Jadi skenarionya sederhana saja, saya akan login ke wordpress yang sudah saya install di komputer sendiri (localhost) menggunakan OpenID identifier: masrizki.ilmuhacking.com. Setelah itu saya akan diredirect ke halaman login PIP Verisignlabs dan juga melakukan otorisasi trust relationship. Kemudian saya akan dikembalikan ke halaman administrasi wordpress sebagai seorang contributor.

Login to WordPress using OpenID

Saya akan mulai simulasinya dengan login ke wordpress pada URL http://localhost/wordpress/wp-login.php. Pada kolom openid saya masukkan masrizki.ilmuhacking.com sedangkan kolom lainnya saya kosongkan. Berikut adalah gambar dari halaman login wordpress yang sudah mendukung openid di localhost.

wordpress login page

Komunikasi http yang berhasil disniff ketika tombol Login diklik adalah (beberapa header yang tidak penting saya hapus):

1 2 3 4 5 6 7 8 9 10 11 12 13

http://localhost/wordpress/wp-login.php   POST /wordpress/wp-login.php HTTP/1.1 Host: localhost Referer: http://localhost/wordpress/wp-login.php Cookie: wordpress_test_cookie=WP+Cookie+check; wp-settings-time-1=1234937131; wp-settings-time-2=1234936984; PHPSESSID=d4d55ee29f62239a347be3a04dc8f8a4 Content-Type: application/x-www-form-urlencoded Content-Length: 143 log=&pwd=&openid_identifier=masrizki.ilmuhacking.com&wp-submit=Log+In&redirect_to=http%3A%2F%2Flocalhost%2Fwordpress%2Fwp-admin%2F&testcookie=1   HTTP/1.x 200 OK Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/wordpress/ Content-Length: 1718

Pada baris ke-9 terlihat parameter POST yang dikirim, diantara yang penting adalah:

• openid_identifier: masrizki.ilmuhacking.com
• redirect_to: http://localhost/wordpress/wp-admin/

openid_identifier menunjukkan identifier (url) openid yang dipakai untuk login, dan redirect_to menunjukkan url ketika semua proses authentication berhasil (bila login berhasil user akan masuk ke url tersebut). Setelah user mengklik submit, consumer akan mendownload file html yang ada di http://masrizki.ilmuhacking.com. Berikut sniffing download file tersebut:

GET / HTTP/1.0
User-Agent: php-openid/2.1.2 (php/5.2.6)
Host: masrizki.ilmuhacking.com
Range: 0-1048576
Port: 80
Accept: application/xrds+xml, text/html; q=0.3, application/xhtml+xml; q=0.5
 
HTTP/1.1 200 OK
Date: Wed, 18 Feb 2009 06:03:43 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Last-Modified: Wed, 11 Feb 2009 08:51:39 GMT
ETag: "3fe00c5-2b2-462a0b6435cc0"
Accept-Ranges: bytes
Content-Length: 690
Connection: close
Content-Type: text/html
 
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
 
<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" />
<link rel="openid2.provider" href="http://pip.verisignlabs.com/server" />
<link rel="openid2.local_id" href="http://masrizki.pip.verisignlabs.com" />
<meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" />
 
    <title>OpenID MasRizki</title>
  </head>
  <body>
    <h1>OpenID MasRizki</h1>
  </body>
</html>

File html yang didapatkan dari masrizki.ilmuhacking.com mengandung informasi server openid provider yang dipakai, yaitu http://pip.verisignlabs.com/server. Selain itu juga didapatkan lokasi file XRDS, di http://pip.verisignlabs.com/user/masrizki/yadisxrds, berikutnya consumer akan mendownload file XRDS dari url tersebut. Berikut sniffing komunikasi yang terjadi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

GET /user/masrizki/yadisxrds HTTP/1.0 User-Agent: php-openid/2.1.2 (php/5.2.6) Host: pip.verisignlabs.com Range: 0-1048576 Port: 80   HTTP/1.1 200 OK Date: Wed, 18 Feb 2009 06:04:01 GMT X-XRDS-Location: http://pip.verisignlabs.com/user/masrizki/yadisxrds Content-Type: application/xrds+xml;charset=ISO-8859-1 Content-Length: 1118 Connection: close   <?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</Type> <URI>http://pip.verisignlabs.com/server</URI> <LocalID>http://masrizki.pip.verisignlabs.com/</LocalID> </Service> <Service priority="1"> <Type>http://openid.net/signon/1.1</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <URI>http://pip.verisignlabs.com/server</URI> <openid:Delegate>http://masrizki.pip.verisignlabs.com/</openid:Delegate> </Service> </XRD> </xrds:XRDS>

Setelah mendownload file html dari XRDS, berikutnya consumer akan meminta provider untuk melakukan authentication terhadap user tersebut. Untuk melakukannya consumer akan meminta browser untuk membuat request ke openid server provider di url: http://pip.verisignlabs.com/server. Ada dua cara untuk melakukan itu, yaitu dengan memberi response 302 Redirect atau memberi response 200 OK namun diberi html form auto-submit. Openid pada wordpress memilih memakai form auto-submit, dengan cara mengirimkan file html berikut sebagai response dari klik tombol Login di halaman login wordpress :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" lang="en-US"><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>OpenID Authentication Redirect</title> <link rel="stylesheet" href="http://localhost/wordpress/wp-admin/css/install.css?ver=20081210" type="text/css" media="all"> </head><body id="openid-page">   <noscript><p>Since your browser does not support JavaScript, you must press the Continue button once to proceed.</p></noscript> <form action="http://pip.verisignlabs.com/server" method="post"> <input name="openid.ns" value="http://specs.openid.net/auth/2.0" type="hidden">   <input name="openid.realm" value="http://localhost/wordpress/" type="hidden"> <input name="openid.mode" value="checkid_setup" type="hidden"> <input name="openid.return_to" value="http://localhost/wordpress/?openid=consumer&amp;janrain_nonce=2009-02-18T06%3A38%3A05ZrtUK3x" type="hidden"> <input name="openid.identity" value="http://masrizki.pip.verisignlabs.com/" type="hidden"> <input name="openid.claimed_id" value="http://masrizki.ilmuhacking.com/" type="hidden"> <input name="openid.assoc_handle" value="dec470c0-fd80-11dd-8f5a-d5350139866a" type="hidden"> <noscript><div><input value="Continue" type="submit"></div></noscript> </form>   <script type="text/javascript"> document.write("<h2>Please Wait...</h2>"); document.forms[0].submit() </script></body></html>

Pada file html tersebut terdapat tag FORM dengan method POST ke action url: http://pip.verisignlabs.com/server. Tadi saya menyebut auto-submit karena pada baris di paling bawah terdapat javascript yang melakukan submit, jadi tanpa perlu user klik tombol submit, form tersebut sudah automatically submit. Namun bila di browser user tidak mendukung javascript, maka user harus mengklik tombol “Continue” secara manual. Ketika HTTP POST ini disubmit, berikut sniffing komunikasi yang terjadi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

http://pip.verisignlabs.com/server   POST /server HTTP/1.1 Host: pip.verisignlabs.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 ImageShackToolbar/5.0.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost/wordpress/wp-login.php Cookie: __utma=182045240.1255127474965694500.1234512662.1234523895.1234936800.3; __utmz=182045240.1234512662.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=182045240.9.10.1234936800; __utmc=182045240; JSESSIONID=4F3B5E2D447C07B6D616CCFFF1DF3663.pip1 Content-Type: application/x-www-form-urlencoded Content-Length: 549 openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.sreg.optional=nickname%2Cemail%2Cfullname&openid.realm=http%3A%2F%2Flocalhost%2Fwordpress%2F&openid.mode=checkid_setup&openid.return_to=http%3A%2F%2Flocalhost%2Fwordpress%2F%3Fopenid%3Dconsumer%26janrain_nonce%3D2009-02-18T06%253A07%253A10Z4ZW4Xj&openid.identity=http%3A%2F%2Fmasrizki.pip.verisignlabs.com%2F&openid.claimed_id=http%3A%2F%2Fmasrizki.ilmuhacking.com%2F&openid.assoc_handle=dec470c0-fd80-11dd-8f5a-d5350139866a   HTTP/1.x 302 Moved Temporarily Date: Wed, 18 Feb 2009 06:04:07 GMT Location: http://pip.verisignlabs.com/login.do Content-Length: 0 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html

Ternyata submit post ke URL http://pip.verisignlabs.com/server, dibalas dengan 302 Redirect ke URL: http://pip.verisignlabs.com/login.do, yang tidak lain adalah halaman login. Hal ini terjadi karena user tersebut belum login di PIP sehingga diarahkan ke halaman login, bila user sudah login maka tidak diarahkan ke halaman login, tapi langsung ke halaman authorize trust relationship.

Login to OpenID Provider

PIP login page

Perhatikan pada gambar tersebut halaman login menggunakan https. Ternyata pada saat browser request ke http://pip.verisignlabs.com/login.do lagi-lagi diresponse dengan 302 Redirect ke url https://pip.verisignlabs.com/login.do. PIP meredirect request ke halaman login selalu ke halaman yang menggunakan https demi menghindarkan user dari serangan sniffing dan mitm attack. Setelah user memasukkan username dan password dan mengklik tombol “sign in”, berikut adalah sniffing komunikasi yang terjadi:

https://pip.verisignlabs.com/login_user.do
 
POST /login_user.do HTTP/1.1
Host: pip.verisignlabs.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 ImageShackToolbar/5.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://pip.verisignlabs.com/login.do
Cookie: __utma=182045240.1255127474965694500.1234512662.1234523895.1234936800.3; __utmz=182045240.1234512662.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); JSESSIONID=4F3B5E2D447C07B6D616CCFFF1DF3663.pip1; __utmb=182045240.10.10.1234936800; __utmc=182045240; JSESSIONID=4F3B5E2D447C07B6D616CCFFF1DF3663.pip1
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
username=ilmuhacking&password=<sensor>
 
HTTP/1.x 302 Moved Temporarily
Date: Wed, 18 Feb 2009 06:05:47 GMT
X-XRDS-Location: http://pip.verisignlabs.com/user/DIRECTED_IDENTITY_USER/yadisxrds
Pragma: No-cache
Cache-Control: no-cache,no-store,max-age=0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: _session-id_v01_ilmuhacking=6cf8bd30ec8b2fef728d7f3f2b676878; Domain=pip.verisignlabs.com; Path=/; HttpOnly
Location: https://pip.verisignlabs.com/dataExchange?target=render&identityName=masrizki
Content-Type: text/html
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Terlihat username dan password disubmit ke URL: https://pip.verisignlabs.com/login_user.do dan submit POST tersebut diresponse dengan 302 Redirect ke URL: https://pip.verisignlabs.com/dataExchange?target=render&identityName=masrizki . URL tersebut adalah url yang berisi halaman otorisasi dan verifikasi trust relationship dengan wordpress yang menjadi consumer.

trust relationship verification

Setelah user menentukan trust relationship dan mengisi beberapa data, berikut adalah sniff komunikasi POST yang terjadi ketika user mensubmit datanya.

https://pip.verisignlabs.com/authExchAction.do
 
POST /authExchAction.do HTTP/1.1
Host: pip.verisignlabs.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 ImageShackToolbar/5.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://pip.verisignlabs.com/dataExchange?target=render&identityName=masrizki
Cookie: __utma=182045240.1255127474965694500.1234512662.1234523895.1234936800.3; __utmz=182045240.1234512662.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); JSESSIONID=4F3B5E2D447C07B6D616CCFFF1DF3663.pip1; __utmb=182045240.11.10.1234936800; __utmc=182045240; JSESSIONID=4F3B5E2D447C07B6D616CCFFF1DF3663.pip1; _session-id_v01_ilmuhacking=6cf8bd30ec8b2fef728d7f3f2b676878
Content-Type: application/x-www-form-urlencoded
Content-Length: 271
session_id_validation=3adb2f83&target=submit&identity=masrizki&fullname=Mas+Rizki&nickname=Rizki&email=rizki%40ilmuhacking.com&dobmonth=10&dobday=09&dobyear=1981&gender=M&postcode=12345&country=ID&language=ind&timezone=Asia%2FJakarta&month=02&day=17&year=2009&timing=once
 
HTTP/1.x 302 Moved Temporarily
Date: Wed, 18 Feb 2009 06:06:44 GMT
X-XRDS-Location: http://pip.verisignlabs.com/user/DIRECTED_IDENTITY_USER/yadisxrds
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: http://localhost/wordpress/?openid=consumer&janrain_nonce=2009-02-18T06%3A07%3A10Z4ZW4Xj&openid.sreg.fullname=Mas+Rizki&openid.assoc_handle=5193a7f0-fd82-11dd-a512-79ad78e29b8b&openid.response_nonce=2009-02-18T06%3A06%3A44ZqYxKBQ%3D%3D&openid.sreg.email=rizki%40ilmuhacking.com&openid.sreg.nickname=Rizki&openid.pape.nist_auth_level=0&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=http%3A%2F%2Fpip.verisignlabs.com%2Fserver&openid.pape.auth_policies=none&openid.claimed_id=http%3A%2F%2Fmasrizki.ilmuhacking.com%2F&openid.sig=2CdUovMZVV2DbHQzLt2W3SjR5mE%3D&openid.identity=http%3A%2F%2Fmasrizki.pip.verisignlabs.com%2F&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_time=2009-02-18T06%3A05%3A47Z&openid.signed=assoc_handle%2Cidentity%2Cresponse_nonce%2Creturn_to%2Cclaimed_id%2Cop_endpoint%2Csreg.nickname%2Csreg.email%2Csreg.fullname%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Cpape.nist_auth_level&openid.invalidate_handle=dec470c0-fd80-11dd-8f5a-d5350139866a&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.return_to=http%3A%2F%2Flocalhost%2Fwordpress%2F%3Fopenid%3Dconsumer%26janrain_nonce%3D2009-02-18T06%253A07%253A10Z4ZW4Xj
Content-Type: text/html
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Terlihat setelah user mensubmit datanya dan trust relationshipnya, PIP akan me-redirect user ke wordpress seperti semula. Perhatikan juga bahwa URL yang akan dituju oleh Redirect mengandung beberapa parameter yang gunanya untuk menyampaikan status proses authentication. HTTP Redirect ini merupakan jawaban (response) dari request yang diajukan consumer ketika user pertama login di halaman wordpress.

Direct vs Indirect Communication

Komunikasi ini adalah komunikasi tidak langsung, berawal dari consumer melakukan request ke provider (melalui perantaraan user), kemudian setelah user berhasil terotentikasi di provider, provider memberikan response balik ke consumer (melalui perantaraan user). Mengirimkan request/response melalui perantaraan user bisa dilakukan dengan mengirimkan status 302 Redirect atau memberikan html berisi auto-submit form. Untuk lebih jelasnya perhatikan gambar di samping.

Cross Check Authentication to Provider

Kini tiba langkah terakhir yang akan dilakukan consumer, yaitu melakukan cross-check/verifikasi, apakah benar user ini telah terotentikasi dengan sukses di provider. Consumer melakukan komunikasi langsung dengan provider tanpa perantaraan user dengan mengirimkan request POST berikut ini:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

POST /server HTTP/1.0 Host: pip.verisignlabs.com Content-type: application/x-www-form-urlencoded Content-length: 1231 janrain_nonce=2009-02-18T06%3A07%3A10Z4ZW4Xj&openid=consumer&openid.assoc_handle=5193a7f0-fd82-11dd-a512-79ad78e29b8b&openid.claimed_id=http%3A%2F%2Fmasrizki.ilmuhacking.com%2F&openid.identity=http%3A%2F%2Fmasrizki.pip.verisignlabs.com%2F&openid.invalidate_handle=dec470c0-fd80-11dd-8f5a-d5350139866a&openid.mode=check_authentication&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.op_endpoint=http%3A%2F%2Fpip.verisignlabs.com%2Fserver&openid.pape.auth_policies=none&openid.pape.auth_time=2009-02-18T06%3A05%3A47Z&openid.pape.nist_auth_level=0&openid.response_nonce=2009-02-18T06%3A06%3A44ZqYxKBQ%3D%3D&openid.return_to=http%3A%2F%2Flocalhost%2Fwordpress%2F%3Fopenid%3Dconsumer%26janrain_nonce%3D2009-02-18T06%253A07%253A10Z4ZW4Xj&openid.sig=2CdUovMZVV2DbHQzLt2W3SjR5mE%3D&openid.signed=assoc_handle%2Cidentity%2Cresponse_nonce%2Creturn_to%2Cclaimed_id%2Cop_endpoint%2Csreg.nickname%2Csreg.email%2Csreg.fullname%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Cpape.nist_auth_level&openid.sreg.email=rizki%40ilmuhacking.com&openid.sreg.fullname=Mas+Rizki&openid.sreg.nickname=Rizki   HTTP/1.1 200 OK Date: Wed, 18 Feb 2009 06:06:46 GMT Content-Length: 50 Connection: close Content-Type: text/html   is_valid:true ns:http://specs.openid.net/auth/2.0

Terlihat pada request tersebut consumer membawa serta semua parameter yang didapatkannya dari provider (melalui browser redirect pada paragraf sebelumnya). Parameter tersebut akan dicocokkan dengan data yang dimiliki provider, bila memang benar terotentikasi maka responsenya adalah seperti pada baris ke-13 pada sniffing di atas, yaitu: is_valid:true. Setelah mengetahui bahwa user telah terotentikasi dengan sukses, maka selanjutnya user diijinkan masuk ke wordpress dan selesailah proses authentication dengan openid ini. Setelah selesai proses authentication, tidak ada lagi hubungan dan keterkaitan antara consumer dan provider, masing-masing memiliki session yang terpisah.

sumber: ilmuhacking.com

Read more »

Posted in: Basic Concept

Mengenal OpenID

Setiap anda akan mengakses bank account, social network, email dan layanan lain, anda memerlukan identitas digital. Dalam artikel ini saya membahas tentang OpenID sebagai bentuk baru identitas digital anda  yang akan memudahkan mengelola identitas anda.

Security pada OpenID akan saya bahas pada artikel saya berikutnya, dalam artikel ini sifatnya hanya konsep dasar dan perkenalan.

Digital Identity

Identitas adalah atribut yang membuat berbeda dengan yang lain.

Identitas adalah kumpulan atribut yang membedakan sesuatu dengan yang lainnya. Nama saja tidak bisa dijadikan identitas seseorang karena kemungkinan banyak orang yang bernama sama. Biasanya identitas seseorang ditunjukkan dengan ID Card yang berisi kumpulan atribut, antara lain: nama, alamat, tanggal lahir. Bila nama saja tidak cukup membedakan seseorang dengan yang lain, maka kumpulan dari nama, alamat, tanggal lahir akan membuatnya unik (berbeda dengan yang lain).

Berbeda dengan di dunia nyata, di internet biasanya nama (username) atau alamat email memang harus unik dari awalnya. Tidak mungkin ada alamat email yang sama untuk dua orang yang berbeda, sehingga umumnya username atau email bisa dijadikan identitas. Khusus untuk username, biasanya keunikannya hanya relatif terhadap satu website/domain saja. Misal, bila kita punya username rizki di detik.com, kita boleh juga membuat username yang sama di facebook.com.

On the Internet, Nobody Knows You‘re a Dog

Di internet, anda bisa menjadi siapa saja yang anda mau. Mau jadi diri sendiri, silakan. Mau menyamar jadi orang lain juga boleh. Sangat sulit bagi orang lain untuk bisa mengetahui siapa anda sebenarnya. Hal ini karena identitas anda di internet diwakilkan dalam bentuk username dan password. Siapapun yang mengetahui username dan password anda, akan bisa memakai identitas anda dan semua orang akan menganggap dia adalah anda.

Identitas digital sangat mudah dibuat, cukup dengan memasukkan beberapa data pada saat signup/register di suatu web, maka anda telah membuat identitas baru untuk anda. Karena mudah dibuat, maka identitas digital kurang bisa dipercaya. Agar identitas digital memiliki kredibilitas yang kuat, maka perlu didukung dengan proses verifikasi manual.

Salah satu contoh digital identitas yang kredibilitasnya kuat adalah SSL certificate. SSL certificate adalah bentuk bukti identitas suatu server. Dalam sertifikat tersebut tertera nama domain, nama perusahaan dan deskripsi lainnya. Data-data tersebut telah melalui proses verifikasi yang ketat oleh Certificate Authority (CA) sehingga dijamin datanya benar, bukan fiktif.

Contoh lain adalah Paypal. Pengguna Paypal harus memasukkan nomor kartu kredit yang akan dipakai untuk bertransaksi. Dalam Paypal account terbagi dalam dua macam, Verified dan non-Verified. Apa bedanya? Bedanya adalah verified account telah melalui verifikasi manual untuk memastikan bahwa anda adalah pemilik kartu kredit yang anda daftarkan tersebut. Caranya adalah dengan memasukkan sebuah kode dalam tagihan kartu kredit anda. Anda harus menunggu sampai tagihan kartu kredit anda bulan berikutnya tiba, kemudian memasukkan kode yang tertera di dalamnya. Bila kode yang anda masukkan benar, berarti anda telah membuktikan bahwa anda memang benar pemilik kartu kredit yang anda daftarkan dalam Paypal. Hal ini karena hanya pemilik kartu kredit yang sah yang bisa membaca lembar tagihan, kecuali bila anda mencuri surat tagihan kartu kredit milik orang lain.

Hal ini berbeda dengan identitas anda di jaringan social seperti Facebook. Dalam facebook anda bisa menjadi siapa saja karena tidak ada verifikasi manual di Facebook. Untuk menjadi seorang selebritas, anda cukup mendaftar dengan nama dan data umum selebritas tersebut, kemudian upload foto-fotonya. Dengan begini, kini anda telah menjadi seorang selebritas di Internet. Tidak akan ada yang bisa membedakan, apakah anda memang benar-benar selebritas, atau orang biasa yang menyamar.

Too Many Identity Problem

how to effectively manage multiple identities at many web sites that a user has to interact with

Kemudahan membuat identitas digital membuat satu orang bisa memiliki banyak identitas. Hal ini menjadi masalah, karena seseorang harus mengelola banyak identitias untuk web yang berbeda-beda. Bila identitas sudah terlalu banyak, orang cenderung untuk melakukan hal yang terlarang, antara lain membuat password yang terlalu lemah, mencatat password di kertas dan membuat password yang sama untuk semua web.

Bila seseorang menggunakan password yang sama untuk semua web, maka bila ada satu saja web yang diikuti korban berhasil ditembus dengan sql injection atau bug lainnya, maka attacker itu bisa mengakses semua account milik korban dengan mudah. Ini sangat berbahaya.

Dari sisi server kita tahu bahwa tidaklah mudah membuat authentication yang tingkat keamanannya tinggi. Banyak kasus hacking yang disebabkan karena authentication yang tidak aman. Salah satu yang cukup sering terjadi adalah sql injection di halaman login. Selain itu halaman authentication yang aman seharusnya menggunakan SSL (https), bukan http biasa karena http tidak mengenkrip paket datanya.

Namun tidak mudah dan murah biayanya untuk membuat halaman authentication yang aman. Sehingga tidak heran bila sebagian besar halaman authentication di web tidak menggunakan https. Bila ada seseorang yang memiliki banyak account dengan password yang sama. Bila ada salah satu web saja yang tidak secure dan membuat passwordnya berhasil di sniff, maka semua account lainnya akan terancam juga.

Jadi baik dari sisi klien maupun dari sisi server, terlalu banyak identitas menimbulkan masalah. Oleh karena itu dibutuhkan identitas digital tunggal yang diterima di banyak tempat.

URL as Single Universal Identity

Kita telah melihat bahwa terlalu banyak identitas membuat masalah yang berbahaya, mempunyai banyak identitas terkadang diperlukan untuk beragam kondisi. Namun memiliki terlalu banyak identitas bisa melukai pemiliknya karena username, password dan data lain milik user bertebaran di banyak tempat menunggu untuk dicuri cracker.

OpenID adalah protokol terbuka yang memungkinkan seseorang menggunakan URL sebagai identitas tunggal yang diterima di banyak tempat. Apa maksudnya, URL kok dijadikan identitas?

URL  bisa dibayangkan sebagai petunjuk untuk mencapai lokasi yang mengandung sesuatu yang berharga

Kembali ke URL sebagai identitas. Bagaimana logikanya? Identitas menunjukkan siapa anda, yang biasanya diwakilkan dengan identifier/nama. Jadi sebenarnya sederhana saja, URL bisa dianggap sebagai identifier/nama, jadi bisa juga dipakai sebagai identitas. Misalkan kalau ada yang bertanya, siapa anda? Saya bisa menjawab dengan “Saya Rizki”, atau bisa juga menjawab dengan “Saya rizkiwicaksono.pip.verisignlabs.com”.

URL sebagai identifier sebenarnya lebih baik dibanding nama orang, karena URL adalah unik, kalau saya sebutkan saya adalah rizki, tentu banyak orang lain yang punya nama yang sama. Tapi kalau saya bilang, “saya rizkiwicaksono.pip.verisignlabs.com” tidak akan ada kembarannya, karena URL menunjukkan satu lokasi yang unik.

Example of URL Authentication

Identitas tentu sangat erat kaitannya dengan authentication yang fungsinya untuk memastikan siapakah anda. Bagaimanakah authentication dari identitas yang berupa URL? Anda tentu ingat bahwa URL adalah petunjuk lokasi.

Bayangkan bila anda menyebutkan identitas anda bahwa “Saya adalah Jl. Sudirman no. 17″, itu adalah klaim identitas anda yang harus dibuktikan dengan authentication. Orang lain akan percaya bahwa anda adalah “Jl Sudirman no. 17″, bila anda bisa membuktikan bahwa anda adalah pemilik properti di lokasi itu. Salah satu cara membuktikannya adalah dengan menunjukkan surat/akta kepemilikan.

Mirip dengan contoh itu, dalam URL. Salah satu bentuk authentication adalah anda harus bisa membuktikan bahwa anda benar pemilik lokasi yang ditunjukkan oleh URL itu. Bila URL itu menunjukkan alamat web, maka anda harus bisa memasukkan sebuah file, atau mengubah teksnya menjadi sesuatu yang lain. Bila anda bisa, maka orang akan yakin anda benar pemilik URL itu.

Bagi yang pernah memakai Google Analytics tentu tahu, cara untuk membuktikan bahwa anda adalah pemilik web, adalah dengan membuat sebuah file kosong yang namanya telah ditentukan google. Kemudian google akan mengakses file tersebut, bila hasilnya 200 OK, maka anda telah lolos verifikasi google analytics. Berarti klaim anda benar, bahwa web itu memang benar milik anda.

Oke, yang saya sebutkan di atas hanyalah contoh sederhana authentication sebuah URL untuk menunjukkan bahwa URL bisa dipakai sebagai identitas yang sah karena bisa diotentikasi. Faktanya OpenID jauh lebih kompleks dari sekedar memasukkan sebuah file seperti verifikasi yang dilakukan oleh google analytics.

Terminologi

Beberapa istilah yang perlu saya jelaskan sebelum saya masuk pembahasan teknis openid adalah:

• End user: pengguna.
• Consumer/Relying Party: website yang mendukung openid, anda bisa login dengan openid di situs ini.
• Identifier: URL openid.
• Identity provider: server yang mengelola account openid pengguna. Server inilah yang menangani authentication openid account anda. Jadi sebelum bisa mengakses consumer website anda harus login dulu di server identity provider.
• User agent: web browser pengguna.

Creating OpenID

Agar lebih memahami openID, saya akan menunjukkan pembuatan dan pemakaian OpenID. Dalam contoh ini saya menggunakan OpenID provider milik Verisign yaitu Personal Identity Portal. Untuk mendaftar klik ke PIP Portal Verisign, di https://pip.verisignlabs.com. Kemudian klik tombol Get Started Now.

sign up button

Setelah itu masukkan username, password dan email anda.Dalam contoh ini saya menggunakan username ilmuhacking.

sign up form

Setelah selesai, anda akan menerima email konfirmasi dan account PIP anda sudah siap digunakan.

openid created

Sangat mudah bukan membuat openID, hanya perlu 3 langkah saja. OpenID yang baru saya buat adalah “ilmuhacking.pip.verisignlabs.com”. URL tersebut adalah identifier identitas saya yang bisa saya pakai untuk login ke web yang mendukung OpenID. Dalam satu account PIP tersebut saya bisa membuat banyak identitas OpenID, jadi sesuai dengan namanya Personal Identity Portal, jadi PIP itu semacam portal/gerbang untuk identitas pribadi saya. Cukup dengan satu account (username+password) PIP, saya bisa membuat dan memakai banyak identitas OpenID.

multiple openID

Dengan punya banyak identitas dalam satu account, saya bisa menggunakannya untuk kondisi yang berbeda. Misalkan di situs yang terkait dengan hacking, saya pakai “ilmuhacking.pip.verisignlabs.com”, namun bila di situs yang sifatnya umum, saya pakai “masrizki.pip.verisignlabs.com”.

Using OpenID in LiveJournal

livejournal openID

Sebagai contoh pemakaian OpenID, saya menggunakan contoh LiveJournal, yang dalam hal ini bertindak sebagai consumer website. Sebelumnya saya akan logout dulu dari PIP. Untuk Login di Livejournal dengan OpenID, klik link “Login w/ OpenID“. Dalam contoh ini saya menggunakan “ilmuhacking.pip.verisignlabs.com” sebagai identitas saya. Setelah saya klik tombol Login, maka LiveJournal akan redirect ke PIP Verisignlabs.

Berhubung saya sudah mengaktifkan setting “Sign in Security”, maka yang muncul bukan halaman login PIP, tapi peringatan bahwa saya harus login dulu ke PIP dengan cara mengetikkan URL: http://pip.verisignlabs.com/login.do.  Bila settings “Sign in Security” tidak diaktifkan, maka saya akan langsung diarahkan ke halaman login PIP.

Setelah saya login ke PIP, kemudian saya harus mengulang lagi memasukkan OpenID URL saya di LiveJournal. Kali ini karena saya sudah login (session PIP masih hidup di browser saya), saya tidak perlu login ke PIP dulu dan saya langsung masuk ke halaman verifikasi berikut:

verifikasi

Di situ saya diminta untuk memverifikasi, apakah benar ilmuhacking adalah OpenID saya. Saya juga diminta menentukan hubungan trust dengan situs LiveJournal, bila saya tetapkan Never Expire maka berikutnya saya  tidak diminta verifikasi situs LiveJournal.com seperti ini. Namun bila saya setting Expire After Sign In, maka saya hanya mengijinkan untuk login kali ini saja, login berikutnya saya akan ditanyakan verifikasi lagi.

welcome back to livejournal

Setelah verifikasi, saya masuk ke halaman pribadi LiveJournal.com karena saya sudah berhasil login dengan OpenID. Saya tidak pernah mendaftar di situs ini, tapi saya mendaftar di PIP sekali saja, dan saya bisa langsung memakai LiveJournal dan banyak situs lainnya, menyenangkan bukan?

Using OpenID in CommonGate

commongate openid login

Pada contoh sebelumnya saya sudah menunjukkan pemakaian OpenID di situs LiveJournal. Biar lebih mantap, saya akan coba lagi untuk consumer website yang lain, yaitu CommonGate.com. Kali ini saya menggunakan identitas “masrizki.pip.verisignlabs.com”, ingat di awal saya sudah ceritakan bahwa identitas masrizki.pip.verisignlabs.com dan ilmuhacking.pip.verisignlabs.com adalah dua OpenID dalam satu account PIP yang sama, yaitu username ilmuhacking.

Dalam keadaan session PIP saya masih hidup (belum logout) dengan account ilmuhacking, saya masukkan URL OpenID saya di commongate.com seperti pada gambar di atas. Sekali lagi, karena session PIP saya masih hidup, maka saya langsung diarahkan pada halaman verifikasi, karena ini adalah situs baru yang belum pernah saya percayai.

confirmation commongate

Berbeda dengan LiveJournal yang hanya meminta expiration date saja, kali ini commongate meminta beberapa data seperti tanggal lahir, negara, bahasa. Data tersebut adalah data yang sudah saya masukkan sebelumnya ketika saya membuat OpenID di PIP. Jadi sekarang saya tidak perlu repot-repot mengisinya lagi, saya tinggal tentukan tanggal expired hubungan trus commongate.com dengan PIP saya. Untuk mudahnya saya pilih Never Expire.

commongate profile page

Setelah melalui verifikasi, saya langsung diarahkan ke halaman home saya di commongate seperti pada gambar di atas. Karena saya memilih Never Expire, jadi berikutnya dengan session PIP yang masih aktif, ketika saya login di commongate dengan OpenID, saya akan langsung masuk ke halaman profile saya di commongate. Perhatikan pada gambar tersebut, username, country dan gender sudah terisi dengan benar karen field tersebut diambil dari data saya di PIP tanpa perlu saya memasukkan secara manual. Field location masih salah karena memang tidak ada field location di PIP.

Using Different URL

Sebelumnya saya selalu menggunakan “masrizki.pip.verisignlabs.com” dan “ilmuhacking.pip.verisignlabs.com” sebagai identifier OpenID saya. Karena saya membuat OpenID di PIP Verisignlabs (Verisignlabs adalah Identity Provider), maka URL saya defaultnya adalah menggunakan URL yang diberikan oleh PIP.

Sebenarnya URL openID tidak harus sama dengan URL identity provider. Fungsi dari URL OpenID adalah sebagai tempat untuk meng-host html dokumen yang mengandung petunjuk di mana alamat Identity Provider yang dipakai. Mari kita lihat source html dari URL http://masrizki.pip.verisignlabs.com/ :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <link rel="openid.server" href="http://pip.verisignlabs.com/server" /> <link rel="openid2.provider" href="http://pip.verisignlabs.com/server" /> <meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" /> <title>Identity Endpoint For masrizki</title> </head> <body>   <p>This is an identity endpoint for&nbsp;masrizki</p> <p>For more information, please visit <a href="http://pip.verisignlabs.com">http://pip.verisignlabs.com</a></p> </body> </html>

Informasi yang penting hanyalah pada baris ke-5,6 dan 7. Pada baris ke-5 dan 6 terlihat bahwa openid server yang dipakai adalah http://pip.verisignlabs.com/server. Sedangkan pada baris-7 menunjukkan lokasi file XRDS (eXtensible Resource Descriptor Sequence) yang merupakan file XML yang mendeskripsikan openID saya.

Isi dari file XRDS tersebut adalah berikut ini:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

<?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD>   <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</Type> <URI>http://pip.verisignlabs.com/server</URI> <LocalID>http://masrizki.pip.verisignlabs.com/</LocalID> </Service>   <Service priority="1"> <Type>http://openid.net/signon/1.1</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <URI>http://pip.verisignlabs.com/server</URI> <openid:Delegate>http://masrizki.pip.verisignlabs.com/</openid:Delegate> </Service>   </XRD> </xrds:XRDS>

Sebagai contoh saya akan membuat URL : masrizki.ilmuhacking.com sebagai identifier OpenID saya. Saya harus membuat index.html di url itu berisi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head>   <link rel="openid.server" href="http://pip.verisignlabs.com/server" /> <link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" /> <link rel="openid2.provider" href="http://pip.verisignlabs.com/server" /> <link rel="openid2.local_id" href="http://masrizki.pip.verisignlabs.com" /> <meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" />   <title>OpenID MasRizki</title> </head> <body> <h1>OpenID MasRizki</h1> </body> </html>

masrizki.ilmuhacking.com

Kalau dibuka di browser URL tersebut akan tampak seperti gambar disamping. Setelah file htmlnya dibuat, kini saya siap menggunakan masrizki.ilmuhacking.com sebagai identifier saya, bukan lagi memakai masrizki.pip.verisignlabs.com yang menurut saya terlalu panjang. Mari kita coba identifier baru tersebut dalam sniffo.org.

Setelah saya membuka halaman depan sniffo.org dan login, prosesnya terlihat pada gambar di bawah ini.

sniffo.org login using openid

Terlihat pada gambar di atas saya login di sniffo.org menggunakan OpenID identifier: masrizki.ilmuhacking.com. Karena situs itu masih baru, belum ada trust, maka PIP meminta saya untuk menentukan waktu expired trust. Walaupun identifiernya terletak pada host masrizki.ilmuhacking.com, namun authentication tetap dihandle oleh VerisignLabs sebagai OpenID Provider. Jadi masrizki.ilmuhacking.com hanya sebagai nama (identifier) saja, semua proses authentication selanjutnya dihandle oleh PIP Verisignlabs. Proses ini disebut dengan authentication delegation karena host ilmuhacking.com mendelegasikan otentikasi ke PIP Verisignlabs. Instruksi delegate ini bisa diketahui dari dokumen html yang diambil dari url masrizki.ilmuhacking.com pada baris ke-7 yaitu:

<link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" />

Baris di atas menunjukkan bahwa masrizki.ilmuhacking.com mendelegasikan otentikasi kepada masrizki.pip.verisignlabs.com. Sehingga selanjutnya proses otentikasi diarahkan ke Verisignlabs. Dengan begini saya bisa membuat identifier apapun yang saya mau, tanpa perlu repot menjadi OpenID Provider. URL untuk identifier OpenID benar-benar bebas, anda bisa membuat identifier misalkan: www.foobar.or.id/namaku/, yang terpenting pada URL tersebut terdapat file html yang menunjukkan delegasi OpenID provider yang dipakai.

Centralized vs Distributed Session Management

SSO (single sign on) adalah teknologi yang memungkinkan pengguna hanya perlu login sekali saja untuk bisa menikmati banyak layanan. Cara pengelolaan session dalam SSO ada dua macam:

• Centralized: hanya ada satu session saja untuk mengakses semua layanan. Contohnya adalah layanan google dan yahoo.
• Distributed: setiap website memiliki session masing-masing yang saling independent. Openid adalah salah satu contoh SSO yang memakai distributed session.

4 independent session: distributed session

OpenID provider (dalam artikel ini PIP Verisignlabs), hanya mengurus soal authentication, dan tidak bertanggung jawab untuk mengurus session consumer web (livejournal,commongate,sniffo).

Pada gambar di samping terlihat ada 4 session yang terpisah dan satu sama lain saling independent. Bila anda sudah login ke PIP, pada browser anda nanti akan ada session cookie khusus untuk OpenID Provider. Selama session ini masih hidup anda tidak perlu lagi memasukkan password setiap kali memakai openid.

Session untuk masing-masing consumer website dikelola secara mandiri dan tidak ada hubungannya dengan session OpenID provider. Jadi bila anda sudah login ke PIP, kemudian dengan OpenID login ke LiveJournal, CommonGate dan Sniffo, berarti pada browser anda akan ada 4 session cookie yang berbeda, satu untuk openid provider, dan 3 untuk consumer website (livejournal,commongate,sniffo).

Logout dari openid provider, tidak akan membuat anda logout dari consumer website

Bila anda logout dari salah satu consumer website, maka anda tetap bisa memakai layanan di consumer website yang lain. Logout dari satu consumer website hanya mematikan session consumer web itu saja, tidak berpengaruh sama sekali pada session di web lainnya.

single session google network: centralized session

Salah satu contoh implementasi SSO yang terpusat adalah layanan dari yahoo dan google seperti terlihat pada gambar di samping. Pada yahoo/google user cukup sign-on sekali saja, kemudian dia bisa membaca email, chatting dan menggunakan layanan lain tanpa perlu ditanyakan password lagi. Begitu pula sebaliknya, bila user logout dari salah satu layanan, maka user tersebut akan logout dari seluruh network, sehingga tidak bisa mengakses layanan yang lain.

Di Balik Layar

Setelah mencoba berbagai situs yang mendukung OpenID dengan identifier yang dari PIP dan identifier yang dibuat sendiri. Kini tiba saatnya saya untuk menjelaskan apa yang sebenarnya terjadi di balik layar.

Indirect vs Direct Communication between Consumer and Provider

Dalam openid ada 3 entitas yang terlibat, yaitu User Agent (browser yang dipakai user), consumer website (relying party), dan openid provider. Komunikasi yang terjadi di antara ketiganya bisa dilakukan secara langsung atau tidak langsung, semuanya menggunakan protokol HTTP. Pada gambar di samping terlihat gambaran komunikasi secara langsung dan tidak langsung. Komunikasi secara langsung menggunakan HTTP POST, sedangkan komunikasi tidak langsung menggunakan HTTP GET melalui browser Redirect. Pada komunikasi tida langsung, request dikirimkan dalam bentuk http response 302 (redirect), kemudian browser user akan melakukan GET request pada url yang tertera pada header Location. Begitu pula sebaliknya, response juga akan dikirimkan melalui user dengan mengirimkan 302 redirect terlebih dahulu.

Komunikasi yang terjadi di openid ada dua mode:

• Dumb Mode
Pada mode “bodoh” ini, consumer tidak memiliki ingatan, sehingga tidak menyimpan state koneksi antara consumer dan provider. Dalam mode ini percakapan berlangsung lebih banyak karena banyak percakapan yang harus diulang lagi karena “lupa terus”.
• Smart Mode
Pada mode smart, consumer mengingat state koneksi antara consumer dan provider. Hal yang diingat terutama adalah shared secret key, yang dipakai untuk menjaga integritas pesan dengan fungsi HMAC. Dengan mengingat shared key ini, consumer tidak perlu lagi melakukan verifikasi setelah user di-redirect ke consumer website dari openid provider (untuk lebih jelasnya lihat langkah 1-7 di bawah ini).

Alur authentication openid diperlihatkan pada gambar di bawah ini. Gambar tersebut diambil dari white paper Eugene Tsyrklevich dan Vlad Tsyrklevich pada acara BlackHat USA 2007. Pada gambar di bawah ini komunikasi tidak langsung terjadi pada langkah nomor 4 dan 7, yaitu redirect. Sedangkan komunikasi langsung terjadi pada langkah nomor 3, yaitu negotiate crypto keys.

openid authentication flow

Gambar tersebut memperlihatkan alur ketika user login ke consumer website atau relying party. Penjelasan dari skenario pemakaian OpenID tersebut:

1. Login with openid URL
User membuka halaman consumer website (misal livejournal.com) dan login dengan memasukkan identifier openidnya, misal: masrizki.ilmuhacking.com
2. Download openid URL
Livejournal mengakses url http://masrizki.ilmuhacking.com dan menerima file html.
3. Negotiate crypto keys
Dari html yang didapat di url masrizki.ilmuhacking.com, livejournal menemukan delegation server di http://masrizki.pip.versignlabs.com. Di balik layar, livejournal berkomunikasi secara langsung dengan server openid provider pip.verisignlabs.com dengan protokol HTTP untuk menegosiasikan kunci kriptografi yang akan dipakai bersama. Kunci ini dipakai untuk menjaga integritas pesan antara consumer dan provider.
Openid memakai HMAC (Hash Message Authentication Code) untuk menjaga integritas pesan, oleh karena itu kedua pihak harus mengetahui kunci rahasia yang sama. Pertukaran kunci rahasia menggunakan protokol Diffie Helman.
4. Redirect
Karena user belum login ke pip verisign, maka livejournal mengirimkan perintah redirect ke halaman login pip verisignlabs.
5. Enter password
User memasukkan password di halaman login pip.
6. Authorize RP
Bila authentication berhasil (password benar), maka pip verisignlabs, akan meminta user untuk meng-otorisasi relying parter (livejournal.com). Bila user men-set Allow untuk selamanya (Never Expire), maka berikutnya tidak akan dimintai konfirmasi seperti ini.
7. Redirect
Provider berkomunikasi dengan consumer secara tidak langsung melalui browser user dengan mengirimkan perintah Redirect. Informasi yang dikirimkan dari provider ke consumer adalah status authentication, apakah sukses atau gagal. Bila authentication sukses, maka consumer web akan mengijinkan user mengakses consumer website dan mensetup session antara user dan consumer.
Langkah ke-7 adalah langkah terakhir bila menggunakan mode smart. Namun bila memakai mode dumb, ada satu langkah tambahan yaitu verifikasi. Verifikasi ini berguna untuk memastikan bahwa user yang bersangkutan benar-benar telah ter-otentikasi (autenticated) di provider, sehingga mencegah attacker yang ingin menipu consumer dengan request palsu.
Consumer akan mengirimkan request HTTP POST ke provider dengan membawa semua parameter yang diterima dari hasil redirect browser (langkah ke-7). Kemudian provider akan menjawab request tersebut dengan status valid atatu tidak valid.

Kesimpulan

OpenID menjanjikan solusi untuk mengelola identitas digital lebih baik dan lebih mudah. Dalam artikel ini saya hanya menjelaskan basic concept dan sekilas komunikasi openid. Penjelasan teknis dan detil komunikasi yang terjadi tidak saya expose di sini, saya akan expose dalam artikel berikutnya sekaligus membahas tentang keamanan openid.

Read more »

Posted in: Basic Concept

Mengenal Session Fixation Attack

Artikel ini adalah artikel lanjutan dari session hijacking basics. Session fixation attack adalah salah satu dari 3 jurus untuk mendapatkan sessionid korban. Jurus ini sangat berbahaya karena attacker tidak perlu capek menebak atau menangkap sessionid korban.

Stealing Session ID

Dalam artikel saya tentang Session Hijacking Basics, saya menjelaskan bahwa session id adalah kunci dari sebuah session. Jadi untuk membajak session, attacker tidak perlu username atau password, attacker cuma perlu session id. Lebih tepatnya adalah session id dari korban yang sessionnya masih hidup (korban sudah login dan belum logout).

Bagaimana cara attacker mendapatkan session id korban? Dalam artikel session hijacking basics saya juga menjelaskan bahwa ada 3 cara untuk mendapatkan sessionid, yaitu:

1. Predict
2. Capture
3. Fixate

Lebih lengkapnya silakan baca di artikel saya tersebut, dalam artikel ini saya hanya akan fokus membahas tentang cara ke-3 yaitu Fixation.

Session Fixation Attack

Mencari tahu session id korban dalam situasi tertentu sulit untuk dilakukan.  Berbeda dengan serangan lainnya, tujuan dari session fixation attack bukanlah mencuri sessionid, tapi membuat korban menggunakan sessionid yang telah disiapkan sebelumnya.

Dalam serangan session fixation, attacker MEMILIHKAN sessionid untuk korban

Dengan memilihkan sessionid untuk korban, attacker tidak perlu repot mencari tahu sessionid korban karena attacker sudah mengetahuinya sejak awal (karena dia yang memilih).

Sessionid dikirimkan ke server dengan dua cara:

• query string (url rewriting), contohnya index.php?PHPSESSID=abcd
• cookie

Inisiatif pembangkitan/pemilihan sessionid seharusnya dilakukan oleh server, bukan oleh client. Serangan session fixation bisa terjadi karena server mau menerima usulan sessionid dari client baik yang dikirimkan melalui cookie maupun query string (url rewriting). Usulan sessionid dari client bisa digenerate sendiri oleh client secara bebas, atau digenerate oleh server.

Fixation attack bisa terjadi karena server mau menerima usulan sessionid dari client

Bila server mau menerima usulan sessionid yang dikirim melalui query string, berarti serangan session fixation bisa dilakukan secara remote. Tapi bila server hanya mau menerima usulan sessionid dari cookie, maka serangan hanya bisa dilakukan secara lokal di browser korban. Serangan remote jauh lebih berbahaya karena cukup dengan memberikan link dan membuat korban mengklik link tersebut, maka korban sudah termakan jebakan attacker untuk memakai sessionid yang sudah dipilih attacker.

Remote Session Fixation

Serangan remote session fixation secara dengan sessionid bebas dipilih oleh attacker diperlihatkan pada gambar berikut:

remote fixation attack

Dalam kasus di atas attacker tidak perlu me-request sessionid dari server, karena bisa men-generate sendiri. Ketika korban login dengan link yang diberikan korban, maka korban telah terjebak menggunakan sessionid yang dipilih attacker untuk mengakses accountnya.

Ada juga server yang tidak mengijinkan penggunaan sessionid yang tidak dibuat oleh server. Dalam kasus ini skenarionya mirip namun ditambahkan satu langkah untuk me-request sessionid dari server. Perhatikan gambar berikut ini:

remote session fixation

Mirip dengan skenario sebelumnya, gambar di atas memperlihatkan attacker meminta session id ke server terlebih dahulu. Perhatikan bahwa server mungkin memberikan sessionid dalam bentuk cookie, namun ketika attacker menjebak korban, attacker memberikan sessionid dalam bentuk query string kepada korban. Jangan bingung, server biasanya menerima sessionid dalam cookie maupun url rewriting.

Dalam server yang menerima sessionid dalam cookie dan url rewriting, cookie mempunyai prioritas lebih dibanding url rewriting.

Jadi bila di browser sudah ada cookie JSESSIONID=abcd, ketika browser mengakses url dengan query string ?JSESSIONID=wxyz, maka sessionid yang dianggap adalah abcd karena berasal dari cookie.

Ada server yang lebih suka menggunakan cookie daripada query string sehingga server itu selalu memberikan cookie berisi sessionid bila menerima usulan sessionid melalui query string. Jadi untuk request selanjutnya klien tidak perlu menggunakan query string lagi, karena setiap request sessionid otomatis terikirim melalui cookie. Dalam kasus seperti ini serangan menjadi lebih mudah karena begitu korban mengklik link yang mengandung sesionid pada query stringnya, maka selanjutnya korban tidak perlu lagi menambahkan query string sessionid pada requestnya.

Local Session Fixation

Bila server hanya menerima usulan sessionid dari cookie, maka jurus session fixation tidak bisa dilakukan secara remote. Attacker harus menciptakan cookie berisi sessionid ke dalam browser korban. Untuk itu diperlukan akses fisik atau akses remote shell/desktop di komputer korban. Bila memiliki akses fisik atau remote desktop/shell, maka serangan ini mudah sekali dilakukan, cukup dengan membuat cookie berisi sessionid yang tanggal expirednya ditentukan masih sangat lama di komputer korban. Selanjutnya setiap korban membuka halaman yang ditarget attacker, maka sessionid yang dipakai adalah sessionid yang sudah dipilih oleh attacker.

Skenarionya adalah attacker mengakses situs yang ditargetnya, sehingga akan tercipta cookie di browser korban. Attacker memodifikasi waktu expired cookie tersebut menjadi sangat lama. Kemudian attacker mencatat sessionid tersebut dan meninggalkan komputer korban seperti semula.

Agar session tidak dianggap expired oleh server, dari komputer lain, attacker akan terus menerus mengakses situs target dengan cookie berisi sessionid tersebut. Begitu korban login dengan sessionid tersebut, maka attacker akan bisa mengakses account korban juga.

Mencoba Session Fixation di Komputer Sendiri

Untuk lebih mengerti mekanisme kerja session handling, saya akan membuat program kecil dalam php di URL komputer sendiri http://192.168.0.10/mylab/counter.php. Sebelumnya perlu diketahui bahwa sessionid dalam php defaultnya diberi nama PHPSESSID dan dalam contoh ini saya menggunakan nama defaultnya.

1 2 3 4 5 6 7 8 9 10 11

<?php session_start(); print "Session ID: ".session_id()."<br/>";   if (!isset($_SESSION["c"])) { $_SESSION["c"] = 0; } else { $_SESSION["c"]++; } print $_SESSION["c"]."<br/>"; ?>

Server Menentukan Session ID

Bila saya me-request URL tersebut tanpa mengirimkan sessionid dalam cookie maupun query string, maka server akan men-generate sessionid sendiri dan memberikan saya cookie. Sebelum request saya menghapus semua cookie dari host 192.168.0.10 agar tidak ada sessiondid yang terkirim dalam request. Beginilah request yang dilakukan browser saya:

1 2 3 4 5 6 7 8 9 10 11

http://192.168.0.10/mylab/counter.php   GET /mylab/counter.php HTTP/1.1 Host: 192.168.0.10 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive

Perhatikan bahwa pada request tersebut tidak ada satupun sessionid yang dikirimkan dalam bentuk cookie maupun query string. Mari kita lihat response yang diberikan server.

1 2 3 4 5 6 7 8 9 10 11 12

HTTP/1.x 200 OK Date: Mon, 02 Feb 2009 08:12:07 GMT Server: Apache/2.2.3 (Fedora) X-Powered-By: PHP/5.1.6 Set-Cookie: PHPSESSID=of6k7hsg17vl9jrg0b7lhrlck6; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 49 Keep-Alive: timeout=60000, max=489 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8

Pada baris ke-5 dari response terlihat bahwa server memberikan sessionid “of6k7hsg17vl9jrg0b7lhrlck6″ dalam bentuk cookie. Dalam kasus ini terlihat bahwa server yang menentukan sessionid dari sebuah session.

Client Menentukan Session ID dengan Query String

Kalau attacker ingin melakukan session fixation, maka sessionid harus ditentukan oleh client, bukan server. Sekarang kita coba memberikan sessionid dalam query string dan kita lihat request dan response yang terjadi. Seperti biasa saya menghapus semua cookie dari host tersebut sebelum melakukan request. Berikut requst yang terjadi:

1 2 3 4 5 6 7 8 9 10 11

http://192.168.0.10/mylab/counter.php?PHPSESSID=abcdef1234567890   GET /mylab/counter.php?PHPSESSID=abcdef1234567890 HTTP/1.1 Host: 192.168.0.10 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive

Dalam query string saya menambahkan PHPSESSID=abcdef1234567890 dengan maksud untuk memaksa server memakai sessionid tersebut sebagai sessionid dari session yang akan saya pakai. Mari kita lihat response yang diberikan server.

1 2 3 4 5 6 7 8 9 10 11 12 13

HTTP/1.x 200 OK Date: Mon, 02 Feb 2009 08:22:42 GMT Server: Apache/2.2.3 (Fedora) X-Powered-By: PHP/5.1.6 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 39 Keep-Alive: timeout=60000, max=490 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8   Session ID: abcdef1234567890<br/>0<br/>

Terlihat bahwa server menerima usulan saya untuk memakai “abcdef1234567890″ sebagai sessionid, terlihat dari hasil fungsi session_id() yang menghasilkan string tersebut. Dalam kasus ini saya sukses memaksa server memakai sessionid yang saya pilih melalui query string. Bila link http://192.168.0.10/mylab/counter.php?PHPSESSID=abcdef1234567890 saya berikan pada korban, dan korban mengkliknya, maka saya dan korban akan sama-sama memakai sessionid “abcdef1234567890″. Apa saja yang bisa diakses oleh korban saya juga bisa mengaksesnya.

Client Menentukan Session ID dengan Cookie

add session cookie

Setelah mencoba query string, sekarang kita coba memberikan sessionid dalam cookie dan kita lihat request dan response yang terjadi. Kali ini saya harus menambahkan cookie berisi “PHPSESSID=0123456789″ sebelum melakukan request. Berikut requst yang terjadi:

1 2 3 4 5 6 7 8 9 10 11 12

http://192.168.0.10/mylab/counter.php   GET /mylab/counter.php HTTP/1.1 Host: 192.168.0.10 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=01234567890

Pada baris terakhir terlihat cookie yang saya kirimkan berisi sessionid. Saya ingin server menerima usulan saya untuk memakai “01234567890″ sebagai sessionid. Berikut adalah response dari server.

1 2 3 4 5 6 7 8 9 10 11 12 13

HTTP/1.x 200 OK Date: Mon, 02 Feb 2009 08:34:08 GMT Server: Apache/2.2.3 (Fedora) X-Powered-By: PHP/5.1.6 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 34 Keep-Alive: timeout=60000, max=500 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8   Session ID: 01234567890<br/>0<br/>

Terlihat bahwa hasil dari fungsi session_id() menunjukkan bahwa session tersebut menggunakan “01234567890″ sebagai sessionid. Jadi saya sukses memaksa server memakai usulan saya sebagai sessionid.

Pencegahan

Anda telah melihat dalam contoh php di atas bahwa serangan session fixation tidak akan terjadi bila sessionid ditentukan oleh server, bukan oleh client. Dalam contoh php di atas bila client tidak memberikan sessionid dalam bentuk apapun, maka serverlah yang akan memberi sessionid. Jadi agar anda tidak terjebak memakai sessionid yang sudah diketahui orang lain, sebelum anda melakukan koneksi atau login, pastikan:

• Tidak ada cookie berisi sessionid untuk domain situs yang akan anda kunjungi.
• Pastikan URL yang anda kunjungi tidak mengandung query string yang berisi sessionid.

Kesimpulan

Session fixation adalah teknik mendapatkan sessionid yang sangat efektif. Cara ini lebih mudah dilakukan karena tidak perlu menebak sessionid, melakukan sniffing atau melakukan exploitasi XSS. Namun sayang awareness akan adanya teknik ini masih kurang, padahal di luar sana banyak situs yang rentan terhadap serangan ini. Dalam artikel berikutnya saya akan memberikan contoh serangan session fixation pada situs internet banking.

Read more »

Posted in: Basic Concept