QA Friday 2016-Jan-15

How can you prevent denial of service attacks? Most of the techniques you’ll use to prevent a DOS attack are network related. This podcast is about programming so I’ll explain some things you can do that will make your software more resistant to attack. This episode continues the discussion from last week and builds on the same silly story. We’ll go back to the regular QA Fridays next week. The audio goes into more detail but if I had to sum up the main lesson from the podcast, it would be this: Don’t let a client machine spend a small amount of work that causes your program running on a server to spend a large amount of work unless you are sure that the request is legitimate. And even then, you will want to spread this work so it’s even. Don’t let even legitimate customers overflow your services. You want to validate requests as soon as possible. This first check may not even be a complete check. All it needs to do is some simple sanity checks to make sure that a request looks somewhat legitimate. If you find something suspicious or obviously wrong, then also don’t spend a lot of time preparing a long response. Either completely forget about the request or send a short and quick response. Listen to the full episode or you can also read the full transcript below. Transcript There’s always a balance between security and ease of use and openness that you need to find when programming. In the story, the restaurant was open to the public and that let attackers send bins that the workers had to deal with. The first thing you can consider when designing a program is who needs to use it? Does it really need to be open and available to the public? Maybe it’s only needed by employees within the company. Even if it needs to be more widely available, is it possible to ask visitors to register or sign-up for service before being allowed access? Maybe you can setup two services. One is for the general public to try and get a feel for what value you can provide before agreeing to become a paying customer. Your paying customers can then move off of the free service and enjoy an even higher level of service. A DOS attack relies on hundreds or thousands of computers all trying to use your service at once. If you take this approach, then only your trial version will be attackable because the bad guys are not going to become paying customers. I shouldn’t say that only the trial version is attackable, the attackers will have to use different methods to try attacking the paying service. Even though this is still a bit network related because it involves splitting your service into two separate services, I mention it with programming because it will affect your design. You’ll need to plan for this and probably write some amount of code to help support it. Anything you can do that limits which portions of your service can be attacked at any given time will help you fight these attacks. In general, DOS attacks are more successful when attackers can spend very little time and resources that cause your program to spend a lot of time and resources. The variety of DOS attacks is huge because each can be customized to cause your program to maybe spend a lot of processing time, or maybe overflow the memory you have set aside to handle incoming requests, or maybe cause your program to spend time reading or writing information to disk, or maybe your program passes the request to another server running some other program that you wrote. The attackers could be going after your database, or your identity providers, or trying to confuse your load balancers. This is why DOS attacks are so difficult to fight. And why writing smart software that keeps the potential for a future DOS attack in mind might just allow you to save your company some day. If DOS attacks are trying to get you to spend a lot of time and resources, then it seems that a very good thing you can do as a programmer is to reject re