Introduzione
La piattaforma CAST Imaging permette di eseguire l'analisi approfondita di un’applicazione eseguendo una scansione statica del suo codice sorgente.
In questa analisi delle applicazioni è possibile impostare l'opzione ‘Security Dataflow’ che permette di rilevare le vulnerabilità di tipo User Input Security. A questo scopo infatti, è stato implementato un apposito algoritmo che genera un flusso di dati utilizzato per rilevare le variabili, che vanno dall’utente fino alle risorse, senza essere prima sanificate; ovvero le situazioni che permettono a malintenzionati di ‘iniettare’ dati che possono danneggiare le applicazioni.
Vulnerabilità ‘User Input Security’ - Chi le definisce
Le vulnerabilità di tipo ‘User Input Security’ sono considerate di rilevanza grave (CWE – Common Weakness Enumeration) dai principali istituti internazionali che lavorano per la sicurezza del sw, ovvero ad esempio:
- OWASP 2021, nelle top 10 con categoria A01 e A03 (https://owasp.org/Top10/A01_2021-Broken_Access_Control/
e https://owasp.org/Top10/A03_2021-Injection/ - CWE (Mitre), nelle 2021 CWE Top 25 Most Dangerous Software Weaknesses (https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html)
- STIG, CAT I (High) (https://www.stigviewer.com/stig/application_security_and_development/)
Security Dataflow – Metriche rilevate
La funzionalità di Security Dataflow consente di rilevare le seguenti vulnerabilità di sicurezza (vedi Ref. 1):
- SQL Injection (CWE-89)
- Cross-Site Scripting (CWE-79)
- LDAP Injection (CWE-90)
- OS Command Injection (CWE-78)
- XPath Injection (CWE-91)
- Path Manipulation (CWE-99)
- Avoid Log forging vulnerabilities (CWE-117)
- Avoid uncontrolled format string (CWE-134)
- Trust Boundary Violation (CWE-501)
- Sensitive Cookie in HTTPS Session Without 'Secure' Attribute (CWE-614)
- Use of hard-coded credential (java, C#, VB.Net languages) (CWE-798)
Al momento le tecnologie supportate sono JEE e .NET.
Come funziona il Security Dataflow
Questa funzionalità ha un meccanismo interno, il “Dataflow Engine”, che si attiva durante la fase di analisi; l’ engine di CAST Imaging genera una variabile ‘contaminata’ che è utilizzata per tracciare l’input dell’utente non sanificato. Quindi il motore traccia le vulnerabilità tramite dati contaminati che fluiscono dal punto d’ingresso (input utente) fino ai metodi destinazione. Nella figura seguente viene mostrato un possibile scenario di “SQL Injection”
Metodi e Librerie Predefiniti
Alcuni noti metodi di input/target sono già predefiniti e presi in considerazione da CAST per rilevare le vulnerabilità di User Input. Ne riportiamo qui alcuni esempi:
(per il dettaglio completo https://doc.castsoftware.com/display/AIPCONSOLE/User+Input+Security+-+predefined+methods).
Tecnologia JEE
Metodi di Input
[rt.jar]java.io.Console.readLine()
[rt.jar]java.io.Console.readLine([rt.jar]java.lang.String,[rt.jar]java.lang.Object[])
[rt.jar]java.io.Console.readPassword()
[rt.jar]java.io.Console.readPassword([rt.jar]java.lang.String,[rt.jar]java.lang.Object[])
[rt.jar]java.applet.Applet.getParameter([rt.jar]java.lang.String)
….
Metodi Target (es. di Command Injection)
[rt.jar]java.lang.Runtime.exec([rt.jar]java.lang.String)
[rt.jar]java.lang.Runtime.exec([rt.jar]java.lang.String)
[rt.jar]java.lang.Runtime.exec([rt.jar]java.lang.String,[rt.jar]java.lang.String[])
[rt.jar]java.lang.Runtime.exec([rt.jar]java.lang.String,[rt.jar]java.lang.String[])
[rt.jar]java.lang.Runtime.exec([rt.jar]java.lang.String,[rt.jar]java.lang.String[],[rt.jar]java.io.File)
…
Tecnologia .NET
Metodi di Input
[System.Windows.Forms]System.Windows.Forms.Control.get_Text()
[System.Windows.Forms]System.Windows.Forms.ScrollableControl.get_Text()
[System.Windows.Forms]System.Windows.Forms.ContainerControl.get_Text()
[System.Windows.Forms]System.Windows.Forms.AxHost.get_Text()
….
Metodi Target (es. di Command Injection)
[System]System.Diagnostics.Process.Start()
[System]System.Diagnostics.Process.Start([mscorlib]System.String,[mscorlib]System.String,[mscorlib]System.Security.SecureString,[mscorlib]System.String)
[System]System.Diagnostics.Process.Start([mscorlib]System.String,[mscorlib]System.String,[mscorlib]System.Security.SecureString,[mscorlib]System.String)
[System]System.Diagnostics.Process.Start([mscorlib]System.String)
…
Oltre i metodi vengono prese in considerazione anche alcune note librerie per il controllo della sicurezza.
Librerie
OWASP ESAPI
OWASP Java Encoder Project
OWASP Java HTML Sanitizer
Microsoft Anti-XSS
Apache Commons StringEscapeUtils
Spring HtmlUtils
Tutte le SQL parameter binding
Risultati prodotti
Vengono prodotti due tipi di risultati.
1) Risultati intermediSono presentati nella Console di prodotto e forniscono una panoramica di base dei risultati
Rispetto alle vulnerabilità di sicurezza rilevate sono riportati:
- Rule: la vulnerabilità
- Targets, riporta il numero di chiamate ai metodi che accedono alle risorse considerate per la regola violata
- Sources, indica il numero di chiamate a metodi in cui le variabili vengono popolate con l'input dell'utente
- Detected Flaws, è numero di flussi, non preventivamente sanificato, che dai metodi con input dell'utente arriva fino ai metodi che accedono alle risorse
- Black-boxes, è il numero di Black-box file caricato per la regola. E' creato automaticamente (ma può anche essere creato e aggiunto manualmente) per generare codice sorgente ‘esterno’ che venga anch’esso scansionato e quindi preso in considerazione, dall’analizzatore in fase di analisi del codice.
2) Risultati finali
Sono presentati nella Engineering Dashboard di prodotto. Qui viene riportata la lista di tutte le violazioni di Sicurezza rilevate. La lista delle violazione può essere esportata in formato .xls.
Navigando le interfacce della Dashboard si arriva al dettaglio del file e della singola riga in cui è stata rilevata la violazione.
Comments: