![]() |
|
|||||||
| Security Bu bölümde güvenlik ve güvenlik açıkları, Korunma Yolları ile ilgili herşey yayınlanır. |
![]() |
|
|
Seçenekler |
|
|
#1 |
|
Normal Üye
![]() |
Evet uzun zamandır yazmayı düşündüğüm bu dökümanımı bugüne kadar elde ettiğim tecrübelerden birebir aktarıyorum.Şuan için web tabanlı uygulamalar ilgili benim kullandığım yöntemleri yazıyorum.
Uygulama hatalarını bulmanın en kolay yolları; Mevcut sayfalarla oynamak, Uygulamaya ait formlarla oynamak, Headerlarla oynamak, Çerezlerle oynamak, Uygulamanın kaynak kodlarından yararlanma: (Genel içerik: çapraz site betiklenmesi (XSS) ve SQL enjeksiyonu) En basit ve en yararlı olan yöntemdir. Basit dediğime bakmayın oldukça uğraştırır aslında.Nedenine gelince bazen bu sistemlerin hangi uygulamaları kullandığını bulmak oldukça zordur ve eğer public bir uygulama değilse örneğin (PHPNuke,PostNuke gibi) bu yöntemi denemenizi tavsiye etmem. Kaynak kodunu ele geçirdiğiniz uygulamayı önce yerel bir sunucudaki kendi sisteminize bu uygulamayı destekleyen bir sunucu kurmalısınız (PHP tabanlı uygulamalar için: PHPTriad,ApacheTriad gibi sunucu paketleri sizin için idealdir, ASP ve FrontPage tabanlı sistemler için PWS sizler için idealdir ve PWS Windows ile gelir) bu sunucuyu kurdukdan sonra uygulamayı sunucunuz üzerinde çalıştırın. Sonra birebir bütün heryerini önce kurcalayın ve bir hata ile karşılaştığınızdaki bu uygulamada var olan açığın ilk adımını bulmuşsunuz demekdir ki, Bu hata mesajı bazen debug output olarak karşınıza çıkarsa ve alttaki örnek gibiyse Kod:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'or' at line 1 Bazen hata mesajı almasanızda bir tuhaflık gözünüze çarpar örneğin uygulamamıza yerel sunucumuzdan şöyle eriştiğimizi varsayalım; Kod:
http://localhost/research/xxxforum/read.php?id=2 or read.php dosyasını bir metin düzenleyicisi yardımıyla örnek: notepad açın,sonra tek tek bütün kodları inceleyin özellikle read.php'nin sunucudan "GET" yöntemi ile gelen sorgulara hangi fonksiyon ile nasıl yanıt verdiğine bakmalısınız.Eğer fonksiyonda bir terslik gözünüze çarpar ise örnek bir hatalı fonksiyon yazalım. Kod:
function readip() {
@mysql_connect($uo_sqlhost, $uo_sqluser, $uo_sqlpass) or die("Cannot connect to SQL server");
@mysql_select_db($uo_sqlbase) or die("Cannot select database");
$uo_ip = $_GET['SIP'];
$uo_query = "SELECT lastvisit FROM users_online WHERE visitor = $uo_ip";
$uo_result = mysql_query($uo_query);
echo $uo_result;
}
Kod:
$uo_query = "SELECT lastvisit FROM users_online WHERE visitor = $uo_ip"; Hatta uzaktan kod çalıştırma dahi yapabiliriz. Uygulamaları yazan kişiler genelde print (yazdırma) ve view (görüntüleme) sistemlerine ne yazikki dizayndan başka bir önem vermezler ve genelde bütün açıklar bu sayfalarda çıkar. Eğer uygulamanın kaynak kodlarına erişemezseniz, mevcut uygulamaya ulaştığınız web sunucusundan en yukarda bahsettiğim metodları kullanarak az kafasını kurcalamaya çalışarak bir çok açık bulabilirsiniz. Genelde büyük ve özel sunuculardaki açıklar böyle bulunmuştur. Bir çok büyük firmanın sistemine girdiğimde (BigFoot,ICQmail,NetZero,Superonline) bu tarz açıklar bulmuştum. Çerezlerle oynamak: Çerezler aslında HTTP requestte Cookie: headerıyla sunucuya yolladığımız ve sistemin bizi kolayca hatırlamasını sağlayan değerler.Bu değerlerle ufak oynamalar yaparak kendimizi sistem adminiymiş gibi gösterebiliriz bu metodu artık çoğunuz biliyorsunuz.Fazla anlatmaya gerek yok=) Referans değişimi (referer spoofing): Aslında buda headerlar ile oynamak kapsamına girer ancak dikkatsiz programcılar halen bu eski sistemi kullanmaktalar.Bir çoğunuz bu yöntemi ***** sitelere girerken çok kullanıyorsunuz. Burdaki mantık sokete HTTP requesti yollarken sitemizi abudik.com varsayarsak Kod:
GET admin.asp HTTP/1.1 Referer: http://www.abudik.com/login.asp Satır atlattırma CRLF enjeksiyonu Buda headerlarla oynamakdan geçer. Basit bir şekilde sokette headera \n\n karakterleri yazdırılır ve eğer sistem bu ufak oyunumuzu yutar ise istediğimiz headerı yazabilir, SQL enjeksiyondan , uzaktan kod çalıştırılmasına kadar bir çok şeyi yapabiliriz. Bu yöntemlerin hepsi zamanla deneyerek öğrenilecek ve bir süre sonra alışkanlık yapacak yöntemler kendi metodlarınızı kullanarak bu yöntemleri geliştirebilirsiniz. Paylaşımın KaLite İLe Buluştuqu Tek Yere HoşqeLdiniz.. Seni yağmalamışlar kuytularda korkuların nefes nefese
Yüreğinden bıçaklanan sevdalarda Pişman mısın kendine düşman mısın? Hep yanlış sevdalara çiçeklenmiş kuruyup savrulmuşsun Hasretin çıldırıyor anılara gecelere sığmıyorsun Şu soğuk duvarların dili olsa anlatsa neler çektiğini Buz gibi yastıklara sarılıp da sabahı zor ettiğini Ağlıyorsun... Ağlıyor ağlıyorsun Artık gülüp geçiyorsun aşklara inanmıyorsun Yorgunsun biliyorum oysa birtek sözcük yeterdi anlatmaya Saçların o elleri özlüyor Çığlar yuvarlanıyor ömrünün uçurumlarında O en saklı yerinde ağlayan kahkahalar hangi yasak umudun ihanetidir Birer birer kopartmışlar büyüttüğün çiçekleri Anlıyor musun? Yaprak döken gençliğinin satır aralarında Altı kırmızıyla çizilmiş ve tırnak içine alınmış suskunluğun başharflerisin Şehirler uyurken boğazına sarılırken öfkeler Bu gizli gülmelerin bu sessiz ağlamaların nedir anlamı Sen hangi mevsimin yağmurusun Ağlıyor musun? |
|
|
|
|
|
#2 |
|
Amatör Üye
Üyelik Tarihi: Jan 2007
Yaş: 75
Mesajlar: 15
Üye No: 3302
Tecrübe Puanı: 35
Rep Gücü : 69
Rep Derecesi :
![]() |
Web sitenizi ve uygulamalarınızı SQL Enjeksiyon saldırılarından korumak 3 bölümlük bir işlemden oluşur:
Sitenizin, SQL Enjeksiyon ve diğer açıklara karşı tam bir güvenlik denetiminin yapılması ile güvenliğinizin mevcut halinin analiz edilmesi. Web uygulamalarının ve BT altyapısının diğer tüm bileşenlerinin steril olması için en uygun kodlama standartlarının / tekniklerinin kullanılması. Web bileşenlerindeki her değişiklik veya eklemeden sonra düzenli web güvenlik denetimi uygulanması. Ek olarak, SQL Enjeksiyon ve diğer tüm hack tekniklerinin kontrolünde aklınızda olması gereken ana ilke şudur: "Web sitesinde güvenli olduğunu düşündüğümüz hangi bölümler hack saldırılarına açık?" ve "Bir uygulamaya hangi veriyi göndererek normalde yapmaması gereken bir şeyi yaptırabiliriz?". SQL Enjeksiyon açıklarının kontrolü web sitesinin ve web uygulamalarının denetimi ile olur. Manuel açık denetimi karmaşık olabilir ve çok zamanınızı alabilir. Ayrıca yüksek-seviye uzmanlık ve büyük miktarda kodun takip edilmesini ve bilgisayar korsanlarının en son taktiklerinin bilinmesini gerektirir. Web uygulamalarını denetlemenin en iyi yolu otomatik ve keşifsel (heuristic) web güvenlik tarayıcısı kullanmaktır. Otomatik web güvenlik tarayıcısı tüm web sitenizi gezer ve SQL enjeksiyon açıklarını test eder. Hangi URL/betiklerin SQL enjeksiyondan etkilendiğini belirtir. Bu sayede hızlı bir şekilde kodu düzeltebilirsiniz. Bir web uygulama tarayıcısı SQL Enjeksiyon açıklarının yanında Çapraz site betik çalıştırma (XSS) ve diğer web güvenlik açıklarını da test eder. SQL Enjeksiyon için İmza-eşleştirme’ye karşı keşifsel tarama Pek çok firma otomatik ve periyodik web denetimi ihtiyacını anlamış olsa da pek azı hem hazır gelen hem de özel hazırlanan web uygulamalarını taramanın gerekliliğine inanır. Genel yanlış düşüncelerden biri özel yazılmış web uygulamalarının hack saldırılarından etkilenmeyeceğidir. Bu daha çok "asla benim başıma gelmez" olgusundan ve web sitesi sahiplerinin uygulama geliştiricilerine olan güveninden kaynaklanır. Bu doküman yazıldığı sırada Google News’te "SQL Injection" kelimeleri için yaptığımız arama 240 sonuç buldu. Secunia ve SecuObs bilinen web uygulamaları için günlük olarak düzinelerce güvenlik açığı rapor etmekte. Ve özel hazırlanmış uygulamaların hack edilmesi ile ilgili örnekler medyada fazla yer almıyor. Bunun sebebi sadece bilinen meşhur firmalar (ör. Choicepoint, AT&T, PayPal) geçtiğimiz bir kaç ay içinde manşet oldular. Özel yazılmış web uygulamalarının belki de en çok açık içerenler olduğunu anlamak son derece önemlidir. Ve daha çok sayıda bilgisayar korsanının ilgisini çeker çünkü bu tip uygulamaların sıkı testlerden ve kalite güvence işlemlerinden geçmediğini bilirler. Özel yazılmış bir web uygulamasını sadece imza-tabanlı bir tarayıcı ile taramak SQL Enjeksiyon veya diğer açıklara karşı tam olarak test yapılmaması anlamına gelir. Bilinen uygulamarın açıklarının bulunduğu bir veritabanı ile test yapmak yeterli değildir. Bu pasif denetimdir çünkü sadece hazır yazılmış uygulamaları içerir ve yeni hack tekniklerinden etkilenen açıklar keşfedilemez. Hack saldırıları test için imza dosyası kullanmayabilir - bilgisayar korsanları bilinen hazır uygulamaların, sistemler ve sunucular üretici firmaları tarafından sık sık yapılan güncellemeler ile güvenli hale getirildiğini bilirler. Bu yüzden özel hazırlanmış uygulamalar onlar için daha uygundur. Sonuç olarak öncelikli olarak keşifsel (heuristic) tarama metodu (ek olarak imza eşleştirme de) kullanan web uygulama tarayıcıları kullanılmalı. Kaynak:[ÜYE OLMADAN LİNKLERİ GÖREMEZSİNİZ. BURAYA TIKLAYARAK BEDAVA ÜYE OLUN...] Anlaşılır olmanın çok uzağında...!!! Eğer iyi bir hackersan herkes adını bilir ama Muhteşem bir hackersan kimse kim olduğunu bilmez... Cross Site Scripting ( XSS ) RFİ -LFİ SQL İnjection sosyal mühendislik Konu By_HeLL tarafından (06-26-2008 Saat 12:02 AM ) değiştirilmiştir.. |
|
|
|