236: Filesystem: How To Avoid Security Vulnerabilities. Part 2.

Run your program with the least permissions possible. Listen to the full episode to learn how this applies to your application and what role the filesystem has. We’re not talking about imaginary mind control beams anymore. This is real and something you need to be aware of when writing your code. All it takes is a simple link in the filesystem for an attacker to exploit. You can also read the full transcript below. Transcript You have a choice of how you want to run your program. And by that, I mean which user account will be associated with the running application and what permissions will it have? It’s usually a good idea to run with as little permissions as possible. Because an attacker has a goal in mind and doesn’t care how that goal is accomplished. As long as the attacker gets the desired outcome, then any available method to achieve that is open for use. Think of it like this. Imagine that an attacker has a secret mind control weapon that can be used to to take over one employee at your company. Do you think the target will be the junior assistant office manager? Or the company president? Now maybe the attacker doesn’t have an opportunity to use the mind control on the president and has no choice but to choose somebody else. If the junior assistant office manager falls under the control of the attacker, then any documents that person has access to will now be available to the attacker. And anything that was not granted to the office manager will remain unavailable to the attacker. The same thing applies to your application. Only we’re no longer talking about an imaginary mind control weapon. This is real. You must consider what will happen if an attacker manages to take over your application. Anything that your application can do will be available for the attacker. Now, you might wonder, so what? We’re not talking about people with unlimited ability to do things. We’re talking about an application with code that has already been written. A computer can only do what the code tells it to do. And since you didn’t write anything bad into your application, then so what if an attacker gains control. What’s the worst they could do? After all, you didn’t write anything into your application that tells it how to send documents to a foreign country. There’s at least three things to consider. First, what might seem like a perfectly normal feature in your application could actually be far worse when put to use in creative ways you never intended. Maybe your application doesn’t know how to send documents overseas. But it might know how to open documents and save them someplace else. Someplace that an attacker already has access to and can then download them and send the document anywhere. Second, you don’t know what intent the attacker really has. Your application might not be the ultimate goal but is just one step in a larger scheme. What might seem harmless by itself could be damaging when used together with other attacks. And third, along the same lines as the unknown intent. Maybe the attacker isn’t interested in stealing anything. Maybe the goal is to just add extra work to the computer so that it slows down to the point that it becomes unusable. If your application happens to be running on an important server which is handling the logins of all the company employees, then bringing that server down could cause everybody to be unable to login to their computers. This is called a denial of service attack. Once your application is under the control of an attacker, you’ll be glad that it has as few permissions as possible. Because anything your application can do will now be available to the attacker. I’ve mentioned already that an attacker can use code that you programmed into your application to do things unintended. But nobody puts code into their application that turns over control to an attacker. And since computers can only do wh