HTML Injection Attacks: Impact and Mitigation Strategies
Testing or Hacking: Real Advice on Effective Security Testing Stratagies
1. D A N B I L L I N G |
@ T H E T E S T D O C T O R # N T D 2 0 1 6
T E S T I N G O R H A C K I N G
R E A L A D V I C E O N
E F F E C T I V E
S E C U R I T Y T E S T I N G
S T R A T E G I E S
7. S E C U R I T Y
S H O U L D B E
P A R T O F T H E
C O N V E R S A T I O N
8. W E N E E D T O
L E A R N F R O M
T H E H A C K E R S
9. “Hackers…they just might be the
immune system for the
information age…sometimes they
make us sick, and they make us
fix it.”
Keren Elazari @k3e3n3
Cyber Security Researcher, TED 2014
26. F U N C T I O N A L
F L O W
R E G I S T E R S E A R C H R E S U L T S
P U R C H A S E S T O C K C O N T R O L U S E R A D M I N
27. U S E R F L O W
R E G I S T E R S E A R C H R E S U L T S
P U R C H A S E S T O C K C O N T R O L U S E R A D M I N
U N R E G I S T E R E D U S E R S
R E G I S T E R E D U S E R S
A D M I N I S T R A T O R S
29. • ALL COMPONENTS HAVE POTENTIAL
VULNERABILITIES
• POOR IMPLEMENTATIONS OF ANY
COMPONENT CAN LEAD TO FLAWS
• DEEP, INTIMATE KNOWLEDGE OF YOUR
ENVIRONMENT WILL AID YOUR TESTING
35. “As a hacker, I can
• send bad data in URLs, so I can access data and
functions for which I am not authorised
• send bad data in the content of requests…
• send bad data in HTTP headers…
• read and even modify all data that is input/output by
your application
Source: owasp.org Evil User Stories
39. 1.CONSIDER THE SCOPE
2.KNOW YOUR STACK
3.UNDERSTAND YOUR WEAKNESSES
4.POWER UP!
5.USE TOOLS EFFECTIVELY
6.SCAN > VERIFY > EXPLORE > SCAN > VERIFY > EXPLORE
7.BE (OCCASIONALLY) EVIL
8.DON’T DO IT ALONE
9.BE CLEAR, BE HEARD
10.BE DETERMINED
40. D A N B I L L I N G |
@ T H E T E S T D O C T O R # N T D 2 0 1 6
M A N Y T H A N K S !
Q U E S T I O N S
?
Editor's Notes
I think that we, as members of the software development and technology have a problem.
I want to share my thoughts on it with you, and my experiences on how the business I work for has tried to manage this problem.
Right now, as we sit in this room, the applications that we as a community work on are being attacked.
It might be by opportunists, or maybe stereotypical lonely kid who lives with their Mum.
It might even be hacktivist groups like Anonymous…but most likely it will be professional, dedicated, experienced and highly trained criminal gangs.
But if we consider the sheer volume of organisations that have been attacked in the last year, we can see that hackers target a wide range of different organisations from educational institutes, financial services, entertainment and broadcasting, through to health care insurance, telecommunications, web hosting, nation states, children's toys and online dating.
The list is not endless, but very close to it. This slide represents a small fraction of the successful hacks reported in the last year, these are only the ones I could fit on one slide…
BUT JUST ON THESE ORGANISATIONS ALONE it represents almost 250 million breached user records in total.
But if we consider the sheer volume of organisations that have been attacked in the last year, we can see that hackers target a wide range of different organisations from educational institutes, financial services, entertainment and broadcasting, through to health care insurance, telecommunications, web hosting, nation states, children's toys and online dating.
The list is not endless, but very close to it. This slide represents a small fraction of the successful hacks reported in the last year, these are only the ones I could fit on one slide…
BUT JUST ON THESE ORGANISATIONS ALONE it represents almost 250 million breached user records in total.
I don’t want to scare you, well…maybe I do a little…but I REALLY, HONESTLY and DEEPLY feel that testing and testers can and should help.
We may have an uphill battle, but through learning, persistence and adapting our skills we can have an impact.
BUT
We can’t do it alone!!!!!
Security should be part of the conversation when planning and delivering good testing.
We should be discussing and planning for security testing alongside the people who own our products, who are advocates for our customers, and with the people who design and build them, of which we are a part.
But there is one group, or should I say groups, for they are legion, who I think we should learn from. We need to learn from hackers in order to do better at protecting our systems.
And here’s why: They are dedicated, adaptable, and very fast learners. It doesn’t matter whether they are script kiddies, government organisations or the worst cyber criminals - as testers we can learn how hackers operate, how they explore and exploit the weaknesses and vulnerabilities that they discover on the web.
I would argue that the main difference between hackers and testers, apart from the specific skills they have is their ideology. Some hackers want to destroy and steal for financial gain. Some want to cause chaos for their own amusement, and some wish to open the worlds eyes to injustice and corruption.
And we can at least try to be their equals when protecting our applications.
In her talk at TED 2014, Keren Elazari talks about how as a teenager, she began the power that hacking could invoke on society. Initially driven seeing the Angelina Jolie movie, "Hackers", and later, by her curiosity and desire to learn, she trawled hacker forums and message boards, picking up techniques and code along the way.
She describes hackers as the immune system for the information age. They tell us when there are problems, they force us to fix those problems. The best, most ethical security researchers will ALWAYS communicate and co-ordinate with vulnerable organisations before they publish any findings. They will always give a company the opportunity to fix those issues. Some however will go public with their findings if they are ignored or fobbed off.
Let me very quickly explain the environment that we work in at NewVoiceMedia, and some of the technical challenges we are facing with regard to security.
Firstly, we operate a multi-tenanted system. That means that our customers share hosted environments which we supply them, via a web based application. This is so that they don’t have to install, manage and maintain their own contact centre infrastructure.
Through this software we deliver, maintain and manage all telephony and email based contacts that our customers have with their clients, operating around the clock.
This we operate globally.
However it also presents a complex range of security issues:
It’s a huge challenge for our DevOps team, of which testing is a major part. We need to consider the integrity of our entire platform, from network, data storage, hosting, all integrations, and of course the user interface.
We test frequently for the vulnerabilities in the OWASP Top 10, and beyond that also. Not only do we need to prevent external attackers gaining access to our systems, but we also need to consider the leakage of data between user accounts.
Imagine living in a shared house with a bunch other people you don't know, and someone is stealing your milk.
I'm the security testing lead for my business. I also coach, mentor and pair with other testers and developers on their work, where security is an factor. This not only applies to the development team, but also other departments like marketing, who manage the corporate website.
Well, this is the £1000000 question...possibly quite literally.
There is no guarantee that even if you do security testing that your systems won't be hacked and breached.
But consider the risks if it isn't even in your strategy - you aren't then aware of the potential risks and threats to your applications and how to mitigate them. Consider the risks of loss of data, finances and reputation to your business. Then try to answer that question again, and factor it into your strategies.
However you might start to hear questions and statements like this as a result.
This is something you might hear from decision makers at your organisation...this is something I would challenge, but we'll look at this more shortly.
Whilst not necessarily a bad thing, I'd always want development and testing teams to take a pragmatic approach to security.
There are some great specialist security consultancies out there. It's just a question of how you use them, when you use them and how much it costs you.
This particular statement really irritates me - the security of an application, apart from the networking, architecture and so on - IS INHERENTLY a functional problem.
Poor implementation of functionality by development teams can directly lead to security flaws.
We don't have the skills - well, hopefully we can address that!
Rapid delivery is all well and good, but if you are delivering poor, insecure code I wonder whether it is worth delivering at all.
Sure, there are market pressures, but if business continuity, customer data or even the safety of people being at stake, I think there is a trade off to be made here.
So, let's for a minute consider that you have begun to include security testing in your test strategies, and the powers that be are letting it happen. We need to be able to enable ourselves to answer these questions and issues instead...
Unfortunately we have to start from the basis that our systems and applications are never going to be 100% secure. There is no such thing, and frankly it is unachievable.
We have to adapt to that and do the best we can to support that change - so here are 10 ways you can incorporate security testing into your test strategies. I use them...they work for me, so maybe they will work for you:
So, firstly if you are concerned about whether security should be in or out of scope of your testing, then this isn’t the question you should be asking. The more important question is - why aren’t we doing any security testing?
It SHOULD be in scope. It might be that the testing is given to another team, or external organisations - but there IS someone in your companies who is responsible for the security of your business. That might be the CIO, CTO or CSO. Find out who that person is and talk to them about what your teams responsibilities are.
Discover what the priorities of the business are, financially, socially, and even legally. Security should be a part of those priorities, but I appreciate that often it is very much in the back of many peoples minds.
Considering that security testing is ‘out of scope’ for any project that handles data, be it internal or externally sourced in my view is a recipe for disaster. Even if you don’t do the testing yourself, at least consider the implications and impact of not testing for security. What are the risks? What could happen? Risk and Threat analysis are hugely important in defining your scope for security testing.
If you are of the belief that your businesses and software products aren’t at risk of hacking then you are sadly mistaken.
Also, start small..it's much much easier to manage the testing if it is broken into smaller chunks. You could consider scoping your testing in these ways...
Let's examine this basic flow of an online shopping experience. FIRSTLY YOU COULD CONSIDER TESTING FOR SECURITY ALONG THE FUNCTIONAL FLOW OF YOUR APPLICATION - SO TESTING THE SECURITY IN EACH FUNCTION DISCRETELY OF OTHER FUNCTIONS.
Each of these functions could have their own vulnerabilities, and probably share a few as well if they are using the same implementations of technologies and infrastructure.
ALTERNATIVELY YOU COULD CONSIDER THE FLOW OF USER INTERACTION WITHIN THE FUNCTIONALITY - SO WHAT EACH TYPE OF USER IS ABLE TO DO AGAINST WHAT YOU INTEND THEM TO BE ABLE TO DO - CONSIDER THE UNREGISTERED USERS ACCESS, VERSUS A REGISTERED OR ADMINISTRATION USER.
At NewVoiceMedia, we are maturing as a DevOps organisation. That means that every employee, every engineer, whether they are in test, development, networking, database administration, all the way up to the CTO and CEO are responsible for security in different ways.
Good hackers, professional hackers will do as much as they can to learn about your infrastructure and how your applications are put together. It helps them know how to subvert it.
You should know it better - you help build it. Simply put, as testers we need to realise that:
ALL COMPONENTS HAVE VULNERABILITIES
POOR IMPLEMENTATIONS OF ANY COMPONENT CAN LEAD TO FLAWS
DEEP, INTIMATE KNOWLEDGE OF YOUR ENVIRONMENT WILL AID YOUR TESTING
So, once you know and understand how your application is put together, you can better understand where the weak points might be.
Personally, I look to nature for a lot of inspiration. Many animals have formed phenomenal techniques of defence and camouflage. Let’s take our friend the armadillo here. These creatures have evolved themselves a hard outer shell, which will protect them from some of their predators. However, they are prey to mountain lions and birds of prey alike. The outer shell belies a soft underbelly, which the predator will exploit.
What’s the point of having a really secure user interface for a website, if your public facing API is vulnerable to attack? Like the armadillo’s predators, Hackers will target whatever it is easiest for them to get their hands on, whether that is the database, UI, APIs or some other method. When you have to, you might have to curl up in a little ball, rather than get eaten alive.
Understanding the potential risks and threats here are important here in being able to know where your applications are a their weakest, and building a strategy to mitigate them.
At some point we are going to need as testers to address our skills. It’s something we are all striving to do…after all we are attending this conference, attending workshops…always learning while we are testing. Security testing is challenging, but it is not a dark art, and it should not always be the preserve of specialist consultancies who come in at the end of a project just to tick a few boxes.
Specialist security testing consultancies are usually highly trained teams of ethical hackers. They do know what they are doing, and they are a great and powerful learning resource. But they are expensive, both in terms of time and money. You as a tester can do a lot of security testing yourself, whilst you are building new features, or testing older ones.
There are a great range of resources for learning how about security, from books to blogs, vulnerable sites and courses. You could start with the work done by OWASP, who have great tutorials and information on vulnerabilities and tools. There are a whole host of videos and other useful material done by the folks at Computerphile, as well as the work of security researchers like Graham Clueless, Scott Helme, Troy Hunt and Keren Elazari, who I referred to earlier.
What I would say though is to address some of the challenges of incorporating those skills into your day to day testing.
Firstly…try a few techniques
If you are testing and have an input field of some kind, try some injection attacks on it, try some XSS on it. See what happens, observe how the application behaves. While you are doing that, use the browser tools or a proxy to observe what is happening between the application layer and the server.
Your skills WILL deepen as you practice them. As you become more aware of the sort of feedback an application can give you, you will generate more test ideas, thus giving your skills the fuel they need to grow and develop. Whilst you could say this about any aspect of testing, security for me personally has taken the most energy and time.
It’s also worth considering here, that as the web and application development evolves, the way hackers will look to exploit weaknesses will evolve too. Our skills need to evolve to meet that challenge. Without that change, that growth, we won’t be able to address the problems that hacking can present.
Hackers will either use existing tools that are out there on the web, or even build their own. It really depends on what they want to do, and to whom.
If it is a sophisticated attack involving a specific target, then this will take a lot of time and effort to set up. However, if you are just targeting a site you think might be vulnerable, then one of the wide range of penetration testing tools that are out there would be very useful.
I use a range of these myself to achieve what I want to do, including Zed Attack Proxy, BurpSuite, or Beef, some of the tools available via the Kali penetration testing Linux build. One of these tools is SQLMap, which was used recently to great affect by the hackers behind the TalkTalk breach, amongst others. It’s easy to use, inside a command line, powerful, and like any DIY tool, potentially dangerous in the wrong hands.
The question here isn’t really what tool do you use, but more how you use them. Many of these tools are very much like a shotgun. They have a wide range of functions, such as dynamic scanning, spidering or enumerating database tables. But you can also tune them to be much more focussed and targeted on a specific area, it just takes some practice. For example, if your UI has some basic protection against Injection attacks, try tampering those requests via a tool like Fiddler, to see if you can get around the UI and submit malicious requests.
I often use this simple model to perform security testing against an application. It is usually effective, gives me a lot of coverage of the applications I test, but then gives me the flexibility to drill in to specific features and functions later.
Firstly, you might want to use a tool, such as the scanners built into ZAP or Burpsuite. Often I use them together, as each provide different information which you can use to generate further test ideas. Scanners give you a lot of coverage, but not a lot of depth. You can tune them, and apply
After that spend some time filtering out what appear to be false positives, verifying if they are a real problem or not. Something that appears to be a security flaw, but isn’t…as these can often be red herrings that lead you away from what you should be focussing on. For example, a Facebook page ID that is embedded or linked to from the page you are testing could be mistaken by a scanner for being a Credit Card Number. It takes a human to recognise the difference, or write some code that filters these things out of the results.
Then, after I’ve identified areas I want to investigate further, I’ll explore the application with other tools like Fuzzers, CSRF checkers, Bug Magnet. If you are testing access control features, try brute forcing them to see whether you can circumvent them.
Observe the traffic between the application and it’s host, tamper with that traffic to see how it behaves, looking at different parameters and values.
Also take a look at the browser tools, the network traffic, the code being used, the cookies that are in play. Can these be exploited in any way by anyone trying to subvert them?
I’ll then feed that knowledge gained when exploring, to feed back into future scanning. It helps me focus on what I need to test, and becomes more focused each time it happens.
Sometimes, it might be a good idea to get into the mindset of the people who are attempting to undermine or steal from your systems and applications.
And whilst I don’t advocate going out and ‘being evil’ on other peoples systems from your volcano based lair, you can consider when planning your testing activities how hackers might use or abuse your systems…for example you could use Evil User stories
Here are some examples from OWASP, the Open Source Application Security Project…
If like me you work in an Agile development environment, you might already use User Stories structured similar to this, where ‘as a user, I want to do this or that’ to express intended behaviours, acceptance criteria and functionality of a system under test.
You might also want to consider the mirror of those stories, if they were from the point of view of a potential attacker…considering how an alternative user might use the system.
It’s a useful way of focusing your thinking, allowing you to change the mindset behind your approach to development and testing to be more defensive in nature. I often use language like this to describe bugs that I find also, so they are clearly communicated to those that need to understand them - such as “As a hacker I can use SQL Injection on the user login to allow unauthorised access”. It helps me frame the issues discovered under test in such a way that I am able to be more objective when testing issues, allowing me to ‘assume personas’ whilst testing.
Within my organisation, we have a large team of both testers and developers. We have to not only be masters of our domains, but be able to share knowledge, learning and thinking around development and testing.
Within the team, each tester has their own specific interests they wish to pursue, and goals they need to achieve. Mine is to be an advocate for application security, but sometimes it can be a lonely activity.
I enjoy pairing with other testers immensely, especially when coaching them on security and hacking technique, but also learning how this feeds into the needs of their testing and their teams. I prefer it to testing alone in many ways, because sometimes security testing can lead you into always thinking the worst about your applications, and software in general. I’m always on the lookout for security flaws when I am using the web at home.
Other testers help me see that Security shouldn't be an isolated activity in software development. We need to consider performance, usability, accessibility and a whole host of other considerations whilst testing. Security shouldn’t be a blocker to achieving those other needs, and should be considered in balance with all software issues.
What’s the point of making a system so secure that it renders it unusable by the people that you intend to use it. Working with others, with different interests and business needs allows the wider context of those issues to bubble to the top.
When you find problems, you might meet resistance.
Some people will be pleased about what you have found, others less so perhaps. Some might be sceptical. As testers we always need to be prepared to be an advocate for the problems that you find, because that’s what we do.
Security bugs are problems that need investigating, considered and discussed like any other issue with software. Ultimately it is the decision of who owns the application as to whether they are fixed or not.
You might hear things like ‘that’ll never happen to our customers, they don’t use it in that way’ or ‘we have the firewall to protect us from that sort of thing’. Well, hacker’s don’t care how your customer uses the application necessarily, they wan’t to subvert that usage. And firewalls are a sticking plaster, which are not indestructible. Challenge those assumptions, use examples of similar issues and vulnerabilities to back up your argument, even with reference to existing hacks and breaches.
But you need to be clear on the risks not only to the application and its data, but also the business. Have that on your side, and the people who make decisions will have the right information.
If you are testing for security, then the emotional challenge will be as big as the technical challenge. As I mentioned earlier I often find it difficult inhabiting the hacker mind set for 100% of . The time that I am testing. I do like to explore other interesting avenues of testing.
When you are testing for security, you will hit pitfalls and hurdles along the way.
I’ve found that since I’ve focussed on security so much that I am often unable to de focus from the security mindset, which I suppose is one of the downsides of having an almost singular focus.
For example, you may have a gut feeling that an application is vulnerable because it is using older technology, or you have found other issues which might indicate a security problem, such as poor error handling. Some attack scenarios may be more successful than others, and it will be up to us to explore those routes to vulnerabilities.
Being determined in your ability to find and help fix security flaws will be key here. A hacker will be determined to find ANY route in that they can exploit…and we must be equally determined to stop them if at all possible.
So, as we come to the end, let’s summarise
And I leave you with this to consider…
Are hackers testers…YES…I think so in many ways. They want to find out information regarding the applications that they ‘hack’ just as much as we do. It’s the motivation and the intended use of that information that differs here.
And are testers hackers…well…again…YES, I feel we can be in many ways. Like Hackers, testers are creative and learning people. We seek to better our knowledge of applications through testing…we seek to support and nurture our applications through testing. Again, it is our intent, our drive to create great products for our customers that differentiates us.
Let’s learn from that, take the skills of hackers into our domain, and exploit them, as much as they would try to exploit us.
If anyone wants to get hold of me after the conference, here is how…you can also get hold of me on the various testing Slack channels that are floating around.
I work at NewVoiceMedia, and I’m also a facilitator with Weekend Testing. Come and talk to me any time.
Thank you for listening :)
