Python - Sqlite3 Zaafiyetleri

Merhaba,

Programlarımızı hazırlarken database için en basit yöntem olan sqlite3 kullanıyoruz. (json hariç) İnternette araştırmalar yaparken buradaki kaynaktan öğrendiğim bilgiler beni şaşırttı.

Kullanıcıların giriş yapacağı bir panel ve veri tabanı tasarladığımız zaman, kullanıcılar isim ve şifre ile veri tabanına istek attıkları yapılan doğrulama kontrolü ve geri dönen cevap ile eşleşen uyumluluk doğrultusunda programı kullanmaya devam edebiliyoruz.

Fakat bir zafiyeti olduğunu öğrendim. Kullanıcı girişi yaparken, istenen tüm bilgiler için belirtilen girdi kısımlarına eğer blabla' OR '7' = '7 yazarsak, veri tabanına gönderilen sorguda bu giriş sayesinde doğrulama işlemi bypass ediliyor ve programa en yetkili kişi hesabından giriş yapmış gibi devam edebiliyorsunuz.

Detaylar ve daha fazlası için konunun kaynağını lütfen inceleyin.

https://www.hasanbaskin.com/python-veritabani-programlama/

4 Beğeni

Bu açığı istismar eden araçlardan birisi: https://sqlmap.org/

6 Beğeni

Zaafiyet kodda, SQLite ile alakali degil.

4 Beğeni

Bu Sqlite’a özgü bir durum değil. Tüm SQL sürümleri için benzer durumlar söz konusu. Hatta SQL injection temel siber güvenlik eğitimlerinde dahi anlatılagelen bir konudur.

Tabi ki korunma yolları da var. En kolayı, sorguyu doğrudan SQL e göndermek yerien önce işleyip, doğru ve güvenilir ise sorguyu yapacak şekilde kodu düzenlemektir.

SQL Injection Prevention - OWASP Cheat Sheet Series

How to Prevent SQL Injection Attacks in 2022 | eSecurity Planet

Daha da kötüsünü söyleyeyim. Bu açıkların bir kısmı bilinir olup yamalarla düzeltilebilirken, bir kısmı ise henüz yamanmadığı için açık devam etmektedir.

Zero day atakları olarak bilinen bir durumdur. Yani açık bilinir ama henüz yaması hazırlanmadığından açık devam eder. Ve patch yada update gelene kadar korumasız kalırsınız.

Bunun için sürekli siber güvenlik bültenlerini takip etmek, antivirüs firmalarının bullettin boardlarını takip etmek zorundasınız.

Yetmez ama ilk olarak daha önce de belirttiğim gibi, paneller doğrudan sorgu göndermemeli, önce alınan sorgular işlenerek güvenilirliği kontrol edilmeli sonrasında sorgu işlemi yapılmalıdır.

Güvenliğin bir sınırı yok, birileri güvenlik artırırken birileri de güvenliği ihlal ile ilgili elinden geleni yapacaktır.

Her oto sanayide bir yerli araç yapan vardır. Adama NCAP ne desen bilmez ne var benim de arabam çalışıyor diyebilir.

Veri tabanı konusu da böyle bir şey. Sorsak herkes sql programcısı ama güvenli sql programlama nasıl olmalıdır desek bilmeyebiliyor.

6 Beğeni

Buradaki sorun yazılımcının sorguyu yanlış yazmış olması.

Bunlardan kurtulmak için başta web geliştiriciler olmak üzere ORM kullanıyoruz.

Buradaki sorun yazılımcının sorguyu yanlış yazması değil gibi, sorun bu sorguyu yaparak kötü niyetli birinin sisteme sızabileceği gerçeğidir. Panellerinizi doğrudan sql sorguları yapar hale getirirseniz başkası bu şekilde bir sorgu yaparsa olacak olan şeyden bahsediyor.

Yoksa neden bir yazılımcı kasıtlı olarak bunu kendi kodunda yapsın?

Bu nedenle zaten sorguları doğrudan panelde yapmayın önerisinde bulundum.

Burada kullanım amacı daha ziyade farklı veri tabanlarına ortak arayüz oluşturmak gibi göründü, ama kullanılan arayüz de başka açıklara neden olabilir. Yani özel bir güvenlik filtrelemesi yoksa, sorguyu kendi ilgili veritabanına iletirken de aynı şekilde açığa neden olabilir. Hatta sql injection yaparken bu kod üzerinden geçerken güvenlik duvarının atlatılmasına bile neden olabilir.

En basiti, geçersiz sorguları veri tabanına göndermemek. Geçersizliğine karar vermek için de bazı kurallar koymak yeterli.

Bu gün canım istedi hadi bir ORM injection yapayım dese, mesela Java için hibernate…

Exploiting Hibernate Injections (sonarsource.com)

Sonuçta aynı noktaya geliriz.

Panelde doğrudan sql sorgusu yapmayınız. Soyutlasanız da soyutlamasanız da sorguya göndereceğiniz komutları kontrol ettikten sonra gönderiniz.

Konu bu kadar basit.

4 Beğeni