Dovremmo vivere usando Suhosin con PHP?

1

Molti dei miei amici esperti in sicurezza mi hanno detto che ho bisogno di codificare le mie applicazioni web per lavorare con la patch PHP Suhosin, Suhosin essere "un sistema di protezione avanzato per installazioni PHP [...] progettato per proteggere server e utenti da difetti noti e sconosciuti nelle applicazioni PHP" . Senso che afferma tale impresa, ho dovuto riscrivere un bel po 'delle mie funzioni e classi.

Questo è il nuovo standard per creare applicazioni web sicure in modo che sia più difficile da sfruttare e compromettere? Suhosin è ora un requisito comune per lo sviluppo web in PHP?

    
posta Traven 01.07.2014 - 23:31
fonte

1 risposta

4

La descrizione sul sito web di Suhosin è abbastanza chiara, enfasi mia:

If you are using PHP only for your own server and only for your own scripts and applications, then you can judge for yourself, if you trust your code enough. In that case you most probably don’t need the Suhosin extension. [...] Even PHP core programmers are writing insecure code from time to time, because they did not know about a PHP pitfall.

Suhosin è uno dei modi per mitigare i rischi legati ai buffer overflow e vulnerabilità simili. Non è l'unico modo e non renderà magicamente la tua applicazione sicura al 100% e priva di errori.

Ogni programmatore PHP dovrebbe usarlo? No, perché è un eccesso. Personalmente, preferirei convincere ogni programmatore PHP a leggere e comprendere le principali vulnerabilità OWASP e quando leggo domande con tag PHP su Stack Overflow per pochi minuti, spero solo che ogni programmatore PHP possa imparare che cos'è SQL Injection, e solo quello sarebbe un grande passo avanti.

  • Per i piccoli progetti, non importa. Se sono scritti da un ragazzo che sa cos'è SQL Injection, ottimo. È solo che ci sono cose più importanti da fare, come ottenere il lavoro o trovare clienti reali.

  • I progetti di grandi dimensioni sono spesso scritti da sviluppatori esperti che conoscono le loro cose e sanno quali sono le vulnerabilità e come evitarle. Un altro paio di occhi come Suhosin non farà male, ma il team deve osservare tutti i pro e i contro prima di adottarlo, soprattutto perché potrebbe essere abbastanza ridondante con altre tecniche. Preferirei che il mio codice venisse esaminato da un esperto di sicurezza piuttosto che fare affidamento su uno strumento che non conoscevo nemmeno il nome mezz'ora fa.

  • I progetti su media scala sono quelli in cui Suhosin può essere interessante. Quelli potrebbero non essere in grado di permettersi esperti di sicurezza e sviluppatori esperti, quindi qualsiasi strumento gratuito, sarebbe un controllo statico o un'estensione come Suhosin, potrebbe essere d'aiuto. Allo stesso tempo, vorrei capire la seccatura di distribuire un'ulteriore estensione ai server di produzione.

L'utilizzo di tale estensione può anche dare un falso senso di sicurezza , specialmente quando leggi cose come:

Always keep in mind that you are not only protecting yourself and your users, but also other people on the internet, that might get attacked by your server after it has been turned into a (Spam-/DDOS-)attack drone.

Ecco una stima grezza e approssimativa delle fonti di gravi rischi per la sicurezza sui server dei miei clienti (piccole e medie applicazioni web da piccole a medie non importanti per l'azienda):

  • 70%: il server non viene mantenuto (esempio: vecchia versione di PHP di quattro anni, mai rattoppata nonostante i problemi critici scoperti da allora).

  • 15%: io o il mio team abbiamo introdotto un bug nell'applicazione web o utilizzato una libreria di terze parti con un bug che non ho notato.

  • 10%: il server ospita FTP, SMTP, DNS, Active Directory, SQL Server 2000, SQL Server 2005, SQL Server 2008 R2, SharePoint, IIS, Apache e una dozzina di altri servizi. Dato che nessuno sa come configurare il firewall, è stato disabilitato. Un giorno, quando questo controller di dominio viene violato, nessuno ha nemmeno la più pallida idea di cosa sia stato usato dall'hacker.

  • 1%: c'è un exploit nell'ultima versione di PHP, sistema operativo o framework popolare (vedi Attacco zero-day ).

  • 4%: qualcos'altro.

Suhosin aiuterà qui nel massimo del 15% dei casi, ma darà la sensazione di non dover affrontare il 95% dei possibili problemi.

Lo stesso falso senso di sicurezza può portare a problemi più grandi:

If you are not only running your own PHP scripts but are also hosting 3rd party PHP applications for yourself or even for possible customers, then you cannot trust the code quality of the PHP applications you use.

Se non mi fido del codice di terze parti, non lo uso. Non sui miei server. Se è un codice che non può essere rivisto, come il codice scritto dai clienti stessi , allora dovrebbe comunque funzionare in una sandbox, con autorizzazioni molto restrittive .

    
risposta data 02.07.2014 - 02:26
fonte

Leggi altre domande sui tag