Secure Coding Concepts – CompTIA Security+ SY0-401: 4.1

Secure Coding Concepts – CompTIA Security+ SY0-401: 4.1


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.

1 thought on “Secure Coding Concepts – CompTIA Security+ SY0-401: 4.1”

  1. howdy, professor. quick question: what is the difference between the two security + sy0-401 playlists? one seems to have 73 videos, the other seems to have 184. are there any differences besides video count?
    thank you for your time

Leave a Reply

Your email address will not be published. Required fields are marked *