Come posso testare la mia applicazione web per gli attacchi temporali?

Attacchi a tempo, condizioni di competizione (CWE-362) le vulnerabilità non sono molto comuni per le applicazioni web , questi sono principalmente problemi di più lingue di basso livello. Ad esempio, in CVE-2006-5178 , le condizioni di gara erano dovute all'implementazione errata nell'interprete PHP stesso. Ma anche l'applicazione basata su tali funzioni diventa vulnerabile.

Potrebbe essere scoraggiante tentare di riprodurre tale vulnerabilità, a causa di problemi di temporizzazione e delle esigenze di un ambiente specifico. Con gli scanner automatici di vulnerabilità non è possibile condurre questo test - anche per gli umani non è facile trovare tale vulnerabilità.

Secondo me, lo sviluppatore deve solo tenere a mente quando il processo principale può essere interrotto. L'atomicità dovrebbe essere fornita quando la sequenza di azioni non deve essere interrompibile. Principalmente le azioni del database sono suscettibili a tali attacchi. Anche quando DBMS supporta le transazioni e fornisce i mezzi per una sincronizzazione sicura, possono esserci più azioni globali che sono sotto controllo di DBMS per renderle atomiche. L'attenzione deve essere rivolta anche alle situazioni in cui vengono utilizzati i thread.

Nel link a CWE-362, ci sono liste di documenti che sono utili da leggere. Quelli fornirebbero molte più informazioni di quelle che ho dato qui.

La discussione e le risposte qui appaiono intorno a condizioni di gara , a cui solitamente si fa riferimento con quel nome.

Se intendi davvero attacchi temporali , probabilmente stai parlando di fuga di informazioni attraverso discrepanze nei tempi di esecuzione. Una lezione sugli attacchi a tempo è un'introduzione simpatica e accessibile a questo.

Non sono a conoscenza di strumenti che potrebbero aiutare in modo specifico a scoprirli, ma i comuni strumenti di valutazione web potrebbero rivelare altri problemi che potrebbero essere esacerbati da un attacco di temporizzazione.

Supponiamo che tu abbia una vulnerabilità che consente ad una parte esterna di eseguire codice SQL contro il tuo database: l'iniezione SQL classica. Supponiamo che tu abbia preso alcune precauzioni: non possono recuperare dati o scrivere informazioni arbitrarie nel tuo database, devi solo restituire un messaggio di errore generico di qualche tipo. Sarebbe possibile che la parte esterna verifichi lo schema del proprio database usando le istruzioni "select" e calcolando il tempo impiegato per ricevere una risposta; semplicemente osservando quanto lavoro sta facendo il tuo sistema di back-end, stanno imparando qualcosa che potrebbero non avere altrimenti (se esiste una tabella particolare, se ci sono molti record in una tabella, ecc.)