TabletWise.com
 

Secure Deployment Concepts

12 minutes
Share the link to this page
Copied
  Completed
You need to purchase the class to view this lesson.
One-time Purchase
$99.99
List Price:  $139.99
You save:  $40
د.إ367.26
List Price:  د.إ514.18
You save:  د.إ146.92
A$128.22
List Price:  A$179.52
You save:  A$51.29
৳8,479.49
List Price:  ৳11,871.62
You save:  ৳3,392.13
CA$126.28
List Price:  CA$176.80
You save:  CA$50.51
CHF 88.62
List Price:  CHF 124.08
You save:  CHF 35.45
kr611.38
List Price:  kr855.96
You save:  kr244.57
€82.18
List Price:  €115.06
You save:  €32.87
£73.04
List Price:  £102.26
You save:  £29.22
HK$775.32
List Price:  HK$1,085.49
You save:  HK$310.16
₹7,302.63
List Price:  ₹10,223.98
You save:  ₹2,921.34
RM404.40
List Price:  RM566.18
You save:  RM161.78
₦37,946.20
List Price:  ₦53,126.20
You save:  ₦15,180
kr844.98
List Price:  kr1,183.01
You save:  kr338.02
NZ$138.24
List Price:  NZ$193.55
You save:  NZ$55.30
₱4,802.06
List Price:  ₱6,723.08
You save:  ₱1,921.02
₨16,033.39
List Price:  ₨22,447.39
You save:  ₨6,414
S$132.35
List Price:  S$185.30
You save:  S$52.94
฿2,996.70
List Price:  ฿4,195.50
You save:  ฿1,198.80
₺735.45
List Price:  ₺1,029.66
You save:  ₺294.20
B$520.01
List Price:  B$728.03
You save:  B$208.02
R1,504.12
List Price:  R2,105.83
You save:  R601.70
Лв161.11
List Price:  Лв225.56
You save:  Лв64.45
₩109,494.91
List Price:  ₩153,297.25
You save:  ₩43,802.34
₪318.70
List Price:  ₪446.20
You save:  ₪127.49
Already have an account? Log In

Transcript

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 has 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 compiled 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 XC on the end or.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 compiled 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. So 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 you know, it 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. Now, I bet a lot of you have 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 a I don't know an email address like we see here. So as we're entering this email email address, we want the application to validate that it's a good email address. And you've probably seen this where if you don't type in something that looks like an email address with an add sign 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 email address, and then you can even have it then query that domain like total sem.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 querying 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 he'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 create Roll 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 about 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 minified 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 minified. So the magnifier 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 at 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 the 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 600 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 inconsistencies 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 where you type in your first name, last name, email, address, whatever.

And we then process that in some way. So if we do this on the client side, what we're doing is not only do we fill out 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 encryption is not a big concern. Whereas if you're taking important chunks of a database, and sending it down to individual clients, then corruption 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 than 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 total tester online, showing just a few of the different types of JavaScript apps that we actually bring in to make our total tester 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 staying 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 info or personal health information. We almost always today go through aggressive encryptions. Anytime, if for example, we bring some data down to a client, I promise you on a good app, all that information is always encrypted. It's really not even.

There's not even an 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.

Sign Up

Share

Share with friends, get 20% off
Invite your friends to TabletWise learning marketplace. For each purchase they make, you get 20% off (upto $10) on your next purchase.