DevelopSec

developer awareness

by

Investing in People for Better Application Security

Application security, like any facet of security, is a complex challenge with a mountain of solutions. Of course, no one solution is complete. Even throwing multiple solutions will never get 100% coverage.

The push today is around devsecops, or pushing left in the SDLC. I am seeing more solutions recommending also pushing right in the SDLC. I feel like we are stuck at this crossroad where the arrow points both ways.

The good news is that none of these recommendations are wrong. We do need to push left in the SDLC. The sooner we address issues, the better off we are. The idea that if we don’t introduce a vulnerability in the first place is the best case scenario. Unfortunately, we also know that is an unrealistic assumption. So this brings us to pushing right. Here, we are looking to quickly identify issues after they are introduced and, in some cases, actively block attacks. Of course, let’s not leave out that automation is our key to scalable solutions as we build and deploy our applications.

Much of what we focus on is bringing in some form of tool. Tools are great. They take they mundane, repetitive work off of our plate. Unfortunately, they can’t do it all. In fact, many tools need someone that has at least some knowledge of the subject. This is where the people come in.

Over the years, I have worked with many companies as both a developer and an application security expert. I have seen many organizations that put a lot of effort into building an application security team, focused on managing everything application security. Often times, this team is separate from the application development teams. This can create a lot of friction. With the main focus on the application security team, many organizations don’t put as much effort into the actual application development teams.

How does your organization prepare developers, business analysts, project managers and software testers to create secure applications?

In my experience, the following are some common responses. Please feel free to share with me your answers.

  • The organization provides computer based training (CBT) modules for the development teams to watch.
  • The organization sends a few developers to a conference or specialized training course and expects them to brief everyone when they return.
  • The organization brings in an instructor to give an in-house 2-3 day trading class on secure development (once a year).
  • The organization uses its security personnel to provide secure development training to the developers.
  • The organization provides SAST or DAST tools, but the results are reviewed by the security team.
  • The organization has updated the SDLC to included security checkpoints, but no training is provided to the development teams.
  • The organization doesn’t provide any training on security for the development teams.

By no means is this an exhaustive list, but just some of the more common scenarios I have seen. To be fair, many of these responses have a varying range of success across organizations. We will look at some of the pitfalls too many of these approaches in future articles.

The most important point I want to make is that the development teams are the closest you can get to the actual building of the application. The business analysts are helping flush out requirements and design. The developers are writing the actual code, dealing with different languages and frameworks. The QA team, or software testers, are on the front line of testing the application to ensure that it works as expected. These groups know the application inside and out. To help them understand the types of risk they face and techniques to avoid them is crucial to any secure application development program.

My goal is not, let me repeat, NOT, to turn your application development teams into “security” people. I see this concept floating around on social media and I am not a fan. Why? First and foremost, each of you have your own identity, your own role. If you are a developer, you are a developer, not a security person. If you are a software tester, don’t try to be a security person. In these roles, you have a primary role and security is a part of that. It is not the defining attribute of your tasks.

Instead, the goal is to make you aware of how security fits into your role. As a software tester, the historical goals focused on ensuring that the application functions as expected. Looking at validating use cases. When we start to think about security within our role, we start to look at abuse cases. There becomes a desire to ensure that the application doesn’t act in certain ways. Sometimes this is very easy and others it may be beyond our capabilities.

Take the software tester again. The goal is not to turn you into a penetration tester. That role requires much more in-depth knowledge, and honestly, should be reserved for looking for the most complex vulnerabilities. This doesn’t mean that you can’t do simple tests for Direct Object Reference by changing a simple ID in the URL. It doesn’t mean that you don’t understand how to do some simple checks for SQL Injection or Cross-site Scripting. It does mean you should be able to understand what the common vulnerabilities are and how to do some simple tests for them.

If you invest in your people correctly, you will start to realize how quickly application security becomes more manageable. It becomes more scalable. The challenge becomes how to efficiently train your people to provide the right information at the right time. What type of support are you looking for? Is it the simple CBT program, or do you desire something more fluid and ongoing that provides continuing support for your most valuable assets?

Different programs work for different organizations. In all cases, it is important to work with your teams to identify what solution works best for them. Providing the right type of training, mentorship, or support at the right time can make a huge impact.

Don’t just buy a training solution, look for a partner in your development teams training efforts. A partner that gets to know your situation, that is available at the right times, and builds an on-going relationship with the team.

by Leave a Comment

Thinking about starting a bug bounty? Do this first.

Application security has become an important topic within our organizations. We have come to understand that the data that we deem sensitive and critical to our business is made available through these applications. With breaches happening all the time, it is critical to take reasonable steps to help protect that data by ensuring that our applications are implementing strong controls.

Over the years, testing has been the main avenue for “implementing” security into applications. We have seen a shift to the left more recently, leading to doing more throughout the entire development cycle, but we still have a ways to go. I am still a firm believer in embedding security into each of the phases as our main means of securing applications. Testing, however, is still a major component of any security program.

Typically, organizations rely on penetration testing to find the flaws in their applications. This is the de facto standard for understanding your risk. Unfortunately, penetration testing for applications has been watered down from what we think about with network testing. Many of the assessments we call penetration tests these days are just automated scans transposed into a custom report. These types of testing overlook one of the components a penetration test provides, which is the manual testing. Of course, there is much more to a penetration test, but that is not the focus of this post.

Internally, organizations may implement automated tools to help identify security flaws within their applications. These tools are good at finding certain types of flaws, and usually quite quickly. Like many current penetration tests, they lack the manual assessment side.

Not only does manual testing have the ability to find different types of flaws, such as authentication, authorization, CSRF, business logic, etc., it also has the ability to identify flaws that an automation tool overlooks. For example, a tool may not find every instance of cross-site scripting, depending on how that tool analyzes the system. Granted, manual testing is not guaranteed to find every instance either. With each type of testing, there is always a number of issues that will not be identified. The goal is to start reducing these numbers down over time.

Handling the results of all these res ports from the different assessments is critical to how well you start creating more resilient applications. In many organizations, vulnerabilities identified are handled as individual items and patched. In my opinion, the return on investment is when you can analyze these results to review your development process and see what improvements can be made to reduce the chance these types of flaws will be included in the future. Having an expert available to help review the issues and provide insight into how to use that information to improve your process is valuable.

Having a solid application development process in place is important before thinking about implementing a bug bounty program within your organization. If you are not already doing things consistently, there is a better chance the bounty program will fail.

Bug bounty programs have been becoming more prevalent over the last few years. This is especially true for newer technical startups. We have seen much slower adoption with most of the major corporations. There are many reasons for this, which are outside the scope of this post. There have been questions on whether bug bounties can replace penetration testing. The answer is no, because the goal of each of these is different. There are plenty of articles discussing the subject. A bug bounty program has also been seen by many as the evidence to show they are doing application security. Unfortunately, we can’t test ourselves secure. As I stated previously, testing is just a part of our solution for application security.

A key difference between our traditional testing and a bug bounty program is that bug bounties pay by the bug. Our traditional testing is provided at flat fees. For example, that automated tool is a set price for a month or year subscription. A penetration test is a set price per test. A bug bounty is priced per bug, which makes the cost very unpredictable. In addition, if you are not already doing many of the things previously discussed, there could be a lot of bugs to be found, leading to potentially high payouts.

As I have stated before, penetration testing has a different purpose and it can be very expensive. At Jardine Software we offer more budget friendly manual application security testing at a fixed cost. The goal is not necessarily to find every instance of every vulnerability or to exploit vulnerabilities in the way a penetration test would. The focus is on augmenting the automated testing you may already have in place and to provide that missing manual piece. The testing is performed manually by using the application in combination with Burp Suite, to look for weaknesses and provide those in a way that helps prioritize and then remediate them according to your organization’s needs.

The manual application security testing is typically performed over a week to two weeks and includes a broader scope than a typical bug bounty program. The reason for this is that we want to help identify risks that we see based on our years of experience to make you aware. This assessment can then help identify where you may have issues within your application before opening it up for a crowd sourced bounty program where each bug is priced individually.

If you are thinking about implementing a bug bounty program, reach out and lets chat first. Even if you are not considering a bug bounty program, do you have any manual application security testing implemented? We have the expertise to help provide the necessary testing or provide training for your internal teams to start applying manual testing techniques as part of your life cycle.

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

The Hidden Reason for Switching to HTTPS

If you run a website, you have probably debated on whether or not you need to make the switch to HTTPS instead of using HTTP. For those that still don’t know, HTTPS is the encrypted version of HTTP. This is typically seen on banking sites, touted to protect your sensitive information when transmitted between you (your browser) and the application.

I wrote on this topic about a year ago in the post: Is HTTP being left behind for HTTPS? Back then there was a big push for making the switch and since we have seen even government mandates for government operated sites to make the switch to HTTPS.

There are typically two reasons you will hear someone recommend using HTTPS:

  • SEO (search engine optimization) – To learn more about these benefits, check out this great article Should you switch your site to HTTPS? Here’s Why you should or shouldn’t by Neil Patel. Neil does a great job of explaining HTTPS and the pros and cons.
  • Protecting sensitive information – We all should know by now that we need to protect sensitive information as it is transmitted to the application. So if your application transmits any sensitive information (Passwords, Social Security Number, Credit Card Info, Account information, etc) it is a must to use SSL.

But Wait…What about…

There is another big reason that HTTPS is important, even if you do not have sensitive information on your site. Let’s step into our favorite scenario of using your computer in the local coffee shop. You connect to the free wifi and start surfing to your favorite sites. You feel comfortable logging into your bank account because it uses HTTPS and you see the green lock in your browser (although maybe you shouldn’t feel so comfortable). Ideally, that session with your bank is protected from the guy sitting one table over trying to intercept the traffic.

Then you point your browser to a local news site to check out the latest happenings. That site is over HTTP and is not protected while traversing the wifi network. What happens when the attacker is able to intercept that news traffic and he changes the response, that you expect to contain today’s news, to contain malicious content. This would be no different than you clicking on a malicious site to begin with. Except here, you feel safe on that familiar news site.

This scenario shows how your site, the one running without HTTPS, could be used as a launching point to attack a user. While it didn’t effect your actual site, or your servers, it will lead to a break in trust from your visitors. If something happens while on your site, it doesn’t matter how it happened, the finger is pointing straight at you.

Conclusion

So while we put a lot of focus on sensitive information or SEO, there are other very important reasons why a site owner would want to make the switch to HTTPS. Gone are the days when performance is an excuse. Heck, with the Let’s Encrypt project, maybe gone are the days of the cost of purchasing a certificate to enable HTTPS. Sure there may be reasons, even some valid ones, why you don’t need to make the switch. Don’t just look at the constraints. Take the time to really understand your situation, how the change effects you, and make rational decisions. Don’t do it because some site said too. Do it because you understand the situation and know it is right for your situation.

by Leave a Comment

Introduction to Penetration Testing for Application Teams

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at: https://youtu.be/I1PukF8Glh0

https://youtu.be/I1PukF8Glh0

by Leave a Comment

Sharing with Social Media

Does your application provide a way for users to share their progress or success with others through social media? Are you thinking about adding that feature in the future? Everyone loves to share their stories with their friends and colleagues, but as application developers we need to make sure that we are considering the security aspects of how we go about that.

Take-Aways

  • Use the APIs when talking to another service
  • Don’t accept credentials to other systems out of your control
  • Check with security to validate that your design is ok

This morning, whether true or not (I have not registered for the RSA conference), there was lots of talk about the RSA registration page offering to post a message to your twitter account regarding you going to the RSA conference. Here is a story about it. The page asks for your twitter username and password to then post a message out on your twitter account. Unfortunately, that is the wrong way to request access to post to a social media account.

Unfortunately, even if you have the best intentions, this is going to come across in a negative way. People will start assuming you are storing that information, that you know have access to important peoples twitter accounts going forward. Maybe you do, maybe you don’t, the problem there is that no one knows what happened with that information.

Just about every social media site out there has APIs available and support some oAuth or other authorization mechanism to perform this type of task. By using the proper channel, the user would be redirected to the social media site (Twitter in this instance) and after authenticating there, would provide authorization for the other site to post messages as the registered user.

Using this technique, the user doesn’t have to give the initial application their social media password, instead they get a token they can use to make the post. The token may have a limited lifetime, can be revoked, and doesn’t provide full access to the account. Most likely, the token would only allow access to post a message. It would not provide access to modify account settings or anything else.

If you are looking to integrate or share with social media sites, take the time to determine the right way to do it. This is really important when it involves access to someone else account. Protect the user and yourself. Don’t just take the easy way out and throw a form on the screen. Understand the architecture of the system and the security that needs to be in place. There are a lot of sites that allow sharing with social media, understand how they are doing it. When in doubt, run this by someone else to see if what you are planning on doing looks like the right way to do it.