Guider: PHP- och serversäkerhet
Fackartiklar för administratörer och utvecklare: upptäcka webshells, härda php.ini, analysera loggar, programmera säkert.
PHP2Shell-tidslinje: kronologi från 17 till 25 oktober 2026
Alla belagda datum kring PHP2Shell i en översikt, från det första observerade angreppsförsöket till läget den 25 oktober 2026, och vad de innebär för er granskning.
Läs mer →02Bekräftelse på PHP-uppdatering från webbhotellet: så frågar ni efter patchstatus
En visad PHP-version bevisar lite efter PHP2Shell. Med den här mallen begär ni en bekräftelse från ert webbhotell som ni kan dokumentera.
Läs mer →03Upptäcka och ta bort webshell
Hur ni spårar upp bakdörrar på PHP-webbservrar utan att förstöra spår, och varför det sällan räcker att bara radera.
Läs mer →04Hitta WordPress-bakdörrar: spåra dem systematiskt
Var bakdörrar i WordPress typiskt gömmer sig och hur administratörer spårar upp dem systematiskt med WP-CLI och några få kommandon.
Läs mer →05Konfigurera php.ini säkert
Vilka inställningar i php.ini som minskar angreppsytan, hur ni skyddar dem mot överskrivning och vad som gäller extra efter PHP2Shell.
Läs mer →06Använd PHP disable_functions rätt
Med disable_functions spärrar ni riskfyllda PHP-funktioner. Så fastställer ni listan efter er applikation utan att lamslå webbplatsen.
Läs mer →07open_basedir och isolering per webbplats
Så hindrar ni med open_basedir, egna systemanvändare och separata PHP-FPM-pooler att ett intrång i en webbplats drabbar alla andra på servern.
Läs mer →08Filrättigheter på webbservern
Varför webbservern inte får ändra sin egen kod, vilka rättigheter som är lämpliga för filer och mappar och hur ni snabbt kontrollerar nuläget.
Läs mer →09composer audit: kontrollera beroenden efter sårbarheter
Hur utvecklare med composer audit hittar kända sårbarheter i bibliotek, automatiserar kontrollen och undviker typiska fel i deployment.
Läs mer →10PHP End of Life: risker med föråldrade versioner
Vad slutet på supporten för en PHP-version betyder, vilka grenar som efter PHP2Shell fortfarande får officiella patchar och hur ni gör migreringen planerbar.
Läs mer →11Förhindra SQL-injektion i PHP
Så utesluter utvecklare tillförlitligt SQL-injektion i PHP-applikationer med Prepared Statements, vitlistor och minimala databasrättigheter.
Läs mer →12Förhindra XSS i PHP: avvärj cross-site scripting säkert
Så förhindrar utvecklare cross-site scripting i PHP-applikationer: kodning efter sammanhang, auto-escaping i mallar, rensning av HTML och en Content Security Policy.
Läs mer →13Säkra filuppladdningar i PHP: PHP-uppladdningssäkerhet
Uppladdningsformulär är en vanlig väg för webshells. Så kontrollerar ni filtyper rätt, lagrar filer säkert och hindrar servern från att köra uppladdade skript.
Läs mer →14Säkra sessioner i PHP: PHP-sessionssäkerhet i praktiken
Sessioner håller användare inloggade och är därför ett lönsamt mål. Så konfigurerar ni cookies, sessions-ID och lagringsplatser säkert och genomför PHP2Shell-anvisningen om upload progress.
Läs mer →15Osäker deserialisering i PHP: unserialize och säkerhet
unserialize() med främmande data kan i värsta fall leda till kodkörning. Så ersätter ni det med JSON, begränsar det där det måste vara kvar och hittar riskfyllda ställen i koden.
Läs mer →16Förhindra Local File Inclusion i PHP: LFI och RFI
När include eller require tar över sökvägar från förfrågan kan angripare ladda främmande filer. Så bygger ni sidval och mallar säkert och skyddar dessutom servern.
Läs mer →17Skydda admininloggningar mot brute force: brute force-skydd för varje inloggning
Automatiserade lösenordsförsök drabbar varje nåbar inloggningssida. Så bromsar ni angripare med rate limiting och Fail2ban, skyddar konton med en andra faktor och lagrar lösenord rätt.
Läs mer →18DDoS eller hackerangrepp? Bedöm angreppen rätt
Långsam webbplats, hög belastning, märkliga filer: Om en DDoS eller ett intrång ligger bakom avgör rätt reaktion. Så bedömer ni läget med några få kontroller.
Läs mer →19Analysera webbserverloggar efter ett angrepp: läs åtkomstloggen rätt
Loggfiler är efter ett angrepp ofta det viktigaste spåret. Så säkrar ni åtkomst-, fel- och PHP-loggar rätt, hittar avvikande förfrågningar och undviker typiska fel i analysen.
Läs mer →20Införa tvåfaktorsautentisering för adminåtkomst
Ett stulet lösenord får inte räcka för att ta över er server eller butik. Så väljer ni lämplig metod, skyddar alla adminåtkomster och planerar nödåtkomst.
Läs mer →21Backupstrategi för servrar: säkerhetskopior enligt 3-2-1-regeln
En säkerhetskopia hjälper bara om den överlever ett angrepp och går att återställa. Så genomför ni 3-2-1-regeln för webbservrar och planerar lagring och tester rätt.
Läs mer →22Säkerhetsheaders för webbplatser: sätt säkerhetsheaders rätt
Säkerhetsheaders instruerar webbläsaren att skydda era besökare bättre. Så sätter ni de viktigaste headerna i Nginx och Apache, inför en Content Security Policy stegvis och kontrollerar resultatet.
Läs mer →23Ta bort Googles varning ”Den här webbplatsen har hackats”
En hackvarning i sökresultaten kostar besökare och förtroende. Så rensar ni webbplatsen grundligt, hittar dolda skräpsidor och begär granskning i Search Console.
Läs mer →24Checklista efter en hackning: 20 punkter för uppföljningen
Efter ett angrepp räknas rätt ordning. Den här checklistan leder i 20 punkter genom begränsning, bevissäkring, sanering, nya åtkomster, skyldigheter och dokumenterat avslut.
Läs mer →Varje timme räknas. Skriv till oss nu.
Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.