In this module, we ‘ve looked at the threats, potential issues that comes with our applications. Whether it be web-based applications or those for proprietary processes and procedures, either case, not only is the threat an important issue but so is the strategy to mitigate against such threat. We’ve talked about that a little, however, more needs to be spent on the concepts associated with defensive coding. Defensive coding is the philosophy and the system of using good coding practices, to implement secure coding standards, being prepared concerning the potential misuse of our applications and generally having a better quality software.
Defensive coding is where we are closing the gap between our creation, our application we are designing and developing and those possibilities for threats or attacks. The source code follows these better standards which also include coding for security purposes. If we’ve followed standardized, logical code and practices, then generally we’ll have predictable code. On the concept of defensive coding, there are at least ten different ways we will discuss in this last part of module 4. They include such processes as input validation, sanitization of data, others such as version control, code analysis and peer review. So, this section is primarily a discussion about these various processes.
Input Validation is where we are not only asking for a segment of input of data from the public at large, but also we ask about validation of the information to ensure its legitimacy. Data typing and so limit the input length of the fields is one way to validate input. Another way is the have scripts that validate the input and check for things like data control languages. Either way, making sure the input is validated is a huge asset, whenever you are asking the public to input information into your data fields.
Sanitization of data is where we are sanitizing the input and output of data. In this day and age of malicious software or either input/ output that has a malicious use, the sanitization of data translates that piece of information into a safe form, so that we can still access the information piece without the malware still attached. For example, the social security number of an individual and then the information is masked or stripped away so that it isn’t right there. A service representative who was working on the machine, wouldn’t have actual access to that information. Another way to help with sanitization of data is to have more generic kinds of information rather than having the user supplied information. Last, while the supplier may provide a full context of information, we wouldn’t store but just a small portion of that output. So, the question to ask is what is coming out of our organization. And to check our output before we present it to the clients. So, to really deal with the sanitization of the output data, overall, we want a mix of coding, error handling, exception handling, error messages, and so this way whenever there are errors or error messages, there’s not necessarily an indication of the internal vulnerability. There’s just the indication of the fact of being a problem.
Safe API’s is when you are using the alternative to the deprecated API’s, and instead are using the safe version. The usage is huge and what allows access from untrusted entities to access things on your machine, like memory. We have to make sure that we are using the safe kinds of API’s rather than the deprecated kinds. When using simultaneous operations, that is referred to as concurrency. We have to think of the idea of allowing others access to the file, but by file locking then they cannot make any modifications or changes, and they receive a Read-Only file type, and then we don’t have to worry about the concurrency issues. Resource – locking is one way to deal with concurrency issues and they relate to making sure that you are working with safe API’s.
Tokenizing is when there is sensitive data and replacing those unique sets of information with a token and still provide the authentication necessary. Authentication information, password, username, and so on are the kinds of sensitive information, that can be tokenized. Instead of having to provide that information again and again, then can instead present the website token. So, then when presenting the token, within the domain, then they have access to the webpage. The credentials are within that token. The token is a kind of guarantee that you’ve authenticated properly, however, if an attacker gets a hold of the token, then they have the information to a thing bigger than themselves and are able to get into the webpage, get into the sensitive information and access it as if they were the user. As long as developers and designers go through the processes properly, then there should still be a low rate of compromise. It is a better situation as relative to the constantly providing the credentials every time, because the raw data is much, much easier to compromise than the tokens, at this current time.
Sandboxing relates to the fact that any of the applications, especially web applications, represent potential vulnerabilities to the rest of the operating system. Sandboxing is where you have an area of isolation so that if there is a untrusted application or you’re not sure if it’s going to have malicious ware or just what, that you can have it run in the sandbox and then have your host OS away from the specific application or code, and thus preventing threats to the OS itself. Java tends to have in their applets, which is an isolated portion where they the application can run, keeping the OS safe in case somehow the code of the applet has become corrupted or have acquired embedded code, of malicious intent. The sandbox is the area the applet is allowed to run.
Conjoined with the sandboxing idea, is that when anytime an anti-tampering mechanism has been developed with our application, we want to also make sure that what’s been downloaded has been received. So, assurances that there isn’t any modification of the code and the person has just done the download per given instructions. Java is very powerful for this purpose. Something that is also powerful for this purpose is Active X. So code signing, not downloading unless digitally signed, are ways to have good assurances against tampering.
Other ideas with controlling our software, version control, code analysis and peer review.
We want to make sure we know the correct version of code, we also should have the capability of rolling back the previous versions if necessary. This is a good way for management of our cde and “control the software”. Keeping track of the previous versions, and then also following good standard practices for making changes to the code. Each should be tracked to a version. Version control again is where you are keeping track, perhaps storing as separately unique versions. Then code analysis is where we inspect the code. What’s the level of quality and does it do the job it is supposed to, or are there weaknesses within the code that cause problems in the structure and the logic of the coding. Pure inspection code is static code analysis. We’ll talk more about static code in a later chapter, but important to mention here as a way to analyze what’s happening with the coding we’ve developed. Peer review or code review is where there is a systematic evaluation of the source code to locate syntax issues and weaknesses. It is possible for the code to run by be filled with weaknesses. As programmers, of course we’re evaluating on whether it runs or not, but also we’re looking at possibilities of code injection, non-repudiation mechanisms, are there areas of cryptographic support and maintenance/ easy access, does it leave room for race conditions and so on. All these things look for while performing a code review. Basically, is it secure and efficient. So, overall, in the other ideas associated with defensive coding are associated with controlling the software, keeping track of the versions and version control, code analysis and then peer or code review.
Secure builds is when the developer is creating secure code. It is helping to protect the code itself, by limiting the access to the internal coding. On the other hand, if the secure code is created and is great but then access isn’t restricted, then anyone can modify it. So, associated with this concept is the idea of libraries. But that will come in another chapter.
The secure builds is just one method of defensively coding. There are other techniques as well, which include input validation, sanitization of data, safe API’s, and a whole host of others for example, controlling our software, version control and peer reviews. All these techniques and more help to make coding that is secure, roust, and well-structured and logical.