DevelopSec

secure coding

by Leave a Comment

Unsupported Browser Support

Ok, so the title is a bit counter-intuitive. I recently saw an article talking about the end of support for some of the Internet Explorer versions out there (http://www.computerworld.com/article/3018786/web-browsers/last-chance-to-upgrade-ie-or-switch-browsers-as-microsofts-mandate-looms.html) and got to thinking about the number of sites that still require supporting some of these older versions of browsers. This is typically more common in the big corporate enterprises, as they have the legacy systems and tend to move slower upgrading internal software.

The unfortunate reality is that, in some environments, you are stuck supporting outdated browsers. Whether it is an internal application with requirements for the network, or your client base is just slow to move on. This requirement also puts those users, and potentially the company network at risk since there are no more security updates for these browsers.

Over the past few years, browsers have been taking on some of the burden of stopping some forms of application security attack vectors. We saw the addition of the cross-site scripting filters added a while back to help detect and neutralize some reflective cross-site scripting attacks. We also saw browsers start to support custom response headers to indicate content security policy, frame handling, etc.. Some of these protections are supported across all browsers, while others are limited to specific browsers, or versions of browsers. As we see these unsupported browsers still out there, it reminds us that as developers, we cannot rely just on browser functionality for security.

While we may not be able to control what version of a browser we support, well we can but we can’t, we can still make sure that our application is as secure as possible. Lets take cross-site scripting as an example. Sure, for reflected XSS, we could just sent the X-XSS-Protection response header and hope for the best. It might neutralize a few instances, but that is a pretty poor defense mechanism. First, there have been numerous bypasses for these types of client-side blocking attempts. Second, it is our responsibility, as developers, to properly handle our data. That starts with good input validation and ends with properly encoding that data before we send it to the browser.

I am not advocating not using the different response headers. Bugs can be missed and having another control there to help reduce the chance of a vulnerability being exploited is a good thing. But the first effort should be spent on making sure the output is encoded properly in the first place. This is where testing comes into play as well, making sure that we are validating that the encoding is working as expected.

By properly protecting our apps with good application security practices, it shouldn’t matter what browser the client is using. Does the end user run a higher risk, in general, by running out of date software. You bet. That doesn’t mean our application has to be the source of that added risk.

If you are stuck supporting out dated browsers due to corporate compliance or other reasons, take the time to analyze the situation. Determine why that browser is needed and what possible solutions are there. Raise the issue up within the organization, identifying the risks that are exposed due to the use of outdated browsers. While the organization may already know this, it doesn’t hurt to say it again.

by Leave a Comment

Disabling Paste for Passwords?

Passwords, while a simple concept, are one of the most complex issues in security. A majority of user authenticated systems rely on a password to verify the end user. Over the years we have seen many different recommendations for strong passwords. I have talked about this subject many times.

The complexity, while difficult to define, has gotten more difficult over time. At first, it was 8 characters with upper, lower case characters and a number or special character. The focus has shifted away from the types of characters and toward the length of the password. Common recommendations now say a strong password is at least 15 characters.

A popular recommendation from security professionals has been to use a password manager. A password manager allows you to store your passwords and protect them with a master password. The master password means that you only have to remember one long, complex password.

Using a password manager has many benefits. First, it allows you to store long, complex passwords without worrying about forgetting them. Second, it allows you to just copy and paste your passwords when signing into an application. This may not seem like that big of a deal, but many malicious programs use key loggers to steal passwords. If you paste the password in, and don’t type it, a key logger is useless. There are ways to grab data from the clipboard, but they are a less used tactic.

Some applications have started disabling the paste feature on password fields. This exists on some change password forms. The concern is that a typo entered in the password field would go unnoticed if pasted into the verify password field. The risk is the escalated customer support costs for lost passwords or account lockouts. Whether this is a valid risk is up to you. Few good reasons exist for disabling the paste feature on a password field.

The concern of recent is that the password field on the login form disables paste. In turn, this breaks many password managers. The benefits of good password management become degraded. Often, the reasons are due to a misunderstanding of how passwords are attacked.

Attackers do not rely on paste functionality for brute force attempts. In most situations, the attacker doesn’t even use the user interface for the attack. These type of attributes become useless against an attacker. Unfortunately, they only have a negative effect on the end user.

Don’t confuse disabling paste with disabling the autocomplete feature of a password field. Autocomplete is used for browsers to remember data for specific fields. While this is like what a password manager does, they are different. Autocomplete has been abused in the past and represents different issues.

Applications should be encouraging the use of password managers. They provide better password hygiene and ultimately help reduce the risk to the application. If you are making the decision to block the paste feature, prepare to answer to that decision. If the decision is well thought out and understood it will be easier to accept. Understand the reasoning behind the decision. It will generate a more enjoyable user experience.

If you experience an application that blocks your password manager, let them know. It is possible that they don’t even know it is an issue. As a customer, your opinion should matter. Stay positive and provide accurate information. Stay away from a negative stance. It will just make the business ignore your position.

by Leave a Comment

Input Validation: Keep It Simple

Attackers take advantage of an application by manipulating the inputs to the system. For example, a first name field or even a request header like the user-agent. Applications wouldn’t be very useful if they didn’t accept any input from the end user. Unfortunately, this is the key attack vector. One of the basic techniques used to help protect a system is to us input validation, which assesses the input to determine if it is should be accepted.

Many development groups have fought with the concept of input validation in regards to how much should be done. Get to extreme with it and you may never implement it at all. It is important to understand what your goals are for the input validation, goals that should align with what the application does. Make the validation to complex and it is too easy to introduce errors. Start out with a simple plan, don’t go for the gusto out of the start gate. Here are some tips for starting out with input validation.

Type
One of the easiest checks to implement is checking the data type of the input field. If you are expecting a date data type and the input received is not a valid date then it is invalid and should be rejected. Numbers are also fairly simple to validate to ensure they match the type expected. Many of the most popular frameworks provide methods to determine if a string matches a specific data type. Use these features to validate this type of data. Unfortunately, when the data type is a free form string then the check isn’t as useful. This is why we have other checks that we will perform.

Range
You have determined that the input is of the correct type, say a number or a date. Now it is time to validate that it falls within the correct range of acceptable values. Imagine that you have an age field on a form. Depending on your business cases, lets say that a valid age is 0-150. It is a simple step to ensure that the value entered falls into this valid range. Another example is a date field. What if the date represents a signed date and can’t be in the future. In this case, it is important to ensure that the value entered is not later than the current day.

Length
This is really more for the free form text fields to validate that the input doesn’t exceed the expected length for the field. In many cases, this lines up with the database or back end storage. For example, in SQL Server you may specify a first name field that is 100 characters or a state field that only allows two characters for the abbreviation. Limiting down the length of the input can significantly inhibit some of the attacks that are out there. Two characters can be tough to exploit, while possible depending on the application design.

White Lists
White lists can be a very effective control during input validation. Depending on the type of data that is being accepted it may be possible to indicate that only alphabetical characters are acceptable. In other cases you can open the white list up to other special characters but then deny everything else. It is important to remember that even white lists can allow malicious input depending on the values required to be accepted.

Black Lists
Black lists are another control that can be used when there are specifically known bad characters that shouldn’t be allowed. Like white lists, this doesn’t mean that attack payloads can’t get through, but it should make them more difficult.

Regular Expressions
Regular expressions help with white and black lists as well as pattern matching. With the former it is just a matter of defining what the acceptable characters are. Pattern matching is a little different and really aligns more with the range item discussed earlier. Pattern matching is great for free form fields that have a specific pattern. A social security number or an email address. These fields have an exact format that can be matched, allowing you to determine if it is right or not.

Test Your Validation
Make sure that you test the validation routines to ensure they are working as expected. If the field shouldn’t allow negative numbers, make sure that it rejects negative numbers. If the field should only allow email addresses then ensure that it rejects any pattern that doesn’t match a valid email address.

Validate Server Side
Maybe this should have been first? Client side validation is a great feature for the end user. They get immediate feedback to what is wrong with their data without having that round trip to the server and back. THAT IS EASILY BYPASSED!! It is imperative that the validation is also checked on the server. It is too easy to bypass client side validation so this must be done at the server where the user cannot intercept it and bypass it.

Don’t Try To Solve All Problems
Don’t try to solve all output issues with input validation. It is common for someone to try and block cross site scripting with input validation, it is what WAFs do right? But is that the goal? What if that input isn’t even sent to a browser? Are you also going to try and block SQL Injection, LDAP Injection, Command Injection, XML Injection, Parameter Manipulation, etc. with input validation? Now we are getting back to an overly complex solution when there are other solutions for these issues. These types of items shouldn’t be ignored and that is why we have the regular expressions and white lists to help decrease the chance that these payloads make it into the system. We also have output encoding and parameterized queries that help with these additional issues. Don’t spend all of your time focusing on input validation and forget about where this data is going and protecting it there.

Input validation is only half of the solution, the other half is implemented when the data is transmitted from the application to another system (ie. database, web browser, command shell). Just like we don’t want to rely solely on output encoding, we don’t want to do that with input validation. Assess the application and its needs to determine what solution is going to provide the best results. If you are not doing any input validation, start as soon as possible. It is your first line of defense. Start small with the Type/Range/Length checks. When those are working as expected then you can start working into the more advanced input validation techniques. Make sure the output encoding routines are also inplace.

Don’t overwhelm yourself with validating every possible attack. This is one cog in the system. There should also be other controls like monitoring and auditing that catch things as well. Implementing something for input validation is better than nothing, but don’t let it be a false sense of security. Just because you check the length of a string and limit it to 25 characters, don’t think a payload can’t be sent and exploited. It is, however, raising the bar (albeit just a little).

Take the time to assess what you are doing for input validation and work with the business to determine what valid inputs are for the different fields. You can’t do fine validation if you don’t understand the data being received. Don’t forget that data comes in many different forms or encodings. Convert all data to a specific encoding before you perform any validation on it.