Biyografi xmlrpc php.ini Programlama yarışmaları. XML RPC'yi engelleme

XML-RPC'ye giriş

İnternette kullanıcılara belirli bilgiler sağlayan birçok farklı kaynak vardır. Bu, sıradan statik sayfalar anlamına gelmez, örneğin bir veritabanından veya arşivlerden alınan veriler anlamına gelir. Bu, finansal verilerin (döviz kurları, menkul kıymet fiyatları verileri), hava durumu verilerinin veya haberler, makaleler, forumlardan gelen mesajlar gibi daha hacimli bilgilerin bir arşivi olabilir. Bu tür bilgiler sayfa ziyaretçisine örneğin bir form aracılığıyla, bir talebe yanıt olarak sunulabileceği gibi her seferinde dinamik olarak da oluşturulabilir. Ancak zorluk şu ki, bu tür bilgilere çoğu zaman son kullanıcı - bir kişi - değil, bu verileri hesaplamaları veya diğer ihtiyaçları için kullanacak diğer sistemler ve programlar tarafından ihtiyaç duyulur.

Gerçek örnek: Bir bankacılık web sitesinin döviz fiyatlarını görüntüleyen bir sayfası. Sayfaya normal bir kullanıcı olarak bir tarayıcı aracılığıyla erişirseniz, tüm sayfa tasarımını, banner'ları, menüleri ve aramanın gerçek amacını - para birimi tekliflerini "çerçeveleyen" diğer bilgileri görürsünüz. Bu teklifleri çevrimiçi mağazanıza girmeniz gerekiyorsa, gerekli verileri manuel olarak seçip pano aracılığıyla web sitenize aktarmak dışında yapacak başka bir şey kalmaz. Ve bunu her gün yapmanız gerekecek. Gerçekten çıkış yolu yok mu?

Sorunu doğrudan çözerseniz, hemen bir çözüm ortaya çıkar: veriye ihtiyaç duyan bir program (web sitesindeki komut dosyası), "normal kullanıcı" olarak sunucudan bir sayfa alır, ortaya çıkan html kodunu ayrıştırır (ayrıştırır) ve ondan gerekli bilgiler. Bu, normal bir düzenli ifadeyle veya herhangi bir html ayrıştırıcısı kullanılarak yapılabilir. Yaklaşımın zorluğu etkisizliğinde yatmaktadır. İlk olarak, verinin küçük bir kısmını almak için (para birimlerine ilişkin veriler kelimenin tam anlamıyla bir düzine veya iki karakterdir), en az birkaç on kilobayt olan sayfanın tamamını almanız gerekir. İkinci olarak, sayfa kodundaki herhangi bir değişiklikle (örneğin tasarım değişti veya başka bir şeyle), ayrıştırma algoritmamızın yeniden yapılması gerekecek. Ve bu oldukça fazla kaynak gerektirecektir.

Bu nedenle, geliştiriciler bir karara vardılar - herhangi bir yerde bulunabilen programlar arasında şeffaf (protokol ve iletim ortamı düzeyinde) ve kolay veri alışverişine izin verecek, herhangi bir dilde yazılabilecek bir tür evrensel mekanizma geliştirmek gerekiyor ve herhangi bir işletim sistemi altında ve herhangi bir donanım platformunda çalıştırın. Böyle bir mekanizmaya artık yüksek sesle "Web hizmetleri", "SOAP", "hizmet odaklı mimari" deniyor. Veri alışverişi için açık ve zaman içinde test edilmiş standartlar kullanılır - mesajları iletmek için HTTP protokolü kullanılır (ancak diğer protokoller de kullanılabilir - örneğin SMTP). Verilerin kendisi (örneğimizde döviz kurları) platformlar arası formatta, XML belgeleri biçiminde paketlenmiş olarak iletilir. Bu amaçla özel bir standart icat edildi - SABUN.

Evet, artık web hizmetleri, SOAP ve XML herkesin ağzında, aktif olarak uygulanmaya başlıyor ve IBM ve Microsoft gibi büyük şirketler, web hizmetlerinin tam olarak uygulanmasına yardımcı olmak için tasarlanmış yeni ürünler piyasaya sürüyor.

Ancak! Örneğin, bankanın web sitesinden çevrimiçi mağaza motoruna aktarılması gereken döviz kurları ile ilgili böyle bir çözüm çok zor olacaktır. Sonuçta, SOAP standardının açıklaması tek başına bir buçuk bin sayfa kadar müstehcen bir yer kaplıyor ve hepsi bu değil. Pratik kullanım için, aynı zamanda üçüncü parti kütüphaneler ve uzantılarla nasıl çalışılacağını öğrenmeniz (yalnızca PHP 5.0'dan başlayarak, SOAP ile çalışmak için bir kütüphane içerir) ve kendi kodunuzun yüzlerce ve binlerce satırını yazmayı öğrenmeniz gerekecektir. Ve birkaç harf ve rakam elde etmek için yapılan tüm bunlar açıkçası çok hantal ve mantıksız.

Bu nedenle, bilgi alışverişi için başka bir alternatif standart olduğu söylenebilir - XML-RPC. UserLand Software Inc. tarafından Microsoft'un katılımıyla geliştirilmiş olup, İnternet üzerinden uygulamalar arasında birleşik veri aktarımı için tasarlanmıştır. Gerçek web hizmetlerinin tüm "kurumsal" özelliklerinin gerekli olmadığı basit hizmetler oluştururken SOAP'ın yerini alabilir.

XML-RPC kısaltması ne anlama geliyor? RPC, Uzaktan Prosedür Çağrısı anlamına gelir. Bu, bir uygulamanın (ister sunucudaki bir komut dosyası ister istemci bilgisayardaki normal bir uygulama olsun) başka bir bilgisayarda fiziksel olarak uygulanan ve yürütülen bir yöntemi şeffaf bir şekilde kullanabileceği anlamına gelir. Burada XML, iletilen verileri tanımlamak için evrensel bir format sağlamak amacıyla kullanılır. Aktarım olarak HTTP protokolü, mesajları iletmek için kullanılır; bu, herhangi bir ağ cihazı (yönlendiriciler, güvenlik duvarları, proxy sunucuları) aracılığıyla sorunsuz bir şekilde veri alışverişinde bulunmanıza olanak tanır.

Ve bu nedenle, kullanmak için şunlara sahip olmanız gerekir: bir veya daha fazla yöntem sağlayan bir XML-RPC sunucusu, doğru bir istek oluşturabilen ve sunucu yanıtını işleyebilen ve ayrıca başarılı işlem için gerekli sunucu parametrelerini bilen bir XML-RPC istemcisi - adres, yöntem adı ve geçirilen parametreler.

XML-RPC ile yapılan tüm çalışmalar "istek-yanıt" modunda gerçekleşir; bu, hem işlem kavramlarının hem de gecikmeli arama yapma yeteneğinin (sunucu kaydettiği zaman) bulunduğu SOAP standardı ile teknoloji arasındaki farklardan biridir. istek ve gelecekte belirli bir zamanda yanıt verir). Bu ek özellikler, güçlü kurumsal hizmetler için daha kullanışlıdır; sunucuların geliştirilmesini ve desteklenmesini önemli ölçüde karmaşıklaştırır ve istemci çözümü geliştiricilerine ek gereksinimler yükler.

XML-RPC ile çalışma prosedürü bir istek oluşturmakla başlar. Tipik bir istek şuna benzer:

POST /RPC2 HTTP/1.0
Kullanıcı Aracısı: eshop-test/1.1.1 (FreeBSD)
Ana bilgisayar: sunucu.localnet.com
İçerik Türü: metin/xml
İçerik uzunluğu: 172

Test metodu
Merhaba XML-RPC!

İlk satırlar standart HTTP POST istek başlığını oluşturur. Gerekli parametreler ana bilgisayar, metin/xml olması gereken veri türü (MIME türü) ve mesaj uzunluğunu içerir. Standart ayrıca Kullanıcı Aracısı alanının doldurulması gerektiğini de belirtir ancak isteğe bağlı bir değer içerebilir.

Daha sonra XML belgesinin olağan başlığı gelir. İsteğin kök öğesi yalnızca bir tane olabilir ve alt düğümler gibi düğümleri içeremez. Bu, bir isteğin sunucuda yalnızca bir yöntemi çağırabileceği anlamına gelir.

Astar Test metodu TestMetod adlı bir yöntemi çağırdığımızı belirtir. Gerekirse burada yöntemi içeren programın veya modülün adını ve yolunu belirtebilirsiniz. XML-RPC spesifikasyonu, bir yöntemi belirtmek için kullanılabilecek karakter kümesine bazı kısıtlamalar getirse de, bunların nasıl yorumlanacağı tamamen sunucu uygulamasına bağlıdır.

Daha sonra iletilen parametreler ayarlanır. Bu bölüm bunun için kullanılmaktadır. İsteğe bağlı sayıda alt öğe içerebilir Etiket tarafından açıklanan parametreyi içerenler . Parametrelere ve veri türlerine biraz daha ileride bakacağız. Bizim versiyonumuzda, yönteme etiketin içine alınmış bir dize parametresi iletilir .

Tüm parametrelerin açıklamasını kapatma etiketleri takip eder. XML-RPC'deki istek ve yanıt normal XML belgeleridir, dolayısıyla tüm etiketlerin kapatılması gerekir. Ancak XML standardında mevcut olmalarına rağmen XML-RPC'de tek bir etiket yoktur.

Şimdi sunucunun cevabına bakalım. HTTP yanıt başlığı normaldir; istek başarıyla işlenirse sunucu bir HTTP/1.1 200 OK yanıtı döndürür. Tıpkı istekte olduğu gibi MIME türünü, mesaj uzunluğunu ve yanıt oluşturma tarihini doğru bir şekilde belirtmeniz gerekir.

Yanıt gövdesinin kendisi aşağıdaki gibidir:

doğru

Şimdi kök etiketi yerine etiket belirtildi Talep işlemenin sonuçlarını hemen içeren. Ne yazık ki, yanıt yöntem adını iletmiyor; bu nedenle, aynı anda farklı yöntemler çağrılırsa karışıklığı önlemek için onu istemci tarafında saklamalısınız.

İsteğiniz işlenirken bir hata oluştuysa, bunun yerine Yanıt öğeyi içerecektir Hatayı açıklayan bir yapının iç içe yerleştirileceği. Hata açıklaması sayısal bir hata kodu ve bir metin açıklaması içerir.

Şimdi XML-RPC'deki veri türlerine kısaca göz atalım. Toplamda 9 veri türü vardır; yedi basit tür ve 2 karmaşık tür. Her tür kendi etiketi veya etiket kümesiyle (karmaşık türler için) tanımlanır.

Basit türler:

Bütün sayılar- etiket veya ;

Boole türü- etiket , hem 0/1 hem de doğru/yanlış değerlerini alabilir;

ASCII dizesi- etiketle tanımlandı ve isteğe bağlı bir karakter dizisi içerebilir;

Kayan nokta sayıları- etiket , bir sayı işareti de içerebilir; kesirli kısım bir noktayla ayrılır;

tarih ve saat- etiketle tanımlandı ve iso8601 formatına uygun olmalıdır. Bu format, komut dosyalarında daha fazla işlem yapmak için biraz elverişsizdir, bu nedenle bir istek gönderilirken/alınırken her zaman dönüştürülür. Bu, kitaplık içindeki özel bir işlevle yapılabilir veya böyle bir işlev yoksa geliştiricinin tarihi manuel olarak dönüştürmesi gerekir.

Son basit tür ise base64 kodlu dize etiketiyle açıklanan . Bu tür evrenseldir; bu tür kodlama nedeniyle aktarılan verilerin hacmi artmasına rağmen, istemci ile sunucu arasında herhangi bir veri aktarımı için kullanılabilir. Ancak bu, protokolün metinsel yapısının ve özellikle XML formatının bir sonucudur.

Karmaşık türler yapılar ve dizilerle temsil edilir. Yapı kök eleman tarafından belirlenir isteğe bağlı sayıda öğe içerebilen , yapının her bir üyesini tanımlar. Bir yapı elemanı iki etiketle tanımlanır: birincisi, , üyenin adını açıklar, ikincisi, , üyenin değerini içerir (veri türünü açıklayan bir etiketle birlikte).

Dizilerin adı yoktur ve etiketiyle tanımlanır bir element içeren ve bir veya daha fazla alt öğe , belirli verilerin belirtildiği yer. Bir dizi, çok boyutlu dizileri tanımlamanıza olanak tanıyan diğer dizilerin yanı sıra herhangi bir sırayla başka türleri de içerebilir. Ayrıca bir dizi yapıyı da tanımlayabilirsiniz. Ancak dizinin bir adı olmaması bazı durumlarda kullanımını karmaşık hale getirir; karmaşık verileri aktarmak için bunların tekrar tekrar başka türlere paketlenmesi gerekir (örneğin, birkaç diziyi aktarmak için her diziyi ayrı ayrı bir yapıya paketleyebilirsiniz). ve ardından bu yapılardan bir dizi oluşturun).

Elbette birisi böyle bir veri türü listesinin çok zayıf olduğunu ve "genişletilmesine izin vermediğini" söyleyecektir. Evet, karmaşık nesneleri veya büyük miktarda veriyi aktarmanız gerekiyorsa SOAP kullanmak daha iyidir. Ve küçük, iddiasız uygulamalar için XML-RPC oldukça uygundur; üstelik çoğu zaman yetenekleri bile çok fazla olur! Dağıtım kolaylığı, hemen hemen her dil ve platform için çok sayıda kitaplık ve PHP'deki geniş destek göz önüne alındığında, XML-RPC'nin genellikle hiçbir rakibi yoktur. Her ne kadar evrensel bir çözüm olarak hemen tavsiye edilemese de, her özel durumda, koşullara göre karar verilmelidir.

Birkaç gün önce sitelerimin hosting üzerindeki yükünün önemli ölçüde arttığını fark ettim. Genellikle 100-120 "papağan" (CP) civarındayken, son birkaç günde 400-500 CP'ye yükseldi. Bunun iyi bir yanı yok çünkü hosting sahibi daha pahalı bir tarifeye geçebilir, hatta sitelere tamamen yakın erişime geçebilir, ben de araştırmaya başladım.

Ancak XML-RPC işlevselliğini koruyacak bir yöntem seçtim: XML-RPC Pingback'i Devre Dışı Bırak eklentisini yüklemek. Yalnızca "tehlikeli" pingback.ping ve pingback.extensions.getPingbacks yöntemlerini kaldırarak XML-RPC işlevselliğini bırakır. Eklenti kurulduktan sonra yalnızca etkinleştirilmesi gerekir; başka bir yapılandırmaya gerek yoktur.

Bu arada saldırganların erişimlerini engellemek için tüm saldırganların IP'lerini sitelerimin .htaccess dosyasına girdim. Dosyanın sonuna şunu ekledim:

Sipariş İzin Ver, Reddet Tüm Reddetlerden İzin Ver 5.196.5.116 37.59.120.214 92.222.35.159

Hepsi bu, artık xmlrpc.php kullanarak blogu daha sonraki saldırılara karşı güvenilir bir şekilde koruduk. Sitelerimiz, üçüncü taraf sitelere yapılan DDoS saldırılarının yanı sıra, isteklerle barındırmayı yüklemeyi durdurdu.

Hem xmlrpc istemcileri hem de sunucuları oluşturma desteği
PHP değerlerinden xmlrpc'ye tam otomatik veya tamamen manuel, ince taneli kodlama ve kod çözme
UTF8, Latin-1 ve ASCII karakter kodlamaları desteği. Php mbstring uzantısı etkinleştirildiğinde daha da fazla karakter seti desteklenir.
PHP cURL uzantısıyla hem isteklerin hem de yanıtların, çerezlerin, proxy'lerin, temel kimlik doğrulamanın ve https'nin, ntlm kimlik doğrulamasının ve canlı tutmanın http sıkıştırması desteği
Gelen xmlrpc isteğinin parametre türlerinin isteğe bağlı olarak doğrulanması
system.listMethods, system.methodHelp, system.multicall ve system.getCapaability yöntemleri desteği
için destek Ve xmlrpc'ye uzantılar
Mevcut php işlevini veya sınıf yöntemlerini web hizmetleri olarak kaydetme ve phpdoc yorumlarından katma değerli bilgiler çıkarma olanağı
Kitaplığa web tabanlı bir görsel hata ayıklayıcı dahildir

Gereksinimler

PHP 5.3.0 veya üzeri; 5.5 veya üzeri önerilir
Uzak sunucularla iletişim kurmak için SSL veya HTTP 1.1 kullanmak istiyorsanız php "curl" uzantısı gereklidir
ASCII, Latin-1, UTF-8 dışındaki karakter kümelerindeki isteklerin/yanıtların alınmasına izin vermek için php "mbstring" uzantısı gereklidir
php "xmlrpc" yerel uzantısı gerekli değildir, ancak kurulu olması durumunda bu kütüphanenin çalışmasına herhangi bir müdahale olmayacaktır.

İndirmek

Haberler

1 Temmuz 2017
Kitaplık sürümleri 4.2.0 ve 3.1.0 yayınlandı.
Sürüm notlarına Github'da ulaşılabilir
20 Ocak 2016
Kitaplık sürümü 4.0.0 yayınlandı.
Bu, API'nin geçmişi ortadan kaldıran ve günümüz PHP'sine geçişi başlatan büyük değişiklikleri ilk kez görüyor.
Ad alanları eklendi ve varsayılan karakter seti UTF-8'de kullanılıyor; mbstring desteği eklendi ve çok daha fazlası.
Değişikliklerin tam listesi için Github'a gidin
19 Nisan 2015
Kitaplık sürümü 3.0.1 yayınlandı.
15 Haziran 2014
Kitaplık sürümü 3.0.0 yayınlandı.

15 Aralık 2013
Proje GitHub'a taşındı

Çevrimiçi xmlrpc hata ayıklayıcısı

Bu kütüphanenin üzerine inşa edilmiş bir demo xmlrpc hata ayıklayıcı uygulaması http://gggeek.altervista.org/sw/xmlrpc/debugger/ adresinde aktiftir. Hata ayıklayıcıyı ör. SF demo sunucusunu sorgulayın veya ağ üzerinden erişilebiliyorsa kendi kişisel xmlrpc sunucunuzun hatalarını ayıklayın.

Gelişim

Tanım	Durum - güncellenme tarihi: 2009/07/26
Sürüm 2'den bu yana eklenen tüm özellikler için belgeleri güncelleyin	Yavaş yavaş ilerliyor...
Xml mesajlarının formatını seçme olanağını ekleyin	PHP yerel xmlrpc uzantısının yaptığına benzer
PHP 5 ile STRICT modunda çalışırken verilen uyarıları düzeltin	PHP 4 uyumluluğu terk edilerek sürüm 3.0'da zaten yapılmış olabilir ...
İstisna yönetiminin avantajlarından yararlanmak ve xmlrpc hata yanıtlarını döndürmek için otomatik php işlevini xmlrpc yöntem sarmalayıcısına genişletin
PHP işlevlerini PHP için xmlrpc yöntemlerine otomatik olarak dönüştürmek için otomatik saplama oluşturucuyu genişletin<= 5.0.2	bunun nasıl yapılacağı hakkında AMFPHP koduna bakın. Sürüm 2.1'deki birçok geliştirme Artık sunucu php işlevlerini otomatik olarak kaydedebildiğine göre buna daha az ihtiyaç var...
Etkinleştirildiğinde mbstring için daha iyi destek	Örneğin; karakter kümesi kodlamasının daha hızlı tahmin edilmesi
"Sürüm 1" çerezlerine yönelik desteği iyileştirin
Yerel hata kodları yerine kullanma olanağı ekleyin
PEAR uyumluluğu: kütüphanenin PEAR sürümünde farklı adlarla mevcut olan işlevler için eşanlamlılar ekleyin
Xmlrpc uzantısı için destek ekleyin
Hata ayıklayıcıya eksiksiz bir validator1 testi seti başlatma özelliğini ekleyin
Açığa çıkan hizmetleri açıklamak ve system.methodSignature ile system.describeMethods'a/sistemden çeviri yapmak için WSDL'nin kullanılabilirliğini inceleyin	Xmlrpc'yi tam olarak tanımlamak için XSD kullanılmasında bazı sorunlar vardır. Relax NG kesinlikle daha iyi bir alternatif, ancak diğer araç kitlerinde onu bir WSDL dosyasıyla birlikte kullanmak için çok az destek var...
http yönlendirmelerini destekleyin (302)
Xmlrpc.com sitesinde olduğu gibi, gelen kullanıcıların günlüğünü tutan bir doğrulayıcı sayfa uygulayabilmemiz için sf.net'e küçük bir veritabanı ekleyin.
Karşılaştırma paketine sonuçları sf.net'e yükleme özelliğini ekleyin
Kütüphanenin en yoğun kullanılan fonksiyonlarını hızlandıracak bir php uzantısı yazın	Örnek olarak adodb'un bunu nasıl yaptığını görün
Xml'i elle ayrıştırmak yerine simplexml ve rahatlatıcı kullanarak hız/bellek kazanımlarını test edin

Güvenlik

Üçüncü güvenlik ihlali: Ağustos 2005

Bu, aşağıdaki ikinci güvenlik ihlaline verilen ileri ve proaktif bir yanıttı. Hala potansiyel bir istismar olduğundan eval() işlevinin tüm kullanımı kaldırıldı.

Kütüphane orijinal olarak yazıldığında, o sırada mevcut olan php sürümleri call_user_func() ve diğerlerini içermiyordu. Dolayısıyla, xml ayrıştırıcısı tarafından çağrılan işlevlerden ikisinde eval() işlevinin kullanılması bu kısıtlamalar dahilinde yazılmıştır. Bu kullanım nedeniyle, sunucu sınıfı aynı işlevleri kullanarak xml'yi ayrıştırmak zorunda olduğundan eval() işlevini de kullandı.

Bu işleyici işlevleri ve orijinal mesajın içeriğini korumak için kullanılan dizi, değerlendirme için php kodu oluşturmak yerine php değerleri oluşturmak üzere yeniden yazılmıştır. Bu, kod yürütme potansiyelini ortadan kaldırmalıdır.

İkinci güvenlik ihlali: Temmuz 2005

GulfTech Güvenlik Araştırması'ndan James Bercegay tarafından 27 Haziran 2005'te keşfedilen güvenlik açığı oldukça heyecan yarattı. Salshdot'un ön sayfasına çıktı, Netcraft, LWN ve diğer birçok sitede adı geçti.

Yararlanma kodu oluşturmaya ilişkin ayrıntılı talimatlar internette yayınlandı ve birçok web barındırma yöneticisi, en iyi savunma planının ne olduğunu ve gerçek risklerin neler olduğunu merak ediyor. İşte bazı cevaplar.

Sorunun kapsamı

hata, PEAR::XMLRPC ve PHPXMLRMPC olarak bilinen iki kitaplığı etkiliyor.
Bu, php'de yerleşik olan ve derleme zamanında "--with-xmlrpc" seçeneğiyle etkinleştirilen xmlrpc uygulamasını ETKİLEMEZ (Unix'te, Windows'ta genellikle php.ini'deki uygun satır değiştirilerek etkinleştirilir/devre dışı bırakılır) )
hata (uzak ana bilgisayarlar tarafından enjekte edilen php kodunun yürütülmesi) yalnızca dosyada bulunur xmlrpc.inc phpxmlrpc dağıtımında ve RPC.php PEAR dağılımında
hem PEAR::XMLRPC hem de PHPXMLRMPC, kütüphanenin sorunu çözen güncellenmiş sürümlerini yayınladı
her iki kütüphane de çok sayıda php uygulamasında kullanılmıştır (yukarıdaki eksik listeye bakınız).
Kütüphanenin tamamı temelde 2 çok basit dosyadan oluştuğundan, herkes bunları kendi zevklerine/ihtiyaçlarına göre yamalama ve uygulamalarını dağıtırken bunları paketleme eğilimindedir.
Yüksek profilli projelerin çoğu, ilgili uygulamalarının yeni sürümlerini yayınlamada son derece hızlı davrandı, ancak her kullanıcının sistemini güncellemesi çok daha uzun zaman alacak.
Pek çok uygulamanın yakın zamana kadar phpxmlrpc kütüphanesinin son derece eski sürümleriyle birlikte gönderildiğini söylemek gerekir; İlk enjeksiyon hatası 2001'de düzeltildi Görünüşe göre kimse farkına varmadan (...)
Bu ne yazık ki sistem yöneticilerinin soruna kolay bir çözüm bulmasını çok daha zorlaştırıyor: halka açık barındırma sunucularında yukarıda adı geçen dosyaların birçok farklı dizinde ve birçok farklı versiyonda bulunma ihtimali büyük.

Güvenlik açığı nasıl tetiklenir?

Saldırganın hatayı tetiklemek için, bir xmlrpcval nesnesinin oluşturma sürecinde özel hazırlanmış bazı xml'lerin değerlendirilmesi gerekir. Xmlrpcval nesneleri, sunucu komut dosyası xmlrpc isteklerinin kodunu çözdüğünde veya bazı php komut dosyaları bir xmlrpc istemcisi gibi davranıp bir sunucu tarafından gönderilen yanıtın kodunu çözdüğünde oluşturulur.
Sunucu komut dosyası uygulamaya özeldir ve genellikle server.php olarak adlandırılır (ancak proje veya kullanıcı tarafından seçilen herhangi bir değişken mümkündür) ve hem xmlrpc.inc hem de xmlrpcs.inc dosyalarını içermesi gerekir (armut sürümü için, sunucu .php, xmlrpcs.inc'nin eşdeğeridir).
Yalnızca xmlrpc.inc ve xmlrpcs.inc'yi php komut dosyalarına dahil etmek (afaik...) tamamen güvenlidir, ayrıca bunları doğrudan http istekleri aracılığıyla çağırmak da mümkündür, çünkü bu iki dosyada yalnızca işlevlerin, değişkenlerin ve sınıfların tanımı gerçekleştirilir, yani. anında kod yürütme yok.
Tam phpxmlrpc lib'iyle dağıtılan server.php ve tartışma.php dosyaları aslında canlı bir xmlrpc sunucusu uygular, bu nedenle bunlara erişimi engellemeyi veya üretim sunucularında dağıtılmış bulursanız daha iyi bir şekilde kaldırmayı düşünebilirsiniz (en üstte) akılda tutarak, onları içeri çekmek + bilinen kütüphane hatasını istismar etmek için devralma-php-dosyası-ekleme ihlaline maruz kalan ikinci bir php uygulamasını içeren bir tür saldırı oluşturabilirim)

Koruma araçları

Web sunucunuza mümkün olduğu kadar az sistem ayrıcalığı verin. Unix'te bu genellikle Apache'nin kullanıcı hiç kimse olarak ve/veya jailroot'lu/chroot'lu bir ortamda çalıştırılmasını içerir. PHP motoru web sunucusuyla aynı kullanıcı altında çalıştığından, bu ilk savunma hattıdır: Saldırganın enjekte ettiği herhangi bir php kodu, sunucuda en az ayrıcalıklı kullanıcı olarak çalışacak ve verebileceği tüm zarar, php uygulamasının kendisini bozuyor
Php'yi güvenli modda çalıştırın. Herkese açık bir sunucuysanız ve bunu yapmıyorsanız, büyük ihtimalle sunucunuz yine de rootlanmıştır. Bu, php betiklerinin system() veya eval() gibi güvenli olmadığını düşündüğünüz herhangi bir işlevi kullanmasını engeller.
Sert blok: mevcut tüm phpxmlrpc dosyalarını (xmlrpc.inc ve xmlrpcs.inc) bulun ve bunları sistem genelinde devre dışı bırakın (chmod 0).
Bu elbette bazı kullanıcı uygulamalarının çalışmasını engelleyebilir, dolayısıyla bunu yaptığınızda kullanıcılarınızı bilgilendirmelisiniz.
Yumuşak blok: mevcut phpxmlrpc dosyalarının (xmlrpc.inc ve xmlrpcs.inc) tüm kopyalarını 1.1.1 sürümünden gelenlerle değiştirin.
Bu yöntemin maalesef tüm uygulamaların çalışır durumda kalması %100 garanti edilmez. Lib nesnelerinin bazı dahili öğeleri sürüm 0.9'dan 1.0'a ve 1.1'e değiştirildi (örneğin, bir xmlrpcresp nesnesi içinde depolanan http başlıklarının temsili) ve sunucularınıza dağıttığınız kod bunları alt sınıflara ayırırsa başı belaya girebilir. Kablo üzerinden gönderilen xml, kütüphanenin bazı eski sürümlerine göre de değişti (özellikle: sürüm 1.0.99.2, ASCII aralığı dışındaki karakterleri html varlıkları olarak yanlış kodladı, oysa şimdi bunlar xml karakter kümesi varlıkları olarak kodlandı). Birkaç yeni hata yanıt kodu da eklendi. Bunu söyledikten sonra, bu betiği çalıştırırken %95 güvende olmalısınız ve orada oturup kullanıcıların bir şeyin bozuk olduğunu bağırmaya başlamasını beklemelisiniz...
PHP PEAR kütüphanesi tek satırlık bir komutla yükseltilebilir, dolayısıyla bu çok büyük bir sorun değil:
armut XML_RPC'yi yükseltin ve yükseltilip yükseltilmediğini söyleyin (1.3.1 veya üstü sorun değil, şu an için en son sürüm 1.3.2):
armut listesi | grep RPC

Bazı ekstra hususlar

Daha iyi bir kullanıcı deneyimi sağlamak için xmlrpcs.inc dosyası da 1.1.1 sürümünde yamalanmıştır. Daha ayrıntılı olarak: özel hazırlanmış hatalı biçimlendirilmiş xml'in bir sunucuya gönderilmesi, php betiğinin uygun bir xml yanıtı döndürmek yerine bir php hatası vermesine neden olur.
Bazılarına göre, bu aslında bir "yol açıklama güvenlik ihlali" gerektirir (yani görüntülenen php hata mesajı genellikle dosya sistemi yolları hakkında hassas bilgiler içerir), ancak sistem yöneticisi üretim sunucularını çalıştırıyorsa herhangi bir PHP betiği aynı güvenlik sorunuyla karşı karşıya kalır. ini yönergesi display_errors=Açık.
Ayrıca xmlrpc.inc'de beklenmeyen bir parametreyle bir işlevin çağrılmasının php uyarısı veya hatası oluşturacağı pek çok yer olduğunu da biliyorum ve yakın zamanda her bir işlev için katı parametre kontrolü uygulamayı planlamıyorum - eğer isterseniz bunu hedefle, imho, ilk etapta Java'da kod yazsan iyi olur.

Bu dünyanın sonu mu?

Umarım değildir.
Bunun nedeni, kod enjeksiyonu açıklarından etkilenen onlarca PHP uygulamasının bulunmasıdır. Sadece bülten panolarının güvenlik takibine bir göz atın... ve yine de birçok insan hala PHP'nin web geliştirme için iyi bir seçim olduğunu düşünüyor.
Unutmayın: güvenlik ulaşılabilecek bir durum değil, bir süreçtir.

İlk güvenlik ihlali: Eylül 2001

Bu tavsiyeyi Dan Libby'den aldım. Onun izniyle burada çoğaltılmaktadır. Bu istismarın PHP için XML-RPC'nin 1.01 ve sonraki sürümlerinde düzeltildiğini unutmayın. -- Edd Dumbill Salı 24 Eylül 2001 ============= PHP Güvenlik Açığı: potansiyel XML-RPC istismarı ================== == ======================= Özet: Useful Inc'in php xmlrpc kütüphanesinin en son sürümü olan sürüm 1.0'ı kullanarak, bir saldırganın yapılandırma yapması mümkündür. xml'i, xml-rpc kütüphanesini bir web sunucusunda php kodunu çalıştırması için kandıracak şekilde kullandım ve php'nin güvenli modu kapalıyken sistem komutlarını rastgele php kodunu çalıştırabildim. Saldırgan bunu kolayca virüs başlatmak için bir ağ geçidi olarak kullanabilir. Ayrıntılar: Sorunu, xmlrpc dağıtımında bulunan server.php örnek komut dosyasını değiştirerek ve ardından onu yine dağıtımın bir parçası olan client.php komut dosyası aracılığıyla çağırarak gösterdim. Standart sunucu kodunu atladım ve istemciye yanıtları basitçe yankıladım. İstemcinin rastgele php kodu yürütmesini sağladım. Daha sonra server.php örneğini orijinal durumuna geri yükledim ve değiştirilmiş bir php dosyası göndermek için telnet'i kullandım. Biraz farklı bir sözdizimi gerektirse de, kodun sunucuda çalıştırılmasını da başardım. Saldırı, php'nin eval() işlevinin kullanımına odaklanıyor. Xml-rpc kitaplığının, veri yapılarını xml girdisinden oluşturmak için eval kullandığını bildiğimden, mesele sadece xml girdisini şu şekilde yapılandırmaktı: a) eval'e geçirilmeden önce kaçış yapılmaz b) yapar php sözdizimi hatası oluşturmaz Normalde sayısal olmayan tüm veriler, değerlendirmeye geçirilmeden önce kitaplık tarafından çıkarılır. Ancak, eğer bir mesaj gönderirseniz ortaya çıkıyor etiketi ve ardından beklenmeyen bir etiket geliyor: , kaçış kodu atlanacak ve bunun yerine "ham" veriler değerlendirilecek. İstemciden yararlanma: İşte tipik bir xml-rpc yanıtı: Selam Dünya Böyle bir yanıt değerlendirildiğinde şöyle görünür: new xmlrpcval("merhaba dünya", "string") İşte php kodunu echo " için çalıştıracak bir xml-rpc yanıtı.

Selam Dünya

"istemci tarafında: ", "dize"); echo "

Selam Dünya

"; \$atık = dizi(" Bu durumda değerlendirilecek dize şöyledir: new xmlrpcval("", "string"); echo "

Selam Dünya

"; $waste = array("", "string") "string"); ve \$waste arasındaki her şeyi hemen hemen her uzunlukta isteğe bağlı kodla değiştirmek mümkündür. Son olarak, içeriği yazdıracak kodu burada bulabilirsiniz geçerli dizinin: ", "dize"); echo "

"; echo 'ls -al'; echo "

"; çıkış; \$atık = dizi(" Sunucudan yararlanma: Sunucunun istismarı, sunucunun farklı bir eval komutu kullanması dışında istemciyle hemen hemen aynıdır ve bu nedenle, php sözdizimi hatalarını önlemek için biraz farklı başlangıç ve bitiş sözdizimi gerektirir. İşte yukarıdaki kodun aynısı, ancak bir sunucuya karşı çalışacak. system.listMethods ", "dize")); echo "

bir dizin listesi görürseniz, xml-rpc aracılığıyla php ve sistem kodunu çalıştırdım.

"; echo "şimdi ls -al:\n komutunu kullanarak dizin listelemeye çalışacağım "; echo 'ls -al'; echo ""; echo "Kolayca rm -rf komutunu çalıştırabilirdim veya diske bir program yazıp onu çalıştırabilirdim (örneğin bir virüs) veya bazı dosyaları okuyabilirdim. İyi günler.

"; çıkış; $atık = dizi(dizi(" Sorun Alanı: xmlrpc.inc'de, karakter verilerini işlemek için xml ayrıştırıcısı tarafından çağrılan xmlrpc_cd() adı verilen bir işlev vardır. function xmlrpc_cd($parser, $data) ( global $_xh, $xmlrpc_backslash, $xmlrpc_twoslash; //if (ereg("^[\n\r \t]+$", $data)) return; // print " ekleme [$(data)]\n"; if ($_xh[$parser]["lv"]==1) ( $_xh[$parser]["qt"]=1; $_xh[$parser][ "lv"]=2; ) if ($_xh[$çözümleyici]["qt"]) ( // tırnak içine alınmış dize $_xh[$ayrıştırıcı]["ac"].=str_replace("\$", "\\ $", str_replace(""", "\"", str_replace(chr(92),$xmlrpc_backslash, $data))); ) else $_xh[$parser]["ac"].=$data; ) It Verilerin kaçmadan eklenmesine neden olan sonuncusudur. Buna sahip olmak çok tehlikelidir. Bu, sayısal veriler için tasarlanmış gibi görünüyor ve kaçmayı açıp kapatan "qt" (alıntı) değişkenini ayarlamak ve ayarlamak için büyük çaba sarf ediliyor. Bununla birlikte, neden sayısal verilerden benzer şekilde kaçılmaması ve if/else'in kaldırılması gerektiği, böylece bu tür bir istismar için sıfır şansın olması gerektiği bana hemen açık değil.

LiveJournal.com'da (LJ) materyal yayınlamak için PHP'de XML-RPC kullanma

Öncelikle XML-RPC kütüphanesini indirmeniz gerekecek. Bana öyle geliyor ki en başarılı sürüm sourceforge " " aracılığıyla serbestçe dağıtılıyor: Aşağıdaki tüm örnekler bu kütüphane, sürüm 2.2 için verilecektir.

XML-RPC nedir? RPC, Uzaktan Yordam Çağrısı anlamına gelir; bu, XML kullanılarak uzaktan yordam çağrısı olarak Rusçaya çevrilebileceği anlamına gelir. Uzaktan prosedür çağrısı tekniğinin kendisi uzun zamandır bilinmekte ve DCOM, SOAP, CORBA gibi teknolojilerde kullanılmaktadır. RPC, dağıtılmış istemci-sunucu uygulamaları oluşturmak için tasarlanmıştır. Bu, örneğin farklı sistemlerdeki bilgisayarlarda heterojen ağlarda çalışan uygulamalar oluşturmayı, uzaktan veri işlemeyi gerçekleştirmeyi ve uzak uygulamaları yönetmeyi mümkün kılar. Bu protokol özellikle Rusya'da tanınmış livejournal.com web sitesi tarafından kullanılmaktadır.

LiveJournal'a Kiril alfabesiyle bir girişi nasıl yerleştirebileceğinize (ve sorunların sıklıkla ortaya çıktığı yer burasıdır) bir örneğe bakalım. Aşağıda yorumları içeren çalışma kodu verilmiştir:

new xmlrpcval($name, "string"), "password" => new xmlrpcval($password, "string"), "event" => new xmlrpcval($text, "string"), "subject" => new xmlrpcval ($subj, "string"), "lineendings" => new xmlrpcval("unix", "string"), "year" => new xmlrpcval($year, "int"), "mon" => new xmlrpcval( $mon, "int"), "day" => new xmlrpcval($day, "int"), "hour" => new xmlrpcval($hour, "int"), "min" => new xmlrpcval($min) , "int"), "ver" => new xmlrpcval(2, "int")); /* diziye dayalı bir yapı oluşturalım */ $post2 = array(new xmlrpcval($post, "struct")); /* sunucu için bir XML mesajı oluşturalım */ $f = new xmlrpcmsg("LJ.XMLRPC.postevent", $post2); /* sunucuyu tanımlayın */ $c = new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $c->request_charset_encoding = "UTF-8"; /* isteğe bağlı olarak sunucuya gönderilecek olanın XML koduna bakın */ echo nl2br(htmlentities($f->serialize())); /* sunucuya bir XML mesajı gönder */ $r = $c->send($f); /* sonucu analiz edin */ if(!$r->faultCode()) ( /* mesaj başarıyla alındı ve XML sonucu döndürüldü */ $v = php_xmlrpc_decode($r->value()); print_r($v); ) else ( /* sunucu bir hata döndürdü */ print "Bir hata oluştu: "; print "Kod: ".htmlspecialchars($r->faultCode()); print "Neden: "".htmlspecialchars($r->faultString ( ).""\n"; ) ?>

Bu örnekte yalnızca bir yöntem LJ.XMLRPC.postevent dikkate alınmıştır; olası komutların ve söz dizimlerinin tam listesi (İngilizce) şu adreste mevcuttur:

XML-RPC teknolojisi, WordPress sisteminde geri pingler, geri izlemeler, yönetici paneline giriş yapmadan uzaktan site yönetimi vb. gibi çeşitli güzel özellikler için kullanılır. Ne yazık ki saldırganlar bunu web sitelerine DDoS saldırıları gerçekleştirmek için kullanabilirler. Yani kendiniz için veya sipariş vermek için güzel, ilginç WP projeleri yaratırsınız ve aynı zamanda hiçbir şeyden şüphelenmeden bir DDoS botnetinin parçası olabilirsiniz. Kötü insanlar, on binlerce siteyi birbirine bağlayarak kurbanlarına güçlü bir saldırı oluşturur. Her ne kadar aynı zamanda siteniz de zarar görse de, çünkü... yük bulunduğu hostinge gider.

Bu tür kötü etkinliklerin kanıtı, aşağıdaki satırları içeren sunucu günlüklerinde (nginx'teaccess.log) bulunabilir:

103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"

Ancak XML-RPC güvenlik açığına dönelim. Görsel olarak sunucunuzdaki sitelerin yavaş açılması veya hiç yüklenememesi (502 Hatalı Ağ Geçidi hatası) şeklinde kendini gösterir. FASTVPS barındırıcımın teknik desteği tahminlerimi doğruladı ve şunu tavsiye etti:

WordPress'i eklentilerle birlikte en son sürüme güncelleyin. Genel olarak takip ederseniz en son 4.2.3 sürümünün yüklenmesi gerektiğini okumuş olabilirsiniz. güvenlik eleştirileri nedeniyle (tıpkı önceki sürümlerde olduğu gibi). Kısacası güncellemek iyidir.

XML-RPC Pingback'i Devre Dışı Bırak eklentisini yükleyin.

WordPress'te XML-RPC'yi devre dışı bırakma

Daha önce bana XML-RPC'yi etkinleştirme/devre dışı bırakma seçeneği sistem ayarlarında bir yerde bulunuyordu, ancak şimdi onu orada bulamıyorum. Bu nedenle ondan kurtulmanın en kolay yolu uygun eklentiyi kullanmaktır.

XML-RPC Pingback'i Devre Dışı Bırak seçeneğini bulun ve indirin veya doğrudan sistem yöneticisi panelinden yükleyin. Ek bir şey yapılandırmanıza gerek yoktur, modül hemen çalışmaya başlar. XML-RPC arayüzünden pingback.ping ve pingback.extensions.getPingbacks yöntemlerini kaldırır. Ayrıca X-Pingback'i HTTP başlıklarından kaldırır.

Bloglardan birinde XML-RPC'yi devre dışı bırakmayı kaldırmak için birkaç seçenek daha buldum.

1. Şablonda XML-RPC'yi devre dışı bırakın.

Bunu yapmak için temanın Function.php dosyasına aşağıdaki satırı ekleyin:

Reddetme Siparişi Ver, Herkesten Reddetmeye İzin Ver

Şahsen son iki yöntemi kullanmadım çünkü... XML-RPC Pingback'i Devre Dışı Bırak eklentisini bağladım - yeterli olacağını düşünüyorum. Gereksiz kurulumlardan hoşlanmayanlar için alternatif seçenekler önerdim.