This was the singlemost effective tactic Kevin Mitnik used, according to himself. The name sounds cool, but it really is about getting people to spill the beans and give the attacker security sensitive information in the old fashion way, that only requires people skills (as opposed to advanced computer hacking skills).
Allegedly, this is still the most effective way of breaching security, as it relies on the weakest link in the security chain: the human.
Enter Open Web Application Security Project (OWASP)
Here is their Top 10 Web Application Security Risks for 2010 list, with brief descriptions for each :
- A1: Injection: an attacker manages manages to inject commands into various subsystems (i.e. database server), tricking them into executing commands that were never intended by the developer. The SQL injection subtype is a classic example.
- A2: Cross-Site Scripting (XSS): an attacker runs code from his own system into your visitor’s browser, which offers the attacker a lot of options to do harm to your visitor and your system.
- A3: Broken Authentication and Session Management: quite simply, incorrectly or poorly (or sometimes plain shitty) implemented user management functions, opening a whole world of opportunities for the attacker.
- A4: Insecure Direct Object References: for example, letting everybody now that your system directory’s name is “system”, or having database table names or keys exposed in HTML/JS. Without having additional control mechanisms in place for access to those resources, this poses a great risk.
- A5: Cross-Site Request Forgery (CSRF): a malicious system (website) can force the victim’s browser, that is presumably still logged-on to your website, to send HTTP requests to your website; your unprotected website will “think” these requests are legitimate, since they come from the browser of an logged-on user, and contain the proper authentification information and session cookie reference. However, your user’s account is now being used by an attacker.
- A6: Security Misconfiguration: simply put, failing to setup a secure configuration for the system, even if the security mechanisms are in place, i.e., the system can enforce strong user passwords, but the configuration tells it not to.
- A7: Insecure Cryptographic Storage: weak/broken (md5) hashes, unsalted hashes, improperly salted hashes, weak/broken encryption ciphers, encrypting without Initialization Vector (IV), etc..
- A8: Failure to Restrict URL Access: say you are displaying some sort of inline administrative interface on a page, only if a user is logged-on.That interface (links, buttons, forms or whatever) allows the user to modify stuff within the system. However, if you don’t redo the access control check again in the scripts that do the actual modifications, the URLs provided by your administrative interface can be forged, and a non-authenticated attacker can have his way with your system.
- A9: Insufficient Transport Layer Protection: this is about network traffic, and involves support for weak algorhithms, use of invalid or expired certificate, incorrect use of certificate.
- A10: Unvalidated Redirects and Forwards: redirects and forwards are inherent in any web application, but they require careful data validation to determine the destination page, otherwise visitors may be redirected to malicious websites, or attackers to pages not normally accessible on your system.
As OWASP advises, don’t stop at ten! Also, make sure to download their Top 10 as PDF, containing a lot more detail, and, for your general well-being in the future, do bookmark the OWASP website.
Click-jacking/UI redressing is relatively new threat that I’ve yet to encounter. It requires specific counter-measures.