È male non convalidare la lunghezza dell'input dell'utente al campo di testo sul lato server. Può portare a tali vulnerabilità come buffer overflow e altro?
Penso che dipenda dal linguaggio di programmazione dell'applicazione. Quindi, descrivilo per PHP, Java, .NET, Ruby ecc.
Dipende dal linguaggio di programmazione utilizzato. Tieni presente che se si verifica un overflow del buffer per una lingua che gestisce le stringhe, tale overflow si verifica generalmente a livelli che non è possibile raggiungere. Penso che potresti essere più preoccupato per le situazioni in cui passerai la stringa in un altro dominio (come un database, un modulo basato su C, ecc.) A questo punto, sarebbe prudente assicurare la lunghezza e altri dati le caratteristiche del tipo sono appropriate per la destinazione.
Ricordo di aver letto le specifiche originali per HTTP (penso che fosse lì) che un buon server dovrebbe essere flessibile in ciò che accetta, ma deve essere rigoroso in ciò che ritorna. La stessa cosa può essere applicata qui: sii il più flessibile possibile sull'input dell'utente che ricevi, ma assicurati che sia il più sicuro e protetto possibile prima di spostarlo in un altro dominio.
Mentre è vero che ciò che accade durante un overflow del buffer ha molto a che fare con il contesto di sviluppo in cui si verifica l'overflow (cioè quale linguaggio, quale sistema operativo e persino quale tipo di hardware) - è anche un bene generale fai pratica per controllare la dimensione e la sintassi.
Sarei stupito se qualcuno avesse il tempo di scrivere per ognuna delle lingue che menzioni ... Conosco i capricci di alcune di queste lingue, ma non tutte, per colpire in modo adeguato tutte le lingue di loro in una singola risposta sarebbe un livello abbastanza impressionante di competenza.
Posso dire per un linguaggio gestito - come Java e (credo --- no il mio strong) .Net - stai guardando (in generale) ramificazioni meno terrificanti che in un linguaggio più vicino al bare metal (C, C ++ ). Un overflow del buffer in una lingua con memoria gestita dovrebbe consentire al programma di allocare la memoria man mano che le informazioni arrivano e gestirle in un modo un po 'eloquente (ad un certo punto!). L'overflow veramente classico è quello in cui il programmatore non ha assegnato correttamente la matrice di caratteri e i dati nell'overflow sono filtrati in un altro segmento del programma.
Detto questo - anche in Java un buffer overflow può causare risposte non intenzionali. In un linguaggio gestito, potrebbe essere che si succhia il processo di memoria allocata causando rallentamenti. È possibile che la macchina si "apri in errore" se non è stata configurata correttamente, è possibile produrre output imprevisti in qualsiasi meccanismo di persistenza dei dati utilizzato dal programma. Tutto ciò è vero indipendentemente dalla lingua.
Un controllo delle dimensioni generali in prima linea è semplicemente una buona pratica di programmazione. Perché non rimbalzare dati errati prima di lavorare di più? Stai salvando i cicli della CPU, il runtime e la memoria persistente e proteggi il back-end. La sicurezza a strati è solo un buon modo per andare.
Convincerei sempre tutto semplicemente perché ricevevo un input non valido e mostravo un bel errore che provare a far cadere guerra e pace in un varchar (200) e guardare le cose diventare stordito per l'utente finale.
Per quanto riguarda i buchi di sicurezza? Tipicamente no, perché come detto, che è al di fuori del regno dello scripting (costrutti linguistici di basso livello), comunque scommetto che ci sono circostanze in cui è possibile ottenere un'applicazione per ritagliare i dati, spezzare il DOM e consentire l'eventuale iniezione (completamente disattivata comunque, in testa) e molti altri modi complicati per utilizzare a proprio vantaggio la mancanza di limiti di lunghezza.
Leggi altre domande sui tag web-application attacks appsec