An application developer must use many different techniques to keep their code secure. In this video, you’ll learn about stored procedures, obfuscation, input validation, memory management, and more.
<< Previous Video: Provisioning and Deprovisioning Next: Software Diversity >>
Creating an application is always a balancing act between, how much time it takes to create the app and the quality of the final product. We want to always have an application that is able to do all of the things we need, but we also want to have the application be secure.
We also have to think about the entire process for creating the application, and things like the QA process, take a lot of time as we begin testing and verifying different features of the application. And of course, eventually, some type of security vulnerability may be found inside of that application, and that would need to be patched before someone was able to exploit that vulnerability.
One way to make an application more secure is to create stored procedures for your database calls. For example, this is a SQL database call, where it is a select command, where we’re asking for data from the database, from a particular table in the database, and a particular value within that table.
If the client using this application realizes that these requests are being made directly from the application to the database, they may be able to modify the information within this query and gain access to information that normally would not be available.
To avoid this, a stored procedure is created on the database server itself. So instead of having the client send this information to the database server to run that query, that query is instead stored on the database server, and the application just sends a message saying, CALL, and then the name of the stored procedure to run.
Using this format, the client is not able to modify any of the parameters of that database call. They can only choose to either run that stored procedure or not run that stored procedure. This would mean the app developer would need to create stored procedures for every database query that could be called by that application. And by doing so, they’ve created an application that’s much more secure, and it prevents the users from making any direct database calls.
Another method that application developers use to make their code a bit more secure, is to use obfuscation. Obfuscation is a way to take something that normally is very easy to understand and make it so that is very difficult to understand. From an application developers’ perspective, they’re taking, application code that they’ve written, and they’re changing that code to make it very difficult to read by other human beings.
Fortunately, the computer understands the obfuscated code perfectly. It only prevents human beings from being able to read through that code and understand what’s going on. The obfuscated code makes it more difficult for someone to look at the software, and determine where any security vulnerabilities might be.
Here’s an example of code obfuscation. This is a single line of code in PHP that puts on the screen a message that says, Hello world, so it’s echo, a quote sign, Hello World, in the quotes, and a semicolon. This exact same function can be represented by this amount of code. This is obfuscated code, that has taken a very simple echo message and put this on the screen, and turned it into something that’s extremely difficult for a human to look at, and understand that that’s what’s going to happen.
If you were to run this code with PHP on your computer, it would be able to output at the bottom, Hello world. So all of this obfuscated code, which looks nothing like the original echo command, ends up performing exactly the same function.
Another security issue might arise when an application developer chooses to reuse code between different applications. This is a very common thing for application developers do, because they’ve spent all that time, to create code that performs a particular function in one program, and now they need exactly that same capability in another program, so they simply copy and paste that between applications.
However, if that code has a security vulnerability associated with it, copying that code to multiple applications, now spreads that security vulnerability into all of those other apps. Another challenge developers have, is to make sure that the code that they’ve put into the application, is actually, performing a useful function.
There can be instances, where a code has been added to a particular application, it runs through the logic of the application, creates calculations, stores variables in the application, and then none of that information is used anywhere else in the app. We refer to this as, dead code, where there has been a code put into the application, it is running through and processing some type of logic, but the ultimate results of that logic aren’t used anywhere else within the app.
Any type of code added to an application, adds the potential for a security issue. So it’s important to make sure that any of the coding that we’re doing, is following the best practices, and avoiding any type of code reuse, or dead code.
One of the main functions of an application is for us to put data into the app, and then we get some type of result back out of the application. One of the ways that attackers is able to identify vulnerabilities of an application, is to find a place where the input is not properly being validated.
For example, if an application is asking for a zip code, then it’s expecting a certain set of numbers, over a certain range. And in many applications, there are multiple places for data input. This might be a file that’s uploaded, it might be putting information into a form, and all of this information needs to be validated.
The application should be checking through all of the data to make sure it’s in the right format, and if it’s not the right format, it should add any corrections. We refer to this as, normalization. For example, a zip code should only be a certain number of characters long, and it should usually consist of a series of numbers or a very specific combination of letters and numbers.
If the information being input into the application does not match what’s expected from the input validation, then the application should put a message on the screen to the user to correct the problem, or there may be logic within the application that’s able to fix the input without any other type of user interaction.
Attackers will use fuzzers and other techniques to try to find a way around the input validation. So, it’s very important that the developers address any type of input going into their applications. The application developer can choose to validate this input in different locations.
When commonplace is on the server itself, we call the server-side validation, because the data is sent into the server, and code on the server, is able to look through the data, and validate that the input has been done correctly. This would prevent the user from making changes to the data before it gets to the server, in the hopes that it would somehow get around the validation process.
Some applications will validate the data on the client-side before it’s sent to the server. The end-user application will validate the input on the client’s machine, and then it will determine if that is appropriate to send to the server. This might speed things up a bit since you’re not waiting for the server to evaluate the input, and then provide you with any type of feedback since all of those checks are being made on the local machine.
Although, it’s common to use both client-side validation and server-side validation. Using server-side validation is usually considered the safer alternative. And if you only had to choose between one of these, you would probably choose server-side validation.
When we’re using an application, we don’t often have to think about how the memory is being used within the app. That’s a major concern for the developer. They have to keep track of where all these variables are stored, and make sure that all of that information is available to the application. We also have to think about this from a security perspective, because users will input different types of data into the application, and that information will be stored in memory.
Malicious users will try to get around some of these input validations, to put their own data into the memory of your computer. A good example of one of these security problems would be, a buffer overflow. In certain situations, the user might be able to send more data than what was expected and overflow a section of memory.
This might cause the application to crash, or it might cause the application to provide the user with additional access, that they would not normally have. This is why it’s sometimes better for the application developer, to write their own logic for the application, rather than use some type of third-party library, which could be insecure.
This is an ongoing challenge for application developers because they write all of this logic for their application, but there may still be certain features or functions that need to be added, that they have not written any code for. One way to speed up this process is to use code that has already been written by someone else.
These would be third-party libraries or information, that’s contained within software development kits or SDKs. This extends the functionality of the programming language, it speeds up the development process and gets the application built that much faster.
Unfortunately, these libraries are written by someone else. So we are not sure exactly how secure the library might be. It might be that library is very secure, or it may be that there are vulnerabilities within that library, and using that library in our application could open up our application to an exploit.
If you’re an application developer, and you’re trying to decide if you should use an application library, or not, make sure you’re doing your research and you know exactly how secure that library is.
In many applications, we’re inputting a lot of sensitive data. We could put in our name, our address, our birthday, our social security number, information about our family, our medical information, and so much more. That information needs to be secure. We need to make sure that we are encrypting this data when we’re storing it into some type of database or storage system.
If we’re sending that information across the network, we need to make sure it’s sent in an encrypted form as well. And if we’re displaying this information on the screen, we may want to filter out some of this information or display it in a way that’s more secure.
Any time we have data going into an application, or being sent from that application, we need to check it and make sure that any type of data is not being exposed. By doing this, we can be assured that all of the data will be protected from the time we put it into the application, until the time we see it on our screen.
Application developers are constantly making changes to their application code, and it’s very common for them to use version control. This means that they could write some software, check it into a version control system, and then next time they’re ready to update this code, they can keep track of anything that may have changed between one version and another. This is a feature, of course, it’s not just used for application development. You’ll see this in operating systems, file systems, and wikis, and other locations as well.
Version control can also be very effective from a security perspective. It’s useful to look at a particular file today, and compare it to what that file was a week ago, or a month ago. If we’re trying to determine if a file may have been changed over time, using version control, is a great way to make that determination. Saving this information for historical reference can be a valuable security tool, but you want to make sure that a third party is not able to gain access to that sensitive information.