Il mio team utilizza attualmente ASP.NET con MS SQL Server per il nostro software. La sicurezza è diventata importante da quando ho iniziato, in cui ci sono vulnerabilità di iniezione ovunque.
Data l'attuale integrazione con Oracle e MS SQL, la decisione aziendale non è mai stata di utilizzare query parametrizzate. Questo naturalmente è stato un problema.
L'implementazione di Trova e sostituisci e la whitelist dei parametri ha ridotto notevolmente il problema.
Il mio unico problema è che ho letto molto su Unicode e altre codifiche che sono la causa di SQL injection. Non lo capisco abbastanza. Attualmente disinfettiamo tutto in questo modo:
Const pattern As String = "^[a-zA-Z0-9.=,:\s\\/\']*$"
term = term.Replace("'", "''")
If Not Tools.ValidString(term, pattern) Then
term = String.Empty
End If
Public Shared Function ValidString(ByVal source As String, ByVal pattern As String) As Boolean
If source = String.Empty Then Return True
Dim params As Text.RegularExpressions.RegexOptions = Text.RegularExpressions.RegexOptions.None
Dim regex As New Text.RegularExpressions.Regex(pattern, params)
Dim match As Text.RegularExpressions.Match = regex.Match(source, pattern, params)
Return match.Success
End Function
Qualcuno ha un esempio in cui è possibile utilizzare l'iniezione unicode / codificata o solo un semplice esempio in cui questa espressione regolare non riuscirebbe a impedire l'iniezione di SQL.
Grazie
Aggiorna
Per favore non ho risposte relative allo standard SQL Injection. Conosco già molto questo. INOLTRE, per favore, smetti di postare dicendo di non usare la sanificazione delle corde. Nell'azienda non vi sono risorse a zero per spostare tutte le query in query parametrizzate con ADO.NET, ma anche in logica per utilizzare ODP.NET se il client utilizza oracle. OWASP menziona l'uso di whitelisting di caratteri se la parametrizzazione è fuori questione, quindi, come nell'espressione regolare, sono ammessi solo pochi caratteri. Non sto inserendo i caratteri nella lista nera, perché questo è stupido.
Non è richiesta alcuna conformità per i dati in nostro possesso. La sicurezza è per l'integrità del database, in quanto sarebbe un incubo se il contenuto fosse cambiato.
Il nostro software è un'applicazione cloud CMS e DMS di grandi dimensioni in uno, in cui il 99% del software è utilizzato internamente e solo una minoranza è esterna e viene utilizzata solo per la revisione pubblica e per commentare i documenti.
Dalla mia nuova comprensione dell'iniezione Unicode. Può verificarsi solo se i dati vengono codificati prima di essere inseriti nella query e pertanto l'iniezione Unicode si verifica solo nelle applicazioni con globalizzazione dei dati. Sto passando i campi di stringa grezzi direttamente nella query di stringa dopo la sanificazione di cui sopra.
Posso avere solo una risposta da un esperto in iniezione, chi può eseguire il backup del mio reclamo in base al quale Unicode non si applica alle mie circostanze?