Soru Bir cgi-bin / php POST istek saldırısından sunucular nasıl güvenli hale getirilir


Sunucumuzda aşağıdakileri içeren bir POST isteği var:

%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%F%69%6E%70%75%74+%2D%6E

URL kod çözümünü kullanarak şunu çevirir:

cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env file=php://input -n

Benzer gibi görünüyor Ubuntu 14.04'te Nginx üzerinden garip URL istekleri, kötü niyetli kullanıcı ne yapmaya çalışıyor?. Talep hangi senaryoda çalışır? 404'ü gönderdiğimiz günlüklerden görüyorum ama savunmasız olabilecek başka bir kutumuz olmadığından emin olmak istiyorum.


4
2017-08-09 10:53


Menşei


Her zaman, sunucuların kapatıldığında, ağa bağlı tüm sistemlerden kaldırıldığında ya da başka bir şekilde dünyadan izole edildiğinde saldırıya karşı en savunmasız olduklarını gördüm. - MSC
Buradaki soru, bazı tavsiyelerde bulunur; serverfault.com/questions/453732/... - yagmoth555♦


Cevaplar:


Yıllar önce insanlar PHP'yi bir CGI betiği olarak çalıştırdılar (FastCGI bile değil, henüz yoktu!) Böylece Apache'yi düşük performanslı prefork MPM'den yeni ve biraz daha yüksek performanslı çalışan MPM'ye çevirebilsinler. (Ve nginx henüz bilinmiyordu, uzun zaman önceydi.) Bir sunucu PHP'yi bir CGI betiği olarak çalıştıracak şekilde ayarlanmışsa, o zaman PHP tercümanını doğrudan /cgi-bin/php.

PHP teknik olarak hala CGI olarak kurulabilirdi, ama insanların umduğundan daha fazla performans göstermediği ortaya çıktı, böylece FastCGI icat edildi. Tüm yüksek performanslı PHP siteleri, genellikle nginx ile veya bazen Apache'nin olay MPM'si ile FastCGI / FPM kullanır. FastCGI / FPM, PHP'nin doğrudan çağrılmasına izin vermediği için buna karşı savunmasız değildir. /cgi-bin.

Sunucunuz CGI olarak çalıştırılan eski bir çürüyen kazık yığını değilse, bu istek hakkında endişelenmenize gerek yoktur.


14
2017-08-09 12:49



Bazı nedenlerden dolayı 'Yıllar önce insanlar ...' yazdığınız zaman, Apache 2.x'teki eski sömürüyü düşündüm. Parmaklarımın ucunda ama kediye sık sık kullanılıyordu / Etc / passwd Yine de, her şey gibi, tüm sunucularda çalışmaz. Bu 1990'lı yıllarda oldu, belki de 2000'lerin başına kadar gitti? Ben hatırlamıyorum. Sağ. Bunu neden düşündüğümü biliyorum - phf yerine php... - Pryftan
@Pryftan Yıllar boyunca çok fazla istismar var ... ama phf muğlak bir şekilde tanıdık geliyor. Oldukça eminim ki, bu bin yıl boyunca etrafta dolanırken çoktan gitmişti. - Michael Hampton♦
Tek bildiğim, 1990'ların ortalarındaydı. Apache'nin yeni bir ağacının piyasaya sürüldüğü varsayıldığında bile, tüm sunucuların güncellenmesi için uzun bir zaman harcayacağı (daha sonra standart bilgisayarlarda olduğu gibi - Windows XP gibi iyi bir örnek olduğu gibi) ) idi. - Pryftan


Genel sorun komuta enjeksiyon. Bir 404'ü gönderen modern bir web sunucusunun bu özelliğe karşı savunmasız olmasına rağmen, php yürütme yönüne izin veren eski güvensiz CGI konfigürasyonları ile daha kolay.

Gerekmediğinde CGI'yi kaldırarak, web sunucusunu dosya izinleriyle ve belki de SELinux ile kilitleyerek ve web uygulamalarınızı güvenli hale getirerek önlersiniz. Açık Web Uygulama Güvenliği Proje Test Projesi  bazı genel tavsiye var.


4
2017-08-09 13:08





Hatalı ödülünüzün bir parçası olmak isteyen saldırgan saldırganlar veya pandomerler, web uygulamaları yazarken yaptığınız yaygın hatalar için web sitenizi test eder.

Webapps'inizi başarılı bir saldırıya karşı güçlendirmenin birkaç yolu vardır:

  • Her zaman olduğu gibi web geliştiricilerinizi iyi güvenlik uygulamalarını kullanarak eğitin. OWASP iyi bir başlangıç ​​noktasıdır: https://www.owasp.org/index.php/OWASP_Guide_Project
  • uygulamalarınızı bir Web Uygulaması Güvenlik Duvarı'nın arkasına koyun. (WAF) bir WAF tüm gelen istekleri tarayacak ve sadece iyi olmadıklarına benzeyenleri indirecektir. Kullanımı kolay bir bulut çözümü https://www.cloudflare.com/lp/waf-a/ ama orada başkaları da var, bulut var, veri merkezinizde yükleyebileceğiniz, sunucularınızda çalıştırabileceğiniz cihazlar (palo alto, fortigate, checkpoint, watchguard)
  • Bir kalem testçisinin altyapınızı (düzenli olarak) araştırmasına izin verin, eğer sisteminiz hakkında bilgi ve belge verirseniz, bu testleri internette rastgele bir saldırgandan daha az kör hale getirebilecekse, sorunları daha sonra rastgele bulabilecekler. saldırgan ve bunları onarabilirsin. Bunu kendiniz yapmak isterseniz, OWASP harika bir kaynaktır: https://www.owasp.org/index.php/OWASP_Testing_Project

Bu seçeneklerden hiçbiri% 100 garantiye sahip değildir ve hepsini yapmasını öneririm.


3
2017-08-10 08:00





iyileştirme

sanitization

URL ve form verilerinin geçersiz karakterler için dezenfekte edilmesi gerekir. bir   Karakterlerin “kara listesi” bir seçenektir, ancak zor olabilir   Doğrulamak için tüm karakterleri düşünün. Ayrıca olabilir   Bazıları henüz keşfedilmemişti. İçeren “beyaz liste”   sadece izin verilen karakterler veya komut listesi oluşturulmalıdır   kullanıcı girişini doğrulayın. Yanı sıra cevapsız karakterler   keşfedilmemiş tehditler, bu listeyle ortadan kaldırılmalıdır.

Commannd enjeksiyon için dahil edilecek olan kara mavisi kara liste olabilir | ; & $ > < ' \ ! >> #

Pencereler için özel karakterler kaçmak veya filtrelemek, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , 

Linux için özel karakterleri kaçış veya filtreleme, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + , 

İzinler

Web uygulaması ve bileşenleri sıkı çalışmalıdır.   işletim sistemi komut yürütmesine izin vermeyen izinler. Deneyin   Tüm bu bilgileri Gray Box noktasından test etmek için doğrulamak   görünüm.

https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-013)

Ayrıca comodo kuralları ile Nginx'te modsecurity yükleyin.

https://waf.comodo.com/


-4
2017-08-09 14:19



Karartma kara listeye alma, bir güvenlik sorusu için asla doğru cevap değildir. Bahsettiğiniz tüm karakterler bir URL'de meşru bir şekilde gerçekleşebilir, veriyi asla boşvermeyiniz! Kullanamayacağınız konusunda nasıl hissedersiniz? + veya / veya ' veya () SE yazılarında mı? - marcelm
Birçoğumuz OWASP ile bağlantı kuruyoruz, ama sanırım dar bir alana odaklanmak doğru bir öncelik değil. Kullanımda değilse, modern bir web sunucusu kullanın eğer PHP kaldırın. Web sunucusunun keyfi programları yürütmesini engelle. Kötü amaçlı materyalleri filtrelemek için bir WAF ekleyin. Mümkünse web uygulamalarında OS komutlarını çalıştırmayın. Ve bunun gibi. - John Mahowald