Sicurezza accettabile: disabilitare ValidateRequest con le stringhe codificate SQL e HTML paramatizzate?

Question

Sto cercando di assicurarmi che l'applicazione ASP.NET di Webform sia il più sicura possibile, riceve e archivia i dati di input dell'utente in un database SQL (le solite cose) solo per gli utenti con un accesso, quindi non disponibili per il generale pubblico.

Disattivando ValidateRequest per le pagine di input, apprezzo il rischio di attacchi XSS: tutte le query SQL sono parametrizzate, quindi sono sicure da SQL Injection (corretto?).

Invece di utilizzare il libary Anti-XSS, posso solo usare HTMLencode sul testo di input? Conservo quindi la stringa d HTMLencode?

O lo sto guardando nel modo sbagliato? Devo memorizzare gli utenti immettendo testualmente, e quindi HTMLencode o XSS-HTMLencode ogni volta che viene inviato a un browser?

Answer 1

OK, leggendo attorno ad esso sembra che la saggezza comune è quella di memorizzare l'input alla lettera, non apportare modifiche what-ever-ever, semplicemente parametrizzare per proteggere contro le Iniezioni SQL.

Alcuni buoni commenti qui: What are the best practices for avoiding xss attacks in a PHP site

Allora o HTML Encode (sembra vulnerabile), o utilizzare il XSS-Library per codificare l'uscita - Come detto nel link qui sopra, la destinazione dei dati non può essere un browser in un secondo momento.

Quindi utilizzare l'esempio di attacchi XSS qui: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet immettere alcuni di questi nel database e leggere di nuovo nel browser. Con la giusta codifica dovresti vedere il testo e non avere uno script eseguito.

Answer 2

Tenendo conto che gli attacchi di Injection e XSS contengono due primi punti nello OWASP top 10 è necessario essere molto attenti, quindi si disabilita la convalida della richiesta in asp.net.

Prima non disabilitare la convalida della richiesta a meno che non sia realmente necessaria. Devi avere una ragione per farlo. La convalida delle richieste è un meccanismo nativo contro il tipo di attacco XSS.

Seconda sempre fare white list validation per tutti i campi di input, che ha permesso di passare attraverso solo carte accettabili.

Ci saranno casi in cui è necessario passare attraverso caratteri come "<" o ">", che è potenzialmente pericoloso.

in modo da avere per codificare sempre uscita se si visualizza nella pagina. Sempre. Questo è impedito da JavaScript (se quello è stato inserito nell'input) per essere eseguito.

query parametrizzate devono essere utilizzati insieme suddetto convalida bianco-list e codifica output per evitare attacchi SQL injection.

Inoltre non fare alcuna costruzione query dinamica (SQL dinamico) all'interno stored procedure SQL.

E assicurarsi che tutti voi utenti DB e SQL stored procedure ha un adeguato livello di accesso alle risorse DB (il meno possibile l'accesso approccio diritti).