Form güvenliği ve açık yönlendirme: CSRF, autocomplete ve redirect riski

Rehber · Form & yönlendirme

Web uygulamalarında formlar; giriş, kayıt, ödeme, şifre değiştirme, iletişim ve kullanıcı ayarları gibi kritik işlemlerin önemli bir bölümünü oluşturur.

Bu nedenle bir formun yalnızca doğru çalışması yeterli değildir. Formun kim tarafından gönderilebildiği, tarayıcının hangi bilgileri sakladığı ve işlem sonrasında kullanıcının nereye yönlendirildiği de güvenlik açısından değerlendirilmelidir.

Özellikle üç konu sıkça gözden kaçırılır:

• CSRF (Cross-Site Request Forgery)
• Autocomplete ve hassas form alanları
• Open Redirect / açık yönlendirme

Guardbee, web güvenlik taraması sırasında bu davranışları analiz ederek yalnızca teknik bir hata üretmek yerine, problemin kullanıcı ve uygulama açısından oluşturduğu riski görünür hale getirmeyi amaçlar.

Form güvenliği neden önemlidir?

Bir login formu düşünelim:

<form action="/login" method="POST">
    <input type="email" name="email">
    <input type="password" name="password">
    <button type="submit">Giriş</button>
</form>

İlk bakışta oldukça basit görünür. Ancak güvenlik açısından şu sorular ortaya çıkar:

Bu form başka bir siteden tetiklenebilir mi?
        ↓
Tarayıcı hassas bilgileri saklıyor mu?
        ↓
Form isteğinde CSRF koruması var mı?
        ↓
Başarılı işlemden sonra kullanıcı nereye yönlendiriliyor?
        ↓
Redirect adresi kullanıcı tarafından değiştirilebilir mi?

İşte form güvenliği bu noktada başlar.

1. CSRF nedir?

CSRF, Cross-Site Request Forgery yani Siteler Arası İstek Sahteciliği anlamına gelir.

Temel problem şudur: kullanıcı bir web sitesinde oturum açmışken, saldırgan kullanıcının tarayıcısını kullanarak hedef uygulamaya istenmeyen bir işlem yaptırmaya çalışır.

Örneğin kullanıcı https://bank.example.com üzerinde oturum açmış olsun. Saldırgan kendi sitesine şu tarz bir form koyabilir:

<form action="https://bank.example.com/api/change-email"
      method="POST">
    <input type="hidden"
           name="email"
           value="attacker@example.com">
</form>

Kullanıcı saldırganın sayfasını ziyaret ettiğinde form otomatik olarak gönderilmeye çalışabilir.

Eğer hedef uygulama gerekli CSRF kontrollerini yapmıyorsa ve authentication cookie’sini isteğe ekliyorsa, sunucu isteği gerçek kullanıcı tarafından yapılmış gibi değerlendirebilir.

Sonuç olarak saldırgan hesap bilgilerini değiştirebilir, adres değiştirebilir, işlem başlatabilir, ayarları değiştirebilir ve bazı durumlarda finansal işlem gerçekleştirebilir. CSRF’nin etkisi uygulamanın yaptığı işleme bağlıdır.

CSRF token nasıl çalışır?

Yaygın çözümlerden biri CSRF token kullanmaktır:

<form method="POST">
    <input type="hidden"
           name="csrf_token"
           value="random-token">
</form>

Sunucu bu token’ı kullanıcı oturumuyla ilişkilendirir:

Request
   ↓
Session
   +
CSRF Token
   ↓
Validation
   ↓
Allow / Reject

Token doğru değilse işlem reddedilir.

Bunun yanında framework seviyesinde CSRF koruması, SameSite cookie politikaları ve uygun authentication mimarisi de birlikte değerlendirilebilir. OWASP, CSRF token’larının sunucu tarafından doğrulanmasını ve özellikle state-changing işlemlerde CSRF savunmalarının uygulanmasını öneriyor.

Guardbee CSRF’yi nasıl analiz eder?

Guardbee öncelikle sayfadaki formları ve state-changing endpoint’leri keşfeder. Örneğin:

POST /login
POST /profile/update
POST /password/change
POST /payment

Ardından form yapısını ve request davranışını analiz eder:

Form
 │
 ├── Method
 ├── Action
 ├── Hidden fields
 ├── CSRF token
 ├── Cookies
 └── Security attributes

Örneğin state-changing bir formda CSRF korumasına dair herhangi bir mekanizma bulunmuyorsa Guardbee bunu potansiyel CSRF riski olarak raporlayabilir.

Ancak önemli bir ayrım vardır: bir formda açıkça csrf_token bulunmaması tek başına kesin CSRF açığı olduğu anlamına gelmez. Uygulama SameSite cookie, framework middleware, custom header veya server-side validation gibi başka bir koruma kullanıyor olabilir.

Bu nedenle Guardbee’nin mümkün olduğunca pasif tespit ile aktif doğrulamayı birbirinden ayırması önemlidir.

2. Autocomplete ve form verilerinin saklanması

Tarayıcılar kullanıcı deneyimini iyileştirmek için form alanlarını otomatik doldurabilir. Örneğin:

<input
    type="email"
    name="email"
    autocomplete="email">

kullanıcının email adresinin daha sonra otomatik doldurulmasına izin verir. Bu özellik normal alanlarda oldukça kullanışlıdır. Ancak hassas bilgiler söz konusu olduğunda formun nasıl yapılandırıldığı önem kazanır.

Örneğin:

<input
    type="password"
    name="password"
    autocomplete="on">

gibi bir kullanım, parola alanının tarayıcı tarafından hatırlanmasına veya otomatik doldurulmasına izin verebilir.

Burada önemli olan: autocomplete kullanılması tek başına güvenlik açığı değildir. Özellikle modern tarayıcılarda password manager’lar ve otomatik doldurma davranışları güvenlik ve kullanılabilirlik açısından birlikte değerlendirilmelidir.

OWASP da autocomplete kontrollerinin bağlama göre değerlendirilmesini ve hassas bilgilerin gereksiz şekilde istemci tarafında saklanmasının önlenmesini öneriyor.

Guardbee autocomplete’i nasıl analiz eder?

Guardbee sayfadaki form alanlarını analiz ederek şu bilgileri çıkarabilir:

Input
 │
 ├── type
 ├── name
 ├── autocomplete
 ├── sensitive-data indicator
 └── form context

Örneğin şu alanlar tespit edildiğinde alanın hassas veri içerip içermediği değerlendirilir:

<input
    type="text"
    name="credit_card"
    autocomplete="on">

<input
    type="password"
    name="password"
    autocomplete="on">

Guardbee burada yalnızca “autocomplete attribute var” demek yerine alanın ne amaçla kullanıldığını anlamaya çalışmalıdır. Email, password, credit card, OTP, security answer ve personal information gibi alanlar farklı risk kategorilerine ayrılabilir.

3. Open redirect nedir?

Open Redirect, kullanıcının güvenilir bir domain üzerinden başka bir adrese yönlendirilmesine izin veren güvenlik problemidir.

Örneğin uygulamada https://example.com/login?redirect=/dashboard gibi bir yapı olabilir. Bu normaldir. Fakat uygulama redirect parametresini kontrol etmeden kullanıyorsa saldırgan şu URL’yi oluşturabilir:

https://example.com/login?redirect=https://attacker.example

Kullanıcı example.com domain’ine güvendiği için linke tıklayabilir. Uygulama ise kullanıcıyı example.com → attacker.example adresine yönlendirir.

Bu durum özellikle phishing ve güvenilir domain üzerinden kötü amaçlı yönlendirme saldırılarında kullanılabilir. OWASP Unvalidated Redirects and Forwards rehberinde, kullanıcı tarafından kontrol edilen URL’lerin doğrulanmadan redirect işleminde kullanılmasının phishing gibi saldırılara yardımcı olabileceği belirtiliyor.

Open redirect nerelerde karşımıza çıkar?

Sadece login sayfalarında değil; şu parametrelerde de görülebilir:

/login?redirect=
/logout?redirect=
/callback?returnUrl=
/auth?next=
/redirect?url=
/continue?return=

Örneğin şu endpoint’ler özellikle incelenmelidir:

https://example.com/login?next=https://attacker.example
https://example.com/redirect?url=https://attacker.example

Guardbee open redirect’i nasıl tespit eder?

Guardbee crawler sırasında URL parametrelerini analiz eder. Yaygın redirect parametreleri arasında redirect, returnUrl, return, next, url, continue, destination ve target bulunur.

Ardından kontrollü bir test gerçekleştirilebilir:

Normal URL
     ↓
/login?next=/dashboard
Test URL
     ↓
/login?next=https://controlled-test-domain

Sunucunun response’u analiz edilir. Örneğin:

HTTP/1.1 302 Found
Location: https://controlled-test-domain

gibi bir davranış görülüyorsa Guardbee bunu potansiyel open redirect olarak işaretleyebilir.

Güvenli redirect nasıl yapılır?

Kullanıcı tarafından gönderilen URL’yi doğrudan kullanmak yerine izin verilen hedefler tanımlanabilir:

const allowedPaths = [
    "/dashboard",
    "/profile",
    "/settings"
];
if (allowedPaths.includes(returnUrl)) {
    redirect(returnUrl);
}

Daha gelişmiş sistemlerde validation şöyle uygulanabilir:

External URL
      ↓
Is domain trusted?
      ↓
Is path allowed?
      ↓
Is scheme HTTPS?
      ↓
Redirect

En güvenli yaklaşımlardan biri, mümkün olduğunda relative path veya server-side tanımlanmış redirect ID’leri kullanmaktır.

Guardbee form security scan nasıl çalışır?

Guardbee’nin bu kontrollerini genel olarak şöyle düşünebiliriz:

                 Web Site
                    │
                    ▼
              Page Discovery
                    │
                    ▼
             Form Discovery
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      CSRF      Autocomplete   Redirect
        │           │           │
        └───────────┼───────────┘
                    ▼
              Risk Analysis
                    │
                    ▼
             Security Finding
                    │
                    ▼
              Fix Guidance

Tarama sırasında yalnızca HTML’in statik olarak okunması yeterli değildir. Redirect problemi için URL parametrelerinin davranışını gözlemlemek gerekir. CSRF için formun hangi endpoint’e istek gönderdiği ve authentication mekanizmasıyla nasıl ilişkilendiği önemlidir. Autocomplete için ise input’un yalnızca attribute’larına değil, hangi tip veriyi kabul ettiğine bakmak gerekir.

Guardbee bulguyu nasıl sunmalı?

Amaç geliştiriciye onlarca teknik detay vermek değil, problemi hızlıca anlayıp düzeltebilmesini sağlamaktır.

Örneğin:

Open Redirect Detected
Severity: Medium

Endpoint
/login?next=

Risk
next parametresi kullanıcı tarafından kontrol edilebiliyor ve uygulama harici bir domain’e yönlendirme yapabiliyor.

Potential Impact
Saldırgan güvenilir domain’in kullanıldığı phishing bağlantıları oluşturabilir.

Recommended Fix
Harici URL’leri doğrudan kabul etmek yerine yalnızca izin verilen relative path’leri veya trusted domain’leri kabul edin.

Başka bir örnek:

Potential CSRF Protection Missing

Endpoint
POST /account/change-email

Risk
State-changing form isteğinde görünür bir CSRF token tespit edilemedi.

Recommended Fix
Framework seviyesinde CSRF protection kullanın ve state-changing request’lerde server-side token validation uygulayın.

Guardbee, framework veya başka bir mekanizma üzerinden uygulanan CSRF korumasını da mümkün olduğunca dikkate almalı; yalnızca hidden input bulunmadığı için kesin vulnerability üretmemelidir.

Neden bu kontroller birlikte değerlendirilmeli?

Tek bir güvenlik kontrolü çoğu zaman gerçek riski anlatmaz.

Örneğin open redirect + login flow + external URL birlikte değerlendirildiğinde phishing riski ortaya çıkabilir. Benzer şekilde sensitive form + autocomplete + client-side storage, kullanıcı verilerinin istemci tarafında gereksiz şekilde tutulması açısından daha anlamlı hale gelebilir.

CSRF tarafında ise state-changing request + cookie authentication + missing/weak CSRF defense bir araya geldiğinde risk çok daha net hale gelir.

Guardbee’nin burada yapması gereken, yalnızca tek tek kuralları tetiklemek değil; bulgular arasındaki ilişkiyi de değerlendirmektir.

Guardbee ile form güvenliği

Guardbee form güvenliği taramasında web uygulamasının kullanıcı etkileşim noktalarını analiz ederek CSRF koruması, form güvenlik yapılandırması, hassas input alanları, autocomplete davranışı, redirect parametreleri, open redirect, authentication akışları ve state-changing işlemler gibi alanları inceleyebilir.

Tespit edilen bulgular risk seviyesine göre sınıflandırılarak geliştiriciye şu soruların cevabını veren bir rapor halinde sunulabilir:

• Ne bulundu?
• Neden riskli?
• Hangi endpoint etkileniyor?
• Nasıl düzeltilebilir?

Sonuç

Formlar basit kullanıcı arayüzleri gibi görünse de arka planda authentication, kullanıcı verileri ve kritik işlemlerle doğrudan bağlantılıdır. Bu nedenle form güvenliği yalnızca input validation’dan ibaret değildir.

CSRF, kullanıcının istemediği bir işlemin onun oturumu üzerinden gerçekleştirilmesini önlemeyi amaçlar. Autocomplete, hassas form alanlarının tarayıcı tarafından nasıl ele alındığı konusunda dikkatli olunmasını gerektirir. Open Redirect, güvenilir bir domain üzerinden saldırgan tarafından kontrol edilen bir adrese yönlendirme yapılmasına neden olabilir.

Guardbee ise bu kontrolleri tek tek izole kurallar olarak değil, uygulamanın gerçek kullanıcı akışı ve saldırı yüzeyi içerisinde değerlendirmeyi hedefler.

Çünkü web güvenliğinde önemli olan yalnızca bir güvenlik kuralının ihlal edilip edilmediği değil, bu ihlalin gerçek dünyada saldırgana ne kazandırabileceğidir.

Sık sorulan sorular

Her formu mu tarar?

Keşfedilen sayfalardaki form sinyallerini inceler; tüm uygulama derinliğini kapsamaz.

CSRF token yoksa kesin açık mı demektir?

Hayır. SameSite cookie, framework middleware, custom header veya server-side validation gibi başka korumalar da kullanılabilir. Guardbee pasif tespit ile aktif doğrulamayı ayırmayı hedefler.

Autocomplete her zaman güvenlik açığı mıdır?

Hayır. Bağlama göre değerlendirilir. Özellikle hassas alanlarda tarayıcının veriyi nasıl sakladığı önemlidir.

Open redirect nasıl düzeltilir?

Yönlendirme hedeflerini allowlist ile sınırlayın; kullanıcı girdisini doğrudan Location’a yazmayın. Mümkünse relative path veya server-side redirect ID kullanın.

Rate limit ile ilişkisi var mı?

Rate limit sinyalleri ayrı bir modüldür; brute-force ve kötüye kullanım yüzeyini tamamlar.