Deneme süresinde bir PHP geliştiricisi için test görevi. PHP ve AJAX Test başarısı php kullanarak basit bir örnek

7.4K
Bu yazıda, bir AJAX formunun nasıl oluşturulacağını ve gönderileceğini anlatacağım. Bundan sonra, animate.css kullanarak animasyon uygulamaya, JavaScript kullanarak veri doğrulamaya bakabiliriz.

Bu yazının yazıldığı sırada Bootstrap 3.3.5, çerçevenin güncel sürümüdür. Bu makale için varsayılan Bootstrap derlemesini kullanıyoruz (12 sütun). Bu makaledeki görevleri tamamladığınızda, bölümünde açıklanan en son snippet'leri ve kod yapısını kullandığınızdan emin olun. Önyükleme belgeleri.

Dosya ve klasör yapısı

Bir kök dizin oluşturacağız ve buna aşağıdaki dosya ve klasörleri ekleyeceğiz:

Önyükleme-Formu:

Bazı ön uç kitaplıkları eklememiz gerekecek:

• Önyükleme;
• jQuery.

Bu kütüphaneler göz önünde bulundurulduğunda, dosya yapısı şöyle görünecektir:

Önyükleme-Formu:

Form oluşturma

index.html dosyanızı açın ve aşağıdaki temel yapıyı içine kopyalayın AJAX iletişim formları:

"

Bu, form içeriğini ekleyeceğimiz temel HTML şablonu. Gerekli tüm CSS ve JavaScript dosyalarını ekledik. Bu özel örnek için bootstrap.js'ye ihtiyacımız olmadığını unutmayın.

Bootstrap içindeki medya sorguları için görünüm meta etiketini ekledik. JavaScript, önce ana kodun işlenmesi için dosyanın altına yerleştirildi.

Gövde etiketine col-sm-6 col-sm-offset-3 sınıfına sahip bir div ekledik. Bu, sm (küçük) görünüm alanının içinde ve üstünde %50 genişliğinde bir sütun görüntülemek istediğimiz anlamına gelir ( maksimum sütun sayısı 12). col-sm-offset-3 sınıfı, sol dolguyu %25'e ayarlar.

Bu, kullanılabilir alanın yarısını kaplayan ve yatay olarak ortalanmış bir düzen oluşturur. Bundan sonra h3'ü açtık ve ardından şeklin tabanı gidiyor. Daha sonra AJAX JQuery formunu göndermek üzere bir olay ekleyebilmek için forma bir kimlik uyguladığınızdan emin olun:

Mücadelesiz zafer olmaz

Göndermek

Bunlar, kullanıcının etkileşimde bulunacağı tüm giriş alanları ve düğmelerdir. İlk div'e atanan sınıf satırı, col öğelerinin yatay bir gruplaması olan klasik Bootstrap sözdizimidir. Bootstrap içindeki sütunlar dolgu veya boşluk oluşturur. Bunları çıkararak hattın kaba eşit bir şekilde oturmasını sağlayabilirsiniz.

Formun üst kısmını ayırmak için kullanacağımız col-sm-6 (%50) sınıfında iki sütun oluşturduk. İlk sütun col-sm-6 içinde ad ve e-posta için bir etiket ve alanlar oluşturduk. Her biri, karşılık gelen for özniteliğine sahip bir etiket içerir, bu nedenle etiket ilgili alanla ilişkilendirilir.

Bu sütunların her biri, altta küçük bir kenar boşluğu oluşturarak etiketleri anlamsal olarak gruplayan bir form grubu içerir:

tipografi

Bootstrap, H1-H6 için sınıflara izin verir. Fazladan alanlar eklemeden veya süper AJAX iletişim formu öğesi blokları oluşturmadan satır içi öğelere stil vermenize yardımcı olurlar. Etiketleri biçimlendirmek ve onları büyütmek için H4 için bir sınıf kullandık.

Form-kontrol sınıfı, her bir girdi öğesine, kabın tam genişliğini (%100 genişlik) kaplayacak şekilde uygulanır. Bu sınıf ayrıca okunması kolay bir form öğesi oluşturmak için çeşitli stiller ekler ( büyük boy, keskin kenarlar vb.).

Bu sütunlardan sonra mesajın gövdesini ekliyoruz. Bir form grubuna sarıyoruz ve etiketler ve metin kutuları ile aynı stilleri uyguluyoruz.

Eylem çağrısı

Gönder butonu oluşturalım. Bootstrap, çeşitli düğmeler ve durumları için sınıflar içerir. " düğmesini kullanmaya karar verdik. başarı” (btn-başarı), varsayılan olarak yeşildir.

Düğmenin temel parametrelerini sıfırlamak için temel btn sınıfını da uygulamanız gerekir ( çerçeve, girinti, metin hizalama, yazı tipi boyutu). Büyük bir düğme oluşturan btn-lg sınıfını ve ardından soldaki düğmeyi saran sağa çekme sınıfını kullandık.

Butondan sonra #msgSubmit ID ile bir div ekledik ve şu sınıfları uyguladık: “ h3 metin merkezi gizli". h3 sınıfı daha büyük bir başlık oluşturmaya yardımcı olur, metin merkezi metin hizalamasını merkeze ayarlar ve gizli kümeler görüntülenir: yok ve görünür: gizli:

Veri gönderme işlevini ekleme

Temel bir Bootstrap JQuery AJAX formu oluşturduk, ancak henüz hiçbir şey yapmıyor. Bir sonraki adımımız, kullanıcı girdisini alıp asenkron olarak PHP'ye gönderen bir fonksiyon yaratmaktır.

scripts.js dosyasını açın ve aşağıdaki kodu içine kopyalayın:

$ ("# contactForm").gönder (işlev (etkinlik) (// form verilerinin gönderilmesini iptal eder event.preventDefault (); sendForm ();));

Bu jQuery kod parçacığı veri gönderme işlevlerini dinleyen #contactForm ( daha önce belirtildiği gibi). Bu fonksiyondan önce, fonksiyon için form gönderme eylemini tutan olay değişkenini ele alıyoruz.

event.preventDeafult (), formda bir eylem seçmeden sayfa yenilendiğinde form verilerini göndermeyi durdurur. Ve sonunda bu kod, sendForm() işlevini ister; :

function sendForm () (// form içeriğiyle bir değişken başlat var name = $ ("# name"). val (); var email = $ ("# email"). val (); var mesaj = $ ("# ileti ") .val (); $ .ajax ((tür:" POST ", url:" php / form-process.php ", veri:" ad = "+ ad +" & e-posta = "+ e-posta +" & mesaj = " + mesaj, başarı: işlev (metin) (if (metin == "başarı") (formSuccess ();))));) işlev formSuccess () ($ ("# msgGönder"). removeClass ("gizli"); )

Üç tetiklenen değişken, form giriş alanlarının her birinin değerlerini yakalar ve daha sonra kullanmak üzere bir JavaScript değişkenine iletir.

başlatıyoruz JQuery içindeki AJAX nesnesi ve gönderi parametrelerini, PHP dosyasının konumunu, göndermek istediğimiz verileri ve geri arama işlevini ayarlayın. Veriler, ilgili kimliğe sahip üç değişkeni de içerir. AJAX nesnesi PHP betiğinden başarıyla bilgi aldığında geri çağırma işlevi çağrılır. İşlev, döndürülen metni yakalar ve " dizesine eşit olup olmadığını kontrol eder. başarı”. Eğer öyleyse, son formSuccess işlevi çalıştırılır.

Daha önce uyguladığımız #msgSubmit DIV'den gizli sınıfı kaldırır, böylece metni oluşturur.

PHP Mail işlevine bağlanma

Şimdi AJAX formundan veri alacak ve içeriği PHP Mail fonksiyonu ile gönderecek bir script yazmamız gerekiyor. process.php dosyasını açın ve aşağıdaki kodu ekleyin:

Kullanmak istediğimiz değişkenleri kaydetmemiz gerekiyor. Bir posta işlevinden üç giriş değişkeni alınabilir ve PHP'de aynı adlar verilebilir. $ EmailTo değişkeni, komut dosyasında ayarlanabilen bir e-posta adresidir. $ Konu, e-postanın konusunu açıklayan bir dizedir.

Mektubun gövdesi, oluşturulan üç değişkenin eklenmesiyle keyfi olarak oluşturulur. İlk olarak, açıklayıcı metni belirledik, örneğin, “ İsim:“, Ardından bir değişken ve ardından yeni bir satır (/ n). Tüm verileri $ body değişkenine bağlayarak aynı adımları tekrarlıyoruz.

Bir e-posta göndermek için onu posta işlevine ekliyoruz. $ Success değişkenine bir değer atayarak e-postanın gönderileceği e-posta adresini, e-posta konusunu, göndericinin gövdesini ve e-posta adresini belirliyoruz.

E-posta gönderme işlemini başlatmak için, onu bir if ifadesinde çağırmanız gerekir. Bu şekilde form verilerinin başarılı bir şekilde gönderilip gönderilmediğini kontrol edebilirsiniz. Posta işlevi dönerse “ NS”, Komut dosyası döner“ başarı", Fonksiyon hata verirse geri döner" geçersiz”.

Bu sonuç AJAX nesnesine döndürülecek ve istemci tarafında işlenecektir. AJAX'ın avantajı, hepsinin istemci tarafında eşzamansız olarak yapılmasıdır. Bu, kullanıcının AJAX form verilerini gönderirken siteyle etkileşime devam etmesine olanak tanır:

Parlamak

Şimdi etkinleştirilebilecek çeşitli ek özelliklerle kullanıcı geri bildirimi sağlamaya odaklanacağız. Özellikle, hem istemci tarafında hem de sunucu tarafında hata işlemeyi kullanarak form geri bildirimine bakacağız.

Ayrıca formu doğrulamak için bazı araçlar kullanıyoruz:

• Animate.css:;
• Önyükleme Doğrulayıcı.

Bunları daha önce Bootstrap ve JQuery ile yaptığımız gibi projenize ekleyin. Bu araçlar, verileri gönderdikten sonra kullanıcıya geri bildirim sağlamaya yardımcı olacaktır.

Proje yapısı şimdi şöyle görünmelidir:

Form doğrulama

PHP AJAX geri bildirim formu verilerini girdikten sonra doğrulayıcıyı kurarak başlayalım. scripts.js'ye gidin ve form verileri gönderildikten sonra SubmitForm () işlevini çağıran ilk kod parçasını düzenleyin.
Aşağıdaki gibi değiştirilmesi gerekiyor:

$ ("# contactForm"). validator (). on ("gönder", function (event) (if (event.isDefaultPrevented ()) (// form hatası işlenir ...) else (// tamam! event .preventDefault) (); Formu gönder ();)));

Bu yeni kod parçacığı, Bootstrap Validator'ın sorun bulup bulmadığını ve kodun çalışmasını durdurup durdurmadığını kontrol eder. Değilse, eylemleri standart modda gerçekleştirmeye devam ediyoruz. Yine de varsayılan eylemi hariç tutmamız gerekiyor ( formu doldurmadan sayfayı yeniden yüklemek) form veri gönderme komut dosyasından.

Şimdi, tüm alanları doldurmadan form verilerini gönder düğmesine tıklarsak, boş olanlar kırmızı ile vurgulanacaktır:

Doğrulama ekleme sürecinde yerel HTML5 doğrulamasını engelledik. Hata mesajları ekleyerek doğrulamaya ek bağlam ekleyebilirsiniz. Bootstrap Validator, alanların her biri için hata mesajlarını görüntülemenizi sağlayan kullanışlı bir özelliğe sahiptir. Bunları eklemek için HTML işaretlemesini tamamlamanız gerekir.

Her form grubunun içinde, veri giriş alanının altına aşağıdaki HTML kodunu yerleştirmeniz gerekir:

Örnek olarak, ad ve e-posta alanlarına eklenecek fazladan bir div aşağıda verilmiştir:

Şimdi, AJAX JQuery form verilerini yeniden gönderirken, form alanları doldurulmamışsa bir hata mesajı görüntülenecektir: “ Lütfen bu alanı doldurun.”. Giriş verileri için “adlı bir veri özniteliği ekleyerek veri hatası”, Özel bir hata mesajı ekleyebilirsiniz.

Örneğin:

Geri bildirim animasyonu ekleme

Boş form alanlarını belirtmek için işlevsellik ekledik. Ancak, kullanıcıya neler olup bittiğini bildirmek için bazı ekstra animasyonlar ve bazı mesajlar eklemek güzel olurdu. Şu anda, form verilerinin başarılı bir şekilde gönderilmesinin ardından “ Mesaj Gönderildi!"Peki ya böcekler?

Mevcut koddan yararlanmak için mevcut gönderiyi başarıyla değiştireceğiz. Her şeyden önce, " metnini kaldırın Mesaj Gönderildi!"HTML işaretlemesinden ve div'i boş bırakın:

Şimdi mesajın durumunu işlemek için yeni bir fonksiyon oluşturmamız gerekiyor. Bu işlevi scripts.js dosyanızın altına ekleyin:

function sendMSG (geçerli, msg) (var msgClasses; if (geçerli) (msgClasses = "h3 metin merkezi tada animasyonlu metin başarısı";) else (msgClasses = "h3 metin merkezi metin tehlikesi";) $ ("# msgSubmit "). removeClass (). addClass (msgClasses) .text (msg);)

Bu fonksiyon iki argüman alır. geçerli bir boole değişkeni olacaktır: değeri doğruysa, başarılı veri gönderimi hakkında bir mesaj görüntülenecektir. Yanlış ise, bir hata mesajı görüntülenecektir. msg div bloğunda ekranda göreceğimiz mesajdır.

Bu fonksiyon, başarılı bir veri gönderimi veya bir hata mesajı ile ilgili bir mesajla ilgilenip ilgilenmediğimizi kontrol eder. Bu, geçerli değişkenin değeri kontrol edilerek yapılır. Her iki durumda da uygun CSS sınıflarıyla bir değişken ayarlar ( onları kaldıracağımız için h3 ve text-center'ı yeniden eklememiz gerekiyor).

Not: Başarı mesajı sınıfı için bazı animate.css sınıfları kullanıyoruz. Tada animasyonu, AJAX JQuery iletişim formu başarıyla gönderildiğinde oynatılacaktır.

Son olarak, işlev tüm sınıfları #msgSubmit ( çakışan sınıfları önlemek için) ve ardından öncelik sınıflarını ayarlar ve yazı metnini div'e ekler.

Bu bölümün başındaki doğrulayıcının başlatılmasında, doğru olarak değerlendirildiğinde if ifadesinin içindeki aşağıdaki işleve bir çağrı eklemek için kodu güncelleriz:

sendMSG (yanlış, "Formu düzgün doldurdunuz mu?");

Şimdi, tüm alanları doldurmadıysanız, hata mesajı “ Formu düzgün doldurdunuz mu?»

Bu yeni sendMSG işlevi için son adım, form verileri başarıyla gönderildiğinde onu çağırmaktır. formSuccess() işlevini aşağıdaki gibi güncelleyin:

$ ("# iletişimFormu").reset(); sendMSG (doğru, "Mesaj Gönderildi!")

Başarılı gönderim mesajı ile yukarıda belirtildiği gibi sendMSG işlevini çağırdığımızda formu sıfırlamak ve değerleri temizlemek istiyoruz. Şimdi, form verilerinin başarılı bir şekilde gönderilmesinden sonra, animate.css tada animasyonu ile ilgili mesaj görüntülenmelidir:

Hadi sallayalım

Tüm forma bir hata animasyonu ekleyelim, genel bir "sallama" animasyonu işe yaramalı!

formSuccess() işlevinden hemen sonra yeni bir tane oluşturun ve onu formError() olarak adlandırın:

function formError () ($ ("# contactForm"). removeClass (). addClass ("animasyonlu sallama"). one ("webkitAnimationEnd mozAnimationEnd MSAnimationEnd oanimationend animasyonend", function () ($ (this) .removeClass ();)) ;)

Bu işlev, bir öğeye animasyon eklemenize ve ardından onu yeniden çağırmanıza olanak tanıyan animate.css demo sayfasında açıklanan yaklaşımı kullanır.

CSS animasyonlarının kötü bir yönü vardır: Sınıf kaldırılıp yeniden eklense bile yeniden oynatma yetenekleri yoktur. Bu özellik, animasyon bitiş sınıflarını yeniden ekleyebilmeniz için sıfırlamaya yardımcı olur. Kullanıcı geri bildirim formunun tüm AJAX alanlarını doldurmadan Gönder düğmesine tıkladığında sallama animasyonunu oynatıyoruz. Ve yine tüm alanları doldurmazsa, bu animasyonu tekrar oynatmanız gerekir.

Hata mesajı için oluşturduğumuz sendMSG() fonksiyonunun yukarısındaki formError() fonksiyonunu çağırabilirsiniz. Örneğin, bunun gibi:

formError(); sendMSG (yanlış, "Formu düzgün doldurdunuz mu?");

Şimdi, kullanıcı tüm alanları doldurmadan form verilerini göndermeye çalıştığında, bir şeylerin yanlış olduğunu anlayacak şekilde sallanacaktır.

Daha fazla doğrulama

İstemci tarafı doğrulama iyidir, ancak herkes kodu tarayıcıda düzenleyerek bunu kapatabilir ve boş alanları olan bir form gönderebilir. Sunucu tarafı doğrulama hizmeti oluşturmanız gerekir.

Tüm alanların doğrulandığından emin olmak için process.php dosyasını açmamız ve gerekli değişiklikleri yapmamız gerekiyor. Hata mesajlarını yakaladığımız bir $ errorMSG değişkeni oluşturacağız ve ardından ek bir $ _POST kontrolünü etkinleştireceğiz:

Bu PHP kodu, verilerini uygun değişkenler olarak ayarlamadan önce boş AJAX form alanlarının olup olmadığını kontrol eder ( $ _POST'tan kodda ayarlanan mevcut değişkenleri değiştirir). Alanlar boşsa, istemciye geri göndermek için genel bir mesaj ayarlarız.

Orijinal AJAX çağrısına yanıt olarak, tarayıcıda görüntülenecek bir hata mesajı göndermemiz gerekiyor. Bunu yapmak için, PHP kodunun altında daha önce oluşturduğumuz if ifadesini düzenleyin:

if deyimi aracılığıyla $ errorMSG değişkeninin boş ("") olup olmadığını ve ayrıca $başarı değişkeni için kullandığımız yerleşik Mail işlevinin durumunu kontrol ederiz. Else yan tümcesine, hatanın bir $ başarı hatasının sonucu olup olmadığını görmek için fazladan bir kontrol ekledik. Eğer öyleyse, mesajı geri göndeririz” Bir şeyler yanlış gitti:". Aksi takdirde boş alanları kontrol ettiğimizde derlenen mesajı görüntülüyoruz.

Ve son adım, AJAX'ta yeni bir mesajı kabul etmek ve formda görüntülemek. scripts.js dosyasındaki AJAX nesnesini aşağıdaki gibi güncellememiz gerekiyor:

$ .ajax ((type: "POST", url: "php / form-process.php", veri: "ad =" + ad + "& e-posta =" + e-posta + "& mesaj =" + mesaj, başarı: function ( metin) (if (metin == "başarı") (formSuccess ();) else (formError (); gönderMSG (yanlış, metin);))));

text == başarısını test eden else cümleciklerini yeni güncelledik. Diğerinde, sallama animasyonunu uygulayan ve PHP'den döndürülen metin için sendMSG () işlevini isteyen formError () işlevini çağırırız.

Çözüm

Kodun tamamını görüntülemek için Github'a gidin. Şimdi PHP AJAX geri bildirim formu kullanıcıya hangi alanları doldurmadığı hakkında bilgi verir. Duruma ve PHP'den döndürülen mesaja göre bağlamsal mesajları görüntüleriz. Ayrıca, ön uç doğrulamasını atlamaya çalışan kullanıcılar için ek bir sunucu tarafı doğrulama katmanı uyguladık.

Umarım bu makaleden hoşlanmışsınızdır. Lütfen sorularınızı ve görüşlerinizi yorumlarda bırakın.

Bu yayın makalenin bir çevirisidir " PHP ve AJAX Kullanarak Önyükleme İletişim Formu Oluşturma"Güleryüzlü proje ekibi tarafından hazırlanmıştır.

Temel işlevselliğe aşağıdaki özellikler eklenmelidir:

• Kullanıcı, mesajlarda aşağıdaki HTML etiketlerini kullanabilir:
• Kapanış etiketleri için bir kontrol olmalı, kod geçerli XHTML olmalıdır

Ziyaretçi defteri. JavaScript ve AJAX.

Temel işlevselliğe aşağıdaki özellikler eklenmelidir:

• Sunucu tarafı ve istemci tarafı giriş doğrulaması
• Sayfayı yeniden yüklemeden bir mesajı önizleme ve ekleme işlevi
• HTML etiketleri için (,,,,) düğmeleriyle bir panel yapın.
• Görsel efektler eklemek de memnuniyetle karşılanmaktadır.

Gereksinimler

Sistem, aşağıdaki yapılandırmayla Linux işletim sisteminde düzgün çalışmalıdır:

• PHP 5.1+
• MySQL 4.1+
• Apaçi 2.2+

Aşağıdaki kütüphaneler kullanılabilir:

• PHP Zend Çerçevesi veya PEAR
• JS jQuery veya Prototip

not Resim Stirling motorunu gösteriyor, wikipedia genellikle zihin için yiyecek veriyor ...

yukarı: blogumda çok doğru bir yorum çıktı:

millet, muhtemelen bu görevin kimin için tasarlandığını anlamıyorsunuz. Tecrübeli bir kişi DOĞAL olarak iki nedenden dolayı bunu yapmayacaktır: a) zaman kaybetmek istemeyecek ve b) kendisine verilmeyecektir.

Ancak gerçek şu ki, bu genellikle genç php geliştirici pozisyonu için başvuranın ilk az ya da çok hacimli işidir.

Bu nedenle, 80 saat sadece bu görevi yapması için değil, özgeçmişindeki php, html, css, js, ajax, mysql karşısındaki onay kutularına göre gerçeği (bilgisini) getirmek için verilir.

Sonuç olarak, hem beceri hem de öğrenme yeteneğinin ve google yeteneğinin belirli bir ayrılmaz göstergesini elde ederiz.

Aslında, görev bununla başa çıkıyor.

Ve doğal olarak gösterecek bir şeyleri olan adaylar doğrudan projelere giderler.

Etiketler: Etiket Ekle

Modern web çağında, çoğu site daha etkileşimli hale geliyor. Daha önce, güncellenmiş verileri almak için sayfayı tamamen güncellememiz gerekiyordu, şimdi sayfanın tamamını değil, yalnızca ayrı bir bölümünü yüklemeye izin veren teknolojiler ortaya çıktı. Buna karşılık, bu hem kullanıcılara hem de sunucu sahiplerine kolaylık sağlar, çünkü kullanıcı için sayfanın yalnızca ayrı bir kısmı yüklendiğinden sayfa yüklemesi daha hızlı olacaktır ve sunucunun her seferinde sayfayı oluşturmasına ve vermesine gerek yoktur. kullanıcıya. Bu özelliklerin php ve ajax kullanılarak uygulanması kolaydır.

Bugün konseptin nasıl çalıştığını daha iyi anlamak için küçük bir örneği analiz edeceğiz. AJAX... Bazen yeni başlayanlar için php ve ajax'ın birbirleriyle nasıl etkileşime girdiğini anlamak zordur, birçok kişi tüm sayfayı yeniden yüklemeden formları anında nasıl doğrulayacaklarına dair örnekler arıyor. Bunu nasıl yapacağınızı kısaca göstereceğim, böylece diğer araçları hızlı bir şekilde öğrenmenize ve gelecekte kendi scriptlerinizi yazmanıza olanak sağlayacak temelleri ve ilkeleri anlayabilirsiniz.

Kendimize küçük bir görev bulalım, php ve ajax kullanarak sayfayı yeniden yüklemeden veritabanında bir e-posta adresinin olup olmadığını kontrol edeceğiz. Böyle bir örnek, sayfayı tarayıcıya yeniden yüklemeden sunucuyla nasıl etkileşime geçebileceğimizi iyi bir şekilde gösterecektir ve ayrıca, genellikle çeşitli kullanıcı formu doğrulamalarında kullanılır. Kök dizinde index.php, email.php, validate.js adında 3 dosya oluşturun.

Bir sayfa yarat

Yalnızca bir e-posta alanı içeren basit bir tek form sayfası oluşturalım.
Index.php dosya sözdizimi

ile çalışmanın en kolay yolu AJAXçerçeveyi bağlamaktır jQuery, ki aslında yaptım. jQuery göndermek için bize anlaşılması kolay ve kullanımı kolay bir sözdizimi sağlar AJAX istekler, neden bundan faydalanmıyorsunuz?

Js komut dosyası oluşturma

validate.js dosyasının sözdizimi şöyledir:

$ (belge) .ready (işlev () (var email = ""; $ ("# email").keyup (işlev () (var değeri = $ (bu) .val (); $ .ajax ((tür: "POST", url: "email.php", veri: "email =" + değer, başarı: işlev (msg) (if (msg == "geçerli") ($ ("# mesaj"). Html (" Bu E-posta kullanılabilir.Bu e-posta zaten alınmış.");))));)); $ (" # gönder "). (işlev ()'e tıklayın (if (email ==" ") (uyarı ("Lütfen, tüm e-postalara veri koyun ");) başka ( $ .ajax ((tür: "POST", url: "email.php", veri: "add_email =" + e-posta, başarı: işlev (msg) ($ ("# mesaj"). html (msg);)) );)));));

PHP işleyicisi

Bu komut dosyası alacak İLETİİstemciden istekte bulunun, işleyin ve sonucu döndürün. AJAX sonucu okur ve ona göre karar verir.
email.php dosyasının sözdizimi şöyledir:

$ bağlantı = mysqli_connect ("localhost", "e-posta", "e-posta", "e-posta"); if (isset ($ _ POST ["email"]) && $ _POST ["email"]! = "") ($ email = $ _POST ["email"]; $ email = mysqli_real_escape_string ($ bağlantı, $ email); if (! filter_var ($ email, FILTER_VALIDATE_EMAIL)) (echo "geçersiz";) else ($ sql = "SELECT id FROM email WHERE email =" $ email ""; $ sonuç = mysqli_query ($ bağlantı, $ sql); if ( mysqli_num_rows ($ sonuç) == 1) (echo "geçersiz";) else (echo "geçerli";))) if (isset ($ _ POST ["add_email"]) && $ _POST ["add_email"]! = "" ) ($ email = mysqli_real_escape_string ($ bağlantı, $ _ POST ["add_email"]); $ sql = "E-posta (e-posta) DEĞERLERİNE GİRİN (" $ email ")"; if (mysqli_query ($ bağlantı, $ sql) )) ( yankı Başarı";) başka (yankı" Hata"; } }

PHP betiğimizde, bir gönderi isteğini işleyen ve sayfadaki belirli metni yazdıran en yaygın kod. Sonuç olarak AJAX php betiğine bir istek gönderir, betik onu işler ve sonucu döndürür, AJAX sonucu okur ve sayfayı gerçek zamanlı olarak değiştirir.

AJAX, POST isteğini bu kod parçası aracılığıyla komut dosyasına iletir:

$ .ajax ((tür: "POST", url: "email.php", veri: "email =" + değer, başarı: işlev (msg) (if (msg == "geçerli") ($ ("# mesaj") ") .html (" Bu E-posta kullanılabilir."); email = değer;) else ($ (" # mesaj "). html (" Bu e-posta zaten alınmış."); } } });

type - İstek türü, POST veya GET. Bizim durumumuzda, POST;
url - isteğin gönderildiği komut dosyasının adresi;
veri - istekte iletilen veriler;
başarı - isteğin başarılı bir şekilde yürütülmesinin bir sonucu olarak ne yapılması gerektiği. Bizim durumumuzda fonksiyon çağrılır;

Komut dosyasının kendisinde, e-posta alanına her karakter girildiğinde, veritabanında e-posta olup olmadığının kontrolü gerçekleştirilir. Komut dosyasında $ ("# email").Keyup (function () ()); bu, id = "email" olan alanda bir tuşa basıp basmadığını kontrol eder.
Gördüğünüz gibi, kod oldukça basittir ve anlamak için özellikle büyük beceriler gerektirmez, her şey keyup () olaylarını işlemeye bağlıdır - bir tuşa basmak, () - bir öğeye tıklamak. Bunu takiben AJAX komut dosyasından istek ve yanıt. Böylece, php ve ajax kullanarak etkileşimli sayfalar oluşturmak için neredeyse sonsuz olanaklar elde edebilirsiniz.
Bu kodun yüksek kalitede olduğunu iddia etmiyor, ancak geliştirirseniz, istemci ve sunucu düzeyinde doğru doğrulamaları ekleyin, css girin, projelerinizde oldukça kullanabilirsiniz.
Herhangi bir sorunuz varsa, yorum yazmaktan çekinmeyin.
İyi günler ve yakında görüşürüz 🙂

İnternet üzerinden mal ve hizmetler için ödeme yapmanın ekonomik ve güvenli bir yoludur. Çevrimiçi mağazanıza bu sistem için bir işleyici ekleyin ve ödemeleri gecikmeden kabul edin.

Güncellenen Yandex.Money 3.0 protokolü, farklı ödeme türleri kullanmanıza olanak tanır:

• Aslında Yandex parası;
• Banka kartları;
• Terminal ödemeleri;
• Mobil ödemeler.

Ayrıca, platformda oluşturulan mağazaları bağlama prosedürü 1C-Bitrix: Site Yönetimi, Yanedeks'e Para büyük ölçüde basitleştirildi. Yandex.Money web sitesinde bir istek bırakmanız gerekir (yorumlarda bir web siteniz olduğunu belirtir) protokol sürümü 3.0 ile.) ve basitleştirilmiş bir anket doldurun (sadece 3 alandan oluşur).

Yeni Yandex.Money protokolünü 1C-Bitrix platformundaki bir çevrimiçi mağazaya bağlamak için yeni bir ödeme sistemi oluşturmanız ve bir işleyici seçmeniz gerekir.

Sitenizin https üzerinden yanıt verip vermediğini kontrol edin. Bu, Yanedeks.Money 3.0 protokolünü kullanarak ödemeleri kabul etmek için bir ön koşuldur.

Kendinden imzalı bir SSL sertifikası veya her şeyin önceden yapılandırıldığı Sanal Makinemizi kullanabilirsiniz.

Sonraki belirtin Kimliği CPP'de saklayın, CPP'deki vitrin numarası sözleşmeyi imzalarken Yandex'den almanız gereken ve Mağaza şifresi (shopPassword) mağazanın Yandex anketinden.

Her ödeme türü için kendi işleyicinizi oluşturmanız ve gerekli ödeme türünü seçmeniz gerekir.

Ödemeyi test etmek için alana "Y" değerini girmeniz gerekir. Test modu... Yandex.Money 3.0 protokolünü bağlamak için bir başvuru gönderdiğinizde, 1000 rublelik bir test için cüzdanınızın bakiyesini dolduracağınız özel bir bağlantı alacaksınız.

Çevrimiçi mağaza modülünün ayarlarında, başarılı bir ödeme veya hata mesajı içeren sayfalara giden yolları yeniden tanımlayabilirsiniz.

Her şey. Kurulum tamamlandı.

Yandex.Money'nin (1.6) önceki sürümünü bağlamış olan müşterilerin 3.0 sürümüne yükseltme yapmasına gerek yoktur. Onlar. her iki sürüm de hem Yandex.Money hem de 1C-Bitrix: Site Yönetimi tarafından desteklenmektedir. AMA sürüm 1.6, Yandex.Money dışındaki ödemeleri kullanma yeteneği eklemez. Bu ödeme sisteminin yeni müşterileri 3.0 protokolü kullanılarak bağlanır.

Ürün teslimatında 1C-Bitrix: Site Yönetimi Yandex.Money işlemcisi (3.0), Çevrimiçi mağaza (satış) modülünün 14.0.0 sürümünde piyasaya sürülecek. Bu güncelleştirmenin yayımlanmasından önce (ay sonunda alfa sürümünde yayımlanacağını varsayıyoruz), işleyici Teknik Destek aracılığıyla talep edilebilir.

OWASP sürümüne göre en yaygın on saldırı türü listesinde, ilk iki sırada kod enjeksiyonu ve XSS (siteler arası komut dosyası oluşturma) saldırıları yer alıyor. El ele giderler çünkü XSS, diğer birçok saldırı türü gibi, enjekte eden saldırıların başarısına bağlıdır. Bu ad, kötü amaçlı kodu bir saldırganın istediği şekilde yürütmeye veya yorumlamaya zorlamak için verilerin bir web uygulamasına enjekte edildiği tüm bir saldırı sınıfını gizler. Bu saldırılar arasında örneğin XSS, SQL Injection, Header Injection, Code Injection ve Full Path Disclosure sayılabilir. Ve bu sadece küçük bir kısım.

Enjeksiyon saldırıları, tüm programcılar için bir korku hikayesidir. Çeşitlilikleri, ölçekleri ve (bazen) onlara karşı savunmadaki güçlükleri nedeniyle en yaygın ve başarılıdırlar. Tüm uygulamaların bir yerden veri alması gerekir. XSS ve UI Redress özellikle yaygındır, bu yüzden onları ayrı bölümlere ayırdım ve genel sınıftan ayırdım.

OWASP, enjeksiyon saldırıları için aşağıdaki tanımı sağlar:

SQL, OS ve LDAP gibi enjeksiyon fırsatları, yorumlayıcı bir komut isteğinin parçası olarak güvenilmeyen verileri aldığında ortaya çıkar. Kötü amaçlı veriler, yorumlayıcıyı belirli komutları yürütmesi veya yetkisiz verilere erişmesi için kandırabilir.

SQL enjeksiyonu

SQL enjeksiyonu, enjeksiyon saldırılarının en yaygın ve son derece tehlikeli şeklidir. Bu tehdidin ciddiyetini abartmak zordur, bu nedenle saldırıların başarısını neyin etkilediğini ve bunlara karşı nasıl savunma yapılacağını anlamak son derece önemlidir.

Böylece veriler bir web uygulamasına enjekte edilir ve ardından SQL sorgularında kullanılır. Genellikle web formları gibi güvenilmeyen girdi kaynaklarından gelirler. Ancak enjeksiyon, veritabanının kendisi gibi diğer konumlardan yapılabilir. Programcılar genellikle üssünün tam güvenliğine inanırlar, ancak bir durumda güvenli olmasının gelecekte güvenli olacağı anlamına gelmediğini fark etmezler. Veritabanındaki veriler, aksi kanıtlanana kadar, yani doğrulanıncaya kadar güvenilmez olarak kabul edilmelidir.

Saldırı başarılı olursa, saldırgan, geliştiriciler tarafından amaçlanmayan veritabanı üzerinde işlemler gerçekleştirmek için SQL sorgusunu değiştirebilir.

Bu sorguya bir göz atın:

$ db = new mysqli ("localhost", "username", "password", "storedb"); $ sonuç = $ db-> sorgu ("SELECT * FROM WHERE user_id =". $ _POST ["user_id"]);

Burada bir dizi söve var. İlk olarak, user_id'nin doğruluğu için POST verilerinin içeriğini kontrol etmedik. İkinci olarak, güvenilmeyen bir kaynağın bize hangi user_id'nin kullanılacağını söylemesine izin veriyoruz: bir saldırgan herhangi bir geçerli user_id'yi kaydırabilir. Belki de güvenli olduğunu düşündüğümüz bir formun gizli bir alanında bulunuyordu, çünkü düzenlenemez (saldırganların herhangi bir veri girebileceğini unutarak). Üçüncüsü, user_id'den kaçmadık ve sorguya bağlı bir parametre olarak iletmedik, bu da saldırganın SQL sorgusunu manipüle edecek rasgele dizeleri enjekte etmesine izin veriyor, çünkü ilk etapta doğrulayamadık .

Bu üç eksiklik, web uygulamalarında çok yaygındır.

Veritabanına güvenmek açısından, user_name alanını kullanarak işlemler aradığımızı hayal edin. Adlar geniştir ve tırnak işaretleri içerebilir. Diyelim ki saldırgan, enjekte edilen dize değerini kullanıcı adlarından birine kaydetti. Bu değeri aşağıdaki sorgulardan birinde tekrar kullandığımızda, veritabanını güvenilir bir kaynak olarak kabul ettiğimizden, güvenliği ihlal edilmiş sorguyu yalıtmadığından veya kısıtlamadığından, sorgu dizesini değiştirecektir.

Ayrıca başka bir SQL enjeksiyon faktörüne de dikkat edin: Kalıcı depolamanın her zaman sunucuda tutulması gerekmez. HTML 5, SQL ve JavaScript kullanılarak sorguların gönderilebildiği bir istemci tarafı veritabanının kullanımını destekler. Bunun için iki API vardır: WebSQL ve IndexedDB. 2010'da W3C, WebSQL'in seçilmesini önermedi; arka uç olarak SQLite kullanan WebKit tarayıcıları tarafından desteklenir. Büyük olasılıkla, W3C tavsiyesine rağmen, geriye dönük uyumluluk adına destek devam edecektir. Adından da anlaşılacağı gibi, bu API SQL sorgularını kabul eder ve bu nedenle enjeksiyon saldırılarının hedefi olabilir. IndexedDB daha yeni bir alternatiftir, NoSQL veritabanıdır (SQL sorguları gerektirmez).

SQL enjeksiyon örnekleri

SQL sorgularını manipüle etmek aşağıdaki amaçlara hizmet edebilir:

1. Veri sızıntıları.
2. Saklanan bilgilerin ifşası.
3. Depolanan bilgilerin manipülasyonu.
4. Yetkilendirme atlaması.
5. İstemci tarafı SQL enjeksiyonu.

SQL enjeksiyon koruması

SQL enjeksiyon koruması, ayırma ilkesine dayanmaktadır. Talepteki verileri kullanmadan önce formlarının doğru olup olmadığını kontrol etmeniz gerekir. Ayrıca, sorguya dahil edilmeden önce verileri ayırmanız veya bir geçiş parametresi olarak eklemeniz gerekir.

muayene

Sürekli tekrar ediyorum: Geçerli isteğin orijinal PHP kodunda açıkça oluşturulmamış tüm veriler güvenilir değil. Bunları kesinlikle kontrol edin ve kontrolleri geçemeyen her şeyi reddedin. Verileri "düzeltmeye" çalışmayın, formatta yalnızca küçük, kozmetik değişiklikler yapabilirsiniz.

Yaygın hatalar, verileri daha sonraki kullanımlar için doğrulamayı (örneğin, görüntüleme veya hesaplamalar için) ve bir veritabanındaki alanları sonunda bilgi depolayacak alanları doğrulamamayı içerir.

ekranlama

mysqli uzantısı ile bir SQL sorgusunda bulunan tüm verileri izole edebilirsiniz. Bu, mysqli_real_escape_string() işlevi tarafından yapılır. PostgresSQL için pgsql uzantısı, pg_escape_bytea (), pg_escape_identifier (), pg_escape_literal () ve pg_escape_string () işlevlerini sunar. Mssql uzantısında (Microsoft SQL Server) hiçbir ayırma işlevi yoktur ve addslashes () yaklaşımı etkisizdir - özel bir işleve ihtiyacınız vardır.

Hayatı sizin için daha da zorlaştırmak adına sorguya girilen verileri izole ederken hataya yeriniz olmadığını söyleyeceğim. Bir özledim ve saldırıya karşı savunmasızsınız.

Özetle. Ekranlama en iyi koruma seçeneği değildir. Son çare olarak başvurmaya değer. Soyutlama için kullandığınız veritabanı kitaplığı, parametre bağlamayı zorlamadan çıplak SQL sorgularını veya bir sorgunun bölümlerini özelleştirmenize izin veriyorsa gerekli olabilir. Diğer durumlarda, izolasyondan tamamen kaçınmak en iyisidir. Bu yaklaşım karmaşıktır, hataya açıktır ve veritabanı uzantısına bağlı olarak farklılık gösterir.

Parametreli sorgular (hazır ifadeler)

Parametreleştirme veya parametre bağlama, SQL sorguları oluşturmanın önerilen yoludur. Tüm iyi veritabanı kitaplıkları bunu varsayılan olarak kullanır. İşte PDO PHP uzantısını kullanan bir örnek:

if (ctype_digit ($ _ POST ["id"]) && is_int ($ _ POST ["id"])) ($ validatedId = $ _POST ["id"]; $ pdo = new PDO ("mysql: store.db "); $ stmt = $ pdo-> hazırla ("SELECT * FROM WHERE user_id =: id"); $ stmt-> bindParam (": id", $ validatedId, PDO :: PARAM_INT); $ stmt-> yürüt () ;) else (// id değerini reddet ve hatayı kullanıcıya bildir)

PDO ifadeleri için kullanılabilen bindParam () yöntemi, hazırlanmış bir ifadede sağlanan "yer tutuculara" parametreleri bağlamanıza olanak tanır. Bu yöntem, PDO :: PARAM_INT, PDO :: PARAM_BOOL, PDO :: PARAM_LOB ve PDO :: PARAM_STR gibi temel veri türleri için parametreleri kabul eder. PDO :: PARAM_STR için aksi belirtilmedikçe bu varsayılan değerdir, bu nedenle diğer değerleri de unutmayın!

El ile ayırmadan farklı olarak, parametre bağlama (veya veritabanı kitaplığınız tarafından kullanılan başka bir yöntem) otomatik olarak bağlı verileri doğru şekilde yalıtır, böylece hangi işlevi kullanacağınızı hatırlamanız gerekmez. Ayrıca, tutarlı parametre bağlama, her şeyi manuel olarak ayırmayı hatırlamaya çalışmaktan çok daha güvenilirdir.

En az ayrıcalık ilkesinin uygulanması

Başarılı bir SQL enjeksiyonunu iptal etmek, onu tamamen engellemek kadar önemlidir. Bir saldırgan SQL sorguları yürütme fırsatı bulduğunda, bunu belirli bir veritabanı kullanıcısı olarak yapacaktır. En az ayrıcalık ilkesini kullanarak, tüm kullanıcıların yalnızca görevlerini yerine getirmek için kesinlikle gerekli olan ayrıcalıklara sahip olmasını sağlayabilirsiniz.

Bir kullanıcının geniş ayrıcalıkları varsa, bir saldırgan tabloları bırakabilir ve onların adına yeni SQL enjeksiyonları gerçekleştirerek diğer kullanıcıların ayrıcalıklarını değiştirebilir. Bunun olmasını önlemek için, veritabanına hiçbir zaman bir web uygulamasından kök, yönetici veya yüksek ayrıcalıklara sahip başka bir kullanıcı olarak erişmeyin.

İlkenin bir başka uygulaması, veri tabanına veri okuma ve yazma rollerinin ayrılmasıdır. Salt yazma izinlerine sahip bir kullanıcı ve salt okuma izinlerine sahip başka bir kullanıcı seçin. Saldırı "okuyan" kullanıcıya yönelikse, saldırgan tablodaki verileri değiştiremez veya yazamaz. Erişimi daha da dar bir şekilde kısıtlayabilir, böylece başarılı SQL enjeksiyon saldırılarının etkisini azaltabilirsiniz.

Pek çok web uygulaması, özellikle açık kaynaklı olanlar, ayrıcalık seviyesi neredeyse kesinlikle hiç kontrol edilmeyen yalnızca bir veritabanı kullanıcısını kullanacak şekilde tasarlanmıştır. Bu yüzden bu noktayı unutmayın ve uygulamaları yönetici hesabı altında çalıştırmaya çalışmayın.

Kod Enjeksiyonu (Uzaktan Dosya Ekleme olarak bilinir)

Kod yerleştirme, bir saldırganın yorumlanabilmesi ve yürütülebilmesi için bir web uygulamasına kaynak kodu eklemesine izin veren herhangi bir yöntemdir. Aynı zamanda istemci tarafına kod enjekte etmekten bahsetmiyoruz, örneğin JavaScript'te XSS saldırıları zaten burada kullanılıyor.

Kaynak kodunu doğrudan güvenilmeyen bir giriş kaynağından enjekte edebilir veya bir web uygulamasını yerel dosya sisteminden veya URL gibi harici bir kaynaktan yüklemeye zorlayabilirsiniz. Harici kaynak eklemenin bir sonucu olarak kod enjekte edildiğinde, RFI'nin kendisinin her zaman kod enjeksiyonu için kullanılması amaçlanmış olsa da, genellikle uzak dosya ekleme (RFI) olarak adlandırılır.

Kod enjeksiyonunun ana nedenleri şunlardır:

• giriş doğrulamasını atlayarak,
• PHP kodu olarak yorumlanacakları herhangi bir bağlama güvenilmeyen girdileri enjekte etmek,
• kaynak kod depolarının güvenliğini hacklemek,
• üçüncü taraf kitaplıkların yüklenmesiyle ilgili uyarıları devre dışı bırakmak,
• Sunucuyu PHP olmayan dosyaları PHP yorumlayıcısına geçirecek şekilde yeniden yapılandırma.

Son noktaya özellikle dikkat edin: bu durumda, güvenilmeyen kullanıcılar herhangi bir dosyayı sunucuya yükleyebilir.

Kod ekleme örnekleri

PHP'nin kod enjeksiyonu için birçok hedefi vardır, bu nedenle bu tür saldırılar herhangi bir programcının izleme listesinin başında gelir.

Bir dosya dahil

Kod yerleştirme için en belirgin hedefler include(), include_once(), request() ve require_once()'dir. Güvenilir olmayan girdi verileri, bu işlevlere iletilen yol parametresinin belirlenmesine izin veriyorsa, dahil edilecek dosyanın seçimini uzaktan kontrol etmek mümkün olacaktır. Dahil edilen dosyanın gerçek bir PHP dosyası olması gerekmediğine dikkat edilmelidir, metin verilerini depolayabilen herhangi bir formatta bir dosya kullanabilirsiniz (yani, neredeyse kısıtlama olmadan).

Yol parametresi, Dizin Geçişi saldırılarına veya uzaktan dosya eklemeye karşı da savunmasız olabilir. Yolda ../ veya ... karakter kombinasyonlarını kullanmak, bir saldırganın PHP işleminin erişimi olan hemen hemen her dosyaya atlamasını sağlar. Ayrıca, varsayılan PHP yapılandırmasında, allow_url_include devre dışı bırakılmadığı sürece yukarıdaki işlevler URL'leri kabul eder.

muayene

PHP eval() işlevi, yürütme için bir PHP kodu satırını kabul eder.

Normal İfade Uygulaması

PHP'deki PCRE (Perl Uyumlu Normal İfade) preg_replace () işlevi, e (PREG_REPLACE_EVAL) değiştiricisini kabul eder. Bu, değiştirildikten sonra PHP kodu olarak değerlendirilecek olan bir değiştirme dizesi anlamına gelir. Ve eğer bu satırda güvenilir olmayan girdiler varsa, o zaman çalıştırılabilir PHP kodunu enjekte edebilecekler.

Arızalı dosya ekleme mantığı

Tanım olarak, web uygulamaları herhangi bir isteği yerine getirmek için gereken dosyaları içerir. Yönlendirme, bağımlılık yönetimi, otomatik yükleme ve diğer işlemler mantığındaki kusurlardan yararlanırsanız, yolu istek veya parametreleri aracılığıyla değiştirmek, sunucuyu belirli yerel dosyaları dahil etmeye zorlar. Web uygulaması bu tür manipülasyonları işlemek için tasarlanmadığından, sonuçları tahmin edilemez olabilir. Örneğin, bir uygulama yanlışlıkla yalnızca komut satırında kullanılması amaçlanan rotaları vurgulayacaktır. Veya, yapıcıları görevleri yerine getiren diğer sınıfları ortaya çıkaracaktır (bu gibi sınıflar tasarlamamak daha iyidir, ancak bu yine de olur). Bu senaryolardan herhangi biri, uygulamanın arka uç işlemlerine müdahale ederek, doğrudan erişim anlamına gelmeyen kaynak yoğun işlemlerde veri manipülasyonuna veya DOS saldırısına izin verebilir.

Kod ekleme görevleri

Bu tür bir saldırı, saldırganın tercih ettiği herhangi bir PHP kodunun yürütülmesine izin verdiğinden, görevlerin kapsamı son derece geniştir.

Kod Enjeksiyonuna Karşı Savunmalar

Komut Enjeksiyonu

Komut Enjeksiyonu Örnekleri

Komut Enjeksiyonuna Karşı Savunmalar

Günlük Enjeksiyonu (Günlük Dosyası Enjeksiyonu olarak bilinir)

Birçok uygulama günlükleri toplar ve oturum açmış kullanıcılar bunları genellikle HTML arabirimi aracılığıyla görüntüler. Bu nedenle, günlükler, diğer saldırıları gizlemek, günlükleri görüntüleyenleri aldatmak ve hatta daha sonra günlüklerin okunup analiz edildiği izleme uygulamasının kullanıcılarına bir saldırı yapmak isteyen siber suçluların ana hedeflerinden biridir.

Günlüklerin güvenlik açığı, günlük kaydı üzerindeki kontrol mekanizmalarına ve ayrıca kayıtları görüntülerken ve analiz ederken günlük verilerinin güvenilir olmayan bir kaynak olarak ele alınmasına bağlıdır.

Basit bir günlük tutma sistemi, file_put_contents () kullanarak bir dosyaya metin satırları yazabilir. Örneğin, bir programcı hatalı oturum açma girişimlerini aşağıdaki biçimde dizeler olarak günlüğe kaydeder:

sprintf ("% s ile başarısız oturum açma girişimi", $ kullanıcı adı);

Saldırgan formda "AdminnSuccessful login by Adminn" adını kullanırsa ne olur?

Bu satır, güvenilir olmayan giriş verilerinden günlüğe eklenirse, saldırgan, yönetici parolasını girmek için masum bir başarısızlıkla başarısız olan yetkilendirme girişimini başarıyla gizleyecektir. Başarılı bir yetkilendirme girişimi eklerseniz, verilerin şüphesi daha da azalacaktır.

Buradaki bütün nokta, saldırganın günlüğe her türlü girişi ekleyebilmesidir. Konsoldaki günlük girişlerini okumayı zorlaştıran bir XSS vektörü ve hatta semboller de gömebilirsiniz.

Uygulama görevlerini günlüğe kaydet

Uygulamanın amaçlarından biri günlük formatı yorumlayıcılarıdır. Analiz aracı, günlük girişlerini parçalara ayırmak ve farklı alanlara dağıtmak için ayrıştırmak için normal ifadeler kullanıyorsa, normal ifadeleri doğru olanlar yerine gömülü alanları seçmeye zorlayacak bir dize oluşturabilir ve gömebilirsiniz. Örneğin, bu girdi birkaç sorunun kaynağı olabilir:

$ username = "iamnohacker!, 01 Ocak Pazartesi 00:00:00 +1000 2009"; sprintf ("% s'de % s tarafından başarısız oturum açma girişimi", $ kullanıcı adı,)

Daha karmaşık günlük yerleştirme saldırıları, günlüğü tarayıcıda görüntülemek için dizin geçiş saldırılarına dayanır. Doğru koşullar altında, bir günlük mesajına PHP kodunu enjekte etmek ve bir tarayıcıda kayıtları içeren bir dosyayı açmak, başarılı bir kod enjeksiyonuna yol açacaktır, düzgün bir şekilde biçimlendirilmiş ve saldırganın isteği üzerine yürütülmüştür. Ve sunucuda kötü niyetli PHP'nin yürütülmesi söz konusuysa, o zaman yalnızca hasarı azaltabilecek koruma ayrımının etkinliğini umabiliriz.

Log enjeksiyonuna karşı koruma

Tüm harici günlük mesajlarını filtrelemenin en kolay yolu beyaz liste kullanmaktır. Diyelim ki karakter setini sadece sayılar, harfler ve boşluklarla sınırladık. Yetkisiz karakterler içeren mesajlar bozuk olarak kabul edilir. Ardından, olası bir günlük dosyası ekleme girişimi hakkında bir günlük girişi görünür. Bu, güvenilmeyen giriş verilerinden kaçınılamadığı durumlarda basit metin günlüklerini korumanın kolay bir yoludur.

İkinci koruma yöntemi, çeşitli bilgileri metin biçiminde saklamanıza izin verirken, sınırlı bir karakter kümesini destekleyen base64 gibi bir sistem kullanarak güvenilmez girdi verilerinin bölümlerinin dönüştürülmesidir.

Yol geçişi (Dizin Geçişi olarak bilinir)

Yol geçiş saldırıları, bir web uygulamasının arka ucundaki dosya okuma veya yazma işlemlerine müdahale etme girişimleridir. Bu, arka uç işlemlerinde yer alan dosyaların yollarını değiştirmenize izin veren parametreler enjekte edilerek yapılır. Dolayısıyla bu tür saldırılar Bilgi Açıklamasını ve yerel / uzak dosya enjeksiyonunu kolaylaştırır.

Bu tür saldırıları ayrı ayrı ele alacağız, ancak başarıları yol geçişine dayalıdır. Aşağıda açıklanan işlevler dosya yollarını manipüle etmeye özgü olduğundan, birçok PHP işlevinin kelimenin genel anlamıyla dosya yollarını kabul etmediğini belirtmek mantıklıdır. Bunun yerine, include () veya file () gibi işlevler URI'leri alır.

Tamamen doğal görünmüyor. Ancak bu, mutlak yolları kullanan sonraki iki işlev çağrısının eşdeğer olduğu anlamına gelir (örneğin, göreli yolları otomatik yüklemeye dayanmadan).

dahil ('/ var / www / satıcı / kitaplık / Class.php'); include ('dosya: ///var/www/vendor/library/Class.php');

Buradaki nokta, göreceli yolun yan tarafta ele alınmasıdır (php.ini ve mevcut otomatik yükleyicilerde include_path ayarı). Bu gibi durumlarda, PHP işlevleri, bir dosya yolunun başında güvenilmeyen veriler gömülüyse bir saldırganın bir HTTP veya FTP URI'si ekleyebildiği Dosya URI Şeması Değiştirme de dahil olmak üzere birçok parametre işleme biçimine karşı özellikle savunmasızdır. Uzak dosya dahil etme saldırıları bölümünde bunun hakkında daha fazla konuşacağız, ancak şimdilik dosya sistemi yollarını çaprazlamaya odaklanacağız.

Bu güvenlik açığı, başka bir dosyaya başvurmak için yolun değiştirilmesi anlamına gelir. Bu genellikle, bir argümana bir dizi ../ dizisi enjekte edilerek gerçekleştirilir, bu daha sonra işlevlere eklenir veya tamamen include (), request (), file_get_contents () ve hatta daha az şüpheli (bazı insanlar için) gibi işlevlere eklenir. ) DOMDocument: : load () gibi çalışır.

Saldırgan ../ dizisini kullanarak sistemi üst dizine dönmeye zorlar. Böylece /var/www/public/../vendor yolu aslında / var / www / seller'e gider. / public'ten sonraki ../ dizisi bizi ana dizine, yani / var / www dizinine döndürür. Böylece saldırgan, web sunucusundan erişilebilen / public dizininin dışında bulunan dosyalara erişim kazanır.

Tabii ki, bir yolu geçmek sadece geri dönmekle sınırlı değildir. .htaccess'teki kısıtlama ayarları nedeniyle tarayıcıdan erişilemeyen alt dizinlere erişmek için yeni yol öğeleri enjekte edilebilir. PHP'nin dosya sistemi işlemleri, web sunucusundaki genel olmayan dosya ve dizinlere erişim kontrolünün yapılandırılmasıyla ilgilenmez.

Yol Geçişi Örnekleri

Yol Geçişine Karşı Savunmalar

XML enjeksiyonu

JSON'un sunucu ve istemci arasında veri aktarımı için hafif bir araç olarak tanıtılmasına rağmen, XML, web hizmetleri API'leri genellikle JSON ile paralel olarak desteklediği için popüler bir alternatif olmaya devam ediyor. XML, XML şemalarını kullanarak veri alışverişi yapmak için de kullanılır: RSS, Atom, SOAP ve RDF, vb.

XML her yerde bulunur: web uygulama sunucularında, tarayıcılarda (XMLHttpRequest istekleri ve yanıtları için tercih edilen biçim olarak) ve tarayıcı uzantılarında bulunabilir. PHP tarafından DOM'da ve SimpleXML ve XMLReader uzantılarında kullanılan libxml2 gibi popüler bir ayrıştırıcı tarafından yaygınlığı ve varsayılan işlemesi göz önüne alındığında, XML, enjeksiyon saldırıları için bir hedef haline geldi. Bir tarayıcı XML alışverişine aktif olarak katıldığında, yetkili kullanıcıların, aslında saldırganlar tarafından oluşturulmuş XML isteklerini iletmek için XSS kullanabileceği dikkate alınmalıdır.

XML Harici Varlık Enjeksiyonu (XXE)

Bu tür saldırılar, XML ayrıştırma kitaplıklarının genellikle özel varlık başvurularının kullanımını desteklemesi nedeniyle oluşur. >, & lt; gibi özel işaretleme karakterlerini temsil etmek için kullanılan standart XML Varlık Tamamlama hakkında bilgi edineceksiniz. ve & apos;. XML, XML belgesinin kendisi aracılığıyla özel varlıklar tanımlayarak standart varlıklar kümesini genişletmenize olanak tanır. İsteğe bağlı bir DOCTYPE'a doğrudan dahil edilerek tanımlanabilirler. Temsil ettikleri genişletilmiş değer, dahil edilecek harici bir kaynağa atıfta bulunabilir. XXE saldırıları, sıradan XML'in dış kaynakların içeriği nedeniyle büyüyebilen özel bağlantıları depolama yeteneği nedeniyle tam olarak popüler hale geldi. Normal şartlar altında, güvenilmeyen girdiler sistemimizle asla beklenmedik bir şekilde etkileşime girmemelidir. Ve çoğu XXE programcısı, özellikle endişe verici olan XXE saldırılarını neredeyse kesinlikle beklemiyor.

Örneğin, yeni bir özel zararsız varlık tanımlayalım:

]>

Bu tanıma sahip bir XML belgesi, artık varlıklara izin verilen her yerde bir varlığa başvurabilir:

]> Bu sonuç

PHP DOM gibi bir XML ayrıştırıcısı bu XML'i yorumladığında, belge yüklenir yüklenmez bu özel varlığı işler. Bu nedenle, uygun metin istendiğinde aşağıdakileri döndürür:

Bu sonuç tamamen zararsızdır

Açıkçası, özel varlıklar, daha kısa varlık adlarıyla yinelenen metni ve XML'i temsil etme avantajına sahiptir. Genellikle XML'in belirli bir dilbilgisini izlemesi gerekir ve özel varlıklar düzenlemeyi kolaylaştırır. Ancak, harici girdilere olan güvensizliğimiz göz önüne alındığında, uygulamamız tarafından tüketilen tüm XML'e çok dikkat etmemiz gerekiyor. Örneğin, bu hiç güvenli bir çeşit değil:

]> &harmless;

İstenen yerel dosyanın içeriğine bağlı olarak, varlık genişletilirken veriler kullanılabilir. Ardından, genişletilmiş içerik XML ayrıştırıcısından çıkarılabilir ve saldırgan tarafından analiz edilmek üzere web uygulamasının giden verilerine dahil edilebilir. Örneğin, bilgileri ifşa etmek. Çıkarılan dosya XML olarak yorumlanacaktır, ancak bu tür bir yorumlamayı başlatacak özel karakterler yoktur. Bu, yerel dosyanın içeriğinin ifşa kapsamını sınırlar. Dosya XML olarak yorumlanır ancak geçerli XML içermiyorsa, büyük olasılıkla içeriğin genişletilmesini önleyecek bir hata alırız. Ancak PHP, ölçek sınırlamasını aşmak için temiz bir numara sağlar, bu nedenle uzak HTTP istekleri, döndürülen yanıt saldırgana geri iletilemese bile web uygulamasını etkiler.

PHP'de XML'i ayrıştırmak ve tüketmek için üç yaygın yöntem vardır: PHP DOM, SimpleXML ve XMLReader. Hepsi libxml2 uzantısını kullanır, harici varlıklar için destek varsayılan olarak etkindir. Sonuç olarak, PHP, XML kullanan bir web uygulamasının veya kitaplığın güvenliği düşünüldüğünde gözden kaçırılması çok kolay olan varsayılan bir XXE güvenlik açığına sahiptir.

XHTML ve HTML 5'in iyi biçimlendirilmiş XML olarak serileştirilebileceğini de unutmayın. Bu, bazı XHTML sayfalarının veya XML seri hale getirilmiş HTML 5'in, DOMDocument :: loadHTML () yerine DOMDocument :: loadXML () kullanılarak XML olarak ayrıştırılabileceği anlamına gelir. Bir XML ayrıştırıcısının bu kullanımı, harici XML varlık enjeksiyonuna karşı da savunmasızdır. libxml2'nin henüz HTML 5 DOCTYPE'ı tanımadığını unutmayın, bu nedenle onu XHTML DOCTYPES olarak doğrulayamaz.

Harici XML varlıklarını enjekte etme örnekleri

Dosya içeriği ve ifşa

Yukarıda, özel bir XML varlığının harici bir dosyaya başvurabileceğini belirterek bir bilgi ifşa örneğine baktık.

]> &harmless;

Bu durumda, özel varlık, dosyaların içeriğiyle genişletilecektir. Bu tür tüm istekler yerel olarak gerçekleştirildiğinden, bu, uygulamanın okuyabileceği tüm dosyaların içeriğini genişletmenize olanak tanır. Yani, genişletilmiş varlık giden uygulama verilerine dahil edildiğinde, saldırgan özel erişimdeki dosyaları inceleyebilecektir. Ancak bu durumda ciddi bir sınırlama vardır: Dosyalar ya XML biçiminde ya da XML ayrıştırıcı hatasına yol açmayacak biçimde olmalıdır. Ama mesele şu ki, bu sınırlama PHP'de tamamen göz ardı edilebilir:

]> &harmless;

PHP, dosya sistemiyle çalışmak için standart işlevler tarafından kabul edilen protokollerden biri olan bir URI biçiminde sarmalayıcıya erişim sağlar: file_get_contents (), request (), request_once (), dosya (), kopya () ve birçok diğerleri. PHP sarmalayıcısı, sonuçların bir işlev çağrısı tarafından döndürülmesi için belirli bir kaynağa uygulanabilecek bir dizi filtreyi destekler. Yukarıdaki örnekte, okumak istediğimiz hedef dosyaya convert.base-64-encode filtresini uyguluyoruz.

Bu, bir saldırganın, metin biçiminden bağımsız olarak PHP tarafından erişilebilen herhangi bir dosyayı okuyabileceği anlamına gelir. Sadece uygulamadan gelen verilerin kodunu çözmek ve ardından cezasız bir şekilde incelemek yeterlidir. Bu, son kullanıcılara veya uygulama arka ucuna doğrudan zarar vermese de, saldırganların diğer güvenlik açıklarını bulma girişiminde uygulama yapısına iyi bakmalarına olanak tanır. Ayrıca, saldırganların keşfedilme riski minimumdur.

Erişim kontrolünü atla

Erişim çeşitli şekillerde kontrol edilir. XXE saldırıları bir web uygulamasının arka ucunda gerçekleştirildiği için mevcut kullanıcının oturumunu kullanmak işe yaramaz. Ancak bir saldırgan, yerel sunucudan gelen istekleri kullanarak arka uç erişim denetimini yine de atlayabilir. Bunun gibi ilkel bir erişim denetimi düşünün:

if (isset ($ _ SERVER ["HTTP_CLIENT_IP"]) || isset ($ _ SERVER ["HTTP_X_FORWARDED_FOR"]) ||! in_array (@ $ _ SERVER ["REMOTE_ADDR"], array ("127.0.0.1", " :: 1 ",))) (başlık (" HTTP / 1.0 403 Yasak "); çıkış (" Bu dosyaya erişme izniniz yok. ");)

PHP'nin bu yığını, onun gibi sayısız diğerleri gibi, yerel sunucudaki belirli PHP dosyalarına, yani localhost'a erişimi kısıtlar. Bununla birlikte, uygulamanın ön ucundaki XXE saldırısı, saldırgana bu erişim kontrolünü atlamak için gereken tam kimlik bilgilerini verir, çünkü XML ayrıştırıcısına yönelik tüm HTTP istekleri localhost'tan yapılacaktır.

]> &harmless;

Günlükleri görüntüleme yerel isteklerle sınırlı olsa bile, saldırgan yine de günlükleri alabilir. Aynısı, erişimi benzer şekilde kısıtlanmış olan bakım veya yönetim arayüzleri için de geçerlidir.

DOS saldırıları

DOS saldırıları için, sunucu kaynaklarının tüketimini belirleyen hemen hemen her şeyi kullanabilirsiniz. Saldırgan, harici bir XML varlığı enjekte ederek, doğru koşullar altında sunucu kaynaklarını tüketen rastgele HTTP istekleri yapabilir.

XXE saldırılarının diğer potansiyel DOS kullanımlarından daha sonra XML varlık uzantıları açısından bahsedeceğiz.

Harici XML varlık enjeksiyonuna karşı koruma

Bu saldırılar çok popülerdir, bu yüzden onlara karşı savunmanın ne kadar kolay olduğu sizi şaşırtacak. DOM, SimpleXML ve XMLReader'ın tümü libxml2'ye dayandığından, harici varlıkların kullanımını devre dışı bırakmak için sadece libxml_disable_entity_loader() işlevini kullanabilirsiniz. Ancak bu, DOCTYPE'da önceden tanımlanmış özel varlıkları devre dışı bırakmaz, çünkü bunlar bir HTTP isteği veya dosya sistemi işlemi gerektiren harici kaynakları kullanmazlar.

$ oldValue = libxml_disable_entity_loader (doğru); $ dom = yeni DOMDocument(); $ dom-> loadXML ($ xml); libxml_disable_entity_loader ($ oldValue);

Bu, dizelerden, dosyalardan veya uzak URI'lerden XML yüklemeyi içeren tüm işlemler için yapılmalıdır.

Uygulamanın hiçbir zaman harici varlıklar gerektirmediği ve isteklerinin çoğu için harici kaynakların yüklenmesini daha genel bir düzeyde devre dışı bırakabilirsiniz. Çoğu durumda, birçok kitaplığın XXE saldırılarına karşı doğal güvenlik açıklarına sahip olduğu göz önüne alındığında, tüm XML yükleme noktalarını tanımlamak için bu daha çok tercih edilir:

libxml_disable_entity_loader (doğru);

Harici kaynak yüklemeyi her etkinleştirdiğinizden sonra DOĞRU döndürmeyi unutmayın. XSL stil sayfalarının harici varlıklara bağlı olduğu Docbook XML'i HTML'ye dönüştürmek gibi zararsız görevler için buna ihtiyacınız olabilir.

Ancak, libxml2'nin devre dışı bırakma işlevi her derde deva değildir. Harici varlıkların kullanımındaki "anahtarlarını" bulmak için XML'i ayrıştıran veya başka şekilde işleyen diğer uzantıları ve PHP kitaplıklarını analiz edin.

Bu mümkün değilse, ayrıca XML belgesinin bir DOCTYPE bildirip bildirmediğini kontrol edin. Böyleyse ve harici varlıklar devre dışı bırakılırsa, potansiyel olarak savunmasız ayrıştırıcıya güvenilmeyen XML erişimini reddederek ve olası bir saldırı olarak günlüğe kaydederek XML belgesini atmanız yeterlidir. Bu gerekli bir adımdır, çünkü başka bir işaret olmayacak - hata yok, istisna yok. Bu doğrulamayı normal giriş doğrulamanıza ekleyin. Ancak bu yöntem ideal olmaktan uzaktır, bu nedenle dış varlıklar sorununu temelden çözmeniz şiddetle tavsiye edilir.

/ ** * Hızlı bir algılama denemesi * / $ daraltılmışXML = preg_replace ("/ [: boşluk:] /", "", $ xml); if (preg_match ("/

Bir saldırının sonucu olabilecek şüpheli verilerin hemen silinmesi de tercih edilir. Neden tehlikeli görünen bir şeyle çalışmaya devam ediyorsun? Bu nedenle, yukarıdaki iki önlemin birleşimi, verilerin silinememesi durumunda (örneğin, üçüncü taraf kitaplıkları ise) kendinizi korurken, açıkça kötü niyetli verileri önceden yok saymanıza olanak tanır. Ayrıca verileri silmeniz gerekir çünkü libxml_disable_entity_loader () tüm özel varlıkları devre dışı bırakmaz, yalnızca dış kaynaklara başvuranları devre dışı bırakır. Bu, bir XML Varlık Genişletme saldırısı olasılığını bırakır.

XML Varlığını Genişletme

Bu saldırı, XML Entity Injection saldırısına çok benzer. Ancak bu durumda, hedef uygulamanın sunucu ortamının kaynaklarını boşaltmaya yönelik bir DOS saldırısına vurgu yapılır. DOCTYPE XML'de, örneğin bellekte orijinalden çok daha büyük XML yapıları oluşturabilen özel bir varlık tanımı oluşturulur. Bu, belleği doldurabilir ve sunucu performansını azaltabilir. Bu saldırı, libxml2 uzantısı tarafından HTML olarak tanınmıyorsa, HTML 5 XML serileştirmesi için de geçerlidir.

XML Varlık Uzantısı Örnekleri

Özel XML varlıklarını istenen sunucu kaynakları tükenmesine genişletmenin birkaç yolu vardır.

Genel varlık uzantısı

Başka bir isim "kare büyütme saldırısı" dır. Özel bir varlık, çok uzun bir dize olarak tanımlanır. Bir belgede yeniden kullanırsanız, her seferinde büyür, sonuç olarak XML yapısı orijinal XML'e kıyasla çok daha fazla RAM tüketir.

]> Şimdi bu XML yapısının bellek içi boyutunu genişletmek için birçok kez ekleyin Devam et ... ...

Özel varlık dizesinin boyutu ile belgenin gövdesindeki kullanım miktarı arasında bir denge bulursanız, genişletildiğinde sunucu belleği tüketimini tahmin edecek bir XML dosyası veya dizesi oluşturabilirsiniz. Böyle tekrar eden sorularla doldurursanız, gerçek bir DOS saldırısı olacaktır. Yaklaşımın dezavantajı: Bellek tüketimi basit bir çarpma etkisine bağlı olduğundan, orijinal XML de oldukça büyük olmalıdır.

Özyinelemeli varlık genişletme

Genel genişletme, başlangıçta büyük XML kullanımını gerektirirken, özyinelemeli genişletme çok daha yüksek bir büyütme faktörü sağlar. Bu yöntem, boyut olarak önemli ölçüde büyümeleri için küçük varlıkların üstel çözünürlük (çözüm) kümelerine dayanır. Bu tekniğe genellikle XML Bombası ve Billion Laughs Attack olarak atıfta bulunulması mantıklıdır.

]> 3 ... 2 ... 1 ...

XML Bomb, bazen uygulama tarafından boyut olarak sınırlandırılabilen büyük XML gerektirmez. Saldırı, belleğin, varlığın orijinal değerinin boyutunun 2 ^ 100 katı olan metinle tıkanmasına neden olur -. Gerçek bir BOMBA!

Uzak varlık uzantısı

Yukarıdaki saldırıların her ikisi de XML DTD'de yerel olarak tanımlanmış varlıkları kullanır. Ancak, XML ayrıştırıcısı harici HTTP istekleri yapabilirse, saldırgan varlığı uzaktan belirleyebilir. XXE (XML External Entity Injection) açıklamasında gördüğümüz gibi, temel bir güvenlik önlemi olarak bu özelliğin engellenmesi gerekir. Böylece XXE'ye karşı kendimizi savunurken, bu tür saldırılara karşı da kendimizi savunuyoruz.

Neyse: Bu saldırı için, XML ayrıştırıcı, karşılık gelen varlıkların genişletilmiş değerini almak için harici HTTP istekleri yapmalıdır. Sırayla, ayrıştırıcının ek HTTP istekleri yapması gereken yeni harici varlıkları bağımsız olarak tanımlayacaklar. Bu nedenle, birkaç zararsız görünen sorgu hızla kontrolden çıkar ve mevcut sunucu kaynakları üzerindeki yükü artırır ve sonuç olarak varlıkların yinelemeli olarak genişlemesine ve durumu daha da kötüleştirmesine neden olabilir.

]> 3..2..1 ... ve kademeli

Yukarıdaki kod, daha incelikli bir DOS saldırısına da izin verir: harici istekler, yerel bir uygulama veya sunucu kaynaklarını paylaşan diğer herhangi bir uygulama için uyarlanmalıdır. Sonuç olarak, sistem kendi kendine saldırır: XML ayrıştırıcı kullanarak harici varlıkları çözme (çözme) girişimleri, yerel uygulamalara birçok istek gönderilmesine ve çok fazla sunucu kaynağının tüketilmesine neden olur. Bu saldırı, bir DOS saldırısını daha da gerçekleştirmek için bir XXE saldırısının etkisini artırmak için kullanılabilir.

XML varlık uzantısı koruması

Koruma yöntemleri, tekli XXE saldırıları durumundakiyle aynıdır. Özel XML varlıklarının yerel dosyalara ve ayrıca işlevlere çözünürlüğünü (çözünürlüğünü) devre dışı bırakmak gerekir; libxml2'ye dayalı tüm PHP XML uzantıları için genel olarak geçerli olan aşağıdaki işlevle harici HTTP isteklerini devre dışı bırakın.

libxml_disable_entity_loader (doğru);

Ancak PHP, DOCTYPE aracılığıyla XML DTD'leri kullanan özel varlıkların tanımını tamamen devre dışı bırakmanın açık bir yolunu uygulamaz. PHP sabit LIBXML_NOENT tanımlar, ayrıca DOMDocument :: $ replaceEntities genel özelliği vardır, ancak durumu iyileştirmezler. Görünüşe göre kendi geçici çözüm kümelerinizi kullanmanız gerekiyor.

libxml2, varlıkların özyinelemeli ayrıştırılmasına karşı doğuştan gelen bir hoşgörüsüzlüğe sahiptir, bu nedenle hata günlüğünüz bir Noel ağacı gibi süslenecektir. Bu nedenle, özyinelemeli varlıklara karşı özel bir koruma uygulamamız için özel bir ihtiyacımız yok; libxml2'nin nüksetmesi durumunda bir şeyler yapılması gerekmesine rağmen.

Dolayısıyla birincil yeni tehdit, kaba XML bombası veya genel varlık uzantısı yaklaşımlarıdır. Bu saldırılar, yerel veya uzak sistem çağrıları veya varlık özyineleme gerektirmez. Temel olarak, tek çözüm, bir DOCTYPE içeriyorsa XML'i silmek veya temizlemektir. DOCTYPE'ı kullanmamız gerekmiyorsa ve onu güvenilir bir güvenilir kaynaktan, yani kimliği doğrulanmış bir HTTPS bağlantısı aracılığıyla almadıysak, silmek daha güvenlidir. Aksi takdirde, PHP bize DTD'yi devre dışı bırakmak için bir çalışma seçeneği sunmadığından, kendi kendine yapılan bir mantık oluşturmamız gerekir. libxml_disable_entity_loader'ı (TRUE) çağırabileceğinizi varsayarsak, aşağıdaki kod güvenli olacaktır çünkü varlık, uzantının bulaştığı düğüm değerine erişim olana kadar genişlemeyecektir. Ve bu, bu kontrol sırasında olmayacak.

$ dom = yeni DOMDocument; $ dom-> loadXML ($ xml); foreach ($ dom-> childNodes as $ child) (if ($ child-> nodeType === XML_DOCUMENT_TYPE_NODE) ​​​​(yeni at \ InvalidArgumentException ("Geçersiz XML: Yasadışı DOCTYPE kullanımı algılandı"));

Tabii ki, yine de güvenli tarafta olmanız ve libxml_disable_entity_loader'ı DOĞRU olarak ayarlamanız gerekir, böylece XML ilk yüklendiğinde harici varlıklara yapılan başvurular çözülmez. Bu, ayrıştırıcının varlık ayrıştırmasını kontrol etmek için kapsamlı bir seçenekler grubuna sahip olmadığı sürece, XML ayrıştırıcısının libxml2'ye bağlı olmadığı tek koruma olabilir.

SimpleXML kullanmayı düşünüyorsanız, simplexml_import_dom () işlevini kullanarak doğrulanmış bir DOMDocument nesnesini içe aktarabileceğinizi unutmayın.