Sql İnjection – Meta Karakter Temizliği

Dökümana başlamadan önce sql nedir ufakça bir değinelim.:

Select, form, where gibi sql cümlecikleri ile araya sıkıştırılan meta karakterlerle sql üzerinden uzaktan kod çalıştırmaya “sql injection” denir.

Meta karater nedir?

Meta karakter çeşitli dillerde özel anlam ifade eden harf ya da çeşitli noktala işaretleridir. Harf ve noktala işaretlerinin tamamına verilen isim ise karakterdir. Sql de en önemli karakter ‘ ve ; yani tık tırnak veya noktalı virgüldür. Satırın bittiğini veya başladığını belirtir.

Örnek:

1. ‘////tDeger : Formyada QueryStringden Gelen Değer
2.  
3. ‘tDeger Parametresi ise burda sayısal mı tarih mi yoksa string durumlarına göre kontrol sağlanıyor
4.  
5. ‘0:String,1:Sayısal,2:Tarih
6.  
7. Function foFuncInjectionTemizle(tDeger,tParam)
8. if NOT tDeger=vbNullString then
9. if tParam=0 then
10.  
11. tDeger=trim(tDeger)
12. tDeger = Replace(tDeger,”UNION”,”")
13. tDeger = Replace(tDeger,”‘”,”’”)
14. tDeger = Replace(tDeger,”"”",”"”)
15. foFuncInjectionTemizle=tDeger
16. elseif tParam=1 then
17. if Not IsNumeric(tDeger) then
18. foFuncInjectionTemizle=”0″

Eval Injection

NMAP nedir?

Nmap, sistem yöneticilerinin geniş ağlarını taramasında ve hangi istemci/sunucusunda hangi servislerin çalıştığını saptamasında kullanabileceği bir araç olarak tasarlandı.

Nmap geniş bir tarama yelpazesini destekler ; UDP, TCP Connect, TCP SYN (Yarı Açık), FTP Proxy Bounce Atağı, TCP FIN, TCP Xmass Tree, ICMP (Ping Sweep), ACK Sweep, SYN Sweep ve Null Scan bunlara birkaç örnektir. Bahsi geçen port türleriyle ilgili daha ayrıntılı bilgi bu yazının ilerleyen bölümlerinde ve Port Tarama Nedir? yazımızda bulunmaktadır. Nmap ayrıca gelişmiş özelliklere sahip bir araçtır, TCP/IP parmak izleri ile hedefin işletim sistemini saptayabilir, Stealth (Gizli) tarama yapabilir, taramalarında dinamik zamanlamalar kullanılabilir, paralel taramalar yapabilir, ping atarak aktif hostları bulabilir, RPC taraması yapabilir, esnek port ve hedef özelliklerine sahiptir.

Unutulmaması gereken en önemli nokta hedef sistemde açık olan portların nmap’in standart olarak nitelendirilen ve /etc/services dosyasından aldığı port numarası ve sunucu servis karşılaştırılmaları tablosu aracılığıyla tespit edilmiş olmasıdır.

Örnek olarak standart kullanımda 21/TCP ftp protokolü için kullanılan bir port olması dolayısıyla bu portu açık bulan nmap servisin ftp olduğunu bildirecektir, ancak o portu dinleyen servis farklı bir servis (örnegin vnc sunucusu) olabilir.

Şimdi neler yapabileceği anlatıldığına göre sıra bunların nasıl yapıldığını anlatmaya geldi.

Tarama Türleri

-sT  TCP Connect Scan : En basit anlamda çalışan tarama tekniğidir, hedef porta bağlanmak için SYN paket gönderir, karşılığında SYN/ACK paketi gelirse ACK paketi göndererek porta bağlanır ve portun açık olduğunu rapor eder, eğer SYN paketine RST cevabı gelirse portun kapalı olduğunu rapor eder. Bu tarama türünde extra paket özelliklerine sahip olmak gerekmediği için root olmayan kullanıcılarda kullanabilir. En kötü özelliği açılan tüm oturumların hedef sistem, Firewall yada IDS tarafından loglanıyor olmasıdır.

-sS TCP SYN Scan : Yarı açık olarakta tanınan SYN tarama oturumu tamamen açmaz, SYN paketinin karşılığında SYN/ACK paketi geldiğinde portun açık olduğunu rapor eder ve RST paketi göndererek oturumu kapatır, port kapalı ise hedef zaten direk RST cevabı gönderir. Bu yöntemi uygulayabilmek için root olmak gerekmektedir. IDS ve Firewall’lara yakalanma ihtimali ve loglanma ihtimali azdır.

-sF, -sX, -sN : Bu tarama yöntemleri ise sırayla gizli FIN , Xmass Tree ve Null Scan’dir. IDS ve Firewall’ların SYN taramaları loglayabileceğini düşünerek kullanılan yöntemlerdir. FIN, Xmass Tree ve Null scan paketlerinin gönderilmesi durumunda hedefin RFC 793’te açıklandığı gibi kapalı olan tüm portlar için RST cevabı göndermesi mantığına dayanır. Bu yöntem IPeye ve NmapNT ile windows platformunda da uygulanabilmektedir. Ayrıca bu tarama yöntemleri açık port buluyorsa (FIN taramada Windows sistemlerindeki tüm portlar açık olarak görünmektedir, çünkü Windows tabanlı sistemler bir oturuma ait olmayan FIN paketleri ile karşılaşıyorsa tümünü göz ardı ederler ve göz ardı edilen paketler standart olarak portun açık olduğu anlamına gelir.) hedefin sistemi Windows tabanlı değildir. Eğer SYN scan açık port buluyor ve bu tarama yöntemleri bulamıyor ise hedef Windows tabanlı bir sisteme sahip demektir. Nmap’in İşletim sistemi saptama özelliklerine bu durum dahildir. Windows’la aynı tepkiyi veren bazı sistemler ise Cisco, BSDI, HP/UX, MVS ve IRIX’ tir.

-sP Ping Sweep : Taranılan ağda hangi hostların aktif olduğuna ihtiyaç olduğunda kullanılan genel yöntem ICMP Echo paketleri gönderip cevap beklemektir, son zamanlarda bu ping isteklerinin Firewall’lar tarafından bloke edildiği düşünüldüğünde alternatif çözümler geliştirilmelidir. Bu durumda nmap TCP ACK paketi gönderiyor (standart olarak 80. porttan – değiştirilebilir), eğer porttan RST cevabı geliyorsa sistemin aktif olduğu rapor ediliyor. Diğer alternatif teknikte bir SYN paket gönderip hedeften SYN/ACK yada RST cevabı beklemektir, her iki cevapta sistemin aktif oldugunu gösterir. Root olmayan kulanıcılar için ise standart TCP Connect yöntemi kullanılır. Standart olarak ICMP ve ACK teknikleri paralel olarak uygulanır. Eğer bunun değiştirilmesi istenirse -P* parametreleri kullanılarak bu yöntemler değiştirilebilir. Ayrıca bu pingleme işlemi tamamlandığında sadece aktif sistemler taranır, bu seçenek ping taraması kullanmadan port taramaya geçmek isteniyorsa kullanılabilir.

-sU UDP Scan : Bu teknik hedef bilgisayarın UDP portlarından hangilerinin açık olduğunu saptamak için kullanılır.

(RFC 768) Hedef makinede açık olduğu düşünülen porta 0 byte’lik bir UDP paket göndermek ve “ICMP Port Unreachable” paketini beklemek temeline dayanır. Paket gelirse port kapalı gelmezse açık olduğuna karar verilir. Bazı insanlar UDP taramayı önemsemezler. Önemsemelerini gerektiren sebepler arasında Tftp, NFS, Snmp gibi protokollerin UDP üzerinden çalışması ve Solaris’in RPCBind açığı sayılabilir.

-sA ACK Scan : ACK tarama yöntemi Firewall`ların ACL`lerini bypass ederek tarama yapılmasını sağlar. Bazı Firewall`lar stateful yada basit paket filtreleme Firewall`ları olabilir, dışarıdan gelen SYN paketlerini bloke edebilir ancak ACK flag’lı paketin geçişine izin veriyor olabilir. Rastgele üretilmiş ack/sequence numaralarıyla yapılır. Cevap gelmezse yada ICMP port unreachable mesajı geliyorsa port filtrelenen bir porttur. Nmap genellikle portlar için unfiltered nitelemesi yapmaz. Bu taramada bulunan portları asla açıkca `open` olarak nitelendirmez.

-sW Window Scan : Bu gelişmis tarama türü ACK tarama türüne çok benzer, portların açık olup olmadığını taraması dışında bu portları filtered/unfiltered olarak nitelendirir ve çerçeve boyutundaki farklılıklardan hedefin işletim sistemini saptar. Aralarında AIX, Amiga, BeOS, BSDI, Cray, Tru64 UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, QNX, Rhapsody, SunOS 4.X, Ultrix, VAX ve VxWorks gibi işletim sistemlerininde bulunduğu işletim sistemlerinin bazı versiyonları bu durumdan etkilenir. Tam listeye ulaşabilmek için Nmap-Hackers posta listesinin arşivlerine bakılabilir.

-sR RPC Scan : RPC taramaları için diğer tarama türleriyle beraber kullanılır. Bütün TCP/UDP portları tarayarak açık bulduğu portlarda SunRPC`nin “NULL” komutlarını kullanarak rpc portlarını saptamaya çalışır, eğer rpc portu bulursa çalışan program ve sürümlerini saptamaya çalışır. Böylece Firewall yada diğer paket filtreleme cihazları hakkında bazı işe yarar bilgiler saptamaya çalışır. Decoy özelliği şu an için RPC taramalarda kullanılamıyor ancak bazı UDP RPC taramalarında bu özellik nmap`e eklenmiştir.

-b (ftp relay host) : Ftp protokolunun ilginç bir özelliği proxy için destek vermesidir (RFC 959). Bunun için öncelikle hedefin ftp sunucusuna bağlanmak gereklidir, daha sonra internette herhangi bir yerden o sunucuya bir dosya gönderilebilir. RFC nin yazıldığı 1985 yılından günümüze kadar ftp bu özelliğe sahip olabilir. Böylece bir ftp sunucu üzerinden TCP port tarama yapabilme imkanıda kazanılmış olur. Bu seçenek ile bu denemeler uygulanabilir.

Dranzer – ActiveX Nesnelerinin Güvenlik Testi Nasıl Yapılır?

Uzun zamandır activeX ile ilgili doğru düzgün bir güvenlik yazılımı görmemiştim. O yüzden bu yazılım gözümde bi kat daha değerli. Bugün security-database’de gezinirken rastladığım bu güzel programı paylaşmak istedim.

Download :

http://sourceforge.net/projects/dranzer/

Usage (Kullanım) :

“dranzer.exe <secenekler>”

Seçenekler :

-o <outputfile> – Output Filename
-i <inputfile> – Use input file CLSID list
-d <notestfile> – Use don’t test CLSID List
-g – Generate base COM list
-k – Generate Kill Bit COM list
-l – Generate Interface Listings
-b – Load In Browser (IE)
-t – Test Interfaces Properties and Methods
-p – Test PARAMS (PropertyBag) in Internet Explorer
-s – Test PARAMS (Binary Scan) in Internet Explorer
-n – Print COM object information
-v – Print out version information
-r – Generate Kill Bit registry files

Örnek:

dranzer.exe -g

User Guide :

http://docs.google.com/Doc?docid=0ATn5yqW-bnJPZGhtZGNoZjVfMTAwYzU0NW04OXE&hl=tr

Döküman :

dranzer

Bakılması Tavsiye Kaynaklar :

http://www.cert.org/vuls/discovery/dranzer.html

M.Serhat Dündar

Güvenli ASP.NET Prodüksiyon Ortamı

Web Uygulaması Güvenliği

Web uygulaması güvenliği sağlanırken genellikle akıllara ilk gelenler çeşitli kod enjeksiyonu zafiyetleri ve girdi doğrulama temelli yaklaşımlardır. SQL Injection’ı kesmek için parametrik sorgular, XSS’i kesmek için output encoding, LFI & RFI için doğru şekilde girdi doğrulama ve CSRF için de kritik fonksiyonaliteler için token uygulaması.

Oysa dünyanın en güvenli uygulamasını yazmış olsanız dahi, sunucu üzerinde tutulan bir klasörün izinlerini doğru şekilde düzenlemediyseniz , hack’lenmeniz işten bile değil ! Bundan dolayı işin kod kalitesi ile ilgili kısmını düşünürken, konfigürasyonel boyutunu da es geçmemek gerekmektedir.

ASP.NET

Günümüzde web uygulamaları bir çok programlama dili vasıtasıyla yazılabilmekte ve bir çok üretim ortamında çalışabilmektedir. Bu dillerden ve platformlardan önemli bir tanesi ise ASP.NET ‘dir.

ASP.NET ortamında geliştirilmiş uygulamaların konfigürasyon bilgileri web.config isimli dosyada tutulur.

Web Açıklık Tarayıcıları – Bölüm 1

Web uygulamalarında bulunan güvenlik zafiyetlerinin taşıdığı riskler, bu açıklıkları, günümüz siber güvenlik anlayışının en önemli konularından biri (belki de en önemlisi) haline getirmiştir. İstatistiklere göre her 10 web sitesinden 9’unda ciddi seviyede bir açıklığın olmasının yanında siber saldırıların %60’ından fazlasının web teknolojilerine yönelik gerçekleştirilmesi bu önemin açık bir nedenidir [1].

İki bölümden oluşacak bu yazının ilk bölümü, otomatik web zafiyet tarayıcılarının genellikle ilk fazı olan girdi noktası bulma algoritmaları ve etkinlikleri üzerine olacaktır.

Web uygulamalarında bulunan açıklıklar; SQL enjeksiyonu, XSS, yetersiz hata yönetimi, CSRF gibi sadece yazılımsal veya standartlarda bulunan dizayn tabanlı hatalar olmayıp, yönetimsel ve mantıksal hataları da içermektedir.

Bu yazılımlardaki güvenlik problemlerinin bulunması, düzeltilmelerindeki en önemli adımdır. Bu adımı gerçeklemek adına üç önemli yöntem; elle yapılan testler, web uygulama açıklık tarayıcıları, statik/dinamik kod analiz araçlarıdır. Ancak bilinmelidir ki, yazılımlarda bulunan risk seviyesi yüksek zafiyetlerin açığa çıkarılması sadece tek bir yöntemle mümkün veya uygulanabilir değildir. Bu nedenle kapsamlı bir risk haritası için her üç yönetimin de elden geldiğince uygulanması gerekir.

Otomatik web açıklık tarayıcılarının (WAT) kapsayıcı ve zaman açısından etkin olmaları, web güvenlik risk haritasının çıkarılmasında çok önemlidir. WAT çalışma süreçlerinin birçok safhası vardır ama işleyişleri genel olarak ikiye ayrılır; girdi keşfi ve zafiyet analizi.

Fuzz Testing

Bu yazımızda uygulama test tekniklerinden birisi olan fuzz testing (fuzzing) tekniğini ve web uygulamalarına nasıl uygulanabileceğini göreceğiz.

---

Fuzz Testing (Fuzzing)

Bir uygulamada zafiyet tespit edebilmek için uygulamaya rastgele veriler göndererek, uygulamanın farklı isteklere verdiği cevapları analiz etmek isteyebiliriz. Bu rastgele veri gönderme işlemine fuzzing (fuzz testing), bu işlemi yapmaya yarayan araçlara ise fuzzer denilmektedir.

Fuzz testing; test yapılacak uygulamanın arka planında ki işlevsel ve yazılımsal özellikler bilinmediğinden ve gönderilen verilerin uygulamada oluşturduğu etki ve sonuçların analizine dayandığından, uygulama test tekniklerinden black-box kategorisine girmektedir [1,2].

Fuzz testing; yazılım geliştirme ve test süreçlerinde ve ters mühendislik işlemlerinde kullanıldığı gibi, web uygulamalarında zayıflık tespiti veya bilgi toplama amaçlı da kullanılmaktadır. Web uygulamaları için geliştirilmiş olan fuzzing araçlarını (fuzzer) iki kategoride inceleyebiliriz [3];

Web Açıklık Tarayıcıları – Bölüm 2

İlk bakışta ve özellikle demolarda özellikleri ile baş döndüren bu araçlar, yakından tecrübe edildikçe ve üzerinde çalıştıkları teknolojiler/zafiyet detayları öğrenildikçe, başarmaya çalıştıkları görevin çok karmaşık ve zor olmasından, bazı durumlarda beklenildiği gibi çalışmadıkları görülmektedir.

Tekrarlamak gerekirse, bu yazıda otomatik tarayıcıların iddia ettikleri özelliklerin üzerine yoğunlaşılmıştır. İddia etmedikleri özellikler ise başka bir makale konusu olabilir (mesela, kullanıcı profili çapraz testleri, integer overflow, v.b.).

Tarayıcıyı Doğru Yolda Tutmak

Hassas verilerini son kullanıcılardan koruma güvenlik gereksinimi ile yazılan web uygulamaları, kimlik doğrulama ve yetkilendirme adımlarını gerçeklemektedirler. Bu uygulamaları uzaktan denetleyecek tarayıcıların, bu kontrollerden geçip uygulamanın dahili arayüzlerine ulaşması ve uygulamadan çıkmadan ulaşabildiği bütün arayüzleri denetlemesi gerekmektedir.

Tarayıcılar doğru yolda tutunabilmek için bir çok mantıklı seçenek getirmişlerdir; giriş makro kaydedicileri, logout link belirlenmesi, v.b. Bu seçenekler denetlenen uygulamaların çoğunluğunda (ağırlıklı olarak ASP.NET/PHP/ASP) işe yaramakla birlikte, bazı durumlarda yetersiz kalmakta ve taramaların eksik kalmasına neden olmaktadırlar.

Web Güvenliğinde Otomasyon

Bu yazımızda web güvenliği testlerinde otomasyon gereksinimi ve rakamlar ile web uygulaması testleri konularını ele alıyoruz.

Yeni gelen teknolojilerin bir çoğu ilk başlarda çok güvensiz olur. Kimsenin firewall kullanmadığı, kimsenin kablosuz ağına şifre koymadığı, bir exploit’ in internetin 1/4’ ünü etkilediği zamanları görüp geçirdik. Aynı bunun gibi her üç sitenin ikisinde SQL Injection, Cross-site Scripting olduğu günleri de geride bıraktık diyebiliriz.

Tüm ağlar, işletim sistemleri bir gecede güvenli olmadı ama git gide insanların bilinçlenmesi , “firewall”, “otomatik güncelleme” gibi şeylerin standart hale gelmesi ile genel olarak çok daha güvenli sistemler ile karşılaşmaya başladık. Tabii ki bu sistemlerin basit saldırılara karşı güvenli olması tüm güvenlik açıklarının yok olduğu anlamına da gelmiyor, hala güvenlik açıkları var ama daha zor yerlerdeler.

Web de benzer bir geçiş sürecinden nasibini aldı. Daha güvenli web dilleri ortaya çıktı, üç sene önce web geliştiricileri XSS (Cross-site Scripting)’in [1] ne olduğunu bilmiyorken bugün web geliştiricisi olmayan kişiler bile en azından bu konuda bir fikir sahibiler. Tabii ki bu bilinçlenmeye katkıda bulunan tüm XSS ve SQL Injection solucanlarının da hakkını vermemiz lazım, onlar sayesinde bu tip sorunlar medayada kendilerine yer buldular [2].

Güvenlik hakkındaki bu genel bilinçlenme bir çok güvenlik açığının oluşmasına engel olmaya başladı. Artık hiç bir sitenin login formunda SQL Injection bulunmuyor ama hala bir çok web uygulamasında “Nümerik” değerler bekleyen SQL cümleciklerinde data tip kontrolü yerine sadece tek tırnaklardan kaçıldığını görebilirsiniz, mesela şu iki SQL cümleciğine bakalım:

Blind SQL Injection

Bir çoğumuz SQL cümlecikleri kullanarak veritabanlarımızda listeleme, güncelleme ve ekleme işlemleri yaparız. Fakat bu kullandığımız SQL cümleciklerinin ne tür sıkıntılar doğurabileceğinin üzerinde pek durmayız. Bir yazılımcı için önemli olan tüm kullanıcı listesini çekmek ise “SELECT * FROM users” yazmaktır. Belli bir numaraya sahip bir kullanıcı çekmek için ise “SELECT * FROM users WHERE UserID=101” yazmak yetecektir. Fakat kullandığımız programlama teknikleri bir kullanıcının bilgilerini çekmek için yazılan SQL cümleciğini çok tehlikeli durumlara sokabilir. Bu aslında bazen kullanılan dilin, bazen de yazılımcının tekniğinin sonucudur. Yine de ucu açık bir tartışma konusu diyebiliriz.

SQL Injection için söylenecekler çok fazla olsa da temel de problemin ortaya çıkış nedeni; cümleciğin herhangi bir yerine eklenen kod parçacıklarıyla farkedilir. Örneğin; “ ` ” gönderip, sonucunun hata dönmesi gibi. Tabi bazen bu hata çıktılarıda işimizi görmeyebilir veya hata dönmeyebilir. Blind hem SQL Injection açığını barındırmasıyla birlikte sonucun her zaman true/false dönmesiyle ilgilenir. Aslında bu açıklığın ciddi bir problem oluşturması temel bir matematik probleminin varlığıyla meydana gelmektedir.

MySQL: Secure Web Apps – SQL Injection techniques

Bu adresten okuyabilirsiniz :

http://docs.google.com/Doc?docid=0ATn5yqW-bnJPZGhtZGNoZjVfNzloamRjeG1mdA&hl=tr

-[ Bilgiler ]———————————————————————–

Title: “MySQL: Secure Web Apps – SQL Injection techniques”

Author: Omni

Website: http://omni.playhack.net

Date: 2009-02-26 (ISO 8601)

Translate : Serhat DÜNDAR ( CWKaradeniz / clbrTR / clbr.fentanyl / FenTanyL etc.. )

———————————————————————————

-[ Özet ]———————————————————————

0×01: Açıklama

0×02: SQL Injection

0×03: Giriş formlarını exploit etmek

0×04: Farklı SQL ifade tiplerini exploit etmek

0×05: Temel Fingerprinting

0×06: Standard Blind SQL Injection

0×07: Çift Sorgu

0×08: Filterelerin Kaçırdıkları

0×09: SQL Injection’dan Korunma

———————————————————————————

—[ 0x01: Açıklama ]

Merhaba, Yine birkaç satır daha yazmak için burada-sizinleyim. Web Uygulama Güvenliği ile ilgili ilgi çekici bir yazı olacağını düşünüyorum. Bu satırların amacı, size SQL İnj. Zaafları hakkında yardımcı olmaktır.

Burada kısa zaman önce bir çok şeyin açıklandığını biliyorum fakat bir çok kişi’den aldığım e-mailler’de kendi kodlarındaki sql inj. açıklarını nasıl bulup-düzelteceklerini soranları gördüm.

Bu yazıyı çok temel bilgilerini anlattığım; “PHP Underground Security” isimli makalenin ikinci bölümü olarak değerlendirebiliriz.

——————————————————————————-[/]

—[ 0x02: SQL Injection]

Bildiğiniz üzere; Web uygulamaları (LAMP mimarisi üzerine kurulmuş web uygulama dilleri) çeşitli verileri barındırmak için (resimler, yazılar, kullanıcı hesapları, kişisel bilgiler vb.) veritabanı kullanmaya ihtiyac duyar.

Web uygulamasıbu bilgilere SQL (Structured Query Language) kullanarak ulaşır.

Bu tipteki uygulamalar; veritabanını sorgulamak için (örnek olarak veritabanından veri çekmek gibi), bir veya birden çok Sql ifadesi inşa eder. Fakat bu sorgu bazen kullanıcı tarafından talep edilecek veri ile ilişkisiz olabilir. (Bunun hakkında biraz düşünün)

Peki ya SQL?

SQL; veritabanı içine kayıt eklemek, değiştirmek, kayıt okumak, düzenlemek için kullanılan bir DML’dir. (Data Manipulation Language)

Belirttiğimiz üzere web uygulamaları kullanıcı-tabanlı (kullanıcının bilgisi dahilinde) sorgu kullanır. Fakat; eğer kullanıcı-tabanlı veri; kullanımdan önce sağlıklı bir şekilde korunmamış ise saldırgana kendi kodunu enjecte etme imkanı sunar.

Sql Server Şifreleri ve Saklanması

Sql Server şifreleri saklamak için dökümante edilmemiş bir fonksiyon olan pwdencrypt() kullanır.Bu fonksiyon kullanıcı şifresi için bir hash değeri üretir.

Buralar genellikle herkesin bildiği şeyler.Ama daha public edilmeyen şey ise bu fonksiyonun ayrıntılarıdır.İşte bu dökümanda bu fonksiyonun detayları ve zayıflıkları hakkında bilgi vereceğim..

SQL şifre hash ’ı nasıl birşeydir ?

Query Analyzer ya da Sql aracı kullanarak şu sorguyu sorun ;

select password from master.dbo.sysxlogins where name=’sa’

Buna benzer bir şey alacaksınız ;

0×01008D504D65431D6F8AA7AED333590D7DB1863CBFC98186 BF
AE06EB6B327EFA5449E6F649BA954AFF4057056D9B

Sql Server Kullanan Uygulamalarda Tampon Belleği Kötüye Kullanmak

ÖNSÖZ

Bu makale son zamanlarda onların değer biçilmiş uygulamalarının rotası kabul edilmiş bir saldırı tekniği olan Sec-1 için tasarlanmıştır. Bu tekniğin ana prensibi bazı zamanlar için vardır. Fakat umuyoruz ki bu makale web uygulamalarında yaygın bir saldırı olarak kabul edilen “şifremi unuttum” saldırısına karşı size bir bakış açısı sağlayacaktır. Bu doküman iki bölüme ayrılmıştır. Birinci bölüm tekniğin temel esaslarından bahsetmektedir, ikinci bölüm ise ticari uygulamalarına karşı olan atakları içermektedir.

“ŞİFREMİ UNUTTUM ” ATAĞI

Web uygulamalarında çoğunlukla kullanıcının hesabının doğrulanması gerekmektedir. Ayrıca kullanıcının şifresini yenilenmesi ya da yeniden verilmesini sağlayan yöntemlerde bulunmaktadır. Bu parçalar farklı genişlikte çalışmaktadırlar. Bunun bir kaç nedeni bulunmaktadır. Örneğin: stil, dil, mantık ya da işletilen sistem. Bu atağı bir ortam yâda geliştirme stili ile sınırlandırmamak gerekir. Bu dokuman ile aşağıdaki bilinen parçalara adapte olunmuştur.
NOT: Bu örnek  Sec-1 ASNA takımı ile gerçek bir web uygulamasına dayanmaktadır.

PHP’de Güvenlik

S.A Bu konuda PHP güvenliği hakkında yazdığım makalelerimi yayınlayacağım.İnş faydalı olur.

1 – Kod Enjeksiyonu (Code İnjection):

Kullanıcıdan girdi istenen form  yapıları veya adres satırı ile yapılan saldırılara code injection saldırıları denir. Saldırgan form veya adres satırı yoluyla değişkenlere ve dolayısıyla değişkenleri kullanan sorgulara çeşitli kodlar gönderir ve eğer kullanıcıdan alınan veriler filtrelenmeden işleme konuluyorsa bu kodlar sistemde çalışırlar ve böylece güvenlik açığı meydana gelir.

Açığın oluşumu konusunda internette fazlasıyla kaynak mevcut ama ben yine de açığın oluşumunu sql üzerinden basitçe anlatacağım çünkü bizim için önemli olan kısım nasıl korunacağımız…

Örneğin bir login sayfamız var ve buradan kullanıcıların nicklerini ve şifrelerini girecekleri  bir formumuz var.Arka planda ise şöyle bir kod yapısı mevcut;

$nick=$_POST[“nick”];

$sifre=$_POST[“sifre”];

$sql= mysql_query(”select * from kullanicilar where nick=’$nick’ and sifre=’$sifre’ ”);

Normal şartlarda eğer şifre ve nick doğruysa sistem true değer döndürecek, bir tanesi bile yanlışsa sistem false değer döndürecektir.Peki ama giriş panelini açan kişinin niyeti farklıysa…

Zayıf Nokta: https

Online alışveriş yaparken, web bankacılığında ya da kullanıcı adı ve şifre girdiğiniz sayfalarda gözünüze ilişmiştir: “güvenli alışveriş”, “secure site”, “secured by xxx”. Bunlar kısmen doğru olsa da güvenlidir diyemeyiz. Burada bahsedilen güvenlik SSL güvenliğidir. Https protokolü ile web sunucusu ve istemci arasında gidip gelen trafiği şifreleyerek ağ üzerinde herhangi bir noktadan sniff edilmesini (dinlenmesini) engellemektir amacı. Özellikle kredi kartı bilgileri veya web bankacılığı giriş şifrelerini korumak için elbette zorunlu bir yöntem. Ancak oldukça büyük riskler de getiriyor web sunucusu barındıran şirketler için.

Günümüzde güvenlik duvarı kullanmayan sistem kalmadı. Birçok büyük şirkette de ya bir atak engelleme sistemi çalışıyor ya da proje aşamasında. Bu güvenlik ürünleri artık olmazsa olmazlardan. Ancak şimdi işin farklı bir boyutuna bakacağız.

Standart Intrusion Detection (IDS) ürünleri ağ üzerinde konumlandırılır ve tüm trafiği yakalayıp atak arar. IDS’ler akıllı cihazlar değildir, yakaladığı atağa karşı iki koruması vardır. Tcp reset komutu gönderebilir atak yapan ip adresine ve güvenlik duvarına bağlanıp ilgili ip adresini blok listesine yazdırtabilir. Ancak bu yöntemler oldukça yetersiz hatta risklidir.

Udp ataklarında reset diye bir imkan olmadığından IDS’ler udp ataklarını izlemekle yetinir. Bazı IDS’ler icmp ataklarına karşı unreachable cevabı dönebilir ama birçoğu bunu da yapamaz. Firewall’a kural yazdırmak ise bir atak tipi ortaya çıkarmıştır. Örneğin IDS çalıştıran sisteme bir atak yapıp, atak sırasında source ip adreslerini mask edip bilinen büyük dns sunucularının ip’sini yerleştirelim (odtu ve büyük isp’ler mesela). IDS’de gitsin bu ip’leri firewall blok listesine eklesin. Bu durumda kurban sistem dns çözümleyemez hale gelir. İntihar gibi bir şey olsa gerek IDS’lerin firewall ürünlerine blok yazdırması.