Ultimate PHP Security Best Practices

Ultimate PHP Security Best Practices

eftersom PHP är ryggraden för nästan varje webbplats, därför bör PHP-säkerhet inte betraktas som försumbar till varje pris. PHP-utvecklare har dock förmånen att undvika vanliga hot som förfalskning av webbplatsförfrågningar, SQL-injektioner och datahantering. Och allt detta kommer till nytta med hjälp av PHP inbyggda säkerhetsfunktioner som gör det lättare för utvecklare att skydda webbplatsen.

PHP sägs vara den mest kraftfulla serversidan Språk, PHP använder 80 procent av världens webb, med topp 10 miljoner domäner. Av denna anledning är det att förstå att PHP hjälper dig att skydda mot angripare.

att säkra webbapplikationer från alla typer av smidda attackerande försök är den ultimata plikten för en webbutvecklare. Du bör bygga dina webbappar tillräckligt skyddande för att inte ha några säkerhetsproblem eller kryphål.

PHP är det mest använda webbprogrammeringsspråket på serversidan över hela världen. Olika PHP-applikationer delar olika delar av sin kod och skript med andra webbapplikationer. Om den delade koden hittas upptäckt sårbar, är alla applikationer som använder den delade koden utsatta och anses vara sårbara.

PHP är det mest kritiserade skriptspråket när det gäller säkerhet. En stor del av utvecklare och QA-experter tror att PHP inte har några robusta tekniker för att säkra applikationer. Domen har viss grund också eftersom PHP är det äldsta och mest använda språket för webbapputveckling. Men länge sedan PHP 5.6 har vi inte sett några större uppdateringar angående säkerhet och därmed står språket inför vissa säkerhetsproblem.

hur säker är PHP

PHP är lika säker som alla andra större språk. PHP är lika säkert som alla större språk på serversidan. Med de nya PHP-ramarna och verktygen som introducerats under de senaste åren är det nu enklare än någonsin att hantera förstklassig säkerhet.

om vi gör en jämförelse PHP är jämnt säkrad. Rails, Java, Javascript och andra språk har alla haft sina sårbarheter genom åren. ”Om du hittar ett språk som inte har haft en sårbarhet i någon form eller form kan du skriva säker kod i PHP helt bra.

säkerhetsproblem i PHP CMS

populära CMS som WordPress, Joomla, Magento och Drupal är byggda i PHP och enligt Sucuri kom de flesta sårbarheterna i PHP CMS fram under året 2017:

• WordPress säkerhetsfrågor ökade från 74% i 2016 Q3 till 83% i 2017.
• Joomla säkerhetsproblem har sjunkit från 17% i 2016 Q3 till 13.1% i 2017.
• Magento säkerhetsfrågor ökade marginellt från 6% i Q3 2016 till 6.5% i 2017.
• Drupal säkerhetsproblem sjönk något från 2% i Q3 2016 till 1.6% i 2017.

den nuvarande situationen är inte tillräckligt bra, men tack vare Open source bidragsgivare, som försöker hårt för att övervinna problemen och vi har sett några drastiska förändringar i PHP för sent. PHP 7.x lanserades förra året med olika uppdateringar och korrigeringar. Det bästa med PHP 7.x avser säkerhetsuppgraderingar som verkligen förnyade språkets säkerhetsprotokoll.

Vad innehåller denna PHP-Säkerhetshandledning?

jag har arbetat med PHP säkerhets-och prestandaproblem under en mycket lång tid, att vara mycket aktiv i PHP samhället frågar Topputvecklare om tips och tricks de använder i sina levande projekt. Därför är huvudsyftet med denna PHP-säkerhetshandledning att göra dig medveten om de bästa metoderna för säkerhet i PHP-webbapplikationer. Jag kommer att definiera följande problem och nämna möjliga lösningar för dem.

• uppdatera PHP regelbundet
• cross site scripting (XSS)
• SQL Injection Attacks
• Cross site request forgery xsrf/CSRF
• Session kapning
• dölj filer från webbläsaren
• säkert ladda upp filer
• Använd SSL-certifikat för HTTPS
• distribuera PHP-appar på moln

Obs: Vänligen betrakta det inte som ett komplett fuskblad. Det måste finnas bättre sätt och mer unika lösningar utvecklare skulle tillämpa på sina applikationer för att göra det perfekt säkrad.

PHP Security Best Practice

när du skapar en PHP-webbapplikation bör en webbingenjör vara oroad över bästa praxis för säkerhet. En osäker webbapplikation ger hackare chansen att ta värdefulla data, till exempel kundinformation eller kreditkortsuppgifter. Dessutom kan ett dataintrång ha en extrem effekt på organisationens giltighet och framtida verksamhet.

uppdatera PHP regelbundet

just nu är den mest stabila och senaste versionen av PHP tillgänglig PHP 8. Jag rekommenderar att du måste uppdatera din PHP-applikation till den här nya. Om du fortfarande använder PHP 5.6 eller 7 kommer du att ha många avskrivningar när du uppgraderar PHP-appar. Du kommer också att behöva uppdatera din kod och ändra vissa funktionella logiker som lösenord hashing etc. Det finns också några verktyg tillgängliga för att kontrollera avskrivningen av din kod och hjälpa dig att migrera dem. Jag har listat några verktyg nedan:

1. PHP Compatibility Checker
2. PHP MAR
3. Phan

om du använder PHPStorm kan du använda PHP 7 Compatibility Inspection, som visar vilken kod som kommer att orsaka problem.

Läs Mer: PHP Hosting på Cloudways

Cross-site scripting (XSS)

Cross site scripting är en typ av skadlig webbattack där ett externt skript injiceras i webbplatsens kod eller utdata. Angriparen kan skicka infekterad kod till slutanvändaren medan webbläsaren inte kan identifiera den som ett pålitligt skript. Denna attack sker oftast på de platser där användaren har möjlighet att mata in och skicka in data. Attacken kan komma åt cookies, sessioner och annan känslig information om webbläsaren. Låt oss titta på exemplet på en GET-begäran som skickar vissa data via URL:

URL: http://example.com/search.php?search=<script>alert('test')</script>$search = $_GET ?? null;echo 'Search results for '.$search;

du kan räkna ut denna attack genom att använda htmlspecialchars. Även genom att använda ENT_QUOTES, kan du fly enkla och dubbla citat.

$search = htmlspecialchars($search, ENT_QUOTES, 'UTF-8');echo 'Search results for '.$search;

under tiden kan XSS-attacker också köras via attribut, kodade URI-scheman och kodkodning.

Läs Mer: förhindra XSS i Laravel

SQL-injektionsattacker

SQL-injektionen är den vanligaste attacken i PHP-skript. En enda fråga kan äventyra hela applikationen. I SQL injection attack försöker angriparen ändra de data du skickar via frågor. Antag att du direkt behandlar användardata i SQL-frågor, och plötsligt använder en anonym angripare i hemlighet olika tecken för att kringgå den. Se nedanstående SQL-fråga:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';

användarnamnet $kan innehålla ändrade data som kan skada databasen, inklusive att ta bort hela databasen med ett ögonblick. Så, vad är lösningen? Sub. Jag rekommenderar att du alltid använder förberedda uttalanden. PDO hjälper dig att säkra SQL-frågor.

$id = $_GET ?? null;

anslutningen mellan databasen och applikationen görs med nedanstående uttalande:

$dbh = new PDO('mysql:dbname=testdb;host=127.0.0.1', 'dbusername', 'dbpassword');

du kan välja användarnamn baserat på ovanstående ID men vänta! Här injiceras SQL-koden ’GET data’ i din fråga. Var noga med att undvika sådan kodning och använd förberedda uttalanden istället:

$sql = "SELECT username, email FROM users WHERE id = ".$id." ;foreach ($dbh->query($sql) as $row) { printf ("%s (%s)\n", $row, $row);}

nu kan du undvika ovanstående SQL-injektionsmöjlighet genom att använda

$sql = "SELECT username, email FROM users WHERE id = :id";$sth = $dbh->prepare($sql, );$sth->execute();$users = $sth->fetchAll();

en bra praxis är också att använda ORM som doktrin eller vältalig, eftersom det finns minst möjlighet att injicera SQL-frågor i dem.

Läs Mer: Skydda PHP-webbplats från SQL-injektion

Cross site request forgery XSRF/CSRF

CSRF-attacken är helt annorlunda än XSS-attacker. I CSRF-attack kan slutanvändaren utföra oönskade åtgärder på de autentiserade webbplatserna och kan överföra skadliga kommandon till webbplatsen för att utföra oönskade åtgärder. CSRF kan inte läsa begäran data och mestadels riktar staten ändra begäran genom att skicka någon länk eller ändrade data i HTML-taggar. Det kan tvinga användaren att utföra Statliga ändringsförfrågningar som att överföra pengar, ändra sina e-postadresser etc. Låt oss se den här webbadressen där GET requests skickar pengar till ett annat konto:

GET http://bank.com/transfer.do?acct=TIM&amount=100 HTTP/1.1

nu om någon vill utnyttja webbapplikationen kommer han / hon att ändra webbadressen med namn och belopp så här

http://bank.com/transfer.do?acct=Sandy&amount=100000

nu kan denna webbadress skickas via e-post i valfri fil, bild etc och angriparen kan be dig ladda ner filen

eller klicka på bilden. Och så fort du gör det, du omedelbart sluta med att skicka enorma summa pengar du aldrig vet om.

Session Hijacking

Session hijacking är en viss typ av skadlig webbattack där angriparen i hemlighet stjäl användarens sessions-ID. Det sessions-ID skickas till servern där den associerade $_SESSION-arrayen validerar sin lagring i stacken och ger åtkomst till programmet. Session kapning är möjligt genom en XSS attack eller när någon får tillgång till mappen på en server där sessionsdata lagras.

för att förhindra session kapning alltid binda sessioner till din IP-adress till:

$IP = getenv ( "REMOTE_ADDR" );

titta på det när du arbetar med localhost eftersom det inte ger dig exakt IP men :::1 eller :::127 typvärden. Du bör ogiltigförklara (unset cookie, unset session storage, remove traces) session snabbt när en överträdelse inträffar och bör alltid försöka att inte avslöja ID under några omständigheter.

för cookies är det bästa sättet att aldrig använda serialisering av data som lagras i en cookie. Hackare kan enkelt manipulera cookies, vilket resulterar i att du lägger till variabler i ditt omfång. Ta bort cookies på ett säkert sätt så här:

setcookie ($name, "", 1);setcookie ($name, false);unset($_COOKIE);

den första raden i koden säkerställer att cookien går ut i webbläsaren, den andra raden visar det vanliga sättet att ta bort en cookie (så du kan inte lagra false i en cookie). Den tredje raden tar bort cookien från ditt skript.

Läs mer: Redis Server som en PHP-Sessionshanterare

dölj filer från webbläsaren

om du har använt MIKRORAMAR av PHP måste du ha sett den specifika katalogstrukturen som säkerställer placeringen av filer korrekt. Ramar gör det möjligt att ha olika filer som styrenheter, modeller, konfigurationsfil(.yaml) etc i den katalogen, men för det mesta behandlar webbläsaren inte alla filer, men de är tillgängliga att se i webbläsaren. För att lösa problemet måste du inte placera dina filer i rotkatalogen utan i en gemensam mapp så att de inte är tillgängliga hela tiden i webbläsaren. Titta på katalogstrukturen för Slim-ramverket nedan:

säkert Ladda upp filer

filuppladdning är en nödvändig del av alla användardata bearbetning ansökan. Men kom ihåg på vissa punkter, filer används också för XSS-attacker som jag redan har förklarat ovan i artikeln. Återgå till grunderna, använd alltid POST-förfrågan i formuläret och deklarera egenskapen enctype=”multipart/form-data” i <form> tagg. Validera sedan filtypen med finfo-klassen så här:

$finfo = new finfo(FILEINFO_MIME_TYPE);$fileContents = file_get_contents($_FILES);$mimeType = $finfo->buffer($fileContents);

utvecklare kan skapa sina egna anpassade och ultrasäkra filvalideringsregler, men vissa ramar som Laravel, Symfony och codeigniter har redan fördefinierade metoder för att validera filtyper.

Låt oss titta på ett annat exempel. HTML-formuläret ska vara så här:

<form method="post" enctype="multipart/form-data" action="upload.php"> File: <input type="file" name="pictures" multiple="true"> <input type="submit"></form>

och ladda upp.php innehåller följande kod:

foreach ($_FILES as $key => $error) { if ($error == UPLOAD_ERR_OK) { $tmpName = $_FILES; $name = basename($_FILES); move_uploaded_file($tmpName, "/var/www/project/uploads/$name"); }}

korrekt deklarering av UPLOAD_ERR och basename () kan förhindra katalogtraverseringsattacker, men få andra valideringar – som Filstorlek, filnamn och lagra uppladdade filer på privat plats – krävs också för att stärka säkerheten för applikationerna.

Läs mer: Bild och filuppladdning i PHP

Använd SSL-certifikat för HTTPS

alla moderna webbläsare som Google Chrome, Opera, Firefox och andra, rekommenderar att använda HTTPS-protokollet för webbapplikationer. HTTPs ger en säker och krypterad åtkomstkanal för otillförlitliga webbplatser. Du måste inkludera HTTPS genom att installera SSL-certifikat på din webbplats. Det stärker också dina webbapplikationer mot XSS-attacker och förhindrar hackare att läsa transporterade data med koder. Cloudways tillhandahåller gratis SSL-certifikat med ett klick som är giltiga i 90 dagar och du kan enkelt återkalla eller förnya dem med ett klick. Du kan följa guiderna för att ställa in SSL-certifikat i dina PHP -, WordPress -, Magento-och Drupal-applikationer.

distribuera PHP-appar på moln

Hosting är det sista och viktigaste steget för alla webbapplikationer, eftersom du alltid skapar projektet på lokala PHP-servrar och distribuerar dem på live-servrar som erbjuder antingen delad, moln eller dedikerad hosting. Jag rekommenderar alltid att använda molnhotell som DigitalOcean, Linode, AWS. De är snabba, säkra och säkra för alla typer av webbplatser och applikationer. De ger alltid säkrade lager för att förhindra DDoS, Brute force och phishing-attacker som är mycket skadliga för webbapplikationer.

du kanske också gillar: fallgropar av Laravel Shared Hosting för dina projekt

för att distribuera PHP-applikationer på molnservrar måste du ha goda Linux-färdigheter för att skapa kraftfulla webbstackar som LAMP eller LEMP, vilket ofta kostar dig tid och budget för Linux-proffs. Istället Cloudways managed PHP och MySQL hosting platform ger dig det enkla sättet att distribuera servrar med Thunderstack inom några klick på de ovan nämnda molnleverantörer. Thunderstack hjälper din PHP-applikation att vara helt säkrad från olika skadliga attacker och garanterar optimerad prestanda.

Läs mer: Enhanced Cloudways Staging Environment är nu tillgänglig för alla användare

Document Root Setup

dokumentroten för PHP-applikationer på vilken server som helst måste vara inställd på var/www/html så att användare kan komma åt din webbplats via webbläsaren. Men i vissa fall, när du utvecklar API: er med ramar som Laravel, Symfony och Slim, måste du uppdatera Webroot till `/public-mappen.

/public tjänar produktionen av ansökan liknar enkel PHP webbplats med index.php-fil. Syftet med att ställa in webroot till var/www/html / public är att dölja känsliga filer som .htaccess och .env som innehåller miljövariabler och referenser för Databas, post, betalnings API: er.

ramar som Laravel, Symfony rekommenderar att du inte flyttar alla dina filer till rotmappen, istället skapar du en fin katalogstruktur för att spara relaterade filer som view, models and controllers är ett mer rimligt tillvägagångssätt.

logga alla fel och Dölj i produktion

när du har utvecklat webbplatsen och distribuerat på live server. Det första du måste göra är att inaktivera visning av fel, eftersom hackare kan få samma värdefulla information från felen. Ställ in den här parametern i din php.ini file:

display_errors=Off

nu, efter att ha gjort visning av, logga PHP-fel till en specifik fil för framtida behov:

log_errors=Onerror_log=/var/log/httpd/php_scripts_error.log

självklart kan du ändra filnamn som du vill.

du kanske också gillar: förenkla Laravel felloggning med PHP Rollbar Integration

vitlista offentliga IP för Mysql

när du arbetar med PHP apps du ofta måste ställa mysql-databas i interna skript samt i mysql-klienter. De flesta klienter används för att ställa in MySQL fjärranslutning som behöver IP-adressen eller annat värdnamn som tillhandahålls av värdserver för att skapa anslutning.

den offentliga IP-adressen för fjärranslutningen av Mysql måste vara vitlistad i din värdserver så att en anonym användare inte kan få tillgång till databasen. Till exempel på Cloudways kan du vitlista IP som:

nu kan du ansluta SQLyog eller Mysql workbench att arbeta på distans med databasen.

Förpackning!

Tja, PHP-säkerhets bästa praxis är ett mycket stort ämne. Utvecklare från hela världen tenderar att utveckla olika användningsfall för att säkra webbappar. Medan många företag kör olika bounty-program för att ta reda på säkerhetsluckor och sårbarheter i sina applikationer och därmed belöna de säkerhetsexperter som påpekar kritiska kryphål i applikationerna. Den här artikeln täcker grundläggande PHP-säkerhetsproblem, för att hjälpa dig att förstå hur du skyddar dina PHP-projekt från olika skadliga attacker. Jag kommer också att skriva om några fler PHP – säkerhetstips och tricks i framtiden också. Till dess kan du bidra med dina tankar och säkerhetspraxis i kommentarfältet nedan.