Ignorando la convalida dell'input dell'applicazione Web

L'attaccante non può scegliere quali codifiche potrebbero essere efficaci. Se non è presente decodificatore base64 a livello di applicazione, l'esecuzione della codifica base64 non porterà a nulla.

Se è un passo di decodifica base64 alla fine dell'applicazione, l'applicazione dovrebbe eseguire la convalida dell'input dopo la decodifica è stata eseguita.

Nel caso dei WAF, che siedono nel mezzo e non sanno cosa potrebbe fare la decodifica dell'applicazione, hai ragione - non sono affidabili.

Alcuni strumenti applicano solo la decodifica standard del protocollo (ad esempio decodifica URL per i parametri URL) e falsi-negativi sugli attacchi codificati utilizzando uno schema ad hoc; alcuni strumenti provano una selezione di codifiche e opzionalmente combinazioni n di codifiche profonde per cercare di individuare le firme di attacco, che possono portare a falsi positivi poiché il testo innocuo che non sarà mai codificato in base64 viene interpretato erroneamente come base64- codifica di qualcosa che potrebbe essere un attacco.

Quindi sì, le correzioni come i WAF che operano al di sopra del livello dell'applicazione sono inaffidabili, ma non è una novità. Nessuno dovrebbe fare affidamento esclusivamente su un WAF per la sicurezza; sono utili per rilevare attacchi generici e per soluzioni temporanee personalizzate per vulnerabilità note fino a quando è disponibile una correzione per app, ma non possono mai essere un filtro di input a tenuta stagna.

Non convalidi le stringhe di input in abstracto . Convalidi le stringhe per uno scopo specifico .

Quando un utente malintenzionato aggira un sistema di validazione usando Base64, ciò significa che il sistema di convalida e il sistema che usa il valore, non sono d'accordo. Il sistema di validazione non conosce Base64, ma il sistema sottostante applicherà felicemente la decodifica Base64 sull'input. Questa è una convalida mal fatta.

Potremmo argomentare che "la validazione dell'input" è più o meno destinata a fallire quando viene eseguita in un sistema separato (ad esempio in un front-end), perché due pezzi di software gestiti in modo indipendente non possono essere mantenuti completamente sincronizzati in ogni momento. Questo è il problema generico con mysql_real_escape_string() nel contesto PHP + MySQL: la funzione PHP deve essere pienamente consapevole di tutti i dettagli di come l'implementazione MySQL sottostante interpreterà le stringhe di input, e tali dettagli variano con le versioni del prodotto.

Sono d'accordo con il post di @ Thomas-pornin riguardo alla convalida dell'input, ma vale la pena segnalare (RE: OP) che non esiste un infinito numero di schemi di codifica. Ce ne sono molte, ma non è un sistema interminabile. Quando si proteggono le applicazioni è importante ricercare quali schemi di codifica sono supportati dai propri sistemi e adattare la sicurezza alle esigenze del proprio sistema, piuttosto che cercare di mappare ogni set di codici noto per ogni potenziale problema di sicurezza. Sfortunatamente non esiste un "martello d'oro" per risolvere il problema di un'acquisizione o di una gestione non sicura dei dati, quindi la dovuta attenzione e la dovuta diligenza sono fondamentali.

Buona fortuna per il tuo lavoro.

Un utente malintenzionato che di solito cerca di iniettare codice dannoso usando le vulnerabilità XSS o SQL injection, considera che hai implementato un'istruzione preparata che previene dall'iniezione SQL, quindi la restante possibilità è l'attacco XSS.

Il codice dannoso per XSS contiene JavaScript o qualsiasi tipo di incorporamento incrociato:

JavaScript with <script src="..."></script>
CSS with <link rel="stylesheet" href="...">
Images with <img>
Media files with <video> and <audio>.
Plug-ins with <object>, <embed> and <applet>.
Fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
Anything with <frame> and <iframe>

From (Same-origin policy)

Ora, considera che l'utente usi uno di questi metodi, è noto che consentire l'HTML è pericoloso per l'utente, considerando che l'utente malintenzionato usa la codifica base65 per offuscare il codice, ma come può essere eseguito questo codice? e perché il tuo sistema decodifica base64?

Un altro scenario è quando la tua applicazione usa l'input dell'utente per essere usato in applicazioni di terze parti, in questo caso puoi dire rigorosamente all'utente di seguire il pattern consentito, altrimenti potresti rifiutare l'input.