James Jardine – Page 2

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.

January 23, 2017 by James Jardine

New browser security notifications highlight insecure connections

Creating an application and presenting it to others requires a lot of different security considerations. One of the most fundamental security controls is to provide a secure communication channel between the application and the server. For web applications, that focuses on the web browser to server communications. For mobile applications, it could be a built in web browser or the application making API calls directly. If you are developing IoT devices, it is the connection between the device and the back-end server.

Secure communication is most commonly conducted using HTTPS, or WSS for web sockets. HTTPS implements TLS (SSL is no longer recommended) to encrypt the data between the client and server. The encryption of the data reduces the risk of an attacker on the same network pathway from reading or manipulating the data. In addition, the use of a certificate provides authentication of who the client is communicating with. Let’s take a look at how each of these helps reduce risk.

Authentication

The first thing we want to understand is how authentication is provided by our secure communication. Certificates are issued by certificate authorities that are supposed to verify the identity of the organization requesting the certificate. Once the application is complete, and the certificate is installed on the server, the user will receive the valid certificate. When the user visits that application over HTTPS, a green lock will typically appear indicating that the connection is secure. It is possible to dig into that status icon to get the name of the organization that requested the certificate. For organizations that get an EV (Extended Verification) certificate, it may show the organization name in the address bar.

Certificates from root certificate authorities are already trusted by most browsers. This factor makes browsing most applications seamless. If a certificate is self-signed or not from a trusted authority, browsers will display a warning message to the user. This warning helps bring to attention the fact there is an issue, or higher risk, when visiting that application. Many organizations will use self-signed certificates internally. If the certificate is not properly deployed and trusted on all the user systems, it can lead to confusion when dealing with the browser alert. It could create a situation where user’s just click through any notifications without understanding them. This authentication and trust allows the user to know who they are communicating with.

Secure Communication

Protecting the communication from eavesdroppers is critical for applications that transmit sensitive data, such as PII, credit card numbers, account numbers, etc. When data is transmitted in clear text, it is possible for others on the same network segments (between the user and the server) to potentially view that data. This allows for stealing passwords and other sensitive information.

Don’t assume that a site/application that doesn’t contain sensitive information shouldn’t be concerned with secure communication. Just because there is a lack of sensitive information, there is still a risk to the end user. Just as an attacker may eavesdrop on communications, there is also the possibility they can manipulate the traffic from the server to the client. Using this technique, the attacker can modify the response to remove security controls, modify the content displayed, or even inject malicious content into the page to attack the user directly. By encrypting the transmission, it makes it much more difficult to manipulate any of the data, helping provide more protection to the end user.

How Browsers Help

Starting this year, well, this month actually, both FireFox and Chrome are releasing updates to help notify users when their connection is insecure. The browsers already have a mechanism to help alert users of issues with certificates (self-signed, expired) and they are now adding additional notifications.

FireFox will be adding a grey lock with a red line through it when an application is found to be using HTTP (non-secure) and transmits passwords.

Chrome will be adding a notification similar to FireFox when an application is found to be using HTTP and transmits passwords or credit card numbers.

In both cases, the goal is to help notify the user that some form of sensitive information is being passed over a non-secure channel, exposing them to more risk.

What Now?

Here are a few questions to consider regarding the use of secure communications:

Do you know what applications, in your organization, are not using a secure communication channel?
Have you analyzed the risk around not implementing HTTPS?
What is preventing the use of HTTPS on all of your applications?
Do you have a plan to provide a response to users that may have questions if they see these new notifications?
Do your QA engineers know how to identify and properly handle this scenario during testing?

There may be technical issues prohibiting the use of HTTPS. If so, are they documented and understood? The first step is having a grasp on your applications and the user base. the next step is understanding the technical details to support the appropriate implementation.

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

January 10, 2017 by James Jardine

When it comes to security, read the instructions

Many of us are fairly technical and have gotten along just fine just clicking through wizards to install new software or devices. For many, it is like building your favorite furniture from IKEA. Who needs instructions? You fight your way through it, making assumptions on what pieces go where and with which hardware. With your furniture, a missed step may lead to some left over parts and the item collapsing at an unfortunate time. With software and devices, a missed step could lead to the loss of sensitive data, loss of money, or even possibly physical harm.

In a perfect world, software and devices would force secure defaults and then require explicit actions to remove that security. We don’t live in that perfect world. This was seen with the recent news about MongoDB databases being exposed on the internet and infected with ransomeware.

In the case of MongoDB, misconfigurations may bind the database port to the public interface, while also allowing anonymous access. This combination can be devastating. Doing a quick search on Shodan you may find there are thousands of misconfigured MondoDB servers exposed on the internet.

Like many other software packages, MongoDB has a security checklist available to help minimize this exposure. The checklist covers important steps, such as enforcing authentication and limiting network exposure. I am seeing more packages that are including security checklists, or security guides that are available. If you are installing something new, take a moment to see if there is a guide availble to properly secure the item.

In addition to the security checklist, the creators of MongoDB have created a post addressing the ransomware attacks that are happening. This link points out a few other items to help secure your MongoDB instance. It also points out that the most popular installer for MongoDB (RPM) limits network access to localhost. This default configuration is critical in helping reduce the exposure of these databases.

As time goes on, I expect we will see more improvements made to these types of products that make them more secure by default. As an organization developing this type of software, or devices, think about how the item is installed and how that reflects security. Starting off more secure and requiring explicit configuration to open make the item available will provide much better protection than it being open by default.

If you are running MongoDB, go back and check the security checklist. Make sure you are not exposing the instance publicly and authentication is enabled. If you are running other software or devices, make sure to know where they are and determine if they are deployed securely. Check to see if a security checklist exists.

We are often in a hurry and just click through the prompts of an installer. However, to provide the proper risk management, we must take the next steps to understand the configurations to protect our assets.

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.

November 22, 2016 by James Jardine

5 mistakes to avoid to hire qualified application security talent

Hiring for application security positions is often seen as almost impossible. With many claims of talent shortages and so many open positions, finding the right candidate can be a daunting task. Here are 5 common mistakes to avoid and how to get past them.

Not understanding your current needs

If you are thinking about bringing on an additional resource focused on application security, you must understand what the duties will be. Unfortunately, due to the constant pressure to be secure, many companies focus on having the resources and then trying to determine what they will be expected to do. While this may be the case for the initial hire of a brand new application security program, it shouldn’t be the norm.

Understanding your needs requires work. It requires understanding what your immediate priorities are vs. the long term goals. While both of these may play into the candidates skill sets, focusing on the immediate may result in a quicker hire. There are many different tasks that an application security professional may perform. For example, working with static or dynamic analysis tools, or helping with threat modeling. They may also be creating automation around identifying security issues within the organization’s environment. You have to ask yourself, which of these are the current priority. Your organization may implement static analysis this year, but have dynamic analysis scheduled out a year. Maybe manual testing (red teaming) is a nice to have, but you know you won’t have time to build up that program for a few months.

Ignoring existing resources

Once you have a good understanding of what your needs are, it is time to look at existing resources. The common mistake is to just look at the security team. Instead, look at the application teams as well. What type of resources and skill sets exist within the organization. Business analysts are great at digging into understanding problems and gathering requirements. Developers know development and are typically great problem solvers. QA testers know how to test applications. Project managers know how to efficiently schedule tasks to get the project to its expected milestones.

All of theses resources, none of which are dedicated to security, provide a wealth of experience that can be applied to security. Let’s be honest, application security should be a part of each of these roles if we expect it to be successful.

Not sharing the workload

Just because it says application security doesn’t mean everything has to be handled or executed by the application security team. Many of the application security programs can be spread across multiple teams. For example, dynamic analysis could be integrated into the QA team’s responsibilities. The team already performs testing against the application, it makes sense to put dynamic testing within this context. Shifting the ownership to the correct location adds many benefits. First, it allows the application security team to focus on more specialized tasks. If using on-premise static analysis, this may include writing custom rulesets vs. just executing the tool and reformatting the results. It also helps embed security into the SDLC. The verification phase will now not only test for the common bugs, but also for the security bugs. In addition, the bugs will all be tracked using the same process, requiring less implementation effort.

There are many application security tasks that can be integrated into the existing SDLC processes. This will typically require engagement from the application security team to help guide the creation of these processes. That may be, however, what defines the role you are trying to fill.

Not defining the role

Once you have a good understanding of your needs and what still falls within the application security team’s responsibility, you can start to define the role you see. This process still relies heavily on understanding your needs, filtering out what is covered by current resources. Depending on the size of your organization and your application security team, the role may be very broad or very specific. It is this definition, however, that will drive the job requirements that get shared to human resources.

Overly broad job requirements

Getting candidates interested in the open position is critical to getting their attention. Being specific about what you are really looking for helps reduce noise and attract more relevant candidates. Often times job requirements are very broad and cover every possible task that may be performed. How often do those tasks actually get performed once someone is brought in? Some of them may never get executed.

Having too broad of requirements may cause great people to pass on by, thinking they don’t have all the skill sets needed. On the other hand, people may apply because they have one of those skill sets and it never gets used once they are hired.

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

November 21, 2016 by James Jardine

SSL Labs Grading Changes and HSTS

Qualys recently posted about some grading changes coming to SSL Labs in 2017. If you are not aware of SSL Labs, it is a service to check your SSL/TLS implementation for your web applications to determine how secure they are. While there were more changes listed, you can read about them in the link above, I wanted to focus on the one regarding HTTP Strict Transport Security (HSTS).

If you haven’t heard of HSTS, or want a quick refresher, you can check out this post: HTTP Strict Transport Security (HSTS): Overview.

According to Qualys, the changes regarding HSTS will not be implemented until later in 2017, not with the initial set of changes. However, this early notification may help some companies make preparations for the change. Here is what they say about HSTS grading changes:

HSTS Preloading required for A+
HSTS required for A

Some organizations have specific requirements to the grade they expect to receive on the SSL Labs report. If an A is your target, HSTS is going to be a critical component for that. Even if it is not, this change is a clear indication that HSTS does not look like it is going away.

HSTS is a great way to help increase the security of your transmission from browser to server. However, it may not be something that can just be turned on. We have seen many sites have difficulty going to 100% HTTPS, and HSTS doesn’t play well with mixed content. It also doesn’t play well with self-signed certificates. While these are important for the increased security it provides, this is where the difficulty may come in.

If you are not using HSTS currently, now may be the time to start thinking about it. Creating the header is typically not very difficult. Testing to make sure nothing breaks because of it can be a bit more tedious. Want to know more about HSTS or application security?

Security Tips for Copy/Paste of Code From the Internet

New browser security notifications highlight insecure connections

When it comes to security, read the instructions

5 mistakes to avoid to hire qualified application security talent

SSL Labs Grading Changes and HSTS

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us