Pemrograman Layanan Web

WEB SERVICES SECURITY
PENGERTIAN WEB SERVIS SECURITY

Web Servis Security adalah suatu konsep untuk mengamankan Web. OASIS telah mengembangkan standard untuk mengamankan pesan SOAP yang dikenal dengan nama WS-Security. WS-Security mendefinisikan suatu spesifikasi mengenai bagaimana mengamankan pesan SOAP secara end-to-end, dengan cara menyertakan (attach) digital signature, enkripsi dan security token pada bagian Header dari pesan SOAP.
WSS menyediakan 3 mekanisme untuk memproteksi pesan dari ancaman terhadap upaya gangguan keamanan pesan SOAP, yaitu (1)Kemampuan untuk mengirim security token sebagai bagian dari pesan SOAP, (2) Message integrity dan (3) Message confidentiality. Namun demikian, mekanisme tersebut tidak memberikan solusi keamanan yang lengkap untuk Web Service. Spesifikasi ini merupakan building block yang digunakan untuk mengakomoda- sikan berbagai variasi model keamanan dan teknologi kemanan. Dengan kata lain, WS-Security tidak menspesifikasikan suatu mekanisme keamanan baru, tetapi menyediakan fleksibilitas untuk menggunaan teknologi keamanan yang sudah ada (X.509, Karberos, XML Encryption), sehingga dapat mengakomodasi berbagai pendekatan keamanan secara umum. Hal baru yang ditambahkan oleh WS-Security adalah suatu spesifikasi untuk menerapkan mekanisme keamanan yang sudah ada (existing) tersebut kedalam pesan SOAP.

ASPEK PENGAMANAN WEB SERVICE
Secara umum ada 5 aspek keamanan dasar yang perlu diperhatikan dalam mengimplementasikan sistem berbasis Web pada umumnya termasuk dalam hal ini adalah aplikasi Web Service, yaitu : Authentication, Authorization, Confidentiality, Data Integrity dan Non-Repudiation. Disamping itu layanan aplikasi berbasis Web harus dapat memberikan konteks pengamanan secara end-to-end, dimana setiap transaksi harus dapat dijamin keamanannya mulai dari asal transaksi sampai dengan penyelesaian akhir transaksi sehingga dapat mempertahankan keamanan yang konsisten di semua tahapan pengolahan transaksi.

Otentikasi
Otentikasi (Authentication) merupakan proses untuk mengidentifikasi Pengirim maupun penerima. Seperti halnya aplikasi berbasis Web lainnya, Service requester perlu di-otentikasi oleh service provider sebelum informasi dikirim. Sebaliknya, Service requester juga perlu meng-otentikasi Service provider. Otentikasi sangat penting dan crucial diterapkan untuk melakukan transaksi di Internet. Saat ini telah tersedia standard yang biasa digunakan untuk menerapkan mekanisme Otentikasi pada 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 Service requester berkomunikasi bukan dengan Service privider sesungguhnya, melainkan dengan Spoofed Web Service. Oleh karena itu, dokumen WSDL perlu di-otentikasi untuk menjamin integritas data.

Otorisasi
Otorisasi (authorization) menjamin bahwa requester yang telah berhasil melakukan otentikasi dapat meng-akses sumber daya yang ada sesuai dengan karakteristik akses (access control) yang disediakan. Aplikasi berbasis Web perlu melindungi data front-end maupun back-end dan sumber daya sistem lainnya dengan menerapkan mekanisme kontrol akses, sebagai contoh : apa yang dapat dilakukan oleh user/aplikasi, sumber daya apa yang dapat diakses, dan operasi apa yang dapat dilakukan terhadap data tersebut.

Confidenciality
Confidentiality menjamin kerahasiaan (privacy) terhadap data/informasi yang dipertukarkan yaitu dengan melindungi data/informasi agar tidak mudah dibaca oleh entitas (orang atau aplikasi) yang tidak berhak. Standard yang biasa digunakan untuk menjaga kerahasiaan data yang dikirim adalah menggunakan teknologi Enkripsi, misalnya dengan metode Digital Signature. Service requester menandatangani dokumen yang dikirimkan dengan suatu private key, dan mengirimkannya bersamaan dengan body of message. Service provider kemudian dapat memverifikasi tandatangan tersebut dengan sender’s private key untuk melihat apakah ada bagian dari dokumen yang telah berubah. Dengan cara ini, sistem dapat menjamin integritas data ketika melakukan komunikasi satu sama lain.

Integritas Data
Integritas data menghendaki bahwa komunikasi antara client dan server dilindungi dari adanya kemungkinan untuk merubah data oleh user/aplikasi yang tidak memiliki hak untuk melakukan perubahan data. Dengan kata lain, Integritas Data menjamin bahwa data tidak berubah selama proses pengiriman data dari sumber ke tujuan. Standard yang biasa digunakan untuk mengamankan jalur komunuikasi berbasis Internet adalah Secure Socket Layer/Transport Layer Security (SSL/TSL) dengan menggunakan protokol HTTPS. Seperti suda dijelaskan tersebut diatas, SSL/TSL memiliki konteks keamanan yang bersifat point-to-point antara Service requestor dan Service provider. Akan tetapi dalam banyak hal, service provider bukan tujuan final dari pesan yang dikirimkan. Service provider dapat bertindak sebagai Service requestor yang mengirimkan pesan ke berbagai Service provider lainnya. Untuk mengamankan mekanisme transaksi, dibutuhkan mekanisme keamanan dengan konteks end-to-end security, yaitu dengan menggunakan standard XML Encryption dengan cara meng-enkrip sebagian dari format pesan, dimana bagian payload dari pesan di-enkrip, sedang bagian Header digunakan 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 telah dilakukan. Mekanisme ini dapat dilakukan dengan menggunakan teknologi digital signature dan timestamping. Dengan teknologi digital signature, Sevice provider tidak hanya memberikan bukti bahwa telah terjadi transaksi, tetapi juga merekam tranksaksi pesan kedalam audit log yang telah ditandatangani pula. Sekali audit log telah ditandatangani, ia tidak dapat dimodifikasi (oleh Hacker) tanpa merubah tandatangan secara signifikan.

ANCAMAN/SERANGAN KEAMANAN PADA WEB SERVICE
Salah satu kunci kesederhanaan Web Service adalah bahwa Web Service diimpelementasikan pada port 80 dan 443, sama seperti standard aplikasi berbasis Web lainnya. Keuntungannya adalah dapat menyerdehanakan komunikasi antara beberapa entitas, tetapi disisi lain memiliki kelemahan dengan membuka peluang munculnya gangguan keamananan yang kurang dimengerti sebelumnya. Untuk mengatasinya, biasanya digunakan Firewall yang dapat melakukan tugas seperti port monitoring dan mengenali adanya serangan yang bersifat brute force, akan tetapi Firewall tidak dapat melakukan tugas untuk melihat isi pesan sebagai upaya untuk Mendeteksi 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 pada gambar berikut ini.
Firewall dapat mengenali pesan SOAP, tetapi menganggapnya hanya sebagai trafik normal biasa seperti trafik HTTP pada umumnya. Walaupun demikian Firewall juga dapat diatur (configure) untuk menolak atau mengijinkan trafik SOAP. SOAP interface merupakan perangkat lunak yang memiliki format Application Program Interface (API) dan dapat menjalankan berbagai macam fungsi. Misalnya, suatu aplikasi Web Service dapat terdiri dari ratusan atau ribuan operasi yang dapat dilakukan, semuanya melalui port 80. Semetara itu dokumen WSDL dan isi UDDI menyediakan informasi rinci yang memberi peluang untuk Hacker untuk melihat isinya karena karakteristik XML yang bersifat (self-describing) dan secara jelas menunjukkan elemen data. Beberapa jenis serangan yang mungkin terjadi terhadap aplikasi berbasis Web juga bisa terjadi pada aplikasi Web Service, yaitu antara lain adalah Denial of Service (DOS), Buffer Overflow, Reply Attack, dan DictionaryAttack.

Denial Of Service
Contoh serangan yang bersifat denial of service (DOS) ini misalnya pada kasus dimana suatu applikasi Web Service hanya mampu menerima transaksi persetujuan pinjaman uang sebanyak 5 permintaan sehari, tetapi suatu serangan DOS dapat terjadi jika ada 10 permintaan penjaman per jam yang dikirim untuk diproses oleh sistem. Serangan DOS biasanya akan menyebabkan kelumpuhan sistem karena kekurangan sumber daya untuk melayani request yang masuk akibat DOS, yang dapat berakibat berhentinya operasi sistem.

Buffer Overflow
Serangan buffer overflow pada Web Service terjadi jika ada parameter data yang dikirim lebih panjang dari pada yang bisa ditangani oleh sistem yang menyebabkan sistem mengalami crash, atau sistem menjalankan kode yang tidak dikehendaki (undesired code) yang dikirim oleh penyerang. Metode untuk melakukan ini biasanya dilakukan dengan cara mengirimkan password dengan jumlah karakter lebih panjang dari yang diharapkan. Serangan yang sama dengan buffer overflow adalah dikenal sebagai format string attack, yang berupa pengiriman string atau karakter yang tidak memiliki fungsi seperti tanda petik, tanda kurung, atau wildcard.

Reply Attack
Reply attck dilakukan dengan menyalin pesan yang valid kemudian mengirimkan ke Web Service server secara berulang-ulang, seperti halnya DOS. Untuk menangani serangan ini dapat menggunakan metode yang sama dalam menghadapi DOS. Dalam beberapa kasus, Reply attack lebih mudah diteksi oleh Web Service karena payload pesan dapat dengan mudah dibaca. Dengan bantuan tool yang tepat, pola serangan Reply attack dapat diteksi secara mudah walaupun jira serangan dikirimkan melalui berbagai medium seperti HTTP, HTTPS, SMTP, atau melalui berbagai interface yang berbeda.

Dictionary Attack
Dictionary attack terjadi jika seorang hacker menyerang dengan cara mencoba memasukkan user ID dan Password untuk masuk ke sistem atau berbagai system secara manual atau otomatis (programmatically). Oleh karena itu seorang Administrator harus dapat meyakinkan bahwa password tidak mudah ditebak dan selalu diperbaruhui/dirubah secara periodik.

ARSITEKTUR WEB SECURITY
Web Service dapat diakses dengan mengirimkan pesan SOAP ke service endpoint yang diidentifikasikan dengan URI (Unified Reaources Identifier), untuk meminta aktivitas tertentu pada Web Service, dan kemudian menerima respon pesan SOAP (termasuk adanya indikasi adanya kesalahan, jika ada). Dalam konteks ini, tujuan pengamanan Web Service dibagi dalam beberap sub-goal yang menyediakan fasilitas untuk mengamankan integritas dan confidentiality pesan dan menjamin service hanya akan melakukan perkerjaannya sesuai dengan isi pesan yang merupakan ekspresi dari Claim yang dibutuhkan oleh suatu Policy.

Fungsi pengamanan terhadap integritas dan confidentialitity pesan dapat diterapkan menggunakan teknologi SSL/TSL maupun IPSec. Namun demikian SSL/TSL maupun IPSec hanya menyediakan konteks keamanan yang bersifat point-to-point. Model arsitektur Web Service yang komprehensif membutuhkan mekanisme keamanan dengan konteks end-to-end. Model ini menghendaki adanya pengamanan pada layer transport maupun aplikasi. IBM dan Microsoft mengusulkan suatu model arsitektur keamanan Web Service untuk memenuhi kebutuhan tersebut diatas dengan suatu karakteristik sebagai berikut :
• Web Service menghendaki bahwa setiap pesan yang masuk dapat menunjukkan dirinya sebagai sekumpulan claim (misalnya: nama, key, permission, kapabilitas, dls). Jika suatu pesan datang tanpa memiliki claim yang dibutuhkan, maka Web Service dapat menolak atau menerima pesan tersebut. Sekumpulan claim dan informasi yang berkaitan dengannya disebut sebagai Policy.
• Suatu requester dapat mengirim pesan dengan menunjukkan bukti mengenai claim yang dibutuhkan Web Service dengan menyertakan Security token bersama dengan pesan tersebut. Jadi, pesan meminta tindakan tertentu kepada service dan membuktikan bahwa pengirim pesan memiliki claim yang meminta tindakan tersebut.
• Jika requester tidak memiliki claim yang dikehendaki,requester atau seseorang yang mengatasnamakannya dapat mencoba memperoleh claim yang diperlukan dengan mengkontak Web Service lain. Web Service ini, yang disebut sebagai Security Token Service, dapat menghendaki sekumpulan claim. Security token service bertindak sebagai perantara trust antara berbagai trust domain yang berbeda dengan menyertakan Security token.
Model tersebut diilustrasikan pada gambar dibawah ini, dimana setiap Requester dapat menjadi Security Token Service , dan Security Token Service dapat menjadi Web Service, yang mengekspresikan Policy dan menghendaki Security token. Model generik messaging tersebut, yaitu claim, policy dan security token, mendukung beberapa model yang lebih spesifik lainnya seperti halnya identitybased security, access-control list, dan capabilities-based security. Model ini juga mendukung teknologi yang ada saat ini seperti X.509 dan Karbero.

SPESIFIKASI KEAMANAN WEB SERVICE
Spesifikasi Keamanan Web Service terdiri dari sekumpulan spesifikasi terpisah yang dikembangkan secara hirarkis dan berlapis diatas protokol SOAP. Masingmasing spesifikasi dikembangkan berdasarkan spesifikasi yang lain. Spesifikasi awal keamanan Web Service terdiri dari :
• Message Security Model
• Web Service Endpoint Policy
• Trust Model
• Privacy Model

IBM dan Microsoft memberi nama masing-masing spesifikasi tersebut adalah WS-Security (untuk message security model), WS-Policy (untuk Web Service endpoint policy), WS-Trust (untuk Trust model) dan WS-Privacy (untuk Privacy model). Secara bersama spefikasi awal tersebut menyediakan landasan untuk menetapkan keamanan yang interoperable antar trust domain.

Berdasarkan spesifikasi awal tersebut, kemudian dapat dikembangkan spesifikasi berikutnya yaitu secure conversation (WS-SecureConversation), federated trust (WS-Federation), dan otorisasi (WS-Authorization). Kombinasi spesifikasi keamanan tersebut memungkinkan adanya banyak skenario yang akan sulit diimplementasikan jika menggunakan mekanisme keamanan dasar yang ada saat ini. Secara ringkas, spesifikasi keamanan dapat dijelaskan sebagai berikut :
Spesifikasi Awal
• WS-Security : Menjelaskan bagaimana menerapkan XML signature dan XML Encryption pada Header pesan SOAP, serta bagaimana menyertakan security token, termasuk X.509, Karbero dan User Name/Password kedalam pesan SOAP.
• WS-Policy : menjelaskan kemampuan dan kendala dari security polici pada level intermediate maupun end-point.
• WS-Trust : menjelaskan bagaimana framework trustu relationship antar entitas bisnis
• WS-Privacy : menjelaskan suatu model bagaimana Web Service dan requester menyatakan privasi subyek yang diinginkan dan privasi organisasi.
Spesifikasi berikutnya
• WS-SecureConversation : menjelaskan bagaimana mengelola dan memelakukan otentikasi pertukaran pesan
• WS-Federation : menjelaskan bagaimana mengintegrasikan berbagai mekanisme manajemen identitas
• WS-Authorization : menjelaskan bagaimana data otorisasi dan authorization policy.

STANDARD KEAMANAAN WEB
Kerentanan yang ada pada Web Service yang berbasis XML menjadi pertimbangan utama yang mempengaruhui keragu-raguan para pengguna untuk mengimplementasikan Web Service. Oleh Karena itu diperlukan standard teknologi keamananan Web Service untuk mendukung keamanan penerapan Web Service secara luas. Walaupun demikian, standard yang ada saat ini seperti LDAP, PKI, SSL/TSL tetap memegang peranan penting untuk mengamankan Web Service dalam konteks point-to-point.
Pada saat ini ada 2 lembaga yang menjadi referensi dalam penetapan standard keamanan XML Web Service yaitu W3C dan OASIS. Tabel berikut ini menunjukkan beberapa standard keamanan XML Web Service yang telah dan sedang ditetapkan oleh kedua organisasi tersebut di bawah ini :

Standard Standard Body Status Deskripsi
XML Digital Signature
(XDSIG) W3C Completed Protokol untuk menandai isi dokumen digital.
Memberikan aspek integritas data, dan non-repudiation
XML Encryption
(XENC) W3C Completed Protokol untuk mengengkripsi dan dekripsi isi
dokumen digital.
XML Key Management
Specification
(XKMS) W3C Working
Draft Protokol untuk mendistribusikan dan me-registrasi public key
Security Assertion Markup
Language
(SAML) OASIS Open
Standard Menyediakan kerangka XML untuk Web Service yang mendukung pertukaran otentikasi dan otorisasi informasi antara partner bisnis
Extensible Access Control
Markup Language
(XACML) OASIS Open
Standard Spesifikasi XML untuk mengekspresikan Policy
tentang akses informasi melalui Internet.
WS-Security OASIS Working
Draft Sekumpulan standard untuk mengamankan pesan SOAP pada aspek integrity dan onfidential- lity
Standard WS-Security yang menjadi referensi penting bagi penerapan XML Web Service, dengan pertimbangan sebagai berikut :
• WS-Security akan menjadi referensi standard keamanan Web Service oleh berbagai pihak (user, vendor, organisasi lainnya).
• WS-Security tidak menspesifikasikan standard keamanan tertentu yang berbeda, 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.
• WS-Security merupakan implementasi dari model arsitektur keamanan Web Service
SKENARIO PENGGUNAAN WEB SERVICES SECURITY
Mekanisme WS-Security dapat diterapkan untuk mengatasi berbagai isu keamanan. Berikut ini adalah beberapa contoh skenario untuk
mendukung implementasi WS-Security berdasarkan usulan oleh IBM dan Microsoft dalam dokumen ‘WS-Security AppNotes’ (15 Agustus 2002), yaitu :
a. Direct Trust using User Name/Password
Server dimana Web Service berada menggunakan pasangan public key untuk menjamin keamanan kanal antara server dan client melalui koneksi HTTP dengan menggunakan SSL/TSL. Requester membuka koneksi ke Web Service dengan menggunakan transport-level security (SSL/TSL), dimana Requester mengirimkan pesan permintaan dengan menyertakan security token yang berisi user name dan password. Sementara Web Service meng-otentikasi informasi yang terdapat dalam pesan, memproses request dan merespon hasilnya. Dalam skenario ini integritas dan kerahasiaan pesan ditangani dengan menggunakan mekanisme keamanan berbasis transport-layer.
b. Direct Trust using Security Token
Skenario ini mengilustrasikan penggunaan security token yang secara langsung dipercaya valid (trusted) oleh Web Service. Dalam hal ini, direct trust berarti bahwa security token dikenal dan diverifikasi oleh Web Service. Skenario ini menganggap bahwa Requester dan Web Service telah menggunakan beberapa mekanisme untuk menetapkan 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 menyertakan security token, dan memberikan proof-of-possession (public/private key) terhadap security token menggunakan digital signature. Service melakukan verifikasi terhadap public/private key dan mengevaluasi security token, memproses permintaan dan mengembalikan hasil pemrosesannya.
c. Security Token Acquisition
Dalam skenario ini, security token tidak terdapat dalam pesan SOAP, melainkan menggunakan mekanisme security token reference untuk mencari dan mengambil token. Requester mengirim pesan ke service dengan menyebutkan referensi terhadap keberadaan security token, dan menyediakan proof-of-possession dalam bentuk XML Signature. Web Service menggunakan informasi yang ada pada security token reference untuk memperoleh security token dari security token service dan memvalidasi private/public key (proof). Web Service menerima (trusted) security token, sehingga request diproses dan dikembalikan hasilnya ke requester.
d. Firewall Processing
Firewall melakukan evaluasi terhadap pesan SOAP yang datang, dan hanya mengijinkan pesan yang berasal dari requester yang telah diotorisasi untuk melewati Firewall. Dalam skenario ini, Firewall membuat keputusan dengan mengevaluasi security token yang digunakan untuk menandatangani pesan. Dalam skenario yang lain, Firewall dapat juga bertindak sebagai security token yang meminta otoritas dan hanya mengijinkan pesan yang memiliki proof-ofpossession (private/public key) terhadap security token yang diminta oleh Firewall.
e. Issued Security Token
Skenario ini hampir sama dengan Security Token Acquisition, kecuali bahwa security token dikirim ke Requester dari Security Token Service , kemudian pesan permintaan dikirim ke Web Service dengan menyertakan security token tersebut menggunakan elemen . Security token dapat berupa X.509 atau Karberos. Sekali security token dikirim oleh Secuirty token service, security token tersebut dapat digunakan beberapa kali oleh, misalnya untuk Web Service yang berbeda jika token yang dikirim mengijinkan hal tersebut.