• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call
You are here: Home / blog

blog

March 24, 2022 by James Jardine

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.

Filed Under: General Tagged With: app sec, applicaiton security, application security, developer security, developer training, input validation, qa, qa security, quality assurance, secure code

March 19, 2022 by James Jardine Leave a Comment

Is encoding really encoding if it is escaping?

The title might be confusing, let’s see if we can clear it up.

I saw an article the other day that was giving a comparison between encoding, encryption and hashing. There was a statement made that basically said:

Encoding has no security purpose.

I thought this was interesting because when training on security topics we mention encoding for specific use cases. For example, when we discuss Cross-Site Scripting, the answer is output encoding.

I want to clarify that I agree with the statement in the article in that encoding does not provide any type of protections regarding confidentiality or anything like that. There is no data protection there. It does start me thinkng about encoding vs. escaping.

In the example above, regarding XSS, we really are talking about escaping, right? For SQL Injection we would say to escape the data, not encode it. For XSS we are trying to achieve the same goal: Ensure that control characters are not interpreted, but read as data.

The difference is that for SQL we would escape something like a single quote (‘) with two single quotes (”). This tells the Interpreter to treat the single quote as data (like O’Reilly) instead of treating it like a delimiter around data.

However, in the browser we typically encode characters rather than escape them. Instead of returning a (<) character, I would return (&lt;). This tells the browser to display a (<) character on the page rather than treat it as the beginning of an HTML tag.

This leads to some confusion when you are following the rules of the interpreter that uses encoding to escape.

When I teach classes I always use the different terminology when I cover these vulnerabilities. SQL Injection uses escaping. XSS is focused on encoding. In the end, the goal is escaping even though one uses encoding.

This becomes confusing when you want to discuss encoding at a pure level as it tends to have a different meaning depending on the context that you use it.

While encoding and escaping are technically different things, their terms are used almost as one when it comes to things like cross-site scripting. In that context, the encoding actually does provide a security purpose even though it is based on the interpreter the data is being sent to.

Security can be confusing at times. If you have questions or thoughts about application security, I would love to have a conversation around them. Feel free to reach out to me. Let me know what struggles you have when it comes to appsec.

Filed Under: General Tagged With: application security, AppSec, cross-site scripting, developer training, training, vulnerability, xss

January 3, 2022 by James Jardine Leave a Comment

How Can I Find The Version of Serv-U FTP on Custom Branded Login?

It is possible to put a custom login page up for the Serv-U login screen. When this happens, the page is most likely not displaying the version number. One way that may help identify the version is to visit the Mobile login page at /Web Client/Mobile/MLogin.htm.

Why is this important?

When performing external security scans with tools like Nessus, it may report that the version of Serv-U is incorrect. Finding the version number is important in identifying potential false positives.

Filed Under: Questions Tagged With: AppSec, pen test, pen testing, penetration testing, security, security awareness, Serv-U, training

December 20, 2021 by James Jardine Leave a Comment

What is the difference between encryption and hashing?

Encryption is a reversible process, whereas hashing is one-way only. Data that has been encrypted can be decrypted back to the original value. Data that has been hashed cannot be transformed back to its original value.

Encryption is used to protect sensitive information like Social Security Numbers, credit card numbers or other sensitive information that may need to be accessed at some point.

Hashing is used to create data signatures or comparison only features. For example, user passwords used for login should be hashed because the program doesn’t need to store the actual password. When the user attempts to log in, the system will generate a hash of the supplied password using the same technique as the one stored and compare them. If they match, the passwords are the same. Another example scenario with hashing is with file downloads to verify integrity. The supplier of the file will create a hash of the file on the server so when you download the file you can then generate the hash locally and compare them to make sure the file is correct.

Filed Under: Questions Tagged With: application security, AppSec, crypto, encryption, hashing, questions, secure development, security awareness, security testing, training

December 19, 2021 by James Jardine Leave a Comment

Ep. 118: Log4J Sparking Thought on Vulnerable Components

Log4J has been the talk of the town recently and everyone is focused on the technical details of the specific vulnerabilities found. In this episode, James talks about the overarching ideas around dealing with vulnerable components. Are you vulnerable? If so, what needs to be done?

Listen to the Episode:

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

[Read more…] about Ep. 118: Log4J Sparking Thought on Vulnerable Components

Filed Under: Podcast Tagged With: application security, application security program, AppSec, leadership, owasp, podcast, secure development, security training, training, vulnerable component

December 15, 2021 by James Jardine Leave a Comment

Log4J – Reflection and Progression

Open any social media platform or pull up any mainstream media and undoubtably, you have seen many posts/articles talking about the log4j vulnerability. If you haven’t seen this, here is a quick link to catch up https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/.

This post is not going to be about log4j, nor is it going to go into any of the details the thousands of others articles out there would go through. Instead, I want to discuss this at a higher level. Log4j is just an example of the risks of using 3rd party components and should be pushing a broader discussion within your organization and team.

The use of Vulnerable and Outdated Components – https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ – Is ranked 6th on the OWASP Top 10.

If you have already started dealing with this (and if you haven’t, you should be), you have probably had similar questions as others out there. The biggest question probably every organization and security team had was “Am I vulnerable?”.

This is a great question, but how easy is it to answer?

Am I vulnerable?

If you had one application with minimal dependencies, maybe this is a quick answer. Maybe it is not a quick answer. As a developer, you may just have responsibility for your application. You also might be able to quickly answer to what version of what dependencies exist in your application. Well, maybe high level dependencies.

As an organization, it may not just be custom in-house applications that we are worried about. What about other applications you use within your organization that could be vulnerable to this. Are you using Software as a Service that could be vulnerable? As we start to pull on these different strings, they start to get tangled together.

[Read more…] about Log4J – Reflection and Progression

Filed Under: General, Take-Aways Tagged With: 3rd party component, application security, AppSec, awareness, components, exploit, log4j, owasp, secure code, training, vulnerability, vulnerable component

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 17
  • Go to Next Page »

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
1044 South Shores Rd.
Jacksonville, FL 32207

P: 904-638-5431
E: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved