Hacker News Reader

Comment by geerlingguy | Hacker News Reader

The takeaway: if you run a site or application that is accessible on the Internet, you are responsible for ensuring the site, servers, and infrastructure is maintained after the initial build is complete.

If you're helping a client or company build a new site/app, and they are not ready and willing to either maintain the site themselves, or pay for a decent maintenance contract, or otherwise guarantee that security patches and hot fixes are applied in a timely manner, they don't yet value their website/app enough. It's your job—as someone who knows the consequences—to convince people of this.

This applies all the more when a project is built on a widely-used platform like Drupal, Wordpress, RoR, Django, etc. Though bespoke/lesser-used frameworks may provide a tiny amount of protection through obscurity, that's still no excuse for not educating people on the importance of maintenance in any software project.

View on HN

Drupal is saying that people were being compromised only hours after the details were known. That's a very short window to update software. In this instance, I'm not really sure what anyone could have done to avoid the potential for compromise. Your install is practically DOA by the time you will learn of the news.

That's exactly the issue. Most enterprises didn't even have time to be notified and properly test/push a patch live before the attacks were already in the wild.

It's like Exploit Wednesday for Windows, except Drupal is a lot easier to reverse and find where the security issues lie given it's open-source.. So instead of taking a day to reverse/find holes, it takes a matter of minutes.

In addition, the issue was leaked pre-announcement among a great many parties who had time to prepare.

Do you have more detail on that? I'd hazard a guess at irresponsible disclosure, or an internal Drupal employee leak.

Then you fall back on backups. These are all very old admin problems.

If I'm using something like Composer to manage dependencies, should I be running an update every week on every past website I've created? I feel like having this run as a cron job would be a bad idea.

If I'm not, is there a way to be notified about critical patches? Should I be signed up for a mailing list for every Github project I've incorporated?

Where I work, it seems like the standard practice is to finish the project, deploy it, and let it sit until the client requests any changes.

It would definitely be a bad idea to run Composer update via cron because unless you know for sure that future versions of packages won't break any functionality you built on top of them, your website could stop working (or worse start working in unexpected ways) without your knowledge.

Maintain a staging environment (even in a temporary virtual machine if necessary) and run your updates in that environment first, then check it, and then deploy to production once you've confirmed everything is ok.

This requires some combo of having a support contract with a budget large enough for manual QA or having built automated tests with the initial work. Vast majority of projects at build-and-forget CMS agencies simply won't. (The reason Drupal and PHP thrive in these environments is because clients can't be upsold out of their cheap LAMP shared hosting.)

This really speaks to this line in the top comment "It's your job—as someone who knows the consequences—to convince people of this."

Your company should really not be taking the "set it and forget it" approach to building web-based applications. It is important to educate the client on the importance of a proactive support/maintenance plan.

As a digital agency building mid-market websites/ applications, we have also found that selling clients on support/maintenance has helped increase client loyalty as well when they want to take on new projects. If you build a site and then disappear the chance they decide to use a different firm next time increases greatly.

You would probably have to make a few assesments, like how often is this package used in my project, and how exposed is it in terms of security vulnerabilities.

An authentication package that provides HTTP endpoints onto your framework where the controller classes are entirely out of your control or you simply pass a Request instance to the service class seems highly likely to be a security risk. The same goes for your ORM(s). Something like a Markdown converter seems less likely, though not impossible.

The popularity of the package could also play a role. If it's popular, it's more likely bugs/vulnerabilities will be spotted and revealed publicly on places like HN or Reddit.

Lastly, if you can ensure that all the packages you use follow semantic versioning, you can lock the version constraint in composer.json to only receive bugfix releases, which would in theory make it safe to run composer update as a cronjob. However, in my experience very few packages do this, and most of them when releasing a new minor version won't backport bugfixes/security fixes to older versions.

Personally, I have an RSS reader set up to notify me of new tags on Github for the more involved packages I use, but I also put a high emphasis on writing a lot of the code myself rather than use packages.

> Something like a Markdown converter seems less likely, though not impossible.

Really? I've found serious XSS bugs in frameworks that are semi-popular for writing real-time applications with a web component. What's outputted from your Markdown converter is generally assumed to be trusted HTML. Additionally, if it's not written in a language with good string support... it has string processing, which could lead to a crash or buffer overflow easily. It seems that a Markdown converter is exactly the sort of place you'd be likely to find an attack vector.

You're right, XSS and client-side injections didn't occur to me when I wrote the comment.

You can run your composer.lock file through here https://security.sensiolabs.org/check to see if there are any vulnerabilities reported against your dependencies.

>If I'm using something like Composer to manage dependencies, should I be running an update every week on every past website I've created?

Absolutely not.

For one, an updated package can bring some subtle or crude incompatible changes when you don't expect it. Even in a minor/bugfix version.

Second, what if the composer repo itself is that got compromised? Then you are installing backdoors to all your sites automatically.

Don't forget providing a way for security researchers to report XSS and similar bugs.

Reply on news.ycombinator.com