DevelopSec

You are here: Home / blog

blog

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.

by Leave a Comment

3rd Party CMS Security

One of the easiest ways to get content available on the Internet is to use a 3rd party content management system (CMS). These systems vary and are usually fairly simple to set up. There is no requirement for any technical knowledge and you can have content up and available within minutes in some cases. No need for that pesky HTML coding or web site management. One of the most common CMS platforms is WordPress (https://wordpress.com). Of course there are many other systems available, but it is common to hear about WordPress when it comes to security, highlighted recently in the article on threat post titled “More Than 1 Million WordPress Sites Open to SQL Injection Attacks“. As I was writing this post I did a quick search for Word Press in the news and this article titled “Bug in WordPress plugin can be exploited to take full control of website” from SC Magazine popped up from today.

To listen to the podcast on this topic you can go to http://developsec.libsyn.com/ep-23-3rd-party-cms-security-thoughts

The previous examples are just a few of the vulnerabilities that have been released related to WordPress. You may be wondering if WordPress is safe to use, and I believe that it is. When we dig a little deeper into many of the news headlines about WordPress security, they often are not vulnerabilities in the core WordPress functionality, but in the plugins that are available. Plugins are 3rd party code that can be added to WordPress to add functionality. An example plugin would be to create a custom signature or bio box below each article. There are also plugins for statistics, multi factor authentication and controlling comment spam.

As mentioned, while vulnerabilities have been identified in the core components, it appears to be far more common for vulnerabilities to be identified in these additional plugins. In most cases, the developers are quick to release a patch once the vulnerability has been identified. The bad news – Many of the patches are not auto-applied. Here are some things to think about if you are implementing a WordPress solution for your systems.

WordPress AutoUpdate
The more recent versions of WordPress support an automatic update feature. If you are using the hosted version of WordPress then the updates should be handled, but if you have decided to host your WordPress site on your own servers this is not the case. Check with your hosting provider to see if they have a mechanism for updating your WordPress installation automatically. Also make sure that you are running the latest version of WordPress and you have enabled the auto-update feature. This will ensure that you have the latest patches for the core system, limiting the exposure of your site.

Know Your Plugins
Plugins have vulnerabilities and may require security patches. The first bit of advice in regards to plugins is to only run the plugins that you absolutely need. The fewer plugins that you have installed means the attack surface is smaller than with a bunch of plugins running out there. Now that you have limited the plugins that are installed, keep an inventory of them. Once you know which ones are installed you can watch the news or different social media feeds to see if any of them are identified. I am not aware of a way for the plugins to auto-update, it is a manual process. If you see that a plugin has been identified as vulnerable make sure that the update (when released) is applied as soon as possible. It is recommended to test the patch out to ensure it will not break anything before hand. If the patch does break something, a determination will have to be made as to whether or not the plugin must be uninstalled or not.

Use Security Controls
Get to know your CMS and what controls exist to help increase your security. If multi factor authentication is available, enable it. If you don’t need some features, then disable them. Maybe your site doesn’t use comments on articles. If that is the case, then turn that feature off.

Remove Default Configurations
Once the site is installed, remove default files that may have been used during installation but are not needed for day to day activity. It is common to see the installers leave behind files that are no longer needed. Scan your system with a tool like WPScan (for WordPress) to see if there are any gaping security holes. Make sure you have set the username and password for the system. Many of these platforms have removed the “default” credentials, but it is your responsibility to make sure that default credentials don’t exist.

Many of the CMS platforms are similar and support many of the same features. The recommendations listed above work for all of these. The point is that you have to be aware of your platforms, what components they use, and how to update those components in a timely manner. The benefits of a CMS are huge when used properly, but can be devastating if attacked.

by Leave a Comment

Black Lists and White Lists: Overview

I came across an interesting post on twitter the other day (https://twitter.com/suffert/status/567486188383379456) that depicts a sidewalk with a sign indicating what wasn’t allowed on the sidewalk. You have seen these before: NO bicycles, skateboards, rollerblades, roller skates, scooters. In the information technology sector, this is known as a black list; a list that defines what is NOT allowed or permitted. You can see black lists all over the place, input validation, output encoding, etc.

BLWL1

The other type of list that we are more commonly seeing is a white list; a list that defines what IS allowed indicating that everything else is NOT allowed. While writing this post I was drawing a blank on where I have seen thin in the physical world and it wasn’t until I was talking to a colleague about this that I realized I had the perfect example: Handicap parking. Handicap parking signs are meant to say that only people with that designation can park there and everyone else is prohibited. In technology, we are seeing it a lot more for input validation and output encoding because it is usually a smaller list compared to a black list. Lets compare the two and see what pros and cons exist.

PROTECTION
Honestly, they both provide good protection when properly defined. Depending on the data, a black list can actually be a strong control. For example, if we have a system that has special escape sequences to identify its control characters. While simplified down (and I know there are more characters than this) SQL uses the (‘) apostrophe as a control character. It is that delimiter to determine what is data and what is command. If SQL only had one control character (the apostrophe) then a black list would be sufficient. Put the apostrophe into the black list and any time that character appeared you could reject it, or escape it. Unfortunately, it is rare that the list will be that small. Using the example of SQL, what happens if in the future the update is released and now the (-) dash is a special character, or the (#) hashtag? Now the list has to be updated and re-deployed and during that time before deployment the application could be vulnerable.

A white list defines exactly what is good and puts everything else up for question. For this example lets take a first name field and look at input validation. If the field is defined as only (a-z) characters then it is easy to set up a white list using a regular expression to say only the letters (a-z) will be accepted. Every other character will be rejected. A regular expression for (a-z) is much simpler than trying to record every other character out there into the black list. What if you forget one? In this case you really don’t forget any because it is such a limited set. In the example I gave earlier with the handicap parking, the sign is simple: One designation that is allowed. What if the sign used a black list? Can you imagine the number of prohibited items there would be?

Another example is in output encoding to protect against HTML context cross-site scripting. I created a document a few years ago showing the different encoding methods in .NET (http://www.jardinesoftware.com/Documents/ASPNET_HTML_Encoding.pdf). Looking at this, there are five characters that are encoded using a black list build into .NET (<,>,”,&,’). This list defines what will get output encoded when using the HTMLEncode method. These are some of the most common characters used to perform cross-site scripting. What if a new character is found to be a problem? This method won’t cover it. With a white list we could say encode everything except for (a-z). Now if a new special character is determined to be a problem it is already encoded for us.

EFFECT ON USER
You wouldn’t expect much effect on the users if all you are doing is saying what is and isn’t allowed based on the use of the data. However, lets go back to the initial example that started all of this, the twitter post. Setting up the black list was most likely fairly simple. Here are some common problem items we see, lets just prohibit them. Of course then someone comes along on a unicycle and while probably shouldn’t be there, are not in violation of the sign. So it appears as a “Good Enough” solution that shouldn’t inhibit any valid users.

I posed the question on what the white list would look like. The first response I got back was “unassisted movement only” from a friend of mine, Tim Tomes.

BLWL2

Seems like a pretty good idea, I am not sure I would have thought of unassisted movement, but lets dig a little deeper. What about a wheelchair or crutches?

The point here is that with a white list, if it is too narrow, it could effect the ability for valid users to use the system. In this case, just using “unassisted movement only”, while a great first draft, would have prohibited anyone in a wheel chair from using the sidewalk. The point is that because a white list will prohibit anything in the list, it must be scrutinized and tested much more to ensure that it is exactly what is needed. Unlike a black list where there can be a control after the black list to continue limiting down items, if it is blocked by the white list there is no way to still have it later on.

CONCLUSION
I like both black lists and white lists and I believe they both have their place. It is important for you to analyze what your situation is to determine what the best course of action will be. In some cases a black list will be exactly what you are looking for, in others the white list will be the right fit. WE often get this feeling that we have to make blanket statements like “White lists are better so only use those.” Situations are different, the lists are different and you want to use the one that best fits your needs. Take a moment to determine what the pros and cons are to each and select the best fit.

by Leave a Comment

Sensitive Data and Storage Issues

Do you know what constitutes sensitive data in your organization? How about in your state or industry? As developers or business analysts we often do not follow the nitty gritty details of sensitive information regulations or laws. Not that we don’t want to enforce them, but often times I think we often just don’t know about them. It is often thought that the CIO, CISO or a privacy officer is responsible for understanding our data and to what level it needs to be protected. I completely believe that these positions should understand the rules and regulations around privacy and what is sensitive data. Although this can be difficult because there are multiple definitions depending on what state and what industry you are in.

When working on developing an application, do you give much thought about data storage and sensitive information much past the user’s password? What is it that defines sensitive information for you and your organization? While it may not be a developers or business analysts main focus, it is important that everyone in the development lifecycle understand that data processed and stored and any rules around it.

The first place to look in most organizations is probably your policies and procedures. Most likely there are data classification documents that describe what is sensitive data and how that data must be handled. If your organization doesn’t have this type of documentation, this is a good time to start thinking about it. Often, this documentation is created by a privacy team, the security team, or some other office outside of the development teams. While it is probably not your job to create the documentation, it is important that you know and understand it.

The second thing to do is to look at your local state regulations for your industry. Regulations or definitions may be different depending on if you are healthcare, PCI, or some other industry. Unfortunately, many states have laws in place (usually around data breach notifications), but they are not standardized across the states. This may be changed soon as there is a movement in the government to create a nationwide breach notification law which may make things a little easier and more consistent. Until then, we are stuck scouring the internet looking for these different laws.

Some examples of these laws are in New Jersey, with this bill that recently went into effect, and Florida with the Florida Information Protection Act of 2014. Both of these are similar, yet have their differences. For example, while NJ calls out Driver’s license and State ID card, Florida also adds Passport, Military ID and other government documents used to verify identity. The Florida law also discusses Username, password and secret questions and answers. The following shows a quick summary of the data that can be considered sensitive:

New Jersey

  • First Name (or initial) and last name linked with one or more of the following:
    • Social Security Number
    • Driver’s License or State ID card Number
    • Address
    • Identifiable health information

Florida

  • First Name (or initial) and last name with one or more of the following:
    • Social Security Number
    • Driver’s License, Passport, Military ID, or other similar number on government document used to verify identity
    • Financial Account Number, Credit or Debit Card Number in combination with
      • Security Code
      • Access Code
      • Password
    • Medical history, mental or physical condition, medical treatment or diagnosis by a health care professional
    • Health insurance policy number or Subscriber ID and any unique identifier used by health insurer to identify individual
  • User name or email address in combination with a password or security question and answer that would permit access to online account

It is important to protect this sensitive information because many times it is what the attackers are after. Both of the laws above require that the information be rendered unusable (encrypted) to be protected. All too often we think only about the user’s password or possibly their social security number, but rarely are we thinking about some of this other information. When we know during design and development what data we use and how it needs to be protected then it is that much easier to do it right the first time.

Take the time to catalog all of the data elements your application uses and how you are protecting them (if needed). You can’t protect what you don’t know you have, so it is important to first inventory and then determine where the holes may be.

Episode 21 of the DevelopSec Podcast discusses this more if you want to take a listen.

by Leave a Comment

Verizon Email API Insecure Direct Object Reference Thoughts and Takeaways

It was recently announced that there was a flaw identified (and since fixed) in the Verizon API that allowed access to Verizon customer email accounts. The way this worked was that there was an ID parameter with the email account’s user ID specified. If a user supplied a different user’s ID name, that user’s email account would be returned. This is known as an Insecure Direct Object Reference. It was also found that the attacker could not only read another user’s email, but also send email from that account. This could be very useful in spear phishing attacks because users are more trustful of emails from their contacts.

Take-Aways

  • Understand the parameters that are used in the application
  • Use a web proxy to see the raw requests and responses for better understanding
  • Create test cases for these parameters that check access to different objects to ensure authorization checks are working properly
  • Implement row-based authorization to ensure the authenticated user can only see his information

The issue that is presented is that the API is not checking if the authenticated user has permission to access the specified mailbox. It would appear that it is only checking that the user is authenticated. Remember that authentication is the process of identifying who the requesting party is. Authorization is the process of determining what the authenticated user has access to. In this situation, the API should first validate that the user is authenticated, and then when a request is made for a resource (email account in this example) verify that that user is authorized to access that account before allowing it.

Unfortunately, many API’s are vulnerable to this type of attack because there is an assumption that the user can’t change the parameter values due to a lack of user interface. It is imperative that developers and QA testers both use a proxy when testing applications to be able to manipulate these types of parameters. This allows testing for unauthorized access to different objects. This is a very simple test case that should be included for every application, and not just for APIs. If you see a parameter value, make sure it is being properly tested from a security standpoint. For example, and ID field that may be an integer may get tested to make sure that the value cannot be any other type of data, but must also be checked to see if different values give access to unauthorized data.

It was also mentioned that the API didn’t use HTTPS for its communication channel. Using HTTP allows other user’s along the communication line to intercept the request and response data, potentially opening up the user to a variety of vulnerabilities. Make sure you are using the proper communication channel to protect your users in your mobile applications as well as the web applications.

by Leave a Comment

OneStopParking Breach Thoughts and Takeaways

It was recently announced that OneStopParking.com suffered from a data breach exposing customer credit card data. According to the report, the breach occurred due to missing patches in the application’s Joomla install. Apparently the patches caused some problems with the application so they were pushed back. The patches in question were released in September of 2014.

Take-Aways

  • Implement a patch management program
  • Use a web application firewall (WAF) for extended coverage

It is common to come across systems that are not fully patched. Of course there are a multitude of reasons for these scenarios. In this case, the patch caused a problem with the application which means that the developer has to fix their application before the patch can be applied, or not apply the patch at all. All too often the issue with missing patches is that the company just doesn’t have a good patch management process. This is very common when a system uses tools like Joomla or other 3rd party frameworks because they don’t even know updates are available. We are seeing these types of frameworks getting better at alerting the system administrator to the availability of the updates, which is a step forward.

In the case of OneStopParking.com it is nice to hear that they were aware of the patch. That is half of the battle. Unfortunately for them it apparently didn’t play nice with their application so they were not able to install it, ultimately leading to a breach. This example shows that there are risks to any 3rd party frameworks that you use and sometimes you may be at their mercy when it comes to the patches. It can be a difficult decision to determine if the application should continue running unpatched, or be taken offline until everything is working properly.

It is difficult for outsiders to try and determine the risk vs reward in a situation like this. It is a gamble and unfortunately, in this case, one that didn’t pay off. This is a good lesson in patching and 3rd party frameworks. If you are using these frameworks, make sure that you have a way to track what frameworks are in use and what security risks may arise at any given time. Create a plan to test the patches and apply them when appropriate.

If applying a security patch causes an issue, think about alternative methods for protecting that application until the patch can be applied. One option is to install a web application firewall (WAF) in front of the application that can be configured to protect the feature that has the security flaw. While this may not be a permanent solution, it is often recommended for this type of situation.