An application is only as secure as its programming. In this video, you’ll learn about security coding, validating input, cross-site scripting concerns, and how to handle exceptions.
<< Previous Video: FuzzingNext: Application Configuration Baselining and Hardening >>
If you’re developing or writing your own software there are a number of concepts you have to keep in mind to make sure that your code is going to be secure. One of the challenges you have, though, is the process and the time that it takes to make that secure is going to extend your development cycle. So you often have this balancing act between speed and security.
When you’re working with your code, and you want to be sure it is as secure as possible, there’s usually a quality assurance process. You have somebody test your code to make sure that it’s going to be secure. And it’s very often not just one type of test, it’s many types of tests that you run through just to make sure that you’re doing the right things to keep your code as secure as possible.
Eventually, in most software, we’re going to find a vulnerability somewhere. It’s going to be with the software. It’s going to be what the platform that it’s on. And the bad guys, when they find that specific problem or that specific vulnerability, they’re going to take advantage of it. So we want to be sure, from the very beginning, we’re writing code that is as secure as possible.
A very common development process is one where we validate the input that is going into our systems. We determine what the expected input might be. And we compare it with what we get. If we’re asking someone for name, if we’re asking someone for an address, maybe a serial number, there’s probably an exact string or set of strings that we might expect. And we want to be sure that if somebody inputs data that we really do check the data, just to make sure it’s exactly what we were expecting.
We want to go through our entire application, document every possible input method, look at forms, look at fields, look at the types of information we’re putting in there, and we want to check all of our input. If we have a field for a zip code we know that zip code should only be a certain length. We know that in certain countries there should only be certain characters, and they should only occur as the third or fourth character in the entire zip code.
We should perform exactly all of those checks. We should leave nothing to chance. Because if we end up having a validation problem the bad guys may find a way into our application.
And as we also saw in one of our other videos, you can use fuzzers to try to manipulate that input, to try to throw a lot of random data at your application just to see what’s going to happen. Is your application going to have a fault? Is there going to be an error? Is the application going to stop running?
There’s all kinds of interesting input and results you can get from a fuzzer. So if you have the flexibility to do that, that’s a great way to validate that input.
In our video on cross-site scripting we talked about and demonstrated how painful it can be if one of your applications happens to have an embedded script in there, and it starts giving back information to the bad guys about what people are doing with that app. So of course we want to check for embedded scripts. We want to validate the input for those, just to make sure there’s not something in there we weren’t expecting.
We also want to check for cross-site request forgeries. We did some of this as well, where we were able just to have– with a one click attack– be able to see the session and identify the session IDs, and then use those session IDs and essentially ride on top of someone’s existing sessions and use their same authentication methods to be able to grab that application and see information in there. So make sure that your session IDs and the methodology we use to authenticate people is encrypted and protected in our applications.
Another important consideration when coding is making sure that we have certain routines in play should an error occur. We can’t possibly plan for everything, and we should always have something that is a generic message that appears when a problem happens. There should be a graceful process. You shouldn’t just get a standard error that pops up as part of the compiler or the script language that you’re using.
So if you lose a network connection, the server hangs, a database suddenly is not available to you, should have a certain message– or at least a generic message– that pops up so that you’re able to understand what’s going on. There are mishandled exceptions, like this one here, where you see the application itself failed and you’ve got a generic Microsoft Visual C++ Runtime library.
So now I happen to know what application was used to develop this app. I know what coding system was used there. And I may be able to take advantage of that with some of my vulnerabilities.
You want to be sure to get rid of any of those default messages. Make it something very generic, or something that is in your pop up screen, so that the bad guys cannot understand what that underlying architecture might be. Use some of those scripting methods, use some of those coding methods, and your software and your applications that you develop are going to be as secure as possible.