Monthly Archives: March 2015

Amazon XSS: Thoughts and Takeaways

It was recently identified, and Amazon was quick (2 days) to fix it, that one of their sites was vulnerable to cross-site scripting. Cross-site scripting is a vulnerability that allows an attacker to control the output in the user’s browser. A more detailed look into cross-site scripting can be found on the OWASP site.

Take-Aways


  • QA could have found this
  • Understand your input validation routines
  • Check to make sure the proper output encoding is in place in every location user supplied data is sent to the browser

Vulnerabilities like the one listed above are simple to detect. In fact, many can be detected by automated scanners. Unfortunately, we cannot rely on automated scanners to find every vulnerability. Automated scanning is a great first step in identifying flaws like cross-site scripting. It is just as important for developers and QA analysts to be looking for these types of bugs. When we break it down, a cross-site scripting flaw is just a bug. It may be classified under “security” but nonetheless it is a bug that effects the quality of the application.

We want to encourage developers and QA to start looking for these types of bugs to increase the quality of their applications. Quality is more than just if the app works as expected. If the application has a bug that allows an attacker the ability to send malicious code to another user of the application that is still a quality issue.

If you are a developer, take a moment to think about what output you send to the client and if you are properly encoding that data. It is not as simple as just encoding the less than character or greater than character. Context matters. Look for the delimiters and control characters that are relative to where the output is going to determine the best course of action. It is also a good idea to standardize the delimiters you use for things like HTML attributes. Don’t use double quotes in some places, single quotes in others and then nothing in the rest. Pick one (double or single quotes) and stick to it everywhere.

If you are a QA analyst, understand what input is accepted by the application and then where that output is then used again. The first step is testing what data you can send to the server. Has there been any input validation put in place? Input validation should be implemented in a way to limit the types and size of data in most of the fields. The next step is to verify that any special characters are being encoded when they are returned back down to the browser. These are simple steps that can be performed by anyone. You could also start scripting these tests to make it easier in the future.

It is our (dev,qa,ba,application owners) responsibility to create quality applications. Adding these types of checks do not add a lot of time to the cycle and the more you do it, the less you will start to see allowing you to increase the testing timelines. Bugs are everywhere so be careful and test often.

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?

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.

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.