yoklateknik mülakat
GelişimGeçmiş

Veritabanı Security Access Mülakat Soruları

75 doğrulanmış Veritabanı Security Access mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Security AccessZorluk 1
SQL injection nedir?
  • aVeritabanının, SQL sözdizimi geçersiz olduğu için bir sorguyu reddetmesi
  • bSaldırganın veritabanı sunucusunu çok sayıda eşzamanlı açık bağlantıyla boğması
  • cSaldırganın, doğrulanmamış input üzerinden SQL sızdırarak bir sorgunun anlamını değiştirmesi✓
  • dFiltrelenen bir kolonda index olmadığı için sorgunun yavaş çalışması
Açıklama:SQL injection, güvenilmeyen input bir SQL string'ine birleştirildiğinde oluşur; input bir değer gibi ele alınmak yerine sorgunun yapısını değiştirebilir (koşul ekler, ek statement çalıştırır). (b) bir denial-of-service / bağlantı taşkınını, (d) bir performans sorununu tarif eder; hiçbiri sorgu mantığını değiştirmez.
Security AccessZorluk 2
Bir uygulama placeholder'lı bir sorgu çalıştırıyor ve değeri ayrı olarak bind ediyor:
-- SQL metni (bir kez gönderilip parse edilir):
SELECT * FROM users WHERE email = ?;
-- değer ayrı olarak, veri olarak verilir:
bind(1, '[email protected]')

Değeri SQL metnine birleştirmek yerine parametre olarak bind etmek SQL injection'ı neden önler?
  • aVeritabanı, bağlı her parametre değerini saklamadan veya karşılaştırmadan önce otomatik olarak şifreler
  • bStatement placeholder ile parse edilir; böylece değer yalnızca veri olarak kullanılabilir, SQL olarak değil✓
  • cBağlı parametre değerleri sabit bir uzunlukla sınırlıdır ve bu uzun injection payload'larını engeller
  • dVeritabanı her parametreyi dikkatle tarar ve SQL keyword içeren her değeri otomatik olarak reddeder
Açıklama:Parameterized (prepared) statement'ta placeholder içeren SQL metni önce parse edilip planlanır; verilen değer sonra yalnızca veri olarak bind edilir ve asla yeniden SQL olarak parse edilmez, dolayısıyla koşul ya da statement ekleyemez. Şifreleme (a) ve keyword engelleme (d) mekanizma değildir — meşru bir değer 'OR' kelimesini veya tırnak içerebilir ve yine de veri olarak kabul edilmelidir. Uzunluk sınırı (c) ise ilgisizdir.
Security AccessZorluk 3
Bir login kontrolü sorgusunu form input'unu birleştirerek kuruyor:
SELECT * FROM users WHERE username = '<input>' AND password = '<input>';

Saldırgan username olarak ' OR '1'='1' -- gönderiyor. Olası sonuç nedir?
  • aSorgu sözdizimi hatası verir ve login denemesi güvenli şekilde reddedilir
  • bYalnızca birebir ' OR '1'='1' adlı kullanıcı eşleşir, dolayısıyla hiçbir satır dönmez
  • cInput tek tırnak içerdiği için veritabanı isteği otomatik olarak engeller
  • dWHERE her zaman true olur ve -- password kontrolünü comment'ler; login bypass edilir✓
Açıklama:Enjekte edilen ' username string'ini kapatır, OR '1'='1' koşulu her zaman true yapar ve -- geri kalanı (password kontrolünü) comment'ler. Sorgu satır döndürür — genelde ilk/admin kullanıcı — ve authentication bypass edilir. Veritabanları tırnağı kendiliğinden reddetmez (c); enjekte edildikten sonra input geçerli SQL'dir, sözdizimi hatası olmaz (a).
Security AccessZorluk 1
Least privilege ilkesine göre, bir production uygulamasının veritabanı hesabında hangi privilege'lar olmalıdır?
  • aYalnızca normal işlemlerinin gerektirdiği belirli privilege'lar, fazlası değil✓
  • bTam superuser hakları; böylece eksik bir permission hiçbir isteği bozamaz
  • cHer tablo üzerinde her privilege, ama yalnızca mesai saatlerinde
  • dUygulamayı yazan geliştiricilerle birebir aynı privilege'lar
Açıklama:Least privilege, bir bileşene yalnızca işini yapması için gereken izinleri vermektir; böylece bileşen ele geçirilir ya da bir bug'ı olursa hasar sınırlı kalır. Superuser bir app hesabı (b), herhangi bir SQL injection veya mantık hatasını tüm veritabanının kontrolüne dönüştürür. Zamana bağlı (c) veya geliştiriciyle eşit (d) grant'lar least privilege demek değildir.
Security AccessZorluk 1
GRANT SELECT ON orders TO reporting; ne yapar?
  • aorders tablosunun ownership'ini reporting rolüne devreder
  • breporting rolünün orders'taki satırları okumasına izin verir ama değiştirmesine izin vermez✓
  • creporting rolüne orders tablosunun tamamında hem tam okuma hem tam yazma erişimi verir
  • dorders tablosunun satırlarını reporting'e ait yeni bir tabloya kopyalar
Açıklama:SELECT okuma privilege'ıdır; GRANT SELECT grantee'nin tabloyu sorgulamasına izin verir ama INSERT/UPDATE/DELETE vermez (yani (c) değil). Ownership'i (a) değiştirmez, veriyi kopyalamaz (d) — ownership ve DDL, veri erişim privilege'larından ayrıdır.
Security AccessZorluk 2
Bir hesabın payments üzerinde SELECT ve INSERT'i var. Şu çalıştırıldıktan sonra:
REVOKE INSERT ON payments FROM app_user;

app_user payments üzerinde hâlâ ne yapabilir?
  • aHiçbir şey, çünkü REVOKE hesabın tablodaki tüm privilege'larını kaldırır
  • bHem SELECT hem INSERT, çünkü REVOKE ancak sunucu restart olunca uygulanır
  • cYalnızca SELECT — INSERT kaldırılır, önceden verilen SELECT kalır✓
  • dYalnızca INSERT, çünkü REVOKE her zaman en son verilen privilege'ı korur
Açıklama:REVOKE tam olarak adı geçen privilege'ı (INSERT) kaldırır; dokunulmayan SELECT grant'ı kalır, dolayısıyla hesap hâlâ okuyabilir ama artık insert edemez. REVOKE anında etkilidir (restart gerekmez, (b) yanlış) ve yalnızca listelediğin privilege'ları etkiler ((a) ve (d) yanlış).

Uzmanlığa göre

MongoDB 450MySQL 450PostgreSQL 450Redis 450

Kıdeme göre

Veritabanı JuniorVeritabanı MidVeritabanı Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudAI EngineerMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2475 soruluk Veritabanı bankasında kendini sına.

Mülakata başla