479 stories
·
4 followers

It’s Beginning to Look a Lot Like XSSmas

1 Comment

Anna Debenham picks up the reins to continue our journey of understanding in the dark forest of web security. With so many packages the reindeer are struggling to pull the sleigh against the weight of all those dependancies. The question is, which packages hold wonderful gifts, and which just coal?


I dread the office Secret Santa. I have a knack for choosing well-meaning but inappropriate presents, like a bottle of port for a teetotaller, a cheese-tasting experience for a vegan, or heaven forbid, Spurs socks for an Arsenal supporter. Ok, the last one was intentional.

It’s the same with gifting code. Once, I made a pattern library for A List Apart which I open sourced, and a few weeks later, a glaring security vulnerability was found in it. My gift was so generous that it enabled unrestricted access to any file on any public-facing server that hosted it.

With platforms like GitHub and npm, giving the gift of code is so easy it’s practically a no-brainer. This giant, open source yankee swap helps us do our jobs without starting from scratch with every project. But like any gift-giving, it’s also risky.

Vulnerabilities and Open Source

Open source code is not inherently more or less vulnerable than closed-source code. What makes it higher risk is that the same piece of code gets reused in lots of places, meaning a hacker can use the same exploit mechanism on the same vulnerable code in different apps.

A graph of open source vulnerabilities published per year, between 2007 and 2017. The number increases from a handful in 2008 to around 50 in 2011, 400 in 2014, up to 900 in 2017.
Graph showing the number of open source vulnerabilities published per year, from the State of Open Source Security 2017

In the first 24 ways article this year, Katie referenced a few different types of vulnerability:

  • Cross-site Request Forgery (also known as CSRF)
  • SQL Injection
  • Cross-site Scripting (also known as XSS)

There are many more types of vulnerability, and those that live under the same category share similarities.

For example, my favourite – is it weird to have a favourite vulnerability? – is Cross Site Scripting (XSS), which allows for the injection of scripts into web pages. This is a really common vulnerability often unwittingly added by developers. OWASP (the Open Web Application Security Project) wrote a great article about how to prevent opening the door to XSS attacks – share it generously with your colleagues.

Most vulnerabilities like this are not added intentionally – they’re doors left ajar due to the way something has been scripted, like the over-generous code in my pattern library.

Others, though, are added intentionally. A few months ago, a hacker, disguised as a helpful elf, offered to take over the maintenance of a popular npm package that had been unmaintained for a couple of years. The owner had moved onto other projects, and was keen to see it continue to be maintained by someone else, so transferred ownership. Fast-forward 3 months, it was discovered that the individual had quietly added a malicious package to the codebase, and the obfuscated code in it had been unwittingly installed onto thousands of apps. The code added was designed to harvest Bitcoin if it was run alongside another application. It was only spotted due to a developer’s curiosity.

Another tactic to get developers to unwittingly install malicious packages into their codebase is “typosquatting” – back in August last year, npm reported that a user had been publishing packages with very similar names to popular packages (for example, crossenv instead of cross-env).

This is a big wakeup call for open source maintainers. Techniques like this are likely to be used more as the maintenance of open source libraries becomes an increasing burden to their owners. After all, starting a new project often has a greater reward than maintaining an existing one, but remember, an open source library is for life, not just for Christmas.

Santa’s on his sleigh

If you use open source libraries, chances are that these libraries also use open source libraries. Your app may only have a handful of dependencies, but tucked in the back of that sleigh may be a whole extra sack of dependencies known as deep dependencies (ones that you didn’t directly install, but are dependencies of that dependency), and these can contain vulnerabilities too.

Let’s look at the npm package santa as an example. santa has 8 direct dependencies listed on npm. That seems pretty manageable. But that’s just the tip of the iceberg – have a look at the full dependency tree which contains 109 dependencies – more dependencies than there are Christmas puns in this article. Only one of these direct dependencies has a vulnerability (at the time of writing), but there are actually 13 other known vulnerabilities in santa, which have been introduced through its deeper dependencies.

Fixing vulnerabilities – the ultimate christmas gift

If you’re a maintainer of open source libraries, taking good care of them is the ultimate gift you can give. Keep your dependencies up to date, use a security tool to monitor and alert you when new vulnerabilities are found in your code, and fix or patch them promptly. This will help keep the whole open source ecosystem healthy.

When you find out about a new vulnerability, you have some options:

Fix the vulnerability via an upgrade

You can often fix a vulnerability by upgrading the library to the latest version. Make sure you’re using software that monitors your dependencies for new security issues and lets you know when a fix is ready, otherwise you may be unwittingly using a vulnerable version.

Patch the vulnerable code

Sometimes, a fix for a vulnerable library isn’t possible. This is often the case when a library is no longer being maintained, or the version of the library being used might be so out of date that upgrading it would cause a breaking change. Patches are bits of code that will fix that particular issue, but won’t change anything else.

Switch to a different library

If the library you’re using has no fix or patch, you may be better of switching it out for another one, particularly if it looks like it’s being unmaintained.

Responsibly disclosing vulnerabilities

Knowing how to responsibly disclose vulnerabilities is something I’m ashamed to admit that I didn’t know about before I joined a security company. But it’s so important! On discovering a new vulnerability, a developer has a few options:

  • A malicious developer will exploit that vulnerability for their own gain.
  • A reckless (or inexperienced) developer will disclose that vulnerability to the world without following a responsible disclosure process. This opens the door to an unethical developer exploiting the vulnerability. At Snyk, we monitor social media for mentions of newly found vulnerabilities so we can add them to our database and share fixes before they get exploited.
  • An ethical and aware developer will follow what’s known as a “responsible disclosure process”. They will contact the maintainer of the code privately, allowing reasonable time for them to release a fix for the issue and to give others who use that vulnerable code a chance to fix it too.

It’s important to understand this process if you’re a maintainer or contributor of code. It can be daunting when a report comes in, but understanding and following the right steps will help reduce the risk to the people who use that code.

So what does responsible disclosure look like? I’ll take Node.js’s security disclosure policy as an example. They ask that all security issues that are found in Node.js are reported there. (There’s a separate process for bug found in third-party npm packages). Once you’ve reported a vulnerability, they promise to acknowledge it within 24 hours, and to give a more detailed response within 48 hours. If they find that the issue is indeed a security bug, they’ll give you regular updates about the progress they’re making towards fixing it. As part of this, they’ll figure out which versions are affected, and prepare fixes for them. They’ll assign the vulnerability a CVE (Common Vulnerabilities and Exposures) ID and decide on an embargo date for public disclosure. On the date of the embargo, they announce the vulnerability in their Node.js security mailing list and deploy fixes to nodejs.org.

Tim Kadlec published an in-depth article about responsible disclosures if you’re interested in knowing more. It has some interesting horror stories of what happened when the disclosure process was not followed.

Encourage responsible disclosure

Add a SECURITY.md file to your project so someone who wants to message you about a vulnerability can do so without having to hunt around for contact details. Last year, Snyk published a State of Open Source Security report that found 79.5% of maintainers do not have a public disclosure policy. Those that did were considerably more likely to get notified privately about a vulnerability – 73% of maintainers who had one had been notified, vs 21% of maintainers who hadn’t published one one.

Some stats: The median time from when a vulnerability was introduced to when it was publicly disclosed is 2.89 years. 75% of vulnerabilities are not discovered by the maintainer. 79.5% of maintainers said that they had no public-facing disclosure policy in place. 21% of maintainers who do not have a public disclosure policy have been notified privately about a vulnerability. 73% of maintainers who do have a public disclosure policy have been notified privately about a vulnerability.
Stats from the State of Open Source Security 2017

Bug bounties

Some companies run bug bounties to encourage the responsible disclosure of vulnerabilities. By offering a reward for finding and safely disclosing a vulnerability, it also reduces the enticement of exploiting a vulnerability over reporting it and getting a quick cash reward. Hackerone is a community of ethical hackers who pentest apps that have signed up for the scheme and get paid when they find a new vulnerability. Wordpress is one such participant, and you can see the long list of vulnerabilities that have been disclosed as part of that program.

If you don’t have such a bounty, be prepared to get the odd vulnerability extortion email. Scott Helme, who founded securityheaders.com and report-uri.com, wrote a post about some of the requests he gets for a report about a critical vulnerability in exchange for money.

On one hand, I want to be as responsible as possible and if my users are at risk then I need to know and patch this issue to protect them. On the other hand this is such irresponsible and unethical behaviour that interacting with this person seems out of the question.

A gift worth giving

It’s time to brush the dust off those old gifts that we shared and forgot about. Practice good hygiene and run them through your favourite security tool – I’m just a little biased towards Snyk, but as Katie mentioned, there’s also npm audit if you use Node.js, and most source code managers like GitHub and GitLab have basic vulnerability alert capabilities.

Some stats: 47% of developers occasionally do a sweep to bump versions. 42% use tools to alert them to vulnerable dependencies. 37% use tools to update to new versions of dependencies. 16% don't update, and 9% update when they overhear or someone points out a need.
Stats from the State of Open Source Security 2017

Most importantly, patch or upgrade away those vulnerabilities away, and if you want to share that Christmas spirit, open fixes for your favourite open source projects, too.


About the author

Anna Debenham lives in London and is a Product Manager at Snyk.

She’s the author of Front-end Style Guides, and when she’s not playing on them, she’s testing as many game console browsers as she can get her hands on.

More articles by Anna

Read the whole story
chrisminett
17 days ago
reply
Interesting hack to take over an abandoned project to inject a vulnerability to something that gets millions of downloads for patch release. Scary!
Milton Keynes, UK
Share this story
Delete

Microsoft announces Edge browser based on Chrome coming to Mac in 2019

1 Comment

Edge was Microsoft’s solution to completely replacing Internet Explorer as the default browser on Windows. When Microsoft launched its new Edge browser, it was only made available on Windows 10, but now, with an upcoming release, Microsoft is bringing its browser to the Mac.

more…

The post Microsoft announces Edge browser based on Chrome coming to Mac in 2019 appeared first on 9to5Mac.

Read the whole story
chrisminett
36 days ago
reply
Edge moves to Blink and macOS
Milton Keynes, UK
Share this story
Delete

PSA: If you’ve ever used a Sennheiser headset with your Mac, it is wide open to attack

1 Comment

If you’ve ever used a Sennheiser headset or speakerphone device with your Mac (or Windows PC), the accompanying HeadSetup app has left your machine wide open to attack.

In what has been described as a ‘monumental security blunder,’ the app allows a bad actor to successfully impersonate any secure website on the Internet …

more…

The post PSA: If you’ve ever used a Sennheiser headset with your Mac, it is wide open to attack appeared first on 9to5Mac.

Read the whole story
chrisminett
45 days ago
reply
Nasty
Milton Keynes, UK
Share this story
Delete

On November 26th, a mole will land on Mars

2 Comments
On November 26th, a mole will land on Mars

This is a comic about NASA's Insight mission to Mars.

View on my website

Read the whole story
chrisminett
56 days ago
reply
Great explanation!
Milton Keynes, UK
Share this story
Delete
1 public comment
kbrint
56 days ago
reply
Cool! and well explained.

How NOT to Review a Pull Request

1 Share
Examine the diff and comment on it, a line at a time

That's not very constructive, Lorna. Do you have a bit more advice for us? Since you asked so nicely, yes I do!

How to Review a Pull Request

First, read the description. If there isn't one, close the pull request. You might need to go looking for an original task or story but it's vital that you read the words there and reflect on what problem this change should solve or what feature it should introduce. The code might be faultless but still miss the point or not catch an important edge case: as a reviewer, that's your job.

Now take the code and run it locally. If you haven't run the code, why are you accepting it into production? Even if you aren't expecting reviewers to also merge the code, an approving review is taking responsibility for that change going live. If it's prose, you still need to see how it renders, etc. Casting your eyes over a diff is never, ever enough, if you're serious about what you do, you'll see the change in context and "poke" at it. I'm sure you do have an excellent build process with tests and whatever - are they better than a curious human checking something for cracks?

When you can answer "yes" to the following questions, you can proceed:

  • Yes, I am happy that this is a useful feature/change, that I understand its purpose and it is fit for that purpose.
  • Yes this change works as expected, even in the not-success case, even with unexpected data, even with missing configuration.

OK now you can read the code diff. My final piece of advice: try not to add low-level idle commentary on other people's code when it really doesn't matter which way things are done. For example: nitpicking use of one approach over another but then allowing the code to merge anyway is IMO very unhelpful. However asking for a confusing/unclear/abbreviated variable to be renamed is probably valuable for the longer term.

Beware the "Helpful" Tools

GitHub is the worst offender for encouraging really awful pull request review processes. When you go to "leave your review", you are immediately transported to the diff. This is exactly where you should not start! Looking at the diff encourages commentary on whitespace. It does not encourage consideration of what is missing from this change request and it also does not encourage trying the code, asking questions, etc. I understand they mean well and for static websites on github pages, perhaps this is enough and the "big green button" is a helpful addition to the workflow. Most of the projects I work are a bit more complicated than that and I encourage developers everywhere to use their brains as well as the helpful tools to provide the best-quality feedback on their peers' changes that they possibly can.

(This blog post also available in talk form but I'm not sure where to submit it to. Suggestions welcome in the comments)

Read the whole story
chrisminett
57 days ago
reply
Milton Keynes, UK
Share this story
Delete

We have an announcement!

1 Share

Last night, at the dotties 2018, we unveiled our new brand identity to a glittering room of clients, partners and employees. We’re thrilled to be able to share our rationale with you today.

What’s new?

We’ve brought our brand up to speed with a new name and look.  From 16th January 2019, we’ll be known as dotdigital. This is not a drastic shift in direction, but to us it signifies our strong commitment to the future of our business and the products we offer our customers.

We’re also changing the name of our platform to Engagement Cloud. In the 20 years we’ve been empowering you, our technology has evolved to meet the ever-advancing needs of your customers. It was becoming clear we needed a name that was more accurate to how you’re using the platform today. Engagement Cloud encompasses all of the same top-notch technology, intelligence and service you rely on to give your customers truly memorable experiences.

 

What inspired us?

You did! Since 1999, we’ve been evolving our platform to empower your customer engagement. We’ve seen the rise in consumer expectation – and we’ve watched our customers blaze a trail of excellence with data-driven marketing automation. We know that, today, email stands as one component of a much bigger, holistic engagement strategy.

We’ve been always been forward-facing, and for us the future brings further evolution, inspiration and empowerment. Our new brand identity is part of this vision.

 

Want to find out more?

Take a closer look into the future of dotdigital »

The post We have an announcement! appeared first on The Marketing Automation Blog.

Read the whole story
chrisminett
74 days ago
reply
Milton Keynes, UK
Share this story
Delete
Next Page of Stories