E 'necessario testare tutti i parametri di input di un'applicazione Web quando si verifica la sua sicurezza?

1. Sì, è necessario testare tutti i parametri se si desidera eseguire un buon test. È possibile scegliere di utilizzare il test automatico o manuale in base alla criticità della variabile di input e alla posizione in cui si trova nell'applicazione. Si noti che mentre una determinata variabile di input può sembrare non critica, potrebbe lasciare agli attaccanti un vettore di accedere a funzionalità più critiche dell'applicazione (si pensi allo XSS memorizzato)
2. Stabilisci priorità in base alla probabilità e all'impatto sulla tua attività. Se tale vulnerabilità consente di eseguire comandi o scaricare tutti i contenuti del database, incluse le informazioni riservate, è necessario correggerli il prima possibile. Se consente solo l'accesso alle informazioni pubbliche (e non può essere sfruttato per ottenere maggiori privilegi all'interno dell'applicazione o l'accesso al sistema operativo sottostante), è possibile renderlo meno prioritario (a seconda di quali sono gli altri problemi in base alle priorità on)
3. Non sono sicuro di quali siano gli "elementi di input", ma se intendi parametri, devi scegliere tutto. Puoi scegliere di prestare maggiore attenzione su alcuni campi rispetto ad altri (a seconda del budget / ora)
4. Dipende, devi fare quello che ti chiede il tuo cliente, ovviamente se la tua esperienza ti ha insegnato che certe variabili sono più sensibili di altre, potresti dare loro un po 'più di attenzione. Ma direi che è necessario tenere conto delle esigenze del cliente.

Anche se una funzionalità non è considerata critica, è sempre necessario valutare l'impatto che l'exploit ha sull'applicazione e le informazioni memorizzate all'interno dell'applicazione. È vero anche il contrario, se si dispone di una funzionalità critica con un exploit, ma non si può effettivamente ottenere alcuna informazione preziosa da esso, quindi si dovrebbe rendere meno una priorità per risolverlo. Pertanto, l'impatto dello sfruttamento di una vulnerabilità è importante e non la criticità della funzione che stai sfruttando. La definizione delle priorità deve avvenire in base all'impatto.

La risposta è in modo definitivo "sì", "no" e "dipende". Il modo migliore per porre questa domanda sarebbe " Sapendo che ho risorse limitate, come dovrei dare la priorità a una recensione della mia applicazione web? ".

In sicurezza, il successo non è definito come sicuro al 100%. Il successo dovrebbe essere definito come la riduzione del rischio fino ad un livello accettabile. Il tuo "livello di rischio accettabile" dovrebbe essere basato su ciò che fa la tua applicazione, su ciò che protegge, quale è la ricaduta se succede qualcosa di brutto. Voglio fare più revisioni del codice che esegue il mio pacemaker di quello del gioco per Android che compro per un dollaro.

Per il 99% delle organizzazioni, le risorse sono limitate. È improbabile che tu abbia le risorse per testare completamente ogni aspetto della tua applicazione web. Devi capire quali risorse hai a disposizione per la revisione e poi la priorità.

Ogni applicazione è diversa, quindi dovresti esprimere i tuoi giudizi, ma qui ci sono alcune cose a cui darei la priorità:

Input utilizzati come parte delle query SQL (SQL injection)

Input usati come parte dei comandi eseguiti (comando di iniezione)

Input usati come parte delle query LDAP (ldap injection)

Input di un utente restituiti ad altri utenti (XSS persistente)

Input di un utente restituiti a quell'utente (XSS riflesso)

Input usati come parte di azioni che modificano l'account di un utente

Input usati come parte di qualsiasi elaborazione complessa (DOS esaurimento risorse)

Input che vengono passati a qualsiasi processo eseguito con privilegi elevati

Inoltre, sapendo che non puoi esaminare in modo esauriente ogni aspetto della tua app web, "imbrogli" aggiungendo ulteriori attenuazioni:

Esegui il tuo server web senza privilegi elevati

Gli account per l'accesso ai DB dovrebbero avere privilegi minimi

Avere account separati per diversi tipi di accesso al DB. Se il 95% delle chiamate DB sono di sola lettura, non utilizzare un account con privilegi di scrittura per tali.

Come altri hanno sottolineato, la risposta breve è YES , è necessario testare tutti i parametri di input perché quando si scende a esso non si ha idea di quanto sia o meno codificata l'applicazione.

Tuttavia , come hai affermato, che non sempre vola quando ci sono scadenze irrealistiche dalle linee di business - che per mancanza di una frase migliore, davvero non mi interessa.

OWASP potrebbe essere in grado di indurti su quali caratteri devi dare la priorità. Ad esempio: link (sito Web OWASP)

Tuttavia, con ciò detto, ora hai appena creato un carico di lavoro più grande. Devi passare attraverso ogni possibile vulnerabilità e determinare quali caratteri sono specifici per tale vulnerabilità.

Questo compito da solo potrebbe richiedere più tempo (almeno inizialmente) rispetto a testare tutti i personaggi e non sarà così approfondito. (che è ovvio)