$ _REQUEST [] kullanmanın nesi yanlış?

Burada $_REQUESTdeğişkeni kullanmamayı söyleyen bir dizi gönderi gördüm . Genelde yapmam ama bazen uygun. Bunun nesi var?

Her ikisinden $_GETve $_POSTbirleşik bir şekilde girdi almakta kesinlikle yanlış bir şey yoktur . Aslında neredeyse her zaman yapmak istediğiniz şey bu:

• Genellikle GET aracılığıyla gönderilen düz bir idempotent isteği için, istediğiniz veri miktarının bir URL'ye sığmama olasılığı vardır, bu nedenle pratik bir mesele olarak POST isteğine dönüştürülmüştür.

• gerçek bir etkisi olan bir istek için, POST yöntemiyle gönderilip gönderilmediğini kontrol etmeniz gerekir. Ancak bunu yapmanın yolu $_SERVER['REQUEST_METHOD'], $_POSTbir GET için boş olmaya güvenmek değil, açıkça kontrol etmektir . Her neyse, yöntem buysa, POSTyine de bazı sorgu parametrelerini URL'den almak isteyebilirsiniz.

Hayır, sorunun $_REQUESTGET ve POST parametrelerini karıştırmakla ilgisi yok. Aynı zamanda, varsayılan olarak içerir $_COOKIE. Çerezler gerçekten de form gönderme parametreleri gibi değildir: neredeyse hiçbir zaman onlara aynı şekilde davranmak istemezsiniz.

Sitenizde yanlışlıkla form parametrelerinizden biriyle aynı ada sahip bir çerez seti alırsanız, bu parametreye dayanan formlar, beklenen parametreleri geçersiz kılan çerez değerleri nedeniyle gizemli bir şekilde düzgün çalışmayı durduracaktır. Aynı sitede birden fazla uygulamanız varsa bunu yapmak çok kolaydır ve artık kullanmadığınız eski çerezlere sahip birkaç kullanıcınız olduğunda hata ayıklamak çok zor olabilir. - başka biri çoğalabilir.

PHP 5.3'teki request_order yapılandırması ile bu davranışı çok daha mantıklı GP(hayır C) sırayla değiştirebilirsiniz . Bunun mümkün olmadığı yerlerde, şahsen bundan kaçınırdım ve birleşik bir GET + POST dizisine ihtiyacım olursa, onu manuel olarak oluşturun.$_REQUEST

PHP Internals'daki bazı haber grubu gönderilerini araştırıyorum ve konuyla ilgili ilginç bir tartışma buldum. İlk iplik başka bir şey oldu, ama Stefan Esser, bir (değilse bir açıklama PHP dünyada) güvenlik uzmanı birkaç mesaj için $ _REQUEST kullanarak güvenlik yan etkileri doğru tartışmayı çevirdi.

PHP Internals'da Stefan Esser'den alıntı

$ _REQUEST, PHP'deki en büyük tasarım zayıflıklarından biridir. $ _REQUEST kullanan her uygulama, Büyük olasılıkla Gecikmeli Siteler Arası İstek Sahteciliği sorunlarına karşı savunmasızdır. (Bu, temel olarak, örneğin (yaş) adlı bir çerez varsa, her zaman GET / POST içeriğinin üzerine yazacağı ve bu nedenle istenmeyen istekler gerçekleştirileceği anlamına gelir)

ve aynı ileti dizisine daha sonraki bir yanıtta

Bu, birinin GET, POST'u taklit edebilmesi ile ilgili değildir; COOKIE değişkenleri. Bu, COOKIE'lerin REQUEST'teki GET ve POST verilerinin üzerine yazacağı gerçeğiyle ilgilidir.

Bu nedenle tarayıcınıza örn. Action = logout yazan bir çerez bulaştırabilirim ve o günden itibaren uygulamayı artık kullanamazsınız çünkü REQUEST [action] oturumunu sonsuza kadar kapatacaktır (çerezi manuel olarak silene kadar).

Ve size bir COOKIE bulaştırmak çok basit ...
a) Bir alt alandaki herhangi bir uygulamada bir XSS vuln kullanabilirim
b) Sahip olduğunuzda * .co.uk veya * .co.kr için bir çerez ayarlamayı denediniz. tek alan var mı?
c) Diğer alanlar arası yollar ne olursa olsun ...

Ve bunun bir sorun olmadığına inanıyorsanız, size birkaç PHP sürümünün yalnızca beyaz sayfalar döndürmesiyle sonuçlanan fe a * .co.kr tanımlama bilgisini ayarlamanın basit bir olasılığı olduğunu söyleyebilirim. Düşünün: * .co.kr'deki tüm PHP sayfalarını öldürmek için yalnızca tek bir çerez

Ve * .co.kr için geçerli olan bir çerezde, + PHPSESSID = illegal olarak adlandırılan bir değişkende geçersiz bir oturum kimliği ayarlayarak, PHP oturumlarını kullanarak Kore'deki her PHP uygulamasında hala DOS yapabilirsiniz ...

Birkaç gönderi için tartışma devam ediyor ve okumak ilginç.

Gördüğünüz gibi, $ _REQUEST ile ilgili temel sorun, $ _GET ve $ _POST'tan verilere sahip olması değil, aynı zamanda $ _COOKIE'den gelen verilere sahip olmasıdır. Listedeki diğer bazı kişiler, $ _REQUEST'in doldurulduğu sıranın değiştirilmesini önerdiler, örneğin önce $ _COOKIE ile doldurmak gibi, ancak bu, örneğin Oturum yönetimi gibi birçok başka olası soruna yol açabilir .

$ _REQUEST globalden $ _COOKIES öğesini tamamen atlayabilirsiniz, böylece diğer diziler tarafından üzerine yazılmaz (aslında, değişken_order ini ayarındaki PHP kılavuzu gibi, standart içeriğinin herhangi bir kombinasyonuyla sınırlayabilirsiniz. bize söyler:

değişken_sırası EGPCS (Ortam, Get, Post, Çerez ve Sunucu) değişken ayrıştırma sırasını belirler. Örneğin, değişkenler_sırası "SP" olarak ayarlanmışsa, PHP, $ _SERVER ve $ _POST süper küresellerini oluşturacak, ancak $ _ENV, $ _GET ve $ _COOKIE oluşturmayacaktır. "" Olarak ayarlamak, süper küresellerin ayarlanmayacağı anlamına gelir.

Ancak yine de, $ _REQUEST'i tamamen kullanmamayı düşünebilirsiniz, çünkü PHP'de kendi globallerinde Environment, Get, Post, Cookie ve Server'a erişebilir ve bir saldırı vektörüne daha az sahip olabilirsiniz. Yine de bu verileri sterilize etmeniz gerekiyor, ancak endişelenmeniz gereken bir şey yok.

Şimdi, $ _REQUEST'in neden var olduğunu ve neden kaldırılmadığını merak edebilirsiniz. Bu, PHP Internals'da da soruldu. Rasmus Lerdorf'tan $ _REQUEST neden var? PHP Internals'da

Buna benzer şeyleri ne kadar çok kaldırırsak, insanların PHP'nin daha yeni, daha hızlı ve daha güvenli sürümlerine hızla geçmesi o kadar zorlaşır. Bu, herkes için birkaç "çirkin" eski özellikten çok daha fazla hayal kırıklığına neden olur. İyi bir teknik neden, performans veya güvenlik varsa, o zaman buna iyice bakmamız gerekir. Bu durumda, bakmamız gereken şey $ _REQUEST'i kaldırmamız gerekip gerekmediği değil, çerez verilerini ondan kaldırmamız gerekip gerekmediğidir. Benimkiler de dahil olmak üzere birçok yapılandırma bunu zaten yapıyor ve $ _REQUEST'e çerezleri dahil etmemek için güçlü bir geçerli güvenlik nedeni var. Çoğu kişi $ _REQUEST'i GET veya POST'u ifade etmek için kullanır, bunun çerezleri de içerebileceğinin farkında olmadan ve bu tür kötü adamlar potansiyel olarak bazı çerez yerleştirme hileleri yapabilir ve saf uygulamaları bozabilir.

Neyse, umarım bu biraz ışık tutar.

$_REQUESTher türlü isteği ifade eder (GET, POST vb ..). Bu bazen yararlıdır, ancak genellikle tam yöntemi ($ _GET, $ _POST vb.) Belirtmek daha iyidir.

$_REQUEST basit-orta karmaşıklıktaki veri dönüşümlerinin genellikle SQL'de bildirilmek yerine uygulama kodunda gerçekleştirilmesiyle aynı nedenden dolayı genellikle zararlı olarak kabul edilir: bazı programcılar berbat.

Bu nedenle, biri $_REQUESTher yerde kullanma eğilimindeyse , GET aracılığıyla POST yoluyla yapabileceğim her şeyi yapabilirim, bu da <img>(kötü niyetli) sitemde e-ticaret modülünüze giriş yapan kullanıcıların ürünleri sessizce satın almasına neden olan etiketleri oluşturması anlamına gelir veya ben tehlikeli eylemlere veya hassas bilgilerin açığa çıkmasına (muhtemelen benim için) neden olacak bağlantıları tıklamalarına neden olabilir.

Ancak bunun nedeni acemi veya en azından deneyimsiz bir PHP programcısının basit hatalar yapmasıdır. Öncelikle, hangi türdeki verilerin ne zaman uygun olduğunu bilin. Örneğin, URLEncoding, XML veya JSON'da yanıtlar döndürebilen bir web servisim var. Uygulama, HTTP_ACCEPT başlığını kontrol ederek yanıtın nasıl biçimlendirileceğine karar verir, ancak formatparametreyi göndererek özellikle bir taneye zorlanabilir .

Biçim parametresinin içeriğini kontrol ederken, çok sayıda faktöre bağlı olarak sorgu dizesi veya son veriler yoluyla gönderilebilir, en önemlisi çağıran uygulamaların kendi isteğiyle karıştırılmış "& format = json" isteyip istemediğidir. Bu durumda, $_REQUESTçok kullanışlıdır çünkü beni böyle bir şey yazmak zorunda bırakmaz:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

Daha fazla konuşmayacağım, ancak $_REQUESTkullanımın caydırılmadığını söylemem yeterli çünkü doğası gereği tehlikeli - bu sadece kendisinden istenenleri tam olarak yapan başka bir araçtır, bu çıkarımları anlasanız da anlamasanız da - Bu soruna neden olan fakir, tembel veya deneyimsiz bir programcının zayıf, tembel veya bilgisiz kararı.

Nasıl $_REQUESTgüvenle kullanılır

1. Verilerinizi bilin : Ne tür veriler elde edeceğiniz konusunda bir beklentiniz olmalıdır, bu nedenle verileri uygun şekilde sterilize edin. Bir veritabanı için veri? addslashes()veya *_escape_string(). Kullanıcıya geri mi gösterecek? htmlentities()veya htmlspecialchars(). Sayısal veri mi bekliyorsunuz? is_numeric()veya ctype_digit(). Aslında filter_input()ve ilgili işlevleri, verileri kontrol edip sterilize etmekten başka hiçbir şey yapmayacak şekilde tasarlanmıştır. Her zaman bu araçları kullanın.
2. Kullanıcı tarafından sağlanan süper küresel verilerine doğrudan erişmeyin . Her seferinde verilerinizi temizlemeyi alışkanlık haline getirin ve verilerinizi, adil olsa bile temiz değişkenlere taşıyın $post_clean. Alternatif olarak, doğrudan süper küresellerde temizleyebilirsiniz, ancak ayrı bir değişken kullanmayı savunmamın nedeni, bunu yapmanın koddaki güvenlik açıklarını tespit etmeyi kolaylaştırmasıdır, çünkü sterilize edilmiş eşdeğerini değil de doğrudan bir süper küresel olanı işaret eden herhangi bir şey tehlikeli bir hata olarak kabul edilir. .
3. Verinizin nereden gelmesi gerektiğini bilin. Örneğime yukarıdan bakarsak, yanıt biçimi değişkeninin GET veya POST yoluyla gönderilmesine izin vermek tamamen mantıklıdır. Ayrıca "eylem" değişkeninin her iki yöntemle de gönderilmesine izin veriyorum. Bununla birlikte, eylemlerin kendilerinin hangi HTTP Fiilinin kabul edilebilir olduğuna dair çok özel gereksinimleri vardır . Örneğin, hizmet tarafından kullanılan verilerde değişiklik yapan işlevler yalnızca POST yoluyla gönderilebilir. Ayrıcalıklı olmayan veya düşük olan belirli veri türleri için istekler (dinamik olarak oluşturulmuş harita görüntüleri gibi), her iki yöntemden gelen isteklere yanıt olarak sunulabilir.

Sonuç olarak, şu basit kuralı unutmayın:

GÜVENLİK YAPTIĞINIZ ŞEY, İNSANLAR!

DÜZENLE:

Ben kuvvetle bobince tavsiyesine tavsiye: Eğer ayarlayabilirsiniz eğer request_order"GP" için php.ini içinde parametreyi; yani, çerez bileşeni yoktur. Çerez verilerinin neredeyse hiçbir zaman sorgu dizesi veya postdata ile karşılaştırılabilir olduğu düşünülmemesi gerektiğinden, vakaların% 98'inde bunun için neredeyse hiçbir mantıklı mantık yoktur.

PS, Anekdot!

$_REQUESTSüper küresel bir yolla erişilebilen verileri basitçe depolamak için bir yer düşünen bir programcı tanıyordum . Önemli kullanıcı adları ve şifreler, dosyaların yolları, siz adlandırın ve içinde saklandı $_REQUEST. Bu değişkenin nasıl davrandığını ona söylediğimde (ne yazık ki komik olmasa da) biraz şaşırmıştı. Söylemeye gerek yok, bu uygulama kaldırıldı.

GET istekleri idempotent olmalıdır ve POST istekleri genellikle değildir. Bu, verilerin içinde $_GETve $_POSTgenellikle farklı şekillerde kullanılması gerektiği anlamına gelir .

Uygulamanız kaynaklı verileri kullanıyorsa $_REQUEST, GET'in idempotansını ihlal eden hem GET hem de POST istekleri için aynı şekilde davranacaktır.

Belirsiz. Sen yok gerçekten o yazıyı almak ve çerez verilerini taşır çünkü verileri size nasıl geldiğini biliyorum. Teslimat yöntemini bilmeniz veya kısıtlamanız gerekmedikçe , bunun her zaman kötü bir şey olduğunu düşünmüyorum .

Aslında kullanmayı seviyorum. Verilerin çoğunun POST edildiği arama formları gibi şeyler için kullanışlı olabilecek GET veya POST'u kullanma esnekliği sağlar, ancak bazen belirli bir aramaya bağlantı demek isteyebilirsiniz, böylece bunun yerine GET parametrelerini kullanabilirsiniz. .

Ayrıca, diğer birçok dile (örneğin ASP.NET) bakarsanız, GET ve POST değişkenleri arasında hiçbir ayrım yapmazlar.

ETA :

COOKIE değerlerini almak için REQUEST'i hiç kullanmadım, ancak Kyle Butt'ın bu yazıdaki yorumlarda harika bir noktaya değindiğini düşünüyorum. COOKIE değerlerini almak için TALEP'i kullanmak iyi bir fikir DEĞİLDİR. Bunu yaparsanız, siteler arası istek sahteciliği için gerçek bir potansiyel olduğu konusunda haklı olduğuna inanıyorum.

Ayrıca REQUEST'e yüklenme sırası php.ini'deki yapılandırma parametreleri tarafından kontrol edilir (değişken_sırası ve istek_sırası). Öyleyse, hem POST hem de GET yoluyla aynı değişkene sahipseniz, hangisinin gerçekte REQUEST'e gireceği bu ini ayarlarına bağlıdır. Bu, belirli bir sıraya bağlıysanız ve bu ayarlar beklediğinizden farklı şekilde yapılandırılırsa taşınabilirliği etkileyebilir.

POST'un ne zaman, GET'in ne zaman ve bir çerezin ne zaman kullanılacağını anlamak önemlidir. $ _REQUEST ile baktığınız değer bunların herhangi birinden gelebilirdi. Bir POST veya GET'ten veya bir ÇEREZDEN değer almayı bekliyorsanız, kodunuzu okuyan biri için $ _REQUEST yerine belirli değişkeni kullanmak daha bilgilendiricidir.

Bir başkası da tüm POST'ların veya çerezlerin GET'ler tarafından geçersiz kılınmasını istemediğinizi belirtti çünkü hepsi için farklı siteler arası kurallar vardır, örneğin $ _REQUEST kullanırken ajax verilerini döndürürseniz savunmasızsınızdır. siteler arası komut dosyası saldırısına.

$_REQUESTGET ile kullanmak kötü bir fikir değildir.

• POST değerlerini yüklemek için kullanırsanız, siteler arası istek sahteciliği riskiyle karşılaşırsınız
• Çerez değerlerini yüklemek için kullanırsanız, yine siteler arası istek sahteciliği riskine girersiniz

Ve GET ile bile yazmak $_GETdaha kısadır $_REQUEST;)

Yalnızca geçerli url'yi veya ana bilgisayar adını almak istiyorsanız kullanılabilir, ancak bu URL'den & simgesini kullanarak parmetreler gibi verileri gerçekten ayrıştırmak için bu muhtemelen iyi bir fikir değildir. Genel olarak, yapmaya çalıştığınız şeyin belirsiz bir tanımını kullanmak istemezsiniz. Spesifik olmanız gerekiyorsa, $ _REQUEST'in kötü olduğu yer burasıysa, spesifik olmanıza gerek yoksa kullanmaktan çekinmeyin. Düşünürdüm.

Hangi verileri istediğinizi biliyorsanız, bunu açıkça istemelisiniz. IMO, GET ve POST iki farklı hayvandır ve neden gönderi verilerini ve sorgu dizelerini karıştırmanız gerektiğine dair iyi bir neden düşünemiyorum. Eğer biri varsa, ilgilenirim.

Komut dosyalarınız GET veya POST'a aynı şekilde yanıt verebilecekse $ _REQUEST kullanmak daha uygun olabilir. Bunun son derece nadir bir durum olması gerektiğini ve çoğu durumda iki ayrı kavramı ele almak veya en azından yöntemi kontrol etmek ve doğru değişkenleri seçmek için iki ayrı fonksiyonun tercih edildiğini iddia ediyorum. Değişkenlerin nereden geldiği konusunda çapraz referans gerekmediğinde program akışını takip etmek genellikle çok daha kolaydır. Kodunuzu 6 ay içinde tutması gereken kişiye karşı nazik olun. Sen olabilirsin.

REQUEST değişkenindeki tanımlama bilgileri ve ortam değişkenlerinin neden olduğu güvenlik sorunlarına ve WTF'lere ek olarak (beni GLOBAL üzerinde başlatmayın), PHP, PUT ve DELETE gibi diğer yöntemleri yerel olarak desteklemeye başlarsa gelecekte neler olabileceğini düşünün. Bunların REQUEST süper küreseliyle birleştirilmesi son derece düşük bir ihtimal olsa da, değişken_sırası ayarında isteğe bağlı olarak dahil edilebilmeleri mümkündür. Yani REQUEST'in neyi barındırdığına ve neyin öncelikli olduğuna dair hiçbir fikriniz yok, özellikle de kodunuz bir üçüncü taraf sunucuya yerleştirilmişse.

POST, GET'ten daha güvenli mi? Pek sayılmaz. GET'i pratik olan yerlerde kullanmak daha iyidir çünkü günlüklerinizde uygulamanızın saldırıya uğradığında nasıl kullanıldığını görmek daha kolaydır. POST, alan durumunu etkileyen işlemler için daha iyidir çünkü örümcekler genellikle onları takip etmez ve tahmini getirme mekanizmaları CMS'nizde oturum açtığınızda tüm içeriğinizi silmez. Bununla birlikte, soru GET ve POST'un yararları ile ilgili değildi, alıcının gelen verileri nasıl ele alması gerektiği ve bunları birleştirmenin neden kötü olduğu ile ilgiliydi, bu yüzden bu gerçekten sadece bir BTW.

Bence bununla ilgili bir sorun yok $_REQUEST, ancak 3 kaynaktan (GPC) gelen değişkenlerin bir koleksiyonu olduğu için onu kullanırken dikkatli olmalıyız.

Sanırım $_REQUESTeski programları yeni php sürümleriyle uyumlu hale getirmek için hala mevcut, ancak yeni projelere başlarsak (yeni kütüphaneler dahil) $_REQUESTprogramları daha net hale getirmek için artık kullanmamamız gerektiğini düşünüyorum . Hatta kullanımlarını silme düşünmelisiniz $_REQUEST, çünkü özellikle büyük gönderilen metin verilerin işlenmesinde ve program açık yapmak için bir sarıcı işlevi ile değiştirerek $_REQUESTkopyalarını içerir $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Darren Cook: "php 5.3'ten beri varsayılan php.ini sadece GET ve POST verilerinin yerleştirildiğini söylüyor $_REQUEST. Bkz. Php.net/request_order Çerez verilerinin içeride olmasını beklerken $_REQUESTve neden olmadığını merak ederken bu geriye dönük uyumluluk kesintisine rastladım ' t çalışıyor! "

Wow ... az önce bazı betiklerim PHP 5.3'e yükseltme nedeniyle çalışmayı durdurdu . Aynı şeyi yaptım: $_REQUESTDeğişken kullanılırken çerezlerin ayarlanacağını varsayın . Yükseltme ile tam olarak çalışmayı durdurdu.

Şimdi çerez değerlerini ayrı ayrı çağırıyorum $_COOKIE["Cookie_name"]...

Temel sorun, diğerlerinin de söylediği gibi, çerez içermesidir.

PHP 7'de bunu yapabilirsiniz:

$request = array_merge($_GET ?? [], $_POST ?? []);

Bu, tanımlama bilgisi sorununu ortadan kaldırır ve size en kötü ihtimalle boş bir dizi ve en iyi durumda $ _GET ile $ _POST'un birleşmesi ve ikincisi öncelikli hale gelir. Sorgu dizesi aracılığıyla parametrelerin URL enjeksiyonuna izin vermekle fazla uğraşmıyorsanız, oldukça kullanışlıdır.

Çok güvensiz. Ayrıca bir POST veya GET veya başka bir istek alıp almadığınızı bilmediğiniz için garip. Uygulamalarınızı tasarlarken aralarındaki farkı gerçekten bilmelisiniz. GET, URL'de iletildiği için çok güvensizdir ve sayfada gezinme dışında neredeyse hiçbir şey için uygun değildir. POST, kendi başına güvenli olmasa da, bir güvenlik seviyesi sağlar.