SLIDE 5 Examples of software problems – Cross site scripting
Exploit:
If the name parameter has a value such as Walter, the JSP will produce a message that says: Hello Walter! But if the name parameter has a value such as %3Cscript%20src%3D%22 http%3A//example.com/evil.js%22%3E%3C/script%3E the server will decode the parameter and send the Web browser this: Hello <script src="http://example.com/evil.js"></script>!
Affects typically Web applications, no matter what language they are written in.
Examples of software problems - Further examples
Integer overflows:
When numbers in a computation get larger than the storage space allocated for their type.
No direct exploitability, since they do not allow direct overwriting of memory or manipulation of execution flow, but are more subtle.
Indirect exploit, e.g., via buffer overflow when integers that overflow are used as array indices.
Affects mostly C and C++ code.
Bad error handling:
Error handling is obviously important since it is about dealing with situations in which the programmer’s expectations are violated.
A class of software problems, where myriads of things can go wrong and where exploitability depends on the concrete problem at hand.
Some examples:
Yielding to much information: Leak information about OS, server version, on logon
failure saying “user id not known”, etc.
Ignoring errors, misinterpreting errors, handling all errors the same: May mean to
do the wrong thing upon error. Example: try { doExchange(); } catch (RareException e) { // this can never happen }
See also http://www.owasp.org/index.php/Uncaught_exception
Examples of software problems - Further examples
Use of magic URLs and hidden form fields:
Some Web Shops use(d) to store session information such as the content of a shopping cart including prices of items in hidden form fields. This allows the attacker to edit the HTML code and , e.g., to adapt prices.
Some applications assume wrongly that URLs cannot be decoded or modified by users.
Improper use of SSL / TLS:
Don’t simply replace an existing network socket with SSL / TLS to make it secure.
Lots of things needs to be handled additionally, such as: Verification of CA signature on server CERT, check expiration date of CERT, check that target URL matches the one
- n CERT, check of CRLs, etc.
Different libraries will handle these things differently. E.g., one library will automatically check the expiration date, while another doesn’t.
The issue boils down to understanding how CERTs really work, and a bit of the underlying crypto.
Examples of software problems - Further examples
Use of weak password based systems:
Passwords are often weak, because poor choices and management by users. However, a weak implementation of a password authentication system can add many additional vulnerabilities.
Don’t store plaintext passwords, only store hash values or other validators, use salt (random values) when creating hashes to avoid brute force attacks.
Carefully choose password based remote authentication protocols. E.g., even when passwords are encrypted, the ciphertext could be replayed resulting in a successful login.
Example vulnerabilities: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-1505 or http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-0432
