Jardine Software

  • Home
  • Solutions
    • Security Testing
    • Security Review
    • Training
      • Fundamentals of Application Security
  • Testimonials
  • Resources
  • Blog
    • .Net Blog
  • About
    • Events
  • DevelopSec

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.

Contact us to discuss more

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.

Filed Under: Uncategorized Tagged With: application risk, application security, appsec, https, risk, secure code, secure deployment, security, security testing, SSL

July 20, 2016 by James Jardine

You don’t need to play Pokemon Go to get a reward

Pokemon Go is taking over the world. An “augmented reality” platform where you hunt pokemon characters using your phone and GPS coordinates. Many voice concern over privacy and safety.

I recently talked about those concerns on Channel 4 News:

Watch the Full Interview

The attention focused on security and privacy distracts from three other areas worthy of discussion. In some cases, the solutions might be more challenging and less obvious. That’s precisely why we can use the Pokemon Go craze to advance the dialogue in our organizations. Here are some of the areas to tackle:

Fake Applications

Due to the overwhelming success of the app so far, there have been a high number of fake, or malicious, applications being released. These applications are billed as being the real Pokemon Go application, but instead are malware used to gain access to the user’s device. These fake apps are found on 3rd party sites, not typically in the official app stores.

My questions to the organizations out there:

  • Have you thought about how these rogue applications could be created in response to your applications?
  • What effect does that have on your organization and your users?
  • Are there any controls you can implement that would help stop that type of behavior?

I’m fascinated with exploring if/how this could be stopped. I am not sure there is a way for an organization to completely block fake apps disguised as their own. It may be possible to issue takedown orders, but that could get out of hand pretty quickly. It also requires you to be tracking all of these apps that pop up. Maybe the best we can do is reinforce with our users where to get the official application and not to download it from 3rd party sites.

One of the factors that made fake apps so popular with Pokemon Go is the fact that the app was not released to everyone at one time. This leads to users looking for a way to get access before it is available to them.

Scams

Popularity brings scams. Whether it is phishing, vishing, smishing or any other type of scam, we may want to start thinking about the possibilities before the release. While we cannot stop scammers from taking advantage of our popularity, there may be some ways to reduce some of the risk.

Take this example from Pokemon Go. Not long after the release, there were reports of phishing emails going around indicating that due to the popularity of the game it would no longer be free. The user’s account would be locked if they didn’t go to a website and start paying $12.99/mo for access. This could lead to stealing of credit card information or user credentials.

Three questions to guide the conversation:

  • How do you communicate to your customers/users?
  • How does your business model affect the types of scams available?
  • How do customers contact the organization for concerns, and are you ready for it?

This isn’t a new technique. Rumors of Facebook going to a pay service have spread for a long time. None have been true from what I can tell. However, this gives us an example of the types of scams that may be used. It allows us to consider how we can handle this type of communication if it were to happen. I wonder how the communication would happen if an app did decide to switch to a monthly service. Would the notice come from within the application? Would the company release information on their official site? How would the user’s know?

Legal

Inevitably, organizations that provide products and services are under heavy legal scrutiny. Of course there are the obvious issues that come up all the time. With Pokemon Go, we are going to see some interesting cases attempting to make the game and its creators liable for a myriad of incidents. We have already seen in the news incidents where players were caught trespassing in a zoo, shot at in their car, and even automobile accidents.

Three questions to consider:

  • How involved is the legal group during the creation of an application?
  • What do your terms of service cover regarding liability concerns?
  • Is your legal group ready to respond to raised concerns?

While none of these events have brought legal suit against the game or its creators, these are things that should be considered with such an interactive offering. Reducing liability through a terms of service may be the first step, it may not be a complete solution. I am no lawyer, but do believe that this is another area that should be fully understood when analyzing the risk of an application. What are you doing to be prepared if legal action is taken?

Next Steps

There are a lot of things to consider when we create new applications and services. Some of these things can be solved, while others cannot. It is impossible to think of all the different things that could go wrong. However, if we look at the things that occur for other applications, we can see new ways to view our own applications and procedures. Maybe no changes will be made, but at least we will have considered some of these topics, rather than being blind to them.

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.

Filed Under: Uncategorized Tagged With: application risk, application security, enterprise risk, enterprise security, legal, pokemon, pokemon go, risk, security

Newsletter

Sign up to receive email updates regarding current application security topics.

Privacy Policy

Contact Us

Contact us today to see how we can help.
Contact Us

Search

Company Profile

Jardine Software Inc. was founded in 2002. Originally focused on software development, we now focus on helping development teams and … Read More...

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Contact Us

Jardine Software Inc.
Email: james@jardinesoftware.com



Privacy Policy

© Copyright 2018-2025 Jardine Software Inc. · All Rights Reserved