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.
And so, even though they do not fall within the
the OAS Top 10 or the Sands Top 25
they certainly are worth mentioning.
We're going to review four of those right now,
so the ones we're gonna look at include unchecked air conditions, ignored conditions or ignored errors,
information leakage and improper air handling,
exposure of private information
and the declaration of a catch for generic exception, something I like to call overly broad catch.
So let's start with our 1st 1 c w e 3 91 unchecked air conditioned, ignored condition or ignored error.
Now this is the situation where you have what's referred to a squashed exceptions
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,
you can see the catch is looking for some sort of custom exception.
But inside of the actual catch block.
Nothing is being done, so this exception is actually not getting logged or getting recorded in any way
now. The problem with this technique is that it does provide
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.
And so that exception doesn't even get recorded or caught. And so it would go completely unnoticed.
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,
and you basically do not record what that issue waas, it can give you a lot of problems in trying to troubleshoot the
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.
Even if you end up propagating that exception.
Up the call stack At least you have done it at the point of offense so that
troubleshooting will not be
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.
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,
that actually give clues as to the programming language you're using
the specific air. Sometimes we've even seen Stack traces, you know, that provide
everything that the program just did in and how it felt to that to that location. So all of those things make, um,
make four memory leakage situations.
The example of code that I have there
with the char bites and the allocation being done is basically an unfortunate event where you allocate memory on the stack
that is too big, and unfortunately, there just isn't enough memory available on the stack for the size that you requesting,
and so that could certainly cause memory leaks and can lead to the buffer, overflow type situations that we had spoken about before.
The other area is improper air handling.
So one of the examples and there are many you should have some sort of
consensus on your exception exception handling methodology inside of your application, first of all.
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,
but it can also provide great clues
to your Attackers about your entire program flow.
So if we take a look at the defenses,
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
for producing Debo statements in production.
And of course, the reason for that would be four troubleshooting
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
And to make sure that you do throw an exception, should you not have enough memory available
now, the next area is C W E 3 59 exposure of private information
in a lot of the HP Fortify scans. It could come up as privacy violation.
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.
Maybe the variable name is seems like it would be sensitive data,
but in actuality, it isn't that thing that it looks like it is. For example, SS ends if you have a variable
that has the letters s sn.
The scan may actually flag that when, in actuality, you're not actually handling the SN
now in the code that I'm showing right here,
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.
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.
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
encryption solutions would need to be implemented.
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.
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.
Now what you'll see in the example is we have a catch block
that is just going to catch exception
Now. Exception is the parent class for all types of exceptions.
And while this is valid code and it will compile
and yes, we are indeed doing something with the exception in inside of the catch block.
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
could have caught had you been more explicit in the type of exception caught.
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.
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.
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,
which actually corresponds to the lab assignment is
concurrency problems with threads
in particular race conditions.
So in this example, we actually have two threads that we're going to be talking about.
So this is our block of code and it's written and pearl.
Basically, when the first thread comes in,
let's say that that threat is requesting a transfer amount of $80.
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
so the calculation is done here, and there's a new balance of $20
so that new balance of $20 should be sent to the database. However,
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
Threat number two decides. Yes, I want to transfer amount of $1
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
100 minus one, which is 99.
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
overwritten do due to this concurrency issue.
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
mutually exclusive from each other.
So you only want to allow one thread to perform all of these actions at a time.
And so one of the ways that you could do that is using theme You, Tex and Lock.
And there are synchronization blocks available in almost every programming language.