Web uygulaması geliştiren arkadaşlara buradan selamlar. Bu yazımda “Web Güvenliği” konusunu bu yazı ile temel alıp, teorik ve uygulamalı olarak Web Güvenliğini nasıl sağlayabileceğimize bakacağız. Öncelikle “Web Güvenliği’nden kastımız nedir?” ona bir göz atalım.
Web güvenliği geliştirdiğiniz bir web uygulamasının kötü amaçlı insanlar tarafından suistimal edilmemesi için gereken korumadır. Bu koruma bir developer tarafından yapılabilecek bir korumadır. Web güvenliğini sağlamak için yazdığınız kodu suistimal edebilecek herhangi bir eksiklik dahi bırakmadan yazmaktır. Örnek olursa bir string değeri int e çeviriyorsunuz ve bunun bir sayı yerine karakter gelebileceğini hiç ihtimal etmeden yazdıysanız verecek hatada sizin için ciddi sıkıntılar çıkarabilir. Bu cümleyi okuyanlar “Bir string i int e çevirmek ile ne açık oluşturulabilir ki” sorusunu duyar oluyorum. Bu makale serisi ile bu sorulara birer birer cevap vereceğim. Eksik cevap verdiklerimi yorum ve mailler ile telafisini yaparız.
Web uygulamamızın güvenliğini sağlamamaız web sitemize zarar gelmemesi, verilerin çalınması hatta silinmemesi için aynı zamanda sitenin kullanıcılarını da rahatsız edebilecek sorunlar oluşturmamak için gerekli önlemleri yerine getirmeliyiz. Ben bu makalemde tüm olumsuzlukları yazacağım ve bunları ayrı ayrı makaleler ile çözüme kavuşturacağım.
1. Uygulamada çıkan hataları değerlendirme
Geliştirdiğimiz web uygulaması dış dünya ile bağlantı kurduğunda oluşacak hataları kullanıcıya göstermek ciddi bir sorundur. Bu yüzden oluşacak her hatayı Log tutmak ve kullanıcıyı bir sayfaya yönlendirmek herkes için en ideal çözümdür. Hatanın nedenini ekrana yazdırmak hackerlara yol göstermektir. Bu yüzden aldığınız hataların detaylarını Log tutarak kendi tarafınızda tutun fakat dış dünyaya bunu açmayınız.
2. İş görür kod yazarak ihtimalleri hesaplamamamk
Web uygulamalarınızda yaptığınız işlemleri iş görürcesine yaptığınızda aslında arkanızda açık bırakmış oluyorsunuz. Arka tarafta String i int e çevirip bunun kontrolünü almamak aslında ciddi sorunlara neden olmaktadır. Gördüğüm deneyimlerle size bunu açıklayacağım. Adana ASKİweb sitesinde parametre olarak alınan ID değerini arka tarafta int e çevirirken alacağı hata için herhangi bir önlem alınmamıştı. Örneğin ID değerine “a” yazdığınızda ASP.Net in o sarı renkli hata sayfası çıkıyor ve hata alan kodu gösteriyordu. Hata alan kodun gösterilmesinden ziyade ASP.Net aldığı hatadaki bir üst satır ve 2 alt satırı da beraberinde göstermektedir. Bundan dolayı çevirme işleminin bir üst satırında tanımlanmış SQLConnection nesnesi ve bu nesneye verilmiş bağlantı cümlesi (ConnectionString) de açık olmasıyıdı. Bir string in int e çevrilme hatası ile bir veritabanı bilgilerini rahatlıkla görebiliyorsunuz. Bu durumdan dolayı bu sitenin saldırı alma olasılığı %99 dur
Aldığınız hatayı Log tutarak hataları gidermek daha iyidir. Makale serimde bunu bire bir yapacağız
3. Session Tokenlardan haberimizin olmayışı
Üyelik sistemli web sitelerimizde yaptığımız işlemlerin Session Token veya anlık doğrulayıcıları olmadığı için oluşturduğumuz ciddi açıklar söz konusu olabiliyor. Bu açık tipine CSRF olarak adlandırılır. Saldırı çeşidinden bahsedersek; tarayıcınızda açık kalmış bir oturumun dışarıdan gelen bir isteğe direk cevap vermesi sonucunda istemsiz işlemler olmasıdır. Örnek olursa eskiden WordPress in bir açığı vardı. Açık şu şekilde işliyor. Web sitenizde WordPress oturumunuz açık bir şekilde kalmış ve gelen bir mailde bir linke tıkladınız. Linkte aslında WordPress e şifre değiştirmesi yapabilen GET parametreleri içeriyor. Açık olan oturumnuz ve token kullanılmadığı için direk işlem gerçekleştirmektedir. Bunu sadece bu şekilde değil, bir web siteye ziyaret ettiğiniz anda bile gerçekleşebilir. JavaScript kodları Client olarak çalışmaktadır. Tarayıcınızdaki kalmış cookies set edilerek yine bu açık tetiklenebilir. Bunların bir çok yolu mevcuttur. İster bir cookies yolu ile isterseniz değişmemiş session token ı ile gerçekleştirilebilir.
4. SQL Injection
Bu açık hala bırakanlar var. Her zaman işleyen bir açıktır. Web uygulamanız üzerinden veritabanınıza erişebilecek bir açıktır. Bunun örneği çoktur. Basit olarak yine Adana ASKİ’nin sitesinde başka bir sayfada parametre olarak alınan bir string tipli değer üzerinden ID alınıyor. Bu ID aslında veritabanına şu şekilde gönderilir. “SELECT * FROM TabloAdi WHERE ID=”+ID olarak gider. Burada ID yerine SQL cümlesini tamamlayabilecek ve üzerine bir şeyler ekleyebileceğiniz anlamına da gelir. Bu durum sonucunda sitede birden fazla sorgu çalıştırabilirsiniz. Bu sorgulardan birisi tablo isimlerini almak olabilir, bu tablo isimlerine göre kolonları almak ve bu kolonlara göre de verileri çekmek olabilir. Yönetim panelinizin bilgileri veritabanında duruyorsa geçmiş olsun
Bu şekilde oluşan açıklar ciddi açıklardır.
5. Şifrelenmemiş Veriler
Web uygulamanızda dışarıdan alınan saldırıda dahi çalınacak verilerin başkaları tarafından okunmamasını sağlamak gerekir. Örnek olursa kullanıcıların şifreleri bu duruma örnektir. Kullanıcıların bilgileri çalınsa da içerisindeki veriler şifrelenmesi durumunda yine de bu bilgilerin zarar verme konusunda pek bir önemliliği olmayacaktır. MD5 Doğrulaması ile kullanıcıların şifrelerinin 32 karakterli Hash lere çevrilmesi sonucunda sadece doğrulama amaçlı kullanılması en iyi tekniğidir. MD5 Hashler geriye döndürülemeyen bir algoritmaya sahiptir. Bu yüzden şifreleme tekniği değil sadece doğrulama tekniğidir. Böylelikle kullanıcılar şifreyi çalsalar da ellerinde aslında geri döndürülemeyecek hash bulunmaktadır. Böylelikle sonuç alınamayacaktır.
6. Her şeye yetki vermeyin
Kompleksli bir web uygulamasında verilerle yapılan işlemleri kısıtlama yaparak işleme tabi tutulmalıdır. Bu kısıtlama şu şekildedir. Veritabanı ile yapacağınız işlemleri farklı yetkilerde ki farklı kullanıcılara yaptırmak daha mantıklıdır. Örnek olarak SELECT sorgularını A kullanıcısı, INSERT işlemlerini B, UPDATE işlemleri C ve DELETE işlemleri için D kullanıcısını yetkilendirin. Böylelikle A kullanıcısı ele geçirilsede veriler sadece okunur hale gelecektir. Aynı zamanda web uygulamalarınızın çalıştığı sunucudaki kullanıcı da tam yetkili değilde gerekli yetkiler verilmesi durumunda çalışmalıdır. Böylelikle uygulamanız üzerinden sunucuya erişim sağlamalarını kesebilirsiniz.
7. Komut çalıştırma
Web uygulamalarınızda SQL Injection dan sebebiyet verebilecek bir diğer açıktır. Bu açık ciddi bir problemdir. Çünkü eğer bu açık mevcut ise uygulamanın bulunduğu sunucu üzerinde çalıştırılacak komutlar ile büyük bir problem oluşturulabilir. Örnek olarak Uzak Masaüstü Bağlantısı için kendisine bir kullanıcı oluşturabilir ve oluşturulan bu kullanıcı ile sunucunuza bağlanabilir, dosyalarınızı çalabilir.
8. Cookies Injection
Cookies değerlerinin alınıp başka bir tarayıcı veya bilgisayardan inject edilip o kullanıcı olarak girilmesi bir açıktır. Kullanıcının Cookies leri çalınıp ki başka JS kodları ile alınması sonucunda bu Cookies lerin girilmesi sonucunda web uygulamasına girilmiş olması ciddi bir açıktır. Böylelikle kullanıcının giriş bilgilerini çalmak yerine Cookieslerini çalmak ile normal kullanıcının işlemlerini yapabilecek konumlara denk gelmektedir.
9. Geliştirici bazlı açıklar
Bu aslında diğer açıklar diye geçiyor. Bazı sitelerde görmüştüm. CSS vs JS dosyasını tek bir dosyadan getirmek için kısaca SEO için yaptığı bir açık vardı. PHP tabanlı bir uygulama ve dosya.php adında bir dosya yazılmış. Bu dosya parametre olarak Base64 ile şifrelenmiş bir dosya yolu alıyor. Burada gelen dosya yoluna css veya js dosyaları yerine index.php ve ona bağlı önemli dosyaların yollarını şifrelenmiş olarak verildiğinde sitenin kodları direk gözükmektedir. Bu aptalca bir açıktır. Başka bir açık olarak da debugging açıklarıdır. Uygulama release olmasına rağmen debugging açık olması sonucunda dışarıdan birisi kodları görebilir ve değişiklik yapabilirler.
Aklıma gelen açıklardan bahsettim ve bundan sonra bu adımları tek tek bir yazı olarak detaylı bir şekilde açıklayacağım. Selametle
Web güvenliği geliştirdiğiniz bir web uygulamasının kötü amaçlı insanlar tarafından suistimal edilmemesi için gereken korumadır. Bu koruma bir developer tarafından yapılabilecek bir korumadır. Web güvenliğini sağlamak için yazdığınız kodu suistimal edebilecek herhangi bir eksiklik dahi bırakmadan yazmaktır. Örnek olursa bir string değeri int e çeviriyorsunuz ve bunun bir sayı yerine karakter gelebileceğini hiç ihtimal etmeden yazdıysanız verecek hatada sizin için ciddi sıkıntılar çıkarabilir. Bu cümleyi okuyanlar “Bir string i int e çevirmek ile ne açık oluşturulabilir ki” sorusunu duyar oluyorum. Bu makale serisi ile bu sorulara birer birer cevap vereceğim. Eksik cevap verdiklerimi yorum ve mailler ile telafisini yaparız.
Web uygulamamızın güvenliğini sağlamamaız web sitemize zarar gelmemesi, verilerin çalınması hatta silinmemesi için aynı zamanda sitenin kullanıcılarını da rahatsız edebilecek sorunlar oluşturmamak için gerekli önlemleri yerine getirmeliyiz. Ben bu makalemde tüm olumsuzlukları yazacağım ve bunları ayrı ayrı makaleler ile çözüme kavuşturacağım.
1. Uygulamada çıkan hataları değerlendirme
Geliştirdiğimiz web uygulaması dış dünya ile bağlantı kurduğunda oluşacak hataları kullanıcıya göstermek ciddi bir sorundur. Bu yüzden oluşacak her hatayı Log tutmak ve kullanıcıyı bir sayfaya yönlendirmek herkes için en ideal çözümdür. Hatanın nedenini ekrana yazdırmak hackerlara yol göstermektir. Bu yüzden aldığınız hataların detaylarını Log tutarak kendi tarafınızda tutun fakat dış dünyaya bunu açmayınız.
2. İş görür kod yazarak ihtimalleri hesaplamamamk
Web uygulamalarınızda yaptığınız işlemleri iş görürcesine yaptığınızda aslında arkanızda açık bırakmış oluyorsunuz. Arka tarafta String i int e çevirip bunun kontrolünü almamak aslında ciddi sorunlara neden olmaktadır. Gördüğüm deneyimlerle size bunu açıklayacağım. Adana ASKİweb sitesinde parametre olarak alınan ID değerini arka tarafta int e çevirirken alacağı hata için herhangi bir önlem alınmamıştı. Örneğin ID değerine “a” yazdığınızda ASP.Net in o sarı renkli hata sayfası çıkıyor ve hata alan kodu gösteriyordu. Hata alan kodun gösterilmesinden ziyade ASP.Net aldığı hatadaki bir üst satır ve 2 alt satırı da beraberinde göstermektedir. Bundan dolayı çevirme işleminin bir üst satırında tanımlanmış SQLConnection nesnesi ve bu nesneye verilmiş bağlantı cümlesi (ConnectionString) de açık olmasıyıdı. Bir string in int e çevrilme hatası ile bir veritabanı bilgilerini rahatlıkla görebiliyorsunuz. Bu durumdan dolayı bu sitenin saldırı alma olasılığı %99 dur
3. Session Tokenlardan haberimizin olmayışı
Üyelik sistemli web sitelerimizde yaptığımız işlemlerin Session Token veya anlık doğrulayıcıları olmadığı için oluşturduğumuz ciddi açıklar söz konusu olabiliyor. Bu açık tipine CSRF olarak adlandırılır. Saldırı çeşidinden bahsedersek; tarayıcınızda açık kalmış bir oturumun dışarıdan gelen bir isteğe direk cevap vermesi sonucunda istemsiz işlemler olmasıdır. Örnek olursa eskiden WordPress in bir açığı vardı. Açık şu şekilde işliyor. Web sitenizde WordPress oturumunuz açık bir şekilde kalmış ve gelen bir mailde bir linke tıkladınız. Linkte aslında WordPress e şifre değiştirmesi yapabilen GET parametreleri içeriyor. Açık olan oturumnuz ve token kullanılmadığı için direk işlem gerçekleştirmektedir. Bunu sadece bu şekilde değil, bir web siteye ziyaret ettiğiniz anda bile gerçekleşebilir. JavaScript kodları Client olarak çalışmaktadır. Tarayıcınızdaki kalmış cookies set edilerek yine bu açık tetiklenebilir. Bunların bir çok yolu mevcuttur. İster bir cookies yolu ile isterseniz değişmemiş session token ı ile gerçekleştirilebilir.
4. SQL Injection
Bu açık hala bırakanlar var. Her zaman işleyen bir açıktır. Web uygulamanız üzerinden veritabanınıza erişebilecek bir açıktır. Bunun örneği çoktur. Basit olarak yine Adana ASKİ’nin sitesinde başka bir sayfada parametre olarak alınan bir string tipli değer üzerinden ID alınıyor. Bu ID aslında veritabanına şu şekilde gönderilir. “SELECT * FROM TabloAdi WHERE ID=”+ID olarak gider. Burada ID yerine SQL cümlesini tamamlayabilecek ve üzerine bir şeyler ekleyebileceğiniz anlamına da gelir. Bu durum sonucunda sitede birden fazla sorgu çalıştırabilirsiniz. Bu sorgulardan birisi tablo isimlerini almak olabilir, bu tablo isimlerine göre kolonları almak ve bu kolonlara göre de verileri çekmek olabilir. Yönetim panelinizin bilgileri veritabanında duruyorsa geçmiş olsun
5. Şifrelenmemiş Veriler
Web uygulamanızda dışarıdan alınan saldırıda dahi çalınacak verilerin başkaları tarafından okunmamasını sağlamak gerekir. Örnek olursa kullanıcıların şifreleri bu duruma örnektir. Kullanıcıların bilgileri çalınsa da içerisindeki veriler şifrelenmesi durumunda yine de bu bilgilerin zarar verme konusunda pek bir önemliliği olmayacaktır. MD5 Doğrulaması ile kullanıcıların şifrelerinin 32 karakterli Hash lere çevrilmesi sonucunda sadece doğrulama amaçlı kullanılması en iyi tekniğidir. MD5 Hashler geriye döndürülemeyen bir algoritmaya sahiptir. Bu yüzden şifreleme tekniği değil sadece doğrulama tekniğidir. Böylelikle kullanıcılar şifreyi çalsalar da ellerinde aslında geri döndürülemeyecek hash bulunmaktadır. Böylelikle sonuç alınamayacaktır.
6. Her şeye yetki vermeyin
Kompleksli bir web uygulamasında verilerle yapılan işlemleri kısıtlama yaparak işleme tabi tutulmalıdır. Bu kısıtlama şu şekildedir. Veritabanı ile yapacağınız işlemleri farklı yetkilerde ki farklı kullanıcılara yaptırmak daha mantıklıdır. Örnek olarak SELECT sorgularını A kullanıcısı, INSERT işlemlerini B, UPDATE işlemleri C ve DELETE işlemleri için D kullanıcısını yetkilendirin. Böylelikle A kullanıcısı ele geçirilsede veriler sadece okunur hale gelecektir. Aynı zamanda web uygulamalarınızın çalıştığı sunucudaki kullanıcı da tam yetkili değilde gerekli yetkiler verilmesi durumunda çalışmalıdır. Böylelikle uygulamanız üzerinden sunucuya erişim sağlamalarını kesebilirsiniz.
7. Komut çalıştırma
Web uygulamalarınızda SQL Injection dan sebebiyet verebilecek bir diğer açıktır. Bu açık ciddi bir problemdir. Çünkü eğer bu açık mevcut ise uygulamanın bulunduğu sunucu üzerinde çalıştırılacak komutlar ile büyük bir problem oluşturulabilir. Örnek olarak Uzak Masaüstü Bağlantısı için kendisine bir kullanıcı oluşturabilir ve oluşturulan bu kullanıcı ile sunucunuza bağlanabilir, dosyalarınızı çalabilir.
8. Cookies Injection
Cookies değerlerinin alınıp başka bir tarayıcı veya bilgisayardan inject edilip o kullanıcı olarak girilmesi bir açıktır. Kullanıcının Cookies leri çalınıp ki başka JS kodları ile alınması sonucunda bu Cookies lerin girilmesi sonucunda web uygulamasına girilmiş olması ciddi bir açıktır. Böylelikle kullanıcının giriş bilgilerini çalmak yerine Cookieslerini çalmak ile normal kullanıcının işlemlerini yapabilecek konumlara denk gelmektedir.
9. Geliştirici bazlı açıklar
Bu aslında diğer açıklar diye geçiyor. Bazı sitelerde görmüştüm. CSS vs JS dosyasını tek bir dosyadan getirmek için kısaca SEO için yaptığı bir açık vardı. PHP tabanlı bir uygulama ve dosya.php adında bir dosya yazılmış. Bu dosya parametre olarak Base64 ile şifrelenmiş bir dosya yolu alıyor. Burada gelen dosya yoluna css veya js dosyaları yerine index.php ve ona bağlı önemli dosyaların yollarını şifrelenmiş olarak verildiğinde sitenin kodları direk gözükmektedir. Bu aptalca bir açıktır. Başka bir açık olarak da debugging açıklarıdır. Uygulama release olmasına rağmen debugging açık olması sonucunda dışarıdan birisi kodları görebilir ve değişiklik yapabilirler.
Aklıma gelen açıklardan bahsettim ve bundan sonra bu adımları tek tek bir yazı olarak detaylı bir şekilde açıklayacağım. Selametle