Part 2 Explanations
Video Activity
This lesson covers software errors that the instructor considers worthy of an honorable mention but are not in the top 25. These are: • CWE 391: unchecked error condition/Ignored condition/Ignored Error • CEW 717: Information leakage and improper error handling • CWE 359: exposure of private information (privacy violation) • CWE 396: Declaration of...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson covers software errors that the instructor considers worthy of an honorable mention but are not in the top 25. These are: • CWE 391: unchecked error condition/Ignored condition/Ignored Error • CEW 717: Information leakage and improper error handling • CWE 359: exposure of private information (privacy violation) • CWE 396: Declaration of Catch for Generic aka Overly Broad Catch Participants also receive code samples that are made to combat these issues. The instructor also briefly touches upon the lab assignment for the unit which focuses on CWE 362: concurrent execution using shared resource with improper synchronization (race condition).
Video Transcription
00:04
hello and welcome to secure coding course. My name is Sonny wear, and we're now entering into the section that I like to call honorable mentions these honorable mentions, our software errors that are quite prevalent and very high and severity.
00:23
And so, even though they do not fall within the
00:27
the OAS Top 10 or the Sands Top 25
00:32
they certainly are worth mentioning.
00:34
We're going to review four of those right now,
00:38
so the ones we're gonna look at include unchecked air conditions, ignored conditions or ignored errors,
00:46
information leakage and improper air handling,
00:50
exposure of private information
00:53
and the declaration of a catch for generic exception, something I like to call overly broad catch.
01:02
So let's start with our 1st 1 c w e 3 91 unchecked air conditioned, ignored condition or ignored error.
01:10
Now this is the situation where you have what's referred to a squashed exceptions
01:17
and the problem with squashed exceptions. If you look at the sample code on the slide is that you have an exception that occurs. If you see in the tri catch block,
01:29
you can see the catch is looking for some sort of custom exception.
01:34
But inside of the actual catch block.
01:37
Nothing is being done, so this exception is actually not getting logged or getting recorded in any way
01:45
now. The problem with this technique is that it does provide
01:49
a great opportunity for Attackers to perform several different actions without ever being noticed. So an exception could be thrown in a situation where maybe they're trying to do a buffer overflow or something like that.
02:07
And so that exception doesn't even get recorded or caught. And so it would go completely unnoticed.
02:15
The other ramification of doing squashed exception blocks is that it makes debugging issues in production very, very difficult. So if you do have a situation of a runtime exception occurring,
02:32
and you basically do not record what that issue waas, it can give you a lot of problems in trying to troubleshoot the
02:43
or pinpoint where that problem occurred. So the defense here is that you're always gonna wanna log your exceptions. Now, whether you log them to a file or to a council doesn't really matter. The point is that you are actually recording that, in exception, has occurred.
03:01
Even if you end up propagating that exception.
03:04
Up the call stack At least you have done it at the point of offense so that
03:12
troubleshooting will not be
03:14
a cz much of an issue when you go to your production environment. Now, the next software air we're gonna take a look at for honorable mentions a C W e 717 information leakage and improper air handling. This is actually quite a large group of different airs and issues.
03:34
I'm going to just point out some information leakage examples as well as improper air handling so falling under information leakage this could be related to memory leaks. It could also be related to having error messages that are too verbose,
03:53
that actually give clues as to the programming language you're using
03:59
the specific air. Sometimes we've even seen Stack traces, you know, that provide
04:06
everything that the program just did in and how it felt to that to that location. So all of those things make, um,
04:16
make four memory leakage situations.
04:20
The example of code that I have there
04:24
with the char bites and the allocation being done is basically an unfortunate event where you allocate memory on the stack
04:35
that is too big, and unfortunately, there just isn't enough memory available on the stack for the size that you requesting,
04:46
and so that could certainly cause memory leaks and can lead to the buffer, overflow type situations that we had spoken about before.
04:57
The other area is improper air handling.
05:00
So one of the examples and there are many you should have some sort of
05:08
consensus on your exception exception handling methodology inside of your application, first of all.
05:15
But another problem is if you have debug statements turned on in production. Now the reason why this is a problem. Not only is it a drain to resource is to be locking all of that information,
05:31
but it can also provide great clues
05:34
to your Attackers about your entire program flow.
05:39
So if we take a look at the defenses,
05:42
we know that we definitely need to turn off debug statements in production. And a lot of times companies will have ah, some sort of guard are some sort of toggle switch that they can turn on and off
05:57
for producing Debo statements in production.
06:00
And of course, the reason for that would be four troubleshooting
06:04
now in regards to the memory leaks, in the example that we saw. Uh, obviously you want to free any memory that you are completed working with, and then you also wanna have some kind of memory sizing check
06:21
And to make sure that you do throw an exception, should you not have enough memory available
06:30
now, the next area is C W E 3 59 exposure of private information
06:35
in a lot of the HP Fortify scans. It could come up as privacy violation.
06:42
And this is where you've got some sort of sensitive data or what the scanner thinks is sensitive data that is being exposed now in a lot of scans, I've seen this, too, to actually be benign.
06:58
Maybe the variable name is seems like it would be sensitive data,
07:02
but in actuality, it isn't that thing that it looks like it is. For example, SS ends if you have a variable
07:11
that has the letters s sn.
07:14
The scan may actually flag that when, in actuality, you're not actually handling the SN
07:21
now in the code that I'm showing right here,
07:25
this line gets flagged because it looks like that we're doing an MQ Siri's call with some connection and we're grabbing a record that or we're placing a record on the Q that has some sensitive information.
07:44
Now it could be that the record is named as a send something or credit card something, and so that is the reason why it was flagged.
07:54
And so once again, it it could be a false positive with something the developer needs to take a look at. So our defense is for privacy. Violation would be, too. Obviously, check for those false positive type situations. If it is determined that there is a privacy violation, then
08:13
encryption solutions would need to be implemented.
08:16
And, of course, the three main areas of protection would include the data when it's at rest or when it's in a database, the data while it's moving around in that's data in motion. And then, of course, the data and use. And that would be our in memory data.
08:35
Now, the next
08:35
software error to mention is C W E. 3 96 This is declaration of catch for generic exception or otherwise known as an overly broad catch.
08:48
Now what you'll see in the example is we have a catch block
08:54
that is just going to catch exception
08:58
Now. Exception is the parent class for all types of exceptions.
09:05
And while this is valid code and it will compile
09:09
and yes, we are indeed doing something with the exception in inside of the catch block.
09:16
The problem is that you're catching every type of exception, and you're actually going to lose Ah, lot of very pertinent information that you
09:28
could have caught had you been more explicit in the type of exception caught.
09:33
And so, really, you need to have multiple catch statements specific to each type of exception that is being thrown, and then that way you can handle it more properly.
09:48
So if we take a look at this example, we can see that now we have a catch block that actually catches a file not found exception.
09:58
And so that is very specific to a particular situation. And so we would know exactly what the problem is exactly which file it is that is throwing this exception et cetera. Now, one last example that we're going to go through,
10:15
which actually corresponds to the lab assignment is
10:20
concurrency problems with threads
10:22
in particular race conditions.
10:26
So in this example, we actually have two threads that we're going to be talking about.
10:33
So this is our block of code and it's written and pearl.
10:37
Basically, when the first thread comes in,
10:41
let's say that that threat is requesting a transfer amount of $80.
10:48
Well, then a call is to get the balance from the database. Now the balance from the database for Thread one happens to be $100
10:58
so the calculation is done here, and there's a new balance of $20
11:03
so that new balance of $20 should be sent to the database. However,
11:09
due to some high volume of traffic or io interruption to the database, there's a delay in sending that new balance. Now inter thread number two
11:22
Threat number two decides. Yes, I want to transfer amount of $1
11:28
but in the get balanced from database, instead of actually getting the balance associated with thread number two, it gets the balance associated with thread number one. And so the $100 balance is then assigned to thread number two, which means that the calculation of the new balance is just
11:48
100 minus one, which is 99.
11:52
And so the new balance that gets set to thread number two is actually $99. And so you can see how, because there is no separation here of threads that they can easily be
12:09
overwritten do due to this concurrency issue.
12:13
Now, the defense here is that you want to actually add either lock or a synchronization block or some way in which each thread can perform these tasks or these functions
12:31
mutually exclusive from each other.
12:33
So you only want to allow one thread to perform all of these actions at a time.
12:41
And so one of the ways that you could do that is using theme You, Tex and Lock.
12:46
And there are synchronization blocks available in almost every programming language.
Up Next
Instructed By
Similar Content
