Pencereler ile Elma’nın Kavgası

Elinin tuttuğu, gözünün gördüğü her şeyin patentini almaya çalışan Apple’ın, son olarak da App Store’u markalaştırmak istemesine tepki gösteren firmalar arasına Microsoft da katıldı. Microsoft Ocak ayında bu durum için mahkemeye başvurmuş ve “App Store”un çok geniş bir isim olduğunu ve markalaştırılmaması gerektiğini belirtmişti. Apple ise App Store ifadesinin, Microsoft’un yorumladığı gibi “süper market” anlamında […]

5 Mart 2011

Posted In: App Store, Apple, linux, Lisans, Marka, microsoft, Özgür, pardus, Patent

Güvenli Kod Yazımı

Evet arkadaşlar uzun zamandır yazamıyordum. Bunun nedeni uzun zamandır projelerle uğraşıyor olmam. Bugün sizlerle projelerimi yaparken rapor olarak yazdığım nasıl güvenli kod yazılır adlı raporumu paylaşacağım. Verilen örnekler biraz .NET platformu üzerinden ama herkes için yararlı olacağını düşünüyorum.


Güvenlik çok yönlü bir olaydır ve güvenlik riskleri her yerde olabilir. Belki kötü bir hata denetim kodu, belki çok geniş bir yetkilendirme, belki de server üzerinde hangi servislerin çalıştığının unutulması  Bu liste böyle uzar gider ve yazımızın amacı da buradan çıkar Burada bizim amacımız en çok yapılan yazılım hatalarını incelemek ve bu hatalara karşı ne gibi önlemler alabileceğimizi öğrenmektir. Unutmayalım ki bunlar sadece güvenli kod yazabilmek için ilk adımlarımızdır. Bunların dışında yüzlerce farklı saldırı tekniği ve korunma metodu vardır. Bunların hepsini uygulasak dahi aklımızdan çıkarmamız gereken bir husus daha vardır. Asla güvenli kod yoktur. Çünkü saldırganlar her geçen gün saldırı tekniklerini değiştirmekte ve farklı saldırılarla sistemlerimize ve kodlarımıza saldırmaktadırlar.

Olası Güvenlik Riskleri

1)SQL Injection

SQL Injection hala daha görülebilecek en büyük açıklıklardan biridir. Kullanıcı verisine dayanan bir atak türüdür. Bu atak türü genellikle kod yazanların SQL Injectionı tam anlamıyla anlamadıkları için başlarına gelir. Peki nedir bu SQL injection. Bunu anlayabilmemiz için once SQL in ne olduğunu bilmemiz gerekir. SQL veritabanıyla anlaşmamızı ve verileri veritabanından çekip üzerlerinde işlem yapmamızı sağlayan bir dildir. Bir nevi biz insanların veritabanıyla konuşup anlaşma şeklidir. SQL Injectionı ise kullanıcının söylediği sözlerin veritabanına biraz değiştirilmiş şekliyle yansıtılması olarak tanımlarsak yanlış tanımlamış olmayız. Buna gore de veri tabanının bize vereceği değer değişecektir ki kötü niyetli son kullanıcılar bu yapıdan faydalanarak istenmeyen olaylara maruz bırakabilir bizi. SQL Injectionı biraz kavradıktan sonra bir tane gerçek örnek üzerinde durumu konuşalım.
Aşağıdaki gibi bir SQL sorgumuz olsun

Select * from kullanıcılar where username=$uname AND password=$pass

$uname ve $pass kısımlarını kullanıcıdan alıyoruz. Burada eğer kullanıcı bize gerçek değerleri verip giriş yaparsa bunda hiçbir sorun yok. Ama eğer kullanıcı adı ve şifre yerine özel bir takım karakterler yazarak girişi sağlayabilirsek işte o anda yetkisiz olarak verilere ulaşabiliriz. Username ve pass için bir SQL injection denemesi yaparak neler olabileceğini inceleyelim. Eğer usename ya da pass yerine “OR” yazarsak yetkisiz olarak giriş yapabiliriz ve system içerisinde kullanıcı yetkilere gore gönlümüzce dolaşabilriz.

Select * from kullanıcılar where uname =”OR”=” AND pass=”OR”=”

2)Cross Side Scripting

Cross Side Scripting kısaca, HTML ve Javascript yardımıyla bir sitede, siteye giren kullanıcıya tehlike arz edecek şekilde kod çalıştırmaya denir. Temel olarak kullanıcıların bilgilerini çalmayı amaçlar. Cross Side Scripting de SQL Injection gibi kullanıcı verilerine dayanan bir saldırı türüdür.

3)Broken Authentication and Session Management
   
Tam olarak güvenliği sağlanmamış ( örneğin md5 veya benzeri bir algoritma ile korunmamış) oturum nesnenleri ve çerezlerinin ele geçirilip kötü amaçlar için kullanılmasıdır. Organizasyonlar için önerilen şeyse developerlarına güçlü authentication ve session management control sağlamasıdır.

4)Insecure Direct Object References
   
Herhangi bir kontrol mekanızması olmadan kod içerisinden bir dosyanın include edilmesi, direk veritabanı erişim bilgilerinin saklanması ve çağrılması ve benzeri public fonksiyon erişimleri gibi hatalardır. Korunmak içinse indirect objeler kullanılmalı ve objelere erişim control altında tutulmalıdır.

5)Cross Site Request Forgery (CSRF)
   
CSRF ataklarından bir sisteme login olmuş kullanıcı tekrardan login request göndermesi için zorlanır fakat bu sefer login requestindeki bilgileri istemciye değil saldırgana aittir.
Konuyu daha iyi anlayabilmek için yine bir banka örneği vererek açıklayalım. Saldırganın amacı banka hesabımızı boşaltmaktır. Bu amaç için bir web sitesi hazırlar ve bir resim içerisine bir kod aşağıdaki gibi bir kod gömer.

http://example.com/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

Eğer kullanıcı önce bankasında bir işlem yapıp daha sonar banka sayfasını kapatmadan bu siteye girip yukarıdaki imajın bulunduğu linke tıklarsa saldırgan kurbanın bilgisayarındaki cookie bilgilerinden yararlanarak amacına ulaşabilir.

6)Security Misconfiguration
   
Güvenlik ile ilgili tanımların zayıf, yanlış veya varsayılan olarak bırakılmasından kaynaklanan saldırılardır. Örneğin evinizdkei ADSL modemleri şifrelerinin değiştirilmemesi gibi. Her cihazın default şifrelerine ( bunlara cisco, juniper vb güçlü cihazlar dahil) internetten 15 saniyede ulaşabilirsiniz.

7)Insecure Cryptographic Storage
   
Kriptolonamamış verilerin zayıf sunucularda korunması(maması). Günümüzde pek çok e-ticaret sitesi müşterilerinin bilgilerini şifrelemeden saklamaktadır. Kötü niyetli Host sahibi veya saldırgan bu bilgilere ulaşabilir. Korunmak için verytabanına kaydettiğimiz özellikle şifre gibi veriler kriptolanmış bir şekilde kaydedilmelidir.

8)Failure to Restrict URL Access
   
Erişimi kısıtlanmış sayfalara erişimlerin kontrol edilmemesidir, bu sayafalara erişen diğer sayfa ve modüllerin iyi bir şekilde izlenmemesi veya kodlama hataları vb.
Örneğin bir admin paneline bir kısıtlama koymadan link yardımıyla ulaşılabilyorsa bu çok büyük bir güvenlik riskidir.

9)Insufficient Transport Layer Protection

Uygulamalar genelde hassas mesajlar gönderilirken network trafiğini kriptolamayı başramayabilirler. Başarsalar bile zayıf algoritmalar vb şeylerle yaparlar. Burada eğer network trafiğini dinlemeyi başaran birileri varsa bizim network üzerinden ulaştırmaya çalıştığımız bütün bilgileri çalabilir.   
Bu ataklardan korunmak için böyle hassas verilerimizi güçlü bir kriptolama işleminden sonra yollamalıyız.

10)Unvalidated Redirects and Forwards
   
Bir çok web uygulamasında ilk ve son veri kontrolü yapılmaksızın yönlendirmeler yapılmaktadır. Buna en güzel örnek yıllar önce alışveriş sitelerinde ödeme sayfasına geçmeden bir önceki sayfalarda fiyatlar ve miktalar değiştirilerek ödeme sayfasına yönlendirme işlemleri idi. Kısaca uygun bir kontrol yapılmadan saldırganın bizi pishing ya da malware sitesine yönlendirmesidir.
Korunmak içinse yönlendirmelerden kaçınmalıyız. Eğer yapmak zorundaysak kullanıcılardan aldığımız veriler doğrultusunda yapmayınız.

Kodlarımızı Daha Güvenli Yapabilmek İçin 7 Öneri

1)Asla Kullanıcı Girdisine Güvenme

Bu yazıyı okuyorsanız aklınızda kalması gereken en önemli şey budur. Asla kullanıcı girdisine güvenmeyin. Çünkü saldırıların büyük bir çoğunluğu bu taraftan gelir. Eğer dış dünyadan aldığımız her verinin doğru ve kötü niyetsiz olduğuna inanırsak ilk sorunumuz orada başlar. Çünkü saldırganlar tarafından kullanılan bir çok güvenlik açığı sunucuya kendi işlerine yarayacak kötü bir mesaj göndermle kırılır.
Inputlara güvenmek ve bilgilerin doğru formda olduğuna koşulsuca inanmak buffer taşmasına, cross side scriptinge, SQL Injectiona ve bunun gibi bir çok soruna neden olabilir.

2)Buffer Taşmalarından Korunun

Buffer taşması saldırganın programa programın beklediği değerden daha büyük bir değer vermesi  sonucunda değişkenin ayrılmış olan memory alanina sığmamasıdır. Ya da programlama yaparken ufak bir gözden kaçma sonrasında da oluşabilir. Programcı ne kadar tecrübeli olursa olsun bu hatalara dikkat etmelidir. Bir buffer taşması sonucu uzaya gönderilmiş olan bir uzay gemisi parçalanmıştır. Görüldüğü gibi küçük bir olaymış gibi gözüksede sonuçları çok büyük olabiliyor. Bu kadar büyük sorunlara yol açabilmesine ragmen genellikle buffer taşmasının çözümü oldukça basittir. Genelde biraz dikkatli olarak ve alınan değerlerin aralıklarını belirleyerek üstesinden gelinebilir.
Bu olaylara mahal vermemek için yapılması gereken en önecelkli şey unsafe kodlara izin vermemektir.


3)Cross-site Scriptlerden Korunun

Croos side scriptleri webe özel güvenlik açıklarından biridir. Aşağıdaki kod parçasına bakmak istersek;


Böyle masum gibi görünen bir kodun aslında saldırıya açık bir kod bloğudur. Normlde, kullanıcı bu tür bir koda aşağıdaki gibi bir URL ile birlikte ulaşırlar:


C# yukarıdaki script kodundan aldığı verileri iyi formda ve sadece name değerinden başka bir şey almayacakmış gibi düşünür. Fakat saldırganlar bu kodu istismar ederler ve name değeri yerine tıpkı bir name değeriymiş gibi bir script girerler;


Eğer yukarıdaki adresi adres çubuğuna girersek önümüze içeriğinde hi! Yazan bir dialog box ın çıktığını görürüz. Bu ne demek peki. Bu saldırganın bizim web sitemize istediği gibi müdahale edebilmesi anlamına geliyor. Belki böylesine zararsız bir kod için çok bir önemi olmayabilir fakat bir de olaya şu açıdan bakın. Bu web sitesinin bir bankanın web sitesi olduğunu ve yazılan scriptin internet şubesine giriş butonunu etkilediğini düşünelim.




Kullanıcı giriş butonuna tıkladığı zaman aynı bankanın internet şubesi arayüzüne bağlanır gibi fakat saldırganın önceden hazırladığı bir web sitesine yönlendirir.




Web sitesi tıpkı bankanın sitesine benzediğinden kullanıcılar çoğunlukla gerçek web sitesiyle arasındaki farkı anlayamazlar ve güvendikleri için bilgilerini girmeye başlarlar. Bunun sonucunda da girilen bilgiler saldırgan tarafından ele geçirilmiş olur. Elbette bankalarımızın güvenliği bunların çok daha üstünde güvenlik tedbirleri alınarak yapılıyor fakat bu örneks durumun vahammiyetini daha iyi kavrayabilmemiz içindi.
Peki cross side scripting den kodumuzu nasıl koruyacağız. Bu olayın başımıza gelmesini engelleyebilmemiz için iki yöntem öneriliyor. İlki ve yazımızda da ilk olarak değindiğimiz konu olan asla kullanıcı girdisine güvenme ve girdinin ne içermesi gerektiğini katı bir şekilde belirle. Örneğin; bu işi gerçekleştirmek için regular expressionları kullanabiliriz. Regular expressionlarla kullanıcının girdisini kısıtlayarak bu işlemi yaparız. Aşağıdaki c# kodu bu işi nasıl yapabileceğimizi gösteriyor.

Regex r=new Regex(@”^[\w]{1,40}$”);
If(r.Match(strName).Success)
{
         //String Kısıtlara uyar
}
else
{
         //String kısıtlara uymaz
}

Bu kodumuzda regular expressionları kullanarak stringimizin 1 ile 40 alfanumerik karakterler arasında kalmasını sağlıyoruz. Kullanıcının girdisini kontrol etmenin en güvenli yolu budur. Bu işlemi terstende uygulayabilirsiniz. Yani yasak karakterleri teker teker yasaklayarak. Fakat burada unutulmaması gereken bir husus var ki bu işlem yapılırken yapacağımız ufak bir dikkatsizlik saldırı yememize neden olabilir. Bu yüzden izin verilmeyen karakterleri yasaklamak yerine izin verilen karakter olup olmadığına bakmak daha güvenli bir yoldur.
Bu saldırıları önlemenin ikinci yoluysa bu özel karakterleri daha güvenli karakterlerle değiştirme yöntemidir. Ama birinci yöntem kesinlikle daha güvenlidir.

4)Asla sa İzniyle Hareket Etme

Şimdi de biraz SQL Injectionları inceleyelim. Bilindiği gibi birçok yazılım geliştirici kullanıcılardan değer alarak very tabanı üzerinde bu değerlerle birlikte işlem yaparlar.
Aşağıdaki kodu biraz inceleyelim;

void DoQuery(string Id) {
    SqlConnection sql=new SqlConnection(@"data source=localhost;" +"user id=sa;password=password;");
    sql.Open();
    sqlstring= "SELECT hasshipped" +
            " FROM shipping WHERE id='" + Id + "'";
    SqlCommand cmd = new SqlCommand(sqlstring,sql);

Birçoğumuz yukarıdaki gibi bir kod yazmıştır muhtemelen. Fakat bize tanıdık gelen bu kod aslında o kadar da masum değil. 3 kusuru var bize tanıdık gelen bu kodun. İlk olarak, database e ulaşım system administrator(sa) hesabı kullanılarak yapılmaya çalışılmış. Sa hesabı için belirlenen mükemmel şifremiz password olarak belirlenmiş. Ama bunlara rağmen bu koddaki asıl sorun string birleştirme işlemi yaparak SQL statementı oluşturuyor olmasıdır. Bu durumda eğer kullanıcı Id değeri için 1001 yazarsa ve bu string işletilirse hiçbir sorun çıkmaz ve muhtemel olarak aşağıdaki gibi bir kod işletilir.

SELECT hasshipped FROM shipping WHERE id = '1001'

Maalesefki saldırganlar bu kadar iyi niyetli değil. Id=1001 yazmak yerine aşağıdaki gibi bir kod işletmeyi deneyebilirler;
SELECT hasshipped FROM
shipping WHERE id = '1001' 
DROP table shipping -- ';

Yukarıdaki sorgu istediğimiz select işlemini yapıyor olmasına rağmen devamında gelen kodlar sayesinde shipping tablosunuda siliyoruz ki bu istemediğmiz bir olay. – operatorü sayesinde sonrasında gelen kodlar yorumlanmıyor. Biraz once sa olarak veri tabanına bağlanmıştık ve şimdide bir tablo sildik. Peki bu tür bir olay sadece select yetkisi verilmiş bir username ile veritabanına bağlanılmış olsaydı başımıza gelirmiydi. Cevap çok basit tabiki hayır. Bu yüzden veri tabanına bağlanırken dikkat edilmesi gereken en önemli konulardan biri veri tabanına asla system administrator yetkisiyle bağlanmamaktır.
Peki nasıl SQL Injection yemekten koruyabilriz kodumuzu. Bunun için dinamik sql kodları kulanmak yerine stored procedure lar kullanmak en akıllıca olan yollardan biridir. Tabiki yine bir numaralı altın kuralımızı unutmayarak kullanıcı girdilerinin istediğimiz formatta olup olmadığını da control etmeliyiz. Örnek kod;

Regex r = new Regex(@"^\d{4,10}$");
if (!r.Match(Id).Success)
    throw new Exception("Invalid ID");

SqlConnection sqlConn= new SqlConnection(strConn);
string str="sp_HasShipped";
SqlCommand cmd = new SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@ID",Id);

Unutmayalımki cross-side scripting, buffer overruns ve SQL Injection ların hepsi kullanıcı girdisine güvenme sonrasında çıkmıştır. Bu yüzden altın kuralımızı her zaman hatırlamalıyız.

5)Asla Kendi Ürettiğin Encryption Sistemini Kullanma

Eğer bir kriptolama işlemi yapıcaksanız asla kendi ürettiğiniz kripto algoritmasını uygulayarak yapmayın. Pek çok insan kendi ürettikleri kripto algoritmalarının kırılmasının çok zor olduğunu düşünerek bu tür bir yolu seçerler fakat yanıldıkları en büyük nokta kriptoladıkları kodların muhtemelen birkaç dakika içerisinde kırılabilecek düzeyde olmasıdır. Bu yüden c# dilinde kriptolama işlemi yapacaksak kripto kütüphanelerini kullanmamız daha iyi sonuçlar doğuracaktır.


6)Least Privilage Prensibine Uyun

İşletim sistemleri ve common language runtime(C# kodumuzun makine diline çevirildiği yer) bir çok nedenden dolayı güvenlik prensiplerine sahiptir. Bunun da temel amacı kullanıcıların erişime yetkisi olmayan yerlerde verilere ulaşmalarını engellemek ve kötü niyetli kişilerin veriliremizle oynamasını engellemektir ve genellikle bunu serilization işlemlerini engelleyerek yaparlar. Güvenlik prensiplerini kodumuzu çevreleyen bir duvar şeklinde düşünebiliriz. Erişime izni olanları içeriye alır, izni olmayanları duvar dışında bırakır.
Yukarıda söylediğim güvenlik prensipleri dışında bize düşen bazı görevler daha vardır. Burada asıl amaç hiçbir zaman gereğinden fazla yetkiyi vermemektir. Şöyle bir örnek düşünelim;
Elimizde veritabanımızdaki verileri gösteren bir yapı olsun. Burada amacımızı gerçekleştirebilmemiz için bize sadece vritabanımızdan select yetkisi almış olan bir connection yetecektir. Çünkü tüm yapmak istediğimiz verileri veritabanından çekmektir. Eğer bir şekilde kötü niyetli bir kişi web sayfamızın diger açıklarından faydalanıp oynamalar yapmaya çalışıyorsa tek yapabileceği bizim kullanıcılara göstermiş olduğumuz verileri alabilmektir. Asla veriler üzerinde değişiklik yapamaz. Ama bu örneğimizde veritabanına erişim yetkimizi sadece select olarak değilde update ve delete de dahil olacak şekilde bir yetki vermiş olsaydık işte o zaman kötü niyetli saldırgan verilerimizi değiştirebilr ve bizim istediğimiz verilerimizi sergilememizi engeleyebilirdi. Hatta ve hatta daha ileriye giderek veritabanımızdaki verilerimizi silebilirdi bile.
İşte yukarıdaki gibi durumlara maruz kalmamak için her zaman işlerimizi yapabileceğimiz en düşük yetki seviyesinde yapmalıyız. Her zaman least privilege ilkesine uymalıyız.

7)Hata Denetimine Yeterli Önemi Ver

Bu yazıyı okuduğunuza gore kod yazma işine bir tarafından dahil olduğunuzu düşünüyorum. Hepimiz kod yazıyoruz öyle değil mi? Peki kaçımız bu yazdığımız kodların test kısmına gerekli önemi veriyoruz ya da error handling mekanizmalarını yeterince kullanıyoruz. Bu üzerinde genellikle yüzeysel olarak durduğumuz konulardan. Oysaki en az yukarıda konuştuğumuz durumlar kadar önemli bir durum bu.
Test edilmeden kullanılan programlar genelde büyük güvenlik açıklarına sahiptirler. Bu güvenlik açıklarına maruz kalmamak için kodlarımızın test bölümüne yeterli önemi vermeliyiz. Elbetteki bütün şartlar için test edemeyiz fakat ne kadar çok test yaparsak ileride programımızın çökme olasılığı da o derecede iner. Ne kadar az test yaparsakta güvenliğin temel ilkelerinden olan sürdürülebilirliği sağlamamız da o derece zorlaşır.
Bir de kodlarımızı yazarken error handling sağlayabilmemiz için gerekli yerlerde try-catch bloklarını koymaya özen göstermeliyiz. Olağan dışı oluşan durumlarda ya da olası olusabilecek hatalarda programımızın çökmesi ya da yanlış çalışması yerine bir uyarı mesajı vererek progamımızın güvenilirliğini artırmamızı sağlar.

Kaynaklar








30 Aralık 2010

Posted In: Gezegen, Guncel ve Teknoloji, microsoft

Muhtacım Sana İE

Daha önce Karadeniz Teknik Üniversitesi’nin kütüphanesindeki bilgisayarların Fedora’ya döndüğünü ve bunun yepyeni bilgisayarlara geçişle gerçekleştiğini yazmıştım. Eğer bu yaz ben yokken bir değişiklik olmadıysa şu aralar kampüse uğramışken bütünleme kaydını da yapmayı düşünen arkadaşlar ilginç bir durumla karşılaştılar. Bütünleme kayıt arabirimi sadece İnternet Explorer ile çalışıyor. Firefox, Konqueror, Opera vs. ne denerseniz deneyin hatta tarayıcıyı [...]

26 Ağustos 2007

Posted In: gnu/linux, KTÜ, Linux Gezegeni, microsoft

WP Twitter Auto Publish Powered By : XYZScripts.com