10:20 Injection
Occurs when un-trusted data is sent to an interpreter. The interpreter is then tricked into executing a hostile command. This can result in data corruption or in data access without the appropriate permissions.
“Little Bobby Tables”
Some examples of this are SQL injection, LDAP (Lightweight Directory Access Protocol) injection, and the like. Essentially, these are situations where you enter data into a user interface, and then the data gets concatenated or otherwise placed into a command that is sent to a data source without cleaning it up.
To avoid, never trust un-sanitized user input, especially when using string manipulation to build a command from it. As an example, use parameterized queries for SQL.
13:10 Broken Authentication
This occurs when an application incorrectly implements authentication or session management procedures to compromise things like passwords, keys, or session tokens.
An example of this might be a reuse of stolen credentials (such as passwords).
“The website goes, oh yeah I’m going to impersonate a baby duck and just believe you when you say that you’re mommy.”
To avoid this, build features to check for weak passwords, limit the number of incorrect login attempts. You can also go a bit further with this and implement multi-factor login.
14:55 Sensitive Data Exposure
Occurs when an application doesn’t correctly protect access to sensitive information. This allows data theft and/or damage to the data on the system.
An example of this would be a situation where data isn’t being encrypted while in transit or at rest on the server.
To avoid this, limit the amount of sensitive data that you store and make sure that it is encrypted whether it is being moved between machines or stored on one.
18:00 XML External Entities (XXE)
XML processors can often reference external entities, which, if compromised, can lead to all kinds of problems, from disclosure of confidential data, to denial of service, and other nasty things like port scanning.
An example of this might be an xml file referencing an external entity (usually specified by a URI) that has been compromised. The contents at the compromised location will then replace the referenced entity. Because the processor may be running in a different security context, this can result in data disclosure, or allow an attacker to pivot to attacking higher value targets.
To prevent this, try to disable DTDs (document type definitions) to reduce the attack surface. Also, look for existing libraries that are safe against these problems, instead of trying to implement your own.
21:15 Broken Access Control
This occurs when an application doesn’t strictly enforce constraints around what a user is allowed to do. Attackers can abuse failures in this to conduct operations for which they don’t have permission.
An example of this might be an application that allows users to edit data belonging to another user by mistake.
“It’s like in martial arts where you throw a hand one way and then you punch them with the other one.”
To address this, security constraints should deny by default, instead of allow by default. In addition, you should log access control violations, and alert administrators of problems.
24:20 Security Misconfiguration
This occurs because of the misconfiguration of a system that allows a malicious user to do something that shouldn’t be allowed. This can range from incorrectly configured access control to overly verbose error messages that expose sensitive data. It can also refer to having an old version of the software running that isn’t caught up on patches.
An example of this might be something like the fairly recent breach of several thousand unsecured MongoDB databases that were sitting out on the open web.
To mitigate this, make sure that your machines stay patched and carefully follow best-practices instructions for configuring your assets for security. Remember that not all software packages ship with sensibly secure defaults.
28:45 Cross Site Scripting (XSS)
This occurs when you include un-trusted data in a web page for other users without proper validation or escaping. This could be as innocuous as allowing a user to put HTML tags in things seen by others and could escalate as far as allowing a user to execute javascript in another user’s browser.
“You didn’t have WYSIWYG editors back then so you put your HTML in the comments, and you could put a