# SQL enjeksiyonları: nedir, sizi ilgilendirip ilgilendirmediğini nasıl anlarsınız

> Bu, veritabanına doğrudan ulaştığı için online mağazalara karşı en sık istismar edilen açıktır: siparişler, müşteriler, parolalar. İşte bu açığın gereksiz teknik jargon olmadan gerçek tanımı.

- Source canonique : [https://allaux.fr/tr/securite/injections-sql-expliquees](https://allaux.fr/tr/securite/injections-sql-expliquees)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Bir testle değil, sürüm envanteriyle başlayın: çekirdek sürümü, ardından filtre, arama veya adresle parametrelenen bir liste gösteren her modülün sürümü. Bunları yayıncının bültenleriyle karşılaştırın. Sonra barındırma erişim günlüğünü okuyun: hiçbir ziyaretçinin üretemeyeceği bir hızda aynı adrese yinelenen istekler saklanmayı hak eder.

## Gereksiz jargon olmadan ilke

Bir e-ticaret sitesi sürekli olarak veritabanına sorgular oluşturur: bir ürün sayfasını göstermek, bir girişi doğrulamak, bir siparişi kaydetmek. Bu sorgular genellikle ziyaretçinin girdiği bir bilgiyi içerir: adresteki bir ürün kimliği, bir arama terimi veya bir form alanı gibi.

SQL enjeksiyonu, bu bilgi sorguya eklenmeden önce yeterince filtrelenmediğinde ortaya çıkar. Girilen içerik artık basit bir veri olmaktan çıkar: sorgunun anlamını değiştirebilir ve veritabanının, sitenin veya modülün geliştiricisinin öngörmediği bir şey yapmasına neden olabilir.

Bu açığın bu kadar ciddiye alınmasının nedeni budur: doğrudan veritabanına, yani siparişlere, müşteri kayıtlarına ve yapılandırmaya bağlı olarak saklanan parolalara ulaşır.

## Bu sayfanın anlatmadığı şey

> Burada herhangi bir saldırı sözdizimi, çalışan bir istismar örneği veya bir sitede enjeksiyon test etme yöntemi bulamazsınız. Amaç ilkeyi anlamak ve riskinizi kontrol etmektir, bir sızma aracı sağlamak değil.

## Mekanizmayı anlamak için üç gerçek örnek

CVE-2022-36408 (CVE-2022-31181 olarak da anılır), 22 Temmuz 2022'de duyuruldu ve PrestaShop çekirdeğinin 1.6.0.10 ile 1.7.8.6 dahil arasındaki sürümlerini etkiliyordu; 1.7.8.7'den itibaren düzeltilmiştir. Yalnızca mağazanın başka bir yerinde, çekirdekte veya bir modülde bulunan bir SQL enjeksiyonuyla zincirlenerek istismar edilebiliyordu: blockwishlist istek listesi modülünün 2.0.0 ile 2.1.0 arası sürümleri böyle bir enjeksiyon sunuyordu (CVE-2022-31101, 2.1.1'de düzeltildi).

CVE-2024-36680, PrestaShop için premium bir üçüncü taraf Facebook entegrasyon modülü olan pkfacebook'u etkiliyordu. TouchWeb analistleri bunu 3 Mart 2024'te tespit etti: oturum açmamış sıradan bir ziyaretçi tarafından bile istismar edilebiliyordu ve sitede girilen kart bilgilerini ele geçirmeye yönelik kod olan ödeme skimmer'larını yaymak için kullanıldı.

CVE-2024-27956, ValvePress'in "WordPress Automatic" eklentisini etkiliyordu ve 21 Mart 2024'te duyuruldu. Enjeksiyon, kimlik doğrulama sürecinin tam içindeydi ve duyurulduğu andan itibaren siteleri ele geçirmek için aktif olarak istismar edildi.

## Etkilenip etkilenmediğinizi nasıl anlarsınız

1. **Çekirdek sürümünüzü belirleyin** — PrestaShop'ta sürüm bilgisi yönetim panelinde görüntülenir. Modüllerini kontrol etmemiş ve 1.7.8.7 öncesi bir sürümde kalmış bir mağaza, özellikle blockwishlist modülü kuruluysa, gözden geçirilmeyi hak eder.
2. **Kurulu premium modülleri kontrol edin** — Facebook entegrasyonları gibi üçüncü taraf modüller tek tek kontrol edilmelidir: sürümü, yayıncısı ve PrestaShop çekirdek sürümünden bağımsız olarak bilinen bir açığın onu etkileyip etkilemediği.
3. **WordPress otomasyon eklentilerini kontrol edin** — WordPress siteniz içeriği otomatik olarak işleyen WordPress Automatic veya benzer bir eklenti kullanıyorsa, siteyi güncel varsaymadan önce sürümünü yayıncısı üzerinden doğrulayın.
4. **Yalnızca nedeni değil, sonuçları da arayın** — Bilinmeyen bir yönetici hesabı, toplu oluşturulmuş siparişler veya müşteri hesapları ya da şüpheli ödeme verileri, zaten istismar edilmiş bir SQL enjeksiyonunun görünür sonucu olabilir.

## Konuyla ilgili diğer sayfalar

- **Terk edilmiş modüller ve eklentiler** — Bir yama yayınlandıktan sonra bile güncellenmemiş bir modülün neden giriş noktası olarak kalmaya devam ettiği. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Sitemin ele geçirilip geçirilmediğini kontrol etme** — Ücretli bir denetim düşünmeden önce yapılabilecek ücretsiz kontroller. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Ele geçirilmiş site güvenliği ve temizliği** — Mağazanızda bir SQL enjeksiyonu zaten istismar edildiyse tam hizmet. ([/services/securite](/services/securite))

## Riski azaltmak

> Çekirdeği ve modülleri güncel tutmak, sitenin kullandığı veritabanı hesabının yetkilerini gerçekten ihtiyaç duyduğu asgari düzeyle sınırlamak ve yalnızca kimliği belirli yayıncılara ait modülleri kurmak, bu tür açıklara karşı en etkili önlemler olarak kalır.

## FAQ

### SQL enjeksiyonu müşterilerimin parolalarını ifşa edebilir mi?

Parolalar veritabanında yeterince korunmuyorsa evet, ancak çoğu güncel CMS bunları karma (hash) biçiminde saklar, bu da elde edilen verilerin doğrudan kullanımını sınırlar. Diğer bilgiler için risk gerçektir: yapılandırmaya bağlı olarak siparişler, adresler, ödeme verileri.

### Sitemin bu açıklardan biri tarafından zaten etkilenip etkilenmediğini nasıl anlarım?

Sunucu erişim günlüklerini kontrol ederim, normal etkinlik dışında oluşturulmuş yönetici hesaplarının veya siparişlerin varlığını incelerim ve kurulu sürümleri kamuya açık bilinen açıklarla karşılaştırırım.

### Ücretli bir modül ücretsiz bir modülden daha mı güvenlidir?

Otomatik olarak değil. CVE-2024-36680 premium bir modülü etkiliyordu. Önemli olan yayıncının düzeltmeyi ne kadar hızlı yaptığı ve güncellemenin mağazanıza ne kadar hızlı uygulandığıdır.

### Bu tür bir açığa karşı bir web uygulama güvenlik duvarı gerekli midir?

Bir web uygulama güvenlik duvarı bazı girişimleri filtreleyebilir, ancak savunmasız kodun güncellenmesinin yerini asla tutmaz: tamamlayıcı bir korumadır, tek başına bir çözüm değildir.

### Bahsedilen açıklardan biri tarafından etkilendiğimi fark edersem ne yapmalıyım?

İlgili modülü veya çekirdeği hemen güncelleyin, ardından güncellemeden önce bir istismarın gerçekleşip gerçekleşmediğini kontrol edin; bu da veritabanının ve sunucu dosyalarının incelenmesini gerektirir.