Ovanligt skydd från PHP Inkludera. Skickar aktiveringsbrev

Alla mjukvaruprodukter för att skydda PHP-skript är indelade i två kategorier: de som kräver installation av ytterligare moduler på servern och de som fungerar med den vanliga konfigurationen av webbservrar. De förra är mer pålitliga när det gäller säkerhet, eftersom de konverterar PHP-skript från textform till speciell binär kod, men kräver åtkomst till servern med administratörsrättigheter. Den senare kan fungera på nästan alla värdsajter som stöder PHP, inklusive gratis, men är inte särskilt svåra att hacka. Källkod som inte använder kryptering eller komprimering kan delas in i en separat undergrupp.

Skydd på servernivå:

Zend Encoder / Zend SafeGuard Suite är det mest populära kommersiella skyddet; moduler för Zend-support installeras vanligtvis på alla betalda värdtjänster. Zend tillhandahåller bindning av skript till domäner och ips, ställer in provkörningstiden för skript och kraftfull förvirring. Alla operativsystem stöds. Det finns flera versioner av verktyg för att ta bort Zend i det offentliga området, alla är modifierade PHP-versioner 4 och 5. Gamla versioner av Zend kan tas bort utan problem, men i de senaste versionerna uppstår svårigheter på grund av förvirring av källkoden.

Nytt, aktivt utvecklande kommersiellt skydd. På nivån av sitt eget API ger det interaktion med skyddade skript, som fungerar Windows-system och Linux. På grund av dess låga förekomst installeras den inte på vanlig virtuell värd, men den kan enkelt installeras av användare på dedikerade servrar. Det finns inga offentliga avkodare.

Kommersiellt skydd hittas praktiskt taget aldrig och är inte installerat på virtuell värd. Låter dig ställa in en provperiod för att köra skript med datumkontroll med hjälp av externa exakta tidsservrar, länka skyddade skript till servrar, IP-adress, MAC-adress nätverkskort, och denna data används för dekryptering. Alla operativsystem stöds. Det finns inga offentliga avkodare.

phpSHIELD. SourceGuardian för PHP-prototyp. Efter sammanslagningen av de två utvecklarna slutade den att utvecklas som en oberoende produkt. Huvudfunktionaliteten är densamma, det finns inga offentliga avkodare.

ionCube PHP Encoder. Den näst mest populära kommersiella produkten för att skydda skript. Efter uppkomsten av offentliga avkodare för Zend började den användas och installeras alltmer på virtuell värd. Låter dig kryptera inte bara skript, utan även mallar, xml-dokument, bilder, binära filer. Länkar skyddade filer till servrar, har en kraftfull obfuscator och stöder alla operativsystem. Det finns inga offentliga avkodare, men i vissa fall kan den tas bort av deZender.

PHTML Encoder. Ett sällan använt kommersiellt säkerhetssystem, det ger den vanliga funktionaliteten för produkter av denna typ, fungerar under alla operativsystem. Mot en extra avgift kan du köpa källsäkerhetskoder och modifiera dem för att passa dina behov. Det finns inga offentliga avkodare.

DWebEncoder. Exotiskt skydd för Windows, designat för att skapa skriptpresentationer och kataloger på CD-skivor. När den är installerad är den ungefär som en oberoende webbserver där kodade PHP-skript exekveras. Det finns inga offentliga avkodare.

PHP kompakt. Försvaret är mer teoretiskt än praktiskt. Det utvecklades på ett av de inhemska forumen, men det verkar som att frågan inte har kommit längre än författarens utgivningar. Det finns inga avkodare, liksom skyddade skript.

Ett tillägg med öppen källkod till de äldre PHP-acceleratorerna Turck MMCache och eAccelerator. Översätter skript till bytekod för att öka hastigheten på deras exekvering. Det finns versioner av moduler för Windows och Linux. Det finns inga offentliga avkodare, men kanske kommer projektets öppna källkod på något sätt att hjälpa till med lärandet.

Skydd på källkodsnivå:

PHP LockIt! . Populärt kommersiellt skydd, som finns mycket ofta, främst på skript från utländska utvecklare. Låter dig ställa in en testperiod för skript, bindning till domäner och IP-adresser, komprimerar skript regelbundna medel php (gzinflate). Den enda svårigheten är en bra obfuscator. Olika versioner av skydd skiljer sig endast i modifieringen av uppackningsmodulen. Lätt att ta bort både manuellt och automatiskt läge. Utan en obfuscator tas den bort exakt till källkoden, med en obfuscator kräver den ytterligare bearbetning.

CNCrypto. Det finns inte ens en demoversion tillgänglig för fri tillgång, analysen utfördes med hjälp av skyddade skript. Plug-in-modulen är inte svår att packa upp, skyddet förlitar sig endast på god förvirring av källkoden.

PHPCipher. Skydd är en onlinetjänst. Ett arkiv med dina skript laddas upp till webbplatsen och det redan skyddade laddas ner. En betald licens låter dig signera skyddade skript med dina data och använda dem för kommersiella ändamål. Den kostnadsfria licensen tillåter endast personligt bruk. Själva skyddet är en Zend-skyddad PHP-modul som ansluter till skyddade skript. Efter deZend tas skyddsmodulen och erhållande av alla nödvändiga konstanter från den bort helt till källkoden. Det finns ingen obfuscator-funktion.

ByteRun Protector för PHP. En kommersiell produkt, beroende på licenstyp, låter dig skydda skript både på servernivå och på källkodsnivå. Serverskydd med standardfunktioner, inget speciellt. Skriptnivåskydd kan tas bort mycket enkelt automatiskt och manuellt. Det finns ingen offentlig avkodare för serverversionen.

Skydd mycket populärt bland inhemska utvecklare. Det är en säkerhetsmodul som är tungt nedsänkt med tom kod, som är kopplad via include till skyddade skript. Avkodningsalgoritmen är mycket enkel och orsakar inga svårigheter vid manuell eller automatisk borttagning. I alla fall tas den bort helt till källkoden, det finns ingen obfuscator-funktion. Det finns små funktioner för speciella fall av avkodning, men de kommer inte att beskrivas här.

Kodlås. Ett annat populärt försvar, ett utmärkt exempel på analfabet programmering. Det är en applikation i PHP som låter dig koda både själva skripten och resultatet av deras arbete i webbläsaren med hjälp av javascript. Skript kan skyddas med ett lösenord, men på grund av den inkompetenta implementeringen kan lösenordet lätt hittas även utan att ta bort det vadderade skyddet. Skyddsmodulen är ett PHP-skript fyllt med tom kod som ansluter till skyddade skript. Skyddsalgoritmen är mycket enkel, den tas bort helt ner till källkoden. Det finns ingen obfuskationsfunktion.

TrueBug PHP Encoder, mer nyligen TrueBug PHP Obfuscator & Encoder. En mycket intressant beskyddare att utforska. Innan version 1.0.2 användes standardmedel php för gzip-komprimering, från och med version 1.0.3 utvecklade författarna sin egen komprimeringsalgoritm. Den nya TrueBug PHP Obfuscator & Encoder-produkten lägger till funktionalitet för obfuskation och källkodsoptimering. Den enda saken svaghet skydd - en oförändrad algoritm för avkodning av skript, men själva algoritmen ändras för varje version av skyddet. Efter parsning tas skyddet enkelt bort exakt till källkoden, givetvis förutsatt att en obfuscator inte användes.

Zorex PHP CryptZ. Skydd, som CodeLock, är en PHP-applikation och kräver en MySQL-databas för att fungera. Skyddsmodulen är ett plug-in skript i PHP, krypterat i flera lager. Efter parsning kan algoritmen tas bort mycket enkelt exakt till källkoden. Det finns ingen obfuskatorfunktion.

Gratis PHP Encoder. Gratis onlinetjänst för kodning av PHP-skript. Skyddsmodulen är ett plug-in PHP script täckt med Zend, som måste laddas ner från hemsidan.Efter att ha tagit bort Zend och tolkat algoritmen kan skyddet enkelt tas bort helt ner till källkoden. Skyddsalgoritmen är oförändrad, det finns ingen obfuskatorfunktion.

Skript i PHP, primitiv kodning, standard base64. Det förtjänar inte mer uppmärksamhet och är inte av praktiskt intresse.

"Banksajter är trasiga för pengarnas skull, Pentagon är trasig för spionagets skull, och ingen behöver mitt projekt," tyvärr är detta exakt vad de flesta ägare av personliga bloggar, visitkort online och virtuella representationskontor för små företag tror. Endast ett fåtal människor tänker på hur man skyddar en webbplats, men förgäves. I moderna verkligheter är absolut vilken plattform som helst, oavsett typ eller popularitet, av intresse i hackares ögon. Vem kan behöva din resurs och till vad? Låt oss ta reda på det:
1. Scriptkiddis upptåg. Jargongen hänvisar till nybörjare hackare som tar sina första steg in i den "mörka sidan". Efter att ha skaffat flera verktyg, eller skrivit ett par egna program, är de ivriga att testa sin prestation på det första offret de stöter på, och, som regel, välja de enklaste (svagt skyddade och inte uppdaterade CMS) målen.
2. Svart hatt SEO. Tjänsterna från oärliga optimerare används fortfarande - att placera dolda länkar i projektkoden med en TCI på mer än 10 praktiseras fortfarande. Och, först och främst, resurser på öppen källkodsmotorer attackeras. källkod(Joomla, Drupal, OpenCart och så vidare).
3. Bygga ett botnät. Att skydda WordPress med htaccess och plugins är också relevant eftersom absolut vilken resurs som helst kan användas för att skapa ett zombienätverk som används i DDoS-attacker, spam, etc.
4. Säkerhetsskador. Slutligen kanske du inte blir attackerad - huvudmålet kommer att vara värd, och webbplatsen kommer endast att fungera som en stor sårbarhet i leverantörens IT-infrastruktur. Naturligtvis kommer hans öde att vara likgiltigt för hackare.

Konsekvenserna av hacking kan vara de mest obehagliga: förlust av innehåll, eller resursen som helhet, pessimisering i sökresultat sökmotorer, förlust av publik på grund av inskriptionen "Webbplatsen kan hota din dators säkerhet eller mobilenhet”, och till och med risken att bli inblandad i ett brottmål om olagliga handlingar begicks på grundval av din webbresurs.

Det betyder att vi med tillförsikt kan säga att säkerhetsproblem påverkar absolut alla webbansvariga. Och om de försummas kan alla ansträngningar för marknadsföring av sökmotorer (vilket innebär pengar och dyrbar tid) gå till spillo över en natt. Problemet är mycket relevant, så jag bestämde mig för att starta en serie artiklar som ägnas åt nätverkshot och metoder för att bekämpa dem. Tre nummer kommer att täcka det populära CMS-systemet – WordPress.

Metoder för att skydda en WordPress-webbplats

En av de mest primitiva hackningsmetoderna är brute force. Termen översätts bokstavligen som "brute force", och betyder att man skaffar ett inloggnings-/lösenordspar genom en uttömmande sökning av möjliga alternativ. Ofta försöker brute forces att göra deras liv enklare genom att dra fördel av fel i motor- och serverinställningarna - detta hjälper dem till exempel att ta reda på kontonamnet, vilket avsevärt minskar antalet kombinationer. Det är elimineringen av dessa sårbarheter, såväl som metoder för att bekämpa obehöriga åtkomstförsök, som kommer att diskuteras.

1. Använd en unik administratörsinloggning

Som standard uppmanar systemet dig att skapa en användare som heter admin. Men för att skydda webbplatsen, WordPress är bättre Använd bara en inloggning som består av en uppsättning slumpmässiga bokstäver och siffror. På en aktiv resurs kan administratörsnamnet lämnas utan särskilda problemändra med en av två metoder:

Via adminpanelen. Gå till avsnittet "Användare", klicka på knappen "Lägg till ny" och skapa konto. I fältet "Roll", välj "Administratör" och bekräfta åtgärden. Logga sedan in som det nyskapade kontot, gå tillbaka till avsnittet "Användare", välj "admin" och klicka på "Ta bort". I fönstret som öppnas, ställ in alternativknappen på "Länka allt innehåll" och välj en ny administratör från rullgardinsmenyn och klicka sedan på "Bekräfta borttagning."
. Använder phpMyAdmin. Det är mycket lättare att utföra samma procedur via databasens kontrollpanel. Välj önskad databas, hitta tabellen wp_users, hitta raden "admin" (ID=1), klicka på "Redigera" och ange önskat namn.

2. Skapa ett särskilt konto för publikationer

Om du inte avslöjar administratören kommer detta att säkerställa ytterligare skydd. Skapa ett separat konto för att lägga upp artiklar och länka allt tidigare publicerat material till det på det sätt som beskrivs i punkt 1. Lägg sedan till information och kommunicera endast med läsarna från det nya kontot.

3. Ställ in ett komplext lösenord

Följ allmänt accepterade riktlinjer: lösenordet måste vara minst 10 tecken långt, det måste vara unikt och bestå av en slumpmässig sekvens av stora och små bokstäver, siffror och specialtecken.
Under inga omständigheter bör du:
. skapa ett lösenord från meningsfulla fraser
. använda alla faktauppgifter (födelsedatum, flicknamn, bankkontonummer, innevarande år...)
Detta kommer att eliminera risken för att välja en lösenfras från en ordbok, och kommer också att avsevärt öka tiden som krävs för brute force. Så att knäcka en sekvens på 10 tecken som endast består av små bokstäver och siffror (hki458p1fa) kommer att ta 10 dagars datortid för en dator, men om du lägger till versaler och ytterligare tecken (Nv6$3PZ~w1), kommer denna period att öka upp till 526 år, vilket garanterar nästan absolut skydd för WordPress. Att komma på och komma ihåg sådana lösenord är ganska svårt, särskilt om du övervakar flera projekt. Därför, för att generera och lagra dem, är det bättre att använda speciella chefer, till exempel KeePassX, som distribueras gratis, eller ett vanligt testdokument (det är bättre om det är packat i ett arkiv med ett lösenord).

4. Ändra ditt databaslösenord

Reglerna som anges ovan gäller även för MySQL-åtkomstkodsäkerhet. När allt kommer omkring är det där som allt innehåll finns, såväl som hashen för administratörens hemliga fras. Om du redan använder ett svagt lösenord bör du överväga att ändra det. Detta görs på följande sätt:

1. Gå till kontrollpanelen för phpMyAdmin
2. Öppna fliken "Användare" och välj databasägaren
3. Klicka på "Redigera rättigheter"
4. Hitta kolumnen "Ändra lösenord" och ange den nya hemliga sekvensen i lämpliga fält
5. Spara ändringarna genom att klicka på "Ok"

Nu återstår bara att redigera wp-config.php, annars kommer WordPress inte att kunna ansluta till databasen. Hitta raden define('DB_PASSWORD', 'lösenord'); och gå in nytt lösenord istället för ordet lösenord. Observera att eftersom tecknet (') används för att avgränsa SQL-kommandon bör det inte användas som en del av en hemlig fras.

5. Uppdatera lösenord regelbundet

De bör bytas minst en gång var sjätte månad. En extraordinär ändring av kodfraser MÅSTE utföras efter:

Överföra autentiseringsdata till tredje part (programmerare, systemadministratörer, optimerare och andra specialister, även om de arbetar för värdföretaget)
. logga in på en webbresurs från någon annans dator (på en fest, på ett internetcafé)
. auktorisation från utrustning som kan ha äventyrats (en maskin infekterad med ett virus)

6. Glöm inte att ändra kakans hemliga nycklar

De finns i filen wp-config.php. Det finns 8 av dem totalt:

define ("AUTH_KEY", "unik nyckel" ); define ("SECURE_AUTH_KEY", "unik nyckel" ); definiera ("LOGGED_IN_KEY", "unik nyckel" ); define ("NONCE_KEY", "unik nyckel" ); define ("AUTH_SALT", "unik nyckel" ); define ("SECURE_AUTH_SALT", "unik nyckel" ); define ("LOGGED_IN_SALT", "unik nyckel" ); define ("NONCE_SALT", "unik nyckel" );

define("AUTH_KEY", "unik nyckel"); define("SECURE_AUTH_KEY", "unik nyckel"); define("LOGGED_IN_KEY", "unik nyckel"); define("NONCE_KEY", "unik nyckel"); define("AUTH_SALT", "unik nyckel"); define("SECURE_AUTH_SALT", "unik nyckel"); define("LOGGED_IN_SALT", "unik nyckel"); define("NONCE_SALT", "unik nyckel");

Som du lätt kan gissa från namnen på variablerna, är nycklarna ansvariga för att kryptera cookie-filer (en välkänd jargong: cookie, salt, vi matar hackare med salta cookies), som används för att säkerställa att webbplatsen "kommer ihåg" din dator efter auktorisering. Summan av kardemumman är att även om en angripare får tag på hash för administratörslösenordet, kommer han inte att kunna generera de cookies som krävs för att komma åt sidan utan de angivna hemliga fraserna.

För att förbättra säkerheten måste standardteckensekvenser ersättas med unika omedelbart efter CMS-distributionen. För enkelhetens skull har utvecklarna skapat en webbgenerator som finns på www.api.wordpress.org/secret-key/1.1/salt/ - när du loggar in kommer nycklarna att visas för dig, och om du uppdaterar sidan, kombinationerna kommer att uppdateras.

7. Dubbel behörighet för adminpanelen

Htaccess låter dig skydda din WordPress-webbplats ytterligare genom att lägga till autentisering på servernivå. Koden kommer att se ut så här:

< Files wp- login. php> # Ställ in den grundläggande autentiseringstypen - detta betyder att när du försöker# när du kommer åt den angivna katalogen eller filen kommer du att bli ombedd att ange ett lösenord: AuthType grundläggande # Ange texten som kommer att visas i formulärets titel: AuthName "Identifiera dig själv" # Ange sökvägen till filen som innehåller lösenfrasen: AuthUserFile "/home/site/.htpasswd" # Vi anger att när du kommer åt filen wp-login.php måste du ange ett lösenord: Kräv giltig användare # Neka åtkomst till .htpasswd-filen för tredje part:< Files . htpasswd>beställa tillåta, neka förneka från alla

# Välj auktoriseringsskriptfilen: # Ställ in den grundläggande autentiseringstypen - detta betyder att när du försöker # komma åt den angivna katalogen eller filen kommer du att bli ombedd att ange ett lösenord: AuthType basic # Ange texten som kommer att visas i formulärets rubrik: AuthName "Identify yourself" # Ange sökvägen till filen som innehåller lösenfrasen: AuthUserFile "/home/site/.htpasswd" # Vi anger att när du kommer åt filen wp-login.php måste du ange ett lösenord: Kräv giltig användare# Neka åtkomst till .htpasswd-filen för tredje part: beställa tillåta, neka förneka från alla

Samtidigt skulle det vara trevligt att ta hand om själva htaccess-säkerheten. Strängt taget bör ett sådant direktiv specificeras i de grundläggande värdinställningarna, men med tanke på vårdslösheten hos vissa leverantörer är det värt att spela det säkert:

Istället för "logga in" ersätter vi det önskade namnet. Allt som återstår är att skapa själva lösenordet, samt kryptera det, eftersom man lagrar sådan data i öppen form- en oöverkomlig lyx. Det finns många tjänster för detta, men det är bättre att skriva det nödvändiga manuset själv. Detta görs på följande sätt:

1) Skapa en fil med filtillägget .php i Notepad, till exempel crypt.php
2) Ange koden där och ersätt ordet "Lösenord" med lösenordet du skapade:

3) Spara filen och ladda upp till rotkatalogen
4) Följ länken site_name.ru/crypt.php - lösenordet hash kommer att visas på skärmen
5) Spara detta värde i filen .htpasswd och ladda upp det till rotkatalogen och ta bort crypt.php

Den sista handen är att förbjuda visning av innehållet i webbresurskatalogen. Det räcker med att lägga till en enda rad till htaccess:

Alternativ Alla - Index

Alternativ Alla - Index

Detta görs för att hackare inte ska kunna ta reda på vilka filer som finns i projektkatalogerna. På många värdsidor är detta direktiv redan inkluderat i serverinställningarna, men om denna punkt förbises är det värt att lägga till det själv.

8. Installera captcha

Genom att använda captcha kan du skära av, om inte alla, så åtminstone de flesta av brute force-robotarna, och samtidigt. Katalogen med plugins för att säkra en WordPress-webbplats erbjuder många alternativ. Förutom att koppla ihop en egenutvecklad lösning från Google är Captcha av BestWebSoft av blandad typ (grafik och text), som bygger på matematiska operationer, av stort intresse. Oberoende av tjänster, tydlighet och en acceptabel nivå av komplexitet gör modulen till en av de bästa.

Installationen är inte särskilt svår. Fliken "Grundläggande" låter dig välja var captcha ska visas, samt ange en titel och symbol för att markera obligatoriska fält.

Avsnittet "Avancerat" ger möjlighet att skapa dina egna felmeddelanden, samt aktivera ytterligare paket bilder för att göra livet ännu svårare för bots.

En annan användbar funktion är en inbyggd vit lista över IP-adresser för vilka captcha inte kommer att visas.

Resultatet av att installera och aktivera insticksprogrammet blir att ett formulär visas på auktoriseringssidan:

9. Ändra administratörsadressen

När man pratar om hur man skyddar en WordPress-webbplats är det värt att nämna en mer radikal, men också mer komplex metod - att ändra URL:en för auktoriseringssidan på skriptnivå. Förfarandet utförs i flera steg:

1. Byt namn på filen wp-login.php. Använd en slumpmässig sekvens av små latinska bokstäver, siffror och bindestreck. Till exempel: abc-123.php
2. I den resulterande filen, hitta alla referenser till wp-login.php och ersätt dem med det nya namnet.
3. För att sajten ska fungera korrekt måste bytet även göras i: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general -template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my -sites.php, schema.php, ru_RU.po

Efter dessa manipulationer kommer adminpanelen att finnas på site/abc-123.php. Åtkomsten till den nya filen bör vara begränsad och lösenordsskyddad enligt beskrivningen ovan. Du kan också lura potentiella hackare genom att skapa en falsk wp-login.php-fil och även ställa in ett lösenord för den.

Ett ännu enklare alternativ är att använda tillägget "Rename wp-login.php". Efter installation av insticksprogrammet för webbplatsskydd visas ett nytt fält i menyn "Inställningar" -> "Permanenta länkar":

10. Ange admin IP

Du kan ge ytterligare säkerhet om du har en statisk IP-adress. Genom att neka åtkomst till wp-login.php från någon annan dator förutom din egen, kommer du att göra livet mycket svårare för hackare:

< Files wp- login. php>beställa neka, tillåta neka från alla tillåta från 127. 0. 0. 1, 127. 0. 02 #Ange dina IP-adresser separerade med kommatecken

beställ neka, tillåt neka från alla tillåt från 127.0.0.1, 127.0.02 #Ange dina IP-adresser separerade med kommatecken

11. Inaktivera auktoriseringsfel

Vid brute-forcing-lösenord, kommer en angripare att tycka att det är mycket användbart att veta att de angivna uppgifterna var felaktiga. Sådana meddelanden visas vid varje misslyckat inloggningsförsök, och WordPress rapporterar även vad som exakt angavs felaktigt, inloggning eller lösenord. För att bli av med dem, lägg bara till en rad i functions.php:

add_filter("login_errors" , create_function ("$a" , "return null;" ) );

add_filter("login_errors",create_function("$a", "return null;"));

För att göra detta, välj " Utseende” -> ”Editor” -> ”Temafunktioner”. Koden måste skrivas efter öppningstaggen

12. Använd en säker anslutning.

För att kryptera trafik mellan användarens dator och webbservern finns https-protokollet, vars användning eliminerar möjligheten att fånga upp viktig data, i vårt fall identifieringsdata. För att aktivera det måste du först köpa ett SSL-certifikat, som utför två funktioner samtidigt: autentisera en webbresurs och kryptera överförd information. Du kan få det från specialiserade center eller från ett antal domännamnsregistratorer. För icke-kommersiella ändamål räcker det att skaffa ett gratis inträdescertifikat (dessa erbjuds av företaget www.startssl.com). När det gäller installationsprocessen, som regel, beskrivs den i detalj i värdens hjälpsektion.

Efter att ha fått ett SSL-certifikat måste du konfigurera omdirigering av den administrativa delen av webbresursen till en säker anslutning. När det gäller WordPress görs detta med följande konstruktion:

< IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine On RewriteCond % ( HTTPS) = off RewriteCond % ( REQUEST_URI) =/ wp- login. php RewriteRule (.*) https:

Alternativ +Följ symbollänkar RewriteEngine On RewriteCond %(HTTPS) =off RewriteCond %(REQUEST_URI) =/wp-login.php RewriteRule (.*) https://%(HTTP_HOST)%(REQUEST_URI)

Du kan också tvinga fram användningen av SSL-certifikat på motornivå. För att göra detta, öppna filen wp-config.php och lägg till efter

definiera ("FORCE_SSL_ADMIN" , sant );

define("FORCE_SSL_ADMIN", true);

Dessutom kan du ställa in en global omdirigering från http till https. För nya webbplatser är detta tillvägagångssätt optimalt, med tanke på att Google uppmuntrar säkra projekt och ger dem viss prioritet i sökresultaten:

< IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine on RewriteCond % ( HTTPS) = off RewriteRule ^(.* ) $ https: //%(HTTP_HOST)%(REQUEST_URI)

Alternativ +Följ symbollänkar RewriteEngine på RewriteCond %(HTTPS) =off RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

13. Blockera inkräktare

Om du upptäcker misstänkt aktivitet från vissa IP-adresser bör du blockera deras åtkomst till webbplatsen. Detta görs i analogi med den tidigare metoden. Skillnaden är att direktiven är skrivna för projektet som helhet, och vi listar adresserna till de vi vill förbjuda:

Beställ Tillåt, Neka Tillåt från alla Neka från 127.0.0.1, 127.0.02 #Ange oönskade IP-adresser

Metoden är pålitlig, men ineffektiv. För det första är det på något sätt nödvändigt att spela in förfrågningar från brutala våldsmakare och skilja dem från respektabla besökare. För det andra, under en massiv attack, kommer du helt enkelt inte att kunna spåra och ange IP-adressen för hackare och botar manuellt. Denna metod är bara bra om administratören har en pålitlig "svart lista" med adresser.

I andra fall kan du använda ett plugin för att skydda din WordPress-webbplats som heter WP Cerber. Denna lösning är helt gratis, samtidigt som den erbjuder en mycket imponerande uppsättning verktyg utformade för att förhindra CMS-hackning. Du kan installera det direkt från adminpanelen.

Som standard erbjuds ganska vettiga parametrar. Antalet försök bör dock utökas till 5, för att undvika missförstånd.

Kryssrutan bredvid "Blockera IP på valfri wp-login.php-förfrågan" bör vara markerad om du ändrar administratörsadressen på det sätt som beskrivits tidigare.

Du kan också använda ditt eget WP Cerber-verktyg för dessa ändamål:

Citadel-webbplatsskyddspluginläget kräver inte heller ytterligare konfiguration. Den är utformad för att "bevara" ett projekt under en massiv brute force attack. Det är bättre att avmarkera rutan bredvid "Spela in inloggningsförsök till en fil" - detta hjälper till att eliminera ytterligare belastning på servern.

Fliken "Åtkomstlistor" används för att skapa en "svart" och "vit" lista med IP-adresser (om du har en statisk adress, se till att lägga till den i listan över betrodda), och avsnittet "Verktyg" låter dig för att importera och exportera tidigare gjorda inställningar. Dessa möjligheter kräver dock inte separat övervägande.

14. Flytta konfigurationsfilen

Som vi fick reda på ovan lagrar wp-config.php viktiga data som inloggning och lösenord för åtkomst till MySQL, såväl som API-nycklar. Nästa steg verkar uppenbart - skydda WordPress via htaccess genom att begränsa filåtkomst:

< Files wp- config. php>Beställ tillåt, neka Neka från alla

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

Det finns dock en mer pålitlig metod. WordPress har en mycket intressant funktion som få människor känner till. Motorn tillåter att konfigurationsfilen placeras en nivå ovanför rotkatalogen..php kan flyttas till webbplatskatalogen. I det här fallet blir filen helt otillgänglig via Internet, medan informationen den innehåller fortfarande kommer att läsas av CMS.

15. Lägg till REFERER-kontroll

En metod som har bevisat sig för att skydda WordPress från skräppost kommer också att hjälpa i fallet med brute forcerar. När allt kommer omkring är brute-force-lösenord inte på något sätt en manuell uppgift: specialiserade program används för dessa ändamål. Detta innebär att genom att aktivera header-checkning i inkommande förfrågningar, kan du klippa ut bots som "kom från ingenstans" med en tom HTTP REFERER:

< IfModule mod_rewrite. c>RewriteEngine On RewriteCond % (REQUEST_METHOD) POST RewriteCond % (REQUEST_URI) . (wp- kommentarer- post | wp- login) \. php* RewriteCond % ( HTTP_REFERER) !.* tekseo. su.* [ ELLER] RewriteCond % ( HTTP_USER_AGENT) ^$ RewriteRule (.* ) http: //%(REMOTE_ADDR)/$1

RewriteEngine On RewriteCond %(REQUEST_METHOD) POST RewriteCond %(REQUEST_URI) .(wp-comments-post|wp-login)\.php* RewriteCond %(HTTP_REFERER) !.*webbplats.* RewriteCond %(HTTP_USER RewriteCond %(HTTP_$USER) *) http://%(REMOTE_ADDR)/$1

16. Säker XML-RPC

Från och med version 3.5 av WordPress har möjligheten att inaktivera XML-RPC-anropsprotokollet för fjärrprocedurer försvunnit. Det behövs främst för att interagera med mobilapplikationer, men alla behöver inte en sådan funktionalitet. Samtidigt används xmlrpc.php aktivt för att utföra DDoS-attacker, vilket är akilleshälen i hela projektet.

Dessutom tänkte hackare på att använda XML-RPC för brute force. Genom att använda metoden wp.getUsersBlogs kan du söka efter autentiseringsuppgifter mycket snabbare än genom adminformuläret. Eftersom många XML-RPC-anrop kräver auktorisering kan en begäran som:

< methodCall> < methodName>wp. getUsersBloggar < params>< param>< value>< string>administration < param>< value>< string> 12345

wp.getUsersBloggar administration 12345

kommer att få motorn att rapportera om den godkända kombinationen är korrekt. För att bli av med detta gissel måste du inaktivera protokollet helt. Du kan göra detta på flera sätt:

1) Genom att blockera åtkomst till filen xmlrpc.php via htaccess

require_once(ABSPATH . "wp-settings.php");

måste registreras

funktion remove_x_pingback($headers) (unset($headers["X-Pingback"]); return $headers; ) add_filter("wp_headers", "remove_x_pingback");

4) Använda kontroll-XML-RPC-publiceringsplugin, som returnerar motsvarande alternativ till "Inställningar" -> "Skrivning":

Observera: tillägget inaktiverar protokollet omedelbart efter aktivering, och i inställningarna kan du aktivera det genom att markera lämplig kryssruta.

17. Övervaka brute force attacker

Slutligen är det värt att nämna ett intressant plugin för att logga hackningsförsök - Autentisering och xmlrpc-loggskrivare. Även om WP Cerber har inbyggda övervakningsverktyg, kommer denna modul fortfarande att vara användbar, särskilt för dem som behöver funktionerna i protokollet som beskrivs ovan. AX LogWriter kan övervaka brute force genom xmlrpc.php, så att du kan bedöma graden av hot och tillrådligheten av att helt vägra att använda dess kapacitet. Slutligen, för dem som inte har varit involverade i säkerheten för sitt projekt alls, kommer ett insticksprogram för webbplatsskydd att få upp ögonen för vikten av de listade aktiviteterna.

Det är enkelt att använda AX LogWriter. Efter installationen visas ett motsvarande avsnitt i admin-menyn där du kan göra alla nödvändiga ändringar:

I fältet "Feltyp" väljer du sparmetoden. Stöder inspelning i systemloggen, Apache-serverloggen, samt möjligheten att skapa en anpassad fil. I det senare fallet kan du också konfigurera dess namn (Custom Error Log Name) och katalog (Custom Error Log Path). Detta öppnar stora möjligheter för systemadministratören - lösningen kan till exempel användas tillsammans med fail2ban. Glöm inte heller att välja lämplig tidszon i kolumnen Tidszon.

Den anpassade loggen kan ses direkt från adminpanelen på sidan Custom Log Viewer:

Låt oss sammanfatta:

Metoderna som listas kommer att bidra till att avsevärt öka säkerheten för din resurs och skydda den från brute force-bots, onlinehuliganer och utövande scriptkiddies. Allt som beskrivs ovan är dock bara toppen av ett isberg. Angripare har också mycket mer sofistikerade metoder i sin arsenal. Och i nästa artikel kommer vi att prata om hur du skyddar dig från riktiga hackare som använder olika sårbarheter i motorn och serverprogramvaran. Som i det här materialet kommer, förutom de allmänna "hygienreglerna", viktiga CMS-inställningar, metoder för kodändring samt de mest relevanta plugins att övervägas.

Låt oss fundera på vem en hacker är? En hacker är inte en krackare! Folk blandar ofta ihop dessa begrepp. En hacker är för det första en person med okonventionellt tänkande, och det är hans styrka så att säga.

För att framgångsrikt motstå en hacker måste du också lära dig att tänka utanför ramarna. Som man säger, vi slår ut kilar med kilar.

Idag kommer jag att erbjuda dig ett mycket ovanligt sätt att skydda dig mot php include-attacker. Naturligtvis passar det inte alla. Och för att vara ärlig skyddar den inte från själva attacken, utan från dess upptäckt. Fascinerad?

Hur hittar man inkludering...

Låt oss först förstå hur exakt en angripare försöker upptäcka en sårbarhet.

Det ser ut så här. Angriparen modifierar alla inkommande parametrar en efter en, förutsatt att data från dessa parametrar hamnar i include-funktionen. Tja, eller om det bara försöker "inkludera" filer. Och för att avgöra om det finns en sårbarhet eller inte, måste han inkludera någon fil på målsystemet (han fick det - det finns en sårbarhet, nej - det finns ingen sårbarhet).

Naturligtvis, om en angripare agerar utifrån, så känner han inte till strukturen för kataloger och filer, och kan inte inkludera någon fil, eftersom han inte kommer att känna till vägen till den. Men det finns filer som alltid finns i systemet, och som du alltid har läsrättigheter till. För Linux är detta /etc/passwd, och för Windows, låt det vara C:\boot.ini. Men förresten, vi är av lite intresse för Windows, så vi kommer att fortsätta prata om passwd

/etc/passwd

Du har förmodligen stött på fler sådana här poster i dina loggar:

Action=../etc/passwd%00
?action=../../etc/passwd%00
?action=../../../etc/passwd%00
?action=../../../../etc/passwd%00
?action=../../../../../etc/passwd%00
?do=../etc/passwd%00
?do=../../etc/passwd%00
?do=../../../etc/passwd%00
?do=../../../../etc/passwd%00
?do=../../../../../etc/passwd%00
?id=../etc/passwd%00
?id=../../etc/passwd%00
?id=../../../etc/passwd%00
?id=../../../../etc/passwd%00
?id=../../../../../etc/passwd%00

Om ja, vet då att de försökte hitta php include (eller möjligheten att läsa godtyckliga filer, men vi är inte intresserade av det nu). Så, om en av dina parametrar inte bearbetas korrekt och hamnar i en funktion omfatta(), då skulle filen /etc/passwd inkluderas, dess innehåll skulle tolkas som ett PHP-skript, och eftersom det inte innehåller PHP-kodtaggar, skulle det matas ut till webbläsaren oförändrat. Detta skulle fungera som en "markör" för angriparen om närvaron av en sårbarhet.

Varför skriver jag detta, för när man söker efter include kommer en angripare definitivt (jag garanterar att i 90% av fallen) försöka inkludera en fil /etc/passwd.

Försvara dig, sir!

Du tänker förmodligen nu: "Vill han erbjuda en vanlig WAF och filtrera paket baserat på närvaron av /etc/passwd i dem?" Nej. Detta är standardsättet. Det här är ett exempel på hur en vanlig människa tänker.

Låt oss visa lite fantasi. Varför lägger vi inte bara till lite PHP-kod till innehållet i passwd-filen? Och om en angripare plötsligt lyckas inkludera den, kommer vår php-kod att exekveras. (Tycker du att det är nonsens? - titta på slutsatsen)

Eftersom vi vet att den enda som skulle kunna tänka sig att inkludera den här filen är en hacker, bör vår php-kod förbjuda den, och för att förhindra att vårt system hackas ytterligare, blockera den sårbara filen, och det är tillrådligt att meddela administratören om händelsen.

Men hur kan du lägga till php-kod till /etc/passwd eftersom dess syntax är strikt reglerad? Varje användare har ett "kommentar"-fält - en beskrivning av användaren; du kan ange vad du vill där (förutom kolon, förstås). Därför tar vi och lägger till användaren i systemet med den kommentar vi behöver. Efter detta kommer /etc/passwd att innehålla denna rad

root:x:0:0:Superuser:/:
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
säkerhetsanvändare:*:1001:1001::/:

Tja, i det anslutna skriptet utför vi redan de åtgärder du behöver - blockera användaren, blockera begäran, meddela administratören.

Som ett resultat har vi kommit fram till en slags fälla som kan skydda din webbplats från hackning.

Slutsats

Ja, jag är fullt medveten om att allt som skrivits ovan ser ut som nonsens. Och jag förstår mycket väl att ingen kommer att använda detta i praktiken. Men det var inte därför jag skrev. Jag skrev för att visa ett exempel på ett icke-standardiserat tillvägagångssätt inom skyddsområdet.

Tack för din uppmärksamhet =)

Vi skapar vår egen registreringssida för en multisite istället för standarden wp-signup.php.

I en typisk WordPress-installation matas registreringssidan (inloggning, lösenordsåterställning) ut av filen wp-login.php.

• /wp-login.php - auktorisering
• /wp-login.php?action=register - registrering
• /wp-login.php?action=lostpassword - lösenordsåterställning

Det finns separata villkor för en multisite i wp-login.php. Så när du följer länken /wp-login.php?action=register på en multisite, kommer WordPress att omdirigera till sidan /wp-signup.php. Många teman får inte sidan att se särskilt attraktiv ut, så vi gör en egen.

Nätverkets huvudsida

Som standard öppnar WordPress registreringssidan (wp-signup.php) på huvuddomänen (webbplatsen) i nätverket. Du kan dock skapa en separat registreringssida för varje webbplats i ditt nätverk, även om de har olika teman. Vi kommer att överväga fallet där alla webbplatser i nätverket har sin egen registreringssida, men samma tema används och webbplatserna skiljer sig endast i språk. Om du använder olika teman måste du skriva mer kod.

functions.php?

Nej. Detta filnamn verkar nämnas i varje artikel om WordPress. I vårt fall, med tanke på att registreringsfunktionen är designad för flera webbplatser, är det vettigt att inkludera den i MU-plugins, som laddas när någon webbplats öppnas.

Lyrisk utvikning

Det är värt att notera att MU-plugins laddas före vanliga plugins och innan WordPress-kärnan är fulladdad, så att anropa vissa funktioner kan leda till fatala fel i PHP. Sådan "tidig" lastning har också sina fördelar. Låt oss säga att du inom något tema inte kan koppla till vissa åtgärder som utlöses även innan functions.php-filen laddas från temat. Ett exempel på detta är åtgärderna från Jetpack-pluginen av formen jetpack_module_loaded_related-posts (related-posts är namnet på modulen), med vars hjälp det är möjligt att övervaka aktiviteten hos moduler i Jetpack. Det är omöjligt att "koppla" till denna åtgärd från temafilen, eftersom åtgärden redan har aktiverats innan temat laddas - plugins laddas före teman. Du kan ta en titt på den allmänna bilden av WordPress-laddningsordningen på Action Reference-sidan i codexen.

Filordning

MU-plugins kan innehålla valfritt antal filer och vilken struktur som helst som verkar logisk för dig. Jag håller mig till något i stil med denna hierarki:

|-mu-plugins |-|-load.php |-|-|-selena-nätverk |-|-|-|-signup |-|-|-|-|-plugin.php |-|-|-| -|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php

Filen load.php innehåller alla nödvändiga "plugins" för vårt nätverk:

// Ladda Översätter för alla tillägg load_muplugin_textdomain ("selena_network", "/selena-network/languages/"); // Nätverksregistrering kräver WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Ytterligare plugins // kräver WPMU_PLUGIN_DIR ...

Inuti selena-network-mappen lagras plugin-mappar, var och en med sin egen plugin.php, som vi inkluderar i load.php. Detta ger dig flexibilitet och möjlighet att snabbt stänga av och på saker.

Adress för registreringssidan

Använd filtret wp_signup_location för att ange adressen till registreringssidan. Den finns i filen wp-login.php och är ansvarig för omdirigeringen till wp-signup.php.

Fall "register" : if (is_multisite()) ( wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); exit;

Låt oss lägga till vår funktion till mu-plugins/selena-network/signup/plugin.php, som returnerar adressen till registreringssidan på den aktuella webbplatsen:

Funktion selena_network_signup_page ($url) ( return home_url () . "/signup/"; ) add_filter ( "wp_signup_location", "selena_network_signup_page", 99);

selena_network är prefixet som jag använder i namnen på alla funktioner i MU-plugins på min sida för att undvika kollisioner, det bör ersättas med ditt eget unika prefix. Prioriteten för att lägga till ett filter är 99, eftersom vissa plugins, till exempel bbPress och BuddyPress, kan skriva över denna adress med sina egna (MU plugins laddas tidigare än vanliga plugins, se ovan). Observera att home_url() används istället för network_site_url() för att hålla besökaren på samma domän. Vilken URL som helst kan användas som adress.

Skapa en sida

Låt oss nu skapa en sida med adressen site.com/signup/ genom det normala gränssnittet, och i mappen för barntema är mallen för vår nya sida page-signup.php. Istället för ordet "registrering" kan du använda ett unikt ID.

Inuti den nya mallen måste du anropa funktionen selena_network_signup_main(), som visar registreringsformuläret.

Det är värt att notera att hela mallprocessen är valfri och du kan istället skapa din egen kortkod som också anropar funktionen selena_network_signup_main().

wp-signup.php och wp-activate.php

Låt oss nu skapa en funktion som visar registreringsformuläret. För att göra detta, kopiera filerna wp-signup.php och wp-activate.php från WordPress-roten till mu-plugings/selena-network/signup/ (och glöm inte att ansluta dem inuti mu-plugins/selena-network /signup/plugin.php) . Ytterligare manipulationer med filer är extremt svåra och långa att beskriva, så du måste göra dem själv. Jag ska bara beskriva exakt vad som behöver göras och publicera källfilerna för mitt projekt:

1. I början av filen, ta bort alla require , funktionsanrop och annan kod utanför funktionerna.
2. Byt namn på alla funktioner genom att lägga till unika prefix till namnen.
3. Slå in den nedre delen av wp-signup.php-koden i selena_network_signup_main-funktionen och skriv i början global $active_signup; .
4. Byt ut layouten med din egen på rätt ställen.

Inuti wp-activate.php behöver du göra ungefär samma sak:

1. Ta bort all kod utanför funktionerna, slå in layouten i en separat funktion.
2. Ändra layouten på platser där det behövs.

Filen wp-activate.php är ansvarig för kontoaktiveringssidan. Som med registreringssidan måste du skapa en separat mall för den, inuti vilken du måste anropa funktionen från filen wp-activate.php.

Skickar aktiveringsbrev

Registreringssidan skickar ett e-postmeddelande till besökaren med en länk för att aktivera sitt konto. Som standard görs detta av funktionen wpmu_signup_user_notification() från filen ms-functions.php. Du kan låna dess funktionalitet för din egen funktion. Anledningen till att undvika att använda den här funktionen är att den skickar kontoaktiveringslänken från wp-activate.php. Du kan "stänga av" den här funktionen med filtret wpmu_signup_user_notification genom att returnera det falskt (om detta inte görs kommer aktiveringsbrevet att skickas två gånger, okej, faktiskt två olika bokstäver).

Funktion armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) ( // ... // Kod från funktionen wpmu_signup_user_notification() wp_mail($user_email, wp_specialchars_mes_demes($subage)), $ ; return false; ) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

Som ett resultat började registreringssidan i Selena-temat se mycket renare och snyggare ut.

Slutsats

Det finns många andra inte särskilt korrekta sätt på Internet att göra samma sak - Apache-omdirigeringar, AJAX-formulär som inte fungerar utan Java Script, etc. Jag gillade inte riktigt allt detta, så jag försökte göra det lika korrekt som möjligt på min egen hemsida.

Jag noterar att du bör redigera filerna noggrant och försöka att inte avvika för mycket från de ursprungliga, så att det i framtiden, om WordPress ändrar filerna wp-signup.php och wp-activate.php, blir det lättare att jämföra dem med varandra för att hitta förändringar.

Glöm inte att titta på källkoden för alla funktioner som beskrivs ovan för att helt förstå vad och hur som händer inuti koden.

Bonus. Skydd mot spammare

Även de minsta WordPress-sajterna plågas ofta av skräppostregistreringar. Du kan skriva oändliga villkor för att filtrera bots, ofta mer som ett försök att skapa artificiell intelligens :) I fallet med en multisite hjälpte en vanlig omdirigering i Apache mig mycket, med hjälp av vilken jag bad om en 404 när jag öppnade / wp-signup.php och /wp-acitvate.php (jag är ingen expert på att konfigurera Apache, så mina regler kanske inte är särskilt korrekta).

RewriteEngine På RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # BÖRJA WordPress # Vi rör inte reglerna från WordPress som standard :) # ... # END WordPress

P.S. Jag försöker beskriva vissa saker från tredje part så detaljerat som möjligt, för när jag började fanns det ibland ingen som kunde föreslå och förklara många saker. Jag tror också att sådana små tips om annat material kommer att uppmuntra någon att lära sig något nytt och utöka sitt kunskapsområde. RewriteRule-poster använder reguljära uttryck, de är inte alls komplicerade, till exempel betyder ^-symbolen början på en rad.

När det kommer till applikationssäkerhet är det viktigt att inte bara ta hand om hårdvaran och operativsystemet utan också att skriva säkra skript. I den här artikeln kommer du att lära dig hur du säkerställer säkerheten för din applikation och gör den mindre sårbar. Nedan finns en lista över åtgärder som hjälper dig att skydda din applikation från alla typer av attacker:

1. Validering av inkommande data
2. Skydd mot XSS-attacker
3. Skydd mot CSRF-attacker
4. Förhindra SQL-injektioner
5. Filsystemskydd
6. Sessionsdataskydd
7. Fel vid bearbetning
8. Skyddar inkluderade filer

Validering av inkommande data

När du designar en applikation bör du sträva efter att skydda den från "dålig" inkommande data. Regeln att följa är ungefär så här: "Lita aldrig på vad användaren anger." Även om de flesta användare inte är ett hot, finns det alltid möjligheten att någon kanske vill hacka din webbplats med hjälp av dålig data som matas in via formulär eller adressfältet. Om du alltid kontrollerar och filtrerar inkommande data har du goda chanser att skriva en säker applikation.

Kontrollera alltid dina data i PHP-skript. Om du använder JavaScript för att validera data kan en angripare när som helst inaktivera det i sin webbläsare. I det här fallet är din ansökan i fara. Ingen är emot JavaScript-validering, men för ett bra skydd måste du dubbelkolla data i PHP-skript.

Skydd mot XSS-attacker

Cross-site scripting eller XSS-attack är en attack baserad på kodinjektion på potentiellt sårbara sidor. Faran är att skadlig kod kan matas in via formulär och sedan visas i webbläsaren.

Låt oss säga att din webbplats har ett formulär för att skriva kommentarer, som visas direkt efter att du lagt till det. En angripare kan ange en kommentar som innehåller JavaScript-kod. Efter att ha skickat in formuläret skickas uppgifterna till servern och förs in i databasen. Efter detta hämtas data från databasen och den nya kommentaren visas på HTML-sidan, inklusive den inbäddade JavaScript-koden. Det kan omdirigera användaren till någon skadlig sida eller till en nätfiskesida.

För att skydda dina applikationer, skicka inkommande data genom funktionen strip_tags() som tar bort alla taggar som finns. Använd funktionen htmlentities() när du visar data i en webbläsare.

Skydd mot CSRF-attacker

Nästa typ av attack vi ska titta på är CSRF-attacken, eller förfalskning av förfrågningar mellan platser. Angriparen använder olika knep för att få konfidentiell information eller slutföra en transaktion utan offrets vetskap. Detta sker främst på dåligt skyddade webbplatser, där affärslogik baseras på GET-förfrågningar.

Generellt sett är GET-förfrågningar idempotenta. Idempotens innebär i detta sammanhang att samma sida kan nås så många gånger som önskas utan ingripande från tredje part. Det är därför GET-förfrågningar endast ska användas för att få tillgång till information, men inte i något fall för att utföra olika typer av transaktioner.

Följande enkla exempel visar hur en oskyddad webbplats kan bli föremål för en CSRF-attack:

Låt oss anta att Bob vill utföra en CSRF-attack på Alice. Han skapade en speciell url-adress och skickade den till Alice via e-post:

Besök min sida!

Om Alice är auktoriserad på example.com och följer den här länken, kommer $1000 att överföras från hennes konto till Bobs konto. Alternativt kan Bob skicka bilden också och lägga till en "dålig" adress i src-attributet.

Webbläsaren kommer inte att kunna visa denna bild, eftersom den inte finns, men begäran kommer att göras utan Alices vetskap och medverkan.

För att förhindra denna typ av attack, använd endast POST-förfrågningar till processer som är utformade för att ändra information i databasen. Använd inte $_REQUEST. Använd $_GET för att bearbeta GET-parametrar och $_POST för att hämta POST-parametrar.

Som en ytterligare åtgärd kan du generera någon sorts unik token och bifoga den till varje POST-förfrågan. När en användare loggar in i systemet kan en slumpmässig token genereras och spelas in i sessionen. Eftersom alla formulär visas för användaren måste denna token skrivas till ett dolt fält. Applikationens affärslogik måste tillhandahålla funktionalitet som kontrollerar token från formulären och token som lagras i sessionen.

Förhindra SQL-injektioner

Du bör använda PDO för att köra databasfrågor. Med parametriserade frågor och förberedda uttryck kan du mildra hotet från SQL-injektioner.

Låt oss titta på följande exempel:

I koden ovan skickar vi en begäran till metoden prepare() inklusive de namngivna parametrarna: :name och:age . Således är frågan förkompilerad för ytterligare datasubstitution. När du anropar metoden execute() genereras och exekveras begäran fullständigt. Om du använder en liknande teknik kommer alla försök från en angripare att utföra SQL-injektion att reduceras till noll.

Filsystemskydd

Som ansvarig utvecklare bör du alltid skriva kod som inte utsätter ditt filsystem för fara. Låt oss titta på koden som laddar ner en fil beroende på vilken data användaren skickar in.

Det här skriptet är mycket farligt, eftersom det låter dig få tillgång till vilken katalog som helst som är tillgänglig från skriptfilen: katalogen med sessioner, systemmappar och mycket mer.

Sessionsdataskydd

Som standard skrivs all sessionsinformation till den tillfälliga katalogen. Om du använder delad hosting kan någon förutom du skriva ett skript och läsa sessionsdata. Se därför upp med att lagra lösenord eller kreditkortsnummer i sessioner.

Om du fortfarande behöver lagra sådan data i en session, skulle kryptering vara den bästa åtgärden. Detta löser inte helt problemet, eftersom den krypterade informationen inte är 100% säker, men den lagrade informationen kommer att vara oläsbar. Du kanske också vill överväga att lagra sessionsdata på en annan plats, till exempel en databas. PHP har en speciell metod session_set_save_handler() som gör att du kan lagra sessionsdata på ditt eget sätt.

Sedan PHP 5.4 kan du skicka ett objekt av typen SessionHandlerInterface till session_set_save_handler() .

Fel vid bearbetning

Under applikationsutveckling är det värt att uppmärksamma alla typer av fel som kan uppstå, dock måste de döljas för slutanvändare. Om fel visas för användare gör detta din webbplats sårbar. Så den bästa lösningen skulle vara att ha en annan konfiguration för produktionsservern och utvecklingsservern.

På en offentlig server måste du inaktivera alternativ som display_errors och display_start_up_errors, men alternativ som error_reporting och log_errors måste vara aktiva så att alla fel som användare stöter på registreras i loggarna.

Du kan också använda set_error_handler för att definiera din egen felhanterare. Det kan dock finnas begränsningar här, eftersom den inbyggda hanteraren är sämre än den inbyggda PHP-mekanismen. Felen E_CORE_ERROR , E_STRICT eller E_COMPILER_ERROR kommer inte att fångas i samma fil som den angivna hanteraren. Dessutom kan fel som kan uppstå i själva hanteraren inte fångas upp.

För ett mer elegant sätt att fånga undantag bör potentiellt farlig kod placeras i ett försök/fånga-block. Alla inbyggda undantag måste vara objekt av undantagsklasser eller underklasser. Om undantag kastades kan de bearbetas i ett försök/fånga-block.

Skyddar inkluderade filer

Ofta laddas andra filer i PHP-skript, som att ansluta till databasen och många andra. Vissa utvecklare ger sådana filer filtillägget .inc. PHP analyserar inte sådana filer som standard. Om du kommer åt dem direkt kommer användaren att kunna se texten i denna fil. Om en hacker lyckas få tillgång till filen som lagrar anslutningsdata till databasen, kan han därefter få tillgång till all data i din applikation. Så använd alltid filtillägget .php för uppladdade filer och lagra dem där det inte finns någon direkt användaråtkomst.

Slutsats

Om du följer dessa 8 regler kommer detta att avsevärt förbättra din applikations motståndskraft mot olika typer av attacker. Lita inte på data som angetts av användare, skydda dina filer och databas.