Çoğu Ajax istekleri / çerçeveler Ajax v Sigara ajax isteklerini filtrelemek için kullanabileceğiniz bu özel başlığını ayarlamanız gerekir. Ben projelerde bol yanıt tipi (json / html) belirlemek için bunu kullanın:

if( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) && ( $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest' ) )
{
	// allow access....
} else {
	// ignore....
}

edit: You can add this yourself in your own Ajax requests with the following in your javascript code:

var xhrobj = new XMLHttpRequest();
xhrobj.setRequestHeader("X-Requested-With", "XMLHttpRequest");

ne kullanın: PHP oturumları + Ben bir istek yapmak her zaman gönderilen bir karma. Bu karma sunucu tarafında bir algoritma kullanılarak üretilir

Mmm ... Eğer _SESSION saklamak, hangi oturum başlangıcında bir kerelik şifre oluşturmak ve bu (bir kaptan gibi bir şey) yeniden iletmek istiyorum ajax çağrı için bir parametre ekleyebilirsiniz. Sadece o oturum için geçerli olacaktır.

Bu otomatik saldırılara karşı kalkan olur, ancak sitenize erişimi olan bir insan hala elle bu yapabileceğini, ancak daha karmaşık bir şey hazırlamak için bir temel olabilir.

Eğer hiç kimse doğrudan bu dosyayı ziyaret etmek gerekir ki ikna neden ben soru. İlk eylem gerçekten insanlar doğrudan sayfasını ziyaret edin ve bu olasılığa etrafında hareket olduğunu varsaymak gerekir. Eğer hala bu dosyaya erişimi kapatmak istiyor ikna iseniz o zaman $_SERVER kökeni olarak bu değişkenleri $_SERVER belirlemek zor olabilir ve değerleri güvenmiyor bilmeli başlıkları sahte olabilir. Bazı test i bu başlıkları ($_SERVER['HTTP_X_REQUESTED_WITH'] ve $_SERVER['HTTP_X_REQUESTED_WITH']) de güvenilmez bulundu etmedi.

Başlıklarına bakarak önerdi Bu konuya herkes bir şekilde ya da başka bir yanlıştır. Isteği her şey (HTTP_REFERER, HTTP_X_REQUESTED_WITH) paylaşılan sırlar dahil, tamamen beceriksiz değil, bir saldırgan tarafından taklit edilebilir [1].

Sitenize bir HTTP isteği yapmasını engellemek olamaz. Ne yapmak istediğinizi bir oturum tanımlama yoluyla, sitenizin bazı hassas parçası için bir istek yapmadan önce kimlik doğrulaması gerekir emin olun. Bir kullanıcı doğrulanmamış isteklerini yaparsa, orada dur ve onlara bir HTTP 403 verin.

Sizin örnek bir GET isteğini yapar, bu yüzden istek kaynak gereksinimleri ile ilgilidir sanırım [2]. Açıktır ki sahte istekleri (veya robots.txt dinlemek değil aptal arama tarayıcılarının) için kökenli olmaktan yeni süreçleri durdurmak için. Htaccess kuralları HTTP_REFERER veya HTTP_X_REQUESTED_WITH başlıklarında bazı basit sağlık kontrolleri yapmak, ama eğer saldırganın sahte Bu, PHP süreç olarak erken olmayan doğrulanmış istekleri için mümkün olduğunca çıkar emin olmak isteyeceksiniz.

[1] Bu istemci / sunucu uygulamaları ile temel sorunlardan biri. Bu işe yaramazsa neden burada: Eğer istemci uygulaması sunucuya kendi kimliğini doğrulamak için bir yol vardı Say - Bir gizli şifre ya da diğer bir yöntem olsun. App ihtiyacı bilgiler zorunlu uygulaması (şifre oralarda gizli, ya da her neyse) için erişilebilir. Bu kullanıcının bilgisayarında çalışır çünkü Ama, onlar da bu bilgilere erişim anlamına gelir: Tüm ihtiyaç duydukları kaynak bakmak için, ya da uygulaması ve sunucu arasındaki ikili veya ağ trafiği, ve sonunda onlar çözemezsin app doğrular ve onu çoğaltmak hangi mekanizma. Belki onlar bile kopyalamak olacak. Belki de sizin app ağır kaldırma (her zaman sadece app sahte kullanıcı girişi gönderebilirsiniz) yetinmek akıllı kesmek yazacağım. Ama ne kadar, onlar gerekli tüm bilgiler var ve aynı zamanda onu sahip app durdurmak değil ki o sahip onları durdurmak için hiçbir yolu yoktur.

[2] iyi tasarlanmış bir uygulama istekleri hiçbir yan etkileri var GET, bu yüzden bunları yaparken kimse sunucu üzerinde bir değişiklik yapmak mümkün olacak. Sizin POST istekleri her zaman sadece kimliği doğrulanmış kullanıcılar onları aramak izin, seans artı CSRF belirteci ile doğrulanmış olmalıdır. Birisi bu saldırırsa, onlar sizin bir hesabınız varsa ve bu hesabı kapatmak istiyorum demektir.

Senin açıklamasına dayanarak, ben düpedüz yaygın istismarı önlemek için çalışıyoruz, ama varsayalım bir kaya gibi sağlam bir çözüm gerekmez.

Bu itibaren, ben çerezleri kullanarak öneririm:

Sadece setcookie() func.php üzerine doğru değerler için AJAX ve çek $_COOKIE kullanarak sayfada. Bu size func.php çağıran herkes son zamanlarda sitenizi ziyaret ettiğini bazı makul güvence verecektir.

Eğer meraklısı almak istiyorsanız, size çerez sahte ya da istismar ediliyor olmadığını güvencesi için (zaten bunu yapabilirsiniz) benzersiz oturum kimlikleri belirlemek ve doğrulamak olabilir.

GET dosya üzerinde istekleri ve aynı sunucudan gelen sadece kabul DİREKLERİ engellemek için durum olmaz mı?

Bu yaparken de hiçbir anlamı yoktur. Bu herhangi bir gerçek güvenlik katmıyor.

Bir istek (HTTP_X_REQUESTED_WITH gibi) Ajax ile yapılıyor olduğunu gösteren tüm başlıkları istemci tarafında sahte olabilir.

Ajax hassas verileri hizmet, ya da hassas operasyonlar erişim sağlayan ise, bir giriş sistemi gibi, düzgün güvenlik eklemek gerekir.