webservice

This is the html version of the file http://www.cert.or.id/~budi/courses/ec7010/2003/report-rusiawan.pdf.Google automatically generates html versions of documents as we crawl the web.

TINJAUAN ASPEK KEAMANANSISTEM WEB SERVICETugas Akhir Semester I - 2003/2004EC 7010 - Keamanan Sistem LanjutDisusun oleh :Fx. Dwi I Rusiawan / 23202065Program Studi Magister Teknologi Informasi - Dept. Teknik ElektroInstitut Teknologi Bandung2003

Page 2

AbstrakWeb Service memberikan paradigma baru dalam mengimplemen-tasikan sistem terdistribusi melalui Web dengan menggunakan standardprotokol SOAP, WSDL dan UDDI yang berbasis XML. Dengan teknologiWeb Service, konsep sistem terdistribusi yang biasanya digunakan pada sistem yang bersifat tertutup dan proprietary (DCOM, CORBA, RMI)dapat diterapkan kedalam sistem yang bersifat terbuka (non-propriertary)berbasis Web. Penerapan Web Service akan memudahkan prosesintegrasi dan kolaborasi antar aplikasi pada lingkungan platform yangheterogen baik melalui jaringan Intranet maupun Internet, dengan biayayang lebih murah dan dalam waktu yang relative lebih cepat.Namun demikian, masih banyak yang ragu untuk segeramenerapkan Web Service, khususnya jika digunakan untuk mendukungtransaksi bisnis melalui Internet (global). Alasan utama yang menjadiperhatian adalah pada aspek keamanan dan kerentanan (vulnerability) yang terdapat pada teknologi Web Service. Sementara itu standardkeamanan yang biasa digunakan untuk mengamankan aplikasi berbasisWeb pada umumnya tidak cukup mampu untuk mengamankan transaksiWeb Service. Pada makalah ini dibahas berbagai aspek kerentanan dankeamanan yang ada pada Web Service, termasuk arsitektur keamanandan spesifikasi standard keamananan untuk Web Service. Secara khususdalam makalah ini dibahas spesifikasi WS-Security sebagai standardkeamanan Web Service. Kata kunci : Web Service, XML, SOAP, WS-Security.

Page 3

DAFTAR ISIAbstrak…………………………………………………………………. iDaftar Isi...................................................................... iiBAB I - PENDAHULUAN……. ..................................................... 1

1.1Permasalahan………………………………………………………….. 1 1.2Tujuan Penulisan ………………………………………………………….. 2BAB II - WEB SERVICE………………………………………………….. 32.1 Arsitektur Web Service ………………………………………………….. 32.2 Standard Teknologi Web Service………………………………….. 5BAB III - ASPEK KERENTANAN & KEAMANAN WEB SERVICE ….. 7 3.1 Sumber Kerentanan Web Service…………………………………. 73.1.1 Kerentanan pada XML …………………………………………. 73.1.2 Kerentanan pada SOAP …………………………………………. 93.2 Aspek Pengamanan Web Service…………………………………. 103.3 Serangan Keamanan pada Web Service…………………………. 12BAB IV - ARSITEKTUR KEAMANAN WEB SERVICE ………………….. 154.1Model Arsitektur Kemanan Web Service ................................. 154.2Spesifikasi Keamanan Web Service .......................................... 17BAB V - STANDARD KEAMANAN WEB SERVICE ......................195.1 Spesifikasi WS-Security………………………………………….. 205.1.1 Konsep Dasar WS-Security ………………………………….. 205.1.2 Mekanisme Proteksi Pesan ………………………………….. 215.1.3 Security Header ………………………………………………….. 225.2 Skenario Penggunaan WS-Security ………………………………….. 25BAB VI – KESIMPULAN………………………………………………….. 31Daftar Pustaka

Page 4Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 20031

BAB IPENDAHULUANPerkembangan Internet ikut mempengaruhi evolusi perkembangan sistem terdistribusi (distributed system), dari sistem yang berdasarkan pada platformproprietary (DCOM, CORBA, RMI) menuju platform yang lebih terbuka (Web).Momentum perkembangan ini diawali dengan kehadiran XML (eXtensible MarkupLanguage) untuk mendukung pertukaran data berbasis Web secara lebih fleksibel.Keberadaan standard XML kemudian ikut mendorong penetapan standard protokol komunikasi untuk mendukung mekanisme transfer data pada sistem terdistribusimelalui jaringan Internet yang dikenal sebagai Simple Object Access Protokol(SOAP) pada tahun 1998. Pada akhirnya kedua teknologi ini (XML dan SOAP)kemudian mendasari perkembangan arsitektur teknologi yang memungkinkan untukmenerapkan konsep sistem terdistribusi pada jaringan Internet berbasis Web, yangkemudian dikenal sebagai Web Service. Standard XML dan SOAP dikembangkan oleh World Wide Web Consortium

(W3C). Selanjutnya, W3C juga terlibat dalam pengembangan standard protokol danarsitektur untuk Web Service, seperti WSDL (Web Service Description Language), termasuk standard teknologi kemanan untuk Web Service seperti XML Encryption,XML Signature, dls. Disamping W3C, beberapa organisasi lain saat ini juga terlibatdalam pengembangan standard untuk Web Service, seperti Organization forAdvancement of Structured Information Standard(OASIS), Web ServiceInteroperability Organization (WS-I), dan Liberty Alliance Technology Group yangdisponsori oleh Sun Microsystem. Web Service memiliki keunggulan dibanding teknologi dengan sistemterdistribusi yang sudah ada seperti CORBA, DCOM dan RMI karena karakteristikWeb Service yang bersifat terbuka, non-propriertary, loosely coupled, dan modular. Web Service dapat diimplementasikan baik untuk lingkungan internal (Intranet)maupun untuk lingkungan publik (Internet). Dalam lingkungan internal, Web Servicememberikan kemudahan dan solusi baru untuk mengintegrasikan berbagai platformaplikasi yang ada dalam organisasi/perusahaan (Enterprises ApplicationIntegration/EAI). Dalam lingkungan publik, Web Service akan memperbaruhui konsep transaksi berbasis Internet seperti e-business dengan cara mengintegrasikanproses bisnis dengan partner bisnis secara lebih mudah, sederhana dan murah. Dansecara umum, Web Service akan mengubah paradigma para pengguna maupunpengembang perangkat lunak , dari API (application program interface)-basedmenjadi message-based. 1.1 PERMASALAHANWalaupun Web Service menjanjikan solusi untuk mengatasi kelemahanteknologi berbasis Web pada umumnya, namun demikian masih banyak yang merasaragu untuk segera menerapkan Web Service, khususnya pada lingkungan Internet(publik), misalnya untuk mendukung transaksi e-business. Keraguan ini disebabkanoleh faktor jaminan keamanan dari teknologi Web Service. Survey menunjukkan

Page 5Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 20032bahwa faktor keamanan merupakan masalah utama yang menjadi perhatian dalammengimplementasikan Web Service. Teknologi keamanan yang biasa digunakan untuk mengatasi aspek keamananpada sistem berbasis Web pada umumnya, seperti Secure socket Layer (SSL)/Transport Secure Layer (TSL), tidak cukup memadai jika diterapkan pada sistemberbasis Web Service. Hal ini dikarenakan SSL/TLS menyediakan solusi kemanandengan konteks point-to-point pada level transport layer. Sementara karakteristiktransaksi Web Service, membutuhkan pengamanan dalam konteks end-to-end padalevel application layer. Teknologi Firewall yang menyediakan pengamanan padalevel Network Layer juga tidak cukup memadai, karena karakteristik transaksi WebService yang menggunakan standard internet (HTTP, SMTP, FTP) akan dilewatkanoleh Firewall karena dianggap Sebagai trafik Internet pada umumnya (firewallfriendly). Walaupun teknologi keamanan yang ada saat ini masih memegang perananpenting, namun demikian masih diperlukan suatu mekanisme keamanan pada levelappplication layer yang dapat diterima luas oleh berbagai pihak yang terlibat dalamimplementasi Web Service, dan mendukung aspek interoperabilitas dalammengimplementasikan Web Service. Keberadaan standard kemananan Web Servicetersebut akan sangat mempengaruhi prospek penerapan Web Service secara luas.1.2TUJUAN PENULISANTujuan penulisan makalah ini adalah untuk memberikan tinjauan umummengenai berbagai aspek yang menyangkut keamanan dalam mengimplementasikansistem Web Service, antara lain meliputi :

▪ Konsep dasar teknologi Web Service yang relatif masih baru sehingga perluada penjelasan khusus▪ Aspek kerentanan dan keamanan dari Web Service yang perlu diperhatikandalam mengimplementasikan Web Service▪ Model Arsitektur Keamanan Web Service yang secara konsepsual memberilandasan dalam mengembangkan spesifikasi keamanan Web Service▪ Standard Kemanan untuk Web Service yang ada dan sedang dikembangkan saatini, khususnya terhadap spesifikasi WS-Security yang akan menjadispesifikasi inti untuk digunakan dalam mengamankan sistem Web Service.


BAB IIWEB SERVICEAda berbagai versi definisi mengenai Web Service, yang pada intinyamenggambarkan karakteristik dari Web Service, yaitu antara lain sebagai berikut :▪ Merupakan application logic yang dapat diakses dan dipublikasikan menggunakan standard Internet (TCP/IP, HTTP, Web).▪ Dideskripsikan dalam format XML. ▪ Didentifikasikan dengan Universal Resources Identifier (URI)▪ Bersifat Loosely coupled, self-contained, modular dan terbuka (non-proprietary) ▪ Digunakan untuk mendukung interoperabilitas interaksi machine-to-machinemelalui jaringan Internet/Intranet. Web Service dapat diimplementasikan pada lingkungan internal (Intranet)untuk kebutuhan integrasi antar sistem aplikasi (EAI=Enterprise ApplicationIntegration) ataupun pada lingkungan eksternal (Internet) untuk mendukung aplikasibusiness-to-business (e-business). 2.1 ARSITEKTUR WEB SERVICEKonsep arsitektur yang mendasari teknologi Web service adalah ServiceOriented Architecure (SOA). Dalam aritektur ini, suatu aplikasi dimodelkan sebagaikomposisi dari sekumpulan service yang disediakan oleh suatu komponen. Lokasikeberadaan komponen tersebut dapat ditemukan oleh client secara dinamis, dalamarti tidak dinyatakan secara statis tetapi menggunakan mekanisme discovery untukmencari keberadaan komponen tersebut. Demikian pula, client dapat meminta(invoke) service tersebut secara dinamis pula. Dalam arsitektur ini, SOAmendefinisikan 3 peran berbeda yang menunjukkan peran dari masing-masingkomponen dalam sistem, yaitu :▪ Service provider, yaitu suatu entitas yang menyediakan interface terhadapsistem yang menjalankan suatu sekumpulan tugas tertentu.Service provider dapat merepresentasikan statu entitas bisnisataupun suatu komponen software yang reusable. ▪ Service requestor , yaitu suatu entitas yang meminta/memperoleh (danmenemukan) software service dalam rangka meyelesai kansuatu tugas tertentu atau menyediakan solusi bisnis tertentu.▪ Service registry , yaitu entitas yang bertindak sebagai penyimpan (repository)suatu software service yang dipublikasikan oleh Serviceprovider. Peran dan interaksi antar komponen tersebut ditunjukkan pada gambar dibawahini :

Page 7Tinjauan Aspek Keamanan Sistem Web Service

Tugas EC-7010 : Keamanan Sistem Lanjut 20034Gambar 2.1- Konsep Service Oriented ArchitectureDalam arsitektur ini, Service dapat didefinisikan sebagai komponen (softwarecomponent) yang memiliki karakteristik :▪ Dapat dideskripsikan dalam suatu bahasa formal▪ Dapat dipublikasikan pada suatu registry of service▪ Dapat ditemukan (discover) menggunakan mekanisme standard▪ Dapat diminta/diperoleh (invoke) melalui jaringan▪ Dapat dibangun bersama service lainW3C mengilustrasikan model SOA tersebut sebagai deskripsi pesan yangdipertukarkan, seperti ditunjukkan pada gamber berikut ini.Gambar 2.2- Diagram generik Model Service Oriented Architecture.Model Arsitektur Web Service menggunakan konsep SOA tersebut dengansedikit perbedaan, yaitu :▪ Web Service menggunakan Standard terbuka, yaitu : XML (eXtensible MarkupLanguage) sebagai bahasa untuk mendeskripsikan data, SOAP (Simple ObjectAccess Protocol) sebagai protokol komunikasi antar komponen , WSDL (WebService Description Language) untuk mendesktipsikan service, UDDI(Universal Description, Discovery and Integration) untuk service discovery,dan HTTP sebagai transport layer.

Page 8Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 20035▪ Standard Web Service merupakan message-based, bukan API-based. Dalamhal ini, komunikasi antara Web Service, Service Requester dan ServiceRegistry menggunakan pesan SOAP berbasis XML.W3C mengembangkan draft arsitektur Web Service yang terdiri dari beberapateknologi yang saling berhubungan dan berlapis seperti digambarkan sebagaiberikut :Gambar 2.3- Arsitektur Web Service2.2 STANDARD TEKNOLOGI WEB SERVICESeperti yang ditunjukkan pada Gambar 1.3 tersebut diatas, Web servicetersusun dari beberapa komponen standard berbasis XML, yaitu : SOAP, WSDL, danUDDI. Simple Object Access Protocol (SOAP)SOAP merupakan suatu protokol berbasis XML yang digunakan untuk kebutuhanpertukaran informasi dalam suatu sistem terdistribusi dan terdesentralisasi, sepertihalnya IIOP (pada CORBA), ORCP (pada DCOM) dan JRMP (pada RMI). Berbedadengan RMI, CORBA dan DCOM, SOAP merupakan protokol yang bersifatindependent terhadap platform, model pemrograman, dan transport protocol yangdigunakan dalam proses pertukaran pesan SOAP. Pesan SOAP dapat dikirimkanmelalui HTTP, SMTP maupun FTP. Pesan SOAP berbentuk sekumpulan XML Schema yang mendefinisikan formatuntuk mentransmisikan pesan XML melalui jaringan, termasuk tipe data dan caramenstrukturkan pesan secara tepat sehingga dapat mudah dipahami oleh server atauend-point lainnya.

Page 9Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 20036Pesan SOAP terdiri dari 3 bagian, yaitu :▪ Envelope , suatu kerangka yang mendefinisikan apa yang ada dalam pesan

dan bagaimana pesan harus diproses serta menunjukkan resipien darimessage tersebut.▪ Header , berisi informasi yang berhubungan dengan keamanan dan routing.Keberadaan Header dalam SOAP bersifat optional. ▪ Body , berisi data yang berhubungan dengan aplikasi tertentu yang sedangdipertukarkan. Data di-‘mark-up’ sebagai XML dan dimasukkan dalamformat yang spesifik yang didefinisikan dalam XML Schema.Standard SOAP yang dikembangkan oleh W3C versi terakhir adalah SOAP versi1.2 yang ditetapkan pada 24 Juni 2003. Web Service Description Language (WSDL)WSDL merupakan bahasa standard yang menyediakan mekanisme untukmendeskripsikan Service yang disediakan oleh sistem (Web service), lokasikeberadaan service tersebut dan bagaimana cara memperolehnya, secara terstrukturdalam format XML. WSDL dapat dianalogikan sebagai IDL (interface definitionlanguage) dalam CORBA dan COM. Service dedeskripsi kan sebagai koleksi darientry-point atau port komunikasi. WSDL mendeskripsikan service denganmenggunakan elemen sebagai berikut :• Type – tipe data yang digunakan sebagai argumen dan return type• Message – merepresentasikan definisi data yang ditransmisikan• Port type – sekumpulan operasi yang didukung oleh satu atu lebih endpoint• Binding – mendefinisikan protokol dan format pertakaran data untuk operasiyang didefinisikan oleh Port type• Port – menspesifikasikan end-point yang digunakan untuk binding• Service – koleksi endpoint yang berkaitan yang disediakan oleh Web service• Operation – mendefinisikan kemampuan yang didukung oleh servis tertentuUniversal Description, Discovery & Integration (UDDI)UDDI merupakan sekumpulan spesifikasi yang menunjukkan registry informasimengenai Webservice. UDDI menyediakan mekanisme untuk mempublikasikan informasi mengenai bisnis dan service pada satu lokasi (repository) yang dikelolasecara terpusat dan melakukan query mengenai informasi tersebut secara dinamis danprogramatis. Direktory pada UDDI bertindak seperti ‘Yellow Pages’ dimana servicedikategorikan sesuai tujuan utamanya. Direktory UDDI terdiri dari 3 bagian, yaitu :• White pages – menyediakan informasi rinci mengenai organisasi yangmenawarkan service• Yellow pages – mencakup pengakatagorian jenis industri berdasarkan standardtaxonomi industri• Green pages – mendeskripsikan interface dan kebutuhan untuk memperolehservice , seperti return type.UDDI merupakan file XML Schema yang mendefinisikan struktur datamengenai karakteristik bisnis dan service. Deskrisi service didefinisikanmenggunakan dokumen Type Model (tModel). Secara umum UDDI berisi informasimengenai siapa yang menyediakan service (businessEntity), Service apa yangdisediakan (businessService), dimana lokasi service tersedia (bindingTemplate),referensi mengenai informasi bagaimana service tersebut diperoleh (tModel).


BAB IIIASPEK KERENTANAN DAN KEAMANANWEB SERVICEPada dasarnya sistem Web Service memiliki kerentanan (vulnerability) dasaryang sama dengan sistem berbasis Web lainnya yang menggunakan protokol HTTP.

Namun demikian, karena Web Service memiliki arsitektur sistem yang agak berbedadengan sistem berbasis Web lainnya, maka Web Service memiliki kerentanantambahan yang spesifik. Karentanan ini bersumber pada arsitektur Web Service danprotokol yang digunakan, yaitu dalam hal ini adalah : SOAP (Simple Object AccessProtocol) yang berbasis XML (eXtended Mark-up Language).3.1 SUMBER KERENTANAN WEB SERVICEDisamping memiliki memiliki kerentanan yang sama seperti aplikasi berbasisWeb lainnya (HTTP), Web Service memiliki kerentanan tambahan yang disebabkanoleh karakteristik teknologi yang mendasari Web Service, yaitu XML dan SOAP.Oleh karena itu standard keamanan yang biasa digunakan pada aplikasi berbasis Webtidak cukup memadai jika diterapkan pada Web Service. Karakteristik spesifik yang menjadi sumber kerentanan pada Web Serviceterletak pada 2 hal berikut ini, yaitu :▪ Protokol yang menjadi dasar teknologi Web Service, yaitu SOAP yangberbasis XML.▪ Arsitektur Web Service yang memberi landasan dalam hal mekanismetransaksi dan implementasi Web Service.Dalam subbab berikut ini pertama-tama akan dibahas mengenai kerentanan padaXML yang menjadi basis teknologi Web Service, kemudian protokol SOAP, yangjuga berbasis XML, yang digunakan sebagai protokol komunikasi antara ServiceRequest dan Service Provider.3.1.1 Kerentanan pada XML (XML Vulnerability) XML (eXtensible Mark-up Language) digunakan sebagai teknologi dasar dariWeb Service berdasarkan pertimbangan bahwa XML merupakan standard yangterbuka dan telah diterima secara luas untuk mendukung transaksi berbasis Internet.Dalam Arsitektur Web Service, XML diimplementasikan untuk menspesifikasikan elemen utama Web Service, yaitu :▪ Communication Protocol : SOAP (Simple Object Access Protocol)▪ Service Description : WSDL ▪ Service Publication & Discovery : UDDI. XML merupakan bahasa generik untuk pertukaran data melalui Internet danmenjadi standard platform komunikasi dalam sistem yang heterogen. Tidak sepertiHTML, XML memisahkan antara bagian Data (content) dan bagaimana dataditampilkan (presentation) secara terstruktur. Oleh karena itu, data pada XML

Page 11Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 20038membuka kemungkinan untuk dapat dimanipulasi oleh siapapun yang dapatmembacanya. XML juga mudah diterjemahkan oleh berbagai bahasa pemrograman.Karena sifat yang berbasis teks, mudah dibaca oleh manusia (human-readeble), makadokumen XML mudah untuk di-debug dan dilewatkan melalui Firewall. Suatuaplikasi yang berbasis XML dapat mendefinisikan markup tag untukmerepresentasikan elemen data yang berbeda dalam suatu file teks sedemikianhingga data dapat dibaca dan diproses oleh apllikasi yang menggunakan XML.Dengan menggunakan XML, suatu entitas bisnis dapat mendefinisikan suatu policydan mengekspresikannya dalam dokumen XML. Gambar 3.1- Contoh WSDL berbasis XMLDengan karakteristik yang berbasis teks dan bersifat terbuka tersebut, makakelemahan pada XML ini juga dapat menjadi sumber kerentanan pada aplikasiberbasis Web Service dengan membuka peluang adanya gangguan atau serangan(attack) terhadap keamanan dokumen WSDL, UDDI dan protokol SOAP yangberbasis XML. W3C dan OASIS telah menetapkan standard untuk menanganikerentanan XML, yaitu antara lain : XML Signature, XML Encryption, dan SAML.Pembahasan selengkapnya mengenai standard SAML ini akan diberikan pada Bab III,sementara XMLSignature dan XML Encryption sudah dibahas pada laporan tugas

akhir yang sudah ada sebelumnya.

Page 12Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200393.1.2 Kerentanan Pada SOAP SOAP merupakan standard protokol komunikasi untuk pertukaran informasidalam sistem Web Service. Pada umumnya pesan SOAP dikirim melalui protokolHTTP. Namum demikian pada dasarnya SOAP merupakan protokol yang independenterhadap layer transport. Dengan kata lain, pesan SOAP juga dapat dikirim melaluiSMTP, atau FTP. Dalam satu transaksi Web Service, suatu pesan SOAP dapatberjalan melalui layer transport yang berbeda-beda, misalnya, pada tahap pertamamenggunakan HTTP, kemudian diteruskan melalui SMTP, dan seterusnya. Pada aplikasi berbasis Web, bisanya digunakan standard pengamanan SecureSocket Layer/Transport Secure Layer (SSL/TSL) untuk mengamankan transaksimelalui HTTP. SSL memberikan jaminan confidentiality melalui mekanisme enkripsidan jaminan otentikasi menggunakan setifikat digital X.509 untuk sesi HTTP yangbersifat tunggal dan point-to-point. Namun demikian, SSL tidak dapat menyediakanmekanisme audit trail yang dapat menjamin bahwa sesi tersebut ada atau pernahterjadi. Gambar 3.2- Model kemanan dengan konteks point-to-pointOleh karena itu, solusi terhadap kelemahan dari SSL ini adalah dengan caramenerapkan mekanisme pengamanan pada pesan SOAP itu sendiri, bukan hanya padalayer transport dimana pesan SOAP dikirim. Solusi ini menjamin bahwa jika SOAPdikirim melalui jalur transport yang tidak aman, atau jika pesan SOAP harus dikirimmelalui beberapa layer transport yang berbeda-beda dan dalam lingkungan yang tidakaman, pesan SOAP tersebut dapat tetap dijamin aman. Misalnya, jika digunakananalogi antara SOAP dan Email. Jika Email dikirim melalui Internet, maka tidaklahcukup jika hanya meng-enkrip link antar Mail server, untuk itu pesan Email itusendiri juga perlu di-enkrip. Demikian juga halnya dengan pesan SOAP. OASIStelah mengembangkan standard untuk mengamankan pesan SOAP ini dengan namaWS-Security yang akan dibahas pada Bab III.Pada sisi lain, dalam Web Service, pesan SOAP di-generate oleh aplikasi,bukan oleh manusia/orang. Akan tetapi keputusan untuk pengamanannya tetapdidasarkan pada identitas orang yang melakukan transaksi. Misalnya dalam situasidimana Web Service digunakan pada kasus pengadaan barang, dimana seorang buyermasuk ke suatu Portal Pengadaan Barang dengan mengotentikasi dirinyamenggunakan password untuk membuat Purchase Order request. Pesan SOAPkemudian dikirim ke beberapa Supplier atas nama Buyer tersebut. Suppliermenggunakan mekanisme pengamanan layer transport untuk meng-otentikasipengirim pesan SOAP tersebut, dalam hal ini Portal Pengadaan Barang. Jika Supplieringin mengetahui siapa identitas Buyer yang mengirim Purchase Order requesttesebut, apa yang harus dilakukan ? Mekanisme pengamanan layer transport sepertiSSL tidak dapat melakukan kebutuhan demikian. Oleh karena itu konteks keamananharus dapat dapat menjamin mekanisme pengamanan end-to-end, dimulai dari end-SecurityContextServiceService ProviderIntermediarySecurityContext


Tugas EC-7010 : Keamanan Sistem Lanjut 200310user yang melakukan otentikasi menggunakan password (dalam contoh tersebutadalah Buyer) sampai dengan Web Service yang bekerja atas nama end-user denganmenggunakan pesan SOAP. Gambar 3.3- Model kemanan dengan konteks end-to-endDalam hal ini, mekanisme keamanan diterapkan dengan menyisipkaninformasi mengenai identitas user (security information) didalam pesan SOAP.Informasi tersebut mencakup antara lain : status otentikasi dari end-user (dalamkasus ini adalah Buyer), aktivitas yang diperbolehkan (otorisasi), dan atribut lainmengenai user tersebut yang berguna untuk menetapkan access control. OASIStelah menetapkan standard untuk maksud tersebut dengan nama SAML (SecurityAssertion Markup Language) yang menspesifikasikan bagaimana informasi mengenaiidentitas user tersebut didefinisikan dalam dokumen XML sebagai pernyataan(assertion) mengenai user. Sementara itu WS-Security mendefinisikan bagaimanapernyataan tersebut ditempatkan dalam pesan SOAP. Pembahasan mengenai standardini akan dibahas pada Bab III. 3.2 ASPEK PENGAMANAN WEB SERVICE Secara umum ada 5 aspek keamanan dasar yang perlu diperhatikan dalammengimplementasikan sistem berbasis Web pada umumnya termasuk dalam hal iniadalah aplikasi Web Service, yaitu : Authentication, Authorization, Confidentiality,Data Integrity dan Non-Repudiation. Disamping itu layanan aplikasi berbasis Webharus dapat memberikan konteks pengamanan secara end-to-end, dimana setiaptransaksi harus dapat dijamin keamanannya mulai dari asal transaksi sampai denganpenyelesaian akhir transaksi sehingga dapat mempertahankan keamanan yangkonsisten di semua tahapan pengolahan transaksi.OtentikasiOtentikasi (Authentication) merupakan proses untuk mengidentifikasi Pengirim mupun penerima. Seperti halnya aplikasi berbasis Web lainnya, Service requesterperlu di-otentikasi oleh service provider sebelum informasi dikirim. Sebaliknya,Service requester juga perlu meng-otentikasi Service provider. Otentikasi sangatpenting dan crucial diterapkan untuk melakukan transaksi di Internet. Saat ini telahtersedia standard yang biasa digunakan untuk menerapkan mekanisme Otentikasipada aplikasi berbasis Web pada umumnya, yaitu antara lain PKI, X.509 Certificate,Karberos, LDAP, dan Active Directory. Dalam kaitannya dengan Web Service, dokumen WSDL dapat dirusak melaluji serangan spoofing sedemikian hingga Servicerequester berkomunikasi bukan dengan Service privider sesungguhnya, melainkanSecurityContextServiceService ProviderIntermediary

Page 14Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200311dengan Spoofed Web Service. Oleh karena itu, dokumen WSDL perlu di-otentikasiuntuk menjamin integritas data.Gambar 3.4- Mekanisme Spoofing terhadap WSDLOtorisasiOtorisasi (authorization) menjamin bahwa requester yang telah berhasil melakukanotentikasi dapt meng-akses sumber daya yang ada sesuai dengan karakteristik akses(access control) yang disediakan. Aplikasi berbasis Web perlu melindungi datafront-end maupun back-end dan sumber daya sistem lainnya dengan menerapkanmekanisme kontrol akses, sebagai contoh : apa yang dapat dilakukan oleh

user/aplikasi, sumber daya apa yang dapat diakses, dan operasi apa yang dapatdilakukan terhadap data tersebut. ConfidencialityConfidentiality menjamin kerahasiaan (privacy) terhadap data/informasi yangdipertukarkan yaitu dengan melindungi data/informasi agar tidak mudah dibaca olehentitas (orang atau aplikasi) yang tidak berhak. Standard yang biasa digunakanuntuk menjaga kerahasiaan data yang dikirim adalah menggunakan teknologiEnkripsi, misalnya dengan metode Digital Signature. Service requestermenandatangani dokumen yang dikirimkan dengan suatu private key, danmengirimkannya bersamaan dengan body of message. Service provider kemudiandapat memverifikasi tandatangan tersebut dengan sender’s private key untuk melihatapakah ada bagian dari dokumen yang telah berubah. Dengan cara ini, sistem dapatmenjamin integritas data ketika melakukan komunikasi satu sama lain.Integritas DataIntegritas data menghendaki bahwa komunikasi antara client dan server dilindungidari adanya kemungkinan untuk merubah data oleh user/aplikasi yang tidak memilikihak untuk melakukan perubahan data. Dengan kata lain, Integritas Data menjaminbahwa data tidak berubah selama proses pengiriman data dari sumber ke tujuan. Standard yang biasa digunakan untuk mengamankan jalur komunuikasi berbasisInternet adalah Secure Socket Layer/Transport Layer Security (SSL/TSL) denganmenggunakan protokol HTTPS. Seperti suda dijelaskan tersebut diatas, SSL/TSLmemiliki konteks keamanan yang bersifat point-to-point antara Service requestor danService provider. Akan tetapi dalam banyak hal, service provider bukan tujuan finaldari pesan yang dikirimkan. Service provider dapat bertindak sebagai Service

Page 15Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200312requestor yang mengirimkan pesan ke berbagai Service provider lainnya, sepertidigambarkan sebagai berikut.Gambar 3.5- Model Transaksi dalam Web Service Untuk mengamankan mekanisme transaksi seperti tersebut diatas, dibutuhkanmekanisme keamanan dengan konteks end-to-end security, yaitu denganmenggunakan standard XML Encryption dengan cara meng-enkrip sebagian dariformat pesan, dimana bagian payload dari pesan di-enkrip, sedang bagian Headerdigunakan untuk kebutuhan routing.Non-Repudiation.Non-repudiation menjamin bahwa masing-masing pihak yang terlibat dalam transaksi(client & service provider) tidak dapat menyangkal terjadinya transaksi yang telahdilakukan. Mekanisme ini dapat dilakukan dengan menggunakan teknologi digitalsignature dan timestamping. Dengan teknologi digital signature, Sevice providertidak hanya memberikan bukti bahwa telah terjadi transaksi, tetapi juga merekamtranksaksi pesan kedalam audit log yang telah ditandatangani pula. Sekali audit logtelah ditandatangani, ia tidak dapat dimodifikasi (oleh Hacker) tanpa merubahtandatangan secara signifikan. 3.3 SERANGAN KEAMANAN PADA WEB SERVICESalah satu kunci kesederhanaan Web Service adalah bahwa Web Servicediimpelementasikan pada port 80 dan 443, sama seperti standard aplikasi berbasisWeb lainnya. Keuntungannya adalah dapat menyerdehanakan komunikasi antarabeberapa entitas, tetapi disisi lain memiliki kelemahan dengan membuka peluangmunculnya gangguan keamananan yang kurang dimengerti sebelumnya. Untukmengatasinya, biasanya digunakan Firewall yang dapat melakukan tugas seperti portmonitoring dan mengenali adanya serangan yang bersifat brute force, akan tetapiFirewall tidak dapat melakukan tugas untuk melihat isi pesan sebagai upaya untukmendeteksi dan mencegah adanya gangguan keamanan yang yang lebih kompleks.Pada sisi lain, Firewall tidak dapat memberikan proteksi terhadap serangan yang

berasal dari dalam (internal) perusahaan itu sendiri, seperti yang ditunjukkan padagambar berikut ini.

Page 16Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200313Gambar 3.6 – Contoh implementasi Keamanan Web Service dengan meggunakan FirewallFirewall dapat mengenali pesan SOAP, tetapi menganggapnya hanya sebagai trafik normal biasa seperti trafik HTTP pada umumnya. Walaupun demikian Firewalljuga dapat diatur (configure) untuk menolak atau mengijinkan trafik SOAP. SOAPinterface merupakan perangkat lunak yang memiliki format Application ProgramInterface (API) dan dapat menjalankan berbagai macam fungsi. Misalnya, suatuaplikasi Web Service dapat terdiri dari ratusan atau ribuan operasi yang dapatdilakukan, semuanya melalui port 80. Semetara itu dokumen WSDL dan isi UDDI menyediakan informasi rinci yang memberi peluang untuk Hacker untuk melihatisinya karena karakteristik XML yang bersifat (self-describing) dan secara jelasmenunjukkan elemen data. Beberapa jenis serangan yang mungkin terjadi terhadapaplikasi berbasis Web juga bisa terjadi pada aplikasi Web Service, yaitu antara lainadalah Denial of Service (DOS), Buffer Overflow, Reply Attack, dan DictionaryAttack. Gambar 3.7- Jenis gangguan kemanan pada Web ServiceDenial Of ServiceContoh serangan yang bersifat denial of service (DOS) ini misalnya pada kasusdimana suatu applikasi Web Service hanya mampu menerima transaksi persetujuanpinjaman uang sebanyak 5 permintaan sehari, tetapi suatu serangan DOS dapatterjadi jika ada 10 permintaan penjaman per jam yang dikirim untuk diproses olehsistem. Serangan DOS biasanya akan menyebabkan kelumpuhan sistem karenakekurangan sumber daya untuk melayani request yang masuk akibat DOS, yang dapatberakibat berhentinya operasi sistem.

Page 17Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200314Buffer OverflowSerangan buffer overflow pada Web Service terjadi jika ada parameter data yangdikirim lebih panjang dari pada yang bisa ditangani oleh sistem yang menyebabkansistem mengalami crash, atau sistem menjalankan kode yang tidak dikehendaki(undesired code) yang dikirim oleh penyerang. Metode untuk melakukan inibiasanya dilakukan dengan cara mengirimkan password dengan jumlah karakter lebihpanjang dari yang diharapkan. Serangan yang sama dengan buffer overflow adalahdikenal sebagai format string attack, yang berupa pengiriman string atau karakteryang tidak memiliki fungsi seperti tanda petik, tanda kurung, atau wildcard.Reply AttackReply attck dilakukan dengan menyalin pesan yang valid kemudian mengirimkanke Web Service server secara berulang-ulang, seperti halnya DOS. Untuk menanganiserangan ini dapat menggunakan metode yang sama dalam menghadapi DOS. Dalambeberapa kasus, Reply attack lebih mudah diteksi oleh Web Service karena payloadpesan dapat dengan mudah dibaca. Dengan bantuan tool yang tepat, pola seranganReply attack dapat diteksi secara mudah walaupun jira serangan dikirimkan melaluiberbagai medium seperti HTTP, HTTPS, SMTP, atau melalui berbagai interface yangberbeda.Dictionary AttackDictionary attack terjadi jika seorang hacker menyerang dengan cara mencobamemasukkan user ID dan Password untuk masuk ke sistem atau berbagai sistem

secara manual atau otomatis (programmatically). Oleh karena itu seorangAdministrator harus dapat meyakinkan bahwa password tidak mudah ditebak danselalu diperbaruhui/dirubah secara periodik.


BAB IVARSITEKTUR KEAMANAN WEB SERVICEModel arsitektur keamanan Web Service menekankan pentingnyamemanfaatkan proses dan teknologi keamanan yang ada saat ini denganmengantisipasi kebutuhan keamanan aplikasi untuk masa mendatang. Model inimenghendaki adanya perhatian terhadap beberapa isu, yaitu : menyatukan berbagaikonsep mengenai keamanan, solusi teknologi (misalnya secure messaging), prosesbisnis (dalam terminologi policy, risk, trust), serta koordinasi antara berbagai pihakyang terlibat, antara lain : vendor, application developer, network/infratructureprovider, dan customer. Model arsitektur yang dibahas dalam bab ini berdasarkanusulan dari Microsoft dan IBM dalam “Security in a Web Service World : A ProposedArchitecture and Roadmap”, April 7, 2002, Versi 1.0.Penyatuan lingkup teknologi keamanan yang ada saat ini dimaksudkan untukmemisahkan antara kebutuhan keamanan suatu aplikasi dengan mekanisme teknologiyang digunakan. Tujuannya adalah untuk memudahkan customer dalam membangunsuatu solusi yang saling dapat dioperasikan (interoperable) dalam suatu lingkunganyang heterogen. Proses integrasi dilakukan dengan membuat abstraksi terhadap suatumodel keamanan tertentu yang memungkinkan suatu organisasi menggunakaninvestasi teknologi keamanan yang ada saat ini untuk berkomunikasi denganorganisasi/perusahaan lain yang menggunakan teknologi yang berbeda.Pada sisi lain, setiap Web Service mempunyai kebutuhan aspek kemanananyang unik didasarkan pada kebutuhan bisnis dan lingkungan operasional yang khusus.Misalnya, untuk kebutuhan internal, maka kesederhanaan dan kemudahan operasionalmerupakan tuntutan utama, sementara untuk kebuthan eksternal (Internet) dibutuhkankemampuan untuk bertahan terhadap, misalnya, serangan DOS. Untuk mendukungkebutuhan demikian maka suatu model keamanan Web Service menghendaki adanyafleksibilitas dalam menggunakan mekanisme keamanan konvensional, tetapi disisilain dapat memberikan solusi bagi berbagai macam kebutuhan keamanan sistemmelalui penerapan kebijakan keamanan (security policy) dan perubahan konfigurasisistem. Dengan kata lain, model arsitektur kemanan Web Service merupakansekumpulan abstraksi keamanan yang menyatukan teknologi yang berbeda-beda yangtelah ada sebelumnya. Model arsitektur demikian dapat memenuhui kebutuhancustomer yang spesifik tetapi pada saat yang sama memungkinkan teknologi untukterus berkembang dan dapat diimplementasikan secara bertahap. Sebagai contoh,suatu Web Service dapat menerapakan model secure messaging (melalui enkripsiterhadap pesan) ketika mengirim pesan melalui lintasan yang aman denganmenggunakan mekanisme keamanan berbasis transport layer (SSL/TSL) yang sudahada. Sehingga pesan dapat memiliki aspek integritas (atau confidentiality) yang adadiluar transport layer.4.1 MODEL ARSITEKTUR KEAMANAN WEB SERVICEWeb Service dapat diakses dengan mengirimkan pesan SOAP ke service end-point yang diidentifikasikan dengan URI (Unified Reaources Identifier), untukmeminta aktivitas tertentu pada Web Service, dan kemudian menerima respon pesanSOAP (termasuk adanya indikasi adanya kesalahan, jika ada). Dalam konteks ini,tujuan pengamanan Web Service dibagi dalam beberap sub-goal yang menyediakanfasilitas untuk mengamankan integritas dan confidentiality pesan dan menjamin

Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200316service hanya akan melakukan perkerjaannya sesuai dengan isi pesan yangmerupakan ekspresi dari Claim yang dibutuhkan oleh suatu Policy. Fungsipengamanan terhadap integritas dan confidentialitity pesan dapat diterapkanmenggunakan teknologi SSL/TSL maupun IPSec. Namun demikian SSL/TSL maupunIPSec hanya menyediakan konteks keamanan yang bersifat point-to-point.Model arsitektur Web Service yang komprehensif membutuhkan mekanismekeamanan dengan konteks end-to-end. Model ini menghendaki adanya pengamananpada layer transport maupun aplikasi. IBM dan Microsoft mengusulkan suatu model arsitektur keamanan WebService untuk memenuhi kebutuhan tersebut diatas dengan suatu karakteristiksebagai berikut :▪ Web Service menghendaki bahwa setiap pesan yang masuk dapat menunjukkandirinya sebagai sekumpulan claim (misalnya: nama, key, permission,kapabilitas, dls). Jika suatu pesan datang tanpa memiliki claim yangdibutuhkan, maka Web Service dapat menolak atau menerima pesan tersebut.Sekumpulan claim dan informasi yang berkaitan dengannya disebut sebagaiPolicy.▪ Suatu requester dapat mengirim pesan dengan menunjukkan bukti mengenaiclaim yang dibutuhkan Web Service dengan menyertakan Security tokenbersama dengan pesan tersebut. Jadi, pesan meminta tindakan tertentu kepadaservice dan membuktikan bahwa pengirim pesan memiliki claim yang memintatindakan tersebut.▪ Jika requester tidak memiliki claim yang dikehendaki,requester atauseseorang yang mengatasnamakannya dapat mencoba memperoleh claim yangdiperlukan dengan mengkontak Web Service lain. Web Service ini, yangdisebut sebagai Security Token Service, dapat menghendaki sekumpulan claim.Security token service bertindak sebagai perantara trust antara berbagai trustdomain yang berbeda dengan menyertakan Security token. Model tersebut diilustrasikan pada gambar dibawah ini, dimana setiapRequester dapat menjadi Security Token Service , dan Security Token Service dapatmenjadi Web Service, yang mengekspresikan Policy dan menghendaki Security token.Gambar 4.1 - Model generik security messaging pada Web Service Model generik messaging tersebut, yaitu claim, policy dan security token, mendukung beberapa model yang lebih spesifik lainnya seperti halnya identity-based security, access-control list, dan capabilities-based security. Model ini jugamendukung teknologi yang ada saat ini seperti X.509 dan Karbero.

Page 20Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 2003174.2 SPESIFIKASI KEAMANAN WEB SERVICESpesifikasi Keamanan Web Service terdiri dari sekumpulan spesifikasi terpisahyang dikembangkan secara hirarkis dan berlapis diatas protokol SOAP. Masing-masing spesifikasi dikembangkan berdasarkan spesifikasi yang lain. Spesifikasi awalkeamanan Web Service terdiri dari : ▪ Message Security Model ▪ Web Service Endpoint Policy▪ Trust Model▪ Privacy ModelIBM dan Microsoft memberi nama masing-masing spesifikasi tersebut adalahWS-Security (untuk message security model), WS-Policy (untuk Web Service end-point policy), WS-Trust (untuk Trust model) dan WS-Privacy (untuk Privacy model).

Secara bersama spefikasi awal tersebut menyediakan landasan untuk menetapkankeamanan yang interoperable antar trust domain. Berdasarkan spesifikasi awaltersebut, kemudian dapat dikembangkan spesifikasi berikutnya yaitu secureconversation (WS-SecureConversation), federated trust (WS-Federation), danotorisasi (WS-Authorization). Struktur kerangka spesifikasi keamanan Web Service diilustrasikan sepertigambar dibawah ini.Gambar 4.2 – Arsitektur & Roadmap Spesifikasi Keamanan untuk Web ServiceKombinasi spesifikasi keamanan tersebut memungkinkan adanya banyakskenario yang akan sulit diimplementasikan jika menggunakan mekanisme keamanandasar yang ada saat ini. Secara ringkas, spesifikasi keamanan tersebut dapat dijelaskan sebagaiberikut :Spesifikasi Awal• WS-Security : Menjelaskan bagaimana menerapkan XML signature dan XMLEncryption pada Header pesan SOAP, serta bagaimana menyertakansecurity token, termasuk X.509, Karbero dan User Name/Password, kedalam pesan SOAP.• WS-Policy : menjelaskan kemampuan dan kendala dari security polici padalevel intermediate maupun end-point.• WS-Trust : menjelaskan bagaimana framework trustu relationship antarentitas bisnis

Page 21Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200318• WS-Privacy : menjelaskan suatu model bagaimana Web Service dan requestermenyatakan privasi subyek yang diinginkan dan privasi organisasi.Spesifikasi berikutnya• WS-SecureConversation : menjelaskan bagaimana mengelola danmemelakukan otentikasi pertukaran pesan • WS-Federation : menjelaskan bagaimana mengintegrasikan berbagaimekanisme manajemen identitas• WS-Authorization : menjelaskan bagaimana data otorisasi dan authorizationpolicy.


BAB VSTANDARD KEAMANAN WEB SERVICEKerentanan yang ada pada Web Service yang berbasis XML menjadipertimbangan utama yang mempengaruhui keragu-raguan para pengguna untukmengimplementasikan Web Service. Oleh Karena itu diperlukan standard teknologikeamananan Web Service untuk mendukung keamanan penerapan Web Service secaraluas. Walaupun demikian, standard yang ada saat ini seperti LDAP, PKI, SSL/TSLtetap memegang peranan penting untuk mengamankan Web Service dalam kontekspoint-to-point.Beberapa lembaga/organisasi profit maupun non-profit telah berupayauntuk mengembangkan standard keamanan XML dan Web Service. Diantaralembaga/organisasi tersebut, hingga saat ini ada 2 lembaga yang menjadi referensidalam penetapan standard keamanan XML Web Service yaitu W3C dan OASIS.

Tabel berikut ini menunjukkan beberapa standard keamanan XML Web Service yangtelah dan sedang ditetapkan oleh kedua organisasi tersebut [10] :StandardStandardBodyStatusDeskripsiXML Digital Signature(XDSIG)W3CCompleted Protokol untuk menandai isidokumen digital.Memberikan aspek integritas data, dan non-repudiationXML Encryption(XENC)W3CCompleted Protokol untuk mengeng-kripsi dan dekripsi isidokumen digital.XML Key ManagementSpecification(XKMS)W3CWorkingDraftProtokol untuk mendistribusikan dan me-registrasipublic keySecurity Assertion MarkupLanguage (SAML)OASISOpenStandardMenyediakan kerangkaXML untuk Web Serviceyang mendukung pertukaran otentikasi dan otorisasiinformasi antara partnerbisnis Extensible Access ControlMarkup Language (XACML)OASISOpenStandardSpesifikasi XML untukmengekspresikan Policytentang akses informasimelalui Internet.WS-SecurityOASISWorkingDraftSekumpulan standard untuk

mengamankan pesanSOAP pada aspek integritydan confidential- lityDalam bab ini fokus pembahasan hanya pada standard WS-Security yangmenjadi referensi penting bagi penerapan XML Web Service, dengan pertimbangansebagai berikut :

Page 23Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200320• WS-Security akan menjadi referensi standard keamanan Web Service olehberbagai pihak (user, vendor, organisasi lainnya). • WS-Security tidak menspesifikasikan standard keamanan tertentu yangberbeda, tetapi memanfaatkan berbagai standard keamanan lain, seperti X.509, Karberos, XML Digital Signature, XML Encryption, SAML, XKMS,dls. • WS-Security independent terhadap teknologi keamanan pada layer transport. Standard keamanan pada level transport seperti SSL/TLS, Karberos, X.509,LDAP, dls sudah banyak dibahas pada berbagai literature yang membahaskeamanan aplikasi berbasis Web pada umumnya, sehingga tidak dibahas secaradetail dalam bab ini.• WS-Security merupakan implementasi dari model arsitektur keamanan WebService seperti yang dibahas pada Bab III. 5.1 SPESIFIKASI WS-SecurityWS-Security atau juga dikenal sebagai Web Service Security Core Language(WSS-Core) merupakan spesifikasi keamanan Web Service yang mendefinisikanmekanisme pengamanan pada level pesan SOAP untuk menjamin message integrity &confidentiality. Standard WS-Security saat ini dikembangkan secara resmi oleh OASISberdasarkan spesifikasi yang diusulkan oleh Microsoft, IBM, dan VerySign pada 11April 2002. Selanjutnya, OASIS melalui Web Service Security Technical Committee(WSS) melanjutkan pengembangan WS-Security dengan menetapkan beberapaspesifikasi teknis terpisah, seperti Core Specification, SAML Profile, XMrL Profile,X.509 Profile, dan Karberos Profile. Produk WSS untuk Core Specification (WSS-Core) adalah WSS: Soap MessageSecurity. Spesifikasi lain yang merupakan bagian dari Core Specification ini adalahWSS: User Name Token Profile dan WSS: X.509 Certificate Token Profile. Disamping 2 organisasi tersebut, ada organisasi lain yang juga aktifmengembangkan standard keamanan Web Service yang disponsori oleh SunMicrosystem yaitu Liberty Alliance Technology Group. Namun pada akhirnyalembaga ini juga mengumumkan untuk memfokuskan diri pada pengembanganspesifikasi WS-Security dan berkerjasama dengan OASIS untuk maksud tersebut.Dengan demikian, WS-Security akan menjadi standard de-facto untuk pengamananWeb Service.5.1.1 Konsep dasar WS-SecuritySecara umum standard WS-Security (versi orisinal) mendefinisikan suatuspesifikasi mengenai bagaimana mengamankan pesan SOAP secara end-to-end,dengan cara menyertakan (attach) digital signature, enkripsi dan security tokenpada bagian Header dari pesan SOAP. Spesifikasi WSS-Core versi terbarumenyediakan 3 mekanisme untuk memproteksi pesan dari ancaman terhadap upayagangguan keamanan pesan SOAP, yaitu (1)Kemampuan untuk mengirim securitytoken sebagai bagian dari pesan SOAP, (2) Message integrity dan (3) Messageconfidentiality. Namun demikian, mekanisme tersebut tidak memberikan solusikeamanan yang lengkap untuk Web Service. Spesifikasi ini merupakan buildingblock yang digunakan untuk mengakomoda- sikan berbagai variasi model keamanandan teknologi kemanan.

Dengan kata lain, WS-Security tidak menspesifikasikan suatu mekanismekeamanan baru, tetapi menyediakan fleksibilitas untuk menggunaan teknologikeamanan yang sudah ada (X.509, Karberos, XML Encryption), sehingga dapat

Page 24Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200321mengakomodasi berbagai pendekatan keamanan secara umum. Hal baru yangditambahkan oleh WS-Security adalah suatu spesifikasi untuk menerapkanmekanisme keamanan yang sudah ada (existing) tersebut kedalam pesan SOAP. 5.1.2 Mekanisme Proteksi Pesan Secara umum struktur pesan Format SOAP yang mengimplementasikan WS-Security terdiri dari : Envelop, Header dan Body seperti digambarkan sebagaiberikut : Gambar 5.1- Diagram Struktur Pesan SOAP Spesifikasi keamanan Web Service diterapkan pada bagian Header dan/atauBody dari pesan SOAP. WSS-Core menspesifikasikan model keamanan pesan dalamdalam bentuk security token yang digabung dengan teknologi digital signature untukmelindungi dan meng-otentikasi pesan SOAP. Security Token menyediakanmekanisme untuk membuktikan informasi mengenai key dari Pengirim. Namundemikian, spesifikasi ini tidak mendefinisikan metode khusus untuk melakukanotentikasi, tetapi hanya menunjukkan bahwa security token dapat diterapkan dalampesan SOAP. Deklarasi security token dapat disyahkan oleh Otorisator ataupun tidakperlu disyahkan. Security token yang perla pengesahan disebut signed security token.Contoh penggunaan signed security token adalah X.509 Certificate dan Karberos.Security token yang tidak perlu pengesahan (unsigned security token) memerlukanmekanisme untuk menolak atau menerima pesan bersarkan kepercayaan padainformasi atau pengetahuan yang disertakan pada pesan tersebut. Contoh unsignedsecurity token ini adalah penggunaan User name/Password. Signature digunakan untuk memverifikasi keaslian dan integritas pesan.Signature juga dapat digunakan oleh Pengirim untuk menunjukkan kunci yangdigunakan untuk menkonfirmasi claim yang ada dalam security token, sehinggamemberikan identitas pada pesan tersebut. WSS-Core menspesifikasikan proteksi pesan dengan menerapkan enkripsi dandigital signature pada Header dan/atau Body dari pesan SOAP untuk menjaminintegritas dan kerahasiaan pesan. Integritas pesan diberikan dengan menerapkanXML Signature bersamaan dengan security token untuk menjamin bahwa modifikasiterhadap pesan dapat diteksi. Semnetara itu, kerahasiaan pesan diberikan dengan

Page 25Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200322menerapkanXML Encryptionbersamaan dengansecurity tokenuntukmempertahankan kerahasiaan bagian pesan SOAP. 5.1.3 Security HeaderSetiap pesan SOAP mempunyai suatu Penerima yang bertindak sebagaipenerima pesan dan merespon pesan. WS-Security versi original menyebut penerimasebagai Aktor. Sehingga, setiap pesan SOAP paling tidak mempunyai satu Aktor,yaitu orang bertindak berdasarkan pada pesan SOAP tersebut. Suatu pesan dapatmempunyai lebih dari satu Aktor jika melalui sederetan node intermediary, sepertiyang akan dijelaskan pada spesifikasi WS-Routing.

Informasi yang berhubungan dengan keamanan pesan SOAP disertakan(attach) pada bagian Header dari SOAP, tepatnya dalam blok yang diawali dengantag <Security>. Blok <Security> ini menyediakan mekanisme untuk menyertakaninformasi yang berkaitan dengan keamanan pada penerima tertentu, dandispesifikasikan oleh atribut Actor. Contoh syntax Header pada pesan SOAP menurutversi WS-Security versi orisinal ditunjukkan pada gambar dibawah ini.Gambar 5.2 - Struktur syntax Pesan SOAP (versi orisinal)Untuk setiap target Penerima yang berbeda, informasi yang berkaitan dengankeamanan harus dituliskan dalam elemen Security Header yang berbeda. SehinggaSecurity Header dapat muncul beberapa kali dalam pesan SOAP. Dalamperjalanannya, satu atau lebih Header baru dapat ditambahkan jika diperlukanpenambahan Target Penerima baru yang belum dispesifikasikan. Atribut Actor dalamsetiap Security Header mengidentifikasikan siapa yang menerima informasikeamanan tersebut. Jika atribut Actortidak disebutkan, elemen Security Headerdapat dikonsumsi oleh setiap orang, tetapi tidak dapat dihapus sampai mencapaitujuan akhirnya. Elemen Security Header juga menunjukkan tahapan ekripsi danpenandatanganan yang dilakukan oleh Pengirim ketika membuat pesan SOAP. Security Header ditambahkan pada pesan SOAP secara berurutan terhadapelemen yang suda ada, untuk menjamin bahwa aplikasi penerima dapat memprosessetiap sub-elemen sesuai dengan urutan keberadaannya pada elemen Header. Namundemikian, Spesifikasi WS-Security ini tidak menyebutkan secara khusus modepengurutan untuk pengolahan sub-elemen tersebut, sehingga aplikasi Penerima dapatmenggunakan apapun Policy yang diperlukan. Dalam spesifikasi terbaru WSS-Core (WSS: SOAP Message Security) yangditetapkan OASIS Web Service Security TC (WSS), atribut untuk aktor ini didiganti<S:Envelope><S:Header>...<Security S:actor="..." S:mustUnderstand="...">...</Security>...</S:Header> ...</S:Envelope>

Page 26Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200323dengan atribut role, dan spesifikasi Security Header terbaru menjadi sebagaiberikut :Gambar 5.3- Struktur syntax Pesan SOAP (versi WSS Core)Elemen Security yang dapat dimasukkan dalam Security Header pada pesanSOAP antara lain adalah :• User Name Token• Binary Security Token (misalnya untuk X.509 Certificate dan Karberos)• XML Token (SecurityTokenReference)• ds:KeyInfo• ds:Signature• XML Encryption• TimeStampContoh penggunaan security token, signature dan encryption sesuai denganspesifikasi WSS-Core secara lengkap dapat dilihat berikut ini :(001) <?xml version="1.0" encoding="utf-8"?>(002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">(003) <S:Header>(004) <wsse:Security>(005) <wsu:Timestamp>(006) <wsu:Created(007) wsu:Id="T0">2001-09-13T08:42:00Z</wsu:Created>(008) </wsu:Timestamp>(009)(010) <wsse:BinarySecurityTokenValueType="wsse:X509v3"wsu:Id="X509Token" EncodingType="wsse:Base64Binary">(011) MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...(012) </wsse:BinarySecurityToken>(013) <xenc:EncryptedKey>(014) <xenc:EncryptionMethod Algorithm=<S:Envelope><S:Header>...<wsse:Security S:role="..."S:mustUnderstand="...">...</wsse:Security>...</S:Header>...</S:Envelope>

Page 27Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200324"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>(015) <ds:KeyInfo>(016) <wsse:KeyIdentifier EncodingType="wsse:Base64Binary"ValueType="wsse:X509v3">MIGfMa0GCSq... (017) </wsse:KeyIdentifier>(018) </ds:KeyInfo>(019) <xenc:CipherData>(020)

<xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...(021) </xenc:CipherValue>(022) </xenc:CipherData>(023) <xenc:ReferenceList>(024) <xenc:DataReference URI="#enc1"/>(025) </xenc:ReferenceList>(026) </xenc:EncryptedKey>(027) <ds:Signature>(028) <ds:SignedInfo>(029) <ds:CanonicalizationMethodAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(030) <ds:SignatureMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>(031) <ds:Reference URI="#T0">(032) <ds:Transforms>(033) <ds:TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(34)</ds:Transforms>(035) <ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>(036) <ds:DigestValue>LyLsF094hPi4wPU...(037) </ds:DigestValue>(038) </ds:Reference>(039) <ds:Reference URI="#body">(040) <ds:Transforms>(041) <ds:TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(042) </ds:Transforms>(043) <ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>(044) <ds:DigestValue>LyLsF094hPi4wPU...(045) </ds:DigestValue>

(046) </ds:Reference>(047) </ds:SignedInfo>(048) <ds:SignatureValue>(049) Hp1ZkmFZ/2kQLXDJbchm5gK...(050) </ds:SignatureValue>(051) <ds:KeyInfo>(052) wsse:SecurityTokenReference>(053) <wsse:Reference URI="#X509Token"/>(054) </wsse:SecurityTokenReference>(055) </ds:KeyInfo>(056) </ds:Signature>(057) </wsse:Security>(058) <S:Header>(059) <S:Body wsu:Id="body">

Page 28Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200325(060) <xenc:EncryptedDataType="http://www.w3.org/2001/04/xmlenc#Element"wsu:Id="enc1">(061) <xenc:EncryptionMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>(062) <xenc:CipherData>(063) <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...(064) </xenc:CipherValue>(065) </xenc:CipherData>(066) </xenc:EncryptedData>(067) </S:Body>(068) </S:Envelope>5.2 SKENARIO PENGGUNAAN WS-SecurityMekanisme WS-Security dapat diterapkan untuk mengatasi berbagai isukeamanan. Berikut ini adalah beberapa contoh skenario untuk mendukungimplementasi WS-Security berdasarkan usulan oleh IBM dan Microsoft dalamdokumen ‘WS-Security AppNotes’ (15 Agustus 2002), yaitu :▪ Direct Trust using User Name/Password – skenario ini mengilustrasikanproses otentikasi menggunakan User Name dan Password dengan transport-

level security▪ Direct Trust using Security Token- skenario ini mengilustrasikan direct trustmenggunakan X.509 certificate dan Karberos service ticket.▪ Security Token Acquisition – skenario ini mengilustrasikan otentikasimenggunakan security token ▪ Firewall Processing - skenario ini mengilustrasikan bagaimana firewall dapatmendukung WS-Security dengan derajat kendali yang besar.▪ Issued Security Token - skenario ini mengilustrasikan mekanisme otentikasidasarDirect Trust using User Name/PasswordServer dimana Web Service berada menggunakan pasangan public key untukmenjamin keamanan kanal antara server dan client melalui koneksi HTTP denganmenggunakan SSL/TSL. Requester membuka koneksi ke Web Service denganmenggunakan transport-level security (SSL/TSL), dimana Requester mengirimkanpesan permintaan dengan menyertakan security token yang berisi user name danpassword. Sementara Web Service meng-otentikasi informasi yang terdapat dalampesan, memproses request dan merespon hasilnya.Dalam skenario ini integritas dan kerahasiaan pesan ditangani denganmenggunakan mekanisme keamanan berbasis transport-layer.

Page 29Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200326Contoh pesan SOAP yang dikirim dari Requester ke Web Service pada scenarioini adalah sebagai berikut :(001) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope">(002) <S:Header>(003) <wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"S:mustUnderstand="1">(004)<wsse:UsernameToken>(005) <wsse:Username>Zoe</wsse:Username>(006) <wsse:Password>ILoveDogs</wsse:Password>(007) </wsse:UsernameToken>(008) </wsse:Security>(009) </S:Header>(010) <S:Body>(011)<m:GetLastTradePrice xmlns:m="http://fabrikam123.com/">(012) <symbol>DIS</symbol>(013) </m:GetLastTradePrice>(014) </S:Body>(015) </S:Envelope>Direct Trust using Security Token

Skenario ini mengilustrasikan penggunaan security token yang secara langsungdipercaya valid (trusted) oleh Web Service. Dalam hal ini, direct trust berarti bahwasecurity token dikenal dan diverifikasi oleh Web Service. Skenario ini menganggapbahwa Requester dan Web Service telah menggunakan beberapa mekanisme untukmenetapkan trust relationship dalam menggunakan security token. Dengan kata lain,kedua belah pihak memahami dengan baik policy untuk privacy masing-masing.Requester mengirim pesan ke Web Service dengan dengan menyertakansecurity token, dan memberikan proof-of-possession (public/private key) terhadapsecurity token menggunakan digital signature. Service melakukan verifikasi terhadappublic/private key dan mengevaluasi security token, memproses permintaan danmengembalikan hasil pemrosesannya.Contoh pesan SOAP yang dikirim dari Requester ke Web Service pada scenarioini adalah sebagai berikut :

Page 30Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200327(001) <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">(002) <S:Header>(003)<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">(004) <m:action>http://fabrikam123.com/getQuote</m:action>(005) <m:to>http://fabrikam123.com/stocks</m:to>(006)<m:from>mailto:[email protected]</m:from>(007) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>(008)</m:path>(009)<wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"S:mustUnderstand="1">(010)<wsse:BinarySecurityTokenEncodingType="wsse:Base64Binary"wsu:Id="X509Token"ValueType="wsse:X509v3">(011)MIIDQTCCAqqgAwIBAgICAZIhvcNAQEFBQAwTjELMAkGA1UEBhMCS...(012) </wsse:BinarySecurityToken>(013) <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">(014)<SignedInfo>(015) <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(016) <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>(017)

<Reference URI="">(018) <Transforms>(019) <Transform Algorithm="http://...#RoutingTransform"/>(020) <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(021)</Transforms>(022) <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>(023)<DigestValue>yH8GsCH3FT747UhqqzHqqSTj7CM=</DigestValue>(024) </Reference>(025)</SignedInfo>(026) <SignatureValue>(027) TQtb/T9NTGgRzbtDCctfw0SKY7/PHVZtPMFoLtPCixU3Kobis/Q...(028) </SignatureValue>(029)<KeyInfo>(030) <wsse:SecurityTokenReference>(031)<wsse:Reference URI="#X509Token"/>(032)</wsse:SecurityTokenReference>(033)</KeyInfo>(034)</Signature>(035) </wsse:Security>(036) </S:Header>(037)<S:Body>(038) <m:GetLastTradePrice xmlns:m="http://www.fablikam123.com/">(039) <symbol>DIS</symbol>(040)</m:GetLastTradePrice>(041) </S:Body>(042) </S:Envelope>

Page 31Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200328Security Token AcquisitionDalam skenario ini, security token tidak terdapat dalam pesan SOAP,

melainkan menggunakan mekanisme security token reference untuk mencari danmengambil token. Requester mengirim pesan ke service dengan menyebutkanreferensi terhadap keberadaan security token, dan menyediakan proof-of-possessiondalam bentuk XML Signature. Web Service menggunakan informasi yang ada padasecurity token reference untuk memperoleh security token dari security token servicedan memvalidasi private/public key (proof). Web Service menerima (trusted)security token, sehingga request diproses dan dikembalikan hasilnya ke requester. Contoh pesan SOAP yang dikirim dari Requester ke Web Service pada scenarioini adalah sebagai berikut :xmlns:S="http://www.w3.org/2001/12/soap-envelope">(002) <S:Header>(003)<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">(004) <m:action>http://fabrikam123.com/getQuote</m:action>(005) <m:to>http://fabrikam123.com/stocks</m:to>(006)<m:from>mailto:[email protected]</m:from>(007)<m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>(008)</m:path>(009)<wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"S:mustUnderstand="1">(010) <wsse:SecurityTokenReference wsu:Id="token1">(011)<wsse:Reference URI="ldap://fabrikam123.com/CN=John..."/>(012) </wsse:SecurityTokenReference>(013) <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">(014) <SignedInfo>(015) <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(016)<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>(017) <Reference URI="">(018) <Transforms>(019)<TransformAlgorithm="http://...#RoutingTransform"/>(020) <TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(021) </Transforms>

Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200329(022) <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>(023) <DigestValue>yH8G3FT747UhqqzHqqSTj7CM=</DigestValue>(024) </Reference>(025)</SignedInfo>(026) <SignatureValue>(027)TQtb/+yR56T9NTGgRzbtDCctfw0SKY7/Pq2FoLtPCixU3Kobis/Q...(028) </SignatureValue>(029) <KeyInfo>(030) <wsse:SecurityTokenReference>(031) <wsse:Reference URI="#token1"/>(032)</wsse:SecurityTokenReference>(033)</KeyInfo>(034) </Signature>(035)</wsse:Security>(036) </S:Header>(037) <S:Body>(038) <m:GetLastTradePrice xmlns:m="http://www.foo.com/">(039) <symbol>DIS</symbol>(040) </m:GetLastTradePrice>(041) </S:Body>(042) </S:Envelope>Firewall ProcessingFirewall melakukan evaluasi terhadap pesan SOAP yang datang, dan hanyamengijinkan pesan yang berasal dari requester yang telah diotorisasi untuk melewatiFirewall. Dalam skenario ini, Firewall membuat keputusan dengan mengevaluasisecurity token yang digunakan untuk menandatangani pesan. Dalam skenario yang lain, Firewall dapat juga bertindak sebagai security tokenyang meminta otoritas dan hanya mengijinkan pesan yang memiliki proof-of-possession (private/public key) terhadap security token yang diminta oleh Firewall. Contoh pesan SOAP yang dikirim dari Requester ke Web Service pada skenarioini adalah sebagai berikut :


30(001) <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">(002) <S:Header>(003) <m:path xmlns:m="http://schemas.xmlsoap.org/rp/">(004) <m:action>http://fabrikam123.com/getQuote</m:action>(005) <m:to>http://fabrikam123.com/stocks</m:to>(006) <m:fwd>(007) <m:via>http://firewall.fabrikam123.com/</m:via>(008) </m:fwd>(009) <m:from>mailto:[email protected]</m:from>(010) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>(011) </m:path>(012) <wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"S:actor="http://firewall.fabrikam123.com/"S:mustUnderstand="1">(013) <wsse:BinarySecurityTokenEncodingType="wsse:Base64Binary"wsu:Id="X509Token4Firewall"ValueType="wsse:X509v3">(014) MIIDQTCCAqqgAwIBAgICAQQwDQYJ...(015) </wsse:BinarySecurityToken>(016) <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">(017) <SignedInfo>(018) <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-14n#"/>(019) <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>(020) <Reference URI="">(021) <Transforms>(022) <Transform Algorithm="http://...#RoutingTransform"/>(023) <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(024) </Transforms>

(025) <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>(026) <DigestValue>yH8GsCH3FTqzHqqSTj7CM=</DigestValue>(027) </Reference>(028) </SignedInfo>(029) <SignatureValue>(030) f5JJPvwToxNBBzy5R3om/ZtTK63jw...(031) </SignatureValue>(032) <KeyInfo>(033) <wsse:SecurityTokenReference>(034) <wsse:Reference URI="#X509Token4Firewall"/>(035) </wsse:SecurityTokenReference>(036) </KeyInfo>(037) </Signature>(038) </wsse:Security>(39)<wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"

Page 34Tinjauan Aspek Keamanan Sistem Web ServiceTugas EC-7010 : Keamanan Sistem Lanjut 200331S:mustUnderstand="1">(040) <wsse:BinarySecurityTokenEncodingType="wsse:Base64Binary"wsu:Id="X509Token4Stockquote"ValueType="wsse:X509v3">(041) MIIDQTCCAqqgAwIBAgICAQQwDQYJKoZIhvcNAQEF...(042) </wsse:BinarySecurityToken>(043) <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">(044) <SignedInfo>(045) <CanonicalizationMethodAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(046) <SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>(047) <Reference URI="">(048) <Transforms>(049) <TransformAlgorithm="http://...#RoutingTransform"/>(050) <TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>(051) </Transforms>(052) <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>(053) <DigestValue>yH8GsCH3FT7qqSTj7CM=</DigestValue>(054) </Reference>(055) </SignedInfo>(056) <SignatureValue>(057) OZ21MKnCQi2Jglw2qIO5e1azezl/j0BP3h2Ut...(058) </SignatureValue>(059) <KeyInfo>(060) <wsse:SecurityTokenReference>(061) <wsse:Reference URI="#X509Token4Stockquote"/>(062) </wsse:SecurityTokenReference>(063) </KeyInfo>(064) </Signature>(065) </wsse:Security>(066) </S:Header>(067) <S:Body>(068) m:GetLastTradePrice xmlns:m="http://www.fabrikam123.com/">(069) <symbol>DIS</symbol>(070) </m:GetLastTradePrice>(071) </S:Body>(072) </S:Envelope>


Tugas EC-7010 : Keamanan Sistem Lanjut 200332Issued Security TokenSkenario ini hampir sama dengan Security Token Acquisition, kecuali bahwa security token dikirim ke Requester dari Security Token Service , kemudian pesanpermintaan dikirim ke Web Service dengan menyertakan security token tersebutmenggunakan elemen <BinarySecurityToken>. Security token dapat berupa X.509atau Karberos. Sekali security token dikirim oleh Secuirty token service, securitytoken tersebut dapat digunakan beberapa kali oleh, misalnya untuk Web Service yangberbeda jika token yang dikirim mengijinkan hal tersebut.


BAB VIKESIMPULANArsitektur dan teknologi Web Service sangat rentan terhadap upayagangguan keamanan dari pihak-pihak yang tidak dikehendaki (attacker). Jenisgangguan kemanan yang dihadapi oleh Web Service pada dasarnya samadengan yang dihadapi oleh sistem berbasis Web lainnya. Tetapi Web Servicememperkenalkan sumber sumber kerentanan tambahan yang secara spesifikberasal dari protokol berbasis XML (SOAP dan WSDL) yang digunakan dalamWeb Service. Oleh karena itu standard keamanan yang ada saat ini sepertiSSL/TSL tidak cukup memadai, walaupun masih memegang peranan penting, jika digunakan untuk mengamankan transaksi berbasis Web Service, karenahanya dapat mengamankan dalam konteks point-to-point. Implementasi WebService membutuhkan konsep keamanan pada level application layer yangbersifat end-to-end. Dari beberapa spesifikasi stándard keamanan Web Service yang ada, WS-Security menyediakan arstitektur keamanan yang lebih komprehensif danindependen terhadap teknologi keamanan yang ada. Spesifikasi WS-Securityditujukan untuk mengamankan pesan SOAP pada bagian header maupun body. Konsep WS-Security menekankan pada pemanfaatan teknologi keamanan yangsudah ada, namun dapat mengantisipasi perkembangan teknologi dimasa depan.WS-Security menjamin integritas data dan kerahasiaan (confidentiality) denganmengimplementasikan teknologi XML Signature dan XML Encryption. Disamping itu, WS-Security menerapkan konsep mengenai secure messagingdengan menggunakan security token untuk mengimplementasikan teknologikemanan yang ada seperti C.509 certificate maupun Karberos akan memberikan jaminan pada aspek otentitas dan otorisasi. Adopsi spesifikasi WS-Security oleh para platform vendor maupunpengembang perangkat lunak (software developer) sangat menentukan prospekpenerapan Web Service secara luas. Disisi lain, adopsi spesifikasi WS-Securityjika dikaitkan dengan aspek perfomansi sistem akan menjadi pertimbanganyang dilematis bagi pengguna maupun pengembang perangkat lunak yang akanmenggunakan teknologi Web Service.)OoO(

Page 37

DAFTAR PUSTAKA[1] Andrew Yang, “Implement Web Service Securely”, .NET Magazine, TechnicalEdition, 2003. Available :http://www.ftponline.com/wss/2003_TE/magazine/features/ayang/[2] Andy Yang, “Web Service Security”, eAI Journal, September, 2002. Available :http://eaijournal.com/PDF/Yang.pdf [3] Caroline Clewlow, “SOAP and Security”, Whitepaper, Microsoft Corporation, October 2002. Available : http://www.qinetiq.com[4] David Chappell, “WS-Security: New Technologies Help You Make Your Web Service More Secure ”,Microsoft Corporation, 2003. Available : http://msdn.microsoft.com/msdnmag/issues/03/04/WS-Security/[5] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana: Web Services Description Language(WSDL) 1.1, 15 March 2001. Available : http://www.w3.org/TR/wsdl.[6] IBM and Microsoft: “Security in a Web Services World: A Proposed Architecture and Roadmap”,Whitepaper, Version 1.0, 7 April 2002. Available : http://www-106.ibm.com/developerworks/library/ws-secmap/ [7] IBM and Microsoft: “Web Service Security (WS-Security)”, Specification, Version 1.0, 02 April2002. Available : http://www-106.ibm.com/developerworks/library/ws-secure/ [8] IBM and Microsoft: “WS-Security AppNotes”, Whitepaper, Version 1.0, 15 Agustus 2002. Available : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security-appnote.asp [9] M. Curphey, D. Endler, W. Hau, S. Taylor at al., “A Guide to Building Secure Web Applications: TheOpen Web Application Security Project”, 11 September 2002 . Available : http://www.owasp.org/guide/ .[10] Maria Tzvetanova, “Security for Web Service”, Master Thesis, University of Constance , May,2003. Available : http://www.inf.uni-konstanz.de/~tzvetano/assets/docs/security_for_webservices.pdf[11] M. Champion, Ch. Ferris, E. Newcomer, D. Orchard, “Web Services Architecture”, W3C WorkingDraft , 14 November 2002. Available : http://www.w3.org/TR/ws-arch .[12] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, E. Simon, “XML Signature Syntax and Processing”,W3C Recommendation, 12 February 2002 . Available : http://www.w3.org/TR/xmldsig-core/ [13] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, C. Henrik Frystyk Nielsen, “SOAP Version1.2 Part 1: Messaging Framework ”, W3C Recommendation , 24 June 2003. Available :http://www.w3.org/TR/SOAP.

Page 38[14] Mark O’Neill, “Architecting Security for Web Service”, JAVAPro, Agustus2003. Available :http://www.ftponline.com/javapro/2003_08/magazine/features/moneill/default_pf.aspx[15] M. Hondo,”Securing Web Services”, IBM System Journal, Volume 41, Number 2, 02 April 2002 .Available : http://www.research.ibm.com/journal/sj/412/hondo.html [16] OASIS Security Services Technical Committee, “Assertions and Protocol for the OASIS SecurityAssertion Markup Language (SAML)”, Committee Specification 01, 31 May 2002. Available : http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf [17] OASIS Security Services Technical Committee, “Security Assertion Markup Language”, 1December 2002 .Available : http://www.oasis-open.org/committees/security/ [18] OASIS Web Services Technical Committee, “Web Services Security Core Specification”, WorkingDraft 17, 27 Agustus 2003. Available :http://www.oasis-open.org/committees/wss/documents/WSS-Core-17-082703-merged.pdf [19] Scott Seely, “Understanding WS-Security”, Microsoft Corporation, October 2002. Available : http://www-106.ibm.com/developerworks/library/ws-secmap/ [20] The Stencil Group, Inc., “The Evolution of UDDI, UDDI.org”, White Paper, 19 July 2002.Available : http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf.[21] T. Imamura, B. Dillaway, E. Simon, “XML Encryption Syntax and Processing”, W3C

Recommendation 10 December 2002 . Available : http://www.w3.org/TR/xmlenc-core/ [22] Westbridge Technology,Inc., “Technology Manager’s Guide to XML Web Service Security”, 6Januari 2003. Available : http://www.westbridgetech.com

webservice

Documents

arsitektur web service

standard teknologi web

dengan teknologi web

aspek pengamanan web

sumber kerentanan web

kerentanan pada xml

kerentanan pada soap

dan modular