Fortify360 - Sinks & Sources - Conteggio delle vulnerabilità

Lo direi quasi sempre come una vulnerabilità che si manifesta in 300 luoghi - specialmente se questo era parte di un report più ampio in cui potrebbero esserci 50, 100 o più vulnerabilità, altrimenti si finisce con un report spesso come un libro su cui nessuno può mai intervenire.

Pensaci dal lato del pubblico - vorranno conoscere la loro esposizione al rischio e cosa possono fare al riguardo. La loro azione consiste nell'assegnare un individuo o una squadra a fare la correzione, quindi dovrebbero essere informati che c'è un problema che devono essere risolti: le 300 istanze in cui si verificano potrebbero renderle una priorità più alta rispetto a una vulnerabilità con una istanza visibile, ma la riparazione potrebbe essere la stessa.

Vorrei ripetere la risposta di AviD - Cross Site Scripting è generalmente risolto meglio come un problema di codifica dell'output sensibile al contesto, piuttosto che un problema di convalida dell'input. Se stai cercando di risolverlo come un problema di convalida dell'input, in molti casi incoraggeresti un approccio di convalida dell'input della lista nera o se utilizzi un approccio alla lista bianca potresti non essere in grado di ottenerli come strettamente ristretto come desideri.

Inoltre - ciò che dovrai gestire per ogni contesto di codifica dell'output (HTML, attributi, CSS, JavaScript) sarà diverso, quindi ti consiglio di guidare il team di sviluppo verso qualcosa che faccia la codifica per loro come Microsoft WPL (Web Protection Library) o OWASP ESAPI o OWASP Reform per altre lingue.

La mia preferenza personale (e tieni presente che lavoro per un fornitore, IBM, ma è la mia opinione) è che il metodo di segnalazione ottimale per la riparazione è quello di fornire l'origine e il sink.

Direi che questo è particolarmente vero nel framework .NET in cui diversi controlli di output (sink) codificano i dati passati a loro in modo diverso e diversi controlli di input (sources) non codificano sempre i dati dalla sua forma codificata url.

Con Java di solito non vedi molta variabilità, tuttavia, penso che devi ancora prendere in considerazione sia l'origine che il sink prima di decidere una soluzione ottimale.

Secondo me è importante e non importa dove sia l'XSS e come possa essere utilizzato.

Non importa perché qualsiasi XSS è in qualche modo pericoloso.

È importante perché un XSS in un URI dall'aspetto innocuo e una struttura param è destinato a generare più phishing. In molti modi (dal punto di vista di un utente malintenzionato), è meglio disporre di un XSS disponibile su una pagina disponibile per i visitatori / utenti autenticati e non autenticati di un'applicazione o dell'infrastruttura.

Quando esprimi questo in modo diverso come SQLi anziché XSS, la situazione diventa molto più rilevante e facile da capire. Ogni istanza di SQLi potrebbe essere trasformata in un esercizio di sfruttabilità. SQLi cieco è spesso più difficile da sfruttare, ma non importa: la vera chiave è quali dati o accessi non autorizzati sono stati esposti da ogni singolo difetto SQLi. CVSS e DREAD vengono in mente, ma in realtà questo dovrebbe essere ancora più ottimizzato come CWSS e STRIDE.

Quindi - per rispondere alla tua domanda - la determinazione dovrebbe essere un esercizio nella gestione del rischio Appec. Probabilmente ci sarà da qualche parte più di 1 e forse anche meno di 300 risultati individuali per categoria di vulnerabilità. Preferisco parlare di loro come debolezze del software, ma questo può variare a seconda del pubblico di destinazione. La personalizzazione per il tuo pubblico di destinazione è sempre importante quando si presentano le informazioni, specialmente negli sforzi di scrittura dei report.

Ancora, se elencare o meno l'origine o il sink (o entrambi) dipende dal pubblico di destinazione. Se dovessi ricevere il rapporto, vorrei vederli entrambi, ma è perché sono un profondo valutatore tecnico delle applicazioni. Il sink è molto utile per la maggior parte degli sviluppatori e potrebbe consentire loro di concentrarsi sul problema della causa principale, ad esempio la codifica (nel caso di XSS e SQLi), tuttavia potrebbero esserci altri rimedi e difesa in profondità strategie da proporre sia per gli sviluppatori che per amministratori di database, amministratori di sistema, gestori e chiunque altro sia coinvolto nell'applicazione e nei cicli di vita del sistema.

Quindi la mia risposta è che questa risposta dipende in gran parte da migliaia o milioni di altri fattori.

La risposta è: dipende.

Una disciplina di progettazione è considerare tutti i dati nel database come non affidabili e disinfettati, in modo che sia responsabilità del codice che sta emettendo HTML per codificarlo o evaderlo correttamente prima di includerlo nell'output HTML. Se questo è l'approccio che il tuo progetto ha adottato, allora questo è 300 bug. Questo è un modo abbastanza comune di strutturare un'applicazione web.

Un'altra disciplina di progettazione è quella di disinfettare tutti i dati prima di memorizzarli nel database, in modo da sapere che i dati memorizzati nel database sono sicuri per l'output in tutti i plausibili contesti HTML (HTML, attributi, CSS, Javascript). Se questa è la disciplina che i tuoi programmatori stanno seguendo, allora quello che vuoi sapere è se c'è qualche posto nel codice che memorizza i dati nel database senza prima codificare / fuggire / sanificarlo correttamente. In questo caso, potresti avere un bug o potresti avere molti bug.

Una disciplina di progettazione più generale è quella di avere un invariante diverso per ogni campo nel database: alcuni di essi sono stati pre-disinfettati prima di essere archiviati nel database (e forse per diversi contesti: ad esempio, un campo potrebbe contenere pre-escape o HTML fidato, un altro potrebbe contenere una stringa pre-escaping adatta per l'inclusione in Javascript), e alcuni non hanno e dovranno essere scappati / disinfettati sul lato di uscita. In questo caso, è necessario esaminare l'invarianza del programma rispetto al particolare campo nel database associato alle vulnerabilità XSS rilevate.

Un quarto approccio, e probabilmente il più comune, è di non avere alcuna disciplina. Questa è una brutta notizia per sicurezza.

Quindi, penso che inizierei cercando di capire se gli sviluppatori del software hanno adottato una strategia sistematica per la difesa contro XSS. Se non hanno adottato alcuna strategia sistematica, c'è il problema di fondo (puoi segnalare alcuni bug, ma sono un sintomo di un problema più fondamentale e serio: la mancanza di una difesa disciplinata contro l'XSS). Se hanno adottato una strategia sistematica, una volta che hai capito quale fosse questa strategia e quali fossero le invarianti previste, sarai in una posizione migliore per scrivere utili segnalazioni di bug.

Penso che la domanda non sia se si tratta di 300 sink o di una fonte, ma è che sei vulnerabile e dovresti risolvere il problema. Quindi, invece di andare dal tuo cliente per giustificare che abbiamo 300 XSS di esposizione o 1 vulnerabilità, dovresti correggerlo e non avere vulnerabilità. Questa dovrebbe essere la posizione di un ingegnere della sicurezza.