developer training

February 6, 2017 by James Jardine

Security Tips for Copy/Paste of Code From the Internet

Developing applications has long involved using code snippets found through textbooks or on the Internet. Rather than re-invent the wheel, it makes sense to identify existing code that helps solve a problem. It may also help speed up the development time.

Years ago, maybe 12, I remember a co-worker that had a SQL Injection vulnerability in his application. The culprit, code copied from someone else. At the time, I explained that once you copy code into your application it is now your responsibility.

Here, 12 years later, I still see this type of occurrence. Using code snippets directly from the web in the application. In many of these cases there may be some form of security weakness. How often do we, as developers, really analyze and understand all the details of the code that we copy?

Here are a few tips when working with external code brought into your application.

Understand what it does

If you were looking for code snippets, you should have a good idea of what the code will do. Better yet, you probably have an understanding of what you think that code will do. How vigorously do you inspect it to make sure that is all it does. Maybe the code performs the specific task you were set out to complete, but what happens if there are other functions you weren’t even looking for. This may not be as much a concern with very small snippets. However, with larger sections of code, it could coverup other functionality. This doesn’t mean that the functionality is intentionally malicious. But undocumented, unintended functionality may open up risk to the application.

Change any passwords or secrets

Depending on the code that you are searching, there may be secrets within it. For example, encryption routines are common for being grabbed off the Internet. To be complete, they contain hard-coded IVs and keys. These should be changed when imported into your projects to something unique. This could also be the case for code that has passwords or other hard-coded values that may provide access to the system.

As I was writing this, I noticed a post about the RadAsyncUpload control regarding the defaults within it. While this is not code copy/pasted from the Internet, it highlights the need to understand the default configurations and that some values should be changed to help provide better protections.

Look for potential vulnerabilities

In addition to the above concerns, the code may have vulnerabilities in it. Imagine a snippet of code used to select data from a SQL database. What if that code passed your tests of accurately pulling the queries, but uses inline SQL and is vulnerable to SQL Injection. The same could happen for code vulnerable to Cross-Site Scripting or not checking proper authorization.

We have to do a better job of performing code reviews on these external snippets, just as we should be doing it on our custom written internal code. Finding snippets of code that perform our needed functionality can be a huge benefit, but we can’t just assume it is production ready. If you are using this type of code, take the time to understand it and review it for potential issues. Don’t stop at just verifying the functionality. Take steps to vet the code just as you would any other code within your application.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

June 3, 2016 by James Jardine

Understanding the “Why”

If I told you to adjust your seat before adjusting your mirror in your car, would you just do it? Just because I said so, or do you understand why there is a specific order? Most of us retain concepts better when we can understand them logically.

Developing applications requires a lot of moving pieces. An important piece in that process is implementing security controls to help protect the application, the company, and the users. In many organizations, security is heavily guided by an outside group, i.e.. the security group or 3rd party testers.

Listen to the podcast of this topic

Looking at an external test, or even a test by an internal security team, often the result is a report containing findings. These findings typically include a recommendation to guide the application team in a direction to help reduce or mitigate the finding. In my experience, the recommendations tend to be pretty generic. For example, a username harvesting flaw may come with a recommendation to return the same message for both valid and invalid user names. In most cases, this is a valid recommendation as it is the reason for the flaw.

But Why? Why does it matter?

Working with application teams, it quickly becomes clear the level of understanding regarding security topics. The part that is often missing is the Why. Sure, the team can implement a generic message (using the username harvesting flaw above) and it may solve the finding. But does it solve the real issue? What are the chances that when you come back and test another app for this same development team that the flaw may exist somewhere else? When we take the time to really explain why this finding is a concern, how it can be abused, and start discussing ways to mitigate it, the team gets better. Push aside the “sky is falling” and take the time to understand the application and context.

As security professionals we focus too much on fixing a vulnerability. Don’t get me wrong, the vulnerability should be fixed, but we are too focused. Taking a step back allows us to see a better approach. It is much more than just identifying flaws. It is about getting the application teams to understand why they are flaws (not just because security said so) so they become a consideration in future development. This includes the entire application team, not just developers. Lets look at another example.

An Example

Let’s say that you have a change password form that doesn’t require the current password. As a security professional, your wheels are probably spinning. Thinking about issues like CSRF. From a development side, the typical response “Why do I need to input my password when I just did that to login to change my password?” While the change will most likely get made, because security said it had too, there is still a lack of understanding from the application team. If CSRF was your first reason, what if they have CSRF protections already in place? Do you have another reason? What about if the account is hijacked somehow, or a person sits at the user’s desk and they forgot to lock their PC? By explaining the reasoning behind the requirement, it starts to make sense and is better received. It dominos into a chance that the next project that is developed will take this into consideration.

When the business analysts sits down to write the next change password user story, it will be a part of it. Not because security said so, but because they understand the use case better and how to protect it.

If you are receiving test results, take the time to make sure you understand the findings and the WHY. It will help providing a learning objective as well as reduce the risk of not correcting the problem. Understand how the issue and remediation effects your application and users.

April 13, 2016 by James Jardine

5 Things to Improve Your Application Security Program

Application security is on the top of everyone’s todo list, and it isn’t as easy as it seems. There are lots of moving parts supported by lots of solutions. We know it is not possible to do everything. James Jardine, our CEO, put together a webcast the other day with a few different things you can do to help improve your application security program.

Watch the Full Video

You might be surprised by the list, since it does not deal directly with the traditional recommendations of static or dynamic analyzers or threat modeling. Instead, he takes a higher level approach to look at how the program as a whole can be improved. Here is a quick rundown of the list (watch the free video for much more insight):

Getting the App Teams Involved

Neither the security teams or the applications can do it all alone. Although many may not want to admit it, we need each other. Traditionally, I have seen security teams trying to take on too much of the burden when it comes to tools and security aspects of an application. Unfortunately, they usually do not have the required skillets or the access to fix many of the issues that are identified. It is important to start getting the application teams, that includes the developers, business analysts, testers, and others all involved with the security of the application. Application security is everyone in the company’s responsibility. The app teams are capable of managing tools like static and dynamic analyzers and even doing some level of security testing. The critical first step in this process is having good solid communication and collaboration between the different teams.

Identify Skill-sets and Resources

Building on the process of getting the application teams involved, we need to understand what resources and skillets we currently have in our organization. Take the time to evaluate your resources to understand what is available. In addition, you need to understand what skillets you need for your tasks. There may be specific technical skill sets, like a specific programming language, or they may be management type skill sets you need. This is where the hard work comes in. It requires you to really understand what your goals are to help determine how you will get there. Once the lists are compiled, it is easier to identify which skill-sets or resources are in need. This leads us to the ability to then determine how we gain those skill-sets. It may be through hiring new resources, or it might just be that you need to provide some training to existing resources. Without having a solid understanding of what you want, you may find yourself hiring resources that don’t help move the program forward.

Training

Training is very important, in fact, it is a must have for the different teams. With the traditional separation of security and development, development doesn’t have as much security experience or training. As you move towards getting more application team involvement, training is the foundation to build upon. The team must have the resources to understand security at a high enough level to be efficient at the tasks they are responsible for. Don’t expect better application security if the teams are not getting the support they need.

Application Inventory

Do you have an application inventory where you track all of your applications? For most companies the answer is no, or we track some applications but they are not kept up to date. An application inventory helps quickly identify the applications, their data classifications, 3rd party library usage, and much more. With the reliance on so many 3rd party libraries, this can be useful when a library is found to be vulnerable. How do you know if it effects your applications or which ones? How do you know which apps have had penetration tests, or are even required too. The application inventory plays a key role in helping understand these decisions.

Policies and Procedures

Last, but not least, do you have policies and procedures in place regarding application security. These policies are what guide the teams into performing better security. If there are no guidelines in place, you can be sure that it will be much more difficult to get good compliance. Take the time to create the policies you need to help define how application security should be handled. Extend those policies and guidelines out to different pieces, such as static or dynamic scanning. How should those tools be used, who is responsible, when should they be executed. Defining the program helps guide the roadmap to an improved application security program.

Watch the Full Video

Jardine Software focuses on helping companies retrieve more value out of their programs. Contact us to discuss your concerns and understand how we can help improve your application security program.

March 9, 2016 by James Jardine

Getting More Value from a Penetration Test

Penetration testing is one of the most common ways for companies to measure their current state of security. Even companies or applications that do not require a penetration test for regulatory reasons rely on them to measure their success or failure. The intent is to hire someone to hack your network or application like “the bad guys” would, and then receive a report indicating weaknesses in the system.

There are multiple ways to measure the value one receives from a penetration test.

The results, or at least a summary of the assessment, can be provided to clients, vendors, or other 3rd party entities. This is typically done to attest that the company is meeting industry standards when it comes to security. Of course, this view is only from an attack perspective, and doesn’t identify actual security operations within the organization. It is a primal indicator to determine if you are susceptible to security weaknesses that could lead to a breach. This type of testing is often required by these outside entities.
The results are used internally to help measure the security stance of the organization or application. It is a chance to get verification whether or not the controls put in place are actually effective. It allows the testing of auditing and monitoring controls in real time. It creates a way to determine if patches are applied to the right resources. It helps validate what we should already know. It also helps identify possible items that are not known.
The results are actionable. The findings can be handed to a developer or administrator to be remediated. This creates the ability to reduce the known risk.

Organizations put a lot of focus on remediating the exact penetration test results. Unfortunately, this leads to a false sense of security. To understand why, you must understand how penetration test reports are consumed. The most important thing to keep in mind is that a penetration test is typically not focused on finding every vulnerability. It isn’t even focused on finding all instances of a specific vulnerability. The focus is identifying weaknesses and risks that are available and determining how much access those items may lead to.

Listen to the podcast of this topic

There are two pieces to a penetration test finding.

The finding – This is the high level identification of a classification of vulnerability. Cross Site Scripting or SQL injection are common examples of a finding.
The instance – This is an example of the finding. There can be multiple instances per finding in the report. Cross Site Scripting on the search results page is an example of an instance of the Cross Site Scripting finding.

Due to the nature of a penetration test, remediating the instances provided falls short from a security perspective. Organizations spend so much effort focusing on the wrong information. Rather than focus on the finding, the focus is typically on each instance of a finding. Let’s look at an example.

A penetration test identifies cross-site scripting in the final report. That finding has 2 instances drawn out. The first instance is on the profile page and the second instance is on the documents page.

When the report is provided it is common to see the organization focus on the instances. In the example above, a developer would be assigned to resolve those two instances of cross-site scripting and the finding would be considered closed. By remediating those two items are you sure the issue is really closed? Remember, the goal of the penetration test is not to identify every instance, but to identify the different risks.

Rather than focusing on the instances, it is important to start focusing on the actual finding. Using the same example from above, the organization should create a task to identify why they have cross-site scripting issues within the application and then how they want to proceed to remediate them.

This involves:

Identifying and understanding the flaw (May indicate needed training)
Understanding how the application is developed
Identifying how it should be coded securely
Going through the application identifying these items to resolve it application wide

By actually analyzing the flaw itself, a much larger impact can be made to the application. Working just the instances identified in the report is like trying to plug randomly identified holes in a sinking ship. Sure, it resolves that one issue, but what is happening with those holes you don’t see letting water in.

If a quick inspection of a ship identified a crack or issue in one location, wouldn’t you want to inspect the rest of the ship making sure that issue isn’t somewhere else?

Penetration tests provide different values, but it is time that the true potential is realized. Don’t stop at just trying to remediate the instances in the penetration test, start looking to enhance your overall security by analyzing the findings.

March 1, 2016 by James Jardine

Introducing the Security Learning Opportunity (SLO)

We are happy to announce the release of the Security Learning Opportunity (SLO) template. SLO is a free template that helps application teams continue their security education through the use of security related items identified within the business applications.

Benefits

Relevant to the business – Identifying issues that relate directly to the business, or a business application helps the team understand the impact of the issue. Typical training uses purposely vulnerable applications or examples from other companies for reference.
Continuous education – Training needs to be re-enforced throughout the year. SLO provides an opportunity to participate in small learning sessions over time in addition to what resources may get through a 2-4 day class held annually.
Effective use of time – SLO is designed to be a short task, allowing the application team to focus more time on building great applications.

You can get SLO from https://www.developsec.com/wp-content/uploads/2016/02/SLO.docx

SLO helps organizations share the information that typically gets handled by one or two developers. Often times, when a vulnerability is discovered, it is handed to one developer to fix. Unfortunately, the other developers are never made aware, leading to a continuation of creating the same issues going forward. The SLO hopes to help solve that issue. The developer, or other team member, can fill out the template and then easily share the results with the rest of the team. This is great if the remediation should be done consistently within the applications.

For example, you find CSRF and decide on a specific way to mitigate it. You will want all of the developers to understand how this mitigation works and how to implement it going forward. If only one developer looks at the issue, resolves it, and moves on, it leaves all the other developers in the dark. It also helps testers and other team members understand the significance of the issue and ways to identify it.

SLO is designed to require only a short amount of time and is composed of 2 phases.

Phase 1: Identification and Analysis (Est. 30 minutes)

During the first phase, a team member will identify a security issue that makes sense to share with others. Don’t get caught up trying to create a SLO for every security issue identified. The trick is to identify things that can be shared on a mass scale and provide value to the other team members. Once an issue is identified, some analysis is performed to determine the following items:

Description of the issue
Risk the issue presents
How to identify/test for it
Remediation

It is estimated that it should take around 30 minutes to complete the identification and analysis phase of the project.

Phase 2: Sharing the Information

The real value of the SLO is realized when the information captured is shared with the team. There are multiple opportunities to share the information.

With the group during dev meeting or stand up
Share via email or internal collaboration site
Include as part of yearly or other security training classes

Sharing the information can be anywhere from 5-30 minutes, depending on the issue identified.

Download It Now

You can get SLO from https://www.developsec.com/wp-content/uploads/2016/02/SLO.docx

Security Tips for Copy/Paste of Code From the Internet

Understanding the “Why”

5 Things to Improve Your Application Security Program

Getting More Value from a Penetration Test

Introducing the Security Learning Opportunity (SLO)

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us