Bene .... dipende. Se il tuo cliente è una banca - no, non possono andare in diretta. Dovrebbero licenziare la squadra e ricominciare. Se il tuo cliente è un sito dedicato a mostrare immagini divertenti di gattini, non si occupa di denaro o di informazioni personali identificabili - quindi sicuro, vai a vivere.

Il fatto che ti abbiano chiesto di fare un audit in primo luogo suggerisce che c'è almeno un certo livello di rischio.

L'argomento "concettuale contro pratico" è un colpo da maestro, ma puoi contrastare con "La sicurezza è un processo, non un prodotto ". Se non si dispone di un processo per la gestione della sicurezza (e ignorando XSS e SQL injection si suggerisce di non farlo), è solo una questione di tempo prima di diventare una vittima. Certo, mod_security ti protegge dalle vulnerabilità note, ma una base di codice scadente è molto più vulnerabile ai nuovi exploit. Se il sito del tuo cliente è attraente per gli aggressori, il codice mal costruito è molto più probabile che offra un qualche tipo di supporto - e potrebbe non essere SQL injection o XSS; potrebbe essere una perdita di informazioni (cosa succede quando si forza un errore? vedi le informazioni che non dovresti?), potrebbe essere un cattivo trattamento dei parametri (cosa succede se manipolo le richieste HTTP per inserire parametri non validi nell'app?).

La mia raccomandazione sarebbe quella di chiedere al cliente di concordare quale dovrebbe essere il loro processo di sicurezza, quali standard pensano di dover rispettare - potresti fare peggio dell'uso di Drupal's e come misureranno i loro obiettivi. Suggerirei di ottenere un buono stato di salute da uno strumento di analisi statica e di poter disattivare mod_security sarebbe essere un buon punto di partenza

Secondo la mia esperienza, un codebase povero tende a degradarsi molto rapidamente; Ho visto un avvio letteralmente dover buttare via il 90% del loro codice meno di 18 mesi dopo che è stato scritto perché la qualità complessiva era così scarsa.

Una volta che sai qual è il processo di sicurezza, puoi concordare un piano per aderirvi. Penso che tu possa prendere una decisione aziendale sul fatto di lanciare l'attuale iterazione del sito. Suggerirei che questa decisione aziendale debba prendere in considerazione la protezione dell'investimento nell'attuale base di codici, nonché i problemi di sicurezza.

Are SQL Injection vulnerabilities in a PHP application acceptable if mod_security is enabled?

No, almeno non se me lo chiedi.

Se le iniezioni SQL sono accettabili per il cliente, non c'è nulla di cui preoccuparsi. Potresti chiederti perché ti hanno chiesto di rivedere le sceneggiature comunque, ma non mi darò fastidio, prenderò i soldi e dirò addio. Non c'è molto da discutere, è una risposta piuttosto semplice:

Non ci sono.

Se è vero per loro, sanno quello che fanno, non i tuoi affari.

Is my position here too harsh? Even if they fix the SQL Injection and XSS problems can I ever endorse the release of an unmaintainable tangle of spaghetti code?

No, la tua posizione non è troppo severa. Devi adottare un approccio molto semplice: correggi le vulnerabilità, organizza il codice e quindi verrà approvato.

Tutto ciò che è inferiore a questo assicurerà che il cliente abbia problemi ancora più grandi lungo la strada ... come ho scoperto quando ho assunto il ruolo di responsabile dello sviluppo per un progetto HRM open source. Ho passato un anno a riscrivere il 95% del codice da zero, perché gli sviluppatori originali non avrebbero avuto il tempo di seguire gli standard di codifica appropriati come la struttura delle cartelle logiche, usando classi e funzioni per la ripetizione, intestazioni universali, database normalizzati, ecc.

Il lungo e breve è, se verrà distribuito a chiunque tramite il web, non è più un problema "concettuale" , è molto pratico.

La tua reazione iniziale è quella di un purista sviluppatore. Vedi spazzatura e pensi che dovrebbe essere aggiustata.

I problemi con questo approccio sono che commercialmente è molto improbabile che sia accettabile per il cliente, e probabilmente non è commercialmente realistico.

Devi dare al cliente una risposta che indirizzi tutti i punti rilevanti, oltre a dare un piano per il futuro (offri al tuo cliente una soluzione, non un problema).

Potresti per esempio fornire un rapporto scritto (e ti consiglio caldamente di metterlo per iscritto - se ti fossi impegnato a fare una valutazione, dovresti consegnare qualcosa per iscritto).

Il rapporto potrebbe dire qualcosa di simile (notevolmente ampliato, ovviamente):

• il prodotto è scritto male (cita esempi che hai già elencato);
• il prodotto contiene vulnerabilità di sicurezza e anche se non sei un esperto nel campo, è tua opinione che saranno sfruttate in un determinato momento;
• il prodotto non verrà scalato correttamente (questo era il tuo brief originale) a causa della scarsa struttura del codice, della mancanza di coerenza, dell'uso di numerose istanze di codice cut-and-paste che compromette la manutenibilità.

Puoi quindi continuare a dire:

• in un mondo perfetto, non vincolato dalle realtà commerciali delle date di rilascio o del budget, il prodotto dovrebbe essere usato come prototipo e lo sviluppo dovrebbe essere ripreso [Dire usato come prototipo significa che non stai dicendo la sua spazzatura, lo stai dicendo è una sveltina che può essere usata per valutare aspetto / tatto / stile / flusso di lavoro, ecc ... è politicamente più morbida.];
• perché il prodotto deve essere rilasciato, un passaggio fondamentale è eseguire un'analisi di vulnerabilità della sicurezza: si tratta di un'attività urgente. Qualsiasi patch up deve essere applicato rapidamente, anche se questo rende il code-base più complesso;
• un'attività secondaria dovrebbe iniziare a iniziare un progetto di sostituzione che si ridimensionerà e sarà più gestibile. Questo potrebbe usare un framework, o potrebbe prendere il codice esistente e migliorarlo;
• se l'esito dell'attività secondaria è di intraprendere processi di refactoring e miglioramento, questo è accettabile ... e potresti suggerire dei punti da cui iniziare (ad esempio, sistema di menu comune, codice HTML di intestazione / piè di pagina comune, spostamento di CSS fuori codice, ecc. ecc.). Ognuno di questi elementi potrebbe essere elencato e questi potrebbero essere elementi di lavoro da preventivare e lavorare come piccoli progetti come parte del refactoring.

Quindi quello che ti suggerisco di presentare è una soluzione graduale piuttosto che alzare le mani e dire "è di nuovo un casino" che è emotivo e non molto costruttivo.

Dopo aver inviato il tuo rapporto, potresti diventare parte della soluzione. Probabilmente non sarai molto popolare tra gli sviluppatori: il fatto che abbiano fatto ciò che hanno fatto probabilmente significa anche che non capiranno la maggior parte di ciò che invii. Il pericolo è che anche il cliente non lo capisca. Quindi c'è un'alta probabilità che, dopo aver inviato il tuo rapporto, vieni pagato e non sentirai più parlare di loro. Così sia. Il rapporto scritto copre il tuo culo [culo per gli americani].

Guardarlo da un'angolazione diversa, se gli sviluppatori pensano che la massiccia ripetizione sia un "problema concettuale, non pratico", allora hai preoccupazioni più serie di problemi di sicurezza che - almeno a questo punto - sono veramente teorici.

Una base di codice piena di ripetizioni inutili non sarà più possibile: quando provano a cambiare qualcosa, dovranno cambiarlo in X posti diversi. Generalmente trovano X-1 (forse meno, a seconda della complessità) e questo introdurrà bug sottili nella base di codice. La loro risoluzione richiederà più modifiche ... e puoi vedere dove sta andando. Su qualsiasi prodotto che deve evolvere, (che è fondamentalmente qualsiasi prodotto ), questo può essere il bacio della morte.

E il fatto che lo liquidino come una mera preoccupazione teorica dimostra che non capiscono che si tratta di un problema reale, il che significa che non sapranno come risolverlo una volta che inizia a causare problemi per loro, o addirittura riconoscendo che questo è alla radice dei loro problemi. Se stavo verificando questo progetto, li avrei falliti solo su questa base, anche se la sicurezza fosse a tenuta d'aria.