OWASP Top Ten
Podcast: Play in new window | Download (49.5MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
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 <script> tag in there.”
An example of this might be a forum on a banking website (please don’t ever do this.) A hostile user makes a post in the forum that includes <script> tags. Subsequent users who load the page will run the script tags, which collect bank account details and post them to an external address. Banks have long since stopped doing dumb things like this, but this is a decent example.
“You’re not going to the beach, but your money is.”
To mitigate this, never, ever, take raw input from an un-trusted source and display it in the browser. This is very similar to the Injection vulnerability that we discussed earlier, except instead of going inward towards your server, it goes outward towards your clients.
33:15 Insecure Deserialization
Serialization is the process of taking a structure in memory and converting it into a format that can be stored. Deserialization is the process going in the other direction. For instance, deserialization occurs when a payload is sent to a web endpoint in JSON format. The server will load that payload into a data structure, rather than a stream of bytes.
Like the XXE vulnerability listed above, this vulnerability type abuses the way data is handled when deserialized by tampering with the data. In the case of JSON, they might (for instance) alter the user id being sent in a payload in order to impersonate another user.
To mitigate this, don’t trust user input. This not only means not trusting the user when they tell you what their id is, but also enforcing things like strict type constraints, using data integrity checks on data sent over the wire, logging deserialization failures, and running deserialization operations in an environment with lower privilege environments.
37:00 Components with known vulnerabilities
Most people build applications and make at least some use of third party components and libraries. This vulnerability type occurs when you use a component that has a vulnerability that is already known. Note that this doesn’t mean “known to you” – it can also mean “known to some hostile government somewhere”.
“Do I go into the lion’s cage to get away from the flesh eating zombies outside…welcome to WordPress.”
An example of this is any number of WordPress plugins that have known and serious vulnerabilities in them. If you use these plugins in your site (as we did in ours a while back), people can write scripts to try and find sites that have the insecure plugin and then attack them en masse. That’s exactly what happened to us with a couple of plugins last year.
To mitigate this, stay on top of security advisories for the software you are relying upon. Also, try to limit your use of third party libraries that don’t seem to do a good job of patching their issues. Yes, you have to vet libraries before you use them, it’s part of being a responsible adult.
42:45 Insufficient Logging and Monitoring
This doesn’t sound like a vulnerability, but insufficient logging and monitoring of your application can result in you failing to notice an attack while it is occurring. This makes it less likely that you will notice in time to mitigate the damage.
An example of this might be a server whose login system is under attack, but that fails to record incorrect authentication attempts. You might notice such an attack if it were logged, but if it wasn’t, you’d have no idea someone was trying to break in.
Treat logging as a first class citizen in your development environment. Having logs for the administrators is as important as a having a UI for the users. That sounds like an ivory tower approach, but it will make your application easier to debug and monitor if you do so, saving more than enough time to pay for itself.
IoTease: Project
Smart Brew Automatic Tea Kettle
This electronic tea kettle has a 1.2L capacity. While not as classic as a stove top kettle, it’s fully programmable with settings for ideal temperature, brewing time, and even an automatic start. For the tea connoisseurs it has two filter baskets to hold loose leaves or tea bags. It also has a pump function that lets you set the steep time and prevents leaves from just sitting in the water. It continuously pumps the water through the baskets to get the perfect steep. Finally it has the ability to control temperature and keep tea warm without burning the tea leaves.
Tricks of the Trade
Remember that you are writing for multiple audiences. You aren’t only writing for the users who are using your GUI, but you are also writing logs for your administrators, developing api endpoints (and commandline interfaces) for people writing scripts, providing library code for other developers, and even providing a good installation/deployment experience for devops folks who are putting your app on a server. Understand your audience and build things with them in mind; don’t let yourself believe that you are only writing for a single audience, because that is observably not true.
Your XSS discussion reminded me a lot of an article on injecting malicious code into NPM – there are some good reasons to minimize the features and dependencies you allow on a site. https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5.