İstemci Aracılığı ile Veri Gönderme
Web uygulamaları sunucu tarafında kullanıcının tüm oturum bilgilerini tutmayıp bir kısmını istemciye geri göndererek bir sonraki aşamada istemci tarafından gönderilmesi yoluyla performanslarını artırmayı hedeflerler. Veya bazı durumlarda normalde istemci tarafından değiştirilmeyeceğine inandıkları bilgilere (Referer başlığı değeri gibi) dayanarak belli kontroller yaparlar. Ancak normalde değiştirilmeyeceği beklenen bu veriler teknik olarak değiştirilebilir ve bir saldırgan tarafından saldırı aracı olarak kullanılabilir.
Saklı Form Alanları (Hidden Form Fields)
Bir form alanı “hidden” olarak işaretlenmişse tarayıcı tarafından kullanıcıya görüntülenmez. Bu nedenle kullanıcı tarafından değiştirilmeyeceği varsayılır ve uygulama tarafından çeşitli amaçlarla kullanılır (oturum takibi, ürün fiyatı, vs.).
Ancak bu alanın değeri de bir POST isteğinin gövdesinde diğer alanlar gibi görünebilir ve bir saldırı proxy’si (ya da intercepting proxy) ile değiştirilebilir. Bu proxy’ler pek çok özelliklerinin yanı sıra isteğin “Content-Length” başlığının değerini de yapılan değişikliğe göre düzeltecek yeteneğe sahiptir. Daha ilkel bir metod da söz konusu HTML sayfasının lokal olarak saklanması ve form sahasının “hidden” özelliğinin kaldırılması sonrasında sahaya istediğimiz değeri yazarak formu göndermektir.
HTTP Cookie’leri
Cookie’ler genellikle oturum yönetimi için kullanılmakla birlikte bazı bilgilerin istemci tarafından gönderilmesi için de kullanılmaktadır. Cookie içerikleri kriptolanmamışsa proxy ile değerleri değiştirilerek uygulama manipüle edilebilir.
URL Parametreleri
Uygulamalar çoğunlukla parametreleri önceden belirlenmiş linkler kullanırlar. Örneğin bir ürün kataloğunda ürünün altındaki link ilgili ürünün görüntülenmesi talebi anlamına gelen bir query string ile oluşturulmuş olabilir. Açıktır ki bu URL’lerin içindeki parametreler tarayıcı üzerinde veya yine proxy ile değiştirilebilir. URL’lerin değiştirilemeyeceği varsayılan başka durumlarda vardır, örneğin:
- Sayfa içinde yüklenen resimlerin URL’leri
- Frame içeriğini yükleyen URL’ler
- POST metodu kullanan bir formun URL’i içinde yer alan önceden belirlenmiş parametreler
- Tarayıcı location bar’ının pop-up penceresi ve diğer tekniklerle gizlenmesi
Yukarıdaki durumlarda URL içinde parametreler bulunması durumunda uygulama geliştiriciler bu parametrelerin değiştirilemeyeceğini varsayabilir, ancak bu değerler diğer bilgilerde olduğu gibi istemci tarafından değiştirilebilir.
Referer Başlığı
Referer başlığı w3.org standartlarına göre opsiyonel olmakla birlikte çoğu tarayıcı tarafından doldurulur ve isteğin geldiği sayfanın URL’ini içerir. Örneğin bir sayfanın içindeki hyperlink’e tıklanması, bir form gönderilmesi (submit edilmesi) veya bir sayfanın içinde resim dosyalarına referans vermesi gibi durumlarda Referer başlığı orjinal sayfanın URL’ini içerir.
Referer başlığı uygulama geliştiriciler tarafından değiştirilmeyeceği varsayımı ile kullanıcının belli bir sayfadan gelmesinin o sayfanın erişim kontrolünden geçtiği, dolayısıyla bu aşamaya da gelebilmesi gerektiği sonucuna ulaşmasına neden olur. Ancak bu sahanın da değeri istemci tarafından değiştirilebilir. HTTP başlıklarının da mesaj içeriği gibi değiştirilmeyeceklerine dair bir güvence bulunmamaktadır.
Opaq Veri
Bazen istemci tarafından gönderilen veri kriptolu veya encoded olabilir. Bu durumda bu sahanın manipüle edilmesi için kodlama veya kriptolama yönteminin anlaşılması gerekir. Bir başka yol da uygulamanın başka bir alanında aynı algoritma kullanılıyor ve bilinen bir metin bu algoritmadan geçirilebiliyorsa sonucunu kullanmak suretiyle parametrenin değiştirilmesi olabilir. Eğer parametrenin kullanım alanını biliyorsak, bu alanda daha önce üretilen bir değeri daha sonra kullanabiliriz. Örneğin gizlenmiş parametrenin fiyat parametresi olarak kullanıldığı durumda daha düşük ücretli bir ürün alındığında bu sahadaki değeri saklayıp daha yüksek ücretli bir ürün içinde kullanabiliriz.
ASP.NET ViewState
ASP.NET uygulamalarında öntanımlı olarak görülen VIEWSTATE saklı alanı normalde web sunucu tarafından kullanıcının durum bilgisinin “serialize” edilmiş (yani byte array’e çevrilmiş) halini Base64 kodlu olarak tutar. Ancak uygulama geliştiricilerinde bu sahaya aşağıdaki biçimde parametre eklemesi mümkündür:
string price = getPrice(prodno);
ViewState.Add(“price”, price);
Bu alan Base64 kodlanmış olduğundan rahatlıkla decode edilebilir. Decode edilmiş bilgi içinde metin bazlı veri değiştirilerek tekrar Base64 encode edilip istek gönderilebilir (ViewState versiyon 2’de string parametrelerin önünde bir de uzunluk bilgisi tutulur. Bu alanın da değişikliğe uygun biçimde düzeltilmesi gerekir Hex editörde). Ancak genellikle ASP.NET platformlarında ViewState alanı aşağıdaki konfigürasyonla sonuna anahtarlı bir hash eklenerek oluşturulur:
EnableViewStateMac=”true”
Eğer bu özellik aktifse hash üretilirken kullanılan anahtar sunucu üzerinde olduğundan alan içeriğini değiştirdiğimizde doğru hash değerini hesaplayamayız ve sunucu hata mesajı döner. Ancak yine de ViewState alanının içinde hassas veriler bulunuyorsa bunları izlemek mümkün olacaktır. Burp Proxy ViewState alanını decode ederek görüntüleyebilir.
Keyed Hash özelliği sayfa bazlı olarak aktif veya pasif hale getirilebilir, o nedenle her önemli sayfayı ViewState kaynaklı açıklıklara karşı incelemekte fayda vardır.
HTML Formlarla Alınmış Verileri Gönderme
Web uygulamaları girdi kontrollerini yapmak için istemci tarafında sağlanan kontrol fonksiyonalitesini kullanabilirler. Ancak istemci tarafından uygulanan her kontrol gibi bunlarda aşılabilir.
Uzunluk Limitleri
HTML formlarında tanımlı sahalarda aşağıdaki örnekte olduğu gibi “maxlength” özelliği (attribute) ile sahaya girilebilecek maksimum karakter sayısı kontrol edilebilmektedir.
<p>Quantity: <input size=”2” maxlength=”3” name=”quantity”>
Tarayıcı bu alan için 3 karakterden fazla veri girmeye izin vermeyecektir. Ancak bir proxy aracılığı ile hem orjinal isteğe gelen yanıt içindeki form bilgilerini daha tarayıcıya ulaşmadan değiştirerek, hem de sınırlı alana girilen veriyi gönderme sırasında değiştirerek bu kontrolü aşmak mümkündür.
Eğer daha sonraki aşamalarda bu sahadan kaynaklanan bir XSS veya SQL injection gibi bir açıklık varsa bu şekilde uzunluk kısıtı aşılıp exploit edilebilir, veya hafıza taşma açıklığı kullanılabilir.
Betik Tabanlı Kontroller
HTML saha özellikleri ile yapılabilecek kontroller çok sınırlı olduğundan form’ların “onsubmit” olaylarında bir betik fonksiyonu tanımlanarak daha karmaşık kontroller yaptırılabilir (örneğin belli bir sahaya sadece numerik bilgi girilmesi, negatif rakam bulunmaması, vb. gibi).
<script>
Function ValidateForm(theForm)
{
....
}
</script>
<form action=”order.asp” method=”post” onsubmit=”return ValidateForm(this)”>
.... </form>
Bu tür kontroller tarayıcıdaki JavaScript desteğinin kaldırılması, uygulama doğru çalışmak için JavaScript’e ihtiyaç duyuyorsa orjinal yanıt gelirken form’un onsubmit özelliğinin değiştirilmesi veya istek giderken ilgili değerin değiştirilmesi gibi yöntemlerle aşılabilir.
Disabled Elements
Form alanları aşağıdaki gibi “disabled” özelliklerine “true” değeri atanarak ekranda gri ve yazılamaz biçimde görüntülenebilir:
<p>Product: <input disabled=”true” name=”product” value=”laptop”></p>
Bu tür sahalar form submit edildiğinde gönderilmez, ancak biz gönderecek biçimde istekte değişiklik yaparsak uygulama bu alandaki bilgiyi dikkate alabilir. Bu şekilde uygulama mantığı etkilenebileceği gibi diğer açıklıklarda tespit edilebilir.
Thick-Client Bileşenleri
Kullanıcı bilgisi toplamanın (kullanıcı tarafından girilen veya kullanıcı platformundan alınan bilgileri) önde gelen yöntemlerinden biri de thick client bileşenler kullanmaktır. Bu amaçla kullanılan bileşenler den sıklıkla karşılaşılanlar Java Applet’ler, ActiveX kontrolleri ve Shockwave Flash nesneleridir.
Bu bileşenler HTML formları ve JavaScript kodlarına göre kullanıcılar açısından daha kapalı olduğundan uygulama geliştiriciler bu bileşenlerle yapılan girdi kontrollerinin daha güçlü olduğu yanılgısına daha kolay düşerler.
İstemci tarafındaki kontrol mekanizmaları ne olursa olsun eğer mesajlar açık biçimde gönderiliyorsa bir proxy ile kesilebilir ve değiştirilebilirler.
Thick client bileşenler verileri obfuscate ederek gönderiyorsa etkili olabilir, bu durumda verilerde proxy ile yapılacak bir değişiklik uygulamanın hata almasına neden olacaktır. O yüzden thick client’ın veriyi nasıl dönüştürdüğünü anlamak gerekir. Bunun için izlenebilecek ilk yöntem belli sayıda istek göndererek dönüşmüş verileri incelemek ve dönüştürme mekanizmasını anlamaya çalışmaktır. Ancak bu metod çoğu zaman işe yaramayacaktır.
Java Applet’leri
Eğer girdi kontrolleri ve çıktı başkalaştırma (obfuscation) bir java class’ı ile gerçekleştiriliyorsa şunlar yapılabilir:
- Class’ın public metodları arasında başkalaştırma metodu varsa doğrudan bu metodu çağırarak istediğimiz veriyi başkalaştırır ve web sunucusuna bu şekilde gönderebiliriz.
- Eğer bu imkan yoksa Java byte kodu decompile edilip girdi kontrolleri budanıp tekrar derlendikten sonra lokal’le saklanan HTML sayfasından çağrılabilir. Decompile etmek için “jad” kullanılabilir.
Java kodu decompile edilme ihtimaline karşı obfuscate edilmiş, class, metod ve değişken isimleri anlamsız değerlerle değiştirilmiş, gereksiz kod path’leri eklenmiş, vb. olabilir. Bu tür işlemleri yapan araçlardan biri “Jode” (decompiler ve bytecode obfuscator)’dur. Obfuscate edilmiş kodları tekrar bir obfuscator’dan geçirmenin yararı olabilir, gereksiz kod alanları budanarak daha anlaşılır bir hale gelebilir.
ActiveX Kontrolleri
ActiveX kontrolleri makine koduna derlenmiş ve Java Applet’ler gibi bir sandbox içine hapsedilmemiş, bilgisayarın tüm kaynaklarına erişebilen thick client uygulamalardır. HTML kodu içinde Java Applet’lere benzer şekilde tanımlanır ve kullanılır. ActiveX kodunun kullanıldığını HTML koduna bakarak anlamak mümkün olduğu gibi web sunucu tarafından yeni yüklenmek istenen kontroller olduğunda tarayıcınız sizi uyarır.
ActiveX kodları makine koduna derlendiğinden decompile edilip manipüle edilmeleri Applet’ler kadar kolay değildir. Bununla birlikte makine kodu da disassembly ve debug edilebilir. Bu nedenle assembly seviyesinde kod incelenebilir, debug sırasında register’lar veya data alanı değiştirilerek yapılan girdi kontrolleri geçersiz hale getirilebilir. Makine kodu içinde cracker’ların yaptığı gibi bazı kontrol noktaları farklı opcode’larla değiştirilerek programın akışı değiştirilebilir.
Bunların yanı sıra kolay yol olarak Applet’lerde olduğu gibi public metodlar verilen girdiyi alıp obfuscated veri üretme fonksiyonu açısından araştırılmalıdır. Export edilen fonksiyonları incelemek için kullanılabilecek araçlardan biri COMRaider’dır.
ActiveX kontrolü bilgisayar üzerinde bir takım kontroller yapıyorsa bunlar tipik dinamik kod incelemesinde olduğu gibi ulaştığı dosyalar ve registry key’leri FileMon ve RegMon gibi araçlarla izlenerek kontrole istediği bilgilerin verilmesi sağlanabilir.
Zaman zaman C# ile yazılmış thick client’lara da rastlanabilir. Bu durumda nesne Java Applet’lerde olduğu gibi kaynak koduna decompile edilebilir. Bunun için kullanılabilecek araçlardan biri “.NET Reflector”dır.
Shockwave Flash Nesneleri
Flash nesneleri de Applet’ler gibi genellikle bir tarayıcı plug-in’i olan bir sanal makine üzerinde çalışır. Diğer thick client’larda olduğu gibi shockwave flash nesneleri de girdi kontrolleri yaptığı veriyi obfuscate ediyorsa nesnenin nasıl çalıştığı anlaşılabilir ve işleyişi değiştirilebilir. Bu 2 şekilde yapılabilir:
- Flash nesnesi bytecode’a disassemble edilir, değişiklik yapıldıktan sonra tekrar assemble edilir (örneğin Flasm aracı ile).
- Eğer kod karmaşık ise flash nesneleri de kaynak kodlarına (ActionScript kaynak koduna) decompile edilebilir (örneğin Flare aracı ile).
<<Önceki Bölüm Sonraki Bölüm>>
