DevelopSec

developer security

by

Input validation is less about specific vulnerabilities

Security takes a layered approach to reduce the risk to our organization. Input validation is the perfect example of one of these layers. In most cases, input validation is 1 factor in a multi-pronged approach to protecting against common vulnerabilities.

Take any course on secure development and they will, or should, mention input validation as a mitigating control for so many vulnerabilities. You might notice that it always comes with a but. Use input validation, but also use output encoding. Use input validation, but also use parameterized queries.

The reason for this is that input validation that covers every potential vulnerability is hard, if not impossible. Even input validation for a specific vulnerability can be complex and difficult. We have to walk this line of good validation, but also a useable application.

I always recommend not trying to look for specific vulnerabilities or attack strings within an input validation function. That turns into a blacklist of attacks that is impossible to keep up with. In addition, you may be looking for attack strings that don’t matter to that input.

One of the challenges is not knowing where the input will actually be used. Is the data going to the database? Is the data going to a database and then going to the browser? If the data is going to the browser, what context will it be in? If you don’t know how that data will be used, how do you know what attack strings to look for?

Instead of focusing on vulnerabilities, you should spend the time to define what good data looks like for that field. What type of data is expected? Is it an integer, a date, a string? What are the valid range of values? How long should the data be? I will discuss these in just a moment.

These limitations will not stop all attacks. There is no argument there. They are just going to help make sure the data is acceptable or the field. It is possible that a cross-site scripting attack string is valid input. That can be ok. You have limited the potential attacks. Then there is the but, remember? In this case, you would have output encoding to protect the app from cross-site scripting.

Let’s look at some of these items in more detail.

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.

Format
Some fields may have a specific format they must match. For example, a social security number may have to match DDD-DD-DDDD. An account number may have a specific format of DDDDDSSS. There are a lot of options for specific formats. If you verify that the data matches the expected format, this can drastically cut down on potential vulnerabilities because many attacks will not be possible when matching the format.

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

XSS in a Script Tag

Cross-site scripting is a pretty common vulnerability, even with many of the new advances in UI frameworks. One of the first things we mention when discussing the vulnerability is to understand the context. Is it HTML, Attribute, JavaScript, etc.? This understanding helps us better understand the types of characters that can be used to expose the vulnerability.

In this post, I want to take a quick look at placing data within a <script> tag. In particular, I want to look at how embedded <script> tags are processed. Let’s use a simple web page as our example.

<html>
	<head>
	</head>
	<body>
	<script>
		var x = "<a href=test.html>test</a>";
	</script>
	</body>
</html>

The above example works as we expect. When you load the page, nothing is displayed. The link tag embedded in the variable is rated as a string, not parsed as a link tag. What happens, though, when we embed a <script> tag? 

<html>
	<head>
	</head>
	<body>
	<script>
		var x = "<script>alert(9)</script>";
	</script>
	</body>
</html>

In the above snippet, actually nothing happens on the screen. Meaning that the alert box does not actually trigger. This often misleads people into thinking the code is not vulnerable to cross-site scripting. if the link tag is not processes, why would the script tag be. In many situations, the understanding is that we need to break out of the (“) delimiter to start writing our own JavaScript commands. For example, if I submitted a payload of (test”;alert(9);t = “). This type of payload would break out of the x variable and add new JavaScript commands. Of course, this doesn’t work if the (“) character is properly encoded to not allow breaking out.

Going back to our previous example, we may have overlooked something very simple. It wasn’t that the script wasn’t executing because it wasn’t being parsed. Instead, it wasn’t executing because our JavaScript was bad. Our issue was that we were attempting to open a <script> within a <script>. What if we modify our value to the following:

<html>
	<head>
	</head>
	<body>
	<script>
		var x = "</script><script>alert(9)</script>";
	</script>
	</body>
</html>

In the above code, we are first closing out the original <script> tag and then we are starting a new one. This removes the embedded nuance and when the page is loaded, the alert box will appear.

This technique works in many places where a user can control the text returned within the <script> element. Of course, the important remediation step is to make sure that data is properly encoded when returned to the browser. By default, Content Security Policy may not be an immediate solution since this situation would indicate that inline scripts are allowed. However, if you are limiting the use of inline scripts to ones with a registered nonce would help prevent this technique. This reference shows setting the nonce (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src).

When testing our applications, it is important to focus on the lack of output encoding and less on the ability to fully exploit a situation. Our secure coding standards should identify the types of encoding that should be applied to outputs. If the encodings are not properly implemented then we are citing a violation of our standards.

by Leave a Comment

MySpace Account Takeover – Take-aways

Have you ever forgotten your password, or lost access to your accounts? I know I have. The process of getting your access back can range from very easy to quite difficult. In one case, I had an account that required that a pin code be physically mailed to me in 7-10 days. Of course, this was a financial account that required extra protections.

I came across this article (https://www.wired.com/story/myspace-security-account-takeover/) that identified that MySpace’s process for regaining access to an account was easily by-passable with just a few pieces of information that is commonly easily found.

According to the issue reported, the following details were needed to gain control of an account:

  • Account Holder’s Name
  • UserName
  • Date of Birth

In addition, the email address was part of the form, but was not actually validated.

With the amount of information available on social media platforms, and even though past breaches, it is very difficult to come up with good questions to help validate a user is who they say they are. In this case, the first 2 pieces of information are reportedly available on a user’s account page and are not difficult to find. It is critical that we give great consideration to the way we attempt to validate a user’s identity.

Security or secret questions have been known to be weak for a long time. While they can help provide some assistance in identifying the user, they should not be used alone. One recommendation is to include a side channel for some verification. For example, requiring a user to receive an email at the address on record before answering these questions helps reduce some of the risk. This method now requires that an attacker gain access to the user’s email account to receive a temporary account reset link. Although this is possible, it adds another hurdle to help protect the user’s account.

Similarly, you could look to send a code to a phone number that is currently on record. Like email, it would then require the interception of the phone message, adding difficulty to the process. One of the points here is that you only want to send to email or phone that is already on record. Never allow the user to provide a new email address or phone number as they could add an untrusted phone number and easily take over the account.

There was another piece of this that should be considered, the unvalidated email address. The request for the email address in this reset process may have been meant as another verification of account information. However, as commonly seen, the value wasn’t actually validated on the server. This is an easy oversight to make when working with web forms.

Remember that validation should always be performed on the server. This is because it is simple to bypass client-side validation with the use of simple add-ins or a web proxy.

Validation of data fields should be a standard part of QA testing. Ensure that when testing forms, such as the account recovery, that the form reacts accordingly with many types of inputs. This includes what happens if a field is not provided or if it does not line up with the expected answer. This same situation has been seen on other sites where the current password may be required to update the password, but is not actually verified.

These types of stories help remind us to review these types of functions and features within our application. For older applications, it may have been a while since we have touched these features and how they were designed initially is no longer recommended. Take a moment to look back at your account recovery process to make sure it is up to par with your current requirements.

Looking for some help with your application security program? Just want someone to talk to about these types of topics? Reach out to us. We are here to help and offer a wide range of services to help make your day easier. Reach out to james@developsec.com for more information.

by Leave a Comment

Properly Placing XSS Output Encoding

Cross-Site Scripting flaws, as well as other injection flaws, are pretty well understood. We know how they work and how to mitigate them. One of the key factors in mitigation of these flaws is output encoding or escaping. For SQL, we escape by using parameters. For cross-site scripting we use context sensitive output encoding.

In this post, I don’t want to focus on the how of output encoding for cross-site scripting. Rather, I want to focus on when in the pipeline it should be done. Over the years I have had a lot of people ask if it is ok to encode the data before storing it in the database. I recently came across this insufficient solution and thought it was a good time to address it again. I will look at a few different cases that indicate why the solution is insufficient and explain a more sufficient approach.

The Database Is Not Trusted

The database should not be considered a trusted resource. This is a common oversight in many organizations, most likely due to the fact that the database is internal. It lives in a protected portion of your production environment. While that is true, it has many sources that have access to it. Even if it is just your application that uses the database today, there are still administrators and update scripts that most likely access it. We can’t rule out the idea of a rogue administrator, even if it is very slim.

We also may not know if other applications access our database. What if there is a mobile application that has access? We can’t guarantee that every source of data is going to properly encode the data before it gets sent to the database. This leaves us with a gap in coverage and a potential for cross-site scripting.

Input Validation My Not Be Enough

I always recommend to developers to have good input validation. Of course, the term good is different for everyone. At the basic level, your input validation may limit a few characters. At the advanced level it may try to limit different types of attacks. In some cases, it is difficult to use input validation to eliminate all cross-site scripting payloads. Why? Due to the different contexts and the types of data that some forms accept, a payload may still squeak by. Are you protecting against all payloads across all the different contexts? How do you know what context the data will be used in?

In addition to potentially missing a payload, what about when another developer creates a function and forgets to include the input validation? Even more likely, what happens when a new application starts accessing your database and doesn’t perform the same input validation. it puts us back into the same scenario described in the section above regarding the database isn’t trusted.

You Don’t Know the Context

When receiving and storing data, the chances are good I don’t know where the data will be used. What is the context of the data when output? Is it going into a span tag, an attribute or even straight into JavaScript? Will it be used by a reporting engine? The context matters because it determines how we encode the data. Different contexts are concerned with different characters. Can I just throw data into the database with an html encoding context? At this point, I am transforming the data at a time where there is no transformation required. Cross-site scripting doesn’t execute in my SQL column.

A Better Approach

As you can see, the above techniques are useful, however, they appear insufficient for multiple reasons. I recommend performing the output encoding immediately before the data is actually used. By that, I mean to encode right before it is output to the client. This way it is very clear what the context is and the appropriate encoding can be implemented.
Don’t forget to perform input validation on your data, but remember it is typically not meant to stop all attack scenarios. Instead it is there to help reduce them. We must be aware that other applications may access our data and those applications may no follow the same procedures we do. Due to this, making sure we make encoding decisions at the last moment provides the best coverage. Of course, this relies on the developers remembering to perform the output encoding.

by Leave a Comment

Application Security and Responsibility

Who is responsible for application security within your organization? While this is something I don’t hear asked very often, when I look around the implied answer is the security team. This isn’t just limited to application security either. Look at network security. Who, in your organization, is responsible for network security? From my experience, the answer is still the security group. But is that how it should be? Is there a better way?

Security has spent a lot of effort to take and accept all of this responsibility. How often have you heard that security is the gate keeper to any production releases? Security has to test your application first. Security has to approve any vulnerabilities that may get accepted. Security has to ….

I won’t argue that the security group has a lot of responsibility when it comes to application security. However, they shouldn’t have all of it, or even a majority of it. If we take a step back for a moment, lets think about how applications are created. Applications are created by application teams which consist of app owners, business analysts, developers, testers, project managers, and business units. Yet, when there is a security risk with the application it is typically the security group under fire. The security group typically doesn’t have any ability to write or fix the application, and they shouldn’t. There is a separation, but are you sure you know where it is?

I have done a few presentations recently where I focus on getting application teams involved in security. I think it is important for organizations to think about this topic because for too long we have tried to separate the duties at the wrong spot.

The first thing I like to point out is that the application development teams are smart, really smart. They are creating complex business functions that drive most organizations. We need to harness this knowledge rather than trying to augment it with other people. You might find this surprising, but most application security tools have GUIs that anyone on your app dev teams can use with little experience. Yet, most organizations I have been into have the security group running the security tools (such as Veracode, Checkmarx, WhiteHat, Contrast, etc). This is an extra layer that just decreases the efficiency of the process.

By getting the right resources involved with some of these tools and tasks, it not only gets security closer to the source, but it also frees up the security team for other activities. Moving security into the development process increases efficiency. Rather than waiting on a scan by the security team, the app team can run the scans and get the results more quickly. Even better, they can build it into their integration process and most likely automate much of the work. This changes the security team to be reserved for the more complex security issues. It also makes the security team more scalable when they do not have to just manage tools.

I know what you are thinking.. But the application team doesn’t understand security. I will give it to you, in may organizations this is very true. But why? Here we have identified what the problem really is. Currently, security tries to throw tools at the issue and manage those tools. But the real problem is that we are not focusing on maturing the application teams. We attempt to separate security from the development lifecycle. I did a podcast on discussing current application security training for development teams.

Listen to the podcast on AppSec Training

Everyone has a responsibility for application security, but we need to put a bigger focus on the application teams and getting them involved. We cannot continue to just hurl statements about getting these teams involved over the fence. We say to implement security into the SDLC, but rarely are we defining these items. We say to educate the developers, but typically just provide offensive security testing training, 1-2 days a year. We are not taking the time to identify how they work, how their processes flow, etc. to determine how to address the problem.

Take a look at your program and really understand it. What are you currently doing? Who is performing what roles? What resources do you have and are you using them effectively? What type of training are you providing and is it effective regarding your goals?

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.

Originally posted at https://www.jardinesoftware.com

by Leave a Comment

ImageMagick – Take-aways

Do your applications accept file uploads? More specifically, image uploads? Do you use a site that allows you to upload images? If you haven’t been following the news lately, there was recently a few vulnerabilities found in the ImageMagick image library. This library is very common in websites to perform image processing. The vulnerability allows remote code execution (RCE) on the web server, which is very dangerous. For more specific details on the vulnerability itself, check out this post on the Sucuri Blog.

There are a few things I wanted to focus on that are less about ImageMagick and more focused on better security solutions.

Application Inventory

I know, enough already. I get it, I mention application inventory all the time. It is with good reason. We rely heavily on 3rd part components just like ImageMagick and there are bound to be security flaws identified in them. Some may be less critical, while others demanding the highest priority. The issue at hand is that we cannot defend against the unknown. In this case, even if we are aware of a vulnerability, it doesn’t help us if we are not aware we use the vulnerable component. Time is important, especially when it comes to critical type issues. You need to be able to quickly determine if your company uses the vulnerable component, which apps are effected, and what types of data resides in those systems. Performing fire drills for every vulnerability announced is very inefficient. Being able to quickly identify the effected areas allows for a better understanding of any risk changes.

Permissions

When you are configuring your applications, think about the type of permissions the application has on the server. Does it have the ability to write to specific folders, execute specific files, read data, etc.? Does the application run as an administrator with full rights? To help reduce the attack surface we must understand what the app needs to do, and then make sure the permissions are aligned with those needs. In this case, the files may be stored on the file system to be used later so write permissions may be required. It is still possible to limit those write permissions to specific folders and even limiting execution permissions.

Application Configuration

How you design and configure your application plays a significant role in how security is handled. In regards to allowing file uploads, how do you handle storing the files? Are they on the file system or in the database? How are features configured? In the case of ImageMagick, there are configuration settings that can be set to limit the vulnerabilities. Make sure that you are only accepting file types that are needed and discarding others. These configurations can take many forms, but will help provide security when they are truly understood.

Importance of Input Validation

The vulnerability in ImageMagick highlights the importance of sanitizing input and performing solid validation. In this case, the file name is not properly handled which allows an attacker to run unintended commands. We have to check to make sure that the data passed to our applications is what we are expecting. If it is not, then it must be discarded.

This is not the last time we will see a vulnerable component that is used by lots of applications. It is part of the risk of using external components. We can do more on our side to make sure that we know what we are using and preparing for the event that something goes wrong. Take the time to understand your applications and think about the different ways security may be effected.