Hosting condiviso È l'opzione economica, no? E per un'enorme quantità di popolazione, è tutto ciò di cui avranno bisogno per ospitare il loro sito Web o la loro applicazione web. E quando fatto bene, l'hosting condiviso è scalabile, veloce e sicuro.
Ma cosa succede quando non è fatto bene?
Bene, è qui che iniziano a insinuarsi pericolosi problemi di sicurezza. Questo è quando il tuo sito è a rischio di essere deturpato, o i dati privati che tieni trapelato. Ma non preoccuparti. La stragrande maggioranza degli host web ha misure di sicurezza decenti. È solo la notte delle notti in cui i padroni di casa delle occasioni speciali devono essere cauti.
Esploreremo i problemi di sicurezza relativi all'hosting condiviso. Ma prima, parliamo di cosa rende sicura una piattaforma di hosting condivisa.
Cosa rende un host Web sicuro
Ci sono alcune considerazioni sulla sicurezza che dovrebbero essere fatte per quanto riguarda l'hosting condiviso.
- Ogni utente sul server dovrebbe essere isolato dagli altri utenti e non dovrebbe essere in grado di accedere o modificare i file di altri utenti.
- Una vulnerabilità di sicurezza nella logica di un sito Web ospitato sul server non dovrebbe essere in grado di influenzare altri utenti.
- Il server viene regolarmente aggiornato, aggiornato e monitorato per risolvere problemi di sicurezza architettonica.
- Ogni utente dovrebbe avere il proprio accesso al database, e non dovrebbe essere permesso di apportare modifiche ai record memorizzati o alle autorizzazioni della tabella di altri utenti.
Ancora una volta, la maggior parte degli host web soddisfa questi requisiti per le loro offerte condivise. Ma se stai cercando di ospitare più siti web su un server, o se sei curioso di vedere come si accumula la tua società di hosting, o addirittura di pensare di lanciare la tua società di hosting e sei desideroso di capire come proteggere i tuoi utenti, leggi per favore sopra.
Ma in primo luogo, un disclaimer
Prima di addentrarci nell'analisi degli attacchi comuni a livello di hosting condiviso, voglio solo precisare che questo post non sarà (e non dovrebbe essere letto) un elenco esauriente di potenziali problemi di sicurezza.
La sicurezza è, in una parola, grande. Ci sono molti modi in cui puoi compromettere un sito. Questo è il doppio per l'hosting condiviso. Coprirli in un singolo articolo non è mai stato sulle carte.
Se sei paranoico riguardo alla tua sicurezza, prendi un VPS o un server dedicato. Questi sono gli ambienti in cui hai (per la maggior parte) il controllo assoluto su ciò che accade. Se non sei sicuro dei diversi tipi di hosting web, dai un'occhiata a questo post Le varie forme di hosting di siti web spiegate [La tecnologia ha spiegato] Le varie forme di hosting di siti web spiegate [Tecnologia spiegata] Leggi altro dal mio collega James Bruce.
Vorrei anche sottolineare che questo post non deve essere interpretato come un attacco all'hosting condiviso. Piuttosto, è uno sguardo puramente accademico sui problemi di sicurezza che circondano questa categoria di web hosting.
Directory Traversal
Iniziamo con gli attraversamenti di directory (spesso noti come attacchi "path traversal"). Questo tipo di attacco ti consente di accedere a file e directory memorizzati al di fuori della web root.
In inglese normale? Bene, immaginiamo che Alice e Bob utilizzino lo stesso server per ospitare i loro siti web. I file di Alice sono memorizzati in / var / www / alice, mentre i documenti di Bob possono essere trovati in / var / www / bob. Inoltre, facciamo finta che ci sia un'altra cartella sul server (/ usr / crappyhosting / myfolder) che contiene un file di testo in chiaro non crittografato (lo chiameremo pwd.txt) contenente i nomi utente e le password di sistema.
Con me finora? Buona. Ora, immaginiamo che il sito Web di Bob serva i file PDF generati localmente e il file locale sia referenziato nell'URL. Qualcosa di simile a:
http://example.com/file?=report.pdf
Cosa succederebbe se sostituissi "report.pdf" con alcuni parametri UNIX che cambiano la directory?
http://example.com/file?=../alice/
Se il server è configurato in modo errato, questo ti permetterebbe di vedere la root del documento di Alice. Interessante, ma siamo molto più interessati a quel succoso file dei passaporti. Password Accio !
http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt
È davvero così facile. Ma come affrontarlo? Questo è facile.
Hai mai sentito parlare di una utility Linux poco conosciuta chiamata chroot ? Probabilmente hai già indovinato cosa fa. Imposta la radice Linux / UNIX su una cartella arbitraria, rendendo impossibile l'uscita dagli utenti. In effetti, blocca gli attacchi di directory trasversale nelle loro tracce.
È difficile dire se il tuo host ha questo in atto senza infrangere la legge. Dopotutto, per testarlo, si accederà a sistemi e file a cui non si ha il permesso di accedere. Con questo in mente, forse sarebbe sensato parlare con il tuo host web e informarsi su come isolano gli utenti gli uni dagli altri.
Stai gestendo il tuo server di hosting condiviso e non stai utilizzando chroot per proteggere i tuoi utenti? Certo, il chroot degli ambienti può essere difficile. Per fortuna, ci sono molti plugin che rendono questo facile. Date un'occhiata a mod_chroot, in particolare.
Iniezione di comando
Torniamo ad Alice e Bob. Quindi, sappiamo che l'applicazione web di Bob ha alcuni ... Ahem ... Problemi di sicurezza in esso. Una di queste è la vulnerabilità di comando dell'iniezione, che consente di eseguire comandi di sistema arbitrari Una guida rapida per iniziare con la riga di comando di Linux Una guida rapida per iniziare con la riga di comando di Linux Puoi fare un sacco di cose incredibili con i comandi in Linux e non è davvero difficile da imparare. Leggi di più .
Il sito Web di Bob consente di eseguire una query whois su un altro sito Web che viene quindi visualizzata nel browser. C'è una casella di input HTML standard che accetta un nome di dominio e quindi esegue il comando whois system. Questo comando viene eseguito chiamando il comando PHP system ().
Cosa succederebbe se qualcuno inserisse il seguente valore?
example.com && cd ../alice/ && rm index.html
Bene, rompiamolo. Alcuni di questi potrebbero esserti familiari se hai letto la nostra Guida introduttiva a Linux Guida introduttiva a Linux Guida introduttiva a Linux Guida introduttiva a Linux di un principiante! Probabilmente hai sentito parlare di Linux, il sistema operativo open source gratuito che sta spingendo contro Microsoft. Per saperne di più e-book, che abbiamo precedentemente pubblicato nel 2010, o abbiamo dato uno sguardo al nostro Linux Cheat Sheet della riga di comando.
Innanzitutto, eseguirà una query whois su example.com. Quindi cambierebbe la directory di lavoro corrente nella root del documento di Alice. Quindi rimuoverebbe il file chiamato 'index.html' che è la pagina indice del suo sito web. Questo non è buono. No signore.
Quindi, come amministratori di sistema, come possiamo mitigare questo? Bene, tornando all'esempio precedente, possiamo sempre mettere ogni utente nel proprio ambiente isolato, igienizzato, chroot.
Possiamo anche affrontarlo da un livello linguistico. È possibile (anche se questo può rompere le cose) rimuovere globalmente le dichiarazioni di funzione dalle lingue. Vale a dire, è possibile rimuovere funzionalità dalle lingue a cui gli utenti hanno accesso.
Guardando in particolare a PHP, è possibile rimuovere la funzionalità con Runkit, il toolkit ufficiale di PHP per modificare la funzionalità della lingua. C'è una grande quantità di documentazione là fuori. Leggi dentro
È anche possibile modificare il file di configurazione di PHP (php.ini) per disabilitare le funzioni che sono spesso abusate dagli hacker. Per farlo, apri un terminale sul tuo server e apri il file php.ini in un editor di testo. Mi piace usare VIM, ma anche NANO è accettabile.
Trova la linea che inizia con disable_functions e aggiungi le definizioni di funzioni che desideri vietare. In questo caso, sarebbe exec, shell_exec e system, anche se vale la pena notare che esistono altre funzioni integrate che sono sfruttabili dagli hacker.
disable_functions = exec, shell_exec, sistema
Attacchi basati su linguaggio e interprete
Quindi, diamo un'occhiata a PHP. Questo è il linguaggio che alimenta un numero sorprendente di siti web. Inoltre viene fornito con un numero di idiosincrasie e comportamenti strani. Come questo.
PHP viene generalmente utilizzato in combinazione con il server Web Apache. Per la maggior parte, è impossibile caricare più versioni della lingua con questa configurazione.
Perché questo è un problema? Bene, immaginiamo che la web application di Bob sia stata originariamente costruita nel 2002. È passato molto tempo. È tornato quando Michelle Branch era ancora in cima alle classifiche, Michael Jordan stava ancora giocando per Washington Wizards e PHP era una lingua molto diversa.
Ma il sito web di Bob funziona ancora! Usa un sacco di funzioni PHP discontinue e deprecate, ma funziona! L'utilizzo di una versione moderna di PHP potrebbe effettivamente compromettere il sito web di Bob, e perché Bob dovrebbe riscrivere il suo sito Web per soddisfare i capricci del suo host web?
Questo dovrebbe darti un'idea del dilemma che alcuni host web devono affrontare. Devono bilanciarsi mantenendo un servizio architettonicamente valido e sicuro, mantenendo ciò in armonia con l'assicurazione che i clienti paganti siano felici.
Di conseguenza, non è raro vedere host più piccoli e indipendenti utilizzare versioni precedenti dell'interprete PHP (o qualsiasi altra lingua, se è per questo).
Non è raro vedere host più piccoli e indipendenti utilizzare versioni precedenti di PHP, esponendo potenzialmente gli utenti a rischi per la sicurezza.
Perché questa è una brutta cosa? Bene, in primo luogo, esporrebbe gli utenti a una serie di rischi per la sicurezza. Come la maggior parte dei principali pacchetti software, PHP viene costantemente aggiornato per affrontare la pletora di vulnerabilità di sicurezza che vengono costantemente scoperte (e divulgate).
Inoltre, significa che gli utenti non possono utilizzare le ultime (e migliori) funzioni linguistiche. Significa anche che le funzioni che sono state deprecate per un motivo rimangono. Nel caso del linguaggio di programmazione PHP, questo include le risibili (e recentemente deprecate) funzioni mysql_ che sono usate per interagire con il MySQL Relational Database System e dl (), che consente agli utenti di importare le proprie estensioni della lingua.
Come utente, dovresti essere in grado di vedere quale versione di un interprete è in esecuzione sul tuo servizio. Se è obsoleto o contiene una serie di vulnerabilità di sicurezza, contatta il tuo host.
E gli amministratori di sistema? Hai alcune opzioni qui. Il primo (e il più promettente) è usare Docker per ognuno dei tuoi utenti. Docker consente di eseguire contemporaneamente più ambienti isolati, proprio come fa una macchina virtuale, anche se non è necessario eseguire un altro sistema operativo. Di conseguenza, questo è veloce. Davvero, veramente veloce.
In inglese normale? È possibile eseguire l'interprete di ultima generazione più recente per la maggior parte degli utenti, mentre i clienti che utilizzano vecchie applicazioni che utilizzano interpreti obsoleti e deprecati lo fanno senza compromettere altri utenti.
Questo ha anche il vantaggio di essere indipendente dal linguaggio. PHP, Python, Ruby. Qualunque cosa. È tutto uguale.
Non avere incubi.
Questo post era destinato a fare un paio di cose. In primo luogo, è stato quello di portare alla vostra attenzione il numero di problemi di sicurezza che le società di web hosting devono affrontare per garantire la sicurezza dei loro clienti e dei loro dati.
Intendeva anche mostrarti come i siti ospitati sullo stesso server possono influenzarsi a vicenda. Vuoi mettere un ammaccatura in questo? Inizia a rispettare gli standard di codifica validi e sicuri. In particolare, inizia a disinfettare i tuoi input sia sul front-end che nel back-end.
Un buon inizio è con la nuova funzionalità di convalida del modulo HTML5. Ne abbiamo già parlato nella nostra guida HTML5. Collettivamente, possiamo rendere i siti Web più sicuri essendo i programmatori migliori e più coscienziosi.
Come sempre, sono pronto per ascoltare i tuoi pensieri. Lasciami un commento qui sotto.
Crediti fotografici: tutti hanno bisogno di un pirata informatico (Alexandre Dulaunoy), di un adesivo sulla finestra del taxi (Cory Doctorow), di una sala server (Torkild Retvedt), di libri e riviste Linux (docente di biblioteca), Elephant PHP (Markus Tacker)