78 lines
4.8 KiB
Markdown
78 lines
4.8 KiB
Markdown
# Go Backend API Güvenlik Tarama / Pentest Prompt (Türkçe)
|
||
|
||
Aşağıdaki prompt'u otomatik bir API güvenlik aracına, dışarıdan test yapacak bir pentester'a veya güvenlik-odaklı bir LLM'ye ver. Testlerin üretim ortamında yapılmaması, veya yapılacaksa kesin izin ve rollback planı gerektirdiğini unutma — yasal izinleri sağla.
|
||
|
||
--------------------------------------------------------------------
|
||
Amaç
|
||
- Go tabanlı API uygulamasının güvenliğini değerlendirmek: yetkisiz erişim, yetki yükseltme, token yönetimi hataları, kimlik doğrulama/oturum güvenliği, API mantık hataları, veri sızıntıları ve yaygın web/API zafiyetleri.
|
||
- Özellikle admin endpoint’lerinin korunması, JWT (access) ve refresh-token mekanizmasının güvenli biçimde uygulanıp uygulanmadığına odaklan.
|
||
|
||
Kapsam
|
||
- Base URL: <API_BASE_URL> (ör. https://api.example.com)
|
||
- Dahil olan yollar (örnek, tam listeyi test öncesi sağla):
|
||
- /api/v1/auth/login
|
||
- /api/v1/auth/refresh
|
||
- /api/v1/users/*
|
||
- /api/v1/admin/*
|
||
- /api/v1/public/*
|
||
- Test ortamı mı yoksa üretim mi: <TEST_ENVIRONMENT_INFO> (SAĞLAYIN)
|
||
- Teste dahil edilmemesi gereken kaynaklar / IP’ler: <EXCLUDE_IF_ANY>
|
||
|
||
Yetkilendirme & Test Hesapları (TEST VERİSİ sağlanmalı)
|
||
- Test kullanıcısı (standard user): kullanıcı adı/email ve parola
|
||
- Test admin hesabı: kullanıcı adı/email ve parola (manuel veya token)
|
||
- Örnek erişim tokenı (opsiyonel): Bearer <JWT_ACCESS_TOKEN_EXAMPLE>
|
||
- Refresh token davranışı: cookie mi, bearer mi, HTTP-only mi, rotating mı? (AÇIKLA)
|
||
- JWT imzalama algoritması: (HS256/RS256/ES256/…) ve varsa public key / JWKS endpointi
|
||
- Rate limit bilgisi ve beklenen limitler
|
||
|
||
İzinler ve Güvenlik Kuralları
|
||
- Yasal izin: Test için gerekli izinler verildi mi? (EVET/HAYIR)
|
||
- Üretime doğrudan zarar verici testler yalnızca açık izin varsa yapılır. (Destruktif işlemler = veri silme, maskeleme, yeniden başlatma gibi)
|
||
- Testler sırasında tetiklenen kritik durumlarda iletişim kişisi: <AD - TEL/EMAIL>
|
||
|
||
Test Senaryoları / Yapılacaklar (ayrıntılı)
|
||
1) Kimlik Doğrulama & Token Yönetimi
|
||
- Doğrulama akışını tam tekrar et: login -> access token al -> protected endpoint çağır -> refresh token ile yeni access al.
|
||
- Access tokenın süresi dolduğunda refresh akışını test et.
|
||
- Refresh token tekrar kullanılabilir mi? (refresh token reuse / replay attack testi)
|
||
- Refresh token rotation: her refresh işleminde eski refresh token invalid ediliyor mu?
|
||
- Logout davranışı: logout sonrasında access/refresh tokenların geçersizleştirildiğini doğrula.
|
||
- Token saklama: refresh token cookie ise Secure, HttpOnly, SameSite ayarlarını kontrol et.
|
||
|
||
2) JWT Güvenlik Testleri
|
||
- Alg none veya algoritma manipülasyon testleri (alg değiştirme, key confusion).
|
||
- HS256/RS256 anahtar/alg uyumsuzluk zafiyetleri kontrolü.
|
||
- JWT imzalanmamış veya hatalı imzalı token ile erişim denemeleri.
|
||
- Exp (expiration), nbf, iat gibi claim kontrolleri; ileri/geri tarihli token denemeleri.
|
||
- Uzun süreli tokenlarda (refresh) reuse/replay tespitleri.
|
||
- JWT içindeki role/claims manipülasyonu ile RBAC atlanabilir mi? (ör. role: user -> role: admin)
|
||
|
||
3) Yetki Kontrolleri & IDOR / Horizontal/Vertical Privilege Escalation
|
||
- Admin endpointlerine kullanıcı tokenı ile erişim denemeleri.
|
||
- IDOR kontrolleri: kullanıcının başka bir kullanıcının verisini görmesi/işlemesi (ör. /users/{id} parametre manipulasyonu).
|
||
- Resource-level access kontrolü (özellikle PUT/DELETE işlemleri).
|
||
|
||
4) Endpoint Mantık / İş Akışı Testleri
|
||
- İş mantığı kaynaklı hatalar: ödeme, bakiye, onay vb. süreçlerde yetki veya mantık atlatılabiliyor mu?
|
||
- Sequence / race condition testleri (ör. aynı anda iki refresh isteği).
|
||
|
||
5) Girdi Doğrulama & Enjeksiyonlar
|
||
- SQL Injection (parametrized query kontrolü), NoSQL injection (eğer NoSQL kullanılıyorsa), LDAP injection.
|
||
- Command injection, OS command dahil kod enjeksiyonu (varsa endpointlerle).
|
||
- XSS (reflected/stored) – API cevaplarında HTML içerik döndürülüyorsa.
|
||
- XML External Entity (XXE) (eğer XML işleniyorsa).
|
||
- JSON payload fuzzing ve boundary testleri (çok büyük/değişken değerler).
|
||
|
||
6) Rate Limiting & Brute Force
|
||
- Login endpointine brute-force testleri (kaba kuvvet). Var ise account lockout, rate limiting ve CAPTCHA mekanizmalarını kontrol et.
|
||
- Token brute-force / token guessing zafiyetleri (zayıf token üretimi).
|
||
|
||
7) Transport Güvenliği & CORS
|
||
- TLS konfigürasyonu: güncel protokoller (TLS1.2/1.3), zayıf şifreler, HSTS header kontrolü.
|
||
- CORS konfigürasyonu: permissive wildcard origin veya credentials ile açık origin olup olmadığı.
|
||
- HSTS, CSP, X-Frame-Options, X-Content-Type-Options gibi güvenlik header’ları.
|
||
|
||
8) Bilgi Sızıntısı & Logging
|
||
- H
|