Monthly Archives: January 2017

Gmail will block JavaScript file attachments

According to a recent announcement, Gmail will start blocking .js file attachments starting February 13, 2017.

Blocking specific attachment types isn’t something that is new to Gmail. They already block attaching file attachments that are .exe, .msc, and .bat types. The recent move to add javascript files is most likely related to the recent malware/ransomware campaigns that have started using JavaScript files instead of Microsoft Office files. There was an article posted back in April discussing this trend.

If you are still looking to send another person a JavaScript file, you can just use other services, like Google Drive, Dropbox, or other similar products. While the change doesn’t block all potential avenues for ransomware to be sent via email, it does help reduce the risk of this particular method.

As a user, we still must be attentive to other attack vectors, such as macros within Microsoft Word files which can be used to infect systems. There may be a resurgence of these methods as the JavaScript files start getting blocked.

This move does beg the question as to why not force all attachments to go through a storage service, rather than directly attached to the email. Would that actually create a larger risk with the abundance of links now being sent within emails? Would it just move the threat from your inbox to the cloud service? It would be interesting to get a bigger picture of this landscape for better understanding.


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.

Secure Notification Updates in FireFox and Chrome

There has been a steady increase in the number of applications that have switched to using HTTPS instead of HTTP for communication. Even sites that have no sensitive information or authentication mechanisms. Using HTTPS provides authentication and a secure channel to transmit data between client and server. The authentication verifies that you are communicating with the organization you thought you were. This secure transmission is meant to stop other parties from being able to read or manipulate the user’s traffic. For non-sensitive applications, it is that ability to manipulate the traffic that we are trying to protect against.

Mozilla announced that the next version of FireFox, Firefox 51, will be changing how it presents the lock icon to represent security issues with the site. Traditionally, there would be a green lock icon for secure sites and no lock icon for sites that use HTTP. The new changes will introduce a grey lock icon with a red slash through it when a site is using HTTP and collects passwords. In addition, there will be a note indicating that “Logins entered on this page could be compromised.”

Mozilla also hints at some additional changes on the roadmap. In particular, a potential indicator on the password field that will alert the user that the account details are insecure and may be compromised. It will be interesting to see how this feature will be implemented, especially if the browser will inject code into the application code. This could raise some concerns for many others out there.

Back in September, 2016, Google announced that Chrome was making similar changes that would take effect in January. I did a podcast on this which is included here.

Google is going further than just passwords and including credit card number fields. There wasn’t much mentioned for FireFox about anything other than passwords. In both browsers, changes should be available soon. Help spread the word about the new changes so your users, your friends, and your family know what the new indicator really means.

You may be surprised at the number, or type of sites that may be affected by this. There are many forums and other community sites that get created without using HTTPS for transmission. This may be because the site owner doesn’t realize the benefits of using HTTPS. They may also not think that the site contains sensitive information, so why add the overhead. However, many of these sites do require you to create an account and log in with a password. Unfortunately, many people re-use passwords so na attacker getting that forum password may have also just gotten your password for other sites. Not to mention, they could impersonate you on the specific site.

In the absence of sensitive or account information, using HTTPS provides protection from traffic manipulation. Even rising a corporate landing page, an attacker on the same network could inject malicious code into the response to attempt malicious activity on your system.

What are your thoughts? Are you for the browsers making these types of changes? Do you think it is an overreach? If so, why? Share your thoughts on twitter or join our slack channel to join the conversation (send me an email for an invite).


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.

Remember Me Features

Tired of constantly logging into your applications? Don’t you wish they would just remember you each time you visit, logging you right in? It isn’t as always easy to achieve such a status. There are multiple ways remember me can be implemented. Lets take a look at some of them.

Remember UserName

One of the most common ways for a site to implement the remember me functionality is to remember the username only. The username is typically stored in a cookie on the client’s computer. Remembering the username helps speed up the authentication process, but doesn’t eliminate it. The user still has to enter their password to gain access to the application. Although this is a common technique, some organizations may have data classification policies that don’t allow displaying the username in the application. This can also carry over to the username and the login screen. For these organizations, they may not implement a remember me feature at all. Remembering the username does contain some risk, as it instantly provides the username to an attacker on the user’s computer. This leaves just the password for the attacker to determine, which may be feasible if the user re-uses passwords that have been previously breached.

Long-term Auth Cookies

Another common technique for remembering a user is to set an authentication cookie that has a long life. Once you login, a cookie is created that may not expire for a year or longer. This allows you to be automatically logged in each time you visit the site. I am sure you can think of a few sites that provide this functionality. It is common among some of the social media sites people visit all the time. This is not recommended for any type of sensitive applications because it would allow immediate access to anyone that gains access to the user’s device.

Storing Password Locally (Remember Password)

Another option, that probably shouldn’t be an option, is storing the password on the user’s computer. This was recently seen on a web application, however we won’t mention the site that did this. We can, however learn from their decisions. In the application, they used CryptoJS to encrypt and decrypt this type of sensitive data. In this case, they stored the password in a cookie. With the encryption routines available on the client, it is possible to use them to decrypt the encrypted password with very little effort. This is typically the case any time the routines are made available, especially if the keys are available as well. While I am sure this was done with good intentions, the implementation is not very secure. As a matter of fact, it provides more of a false sense of security. This is most likely due to the use of encryption. It is not recommended to perform this type of encryption client-side, nor is it recommended to store the user’s password on the client like this.

What Next?

There are multiple options to help ease the burden of frequently logging into an application. Depending on the type of application, data stored, and sensitivity of the transactions, the options should be considered carefully. Providing the option to remember a username is convenient with some residual risk. Keeping a user logged in for extended periods of time increase the risk, but may be acceptable depending on the application and its use. Stay away from storing the user’s password locally on the computer they are using. Secure implementation is not easy or straightforward, increasing the risk levels.


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.

Introducing our Slack channel

It is a new year and time for some new ways for all of us to communicate. We appreciate all that have read the posts and listened to the podcast. Both of these will continue to move forward in 2017 with some new material on the way.

We are happy to announce we have started a Slack channel. You can find it at developsec.slack.com. The blog and podcasts have been great in providing information in a read-only manner. Slack is an opportunity to open up more conversation and create more dialog. A chance for us all to share stories and work out problems.

The channel is dedicated to application security topics. This means web, mobile, IoT, and whatever else is running applications. The goal is to provide a mechanism to bring application security into our everyday life. If you are interested in being a part of the DevelopSec Slack group, just drop me a line at james@jardinesoftware.com. I will send you out an invite.

DevelopSec encourages developers, business analysts, QA, and other application team members to take part in this great new opportunity.

Here is to 2017. A new year with new opportunities. As always, feel free to reach out to discuss AppSec.

MongoDBs under attack from ransomware

In recent news, it was identified that MongoDB databases are being exposed on the internet and infected with ransomeware. In a little under a week, the infection count went from 200 to 10,000. That is a quick ramp up.

In this case, 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. Also make sure you are taking proper backups to help recover if your data is manipulated. 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.

There are lots of exposed MongoDB databases available. Take a moment to make sure yours are not part of that count.


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.