Ultimate PHP Security Best Practice

Ultimate PHP Security Best Practice

Poiché PHP è la spina dorsale di quasi tutti i siti web, quindi, la sicurezza PHP non dovrebbe essere considerata trascurabile ad ogni costo. Tuttavia, gli sviluppatori PHP hanno il privilegio di evitare minacce comuni come la contraffazione di richieste cross-site, le iniezioni SQL e la manomissione dei dati. E tutto questo è utile con l’aiuto di funzionalità di sicurezza integrate in PHP che rendono più facile per gli sviluppatori proteggere il sito web.

PHP si dice che sia il linguaggio server-side più potente, PHP utilizza 80 per cento del web del mondo, con top 10 milioni di domini. Per questo motivo stesso, è capire che PHP ti aiuterà a proteggerti dagli aggressori.

Proteggere le applicazioni web da ogni sorta di tentativi di attacco contraffatti è il dovere ultimo di uno sviluppatore web. Dovresti creare le tue app web abbastanza protettive da non avere problemi di sicurezza o scappatoie.

PHP è il linguaggio di programmazione web lato server più utilizzato in tutto il mondo. Diverse applicazioni PHP condividono diverse parti del loro codice e script con altre applicazioni web. Nel caso in cui il pezzo di codice condiviso venga rilevato vulnerabile, Tutte le applicazioni che utilizzano quel pezzo di codice condiviso vengono messe a rischio e considerate vulnerabili.

PHP è il linguaggio di scripting più criticato quando si tratta di sicurezza. Una parte importante di sviluppatori ed esperti di QA pensa che PHP non abbia tecniche robuste per proteggere le applicazioni. Anche il verdetto ha qualche fondamento perché PHP è il linguaggio più antico e ampiamente utilizzato per lo sviluppo di app web. Ma per molto tempo da PHP 5.6, non abbiamo visto aggiornamenti importanti per quanto riguarda la sicurezza e quindi la lingua deve affrontare alcuni problemi di sicurezza.

Quanto è sicuro PHP

PHP è sicuro come qualsiasi altro linguaggio principale. PHP è sicuro come qualsiasi altro importante linguaggio lato server. Con i nuovi framework e strumenti PHP introdotti negli ultimi anni, ora è più facile che mai gestire la sicurezza di prim’ordine.

Se facciamo un confronto PHP è uniformemente protetto. Rails, Java, Javascript, e altri linguaggi, tutti hanno avuto le loro vulnerabilità nel corso degli anni. “Se trovi un linguaggio che non ha avuto una vulnerabilità di qualche forma o forma, Puoi scrivere codice sicuro in PHP perfettamente bene.

Problemi di Sicurezza in PHP CMS

famosi CMS come WordPress, Joomla, Magento e Drupal sono realizzati in PHP e secondo Sucuri, la maggior parte delle vulnerabilità in PHP CMS è venuto alla luce durante l’anno 2017:

• WordPress problemi di sicurezza rose dal 74% nel 2016 Q3 a 83% nel 2017.
• Problemi di sicurezza Joomla sono scesi dal 17% nel 2016 Q3 al 13,1% nel 2017.
• I problemi di sicurezza di Magento sono aumentati marginalmente da 6% in Q3 2016 a 6.5% in 2017.
• I problemi di sicurezza Drupal sono leggermente diminuiti da 2% in Q3 2016 a 1.6% in 2017.

La situazione attuale non è abbastanza buono, ma grazie all’open source collaboratori, che stanno cercando di superare i problemi e abbiamo visto alcuni cambiamenti drastici in PHP di ritardo. PHP 7.x è stato lanciato l’anno scorso con vari aggiornamenti e correzioni. La cosa migliore di PHP 7.x si riferisce agli aggiornamenti di sicurezza che hanno veramente rinnovato il protocollo di sicurezza della lingua.

Cosa contiene questo tutorial sulla sicurezza PHP?

Ho lavorato su problemi di sicurezza e prestazioni PHP per un tempo molto lungo, essendo molto attivo nella comunità PHP chiedendo ai migliori sviluppatori i suggerimenti e i trucchi che stanno usando nei loro progetti live. Pertanto, l’obiettivo principale di questo tutorial sulla sicurezza PHP è quello di renderti consapevole delle migliori pratiche per la sicurezza nelle applicazioni Web PHP. Definirò i seguenti problemi e menzionerò possibili soluzioni per loro.

• Aggiornamento di PHP Regolarmente
• Cross site scripting (XSS)
• Attacchi di tipo SQL Injection
• Cross site request forgery XSRF/CSRF
• il Dirottamento di Sessione
• Nascondi i File dal Browser
• Caricare in modo Sicuro i File
• Utilizzare i Certificati SSL, HTTPs
• Deploy di Applicazioni PHP su Nuvole

Nota: si prega di non considerare come un completo cheat sheet. Ci devono essere modi migliori e gli sviluppatori di soluzioni più uniche si applicherebbero alle loro applicazioni per renderlo perfettamente protetto.

PHP Security Best Practice

Durante la creazione di un’applicazione Web PHP, un web engineer dovrebbe occuparsi delle best practice di sicurezza. Un’applicazione Web non sicura offre agli hacker la possibilità di acquisire dati preziosi, come le informazioni del cliente o i dettagli della carta di credito. Inoltre, una violazione dei dati può avere un effetto estremo sulla validità dell’organizzazione e sulle operazioni future.

Aggiorna PHP regolarmente

In questo momento, la versione più stabile e più recente di PHP disponibile è PHP 8. Ti consiglio di aggiornare la tua applicazione PHP a questa nuova. Se stai ancora usando PHP 5.6 o 7, avrai molte deprecazioni durante l’aggiornamento delle app PHP. Dovrai anche aggiornare il tuo codice e modificare alcune logiche funzionali come l’hash della password, ecc. Ci sono anche alcuni strumenti disponibili per controllare la deprecazione del tuo codice e aiutarti nella migrazione di quelli. Ho elencato alcuni strumenti di seguito:

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

Se stai usando PHPStorm, puoi usare PHP 7 Compatibility Inspection, che ti mostrerà quale codice ti causerà problemi.

Per saperne di più: PHP Hosting on Cloudways

Cross-site scripting (XSS)

Cross site scripting è un tipo di attacco web dannoso in cui uno script esterno viene iniettato nel codice del sito web o in uscita. L’utente malintenzionato può inviare codice infetto all’utente finale mentre il browser non può identificarlo come uno script attendibile. Questo attacco si verifica principalmente nei luoghi in cui l’utente ha la possibilità di inserire e inviare dati. L’attacco può accedere a cookie, sessioni e altre informazioni sensibili sul browser. Diamo un’occhiata all’esempio di una richiesta GET che sta inviando alcuni dati tramite URL:

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

Puoi capire questo attacco usando htmlspecialchars. Anche usando ENT_QUOTES, puoi sfuggire alle virgolette singole e doppie.

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

Nel frattempo, gli attacchi XSS possono anche essere eseguiti tramite attributi, schemi URI codificati e codifica del codice.

Per saperne di più: Prevenire XSS in Laravel

Attacchi SQL Injection

L’SQL injection è l’attacco più comune nello scripting PHP. Una singola query può compromettere l’intera applicazione. In attacco SQL injection, l’utente malintenzionato tenta di modificare i dati che si stanno passando tramite query. Supponiamo che tu stia elaborando direttamente i dati degli utenti nelle query SQL e improvvisamente, un utente malintenzionato anonimo utilizza segretamente caratteri diversi per ignorarlo. Vedere la query SQL di seguito menzionata:

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

Il nome utente $può contenere dati alterati che possono danneggiare il database, inclusa l’eliminazione dell’intero database in un batter d’occhio. Allora, qual è la soluzione? DOP. Vi consiglio di utilizzare sempre dichiarazioni preparate. PDO ti aiuta a proteggere le query SQL.

$id = $_GET ?? null;

La connessione tra il database e l’applicazione viene effettuata con la seguente istruzione:

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

Puoi selezionare il nome utente in base all’ID sopra, ma aspetta! Qui il codice SQL ‘GET data’ viene iniettato nella query. Fare attenzione ad evitare tale codifica e utilizzare invece istruzioni preparate:

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

Ora puoi evitare la precedente possibilità di SQL injection usando

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

Inoltre, una buona pratica è usare ORM come doctrine o eloquent, in quanto vi è la minima possibilità di iniettare query SQL in esse.

Per saperne di più: Proteggi il sito Web PHP da SQL Injection

Cross site request forgery XSRF/CSRF

L’attacco CSRF è molto diverso dagli attacchi XSS. In CSRF attack, l’utente finale può eseguire azioni indesiderate sui siti Web autenticati e può trasferire comandi dannosi al sito per eseguire qualsiasi azione indesiderata. CSRF non può leggere i dati della richiesta e si rivolge principalmente alla richiesta di modifica dello stato inviando alcun collegamento o dati alterati nei tag HTML. Può costringere l’utente a eseguire richieste di modifica dello stato come il trasferimento di fondi, la modifica dei propri indirizzi e-mail, ecc. Vediamo questo URL in cui GET requests sta inviando denaro a un altro account:

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

Ora se qualcuno vuole sfruttare l’applicazione web cambierà l’URL con nome e importo come questo

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

Ora questo URL può essere inviato via e-mail in qualsiasi file, Immagine ecc. E non appena lo fai, finisci immediatamente con l’invio di enormi quantità di denaro che non sai mai.

Session Hijacking

Session hijacking è un particolare tipo di attacco web dannoso in cui l’utente malintenzionato ruba segretamente l’ID di sessione dell’utente. Tale ID di sessione viene inviato al server in cui l’array associated _SESSION associato convalida la sua archiviazione nello stack e concede l’accesso all’applicazione. Il dirottamento della sessione è possibile attraverso un attacco XSS o quando qualcuno ottiene l’accesso alla cartella su un server in cui sono memorizzati i dati della sessione.

Per impedire il dirottamento della sessione, associa sempre le sessioni al tuo indirizzo IP a:

$IP = getenv ( "REMOTE_ADDR" );

Guardalo quando lavori su localhost poiché non ti fornisce l’IP esatto ma i valori di tipo :::1 o :::127. Si dovrebbe invalidare (unset cookie, unset session storage, remove traces) sessione rapidamente ogni volta che si verifica una violazione e dovrebbe sempre cercare di non esporre gli ID in nessun caso.

per i cookie, la migliore pratica è non utilizzare mai i dati serializzati memorizzati in un cookie. Gli hacker possono manipolare facilmente i cookie, con conseguente aggiunta di variabili al tuo ambito. Elimina in modo sicuro i cookie come questo:

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

La prima riga del codice assicura che il cookie scada nel browser, la seconda riga descrive il modo standard di rimuovere un cookie (quindi non è possibile memorizzare false in un cookie). La terza riga rimuove il cookie dal tuo script.

Leggi di più: Redis Server Come gestore di sessioni PHP

Nascondi file dal browser

Se hai usato micro-framework di PHP, devi aver visto la struttura di directory specifica che garantisce il posizionamento dei file correttamente. I framework consentono di avere file diversi come controller, modelli, file di configurazione (.yaml) ecc in quella directory, ma il più delle volte il browser non elabora tutti i file, ma sono disponibili per vedere nel browser. Per risolvere questo problema, non è necessario inserire i file nella directory principale, ma in una cartella pubblica in modo che non siano accessibili tutto il tempo nel browser. Guarda la struttura delle directory del framework Slim qui sotto:

Caricare in modo sicuro i file

Il caricamento dei file è una parte necessaria di qualsiasi applicazione di elaborazione dei dati degli utenti. Ma ricorda in alcuni punti, i file vengono utilizzati anche per gli attacchi XSS come ho già spiegato sopra nell’articolo. Tornando alle nozioni di base, utilizzare sempre la richiesta POST nel modulo e dichiarare la proprietà enctype = “multipart/form-data” nel tag <form>. Quindi convalidare il tipo di file utilizzando la classe finfo come questa:

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

Gli sviluppatori possono creare le proprie regole di convalida dei file personalizzate e ultra-sicure, ma alcuni framework come Laravel, Symfony e codeigniter hanno già metodi predefiniti per convalidare i tipi di file.

Diamo un’occhiata a un altro esempio. L’HTML di formulario dovrebbe essere come questo:

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

E carica.php contiene il seguente codice:

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

Dichiarare correttamente UPLOAD_ERR e basename () può impedire attacchi di attraversamento della directory, ma poche altre convalide, come la dimensione del file, la rinomina del file e l’archiviazione dei file caricati in posizione privata, sono necessarie anche per rafforzare la sicurezza delle applicazioni.

Per saperne di più: Caricamento di immagini e file in PHP

Utilizzare certificati SSL per HTTPS

Tutti i browser moderni come Google Chrome, Opera, Firefox e altri, consiglia di utilizzare il protocollo HTTPS per le applicazioni web. HTTPs fornisce un canale di accesso sicuro e crittografato per i siti non attendibili. Devi includere HTTPS installando il certificato SSL nel tuo sito web. Rafforza anche le applicazioni web contro gli attacchi XSS e impedisce agli hacker di leggere i dati trasportati utilizzando i codici. Cloudways fornisce certificati SSL gratuiti con un solo clic validi per 90 giorni e puoi facilmente revocarli o rinnovarli con un clic. Puoi seguire le guide per l’impostazione dei certificati SSL nelle tue applicazioni PHP, WordPress, Magento e Drupal.

Deploy PHP Apps on Clouds

Hosting è il passo finale e fondamentale per qualsiasi applicazione web, come si crea sempre il progetto su server PHP locali e distribuirli su server live che offrono sia condiviso, cloud o hosting dedicato. Consiglio sempre di utilizzare il cloud hosting come DigitalOcean, Linode, AWS. Sono veloci, sicuri e protetti per qualsiasi tipo di sito web e applicazione. Forniscono sempre un livello protetto per prevenire attacchi DDOS, forza bruta e phishing che sono altamente dannosi per le applicazioni Web.

Potrebbe interessarti anche: Insidie di Laravel Shared Hosting per i tuoi progetti

Per distribuire applicazioni PHP su server cloud, devi avere buone capacità Linux per creare potenti stack web come LAMP o LEMP, che spesso ti costa tempo e budget per i professionisti Linux. Invece, Cloudways gestito PHP e MySQL piattaforma di hosting fornisce il modo più semplice per distribuire i server con Thunderstack in pochi clic sui fornitori di cloud di cui sopra. Thunderstack aiuta la tua applicazione PHP ad essere completamente protetta da vari attacchi dannosi e garantisce prestazioni ottimizzate.

Per saperne di più: Enhanced Cloudways Staging Environment è ora disponibile per tutti gli utenti

Document Root Setup

La document root per le applicazioni PHP su qualsiasi server deve essere impostata su var/www/html in modo che gli utenti possano accedere al tuo sito web tramite il browser. Ma in alcuni casi, quando si sviluppano API con framework come Laravel, Symfony e Slim, è necessario aggiornare il webroot alla cartella `/public.

/public serve l’output di un’applicazione simile al semplice sito web PHP con indice.file php. Lo scopo per impostare il webroot su var / www / html / public è quello di nascondere i file sensibili come .htaccess e .env che contengono le variabili di ambiente e le credenziali di database, mail, API di pagamento.

Inoltre, framework come Laravel, Symfony raccomandano di non spostare tutti i file nella cartella principale, invece creare una bella struttura di directory per salvare file correlati come view, models e controller è un approccio più ragionevole.

Registra tutti gli errori e nascondi in Produzione

Una volta sviluppato il sito Web e distribuito sul server live. La prima cosa che devi fare è disabilitare la visualizzazione degli errori, perché gli hacker potrebbero ottenere le stesse preziose informazioni dagli errori. Imposta questo parametro nel tuo php.file ini:

display_errors=Off

Ora, dopo aver disattivato la visualizzazione, registra gli errori PHP in un file specifico per esigenze future:

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

Ovviamente, è possibile modificare il nome del file come si desidera.

Potrebbe interessarti anche: Semplificare la registrazione degli errori Laravel con integrazione Rollbar PHP

Whitelist IP pubblico per Mysql

Quando si lavora con le app PHP è spesso necessario configurare il database mysql negli script interni e nei client mysql. La maggior parte dei client viene utilizzata per impostare la connessione remota MySQL che richiede l’indirizzo IP o un altro nome host fornito dal server di hosting per creare la connessione.

L’IP pubblico per la connessione Mysql remota deve essere inserito nella whitelist nel server di hosting in modo che un utente anonimo non possa accedere al database. Ad esempio, su Cloudways puoi whitelist IP come:

Ora è possibile collegare SQLyog o Mysql workbench per lavorare in remoto con il database.

Sto finendo!

Bene, le best practice di sicurezza PHP sono un argomento molto vasto. Gli sviluppatori di tutto il mondo tendono a sviluppare diversi casi d’uso per proteggere le app web. Mentre molte aziende gestiscono diversi programmi di taglie per scoprire scappatoie di sicurezza e vulnerabilità nelle loro applicazioni e quindi premiare quegli esperti di sicurezza che sottolineano scappatoie critiche nelle applicazioni. Questo articolo copre problemi di sicurezza PHP di base, per aiutarti a capire come proteggere i tuoi progetti PHP da diversi attacchi dannosi. Scriverò anche su alcuni altri suggerimenti e trucchi per la sicurezza PHP in futuro. Fino ad allora si può contribuire i vostri pensieri e le pratiche di sicurezza nella sezione commenti qui sotto.