Now the security plus really likes talking about secure coding techniques.
Basically if we're writing applications What are some of the security issues that we need to keep in
mind as we're actually generating that code.
So there's a number of these that are listed.
And you know what I'm just going to go right down the list as actually printed within the objectives
for the security plus.
There's no particular order to them so let's just get them all.
However before we start talking about these I do want to make sure we're clear on one very important
concept and that is the idea of comp. versus runtime code.
For years what we would do is you would write code and you would write it in whatever programming language
you chose.
You would then run that code through some type of compiler and then you would generate executable code
and anybody who's seen a piece of code with each Ex-Sea on the end or dot com if you go that far back
understands that these are programs that are run on your system that run through your RAM.
Most applications that we run on the Internet today are runtime applications.
So what we'll have is like something built into our web browsers that can read basically highly refined
code.
In this case it's not compiled though it's not executable.
It is interpreted by whatever client you have running.
So if you have for example a web browser you can run javascript.
That's because your web browser is able to read javascript scripts and then actually run them.
So there's a big difference between comp. where you have executable code versus runtime code.
So if we're going to be in the web we're probably talking about runtime code and things like javascript
for example would be a great example of that.
Let's start off with proper error handling.
Any application is going to generate errors from time to time.
So if we have a web app in particular you've got some choices here.
First of all you want the application to recognize errors and put up a nice screen that says like oops
or sorry or something like that so that it doesn't do something evil.
Now here's an example of a bad error handling and I'll bet a lot of you've seen errors something like
this what you're looking at here is that the actual application doesn't know what to do with this error
and it has.
If we're lucky it's locked up.
If we're unlucky it could do evil things like allow us to have root access or actually get into the
system behind it itself.
So proper error handling is absolutely critical.
Next is going to be proper input validation.
Every application there is has some kind of input some kind of dialog box.
So let's say for example I've got an application that wants to actually have you enter.
I don't know an e-mail address like we see here.
So as we're entering this e-mail address we want the application to validate that it's a good e-mail
address and you've probably seen this where if you don't type in something that looks like an e-mail
address with an app side or something like that the application kicks back and says Try again.
You could go even further than that.
You could have somebody enter an e-mail address and then you could even have it then query that domain
like total dot com and verify it's a legitimate domain.
So that's really up to you in terms of what you want to do with input validation.
Next is normalization.
Databases can be big onerous items.
And one of the things we want to avoid is replication of data.
When we normalize a database we use tools like for example indexing to take what could be just one database
and turn it into two or more as needed to allow us to have zero or little replication of data and more
efficiency within the database itself.
Next are stored procedures.
Now if you're going to query a database you should be doing things like for example proper input validation.
Now if we just leave it to the individual pieces to handle all this we could run into trouble.
So what we often do is we insert a stored procedure between those which are queering and the database
itself.
So what will happen is that the individual items will then query the stored procedure and then the stored
procedure will do input validation whatever needs to be done and then we'll send that to the database.
Stored Procedures protect databases.
Next is going to be encryption.
Now we got to be careful with encryption because we're going to talk about encryption again in a minute.
But what I'm talking about right here is really what we're calling code signing your code itself is
precious.
We don't want people to be messing with the code if we have updates we want to be able to control those
updates.
So what we do is we actually digitally sign our code so that whoever's getting that code can know that
it's in good order and it's in good shape.
Remember we'll talk more about encryption shortly.
Next is obfuscation or camouflage the same thing.
There are situations where you don't really want to go through a full blown encryption of code but you
don't want to make it that easy for people to for example reverse engineer it and copy whatever you've
come up with.
So if you take a look here here's an example of a man a fire tool used primarily with javascript.
If you look on the left hand side you can see the actual javascript code itself on the right hand side
is the exact same code this time using a minute fire.
So the minute fire gets rid of excess English words it compresses spaces and carriage returns and leaves
pretty much nothing more than the runtime code itself.
Next is going to be code reuse and well we'll throw this in the same time dead code.
All this means is that in any application if you can reuse known good code do it.
So that basically means from a coding standpoint you want to break down as many functions as possible
into individual pieces so that different parts of your code can continue to call it over and over again
as opposed to writing the same thing two or three or four or six hundred times with the risk of error.
On the same token dead code is simply code that we're no longer using a lot of programmers are tempted
to keep dead code in their applications.
The motivation being they might need it or something like that a good rule is get rid of dead code.
Cut it out.
The danger to dead code is that sometimes bad guys can take advantage of little inconsistency in your
code to do naughty things.
So go ahead and just take that dead code out of your systems.
The next issue is going to be server side versus client side execution and or validation to make this
more clear.
Let's set up a situation where we have a server and a client.
Now in this particular situation the server is serving up some web application and the client has a
web browser up actually accessing that web application.
And let's say one of the things that this web application does is it has a dialog box or type in your
first name last name email address whatever.
And then process that in some way.
So if we do this on the client side what we're doing is not only do we thought the form on the client
side but we'd also perform for example input validation and then generate the query and just send the
query over to the database on a server side.
All we're doing in this situation is we fill out the form and then we send all the data.
Good or bad.
Over to the server and then the server performs input validation and generates the query.
There are good and bad aspects to both of these and it really depends on what you're trying to do.
Keep in mind that if you do stuff client side you're putting a lot of onus and a lot of security on
the individual clients and you tend to be sending a lot of code to the clients on the server side.
You tend to put a lot of work on the server.
Things like encryption for example really come into play here depending on if you're just sending a
little bit of data to the client maybe encryptions not a big concern.
Whereas if you're taking important chunks of a database and sending it down to individual clients then
scription can be a really really big deal.
Next is memory management.
The bottom line is that all of these apps use memory.
Now I'm not so worried about on the server side although that can be an issue but this really does become
an issue on the client side.
It is trivially easy for us to make big ugly applications that eat memory.
So not only do we make programs that eat memory but we can actually inadvertently put in memory leaks.
Anybody who remembers Firefox five or six years ago maybe a little more in that it was a bit notorious
for eating up all the RAM in your system.
Whenever you ran some types of Web Apps.
Firefox is great now.
I love Firefox.
The process of memory management usually can be a little bit involved but it has to do with a lot of
testing.
Next is use of third party libraries and software development kits all web apps use lots of third party
libraries.
Here's a little snippet from the total seminars told testor online showing just a few of the different
types of javascript apps that we actually bring in to make our total testor online work.
For example here's one little guy and this little guy called chart his job is to do one thing.
Help us make pretty charts like these.
The downside to third party libraries is that they can be big security issues.
A lot of times bad guys will not be able to attack your app itself but they'll find a weakness because
a lot of these apps are used by hundreds of thousands of people.
So if a bad guy can find a weakness in one of these third party libraries well they can take advantage
of lots of people not because you've written a bad app but because a third party library that you lead
on has a weakness.
The bottom line here is a lot of stain on top of things and lots of patching and making sure you're
aware of weaknesses and vulnerabilities as they appear.
The last one is data exposure and that's where I really want to talk about encryption.
If you have data that is a part of your app some of that data has risk of exposure.
And our job as developers is to reduce if not eliminate any risk of that data exposure especially if
it's personally identifiable information or personal health information.
We almost always today go through aggressive encryptions any time.
If for example we bring some data down to a client I promise you a good app.
All that information is always encrypted it's really not even.
There's not even excuse to not do that anymore.
So make sure if you have data exposure you're going to be using lots and lots of encryption.
We covered a lot of different secure coding techniques in this episode.
Now look Security plus is not trying to turn you into a code head but it is expecting you to understand
some of the basic concepts of all of these very important secure coding techniques.