OWASP Top Ten
Web security vulnerabilities are expensive and massively destructive. They can result in identity theft, illegal content ending up on your server, or even having your machine be used to attack other people's computers. In addition, many of the worst vulnerabilities are not entirely obvious when you are trying to write code to actually accomplish something.
"The goal is to spread awareness and help minimize these risks."
The Open Web Application Security Project (OWASP) is a worldwide not-for-profit organization focused on improving the security of software. OWASP issues software tools and knowledge-based documentation on application security. They put together a document containing the top 10 security vulnerabilities compiled through consensus of security experts from around the world.
Security is hard and is a field unto itself. Many developers have made terrible security decisions that created tremendous amounts of damage, and many will continue to do so. However, if you learn some about how some of the basic attacks work, you are far more likely to build a secure application than someone who doesn't know. This episode was a high level discussion of some very basic things about these types of attacks and you should spend some time learning more about these if your code has any security concerns at all (aka, if your code isn't completely composed of Hello World samples on github).
Episode Breakdown
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