Ultimate PHP Security Best Practices

Ultimate PHP Security Best Practices

SIDEN PHP er ryggraden for nesten alle nettsteder, BØR PHP-sikkerhet derfor ikke betraktes som ubetydelig for enhver pris. PHP-utviklere har imidlertid privilegiet å unngå vanlige trusler som forfalskning på tvers av nettsteder, SQL-injeksjoner og data-manipulering. OG alt dette kommer til nytte ved HJELP AV PHP innebygde sikkerhetsfunksjoner som gjør det enklere for utviklere å beskytte nettstedet.

PHP sies Å være det kraftigste server-sidespråket, PHP bruker 80 prosent av verdens web, med topp 10 millioner domener. AV denne grunn er det å forstå AT PHP vil hjelpe deg med å beskytte mot angripere.

Sikring av webapplikasjoner fra alle slags smidde angrepsforsøk er den ultimate plikten til en webutvikler. Du bør bygge din web apps beskyttende nok til å ha noen sikkerhetsproblemer eller smutthull.

PHP ER det mest brukte server-side web programmeringsspråket over hele verden. ULIKE PHP-programmer dele ulike deler av sin kode og skript med andre web-applikasjoner. Hvis det delte kodestykket blir funnet, oppdages sårbart, blir alle programmene som bruker den delte kodestykket, satt i fare og betraktet som sårbare.

PHP er det mest kritiserte skriptspråket når det gjelder sikkerhet. EN stor del av utviklere og QA eksperter tror PHP har ingen robuste teknikker for å sikre programmer. Dommen har noen grunn også FORDI PHP er den eldste og mye brukt språk for web app utvikling. MEN I LANG tid SIDEN PHP 5.6 har vi ikke sett noen store oppdateringer angående sikkerhet, og dermed står språket overfor noen sikkerhetsproblemer.

HVOR Sikker ER PHP

PHP er like sikker som alle andre store språk. PHP er like sikkert som alle store server-side språk. MED DE nye PHP-rammene og verktøyene som er introdusert de siste årene, er det nå enklere enn noensinne å administrere topp sikkerhet.

HVIS vi gjør en sammenligning PHP er jevnt sikret. Rails, Java, Javascript og andre språk, alle har hatt sine sårbarheter gjennom årene. «Hvis du finner et språk som ikke har hatt en sårbarhet av noen form eller form, kan du skrive sikker kode i PHP helt bra.

Sikkerhetsproblemer I PHP CMS

Populære CMS som WordPress, Joomla, Magento og Drupal er bygget I PHP og Ifølge Sucuri, de fleste av sårbarheter I PHP CMS kom frem i lyset i løpet av året 2017:

• WordPress sikkerhetsproblemer steg fra 74% I 2016 Q3 til 83% i 2017.
• joomla sikkerhetsproblemer har falt fra 17% I 2016 Q3 til 13.1% i 2017.
• Magento sikkerhetsproblemer steg marginalt fra 6% I Q3 2016 til 6.5% i 2017.
• Drupal sikkerhetsproblemer falt litt fra 2% I Q3 2016 til 1.6% i 2017.

den nåværende situasjonen er ikke god nok, men takket være åpen kildekode bidragsytere, som prøver hardt å overvinne problemene, og vi har sett noen drastiske endringer I PHP i det siste. PHP 7.x ble lansert i fjor med ulike oppdateringer og reparasjoner. DET beste MED PHP 7.x gjelder sikkerhet upgradations som virkelig fornyet sikkerhetsprotokoll av språket.

Hva DENNE PHP Sikkerhet Opplæringen Inneholder?

jeg har jobbet med PHP-sikkerhets-og ytelsesproblemer i svært lang tid, og er svært aktiv i PHP-fellesskapet, og spør topputviklere om tips og triks de bruker i sine live-prosjekter. Derfor er hovedformålet MED DENNE PHP – sikkerhetsopplæringen å gjøre deg oppmerksom på de beste praksisene for sikkerhet i PHP webapplikasjoner. Jeg vil definere følgende problemer og nevne mulige løsninger for dem.

• Oppdater PHP Regelmessig
• Cross site scripting (XSS)
• SQL-Injeksjon Angrep
• cross site forespørsel forfalskning XSRF/CSRF
• Økt Kapring
• Skjul Filer Fra Nettleseren
• Sikkert last opp filer
• bruk ssl-sertifikater FOR Https
• Distribuer Php-Apper på skyer

Merk: Vennligst Ikke Betrakt Det Som En Komplett Jukselapp. Det må være bedre måter, og flere unike løsninger utviklere vil søke på deres applikasjoner for å gjøre det perfekt sikret.

BESTE PRAKSIS FOR PHP-Sikkerhet

når DU oppretter ET PHP-webprogram, bør en webingeniør være opptatt av beste praksis for sikkerhet. En usikker webapplikasjon gir hackere muligheten til å ta verdifulle data, for eksempel klientinformasjon eller kredittkortdetaljer. I tillegg kan et datainnbrudd ha en ekstrem effekt på organisasjonens gyldighet og fremtidige operasjoner.

Oppdater PHP Regelmessig

AKKURAT nå ER DEN mest stabile og nyeste versjonen AV PHP TILGJENGELIG PHP 8. Jeg anbefaler at DU må oppdatere PHP-programmet til denne nye. Hvis DU fortsatt bruker PHP 5.6 eller 7, vil du ha mange avskrivninger mens du oppgraderer PHP-apper. Du må også oppdatere koden din og endre noen funksjonelle logikker som passord hashing etc. Det er også noen verktøy tilgjengelig for å sjekke avskrivningen av koden din og hjelpe deg med å migrere dem. Jeg har listet opp noen verktøy nedenfor:

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

HVIS Du bruker PHPStorm, kan DU bruke PHP 7 Compatibility Inspection, som vil vise deg hvilken kode som vil føre til problemer.

Les Mer: PHP Hosting På Cloudways

Cross-site scripting (XSS)

Cross site scripting er en type ondsinnet web angrep der et eksternt skript injiseres i nettstedets kode eller utgang. Angriperen kan sende infisert kode til sluttbrukeren, mens nettleseren ikke kan identifisere den som et klarert skript. Dette angrepet skjer hovedsakelig på de stedene hvor brukeren har muligheten til å legge inn og sende inn data. Angrepet kan få tilgang til informasjonskapsler, økter og annen sensitiv informasjon om nettleseren. La oss se på eksemplet PÅ EN GET-forespørsel som sender noen data VIA URL:

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

du kan finne ut dette angrepet ved å bruke htmlspecialchars. Også ved å bruke ENT_QUOTES, kan du unnslippe enkle og doble anførselstegn.

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

I Mellomtiden KAN XSS-angrep også utføres via attributter, kodede URI-ordninger og kodekoding.

Les Mer: Forhindre XSS I Laravel

SQL-Injeksjonsangrep

SQL-injeksjonen er det vanligste angrepet i PHP-skripting. En enkelt spørring kan kompromittere hele programmet. I SQL injection attack forsøker angriperen å endre dataene du passerer via spørringer. Anta at du behandler brukerdata direkte i SQL-spørringer, og plutselig bruker en anonym angriper i hemmelighet forskjellige tegn for å omgå det. Se DEN NEDENFOR nevnte SQL-spørringen:

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

$brukernavn kan inneholde endrede data som kan skade databasen inkludert slette hele databasen i blinking av øye. Så, hva er løsningen? PUD. Jeg anbefaler at du alltid bruker forberedte uttalelser. PDO hjelper deg med å sikre SQL-spørringer.

$id = $_GET ?? null;

forbindelsen mellom databasen og applikasjonen er laget med under setningen:

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

du kan velge brukernavn basert på OVENNEVNTE ID, men vent! HER BLIR SQL-koden ‘GET data’ injisert i søket ditt. Vær forsiktig med å unngå slik koding og bruk forberedte uttalelser i stedet:

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

Nå kan du unngå OVENNEVNTE SQL-injeksjonsmulighet ved å bruke

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

en god praksis er også Å bruke ORM som doktrin eller veltalende, da det er minst mulighet for å injisere SQL-spørringer i dem.

Les Mer: Beskytt PHP Nettsted FRA SQL Injection

cross site request forfalskning XSRF/CSRF

CSRF-angrepet er ganske annerledes ENN XSS-angrep. I csrf-angrep kan sluttbrukeren utføre uønskede handlinger på de godkjente nettstedene og kan overføre ondsinnede kommandoer til nettstedet for å utføre uønsket handling. CSRF kan ikke lese forespørselsdataene og retter seg hovedsakelig mot statens endringsforespørsel ved å sende en lenke eller endrede data i HTML-koder. Det kan tvinge brukeren til å utføre statlige endringsforespørsler som å overføre midler, endre e-postadresser etc. La oss se DENNE NETTADRESSEN DER GET requests sender penger til en annen konto:

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

Nå hvis noen ønsker å utnytte webapplikasjonen, vil han/hun endre NETTADRESSEN med navn og beløp som dette

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

nå KAN DENNE NETTADRESSEN sendes via e-post i en hvilken som helst fil, Bilde etc, og angriperen kan be deg om å laste ned filen

eller klikk på bildet. Og så snart du gjør det, du umiddelbart ende opp med å sende stor sum penger du aldri vet om.

Øktkapring

øktkapring er en bestemt type ondsinnet nettangrep der angriperen i hemmelighet stjeler økt-IDEN til brukeren. Denne økt-ID-en sendes til serveren der den tilknyttede $_SESSION-matrisen validerer lagringen i stakken og gir tilgang til programmet. Øktkapring er mulig gjennom ET xss-angrep eller når noen får tilgang til mappen på en server der øktdataene er lagret.

for å forhindre øktkapring, bind alltid økter til DIN IP-adresse til:

$IP = getenv ( "REMOTE_ADDR" );

Se etter det når du arbeider på localhost som det ikke gir deg den eksakte IP men :::1 eller::: 127 type verdier. Du bør ugyldiggjøre (unset cookie, unset session storage, remove traces) session raskt når et brudd oppstår, og bør alltid prøve å ikke utsette Ider under noen omstendigheter.

for informasjonskapsler er det best å aldri bruke serialiseringsdata lagret i en informasjonskapsel. Hackere kan enkelt manipulere informasjonskapsler, noe som resulterer i å legge til variabler i ditt omfang. Trygt slette cookies som dette:

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

den første linjen i koden sikrer at informasjonskapselen utløper i nettleseren, den andre linjen viser den vanlige måten å fjerne en informasjonskapsel på(dermed kan du ikke lagre falsk i en informasjonskapsel). Den tredje linjen fjerner informasjonskapselen fra skriptet ditt.

Les mer: Redis Server Som PHP – Øktbehandler

Skjul Filer Fra Nettleseren

hvis DU har brukt mikrorammer AV PHP, må du ha sett den spesifikke katalogstrukturen som sikrer plassering av filer riktig. Rammer tillater å ha forskjellige filer som kontrollere, modeller, konfigurasjonsfil (.i den katalogen, men mesteparten av tiden behandler nettleseren ikke alle filene, men de er tilgjengelige for å se i nettleseren. For å løse dette problemet må du ikke plassere filene i rotmappen, men i en fellesmappe slik at de ikke er tilgjengelige hele tiden i nettleseren. Se på katalogstrukturen Til Slim framework nedenfor:

Sikkert Laste Opp Filer

filopplasting er en nødvendig del av enhver brukerdatabehandlingsprogram. Men husk på noen punkter, filer brukes også TIL XSS-angrep som jeg allerede har forklart ovenfor i artikkelen. Gå tilbake til det grunnleggende, bruk ALLTID POST-forespørselen i skjemaet og deklarere egenskapen enctype= «multipart / form-data» i <skjema > taggen. Deretter validere filtypen ved hjelp finfo klasse som dette:

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

Utviklere kan lage sine egne tilpassede og ultra-sikre filvalideringsregler, men noen rammer som Laravel, Symfony og codeigniter har allerede forhåndsdefinerte metoder for å validere filtyper.

La oss se på et annet eksempel. HTML-skjemaet skal være slik:

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

og last opp.php inneholder følgende kode:

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

Riktig deklarering AV UPLOAD_ERR og basename() kan forhindre katalogoverfarsangrep, men få andre valideringer – som filstørrelse, filnavn og lagre opplastede filer på privat sted – er også nødvendig for å styrke sikkerheten til applikasjonene.

Les mer: Bilde-Og Filopplasting I PHP

Bruk SSL-Sertifikater for HTTPS

alle moderne nettlesere som Google Chrome, Opera, Firefox og andre, anbefaler Å bruke HTTPS-protokoll for webapplikasjoner. HTTPs gir en sikret og kryptert tilgangskanal for usikre nettsteder. DU må inkludere HTTPS ved å installere SSL-sertifikat på nettstedet ditt. Det styrker også dine webapplikasjoner mot XSS-angrep og forhindrer hackere å lese transporterte data ved hjelp av koder. Cloudways tilbyr GRATIS SSL-sertifikater med ett klikk som er gyldige i 90 dager, og du kan enkelt tilbakekalle eller fornye DEM med et klikk. Du kan følge veiledningene for å sette OPP SSL-Sertifikater i PHP, WordPress, Magento og Drupal applikasjoner.

Distribuer PHP-Apper På Skyer

Hosting er det siste og viktigste trinnet for alle webapplikasjoner, da du alltid lager prosjektet på lokale PHP-servere og distribuerer dem på live-servere som tilbyr enten delt, sky eller dedikert hosting. Jeg anbefaler alltid å bruke cloud hosting Som DigitalOcean, Linode, AWS. De er raske, trygge og sikre for enhver form for nettside og applikasjon. De gir alltid sikret lag for å forhindre DDOS, Brute force og phishing-angrep som er svært skadelige for webapplikasjoner.

Du Vil Kanskje Også Like: Fallgruver Laravel Delt Hosting For Prosjektene Dine

for å distribuere PHP-applikasjoner på skyservere må du ha gode Linux-ferdigheter for å lage kraftige webstabler som LAMP eller LEMP, som ofte koster deg tid og budsjett for Linux-fagfolk. I stedet Gir Cloudways managed PHP og MySQL hosting platform deg den enkle måten å distribuere servere med Thunderstack innen få klikk på de ovennevnte skyleverandørene. Thunderstack hjelper PHP-programmet til å være helt sikret mot ulike ondsinnede angrep og garanterer optimalisert ytelse.

Les mer: Forbedret Cloudways Staging Miljø er Nå Tilgjengelig For Alle Brukere

Document Root Setup

dokumentroten for PHP-applikasjoner på en hvilken som helst server må være satt til var / www / html slik at brukerne kan få tilgang til nettstedet ditt via nettleseren. Men i noen tilfeller, når du utvikler Apier med rammer som Laravel, Symfony og Slim, må du oppdatere webroot til ‘ / public folder.

/offentlig serverer produksjonen av programmet ligner på enkel PHP nettsted med indeks.php-fil. Formålet med å sette webroot til var / www / html / public er å skjule de sensitive filene som .htaccess og .env som inneholder miljøvariabler og legitimasjon av database, post, betaling Apier.

også rammer som Laravel, Symfony anbefaler å ikke flytte alle filene dine til rotmappen, i stedet for å lage en fin katalogstruktur for å lagre relaterte filer som vis, modeller og kontrollere er en mer fornuftig tilnærming.

Logg alle Feil Og Skjul I Produksjon

Når du har utviklet nettstedet og distribuert på live server. Det første du må gjøre er å deaktivere visning av feil, fordi hackere kan få samme verdifull informasjon fra feilene. Sett denne parameteren i php.ini fil:

display_errors=Off

nå, etter å ha slått av, logg PHP-feil til en bestemt fil for fremtidige behov:

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

Åpenbart kan du endre filnavn som du vil.

Du Kan Også Like: Forenkle Laravel Feillogging MED PHP Rollbar Integrasjon

Hviteliste Offentlig IP For Mysql

når du arbeider med PHP-apper, må du ofte sette opp mysql-databasen i interne skript og i mysql-klienter. De fleste klienter brukes til å sette Opp MySQL ekstern tilkobling som trenger IP-adressen eller andre vertsnavn gi av hosting server for å opprette tilkobling.

den offentlige IP-EN for den eksterne Mysql-tilkoblingen må være hvitelistet i vertsserveren din slik at en anonym bruker ikke kan få tilgang til databasen. For eksempel, På Cloudways kan DU hviteliste IP som:

Nå kan Du koble SQLyog Eller Mysql workbench å jobbe eksternt med database.

Innpakning Opp!

VEL, PHP sikkerhet beste praksis er et veldig stort tema. Utviklere fra hele verden har en tendens til å utvikle ulike brukstilfeller for å sikre webapper. Mens mange selskaper kjører ulike skuddpremie programmer for å finne ut sikkerhet smutthull og sårbarheter i sine applikasjoner og dermed belønne de sikkerhetseksperter som peker ut kritiske smutthull i programmene. Denne artikkelen dekker grunnleggende PHP – sikkerhetsproblemer, for å hjelpe deg med å forstå hvordan DU sikrer PHP-prosjekter fra forskjellige ondsinnede angrep. Jeg vil også skrive om noen FLERE PHP sikkerhetstips og triks i fremtiden også. Inntil da kan du bidra med dine tanker og sikkerhetspraksis i kommentarfeltet nedenfor.