DevelopSec

developer awareness

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

Untrusted Data: Quick Overview

In the application security community it is common to talk about untrusted data. Talk about any type of injection attack (SQLi, XSS, XXE, etc) and one of the first terms mentions is untrusted data. In some cases it is also known as user data. While we hear the phrase all the time, are we sure everyone understands what it means? What is untrusted data? It is important that anyone associated with creating and testing applications understand the concept of untrusted data.

Unfortunately, it can get a little fuzzy as you start getting into different situations. Lets start with the most simplistic definition:

Untrusted data is data that is controlled by the user.

Client-Side

While this is very simple, it is often confusing to many. When we say controlled by the user, what does that really mean? For some, they stop at data in text boxes or drop down lists, overlooking hidden fields, request headers (cookies, referer, user agent, etc), etc. And that is just on the client side.

From the client perspective, we need to include any data that could be manipulated before it gets to the server. That includes cookie values, hidden form fields, user agent, referer field, and any other item that is available. A common mistake is to assume if there is no input box on the page for the data, it cannot be manipulated. Thanks to browser plugins and web proxies, that is far from the truth. All of that data is vulnerable to manipulation.

Server-Side

What about on the server side? Can we assume everything on the server is trusted? First, lets think about the resources we have server-side. There are configuration files, file system objects, databases, web services, etc. What would you trust out of these systems?

It is typical to trust configuration files stored on the file system of the web server. Think your web.xml or web.config files. These are typically deployed with the application files and are not easy to update. Access to those files in production should be very limited and it would not be easy to open them up to others for manipulation. What about data from the database? Often I hear people trusting the database. This is a dangerous option. Lets take an example.

Database Example

You have a web application that uses a database to store its information. The web application does a good job of input validation (type, length, etc) for any data that can be stored in the database. Since the web application does good input validation, it lacks on output encoding because it assumes the data in the database is good. Today, maybe no other apps write to that database. Maybe the only way to get data into that database is either via SQL Script run by a DBA or through the app with good input validation. Even here, there are weaknesses. What if the input validation misses an attack payload. Sure the validation is good, but does it catch everything? What if a rogue DBA manipulates a script to put malicious data into the database? Could happen.

Now, think about the future, when the application owner requests a mobile application to use the same database, or they decide to create a user interface for data that previously was not available for update in the application previously. Now, that data that was thought to be safe (even though it probably wasn’t) is now even less trusted. The mobile application or other interfaces may not be as stringent as thought.

The above example has been seen in real applications numerous times. It is a good example of how what we might think at first is trusted data really isn’t.

Web services are similar to the database. Even internal web services should be considered untrusted when it comes to the validity of the data being returned. We don’t know how the data on the other side of that service is being handled, so how can we trust it?

Conclusion

When working with data, take the time to think about where that data is coming from and whether or not you are willing to take the risk of trusting it. Think beyond what you can see. It is more than just fields on the form that users can manipulate. It is more than just the client-side data, even though we use terms like user controlled data. There is a lot of talk about threat modeling in application security, and it is a great way to help identify these trust boundaries. Using a data flow model and showing the separation of trust can make it much easier to understand what data we trust and what we don’t. At the bottom of this article is a very basic, high level, rough draft data flow diagram that shows basic trust boundaries for some of the elements I mentioned above. This is just an example and is not indicative of an actual system.

When it comes to output encoding to protect against cross site scripting or proper encoding for SQL, LDAP, or OS calls, the safest approach is to just perform the encoding. While you may trust a value from the web.config it doesn’t mean you can’t properly do output encoding to protect from XSS. From a pure code perspective, that is the most secure code. Assuming the data is safe, while it may be, does increase risk to some level.

If you are new to application security or training others, make sure they really understand what is meant by untrusted data. Go deeper than what is on the surface. Ask questions. Thank about different scenarios. Use stories from past experience. Once the concept is better understood it makes triaging flaws from the different automated tools much easier and should reduce number of bugs going forward.

Example Data Flow Diagram Showing Trust Boundaries
(This is only an example for demonstration purposes.)

Ex. Data Flow

by Leave a Comment

What is a Penetration Test

You spend all day looking at requirements, creating functionality and doing some testing of the code you just created. You have been working for months on this application making sure it worked as expected. The testers have been diligently working to ensure that the requirements have been fulfilled and the application will work as expected and allow the end users the capability to solve a specific set of tasks. Then it happens… You find out that a penetration test is coming. Unfortunately for many, they really don’t understand what that means. Often times it is met with anger or resentment. How many people are actually excited to see the “pen testers” coming?

A penetration test, or pen test, is nothing that should be feared. While it is considered to be an adversarial act, the end goal is to assess the security of the environment or application to identify security risks before the “bad guys” do and help provide recommendations to reduce that risk.

That doesn’t sound that bad right, or does it? I may have left out the fact that a pen test may include exploiting your applications, retrieving your sensitive data, or even social engineering staff members to get what they want. But seriously, that is not as bad as it sounds and a pen test done right can be a very positive experience.

A big issue with a pen test is that in different companies and communities it has a different meaning. Sure the simple definition above should always fit that, but the scope that is defined and the results that are received can be very different. Here are some examples of some different types of pen tests (network and application specific).

Basic Pen Test (Scanner Only)
In my opinion this is not a pen test, but rather a vulnerability scan. In this situation, the “testers” will run a tool like Nessus or Qualys and then provide the results of that scan. The test is usually started by providing a set of IP addresses or URLs and then the scanner is configured and let loose. A few hours later, or maybe days, you get a report from the tool that is then passed on to the client. This type of assessment can make it difficult to identify the true risk of the vulnerabilities identified because they were not fully exploited. Maybe the scanner identified that there was SQL injection, but it didn’t follow through with the vulnerability to see how much access that provided.

Limited Scope Pen Test (Fairly Typical)
This type of test has scope limitations, meaning that it might just include a subset of IP addresses, specific functionality of an application, or how far you can take an exploit if one is found. This is fairly typical as it is rare to find a pen test that is fully open with everything on the table. The scope is defined in the rules of engagement as to what can and cannot be performed.

Full Pen Test (Not as Common)
Everything is game in this type of test. Be prepared to receive phishing emails or phone calls trying to get you to fall for a malicious attack. Your social profiles may also be a concern for you as when everything is game, a tester will use any avenue they can to try and gain access. All IP’s or the entire application is in scope. It can be very difficult to stop the testers from gaining access to systems when everything is in play.

Both the Limited and Full scope pen tests usually consist of both automated tools and lots of manual testing to identify the security risks.

In addition to the types of tests, we need to think about the different goals the client may have for requesting a pen test. Here is a quick rundown of some of the goals we see during a test.

Compliance Check Box
This is commonly seen by organizations that fall under some form of compliance, like PCI. “We are required to do this, so lets just get it done.” Often times the client is not really looking for security risks, but rather just trying to check the box. This doesn’t mean you should short change the testing efforts. The purpose of having a test performed is to help identify and reduce risk to the company.

Assess the Security of the Endpoint
This is seen in most tests where the client wants a vulnerability assessment of their endpoint, whether it is an IP or an application, so they can work to mitigate the risks identified. This type of test can be broken down into multiple levels, depending on how far the client wants to go. Some pen tests with this goal may not allow exploitation, making the goal just to identify vulnerabilities. Others, however, have higher goals of gaining access to internal networks, exploiting vulnerabilities, or gaining domain admin rights. This all depends on the goal of the organizer of the test.

High Stakes Goals
Some tests have very limited, yet high stakes goals. For example, many tests just want to see if the tester can gain domain administrator rights to the domain. In these types of tests, many of the other “vulnerability assessment” type findings may be overlooked. While they may be identified to help reach the ultimate goal, the goal is not to identify all, or as many as possible, of the risks to the endpoint.

In most tests, it is the assessing the security of the endpoint that we see the most. The goal is to identify the different risks, and while gaining internal access or domain administrator rights is great, the client is looking for more actionable results to it.

When testing occurs, often times the development teams have very little involvement. They may know it is going on, or have to provide some support if the applications are not configured properly, but that is usually the extent of it. It is important that we understand the goal and type of testing that is being performed. Also understand the purpose of the test should be to provide insight we didn’t have previously that could help us decrease the risk to our company.

Penetration tests, while “adversarial”, should be a collaborative effort with a positive feel. Don’t look at it as an “us” vs. “them”. The team was brought in for a specific task. The task should produce actionable results that are relevant to the environment. If they don’t, then it may be time to switch testing companies. Keep an open line of communication and a positive attitude.

by Leave a Comment

Static Analysis: Analyzing the Options

When it comes to automated testing for applications there are two main types: Dynamic and Static.

  • Dynamic scanning is where the scanner is analyzing the application in a running state. This method doesn’t have access to the source code or the binary itself, but is able to see how things function during runtime.
  • Static analysis is where the scanner is looking at the source code or the binary output of the application. While this type of analysis doesn’t see the code as it is running, it has the ability to trace how data flows the the application down to the function level.

An important component to any secure development workflow, dynamic scanning analyzes a system as it is running. Before the application is running the focus is shifted to the source code which is where static analysis fits in. At this state it is possible to identify many common vulnerabilities while integrating into your build processes.

If you are thinking about adding static analysis to your process there are a few things to think about. Keep in mind there is not just one factor that should be the decision maker. Budget, in-house experience, application type and other factors will combine to make the right decision.

Disclaimer: I don’t endorse any products I talk about here. I do have direct experience with the ones I mention and that is why they are mentioned. I prefer not to speak to those products I have never used.

Budget

I hate to list this first, but honestly it is a pretty big factor in your implementation of static analysis. The vast options that exist for static analysis range from FREE to VERY EXPENSIVE. It is good to have an idea of what type of budget you have at hand to better understand what option may be right.

Free Tools

There are a few free tools out there that may work for your situation. Most of these tools depend on the programming language you use, unlike many of the commercial tools that support many of the common languages. For .Net developers, CAT.Net is the first static analysis tool that comes to mind. The downside is that it has not been updated in a long time. While it may still help a little, it will not compare to many of the commercial tools that are available.

In the Ruby world, I have used Brakeman which worked fairly well. You may find you have to do a little fiddling to get it up and running properly, but if you are a Ruby developer then this may be a simple task.

Managed Services or In-House

Can you manage a scanner in-house or is this something better delegated to a third party that specializes in the technology?

This can be a difficult question because it may involve many facets of your development environment. Choosing to host the solution in-house, like HP’s Fortify SCA may require a lot more internal knowledge than a managed solution. Do you have the resources available that know the product or that can learn it? Given the right resources, in-house tools can be very beneficial. One of the biggest roadblocks to in-house solutions is related to the cost. Most of them are very expensive. Here are a few in-house benefits:

  • Ability to integrate directly into your Continuous Integration (CI) operations
  • Ability to customize the technology for your environment/workflow
  • Ability to create extensions to tune the results

Choosing to go with a managed solution works well for many companies. Whether it is because the development team is small, resources aren’t available or budget, using a 3rd party may be the right solution. There is always the question as to whether or not you are ok with sending your code to a 3rd party or not, but many are ok with this to get the solution they need. Many of the managed services have the additional benefit of reducing false positives in the results. This can be one of the most time consuming pieces of a static analysis tool, right there with getting it set up and configured properly. Some scans may return upwards of 10’s of thousands of results. Weeding through all of those can be very time consuming and have a negative effect on the poor person stuck doing it. Having a company manage that portion can be very beneficial and cost effective.

Conclusion

Picking the right static analysis solution is important, but can be difficult. Take the time to determine what your end goal is when implementing static analysis. Are you looking for something that is good, but not customizable to your environment, or something that is highly extensible and integrated closely with your workflow? Unfortunately, sometimes our budget may limit what we can do, but we have to start someplace. Take the time to talk to other people that have used the solutions you are looking at. Has their experience been good? What did/do they like? What don’t they like? Remember that static analysis is not the complete solution, but rather a component of a solution. Dropping this into your workflow won’t make you secure, but it will help decrease the attack surface area if implemented properly.

This article was also posted at https://www.jardinesoftware.net

by Leave a Comment

The Importance of Baselines

To understand what is abnormal, we must first understand what is normal. All too often we have overlooked the basic first step of understanding and recording our baselines. Whether it is for network traffic, data input, or binary sizes it is imperative we understand what is normal. Once we have an understanding of what normal is it becomes easier to start identifying abnormalities that can be of concern.

Related podcast: Ep. 24: The Importance of Baselines

Take a moment to think about how we determine if our body is healthy or not. Of course, healthy can be relative. In general, we have some baselines. We know that the normal body temperature is 98.6 degrees with a slight deviation. WE have ranges for good pressure, cholesterol, blood/sugar, etc. With the body there are usually “normal” ranges for many of these values. This is true for our information systems as well.

What is the average size of a 302 redirect from a web server: 1 KiloByte, 100 KiloBytes, 1 MegaByte? Lets say that it is less then 1kb, this makes it easier to understand that if you have 302 redirects that are 500kb then something may be going on and an investigation is in order. While this doesn’t always mean there is a problem, it is that initial event to look at the situation to determine if something is going on.

Having a baseline of the size of applications that are installed on your system may also help identify if an application binary has been modified. Maybe a malicious application has been placed on the system that replaces calc.exe but is 2MB larger than the original one. It may be possible that this was just a software update, but could also mean it is an imposter.

These same questions apply to network traffic as well. Understanding the types of traffic and amount of traffic that generally pass through the network is critical when it comes to identifying an attack. It is not enough to just say a spike in traffic at any given time is a potential concern. It may be possible a legitimate event was happening. Imagine if your backups ran between 3 and 5am every morning and the network saw a spike in traffic. If you didn’t usually watch the traffic and saw that spike one day you might have serious concern. However, if you understand the traffic patterns it may turn out to be an ordinary event.

Once you understand these baselines it is possible to start creating events for things that are now abnormal. No guarantee that these events are malicious or of concern, but it is the starting point to what you are going to investigate. With so many things going on in our applications and networks, these baselines turn out to be critical for securing our systems.

The truth is, creating these baselines is going to be time consuming. Obviously a lot of that depends on your systems and the complexity of them. The time will be required, but is necessary for being able to detect many security related events. The good news is that you don’t need a security group to do this. The network administrators or engineers can do most of this since it is the lifelines of their networks that you will be measuring. The application developers and QA can certainly understand what is normal for the application. It doesn’t have to be a complex task. Start out small, use a spreadsheet or some other collaborative solution to record these values. Of course, that isn’t easy to trigger alerts off of, but that can be an initial first step. Once you get that maturing, then looking at solutions to identify these abnormalities and trigger events becomes imperative.

by Leave a Comment

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.