• 04-04-2025, 19:50:38
    #10
    Misafir adlı üyeden alıntı: mesajı görüntüle
    Lütfen konsepte uyalım, konuyu editleyip bir tane açık yazar mısınız iyi forumlar sevgiler...
    Estağfurullah niyetim konsepte darbe vurmak değil. Ama konunuzu gören birisi; bunu bir PHP açığı sanabilir. Oysa ki bu MySQL'in çalışma prensibinin bir sonucu. Bu prensibin PHP yazılımımıza zarar vermesine engel olmak (ki istiyorsak) bize düşen görev. Bu olay dilin bir kusuru değil.

    Yeni yazılıma başlamış arkadaşlarımız yanlış yönlensinler istemem.
  • 04-04-2025, 19:52:45
    #11
    flyingatm adlı üyeden alıntı: mesajı görüntüle
    Estağfurullah niyetim konsepte darbe vurmak değil. Ama konunuzu gören birisi; bunu bir PHP açığı sanabilir. Oysa ki bu MySQL'in çalışma prensibinin bir sonucu. Bu prensibin PHP yazılımımıza zarar vermesine engel olmak (ki istiyorsak) bize düşen görev. Bu olay dilin bir kusuru değil.

    Yeni yazılıma başlamış arkadaşlarımız yanlış yönlensinler istemem.
    Siz iki taraflı düşünün engin bilgilerinizle bizi aydınlatarak hem yazılım taraflı hemde veritabanı taraflı birer örnekler verebilirsiniz. Teşekkürler..
  • 04-04-2025, 19:56:17
    #12
    Misafir adlı üyeden alıntı: mesajı görüntüle
    Siz iki taraflı düşünün engin bilgilerinizle bizi aydınlatarak hem yazılım taraflı hemde veritabanı taraflı birer örnekler verebilirsiniz. Teşekkürler..
    Burada paradoksa girilen yer şurası; yok. Var olanlar da byte düzeyinde. Günümüzde bir dilin bir temel library fonksiyonunun kendisinde "güvenlik açığı" olması kavramı pek mümkün değil.

    Şayet, şu denebilir;

    PHP 8.5 Beta sürümü ile beraber; htmlspecialchars fonksiyonunda doğan bir bug sebebiyle; insanların ekrana bastırdığı PHP değişkenleri düzgün temizlenmeyebilir ve bir DOM-level güvenlik açığı yaratabilir.

    Buna şayet olsaydı, bu örnek verilebilirdi.

    Ancak, diğer hemen her verilen örnek; tamamen insan hatası.

    Amacım bir konu suikastı yapmak değil; ancak konu temel olarak doğru değil.
  • 04-04-2025, 20:02:10
    #13
    brute force saldırısıyla örneğin login sayfasına aşırı istek yapılarak sunucu aşırı yük altında bırakılabilir. Sistem log tutuyorsa log şişmesi, disk dolması vb. sorunlara yol açar. O yüzden kesinlikle bu saldırı için alınması gereken bir güvenlik önlemi olmalıdır.
  • 04-04-2025, 20:04:21
    #14
    En büyûğü ve güzelini yazılmış zaten rce diye

    Php filter chain lfi bypass

    Örnek kod:
    $page = $_GET['page'];
    include($page);

    Payload: /index.php?page=php://filter/convert.base64-encode/resource=index

    Kullanım amacı php dosyaların kaynak kodunu görüntüleme
  • 04-04-2025, 20:32:53
    #15
    cetin61 adlı üyeden alıntı: mesajı görüntüle
    En büyûğü ve güzelini yazılmış zaten rce diye

    Php filter chain lfi bypass

    Örnek kod:
    $page = $_GET['page'];
    include($page);

    Payload: /index.php?page=php://filter/convert.base64-encode/resource=index

    Kullanım amacı php dosyaların kaynak kodunu görüntüleme
    Elinize sağlık hocam buda çok güzel klasiklerden
    • cetin61
    cetin61 bunu beğendi.
    1 kişi bunu beğendi.
  • 05-04-2025, 13:17:37
    #16
    sql injection bu
  • 05-04-2025, 13:42:25
    #17
    Kurumsal PLUS
    File Upload Vulnerability
    Dosya uzantısı ve içeriği üzerinde yeterli kontrol sağlamazsa zararlı dosyalar yüklenebilir
    Bu açık kullanılarak yüklenen dosya bir web shell ise bu durumda site shell yedi derler

    if (isset($_FILES['file'])) {
    $file = $_FILES['file']['name'];
    $target = "uploads/" . basename($file);

    if (move_uploaded_file($_FILES['file']['tmp_name'], $target)) {
    echo "Dosya yüklendi: " . $file;
    } else {
    echo "Yükleme başarısız.";
    }
    }
  • 05-04-2025, 16:53:16
    #18
    Bir diğer tehlike de ortaktır 🤣 sunucu yedeklerini saçma sapan yerelere yedek diye yükler