Software Security/Group 3/Owasp Top10

Uit Werkplaats
< Software Security‎ | Group 3
Versie door Robbert van den Berg (overleg | bijdragen) op 24 jun 2011 om 09:24 (Improper error handling)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken

OWASP Top Ten

The OWASP 2010 Top Ten consists of:

  • A1: Injection
  • A2: Cross-Site Scripting (XSS)
  • A3: Broken Authentication and Session Management
  • A4: Insecure Direct Object References
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Security Misconfiguration
  • A7: Insecure Cryptographic Storage
  • A8: Failure to Restrict URL Access
  • A9: Insufficient Transport Layer Protection
  • A10: Unvalidated Redirects and Forwards

Earlier versions also included

  • Malicious File Execution
  • Information Leakage and Improper Error Handling

Thus although it is currently not in the top ten, 'Information Leakage and Improper Error Handling' is still an important topic.

After our research, we can say the following about this point concerning phpBB2:

Information leakage

Information leakage concerning logging and error handling is present in the phpBB2. An example is that sometimes the die() function is used to prevent unauthorised access. This makes it possible to distinguish between a 404 (not found) and not authorized which in turn allows version number authorization. Another example is that fatal errors are not captured and printed to screen, which can give attackers information. It is possible to define your own error handling function (see http://ru2.php.net/set_error_handler) which handles fatal errors in a better way.

Improper error handling

We could not find a lot of 'improper error handling', but that can also be caused by the fact that there is little error handling: when an error occurs a user-friendly messages is printed to the screen and thats that, there is no logging or notification of administrators etc. In a rare case the software can be forced to output a username of an user (which could also be looked up in the memberlist) as part of an error message, so maybe with additional tinkering more sensitive information can be leaked from error handling. In DEBUG mode more sensitive information is leaked but this mode should be disabled in production environments.