Monthly Archives: September 2014

QA and Security Pt. 2: Software Testers

Lets start by discussing the type of QA that tests software to ensure it is working as designed. These are the bug finders of the QA world. The process starts by a developer creating some functional code and then deploying it to an environment specific to the QA team. The QA team then uses its knowledge of how the application is supposed to function and determines if it is performing properly. Any bugs identified get filed and sent back for remediation (hopefully).

There are some pretty major differences between different companies, and maybe within some companies, in how technical a QA team actually is. Many companies I have worked at, the QA team was not as technically savvy as I would have expected. They would use Microsoft Excel spreadsheets to define their test scripts. In this case the word script is used as a set of processes to follow, not automation. Here is how the process would go.

  • Open Internet Explorer
  • Type http://www.oursite.com into the address bar and hit go
  • Enter Valid Username (james)
  • Enter Valid Password (password)
  • Submit Login Form
  • Verify the user is logged in and redirected to Default.html
  • Pass/Fail

The above example may be a little over the top, but this is how a lot of scripts are designed. There is not a lot of thinking outside of the box when it comes to testing the functionality. While that may sound bad, there are some pros to the approach. For example, it ensures that the app is tested the same way every time which can help reduce the chance of a previous test being missed later on. These scripts are actually very easy to automate as well. On the other hand, it opens up the opportunity for a lot of good testing to not be performed.

Many companies are even using automation tools to help out with scripts like the one above. LoadRunner and Selenium come to mind as frameworks to help with this. These tools can record your testing and then play them back repeatedly. This helps when it comes time to re-test an application you can re-run your previous scripts automatically, allowing the manual tester to free up some time to look at other stuff. Of course, as you test more things you would hope that those tests also become automated.

In other companies, the QA testers are very technical. They work much more with creating custom tools to help with testing the applications. They are more savvy regarding how the application works and different ways that users will use it. With the addition of the automated tools, it makes sense to have testers with these capabilities to really dig into testing the application.

In many cases, we are not seeing a lot of QA teams embracing security testing. There are many people that want to believe that many security flaws cannot be tested by your normal QA department. I am not one of those people. I think to help increase security, we need to increase our internal QA capabilities. We hear that there is a shortage of security professionals, but really, we just need to enlist the current professionals in the development process to help out and we will be better off.

You might wonder why I think QA can find many of these security flaws. To be blunt, most of these security issues are just bugs. Bugs are what QA people (in the current context) do. There is no need for so much segregation between QA and security testing. I understand that we don’t want to share our bowl of rice or think that someone else could actually do that, but they can. Lets look at a few examples that QA should be able to test for.

Injection Bugs are the first on the list. While I group these together, this refers to things like OS Injection, SQL Injection, LDAP Injection, Cross-Site Scripting, XML Injection, etc. These types of bugs are typically not that difficult to identify. Before you jump all over my back, I will agree that some of them can be very difficult to identify. I don’t see that as the norm though. The method: Input known control characters for the current context and look at the output.

For example, enter a single quote (‘) into a field and examine the response. Did you get a database error message? If yes, good chance you have SQL injection – investigate further. No error message? Were there other indicators of a flaw? How about the response time? Did it change drastically from a request without that malicious value? Obviously there are other tests involved in this, but this shows how simple some of the tests can be to help identify the easy vulnerabilities. Will it find all of them, probably not, but it is better than finding none. We should not be relying on outside parties to identify a SQL Injection flaw by entering a (‘) into a field. This should be found internally.

Cross-Site Scripting is another good example. Just like above, enter in known control characters for this bug and analyze the output. If you enter an HTML tag does it get sent back without being encoded? How does the application react? Does it validate input? Does it encode output?

Another set of bugs are related to authentication and authorization. Again, this is something simple that QA can test. Verifying if restricted resources are only available to those given permission is a simple process. Same goes for verifying that a user must be authenticated properly before accessing the system. Many times during a penetration test we are given different sets of credentials to help facilitate the testing of auth bugs. Create a map of what pages/functions each role should have access too. Then check to ensure the other roles cannot access those pages/functions. You might actually be surprised at how much more you know about your application after mapping it like this.

Much of this testing can be accomplished using simple tools such as your browser, plugins, and proxies like Burp or ZAP. There is no good reason for why software testers don’t have and understand how to use these tools during their testing. Lets stop the “We don’t allow hacking tools” non-sense. Many of these tools were started as just testing tools, not hacking tools. If you are not providing QA the tools they need, you will never get better at assuring the quality of your software.

If you fall into the category of the less technically savvy personnel work to get them some security training. Not only will it benefit you by better security testing, but it will also make that person much more knowledgable in general and most likely less prone to falling for phishing or social engineering attacks.

QA and Security Pt. 1: What QA Are You Talking About?

There has been a lot of chatter recently regarding QA and the role it plays in security testing. Hashing this out over Twitter with 140 characters per post just makes things more confusing. While I think that Twitter helps start some of the most important discussions, there is a need for other mediums to expand on the topic. In this series of posts, I want to take the opportunity to bring up some of these topics and hopefully expand on then a little bit. We all have our opinions and we will certainly not all agree on everything, however these are conversations we need to have.

What do you think of when you hear Quality Assurance (QA) mentioned in a conversation? Is it just a process that documents or processes go through to make sure they are sound? Do you think of that group of people that test applications to make sure they function as they should? It is important for everyone in the discussion to understand the context in which the term QA is being used to ensure everyone is on the same page.

As mentioned above, there are a few different things we think of when we hear the term QA. The one that comes to mind the most to me is the team that tests applications or software to ensure that they are working properly. Most likely I go this route because I come from a lengthy development background and that is the QA I mostly dealt with. This QA team is responsible for identifying bugs in the system, documenting them and getting them back to developers to resolve them. This team is engaged after software is written (well, during the iterative development process) and before it is released to the production environment. Even this group can be very different between companies which I will talk about in future posts in this series.

Other people when they hear about QA think about a different group (most likely) that is responsible for reviewing documents and procedures to ensure accuracy. One example of this is sending requirements or design documents through a QA process to ensure they are correct.

Of course there are other types of QA, but those are the two we will focus on throughout this series. If you have other examples, please feel free to send them my way on twitter (@jardinesoftware) or james@jardinesoftware.com. The more we start distinguishing the context we are discussing the more we can get done by cutting through the confusion. Defining our context is a critical first step.

In the rest of this series I will dive into the different types of QA and how they relate to security. What role can they play. What should they be able to do and what should they not be able to find. Can QA find security flaws? Follow me on this short journey to see what we find out.

When Breaches Get Personal

Leave a reply

Unless you have been living under a rock, you have probably heard about the breach of privacy against some celebrities who had some indecent images stolen. It is easy to get caught up in the hoopla that surrounds this latest intrusion due to the racy images that were stolen, but there is a bigger question around all of this. Lets pull away those top layers and see what the deal is.

The story goes that images were taken with mobile devices, and that device then synced the data to some form of cloud storage. You have seen cloud storage before right? DropBox, Sync, Box, ICloud, etc. There are a lot of services that allow storing your data into “The Cloud”. Some of this is just for backup purposes, others help sync data across multiple devices.

Lets start by talking about this mysterious cloud. If you saw the recent movie “Sex Tape” you may have heard it mentioned. You might be shocked that the only thing about the cloud that actually resembles a cloud is its representative image on a network diagram. There are lots of definitions and everyone will tell you something different when describing the cloud. The key point is that these services have servers running in multiple data centers and when you send your data to them it gets stored on those servers. You don’t know where the data actually is, and in most cases it doesn’t matter. It is, in this scenario, an offsite storage mechanism.

Many of these services make it easy to sync files between devices. Wait, you really don’t have more than one device? It is becoming much more common for people to have a phone, tablet, computer, etc. Wouldn’t it be great if when you created a file (photo, document, etc) that it was available on all your devices? The cloud services help with that. Some programs, like the IOS photos feature will automatically sync your pictures to all your devices.

Whether people are aware of how this works, or the implications is hard to really determine. I think most people really don’t think about the mechanism by which the photo made it from their phone to their tablet. They just care that it got there, not thinking about a copy being stored somewhere else. Just like in law, ignorance is no excuse for not knowing what is going on with your devices and services.

As we have seen in the past few years, breaches are an every day occurrence. Usually we see them at big businesses or retailers. These cloud services are also targets due to the types of data they store. Sure, in the most recent case it was nude photos, but think of some of the other stuff that you store from your device. There is a lot of potential for sensitive information being stored.

Do you stop using cloud services because of an incident? Personally, I keep on trucking as usual. I use ICloud, DropBox, and other cloud services all the time. Understand, there is a risk to using any of these services, although I wonder if that risk of the service getting compromised is less than or greater than your own personal device getting compromised. Like everything we do dealing with life, you have to be aware and take responsibility for what you do. Hey, if you want to take nude photos, that is your business. If those images get compromised, and if on an electronic device there is a chance of that, then you determine how to handle the situation. This goes for any data you store, not just photos.

There is so much finger pointing and blame game going around the internet about the recent nude photo breaches. It is the celebrities fault, it is the hackers fault, it is the cloud service provider’s fault. I don’t see how any blame is put on people that take pictures and use a service. We were all given a choice and that doesn’t give anyone else the right to exploit it. Depending on how the accounts were compromised, maybe user, maybe provider. If the provider did something completely negligent, then I can see some problem there. But lets not let any of that detract from the true malicious user here; the attacker that broke in and stole the information. There are going to be people that do this all the time and we are seeing more of it everyday. Lets be clear, there is no way to remove the blame from the attacker in any of these scenarios.

As users, we need to stay focused on doing the right security practices. Strong pass phrases, less password reuse across sites, don’t click stuff you shouldn’t, stay away from shady sites, and think about what you are doing. Don’t get caught up in the hype of news headlines, but rather take in the details and determine what the real issue is. All of the talk about nude photos is not the issue. Data stolen by an attacker is the issue. Be safe and enjoy the internet.