Programmeringstävlingar. Analysera XML i PHP Biografi xmlrpc php

Introduktion till XML-RPC

Det finns många olika resurser på Internet som ger användarna viss information. Det betyder inte vanliga statiska sidor, utan till exempel data hämtade från en databas eller arkiv. Detta kan vara ett arkiv med finansiell data (växelkurser, värdepapperskurser), väderdata eller mer omfattande information - nyheter, artiklar, meddelanden från forum. Sådan information kan presenteras för sidbesökaren, till exempel genom ett formulär, som ett svar på en förfrågan, eller så kan den genereras dynamiskt varje gång. Men svårigheten är att sådan information ofta behövs inte så mycket av slutanvändaren - en person, utan av andra system och program som kommer att använda dessa data för sina beräkningar eller andra behov.

Verkligt exempel: en sida på en bankwebbplats som visar valutakurser. Om du går in på sidan som en vanlig användare, via en webbläsare, ser du all siddesign, banners, menyer och annan information som "ramar in" det verkliga syftet med sökningen - valutakurser. Om du behöver ange dessa offerter i din webbutik finns det inget annat att göra än att manuellt välja nödvändig data och överföra den till din webbplats via klippbordet. Och du kommer att behöva göra detta varje dag. Finns det verkligen ingen väg ut?

Om du löser problemet direkt, uppstår en lösning omedelbart: ett program (skript på en webbplats) som behöver data tar emot en sida från servern som en "vanlig användare", analyserar (parsar) den resulterande html-koden och extraherar nödvändig information från den. Detta kan göras antingen med ett reguljärt reguljärt uttryck eller med valfri html-tolkare. Svårigheten med tillvägagångssättet ligger i dess ineffektivitet. För det första, för att ta emot en liten del av data (data om valutor är bokstavligen ett dussin eller två tecken), måste du ta emot hela sidan, som är minst flera tiotals kilobyte. För det andra, med någon ändring i sidkoden, till exempel designen har ändrats eller något annat, måste vår parsningsalgoritm göras om. Och detta kommer att kräva en hel del resurser.

Därför kom utvecklarna till ett beslut - det är nödvändigt att utveckla någon form av universell mekanism som skulle möjliggöra transparent (på protokoll- och överföringsmediumnivå) och enkelt utbyte av data mellan program som kan placeras var som helst, skrivas på vilket språk som helst och körs under alla operativsystem, system och på vilken hårdvaruplattform som helst. En sådan mekanism kallas nu de högljudda termerna "webbtjänster", "SOAP", "serviceorienterad arkitektur". För datautbyte används öppna och tidstestade standarder - HTTP-protokollet används för att överföra meddelanden (även om andra protokoll kan användas - till exempel SMTP). Själva data (i vårt exempel, växelkurser) överförs paketerade i ett plattformsoberoende format - i form av XML-dokument. För detta ändamål uppfanns en speciell standard - SOAP.

Ja, nu är webbtjänster, SOAP och XML på allas läppar, de börjar implementeras aktivt och stora företag som IBM och Microsoft släpper nya produkter som är utformade för att hjälpa till med den totala implementeringen av webbtjänster.

Men! För vårt exempel med växelkurser som måste överföras från bankens webbplats till nätbutiksmotorn, kommer en sådan lösning att vara mycket svår. När allt kommer omkring tar bara beskrivningen av SOAP-standarden en obscent ett och ett halvt tusen sidor, och det är inte allt. För praktisk användning måste du också lära dig att arbeta med tredjepartsbibliotek och tillägg (endast från PHP 5.0 innehåller det ett bibliotek för att arbeta med SOAP), och skriva hundratals och tusentals rader av din egen kod. Och allt detta för att få några bokstäver och siffror är uppenbarligen väldigt krångligt och irrationellt.

Därför finns det en annan, kan man säga, alternativ standard för informationsutbyte - XML-RPC. Den utvecklades med deltagande av Microsoft av UserLand Software Inc och är designad för enhetlig dataöverföring mellan applikationer över Internet. Det kan ersätta SOAP när man bygger enkla tjänster där alla "enterprise"-möjligheter hos riktiga webbtjänster inte behövs.

Vad betyder förkortningen XML-RPC? RPC står för Remote Procedure Call. Detta innebär att en applikation (oavsett om det är ett skript på servern eller en vanlig applikation på klientdatorn) transparent kan använda en metod som är fysiskt implementerad och exekverad på en annan dator. XML används här för att tillhandahålla ett universellt format för att beskriva överförda data. Som en transport används HTTP-protokollet för att överföra meddelanden, vilket gör att du sömlöst kan utbyta data genom alla nätverksenheter - routrar, brandväggar, proxyservrar.

Och för att kunna använda måste du ha: en XML-RPC-server som tillhandahåller en eller flera metoder, en XML-RPC-klient som kan generera en korrekt begäran och bearbeta serversvaret, och även känna till serverparametrarna som krävs för framgångsrik drift - adress, metodnamn och godkända parametrar.

Allt arbete med XML-RPC sker i "request-response"-läget, detta är en av skillnaderna mellan tekniken och SOAP-standarden, där det finns både begreppen transaktioner och möjligheten att göra försenade samtal (när servern sparar begäran och svarar på den vid en viss tidpunkt i framtiden). Dessa ytterligare funktioner är mer användbara för kraftfulla företagstjänster, de komplicerar avsevärt utvecklingen och supporten av servrar och ställer ytterligare krav på utvecklare av klientlösningar.

Proceduren för att arbeta med XML-RPC börjar med att skapa en begäran. En typisk begäran ser ut så här:

POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Värd: server.localnet.com
Innehållstyp: text/xml
Innehållslängd: 172

Testmetod
Hej XML-RPC!

De första raderna bildar standardhuvudet för HTTP POST-begäran. Obligatoriska parametrar inkluderar värd, datatyp (MIME-typ), som måste vara text/xml och meddelandelängd. Standarden anger också att fältet User-Agent måste fyllas i, men kan innehålla ett godtyckligt värde.

Därefter kommer den vanliga rubriken för XML-dokumentet. Rotelementet i begäran är , det kan bara finnas en och kan inte innehålla sådana noder som barn. Detta innebär att en begäran endast kan anropa en metod på servern.

Linje Testmetod indikerar att vi anropar en metod som heter TestMetod. Om det behövs kan du här ange namnet på programmet eller modulen som innehåller metoden, samt sökvägen till den. XML-RPC-specifikationen, även om den lägger vissa begränsningar på uppsättningen tecken som kan användas för att beteckna en metod, är hur man tolkar dem helt beroende på serverimplementeringen.

Därefter ställs de överförda parametrarna in. Detta avsnitt används för detta. Som kan innehålla ett godtyckligt antal delelement Som innehåller parametern som beskrivs av taggen . Vi kommer att titta på parametrar och datatyper lite längre. I vår version skickas metoden en strängparameter omsluten i taggen .

Beskrivningen av alla parametrar följs av avslutande taggar. Begäran och svaret i XML-RPC är vanliga XML-dokument, så alla taggar måste stängas. Men det finns inga enstaka taggar i XML-RPC, även om de finns i XML-standarden.

Låt oss nu titta på serverns svar. HTTP-svarshuvudet är normalt; om begäran bearbetas framgångsrikt returnerar servern ett HTTP/1.1 200 OK-svar. Precis som i begäran måste du ange MIME-typ, meddelandelängd och datum för svarsgenerering korrekt.

Själva svarskroppen är följande:

Sann

Nu istället för root-taggen taggen anges , som omedelbart innehåller resultatet av begäran om behandling. Tyvärr passerar inte svaret metodnamnet, så du bör lagra det på klientsidan för att undvika förvirring om olika metoder anropas samtidigt.

Om ett fel uppstod under behandlingen av din begäran, istället för Svaret kommer att innehålla elementet , där en struktur som beskriver felet kommer att kapslas. Felbeskrivningen innehåller en numerisk felkod och en textbeskrivning.

Låt oss nu ta en kort titt på datatyper i XML-RPC. Det finns 9 datatyper totalt - sju enkla typer och 2 komplexa. Varje typ beskrivs av sin egen tagg eller uppsättning taggar (för komplexa typer).

Enkla typer:

Heltal- tagga eller ;

boolesk typ- tagga , kan ta både värden 0/1 och sant/falskt;

ASCII-sträng- beskrivs av tagg och kan innehålla en godtycklig sträng av tecken;

Flyttal- tagga , kan också innehålla ett taltecken, bråkdelen separeras med en punkt;

datum och tid- beskrivs av tagg och måste följa formatet iso8601. För vidare bearbetning i skript är detta format lite obekvämt, så det konverteras alltid när man skickar/tar emot en förfrågan. Detta kan göras av en speciell funktion inom biblioteket, eller, om det inte finns någon, måste utvecklaren konvertera datumet manuellt.

Den sista enkla typen är base64-kodad sträng, som beskrivs av taggen . Denna typ är universell, den kan användas för att överföra alla data mellan klienten och servern, även om volymen överförda data ökar på grund av sådan kodning. Men detta är en konsekvens av protokollets textmässiga karaktär och i synnerhet XML-formatet.

Komplexa typer representeras av strukturer och arrayer. Strukturen bestäms av rotelementet , som kan innehålla ett godtyckligt antal element , definierar varje medlem av strukturen. En strukturmedlem beskrivs av två taggar: först, , beskriver namnet på medlemmen, andra, , innehåller värdet på medlemmen (tillsammans med en tagg som beskriver datatypen).

Arrayer har inga namn och beskrivs av taggen som innehåller ett element , och ett eller flera underordnade element , där specifika uppgifter anges. En array kan innehålla alla andra typer i valfri ordning, såväl som andra arrayer, vilket gör att du kan beskriva flerdimensionella arrayer. Du kan också beskriva en rad strukturer. Men det faktum att arrayen inte har ett namn komplicerar dess användning i vissa fall; för att överföra komplexa data måste de upprepade gånger packas till andra typer (för att till exempel överföra flera arrayer kan du packa varje array separat i en struktur , och skapa sedan en array från dessa strukturer).

Naturligtvis kommer någon att säga att en sådan lista över datatyper är mycket dålig och "låter dig inte expandera." Ja, om du behöver överföra komplexa objekt eller stora mängder data, är det bättre att använda SOAP. Och för små, krävande applikationer är XML-RPC ganska lämpligt, dessutom visar sig mycket ofta till och med dess kapacitet vara för många! Med tanke på den enkla driftsättningen, ett mycket stort antal bibliotek för nästan alla språk och plattformar och brett stöd i PHP, så har XML-RPC ofta helt enkelt inga konkurrenter. Även om det inte omedelbart kan rekommenderas som en universallösning - i varje specifikt fall måste det avgöras efter omständigheterna.

Hackare letar efter olika sätt att hacka dina webbplatser. I de flesta fall, om inte sajten har något kommersiellt värde, är det barn som leker och försöker hävda sig.

Häromdagen var mina värdsajter, milt uttryckt, "lagda". Det var tydligt att några av webbplatserna var DOSerade.

Detta kan främst ses från statistiken över serverresursanvändning:

Jag blev förvånad av anledningen att det inte finns några kommersiella resurser på värdskapet. Varför, kanske du frågar, DOS? Till vilken nytta?

Vad visar diagrammet?

På den första bilden ser vi CPU-belastning. Den mäts till 100 % per kärna. Attacken började runt 15:00 GMT, och runt 21:00 bad jag leverantören att göra något åt ​​det. Teknisk support började överföra hosting till en annan huvudserver. Tydligen för att ge mig möjlighet att använda mer systemresurser. Cirka klockan 22.00 började flyttningen, kontroll av filers integritet och andra procedurer.

Jag ville verkligen inte ens bry mig - och jag gick bara och la mig, för "morgonen är klokare än kvällen."

Vad är synligt i serverloggarna?

Statistiken visade inte längre några anomalier på morgonen. Sajterna öppnade ändå varannan gång och inte direkt, d.v.s. attacken fortsatte. Antingen skrevs statistiken fortfarande från den gamla servern, eller så var den redan data från masterservern...

Därför gick jag vidare till att studera loggarna för att ta reda på var de "knackade".

När jag tittade på loggarna stod det klart att det inte fanns någon anledning att oroa sig - någon sorts shkolota knackade från samma IP-adress i /xmlrpc.php på en av mina WordPress-sajter. Mest troligt tvingar han adminlösenordet.

Naturligtvis är detta inte särskilt trevligt, eftersom alla andra webbplatser på den virtuella servern också "ljuger". Och det mest irriterande är att jag inte använder dessa XML-tjänster på någon av mina WP-sajter.

Blockerar XML RPC.

Det enklaste du kan göra i den här situationen är att ta bort filen från webbplatsens rotmapp /xmlrpc.php. Servern, om den inte hittar ett gnisslande, kommer inte att köra PHP, vilket slösar minnesresurser och processortid. Lösningen är enkel, men inte snygg. För det första kan någon använda RPC-funktioner. Till exempel, publicera inlägg på webbplatsen genom en av de många webbloggklienterna. Och för det andra kommer filen att återställas efter nästa WP-uppdatering.

Om din server körs på Apache kan du blockera åtkomst till xmlrpc.php utan att ta bort själva filen. Du måste lägga till följande instruktioner i början av din .htaccess filen i rotkatalogen på WordPress-webbplatsen. Detta blockerar åtkomst till filen från alla adresser.

# XML-RPC DDoS-SKYDD Beställ neka, tillåt neka från alla

I mitt fall var det möjligt att endast blockera IP-adressen för förfrågningskällan, eftersom... samma adress användes. För att endast blockera IP-adressen för "shkolodoser":

Beställ Tillåt, Neka neka från 85.93.93.157 Tillåt från alla

Men om du använder RPC kan du skapa en vit lista över adresser som har tillgång till skriptet xmlrpc.php.

Beställ Neka, Tillåt #lägg till dina IP-adresser Tillåt från 127.0.0.1 Tillåt från XX.XX.XX.XX ... Neka från alla

Från och med lunchtid på lördagen började min server, där cirka 25 Wordpress-webbplatser finns, uppleva allvarliga nedgångar. Eftersom jag lyckades överleva de tidigare attackerna ( , ) utan att bli märkt, förstod jag inte direkt vad som hände.

När jag kom på det visade det sig att lösenord var brute-forced + många förfrågningar till XMLRPC.

Som ett resultat lyckades vi skära bort det hela, om än inte direkt. Här är tre enkla knep för att undvika detta.

Dessa tekniker är troligen kända för alla, men jag trampade på ett par misstag som jag inte hittade i beskrivningarna - kanske kommer det att spara någon tid.

1. Stoppa sökningen, installera insticksprogrammet Limit Login Attempts - installera det, eftersom andra skydd saktar ner servern kraftigt, till exempel när du använder plugin-programmet Login Security Solution dog servern efter en halvtimme, plugin-programmet belastar databasen kraftigt .

I inställningarna, se till att aktivera kryssrutan "För proxy" - annars kommer den att bestämma IP-adressen för din server för alla och automatiskt blockera alla.
UPPDATERING, tack, detaljer finns nedan i kommentarerna - aktivera kryssrutan "För proxy" endast om definitionen inte fungerar när "Direkt anslutning" är aktiverad

2. Inaktivera XML-RPC - insticksprogrammet Inaktivera XML-RPC (det är lätt att aktivera och det är allt).

3. Stäng wp-login.php – om du kommer åt sidan via IP fungerar inte plugin och väljarna fortsätter att krascha sidan. För att undvika detta, lägg till i .htaccess:

Beställ neka, tillåt neka från alla

Vi kopierar wp-login-filen, byter namn på den till vilket konstigt namn som helst, till exempel poletnormalny.php, och inuti filen använder vi autokorrigering för att ändra alla wp-login.php-inskriptioner till poletnormalny.php.
Det är det, nu kan du komma åt adminpanelen endast med din fil.

Efter dessa 3 enkla steg började platserna flyga igen och lugnet kom.

Ja, plötsligt är det intressant