Kayıt Formu Tasarımında Business Logic ve Güvenlik Kontrolleri

Kayıt formu validasyonu, yalnızca e-posta biçimini veya zorunlu alanları denetlemekten daha geniş bir akış olarak tasarlanmalıdır. Business logic kontrolleri; veri kabulü, biçim doğrulama, normalizasyon, iş kuralları, güvenlik kontrolleri, veritabanı bütünlüğü ve güvenli yanıt adımlarını birlikte kapsar.

Client tarafı hızlı geri bildirim sağlar, ancak güvenlik sınırı değildir. Server tarafı her isteği yeniden değerlendirir, database katmanı ise uygulama hatalarına karşı son veri bütünlüğü savunmasını oluşturur.

Kayıt formunda business kontrolleri hangi sırayla tasarlanmalı?

Uygulanabilir bir tasarım sırası, kontrollerin birbirinin görevini üstlenmesini önler ve hatanın hangi aşamada üretildiğini görünür kılar:

1. Veri kabulü: İstek gövdesini ayrıştır, beklenen alanları allowlist ile sınırla ve bozuk istekleri reddet.
2. Biçim doğrulama: Zorunlu alanları, veri tiplerini, temel uzunluk ve yapı koşullarını denetle.
3. Normalizasyon: Boşlukları ve kimlik karşılaştırmalarını etkileyen biçim farklarını alan politikasına göre düzelt.
4. Business kuralları: Yaş sınırı, yasaklı e-posta alan adı, kullanıcı adı kara listesi ve hesap koşullarını uygula.
5. Güvenlik kontrolleri: CSRF, rate limiting, güvenli hata üretimi ve parametreli sorgu kullanımını devreye al.
6. Veritabanı bütünlüğü: Tekillik, veri tipi, zorunlu alan ve transaction kısıtlarını çalıştır.
7. Güvenli yanıt: Kullanıcıya uygulanabilir hata ver, şifreyi veya dahili sistem ayrıntılarını yanıt ve loglara taşıma.

Bu sıralama katı bir işlem zinciri olmak zorunda değildir. Bazı kontroller paralel yürüyebilir; önemli olan, güvenilmeyen verinin server tarafından yeniden değerlendirilmesi ve kalıcılaştırmadan önce database kısıtlarına takılmasıdır.

Client, server ve database kontrolleri nasıl paylaştırılır?

Katmanlı validasyon kontrol listesinde client kullanılabilirlikten, server güvenilirlikten, database ise kalıcı verinin tutarlılığından sorumludur. Öncelik sırası, önce isteğin yapısını ve türlerini, ardından alanları, iş kurallarını, güvenliği ve son olarak kalıcılaştırmayı kapsamalıdır.

1. İsteği tanı: Alan adlarını, veri tiplerini ve beklenmeyen parametreleri denetle.
2. Alanları doğrula: Zorunlu alan, biçim ve normalizasyon kontrollerini uygula.
3. İş kurallarını uygula: Kararı server tarafında ver; client sonucuna güvenme.
4. Yazma işlemini koru: Güvenlik kontrollerini ve transaction akışını tamamla.
5. Sonucu güvenli döndür: Hataları anlaşılır, teknik ayrıntıları sınırlı tut.

Client tarafındaki kontrol kaldırıldığında sistem yalnızca daha az kullanışlı hâle gelmelidir, daha az güvenli hâle değil. Güvenlik kararı server tarafında verilir; database kısıtları da uygulama kodundaki yarış koşullarını ve unutulan kontrolleri tamamlar.

Girdi doğrulama, temizleme ve iş kuralları nasıl birlikte uygulanır?

Doğrulama, temizleme ve business kuralları aynı işlem değildir. Doğrulama verinin kabul edilebilir olup olmadığını inceler, normalizasyon karşılaştırmayı tutarlı hâle getirir, iş kuralları ise kabul edilen değerin uygulama bağlamında kullanılabilir olup olmadığını belirler.

• E-posta: Boşlukları temizle, temel yapıyı kontrol et ve gerekiyorsa sahiplik doğrulaması kullan. Aşırı karmaşık regex, geçerli adresleri gereksiz yere dışlayabilir.
• Telefon: Ülke bilgisini dikkate al ve değeri tek bir kanonik biçimde sakla. Telefonu yalnızca sayı gibi ele almak, baştaki artı işareti veya ülke kodu gibi bilgileri bozabilir.
• Şifre: Server tarafındaki politikayı uygula; şifreyi trim etme, küçük harfe çevirme, loglama veya client tarafında hashleyerek güvenlik sağladığını varsayma.

E-posta ve kullanıcı adı için aynı kanonikleştirme politikası kullanılmak zorunda değildir. E-posta için uygulamanın kimlik politikasına göre baştaki ve sondaki boşluklar temizlenebilir, alan adı küçük harfe dönüştürülebilir veya uygulama bütün adresi büyük-küçük harfe duyarsız kabul edebilir. Nokta ya da artı etiketi silme gibi sağlayıcıya özgü dönüşümler açıkça tanımlanmadıkça uygulanmamalıdır.

Kullanıcı adı için boşluk temizleme, Unicode kurallarını belirleme, izin verilen karakterleri seçme ve büyük-küçük harf duyarlılığını kararlaştırma gerekir. Bu politika, tekillik kontrolünden ve kara liste karşılaştırmasından önce uygulanmalıdır.

1. Değeri ayrıştır ve alan politikasına göre normalize et.
2. Biçim ve veri tipi kontrollerini uygula.
3. Yapılandırılabilir yaş sınırı, yasaklı e-posta alan adı ve kullanıcı adı kara listesini değerlendir.
4. Alan hatalarını güvenli biçimde döndür; geçerli isteklerde şifreyi dönüştürmeden hashleme aşamasına aktar.

Yasaklı alan adları ve kullanıcı adı listeleri kodun farklı yerlerine dağılmak yerine yönetilebilir bir yapılandırmada tutulmalı, karşılaştırma öncesi aynı kanonikleştirme işleminden geçirilmeli ve değişiklikleri test edilmelidir. Girdi temizlemek de veriyi otomatik olarak güvenli yapmaz. XSS korumasında asıl karar, verinin gösterildiği HTML, JavaScript, URL veya başka bağlama uygun çıktı kodlamasıdır.

Kanonikleştirme ve temel kontrol örneği

Aşağıdaki Python örneği, e-posta ile kullanıcı adını ayrı değişkenlerde normalize eder ve şifreyi dönüştürmeden yalnızca boşluk kontrolü yapar:

import re

EMAIL_SHAPE = re.compile(r"^[^@s]+@[^@s]+.[^@s]+$")

def check_registration(email, username, password, blocked_users):
    email = email.strip().casefold()
    username = username.strip().casefold()
    blocked_users = {item.casefold() for item in blocked_users}
    errors = []

    if not EMAIL_SHAPE.fullmatch(email):
        errors.append("E-posta biçimi geçersiz.")
    if username in blocked_users:
        errors.append("Kullanıcı adı kullanılamaz.")
    if password == "":
        errors.append("Şifre boş olamaz.")

    return email, username, errors

print(check_registration(" [email protected] ", " Admin ", "Gizli", {"admin"}))

Beklenen çıktı: ('[email protected]', 'admin', ['Kullanıcı adı kullanılamaz.']). Regex burada yalnızca temel yapı kontrolüdür; adresin gerçekten kullanılabildiğini kanıtlamaz.

Aynı yaklaşım Java ile de uygulanabilir:

import java.util.*;
import java.util.regex.Pattern;

public class RegisterCheck {
    private static final Pattern EMAIL_SHAPE =
        Pattern.compile("^[^@\s]+@[^@\s]+\.[^@\s]+$");

    public static void main(String[] args) {
        String email = " [email protected] ".trim().toLowerCase(Locale.ROOT);
        String username = " Admin ".trim().toLowerCase(Locale.ROOT);
        String password = "Gizli";
        Set<String> blockedUsers =
            new HashSet<>(Arrays.asList("admin"));
        List<String> errors = new ArrayList<>();

        if (!EMAIL_SHAPE.matcher(email).matches()) {
            errors.add("E-posta biçimi geçersiz.");
        }
        if (blockedUsers.contains(username)) {
            errors.add("Kullanıcı adı kullanılamaz.");
        }
        if (password.isEmpty()) {
            errors.add("Şifre boş olamaz.");
        }

        System.out.println(email + " | " + username + " | " + errors);
    }
}

Beklenen çıktı: [email protected] | admin | [Kullanıcı adı kullanılamaz.]. Gerçek uygulamada kabul kararı bu temel kontrollerin yanı sıra server tarafındaki şifre politikası, iş kuralları ve database kısıtlarıyla birlikte verilmelidir.

E-posta ve kullanıcı adı benzersizliği nasıl güvence altına alınır?

E-posta ve kullanıcı adı benzersizliği iki katmanda kurulmalıdır. Sunucu, formdan gelen değeri belirlenen kanonik biçime dönüştürüp uygulama seviyesinde ön kontrol yapar. Veritabanı ise aynı kanonik değer üzerinde UNIQUE kısıtı veya eşdeğer bir bütünlük kuralı uygular. Uygulama kontrolü kullanıcıya hızlı geri bildirim verir, veritabanı kuralı son veri bütünlüğünü korur.

Normalleştirme kuralları baştan belirlenmelidir. Boşlukların ele alınması, büyük ve küçük harf davranışı, Unicode normalizasyonu ve kullanıcı adı karakterleri gibi kararlar tek bir fonksiyonda toplanmalıdır. Örneğin email_key ve username_key değerleri oluşturulduktan sonra hem ön kontrol sorgusunda hem de kayıt işleminde aynı değerler kullanılmalıdır. Kontrol sırasında başka, kayıt sırasında başka bir dönüşüm uygulanması tutarsızlık üretir.

Yalnızca “bu değer daha önce kullanılmış mı?” sorgusuna güvenmek race condition oluşturabilir. İki istek aynı anda geldiğinde istek A veritabanında değer bulamaz, istek B de aynı anda değer bulamaz. Her iki istek de kontrolü geçip kayıt eklemeye çalışır. UNIQUE kısıtı yoksa iki kayıt da oluşabilir. Kısıt varsa veritabanı isteklerden birini kabul eder, diğerini benzersizlik ihlali olarak sonuçlandırır.

Kanonik değerlerin hazırlanması, ilgili iş kurallarının uygulanması ve kayıt işlemi uygun bir transaction sınırında yürütülmelidir. Duplicate kayıt hatası beklenebilir bir iş akışı olarak yakalanmalı, transaction geri alınmalı ve veritabanının hata ayrıntısı kullanıcıya gönderilmemelidir. Herkese açık kayıt ekranında “bu e-posta zaten kayıtlı” gibi bir yanıt yerine “Kayıt işlemi tamamlanamadı. E-posta adresini veya kullanıcı adını kontrol edip tekrar dene.” gibi hesap varlığını gereksiz biçimde açıklamayan bir yanıt tercih edilebilir. Biçim hataları ise alan bazında açıkça gösterilebilir.

SQL injection, XSS, CSRF ve rate limiting nasıl önlenir?

Bu dört riskin ortak çözümü, kontrolü doğru katmana yerleştirmektir. İstemci tarafındaki kontroller kullanıcı deneyimini iyileştirir ancak güvenlik kararı sunucuda verilmelidir. SQL sorguları parametrelenmeli, XSS için çıktı bağlama uygun biçimde kodlanmalı, durum değiştiren istekler CSRF kontrolünden geçmeli ve kayıt uç noktası birden fazla anahtarla hız sınırlandırılmalıdır.

SQL injection denemesinde kullanılan ' OR '1'='1 değeri, parametreli sorguda SQL komutu değil, aranacak metnin kendisi olur. XSS testinde kullanılan <script>alert(1)</script> ise güvenli uygulamada çalıştırılmak yerine sayfada metin olarak gösterilmelidir.

import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE users (email TEXT UNIQUE)")

value = "' OR '1'='1"
conn.execute("INSERT INTO users (email) VALUES (?)", (value,))
row = conn.execute(
    "SELECT email FROM users WHERE email = ?", (value,)
).fetchone()

print(row[0])

Python örneğinde ? yer tutucusu ile değer sorgu metninden ayrılır. Beklenen çıktı ' OR '1'='1 değerinin aynısıdır; bu içerik sorgunun yapısını değiştirmez. Python'un sqlite3 arayüzü parametre değerlerinin sorguya ayrı verilmesini destekler.

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class SafeLookup {
    static String findEmail(Connection connection, String value)
            throws SQLException {
        String sql = "SELECT email FROM users WHERE email = ?";

        try (PreparedStatement statement =
                     connection.prepareStatement(sql)) {
            statement.setString(1, value);

            try (ResultSet result = statement.executeQuery()) {
                return result.next()
                        ? result.getString("email")
                        : null;
            }
        }
    }
}

Java örneğinde setString, gelen değeri SQL sözdiziminden ayrı bir parametre olarak gönderir. Kullanıcı tom' OR '1'='1 girerse yalnızca bu ifadenin tamamıyla eşleşen bir kayıt aranır. PreparedStatement, istemciden gelen verinin sorgunun parçası olarak yorumlanmasını engelleyen JDBC yaklaşımıdır.

Şifre politikası, hata mesajları ve CAPTCHA nasıl dengelenir?

Şifre politikası uzunluk, yaygın veya ele geçirilmiş parolaları engelleme ve kullanıcı deneyimi arasında kurulmalıdır. Asgari uzunluk belirlenmeli, yaygın parola listesi kullanılmalı ve keyfi biçimde büyük harf, rakam ve sembol kombinasyonu zorunlu tutulmamalıdır. Karakter çeşitliliği ancak uygulamanın risk modeli bunu gerçekten gerektiriyorsa eklenmelidir. Şifrelerin sessizce kısaltılması veya düz metin olarak saklanması doğru değildir.

Sunucu, parolayı parola saklama amacıyla tasarlanmış uyarlanabilir bir yöntemle ve her kayıt için benzersiz salt kullanarak hashlemelidir. Argon2id, scrypt ve bcrypt arasında seçim yaparken yalnızca algoritma adına değil, güvenlik özelliklerine, kütüphane desteğine, bakım durumuna ve doğrulama maliyetine bakılmalıdır. OWASP rehberinde Argon2id öne çıkan seçenek olarak ele alınırken scrypt alternatif, bcrypt ise özellikle eski sistemlerle uyumluluk bağlamında değerlendirilir. Python tarafında argon2-cffi içindeki PasswordHasher sınıfı hash, verify ve yeniden hash gereksinimini kontrol etme akışları sunar. Java'da bakımı yapılan bir parola kütüphanesinin PasswordEncoder arayüzündeki encode ve matches yöntemleri kullanılabilir.

Hata mesajı alan biçimini düzeltmeye yardımcı olmalı, fakat hesap varlığını gereksiz yere açığa çıkarmamalıdır. Eksik alan, hatalı e-posta biçimi veya engellenen parola için açıklayıcı geri bildirim verilebilir. E-posta ya da kullanıcı adı zaten kullanılıyorsa herkese açık kayıtta genel bir sonuç döndürmek, bu bilgilerin hesap yoklama amacıyla kullanılmasını zorlaştırır.

CAPTCHA, rate limiting'in yerine geçen temel kontrol değil, tekrarlanan veya şüpheli otomasyon belirtilerinde devreye alınabilecek ek bir katmandır. Her kullanıcıya zorunlu görsel bulmaca göstermek yerine önce hız sınırı, oturum sinyalleri ve davranış kontrolleri uygulanmalıdır. CAPTCHA kullanılıyorsa erişilebilir bir alternatif ve mümkünse bilişsel yükü daha düşük bir doğrulama yolu sunulmalıdır.

KVKK ve GDPR için kayıt verileri nasıl sınırlandırılır?

Bu bölüm hukuki görüş değil, mevzuat ilkelerinin teknik tasarıma yansımasıdır. Kayıt formu yalnızca hesabı açmak ve hizmeti yürütmek için gerekli alanları toplamalı; ileride kullanılabilir düşüncesiyle doğum tarihi, telefon veya profil bilgisi eklenmemelidir.

KVKK, verilerin belirli ve meşru amaçlarla, amaçla bağlantılı, sınırlı ve ölçülü işlenmesini; GDPR ise buna ek olarak doğruluk, saklama süresi ve bütünlük ile gizlilik ilkelerini birlikte ele alır. Bu nedenle her alanın amacı, saklama ölçütü ve erişim kapsamı tasarım aşamasında belirlenmelidir.

Alan, amaç ve yaşam döngüsü veri modelinde ayrı olsun

Hesap verilerini tek bir onay alanına sıkıştırmak yerine, verinin amacıyla birlikte saklandığı bir model kurabilirsin:

• Hesap tablosu: Gerekli kullanıcı adı, kanonik e-posta, parola özeti ve hesap durumunu tutar.
• Aydınlatma gösterim kaydı: Sunulan metnin sürümünü, gösterim zamanını ve kanalı saklar.
• Rıza kaydı: Her amaç için ayrı durum, metin sürümü, zaman ve varsa geri çekilme bilgisini tutar.
• İletişim tercihleri: Hesap işlemleri ile isteğe bağlı iletişim veya pazarlama tercihlerini birbirinden ayırır.

KVKK açısından aydınlatma yükümlülüğü, veri işleme hangi şarta dayanırsa dayansın devam eder. Açık rıza gerekiyorsa aydınlatma metniyle aynı kutuda, tek bir genel onay olarak tutulmamalıdır. Rıza geri çekildiğinde ilgili amaç durdurulmalı, hesabın başka bir amaç için işlenmesi gerekiyorsa bu süreç ayrı değerlendirilmelidir.

• Her alan için amaç, işleme dayanağı, saklama ölçütü, silme davranışı ve erişebilecek rol tanımlanır.
• Erişim, düzeltme ve silme talepleri için bağlı tabloları bulabilen merkezi bir veri envanteri oluşturulur.
• Loglara parola, erişim token'ı, doğrulama kodu ve gereksiz kişisel veriler yazılmaz.
• Destek, operasyon ve yönetim erişimleri en az yetki ilkesiyle ayrılır; erişim olayları hassas veri içermeden izlenir.

Silme veya düzeltme işlemi, yalnızca ana kullanıcı kaydını değiştirmekle bitmemelidir. Kopyalar, iletişim tercihleri ve ilişkili kayıtlar da tanımlı saklama ve silme kurallarına göre ele alınmalıdır. KVKK ve GDPR, ilgili kişilere erişim, düzeltme ve silme gibi haklar tanıdığı için bu işlemleri sonradan eklenen manuel operasyonlara bırakmayan bir veri modeli tercih edilmelidir.

Bir kayıt isteği uçtan uca nasıl kontrol edilir?

Güvenli akışta client hızlı geri bildirim verir, server doğrulama ve business logic kararını verir, database ise benzersizlik ve bütünlük için son güvenlik katmanı olur.

1. Client geri bildirimi: Boş alan, biçim ve parola kuralları kullanıcıya erken gösterilir. Bu katman yalnızca kullanım kolaylığı sağlar.
2. Server'a alma: İçerik türü, veri tipi, istek gövdesi boyutu ve alan uzunlukları kontrol edilir. Beklenmeyen alanlar reddedilebilir.
3. CSRF, bot ve rate limiting: CSRF token'ı, oturum bağlamı ve tekrarlanan istek sinyalleri kontrol edilir. Rate limit'e takılan istek veritabanına gönderilmez.
4. Trim ve kanonikleştirme: Kullanıcı adı ve e-posta, uygulamanın önceden belirlediği kurallarla normalize edilir. Örneğin mevcut kullanıcı adı ada iken Ada girdisi trim ve küçük harf dönüşümünden sonra aynı değere çakışır.
5. Alan doğrulama: E-posta, varsa telefon, parola ve diğer alanların biçimi kontrol edilir. İstemcinin gönderdiği doğrulama sonucu kabul edilmez.
6. Business logic: Yaş, alan adı, kullanıcı adı ve hesap türü kuralları uygulanır. Geçersiz iş kuralında akış burada durur, parola hash'lenmez ve kayıt açılmaz.
7. Parola hashleme: Parola, yalnızca parolalar için tasarlanmış bir hashleme işleviyle işlenir. Ham parola veritabanına veya loglara yazılmaz.
8. Transaction ve unique kontrolü: Kanonik e-posta ve kullanıcı adı için database unique kısıtları çalışır. Önceden yapılan SELECT kontrolü yardımcı olabilir, ancak tek başına yeterli değildir.
9. Yanıt ve loglama: Duplicate, geçersiz istek ve rate-limited durumları güvenli mesajlarla ayrılır. Yanıtta başka bir hesabın varlığı, token veya parola gibi bilgiler açıklanmaz; loga yalnızca olay türü, korelasyon kimliği ve güvenli hata kategorisi yazılır.

Aynı kanonikleştirme kuralı server'ın tüm servislerinde uygulanmalıdır. Uygulamanın kullanıcı adı politikası dış boşlukları temizleyip küçük harfe dönüştürüyorsa, basit bir örnek şöyledir:

def canonical_username(value):
    return value.strip().lower()

print(canonical_username("  Ada  "))

Beklenen çıktı ada olur. Java tarafındaki karşılığı da aynı davranışı üretmelidir:

import java.util.Locale;

public class Main {
    static String canonicalUsername(String value) {
        return value.trim().toLowerCase(Locale.ROOT);
    }

    public static void main(String[] args) {
        System.out.println(canonicalUsername("  Ada  "));
    }
}

İki istek aynı anda geldiğinde ikisi de ön kontrolden geçebilir. Transaction içindeki unique kısıt nedeniyle yalnızca biri başarılı olur; diğerinin veritabanı hatası kontrollü biçimde duplicate yanıtına çevrilir. Böylece yarış durumu, yalnızca uygulama kodundaki ön sorguya bırakılmaz.

Kısa test listesi

• Geçerli: Bir hesap açılır, parola özeti kaydedilir ve hassas veri loglanmaz.
• Reddedilen: Geçersiz CSRF, veri tipi veya business kuralında database kaydı oluşmaz.
• Duplicate: Aynı kanonik e-posta, kullanıcı adı ve eşzamanlı iki istek senaryoları test edilir.
• Rate-limited: Tekrarlanan istekler hashleme ve kayıt işleminden önce kontrollü biçimde durdurulur.

Sık Sorulan Sorular

Client-side validasyon tek başına yeterli midir?

Hayır. Client-side kontroller kullanıcı deneyimini iyileştirir, ancak istekler doğrudan server'a gönderilebilir. Güvenlik, business logic ve veri bütünlüğü kontrolleri server ve database katmanlarında yeniden uygulanmalıdır.

E-posta ve kullanıcı adı benzersizliği race condition sorununa karşı nasıl korunur?

Değerleri server'da aynı kuralla kanonikleştir, database üzerinde unique kısıt oluştur ve ekleme işlemini transaction içinde yap. Ön sorgu iki isteği aynı anda başarılı sanabilir; son kararı unique kısıt vermelidir.

Kayıt formunda CAPTCHA ne zaman kullanılmalıdır?

CAPTCHA, her kullanıcı için ilk engel olmak zorunda değildir. Rate limiting, CSRF ve istek davranışı kontrollerinden sonra tekrarlanan veya şüpheli denemelerde ek bir doğrulama olarak devreye alınabilir. Tek başına abuse kontrolü yerine geçmez.

Şifre saklamak için genel amaçlı hash fonksiyonu kullanılabilir mi?

Genellikle hayır. Hızlı genel amaçlı özet fonksiyonları parola saklama için uygun tasarlanmamıştır. Parolalar, salt ve ayarlanabilir maliyet desteği bulunan, parolalar için tasarlanmış bir hashleme işleviyle işlenmelidir.

KVKK ve GDPR kapsamında açık rıza ile hesap oluşturma verileri nasıl ayrıştırılır?

Hesap için gerekli veriler, hesap oluşturma amacı ve ilgili işleme dayanağıyla ayrı modellenir. Aydınlatma gösterimi ile açık rıza kayıtları ayrı tutulur; isteğe bağlı pazarlama tercihi ayrı ve geri çekilebilir olur. Her kayıt işleminde açık rıza otomatik olarak zorunlu kabul edilmemelidir.

Güvenli kayıt formu, tek bir regex veya CAPTCHA'dan değil, client geri bildirimi, server business logic'i ve database bütünlüğünü aynı akışta buluşturan katmanlı tasarımdan oluşur.