Quali caratteristiche di sicurezza ti piacerebbe trovare o aspettarti da un framework PHP? Ho un framework PHP che ho sviluppato che sto per essere rilasciato come progetto open source, ma voglio assicurarmi che abbia caratteristiche di sicurezza appropriate. Ecco cosa ho finora:
Cos'altro dovrebbe includere ragionevolmente una struttura PHP?
Bene, costruire la sicurezza in un framework non è un compito facile. Prendi ad esempio la protezione XSS che hai menzionato. L'attuale tendenza nella sicurezza delle applicazioni Web afferma che sono necessarie tre cose per gestire i difetti di iniezione:
Anche quando si gestisce tutto il lato server sopra, si può ancora essere vulnerabili all'attacco DOM XSS quando il codice JavaScript vulnerabile è stato introdotto nell'applicazione (e, ad esempio, jQuery potrebbe introdurre DOM XSS pure.
Personalmente, ritengo che le caratteristiche più importanti e spesso trascurate dei framework siano le impostazioni predefinite sicure e gli esempi di codice sicuro. Gli sviluppatori spesso copiano e incollano il codice o lasciano le impostazioni come predefinite. Pertanto, se stai introducendo token come protezione CSRF, aggiungili in ogni modulo per impostazione predefinita e consenti che vengano disattivati in codice / config.
Se stai cercando una specie di checklist per framework sicuri, una volta c'era un progetto OWASP (ora chiuso) - Manifesto sulla sicurezza delle applicazioni Web . Ha mirato a fornire tale test ed è attualmente la migliore lista di controllo che ci sia. Consulta anche vari fogli cheat OWASP per aiutarti a implementare ogni controllo di sicurezza.
Consiglierei di aggiungere misure anti-automazione ad esso. Un utente del framework può scegliere quali pagine desidera proteggere con questa funzione (ad esempio una pagina di accesso o un modulo di feedback). Se un utente malintenzionato invia il modulo più volte, si troverà di fronte a un CAPTCHA per ogni richiesta successiva, in base al suo IP (non ID di sessione!).
Inoltre, la gestione delle sessioni è un compito noioso. Il framework dovrebbe assicurarsi che:
Le sessioni generate dall'utente non sono accettate Ciò al fine di prevenire il dirottamento di sessione, in cui un utente malintenzionato genera un ID di sessione che qualcun altro deve utilizzare
Gli ID di sessione vengono rigenerati dopo l'autenticazione In questo modo, quando un utente malintenzionato riesce a convincere una vittima a utilizzare un determinato ID di sessione, l'utente malintenzionato non avrà una sessione autenticata quando la vittima effettuerà l'accesso
Gli ID di sessione delle sessioni autenticate non vengono mai trasmessi su HTTP Ma usa SSL per tutte le cose autenticate
I cookie di sessione hanno i flag appropriati HttpOnly e Flag sicuro per sessioni autenticate
Inoltre, raccomanderei che il framework permetta allo sviluppatore di impostare le politiche di caching. Per le pagine che vengono offerte agli utenti autenticati, che potrebbero contenere dati sensibili per la privacy, il caching dovrebbe essere facile (o anche predefinito) da disattivare.
Oh joy - un altro framework PHP. Per favore, scusa il mio sarcasmo, ma ci sono un numero enorme di strutture che galleggiano tutt'attorno. La maggior parte sono gonfie, lente e piene di bug di sicurezza. Ma almeno stai cercando di affrontare i problemi di sicurezza in anticipo.
Direi che è discutibile se un framework debba fornire il proprio livello di astrazione del database. per esempio. A volte il pattern di registrazione attivo è utile, ma non sempre.
Di gran lunga il componente aggiuntivo di sicurezza più prezioso sarebbe la garanzia di compatibilità con le versioni precedenti per incoraggiare la tua base di utenti ad eseguire l'upgrade quando rilascerai nuove versioni.
Come per il mio commento altrove, la convalida non è un problema di sicurezza - sono rappresentazioni corrette dei dati. Fornire un semplice meccanismo per cambiare tra le rappresentazioni per diversi target e da / verso i formati neutri di destinazione (che di solito significa alcune modifiche alla codifica base64) sarebbe buono.
Tuttavia, la convalida dei problemi funzionali non è una cosa negativa - ad es. assicurandoti che la data di partenza per una prenotazione sia successiva alla data di arrivo.
La registrazione è molto importante.
Vale la pena considerare la sandboxing dei file I / O.
Come dice Chris, dovresti fornire prevenzione contro il dirottamento / la fissazione delle sessioni.
Potresti considerare di fornire un framework di autenticazione (dopotutto se hai ACL stai già imponendo alcuni vincoli su come l'autenticazione è implementata).
Se vuoi un framework veramente sicuro, pensa a come implementerai le sessioni non ricercabili (le uniche soluzioni che ho trovato per questo si basano sui demoni per la separazione dei privilegi - quindi sono del tutto inadatte per la maggior parte delle persone che desidera proteggere i dati di sessione, ad esempio quelli sui pacchetti di hosting condiviso a basso costo.
Ci sono molte altre cose fuori dal dominio di sicurezza - ad es. supporto per la messaggistica asincrona. Ma tieni a mente ogni volta che aggiungi più funzionalità potresti negare la possibilità di utilizzare un framework complementare accanto al tuo (ad es. Smarty, gabbiano, la dottrina è molto capace in aree specifiche)
Motore delle regole di convalida dell'input. (e l'output è per questo)
Leggi altre domande sui tag php