Okay, now we've looked at many of the threats and many of the potential issues that come up with our applications, whether their Web based applications or for internal use for proprietary applications. So what is our solution? What is our answer? Well, our solution is to use good coding practices
and to implement what we refer to his defensive coating.
So the idea with defensive coatings were proactive, were using good secure coding standards. And ultimately, we want to make sure that regardless of what comes up, we're prepared. We're thinking about the potential misuse of our applications,
and we're implementing security to mitigate those external threats.
Other benefits of making sure we're using defense coding. We generally have better quality software. It's better written. It's tighter. It's we're closing those instances of vulnerabilities. The source code, because it follows those standards generally is more comprehensible,
anyone that's reviewing the code would have a better idea. Ah, and the code would be easier to understand. And ideally, we want our software to behave predictably. So if we follow good standardized coding practices, we will get predictable code. So defensive coating has a lot of benefits
over the next couple of sides will talk about a few elements of defensive coding.
Input, validation. Big, big, big. If we're gonna ask for input from the general public, we need to make sure that we validate that input is being legitimate. We do that by data typing. We limit the input, um,
length of our field. We have, ah, scripts that validate the input and check for things like that of control languages. But input validation is essential
sanitization of data. We can sanitize input as well as output in any time we talk about sanitization. We're talking about thinking something that could have malicious use or dangerous repercussions and translating it to a safe form.
So when we talk about information,
that could be very valuable. So, for instance, if I'm typing in the Social Security card are the Social Security number of an employee, for instance, maybe that information being stripped away masked out so that the information isn't there and isa service rep wouldn't have access to that information,
replacing user supplied input with safer alternatives, maybe more generic information. So we might query, um,
a user for like we might, for instance, ask a user for their full credit card number, but we might only store the last four digits. The last four digits really aren't confidential the way the entire credit card number is, so the user may supply us with the full context of the information, but we may only store
output. Sanitization What's coming out from our organization? What type of output before we present it to the clients So we want intensive coding is error handling exception handling air messages? So again, the idea here is that our errors
should indicate that there's been some sort of issue without
divulging any sort of internal vulnerability.
Ah, we want to make sure that they're non verbose because in the verbose modes, there's a lot of information that could be used in order to commit some sort of compromise.
Safe AP eyes We've already talked about the risks associated with using deprecate id AP eyes that perhaps have been exploited. A p I usages is huge, and this is what allows access from untrusted entities like applications toe access, trusted resource is like memory.
So we have to make sure that we're using safe and trusted Ap eyes.
We have to think about concurrency
and concurrency is simultaneous operations. You know, if you want to think about something like two users trying to open the same file on a network share will, often that file gets locked,
the first person to access that gets full access to the file and everything everybody else would have read only access. So file locking would be a way that we preserve issues with concurrency,
Um, making sure that we have operations that are single threaded. But again, resource locking is one of the best ways to deal with concurrency issues.
Token izing taking sensitive data with unique information and, uh,
really taking them and replacing them with the idea of a token that would still provide the authentication necessary. And you hear about tokens a lot with authentication, but getting rid of that sensitive data and replacing it with a token. So, for instance, um,
you know, I provide my authentication information, my password, my user name. I have access to all of these Different resource is. So instead of having to provide that information again and again, I'm granted an access token so that when I try to access resource is in the domain. It's that token
that gives me access. I don't have to provide those credentials again.
Nor does that token store my user name and password. That token is kind of a guarantee that I've authenticated properly.
Sandbox sand Boxing is all about applications when there are files, applications, anything that presents a potential vulnerability to the rest of the operating system. Like one of the things I think about. When I hear the term sandbox, I think about Java
unsigned Java, Java, apple. It's or designated to run in an area called the Sandbox. And that sandbox is the context in which this application can run, or this apple it can run. And basically that's the browser. So
basically, what we're doing is creating an isolation point from the host operating system
so that a specific untrusted application or code can run and still keep it safe from the rest on and ideally prevent the threat to the host operating system itself. So you see this a lot with Java,
any type of anti tampering mechanisms that we want to guarantee that what's downloaded is what's been received or when we look at this file, we get that assurance that it hasn't been modified Code signing for Web based applications like Javan Activex controls.
When we're downloading these, you know, job is very powerful. Activex very, very powerful.
When I'm downloading these apple, it's or these controls. I want to make sure that I trust the entity that's providing these files or this this code, and I want to make sure that the code hasn't been modified. So code signing, not downloading these files, if they aren't digitally signed is one way we get a good assurance against tampering,
a other ideas with controlling our software version, control code analysis and peer review.
So when we talk about secure processes for our software, make sure we do version ing. Make sure that we know the correct version of code, and also that we have capability of rolling back to previous versions if that's necessary. This is a good form of change management with our code
so that we understand,
um, that there's a a very specific process for making changes to the code, and each change should be tracked to a version
code analysis. That means we're gonna inspect the code. Is the code well written is it good quality are their internal weaknesses or their problems with the structure and the logic of the code.
And when we talk about static code analysis, that's the pure inspection of the code. And some of this will talk more about in the testing chapter. But ultimately, just in looking at the coach's playing code review,
does it? Is it well written? Is it well formed? Is it logical?
Dynamic code analysis means that we're actually gonna execute the code and analyze from that standpoint.
And then, of course, code review is a very systematic evaluation of the source code.
Ultimately, again, we're looking for good syntax. We're looking for structure. We're looking for logic. We want code, you know, it's very possible for code to run and be poorly written. So in code review, what we're looking for us. We're looking for code that doesn't run efficiently or even worse,
code that runs in an insecure or unsecure manner.
So when we're looking at code reviews and again, we'll talk about a lot of this in the section on testing code. But ultimately, you know when we're doing, uh, unit tests and we're doing code review. This may be part off the code design or the code writing process because we're doing it as programmers.
So we're looking for possibilities of injection non repudiation mechanisms.
Many of these areas that we've talked about are we providing sufficient cryptographic support? Um, do we have maintenance hopes left in the code for easy access? Is it possible to integrate a logic bomb? Um, are there synchronization areas? Does that leave room for race conditions?
So all sorts of things that we're looking for in code reviews
is it secure and isn't well written? Inefficient? That's our goal.
When we talk about secure builds, we're talking about more than just the developer. Creating secure code. It's is access to the code protected itself because of developer can write secure code. But if we don't restrict access to that code, anybody can come in and modify it.
So often we'll talk about the use of libraries. So
while the code is in the development process, it'll go in the developers library in his under strict lock and key management, perhaps by librarian
Um, we want to make sure that there's some sort of automation process that make sure that the build itself is hander handled in a secure manner.
All right, so all of this information, there's a lot of information in this chapter as well. There should be because this is the actual implementation. This is the actual secure coding element. This is, of course, where the rubber meets the road. This is where we implement the security that we've talked about up to this point.
So this is a really important chapter. We look at some common vulnerabilities.
We look at some mitigating strategies, we talk about some good concepts of coding and some potential flaws. So I would definitely encourage you to review this chapter and spend a good amount of time here because this really in the coding is where we prevent or least mitigate some of these threats that we've already talked about.
Following this chapter, we're gonna move into talking about secure testing
and creating an environment in which we can get assurance in the code that we've written