Sei stato assunto per correggere un piccolo bug per un sito ad alta sicurezza. Guardando il codice, è pieno di buchi di sicurezza. cosa fai? [chiuso]

Sono stato assunto da qualcuno per fare qualche piccolo lavoro in un sito. È un sito per una grande azienda. Contiene dati molto sensibili, quindi la sicurezza è molto importante. Dopo aver analizzato il codice, ho notato che è pieno di buchi di sicurezza - leggi, molti file PHP che inviano l'utente ottengono / inviano input direttamente nelle richieste mysql e nei comandi di sistema.

Il problema è che la persona che ha creato il sito per lui è un programmatore con famiglia e figli che dipendono da quel lavoro. Non posso semplicemente dire: "il tuo sito è un parco divertimenti per bambini con sceneggiatura. Fammi rifare per te e starai bene."

Cosa faresti in questa situazione?

Aggiornare:

Ho seguito alcuni buoni consigli qui e cortesemente segnalato allo sviluppatore che ho trovato alcuni possibili difetti di sicurezza sul sito. Ho indicato la linea e detto che potrebbe esserci una possibile vulnerabilità per gli attacchi SQL injection lì, e ho chiesto se ne fosse a conoscenza. Ha risposto: "certo, ma penso che per sfruttarlo l'attaccante dovrebbe avere informazioni sulla struttura del database; devo capire meglio" .

Aggiornamento 2:

Ho detto che non è sempre il caso e ho suggerito di seguire questo link della domanda Stack Overflow per gestirlo correttamente: come prevenire l'iniezione di SQL in PHP? Ha detto che lo avrebbe studiato e mi ha ringraziato per averlo detto prima. Immagino che la mia parte sia finita, grazie ragazzi.

Innanzitutto qui, la priorità è chiudere le falle di sicurezza.

Se stai lavorando direttamente con l'ingegnere che ha scritto questo, documenta tutto e consegnalo a quell'ingegnere.

In caso contrario, informa il tuo datore di lavoro che i problemi di sicurezza sono più grandi di quanto inizialmente pensato e che il sito ha bisogno di molto lavoro. Chiedi di lavorare con lo sviluppatore principale che si trova sul sito e offri loro di insegnare loro sulla sicurezza di PHP (non promettere di rendere la persona esperta, ma offri di addestrarlo in tutto ciò che conosci) in modo che quella persona possa prenderne il controllo dopo aver finito.

Non rendere questo un problema "questo ragazzo è cattivo, licenzialo". Approccio dal punto di vista di "Ehi, ho trovato alcuni potenziali bug che necessitano di correzione stat, che sembrano provenire da alcune ignoranze / idee sbagliate comuni sulla sicurezza del sito. Vorrei anche parlare con il tuo sviluppo in modo che possiamo migliorare il tuo sito e speriamo di evitare più di questi problemi in futuro ".

C'è una differenza tra ignoranza e incompetenza. C'è stato un tempo in cui non sapevi nemmeno cosa fosse l'iniezione di SQL e non c'è motivo di credere che il programmatore originale non sia in grado di risolvere i problemi una volta che ne è venuto a conoscenza.

Quindi diglielo. Sii specifico e obiettivo e renditi disponibile per rispondere alle domande, fornire esempi di exploit e consigli per le correzioni. Se dopo questo punto non riescono ancora a ottenerlo, il massimo che puoi davvero fare non è inserire le tue informazioni personali sul sito.

Il tuo compito non è quello di rifare il sito per lui. Serve a correggere il piccolo bug. Tuttavia, se hai notato problemi di sicurezza che dovrebbero essere risolti, puoi mostrarlo al proprietario del sito e offrire informazioni su quale potrebbe essere il problema.

Non rimproverare o parlare negativamente dello sviluppatore originale o commentare quanto sia orribile il codice. Sii rispettoso e professionale. Puoi offrirti di collaborare con lo sviluppatore per risolvere i problemi. Non provare a risolverlo da solo o offrire una soluzione a meno che non sia stato assunto un contratto per risolvere il problema. Se seguono il tuo consiglio e ti sbagli potrebbero tornare su di te.

Innanzitutto, risolvi la cosa per cui ti hanno assunto. Se non lo fai, allora verrai percepito come il tipo di consulente che è interessato a fare più lavoro per se stesso, piuttosto che farlo.

Insieme alle correzioni, devi dare loro un elenco delle cose che hai notato che è sbagliato dal punto di vista della sicurezza e perché queste cose sono sbagliate.

Non farà bene a nessuno non segnalare i problemi. Se hai avuto un'attività specifica, sei stato assunto per completarlo, ma documenta altri problemi di sicurezza quando li vedi e li segnala alla persona appropriata, probabilmente la persona a cui stai segnalando l'attività per cui sei stato assunto.

Questa è una situazione in cui le competenze trasversali saranno utili per gestire questo problema con il tatto e non richiedere il lavoro svolto da altri sul sito e non far sentire lo sviluppatore come se stessi mettendo in discussione il suo talento.

Evita ovviamente parole come "schifezze, cattive, povere, indovinate" quando ti riferisci al codice / difetti e parole simili per lo sviluppatore che ha scritto il sito.

Oltre alle altre risposte, ciò che potresti voler fare è indicare allo sviluppatore alcune risorse sulla facilità con cui i problemi di iniezione SQL possono essere sfruttati, ad esempio sqlmap che è uno strumento di sfruttamento dell'iniezione SQL automatizzato.

Ciò che ho trovato efficace nel dimostrare la gravità di questo tipo di problema in passato è mostrare cosa si può fare con esso, quindi se si esegue qualcosa di simile contro uno sviluppatore. copia del sito per mostrarne l'estrazione di dati ecc. potresti convincerli della serietà.

Primo e unico; La direzione non vuole conoscere i problemi. Sono stato licenziato dall'Office of Personnel Management (autorizzazioni di sicurezza per la casa bianca) perché ho sottolineato quanto fosse insicuro il loro sistema. Era un po 'indietro, ma gli atteggiamenti della direzione non sono cambiati.

Risolvi il problema con lo sviluppatore, via e-mail in modo da avere una traccia, quindi cammina o scappa. Quando alla fine hanno un problema, come appaltatore, cercheranno di incolpare te, indipendentemente dal fatto che qualsiasi coinvolgimento sia collegato in remoto al problema.

Avere un problema fondamentale come un'iniezione di SQL, indica che erano economici quando inizialmente svilupparono il sistema e, probabilmente, oggi sono al massimo a buon mercato. Ottieni ciò che puoi da loro mentre sono ancora in attività, ma cerca lo sviluppo del business altrove.