Sicurezza Applicativa: classificazioni degli errori di codifica

Tenete a mente queste tre classificazioni degli errori di codifica.

Quella che preferisco:

7 Kingdom (in order of importance)

1. Input Validation and Representation
2. API Abuse
3. Security Features
4. Time and State 
5. Errors
6. Code Quality
7. Encapsulation
8. Environment

Quella a cui guardo con interesse ma che mi lascia perplesso:

OWASP Top 10 2007

• A1 - Cross Site Scripting (XSS)
• A2 - Injection Flaws
• A3 - Malicious File Execution
• A4 - Insecure Direct Object Reference
• A5 - Cross Site Request Forgery (CSRF)
• A6 - Information Leakage and Improper Error Handling
• A7 - Broken Authentication and Session Management
• A8 - Insecure Cryptographic Storage
• A9 - Insecure Communications
• A10 - Failure to Restrict URL Access

Quella che rende più l'idea:

19 Deadly Sins

1. Cross Site Scripting (XSS) problem
2. SQL Injection
3. Command Injection
4. Format string problem
5. Buffer overrun
6. Integer Overflow problem
7. Trusting Network Name resolution
8. Failing to protect network traffic
9. Failing to store and protect data securely
10. Failing to use cryptographically strong random numbers
11. Improper file access
12. Improper use of SSL/TSL
13. Use of weak password based system
14. Unathorized key exchange
15. Race Conditions (TOCTOU)
16. Use of magic URLs and hidden from fields
17. Failure to handle errors
18. Poor usability
19. Information leakage

Inutile dire che se proprio dovessi scegliere una regola su tutte, sceglierei la validazione dei dati immessi dall'utente. Dobbiamo infatti considerare il dato immesso dall'utente non fidato per definizione. Ma attenzione a non risolvere il problema con una black list di caratteri non ammessi. Il problema non è in quello che conosciamo ma in quello che NON conosciamo. Quindi è meglio utilizzare un approccio White-list e filtrare l'input ammettendo solo caratteri o token ammissibili per la nostra applicazione e scartare tutto il resto.

In un prossimo post approfondirò comunque l'argomento della revisione di sicurezza del codice.

I post precedenti sull'argomento Sicurezza Applicativa:

• Sicurezza Applicativa: introduzione
• Sicurezza Applicativa: riferimenti
• Sicurezza Applicativa: linee guida
• Sicurezza Applicativa: best practice per i casi di abuso e i requisiti di sicurezza
• Sicurezza Applicativa: il modello STRIDE per i pattern di attacco
• Sicurezza Applicativa: best practice per l'analisi dei rischi architetturali

Qualche blog link:

• SDLC on the shoulders of giants
• Cigital’s Touchpoints versus Microsoft’s SDL
• Security is not all about Security Updates
• Securing Existing Code