DevelopSec

awareness

by Leave a Comment

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.

by Leave a Comment

When One Testing Solution Isn’t Enough

Go to any conference, attend some webinars, or just do a search for application security testing solutions and you can quickly see the sheer number of solutions out there. As in every situation, there are some that are great and some that are not so great. With such great marketing, it is often very difficult to determine what is the best solution. All too often people are looking for that silver bullet. That one testing tool or pen testing company that will find everything. Unfortunately, that solution doesn’t exist, or I just haven’t seen it.

Application testing usually falls into two categories: Automated scanning and manual assessments. To break that down further, automated scanning is broken down into two disciplines: Static and dynamic.

Static Analysis

Static scanning means that code is scanned without running it. Here is a quick post about static analyzers. Inputs are traced through the code to see what paths are taken and determine vulnerabilities. Static scans can be efficient at finding flaws such as cross-site scripting, injection flaws, configuration issues, etc. Static scans excel at finding code issues like hard coded passwords, cryptography issues, and other items not possible through a dynamic or manual test. They still do not do very well at finding business logic flaws which can be the most devastating.

Dynamic Analysis

Dynamic scanning means that the application is scanned as it is running. Unlike a static scan, it can be very difficult to identify hard coded passwords or cryptographic issues because they are not visible to the end user. Dynamic scans do a decent job of identifying other flaws such as cross-site scripting, injection flaws, insecure cookies, and some other configuration issues to name a few. Dynamic scanners do not do a good job identifying authentication, authorization, or business logic flaws in general. Properly tuned scanners may be able to do this, but that requires extra work.

Manual Assessments

Manual assessments are mostly a manual process of analyzing source code or using the application to find security flaws. Source code review, has many advantages of the static scanning mentioned above. Penetration testing is very similar to the dynamic scanning mentioned. In both cases, the testing is done manually vs. using just an automated tool. Manual assessments (pen tests) are much more efficient at finding authentication, authorization and business logic flaw types. Of course the quality of the assessment is heavily influenced by the skill of the person doing the assessment.

Some of the big vendors have started offering all three types of assessment for their customers. The big players (White Hat Security, VeraCode, HP, etc.) all offer static, dynamic and manual assessments for your applications. And with good reason. If you have worked in an enterprise where you are required to have multiple assessments by different groups you quickly realize how nothing provides a complete solution. Each assessment paints a portion of the security picture. Items found by one may not be found by the other. In some instances you may think that two should have found the same item, but that is the nature of security.. No one finds everything.

Multiple Solutions

While you may think that it is overkill to have multiple scanning solutions or testers looking at an application, they all bring a different viewpoint and help identify different types of vulnerabilities. Sort of like an enhanced second pair of eyes. Not only can they double check the work the other has done, but in may situations they can identify different types of vulnerabilities. Not only do different solutions find different vulnerabilities, they also find them at different phases of the development lifecycle. It is common to use the static scanners in the development phase. Dynamic scanners are more commonly seen in the verification phase. Manual assessments, especially 3rd party penetration testers, are also in the verification phase, but near the end of the cycle. The closer to development a flaw is found, the quicker it is to remediate it.

The right solution is the one that fits your environment. Take the time to analyze your setup to determine the best way to implement a solution. These solutions take time and should be carefully considered.

by Leave a Comment

The FTC’s “Start with Security: A Guide for Business” Document

The FTC recently released a document to help companies learn from others’ security mistakes. The document titled Start with Security: A Guide for Business. It provides ten (10) different security lessons learned by other companies, included below:

  1. Start with security.
  2. Control access to data sensibly.
  3. Require secure passwords and authentication.
  4. Store sensitive personal information securely and protect it during transmission.
  5. Segment your network and monitor who’s trying to get in and out.
  6. Secure remote access to your network.
  7. Apply sound security practices when developing new products.
  8. Make sure your service providers implement reasonable security measures.
  9. Put procedures in place to keep your security current and address vulnerabilities that may arise.
  10. Secure paper, physical media and devices.

The thing I find unique about this document is that it is not technical, actually quite the opposite. It is a high-level description of the security lesson. Additionally, it identifies businesses that have had cases brought against them.

It is great to see a new approach to identifying why security is important. Using lessons from other companies shows a direct relation to the security lesson. It is no longer a matter of theory, these things do have consequences.

I have recorded a 20 minute podcast providing an overview of the document. I will also be breaking down a few of the topics to cover them in a little more detail. I recommend taking a moment to take a look at the document the FTC has provided. It is a quick read.

by Leave a Comment

Tips for Protecting Credit Card Information

Turn on the news and you will see a breach announced for some company. It is happening all the time. In most cases we, as consumers, accept the risk for the convenience of using a credit card for purchases. While there isn’t much you can do to protect your information once you have given it to a business, there are some things you can do to help reduce your risk while shopping online.

Scan for Malware

Most of our online purchases happen from our own computer indicating that this is where we should start our own protections. Over the years we have always told people to make sure you are running anti-virus software, but there are other types of malicious software (called malware) that these programs often don’t detect. Malware is software that is installed on your computer, usually without your knowledge, that has a malicious intent. It may be that it is trying to steal your passwords, credit card information, or other sensitive information. It might be software to spy on you using your computer’s built in microphone or video camera. In any case, it is software that you do not want installed.

There are other programs that you can get to remove this type of malware, above and beyond the use of anti-virus software. A program that I found very useful, that I don’t have any affiliation with, is MalwareBytes (https://www.malwarebytes.org). The greatest benefit is how easy the program is to use (oh and they have a free version). It scans your system for malware and does a really good job of removing it for you. If you have ever tried to remove malware before, it can be pretty difficult. Not with some of these programs like MalwareBytes. If you notice your computer running slow or acting odd it may be a good idea to give it a scan to see if anything comes up.

Be Careful with Emailed Links

Phishing, the art of sending emails with the intent on tricking the user into visiting a malicious site or installing malicious software, is a common way for an attacker to infect your system. All too often we have been told to not open attachments included in an email from someone we don’t know, but this is also true for clicking on links. In many cases, those links do not go to where you are expecting them too. Lets look at a quick example. I have created a simple fake email with some made up business and web site addresses.

BadEmail1

The link in the image above looks normal, however when we take a moment to inspect it more it turns out not to be. To inspect the link, most email clients allow us to hover over it for a moment to see a preview. Hovering means to place your mouse over the link, but don’t click the button. After a few seconds, a balloon should appear to show you what the link actually points to. The following image shows this in action.

BadEmail2

If it is possible, it is recommended to type out the link that is presented or go to the site directly in the browser (if it is a familiar site) rather than clicking on the link. It is understandable that this is not always possible, as some links contain a special discount code or special offer. In these cases, take the time to make sure that the link is going to the site you are expecting. As with any security tip, trust your gut. If something doesn’t seem right, don’t enter any type of personal information with it.

Verify the Site is Using HTTPS

When you are about to use your credit card online, make sure that the web site you are using is using HTTPS. HTTPS means that the information you provide will be encrypted, or protected, as it is sent to the web site. Think of it like using a security envelope vs a regular envelope when sending snail mail. Of course, there are other protections that make it more secure than a security envelope, but that should be a good analogy for most people. There are a few ways to verify this. First, you can look at the address bar in the browser that displays the site name and make sure it starts with “HTTPS”. The next step is to verify that there is a padlock icon near that site address. The image below shows this site and in the top left you will see the padlock icon and https://www.developsec.com. That indicates that the site is using HTTPS and your data will be protected when sent to the business.

DevSec1

You can also verify even further, by clicking on the padlock (in FireFox) the site name matches up with the certificate name. In the below image you will see that the box that appears states I am connected to developsec.com.

devsec2

When Searching, Select the Right Site

If you are using Google or Yahoo, or some other favorite search engine, make sure that the search result you click on is the site you are expecting. With how technology is advancing and the way we have updated how search engines work, there are possibly thousands of results that may come back. Search engines also often put ads as the first few results. Take a moment and ensure that you are going where you think you are going. Don’t just click the first link that is returned.

The following image shows a search for FireFox for Mac. Notice how there is an Ad (which does point to the real FireFox download) and then multiple results. The ones that go to Mozilla.org are valid results that go to the creators of FireFox. Under that are results that don’t go to Mozilla.org. While these sites may be valid downloads of FireFox (I did not try them), you want to try and stay with the creators or the software if possible. Often times software is repackaged by other vendors and that repackaging adds in software you may not want.

ff

Trust Your Gut

Security often times comes down to trusting what your gut tells you. If something seems out of place, then it probably is. If you don’t feel comfortable, then don’t input your sensitive information. Researching the item more can also help make a decision. if you are downloading software, do other searches about it to see if people downloaded malicious versions. If it is from a different site than the vendor, do a search to see if anyone else has flagged that download as bad. Finally, if you notice fraudulent charges, make sure you notify your credit card company as soon as possible.

by Leave a Comment

Best Practices for Cyber Incident: DoJ Released Guide

Breaches and other security incidents are happening all of the time, and can happen to anyone. Do you know what to do if an incident occurs in your backyard? The Department of Justice recently released the Best Practices for Victim Response and Reporting of Cyber Incidents to help you understand the process. Looking through the 15 page document, there are quite a few great points that are made. Here are just a few examples of what are included. I encourage you to check out the entire document as this won’t do it justice. It covers 4 topics:

  • Before the Incident
  • Responding to the Intrusion
  • What Not to do Following an Incident
  • After an Incident

The document is broken down into different topics, starting with before the intrusion actually occurs. This step is often overlooked because we never think it will happen to us. Talk to anyone that performs incident response or forensics and while these tasks are performed after an incident, what was done before the incident can be a game changer. Don’t forget baselines of your systems to know what is normal.

It is good practice to identify what is important to your business, that is, what you need to protect. This is different for every company. The next step is to create an action and response plan in the event an incident occurs. Well thought out plans make dealing with an incident easier. Make sure you are including non-technical resources in this planning. This may include the legal teams, human resources, public relations, and a wide array of other personnel within the company. When a breach occurs, there are a lot of moving parts to deal with.

Forming a relationship with law enforcement is also a good idea. It makes it easier to contact them in the event of an incident and you may feel more comfortable with the situation. The relationship may also lead to information ahead of time that could be useful to thwart an impending attack.

Once an incident occurs it is time to respond to it. This is the 2nd topic covered by the report. This starts with making an initial assessment of the situation. Who is logged on, what systems are affected, etc. Once you have identified affected systems it is time to implement measures to minimize damage. This might include removing systems from the network, shutting them down or segregating them. Once protected it is time to collect information about the incident, often requiring imaging of the affected systems. Note: If you are not sure how to do this it is a good idea to contact a professional. You do not want to risk damaging the evidence.

Once you have identified the affected systems/data it is type to put the notify portion of your action plan into effect. Don’t forget that it is more than just notifying customers. You want to understand which customers need to be notified, but also vendors/partners and internal employees. Depending on the situation, law enforcement may also need to be notified.

I really like that the document contains information about what NOT to do following an incident. Professionals that don’t focus in IR and Forensics tend to not think about what they shouldn’t be doing that could cause problems with the investigation or themselves. The affected systems should not be used for any communication unless absolutely necessary. These systems are most likely compromised and you can’t expect any information to be safe at this point.

While hacking back seems to be a debated topic these days, the recommendation is to avoid it. While the laws are broad when it comes to CFAA and other computer crimes, you don’t want to go from victim to defendant. Let the authorities deal with the issue.

Finally, once the incident is cleared and complete, stay vigilant. Don’t assume that once you get attacked it won’t happen again. Learn from what happened to help reduce the chances it will happen again.

My summary above just touches on the tip of the information provided in the document linked above. It is nice to see we have a list of best practices that are not technical that many should be able to understand. Even if you are not part of incident response or dealing directly with cyber incidents, take a moment to read the information as it might be helpful one day.

by

Is HTTP being left behind for HTTPS?

A few years ago, a FireFox plugin was created called FireSheep.  This tool was designed to sniff network traffic looking for common websites that were being visited over HTTP.  HTTP sends the traffic between your system and the server in clear text.  If it found a request/response of an authenticated user, it would capture the session cookie and allow the user of FireSheep to hijack the current session.  While the site most likely performed the initial authentication with the username and password over an encrypted channel, such as HTTPS, it then degraded to HTTP for the rest of the site visits.  The premise was that the credentials were protected, but the flaw in that approach is that the session cookie used to represent an authenticated user also needs to be protected.  In this case, it was not.

It is starting to become more popular for sites to allow support for HTTPS (the encrypted transport channel) all of the time.  Many sites like Facebook, Google, LinkedIn, Twitter, etc. started making this available as an option after the release of FireSheep.  If your site uses any type of authentication, it is recommended to only use an encrypted channel (HTTPS) for communication. 

What if your site doesn’t use authentication?  What if it is just your company’s marketing website?   What if your site just provides information to people but there are no passwords, sensitive information, or sessions to protect?   Should you still switch to HTTPS?

This is a debate that is starting to grow in the information security world.  With concerns of government snooping, or other entities snooping on traffic, many suggest dropping HTTP and only supporting HTTPS.  There is also the concern that your site, if using HTTP, could allow an attacker to intercept and modify your responses to directly attack your system.  While not attacks, we have seen ISPs deliver ads or other content by inserting it into the responses.   If an attacker can do this, it is possible for an attack payload to be sent and your system comprimised.  If you are on a corporate network this is the first step at attacking the internal network from teh outside.  

On the flip side, we don’t see these types of attacks very widespread and many people are not worried about any type of snooping.  They just want to get their information.   So does it make sense to just go ahead and drop HTTP and go for the gusto?   Pintrest just joined the ranks of going to all HTTPS (https://threatpost.com/https-opens-door-to-paid-pinterest-bug-bounty/111687) as an improvement to their security.  Does it make sense for you?   

There are some things to think about with implementation of HTTPS.   Of course, there is a monetary piece to this.   You have to buy a certificate for your domain so that HTTPS will work.  Depending on the site you go to, these certs vary in price.  The other big concern I often hear is about performance, that HTTPS will slow the site down and users will be unhappy.  Recent advances in SSL and TLS have pretty much negated this issue.  If a site like Facebook can implement it, there is a good chance you can as well.  If you are serving up external content there may be some hurdles as browsers may get upset when trying to display mixed content: that is content from both HTTP and HTTPS.  

I am not sure if it is going mainstream for all sites yet, or just the sites that have the sensitive transactions.  There is a chance that it could make the switch.  Another aspect is search rankings.   Google has stated that it will rank HTTPS sites higher (http://www.zdnet.com/article/google-confirms-its-giving-https-sites-higher-search-rankings/).  Is this the push that is needed?   Is it enough to push everyone to HTTPS?