Úvod do XML-RPC
Na internete je množstvo rôznych zdrojov, ktoré používateľom poskytujú určité informácie. Nemyslí sa tým obyčajné statické stránky, ale napríklad dáta získané z databázy alebo archívov. Môže to byť archív finančných údajov (výmenné kurzy, kotácie cenných papierov), údaje o počasí alebo rozsiahlejšie informácie – novinky, články, správy z fór. Takéto informácie môžu byť návštevníkovi stránky prezentované napríklad prostredníctvom formulára, ako odpoveď na požiadavku, alebo môžu byť zakaždým generované dynamicky. Problém je však v tom, že takéto informácie často nepotrebuje ani tak koncový používateľ – osoba, ale iné systémy a programy, ktoré tieto údaje použijú na svoje výpočty alebo iné potreby.
Skutočný príklad: stránka bankového webu, na ktorej sa zobrazujú menové kurzy. Ak na stránku pristupujete ako bežný používateľ, prostredníctvom prehliadača vidíte celý dizajn stránky, bannery, menu a ďalšie informácie, ktoré „rámcujú“ skutočný účel vyhľadávania – menové kotácie. Ak potrebujete zadať tieto cenové ponuky do vášho internetového obchodu, nezostáva vám nič iné, len manuálne vybrať potrebné údaje a preniesť ich cez schránku na váš web. A budete to musieť robiť každý deň. Naozaj neexistuje východisko?
Ak problém vyriešite priamočiaro, okamžite sa objaví riešenie: program (skript na webe), ktorý potrebuje údaje, dostane stránku zo servera ako „bežný používateľ“, analyzuje (analyzuje) výsledný html kód a extrahuje potrebné informácie z neho. Dá sa to urobiť buď pomocou regulárneho regulárneho výrazu, alebo pomocou akéhokoľvek html analyzátora. Náročnosť prístupu spočíva v jeho neúčinnosti. Po prvé, aby ste dostali malú časť údajov (údaje o menách sú doslova tucet alebo dva znaky), musíte prijať celú stránku, ktorá má najmenej niekoľko desiatok kilobajtov. Po druhé, pri akejkoľvek zmene v kóde stránky, napríklad v dizajne alebo niečom inom, bude potrebné prepracovať náš algoritmus analýzy. A to bude vyžadovať značné množstvo zdrojov.
Preto vývojári dospeli k rozhodnutiu - je potrebné vyvinúť nejaký univerzálny mechanizmus, ktorý by umožnil transparentnú (na úrovni protokolu a prenosového média) a jednoduchú výmenu dát medzi programami, ktoré môžu byť umiestnené kdekoľvek, byť napísané v akomkoľvek jazyku. a bežať pod ľubovoľným operačným systémom a na akejkoľvek hardvérovej platforme. Takýto mechanizmus sa teraz nazýva hlasnými výrazmi „webové služby“, „SOAP“, „architektúra orientovaná na služby“. Na výmenu dát sa používajú otvorené a časom overené štandardy – na prenos správ sa používa protokol HTTP (hoci možno použiť aj iné protokoly – napríklad SMTP). Samotné dáta (v našom príklade výmenné kurzy) sa prenášajú zabalené v multiplatformovom formáte – vo forme XML dokumentov. Na tento účel bol vynájdený špeciálny štandard – SOAP.
Áno, teraz sú webové služby, SOAP a XML na perách každého, začínajú sa aktívne implementovať a veľké korporácie ako IBM a Microsoft uvoľňujú nové produkty určené na pomoc pri celkovej implementácii webových služieb.
Ale! Pre náš príklad s výmennými kurzami, ktoré sa musia prenášať z webovej stránky banky do motora internetového obchodu, bude takéto riešenie veľmi ťažké. Koniec koncov, samotný popis štandardu SOAP zaberá obscénnych jeden a pol tisíc strán, a to nie je všetko. Pre praktické využitie sa tiež budete musieť naučiť pracovať s knižnicami a rozšíreniami tretích strán (až od PHP 5.0 obsahuje knižnicu pre prácu so SOAP) a písať stovky a tisíce riadkov vlastného kódu. A to všetko na získanie niekoľkých písmen a číslic je zjavne veľmi ťažkopádne a iracionálne.
Preto existuje ďalší, dalo by sa povedať, alternatívny štandard výmeny informácií – XML-RPC. Bol vyvinutý za účasti spoločnosti Microsoft spoločnosťou UserLand Software Inc a je určený na jednotný prenos dát medzi aplikáciami cez internet. Môže nahradiť SOAP pri budovaní jednoduchých služieb, kde nie sú potrebné všetky „podnikové“ schopnosti skutočných webových služieb.
Čo znamená skratka XML-RPC? RPC je skratka pre Remote Procedure Call. To znamená, že aplikácia (či už skript na serveri alebo bežná aplikácia na klientskom počítači) môže transparentne používať metódu, ktorá je fyzicky implementovaná a spustená na inom počítači. XML sa tu používa na poskytnutie univerzálneho formátu na popis prenášaných údajov. Ako prenos sa na prenos správ používa protokol HTTP, ktorý vám umožňuje bezproblémovú výmenu údajov prostredníctvom akýchkoľvek sieťových zariadení - smerovačov, firewallov, proxy serverov.
Na použitie teda potrebujete: server XML-RPC, ktorý poskytuje jednu alebo viac metód, klienta XML-RPC, ktorý dokáže vygenerovať správnu požiadavku a spracovať odpoveď servera a tiež poznať parametre servera potrebné pre úspešnú prevádzku - adresa, názov metódy a odovzdané parametre.
Všetka práca s XML-RPC prebieha v režime „request-response“, čo je jeden z rozdielov medzi technológiou a štandardom SOAP, kde existujú koncepty transakcií a možnosť uskutočniť oneskorené hovory (keď server uloží žiadosť a odpovie na ňu v určitom čase v budúcnosti). Tieto doplnkové funkcie sú užitočnejšie pre výkonné podnikové služby, výrazne komplikujú vývoj a podporu serverov a kladú dodatočné požiadavky na vývojárov klientskych riešení.
Postup pri práci s XML-RPC začína vytvorením požiadavky. Typická požiadavka vyzerá takto:
POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Hostiteľ: server.localnet.com
Content-Typ: text/xml
Dĺžka obsahu: 172
Prvé riadky tvoria štandardnú hlavičku HTTP POST požiadavky. Medzi povinné parametre patrí hostiteľ, typ údajov (typ MIME), ktorý musí byť text/xml, a dĺžka správy. Norma tiež určuje, že pole User-Agent musí byť vyplnené, ale môže obsahovať ľubovoľnú hodnotu.
Ďalej nasleduje obvyklá hlavička dokumentu XML. Koreňový prvok požiadavky je
Linka
Ďalej sa nastavia prenášané parametre. Na to slúži táto sekcia.
Za popisom všetkých parametrov nasledujú uzatváracie značky. Požiadavka a odpoveď v XML-RPC sú bežné dokumenty XML, takže všetky značky musia byť zatvorené. V XML-RPC však neexistujú žiadne jednotlivé značky, hoci sú prítomné v štandarde XML.
Teraz sa pozrime na odpoveď servera. Hlavička odpovede HTTP je normálna, ak je požiadavka úspešne spracovaná, server vráti odpoveď HTTP/1.1 200 OK. Rovnako ako v požiadavke musíte správne zadať typ MIME, dĺžku správy a dátum generovania odpovede.
Samotné telo odpovede je nasledovné:
Teraz namiesto koreňovej značky
Ak sa pri spracovaní vašej požiadavky vyskytla chyba, namiesto Odpoveď bude obsahovať prvok
Teraz sa stručne pozrime na dátové typy v XML-RPC. Celkovo existuje 9 dátových typov – sedem jednoduchých typov a 2 komplexné. Každý typ je opísaný vlastnou značkou alebo sadou značiek (pre zložité typy).
Jednoduché typy:
Celé čísla- štítok
Booleovský typ- štítok
ASCII reťazec- popísané tagom
Čísla s pohyblivou rádovou čiarkou- štítok
dátum a čas- popísané tagom
Posledným jednoduchým typom je kódovaný reťazec base64, ktorý je popísaný značkou
Komplexné typy sú reprezentované štruktúrami a poliami. Štruktúra je určená koreňovým prvkom
Polia nemajú názvy a sú popísané tagom
Samozrejme, niekto povie, že takýto zoznam typov údajov je veľmi zlý a „nedovoľuje vám expandovať“. Áno, ak potrebujete preniesť zložité objekty alebo veľké množstvo dát, potom je lepšie použiť SOAP. A pre malé, nenáročné aplikácie je XML-RPC celkom vhodný, navyše sa často aj jeho schopnosti ukážu ako priveľa! Vzhľadom na jednoduchosť nasadenia, veľmi veľký počet knižníc pre takmer akýkoľvek jazyk a platformu a širokú podporu v PHP, XML-RPC často jednoducho nemá konkurenciu. Nedá sa síce hneď odporučiť ako univerzálne riešenie – v každom konkrétnom prípade sa treba rozhodnúť podľa okolností.
Od sobotňajšieho poludnia sa môj server, na ktorom je hosťovaných asi 25 stránok Wordpress, začal výrazne spomaľovať. Keďže sa mi podarilo prežiť predchádzajúce útoky ( , ) bez povšimnutia, hneď som nechápal, čo sa deje.
Keď som na to prišiel, ukázalo sa, že heslá boli hrubo vynútené + veľa požiadaviek na XMLRPC.
Výsledkom bolo, že sa nám to všetko podarilo odstrihnúť, aj keď nie hneď. Tu sú tri jednoduché triky, ako sa tomu vyhnúť.
Tieto techniky sú s najväčšou pravdepodobnosťou známe každému, ale vystúpil som na niekoľko chýb, ktoré som v popisoch nenašiel - možno to niekomu ušetrí čas.
1. Zastavte vyhľadávanie, nainštalujte doplnok Limit Login Attempts - nainštalujte ho, pretože iné ochrany server značne spomaľujú, napríklad pri použití doplnku Login Security Solution server po pol hodine zomrel, doplnok silne zaťažuje databázu .
V nastaveniach nezabudnite začiarknuť políčko „Pre proxy“ - inak určí IP vášho servera pre všetkých a automaticky všetkých zablokuje.
AKTUALIZÁCIA, ďakujem, podrobnosti sú uvedené nižšie v komentároch - začiarknite políčko „Pre proxy“ iba v prípade, že definícia nefunguje, keď je povolené „Priame pripojenie“
2. Zakázať XML-RPC – doplnok Zakázať XML-RPC (je ľahké ho aktivovať a je to).
3. Zatvorte wp-login.php - ak pristupujete na stránku cez IP, plugin nefunguje a výbery pokračujú v páde stránky. Aby ste tomu zabránili, pridajte do .htaccess:
Skopírujeme súbor wp-login, premenujeme ho na akékoľvek zvláštne meno, napríklad poletnormalny.php, a vo vnútri súboru pomocou autocorrect zmeníme všetky nápisy wp-login.php na poletnormalny.php.
To je všetko, teraz máte prístup k správcovskému panelu iba pomocou svojho súboru.
Po týchto 3 jednoduchých krokoch začali lokality opäť lietať a nastal pokoj.
No zrazu je to zaujímavé
Jednou z možností je zistiť, či na vás neútočia. Môžete to vidieť v protokoloch nginx (napríklad tu je cesta k súboru Debian /var/log/nginx access.log).Hackeri hľadajú rôzne spôsoby, ako hacknúť vaše webové stránky. Vo väčšine prípadov, pokiaľ stránka nemá nejakú komerčnú hodnotu, sú to deti, ktoré sa šantia a snažia sa presadiť.
Minule boli moje hostingové stránky, mierne povedané, „uložené“. Bolo jasné, že niektoré stránky boli DOSované.
Vidno to predovšetkým zo štatistík využívania zdrojov servera:
Bol som prekvapený z toho dôvodu, že na hostingu nie sú žiadne komerčné zdroje. Niekto by sa mohol opýtať, prečo je to DOS? Za akým účelom?
Čo ukazuje diagram?
Na prvom obrázku vidíme zaťaženie CPU. Meria sa na 100 % na jadro. Útok začal okolo 15:00 GMT a okolo 21:00 som požiadal poskytovateľa, aby s tým niečo urobil. Technická podpora začala presúvať hosting na iný hlavný server. Vraj preto, aby som mal možnosť využívať viac systémových prostriedkov. Približne o 22:00 sa začalo sťahovanie, kontrola neporušenosti spisov a ďalších postupov.
Naozaj som sa ani nechcel obťažovať - a šiel som spať, pretože "ráno je múdrejšie ako večer."
Čo je viditeľné v protokoloch servera?
Štatistiky k dnešnému ránu už neukázali žiadne anomálie. Stránky sa aj tak otvárali každý druhý raz a nie hneď, t.j. útok pokračoval. Buď boli štatistiky stále zapísané zo starého servera, alebo to už boli údaje z hlavného servera...
Preto som prešiel k štúdiu denníkov, aby som zistil, kde „klopali“.
Keď som sa pozrel na protokoly, bolo jasné, že sa netreba báť – z rovnakej IP adresy v /xmlrpc.php jednej z mojich WordPress stránok klepal nejaký shkolota. S najväčšou pravdepodobnosťou si brutálne vynucuje heslo správcu.
To samozrejme nie je veľmi príjemné, pretože všetky ostatné stránky virtuálneho servera tiež „klamú“. A najnepríjemnejšia vec je, že tieto služby XML nepoužívam na žiadnej z mojich WP stránok.
Blokovanie XML RPC.
Najjednoduchšia vec, ktorú môžete v tejto situácii urobiť, je odstrániť súbor z koreňového priečinka lokality /xmlrpc.php. Server, ak nenájde pískanie, nespustí PHP, čím sa plytvá pamäťovými prostriedkami a časom procesora. Riešenie je jednoduché, ale nie pekné. Po prvé, niekto môže použiť možnosti RPC. Napríklad uverejňujte príspevky na stránke prostredníctvom jedného z mnohých klientov Weblog. A po druhé, súbor sa obnoví po ďalšej aktualizácii WP.
Ak váš server beží na Apache, môžete zablokovať prístup k xmlrpc.php bez odstránenia samotného súboru. Na začiatok svojho musíte pridať nasledujúce pokyny .htaccess súbor v koreňovom adresári stránky WordPress. Tým sa zablokuje prístup k súboru zo všetkých adries.
# OCHRANA DDoS XML-RPC
# OCHRANA DDoS XML-RPC < FilesMatch "^(xmlrpc\.php)" > Objednať Odmietnuť, Povoliť Odmietnuť od všetkých < / FilesMatch > |
V mojom prípade bolo možné zablokovať iba IP adresu zdroja požiadavky, pretože... bola použitá rovnaká adresa. Ak chcete zablokovať iba adresu IP „shkolodoser“:
< FilesMatch "^(xmlrpc\.php)" > Objednať Povoliť, Odmietnuť Deny z 85.93.93.157 Povoliť od všetkých < / FilesMatch > |
Ak však používate RPC, môžete vytvoriť biely zoznam adries, ktoré majú prístup k skriptu xmlrpc.php.
Od sobotňajšieho poludnia sa môj server, na ktorom je hosťovaných asi 25 stránok Wordpress, začal výrazne spomaľovať. Keďže predchádzajúce útoky (útok 1 - presne pred rokom, útok 2 - v marci) sa mi podarilo prežiť bez povšimnutia, hneď som nechápal, čo sa deje.
Keď som na to prišiel, ukázalo sa, že heslá boli hrubo vynútené + veľa požiadaviek na XMLRPC.
Výsledkom bolo, že sa nám to všetko podarilo odstrihnúť, aj keď nie hneď. Tu sú tri jednoduché triky, ako sa tomu vyhnúť.
Tieto techniky sú s najväčšou pravdepodobnosťou známe každému, ale vystúpil som na niekoľko chýb, ktoré som v popisoch nenašiel - možno to niekomu ušetrí čas.
1. Zastavte vyhľadávanie, nainštalujte doplnok Limit Login Attempts - nainštalujte ho, pretože iné ochrany server značne spomaľujú, napríklad pri použití doplnku Login Security Solution server po pol hodine zomrel, doplnok silne zaťažuje databázu .
V nastaveniach nezabudnite začiarknuť políčko „Pre proxy“ - inak určí IP vášho servera pre všetkých a automaticky všetkých zablokuje.
AKTUALIZÁCIA, vďaka DarkByte, podrobnosti nižšie v komentároch - zaškrtnite políčko „Pre proxy“ iba v prípade, že detekcia nefunguje, keď je povolené „Priame pripojenie“
2. Zakázať XML-RPC – doplnok Zakázať XML-RPC (je ľahké ho aktivovať a je to).
3. Zatvorte wp-login.php - ak pristupujete na stránku cez IP, plugin nefunguje a výbery pokračujú v páde stránky. Aby ste tomu zabránili, pridajte do .htaccess:
Skopírujeme súbor wp-login, premenujeme ho na akékoľvek zvláštne meno, napríklad poletnormalny.php, a vo vnútri súboru pomocou autocorrect zmeníme všetky nápisy wp-login.php na poletnormalny.php.
To je všetko, teraz máte prístup k správcovskému panelu iba pomocou svojho súboru.
Po týchto 3 jednoduchých krokoch začali lokality opäť lietať a nastal pokoj.
No zrazu je to zaujímavé
Jednou z možností je zistiť, či na vás neútočia. Môžete to vidieť v protokoloch nginx (napríklad tu je cesta k súboru Debian /var/log/nginx access.log).- Podpora pre vytváranie klientov aj serverov xmlrpc
- Plne automatizované alebo plne manuálne, jemnozrnné kódovanie a dekódovanie z hodnôt php do xmlrpc
- Podpora pre kódovanie znakov UTF8, Latin-1 a ASCII. S povoleným rozšírením php mbstring je podporovaných ešte viac znakových sád.
- Podpora http kompresie požiadaviek aj odpovedí, cookies, proxy, basic auth a https, ntlm auth a keepalives s php cURL rozšírením
- Voliteľné overenie typov parametrov prichádzajúcej požiadavky xmlrpc
- Podpora metód system.listMethods, system.methodHelp, system.multicall a system.getCapabilities
- Podpora pre
a - Možnosť zaregistrovať existujúcu funkciu php alebo metódy triedy ako webové služby, extrahovanie informácií s pridanou hodnotou z komentárov phpdoc
- Súčasťou knižnice je webový vizuálny debugger
Požiadavky
- PHP 5.3.0 alebo novší; Odporúča sa 5.5 alebo novšia verzia
- rozšírenie php "curl" je potrebné, ak chcete používať SSL alebo HTTP 1.1 na komunikáciu so vzdialenými servermi
- rozšírenie php "mbstring" je potrebné na umožnenie príjmu požiadaviek/odpovedí v iných znakových sadách ako ASCII, Latin-1, UTF-8
- natívne rozšírenie php "xmlrpc" nie je potrebné, ale ak je nainštalované, nedôjde k rušeniu fungovania tejto knižnice.
Stiahnuť ▼
Správy
- 1. júla 2017
Vydané verzie knižnice 4.2.0 a 3.1.0.
Poznámky k vydaniu sú dostupné na Github - 20. januára 2016
Vydaná lib verzia 4.0.0.
Toto je vôbec prvýkrát, čo API vidí veľké zmeny, odstraňuje minulosť a začína prechod na moderné php.
Boli zavedené menné priestory a používaná predvolená znaková sada, ak je UTF-8; bola pridaná podpora pre mbstring a oveľa viac.
Úplný zoznam zmien nájdete na stránke Github - 19. apríla 2015
Vydaná lib verzia 3.0.1. - 15. júna 2014
Vydaná lib verzia 3.0.0. - 15. decembra 2013
Projekt sa presunul na GitHubOnline debugger xmlrpc
Na adrese http://gggeek.altervista.org/sw/xmlrpc/debugger/ je aktívna demo aplikácia na ladenie xmlrpc, postavená na tejto knižnici. Debugger môžete použiť napr. dotazujte sa na demo server SF alebo odlaďte svoj vlastný osobný xmlrpc server, ak je dostupný na nete.
rozvoj
Popis Stav – aktualizované 26. 7. 2009 Aktualizujte dokumentáciu pre všetky funkcie pridané od verzie 2 Pomaly napreduje... Pridajte možnosť zvoliť si formátovanie xml správ Podobne ako to robí php natívne rozšírenie xmlrpc Opravte varovania vydávané pri spustení s PHP 5 v STRICT režime Možno to už bolo urobené vo verzii 3.0, opúšťajúc php 4 compat... Rozšírte automatickú funkciu php na obálku metódy xmlrpc, aby ste využili výhody spracovania výnimiek a vrátili odpovede na chyby xmlrpc Rozbaľte automatický stub generátor na automatickú konverziu funkcií php na metódy xmlrpc pre PHP<= 5.0.2 pozrite sa na kód AMFPHP, ako to urobiť.
Mnoho vylepšení vo verzii 2.1
Teraz, keď server dokáže automaticky zaregistrovať funkcie php, je to menej potrebné...Lepšia podpora pre mbstring, keď je povolený Treba urobiť napr. rýchlejšie hádanie kódovania znakov Zlepšite podporu pre súbory cookie verzie 1 Pridajte možnosť použiť namiesto natívnych chybových kódov Kompatibilita PEAR: pridajte synonymá pre funkcie existujúce s rôznymi názvami vo verzii PEAR knižnice Pridajte podporu pre rozšírenie xmlrpc Pridajte k debuggeru schopnosť spustiť kompletnú sadu testov validator1 Preskúmajte použiteľnosť WSDL na popis exponovaných služieb a preklad do/z system.methodSignature a system.describeMethods Pri používaní XSD na striktné definovanie xmlrpc existujú určité problémy. Relax NG je určite lepšia alternatíva, ale v iných súpravách nástrojov je malá podpora na jeho použitie v spojení so súborom WSDL... Podpora http presmerovaní (302) Pridajte na sf.net malú databázu, aby sme mohli implementovať stránku validátora, ktorá zaznamenáva prichádzajúcich používateľov, ako je napríklad stránka xmlrpc.com Pridajte do balíka benchmarkov možnosť nahrávania výsledkov na sf.net Napíšte rozšírenie php, ktoré urýchli najpoužívanejšie funkcie knižnice lib Pozrite si príklad, ako to urobil adodb Testujte rýchlosť/prírastky pamäte pomocou simplexml a relaxng namiesto ručnej analýzy xml Bezpečnosť
Tretie narušenie bezpečnosti: august 2005
Toto bola ďalšia a proaktívna reakcia na druhé narušenie bezpečnosti nižšie. Všetko použitie eval() bolo odstránené, pretože to bolo stále potenciálne využitie.
Keď bola knižnica pôvodne napísaná, verzie php dostupné v tom čase neobsahovali call_user_func(), a kol. Takže v rámci týchto obmedzení bolo napísané použiť eval() v dvoch funkciách volaných analyzátorom xml. Kvôli tomuto použitiu trieda servera tiež používala eval(), pretože musela analyzovať xml pomocou rovnakých funkcií.
Tieto funkcie obsluhy a pole používané na udržanie obsahu pôvodnej správy boli prepísané tak, aby vytvárali hodnoty php namiesto vytvárania kódu php na vyhodnotenie. Toto by malo odstrániť akýkoľvek potenciál na spustenie kódu.
Druhé narušenie bezpečnosti: júl 2005
Bezpečnostná chyba, ktorú objavil James Bercegay z GulfTech Security Research 27. júna 2005, spôsobila veľký rozruch. Dostalo sa na titulnú stránku Salshdotu, bolo spomenuté na Netcraft, LWN a mnohých ďalších stránkach.
Na internete boli zverejnené podrobné pokyny na vytváranie exploit kódu a mnohí správcovia webhostingu sa čudujú, aký je najlepší plán obrany a aké sú skutočné riziká. Tu je niekoľko odpovedí.
Rozsah problému
- chyba ovplyvňuje dve knižnice známe ako PEAR::XMLRPC a PHPXMLRMPC.
NEOVPLYVŇUJE implementáciu xmlrpc, ktorá je vstavaná v php a je povolená v čase kompilácie pomocou voľby „--with-xmlrpc“ (v Unixe, na Windows sa vo všeobecnosti povolí/zakáže zmenou príslušného riadku v php.ini ) - chyba (spustenie php kódu vloženého vzdialenými hostiteľmi) sa nachádza výlučne v súbore xmlrpc.inc v distribúcii phpxmlrpc a RPC.php v distribúcii HRUŠKA
- PEAR::XMLRPC aj PHPXMLRMPC vydali aktualizované verzie knižnice, ktoré riešia problém
- obe knižnice boli použité vo veľkom množstve php aplikácií (pozri neúplný zoznam vyššie).
Keďže celá knižnica pozostáva v podstate z 2 veľmi jednoduchých súborov, každý má tendenciu opravovať si ich podľa vlastného vkusu/potreby a pri distribúcii aplikácie ich spájať.
Väčšina významných projektov bola mimoriadne rýchla pri vydávaní nových verzií príslušných aplikácií, ale každému používateľovi bude trvať oveľa dlhšie, kým aktualizuje svoj systém.
Treba povedať, že mnohé aplikácie boli donedávna dodávané s extrémne zastaranými verziami knižnice phpxmlrpc; prvá chyba vstrekovania bola opravená v roku 2001 bez toho, aby si to niekto zjavne všimol (...)To, žiaľ, pre systémových administrátorov značne sťažuje nájdenie jednoduchého lieku na tento problém: existuje veľká šanca, že na verejných hostingových serveroch sa vyššie uvedené súbory budú nachádzať v mnohých rôznych adresároch a v mnohých rôznych verziách.
Ako sa zraniteľnosť spúšťa
- na spustenie chyby potrebuje útočník v procese vytvárania objektu xmlrpcval vyhodnotiť nejaký špeciálne vytvorený xml. Objekty Xmlrpcval sa vytvárajú, keď skript servera dekóduje požiadavky xmlrpc alebo keď niektoré skripty php fungujú ako klient xmlrpc a dekódujú odpoveď odoslanú serverom.
Serverový skript je špecifický pre aplikáciu a často sa nazýva server.php (ale je možný akýkoľvek variant zvolený projektom alebo používateľom) a musí obsahovať súbory xmlrpc.inc aj xmlrpcs.inc (pre hruškovú verziu server .php je ekvivalentom xmlrpcs.inc). - Jedine zaradenie xmlrpc.inc a xmlrpcs.inc do php skriptov je (afaik...) úplne bezpečné, rovnako ako ich volanie priamo cez http požiadavky, keďže v týchto dvoch súboroch sa vykonáva len definícia funkcií, premenných a tried, t.j. žiadne okamžité spustenie kódu.
- Súbory server.php a diskusné.php distribuované s plnou knižnicou phpxmlrpc v skutočnosti implementujú živý xmlrpc server, takže môžete zvážiť zablokovanie prístupu k nim alebo ešte lepšie ich odstránenie, ak ich nájdete nasadené na produkčných serveroch (z hornej časti môjho myseľ Dokážem vykúzliť nejaký druh útoku zahŕňajúci druhú aplikáciu php, ktorá trpí porušením prevzatia-php-file-inclusion, aby som ich vtiahla dovnútra + využila známu chybu knižnice)
Prostriedky ochrany
- Poskytnite procesu webového servera čo najmenej systémových práv. Na Unixe to vo všeobecnosti zahŕňa spustenie Apache ako užívateľ nikto a/alebo v jailroote/chroote prostredí. Keďže motor PHP beží pod tým istým používateľom ako webový server, toto je prvá obranná línia: akýkoľvek php kód vložený útočníkom sa spustí na serveri ako najmenej privilegovaný používateľ a všetky škody, ktoré môže spôsobiť, budú obmedzené na narušenie samotnej php aplikácie
- Spustite php v núdzovom režime. Ak ste verejný hostiteľ a nerobíte to, je pravdepodobné, že váš server bol aj tak zakorenený. To zabraňuje php skriptom používať akúkoľvek funkciu, ktorú považujete za nebezpečnú, ako napríklad system() alebo eval()
- Tvrdý blok: nájdite všetky existujúce súbory phpxmlrpc (xmlrpc.inc a xmlrpcs.inc) a vypnite ich (chmod 0) v celom systéme.
To samozrejme môže brániť fungovaniu niektorých používateľských aplikácií, takže by ste mali svojich používateľov informovať v čase, keď to urobíte. - Mäkký blok: nahraďte všetky kópie existujúcich súborov phpxmlrpc (xmlrpc.inc a xmlrpcs.inc) tými, ktoré pochádzajú z verzie 1.1.1.
Táto metóda bohužiaľ nie je 100% zaručená, že všetky aplikácie budú fungovať. Niektoré interné prvky objektov lib sa zmenili z verzie 0.9 na 1.0 na 1.1 (napr. reprezentácia hlavičiek http uložených v objekte xmlrpcresp) a ak kód, ktorý ste nasadili na svoje servery, ich podtriedy, môže sa ocitnúť v problémoch. XML odosielané cez drôt sa tiež zmenilo vzhľadom na niektoré staršie verzie knižnice (najmä: verzia 1.0.99.2 nesprávne kódovala znaky mimo rozsahu ASCII ako entity html, zatiaľ čo teraz sú kódované ako entity znakovej sady xml). Bolo pridaných aj niekoľko nových kódov odozvy na chyby. Napriek tomu by ste mali byť na 95 % v bezpečí pri spustení tohto skriptu a sedieť tam a čakať, kým používatelia začnú kričať, že je niečo pokazené... - knižnica PHP PEAR je rozšíriteľná pomocou jednoriadkového príkazu, takže to v skutočnosti nie je veľký problém:
hruška upgrade XML_RPC a zistiť, či bol aktualizovaný (1.3.1 alebo novšia je v poriadku, posledná odteraz je 1.3.2):
zoznam hrušiek | grep RPC
Niektoré ďalšie úvahy
Súbor xmlrpcs.inc bol tiež opravený vo verzii 1.1.1, aby poskytoval lepšiu používateľskú skúsenosť. Podrobnejšie: odoslanie špeciálne vytvoreného poškodeného xml na server by spôsobilo, že php skript vygeneruje chybu php namiesto toho, aby vrátil vhodnú xml odpoveď.
Podľa niektorých to v skutočnosti znamená „narušenie bezpečnosti zverejnenia cesty“ (t. j. zobrazené chybové hlásenie php zvyčajne obsahuje citlivé informácie o cestách súborového systému), ale potom každý jednotlivý skript PHP trpí rovnakým bezpečnostným problémom, ak sysadmin prevádzkuje produkčné servery s direktíva ini display_errors=On.
S istotou tiež viem, že na xmlrpc.inc je veľa miest, kde volanie funkcie s neočakávaným parametrom vygeneruje varovanie alebo chybu php, a neplánujem v dohľadnej dobe implementovať prísnu kontrolu parametrov pre každú jednu funkciu - ak zamerajte sa na to, imho, môžete tiež kódovať v jave.Je toto koniec sveta?
Dúfam, že nie.
Dôvodom je, že existujú desiatky aplikácií PHP, ktoré trpia zneužitím vstrekovania kódu. Stačí sa pozrieť na bezpečnostnú stopu násteniek... a napriek tomu si veľa ľudí stále myslí, že PHP je dobrá voľba pre vývoj webu.
Pamätajte: bezpečnosť je proces, nie stav, ktorý možno dosiahnuť.Prvé narušenie bezpečnosti: september 2001
Túto radu som dostal od Dana Libbyho. S jeho dovolením je tu reprodukovaný. Všimnite si, že tento exploit je opravený v revíziách 1.01 a vyšších XML-RPC pre PHP. -- Edd Dumbill Ut 24. septembra 2001 ============== Bezpečnostná diera PHP: potenciálne zneužitie XML-RPC =================== ========================= Abstrakt: Pomocou najnovšieho vydania knižnice php xmlrpc Useful Inc, verzie 1.0, je možné, že útočník štruktúrujte xml takým spôsobom, aby som oklamal knižnicu xml-rpc na spustenie php kódu na webovom serveri, dokázal som spustiť ľubovoľný php kód a pri vypnutom núdzovom režime php systémové príkazy. Útočník by to mohol ľahko použiť ako bránu na spustenie vírusov. Podrobnosti: Problém som demonštroval tak, že som upravil vzorový skript server.php, ktorý je súčasťou distribúcie xmlrpc, a potom som ho zavolal cez skript client.php, ktorý je tiež súčasťou distribúcie. Obišiel som štandardný kód servera a jednoducho som odoslal odpovede späť klientovi. Podarilo sa mi prinútiť klienta spustiť ľubovoľný php kód. Potom som obnovil vzorku server.php do pôvodného stavu a pomocou telnetu som poslal upravený Podarilo sa mi tiež spustiť kód na serveri, aj keď vyžaduje trochu inú syntax. Útok sa sústreďuje na použitie funkcie eval(). Keďže som vedel, že knižnica xml-rpc používa eval na zostavenie svojich dátových štruktúr zo vstupu xml, išlo len o štrukturovanie vstupného xml takým spôsobom, aby: a) nebolo pred odovzdaním do eval uniknuté nevygeneruje chybu syntaxe php Normálne všetky nečíselné údaje knižnica pred odovzdaním do eval unikne. Ukazuje sa však, že ak pošlete atag, za ktorým nasleduje neočakávaný tag, ako napr , únikový kód bude obídený a namiesto neho sa vyhodnotia „surové“ dáta. Využitie klienta: Tu je typická odpoveď xml-rpc: ahoj svet ahoj svet
"na strane klienta:", "reťazec"); echo " ahoj svet
"; \$odpad = pole("ahoj svet
"; $waste = array("", "string") Všetko medzi "string"); a \$waste je možné nahradiť ľubovoľným kódom takmer ľubovoľnej dĺžky. Nakoniec je tu jeden, ktorý vytlačí obsah aktuálneho adresára:", "reťazec"); echo " "; echo `ls -al`; echo "
"; exit; \$waste = array("system.listMetódy ", "reťazec")); echo " ak vidíte zoznam adresára, práve som spustil php a systémový kód cez xml-rpc.
"; echo "teraz sa pokúsim o výpis adresára pomocou ls -al:\n"; echo `ls -al`; echo " "; echo "Mohol som jednoducho vyvolať rm -rf, alebo napísať program na disk a spustiť ho (napr. vírus) alebo prečítať nejaké súbory. Pekný deň.
"; exit; $waste = pole(pole(" - chyba ovplyvňuje dve knižnice známe ako PEAR::XMLRPC a PHPXMLRMPC.