Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Engineered CMS Airship to Be Simply Secure

paragonie.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: How We Engineered CMS Airship to Be Simply Secure

#11

Post by CiPHPerCoder »

devwastaken wrote: post #5
ogig wrote: post #2

I've been using S3 static sites more and more and I think that exposing any kind of CMS control panel to the internet is a bad idea. Take a look at the list of security concerns Airship tries to manage. Most can be avoided by separating the content creation aspect and the publishing platform. Content creators represent the smallest audience group your site has, why then have a full application exposed to the internet…

Hardly is it that static content is the way to go when you're working with any sort of dynamic data. If you're just making blog posts, Airship most likely isn't for you. An offline app would cause a number of its own problems in that regard, because now you're actually having to design a backend that interface with your webserver and puts the content to it. What happens when you have multiple editors? You're now pull…

One of the projects on our to do list is actually creating a static publishing module that can be used for either:

  - Offline editing for online publishing
  - Static mirrors to resist censorship in the face of DDoS
Updates would be sent from an Airship to a static hub, using challenge-response authentication, with Ed25519 signatures.

Aside from the API that receives data and triggers an update (which is intended to be set up on a different vhost), the attack surface will be minimal.

The only reason this isn't already a thing is that I've had other projects that were higher priority, including one I'll be releasing in a month or so (but probably not submitting to HN; it's an entirely commercial project).

Re: How We Engineered CMS Airship to Be Simply Secure

#13

Post by jarofgreen »

megous wrote: post #3

What always boggled my mind was escaping data on the input side. Yet once it was quite popular. PHP even had option to do it automatically. What a weird idea. You escape data to prevent mistaking it for code whenever you use them in some context. You don't know the context when receiving the input.

The only people I know off doing that now are WordPress. Modern PHP really has come a long way. (And in it's defence, a lot of good PHP at the time didn't use this auto-escaping feature. It was the PHP's designers flawed [as you point out] attempt to try and stop bad PHP developers shooting themselves in the foot.)

In fact, while I found the article interesting I could have done with a bit less of the barbs about other frameworks. If the only way you have of building up your own tech thing is by tearing down other people's ...

Re: How We Engineered CMS Airship to Be Simply Secure

#14

Post by orf »

CiPHPerCoder wrote: post #9
orf wrote: post #4

After a quick peruse of their github repository I have to say there is some dodgy[1] stuff going on. As ever with PHP sites validation seems to be a mess. For example we've got a `escapeSupplierName` function[2] used in some places[3], but a different regex used when creating a suppier[4]. Variants of that regex also appear all over the code, why not put it in a single place? Properly escaping SQL injection is great…

Thank you for taking the time to look through the code. 1. Context matters: That's a CLI script used to build and sign core updates. We bundle it with the source code so anyone can fork our project and use only their own keys, easily. 2-4. This is a good point. https://github.com/paragonie/airship/issues/181 > Properly escaping SQL injection is great (and something PHP apps seem to have a continual problem with), but…

> Context matters: That's a CLI script.

Ahh, my bad, it's still an odd way of doing this. And it's vulnerable to injection via the prompt parameter (not that it matters, but...). That pattern is repeated in a couple of places like the updater.

> Because when Airship was started, everyone insisted on backwards compatibility for PHP 5 and I wanted to make use of strict typing. The master branch includes a static analyzer as part of continuous integration.

Strict typing is great, but you don't have to write your own framework to benefit from it. Is PHP 5 not compatible with modern frameworks?

> Have you seen what I've done to PHP frameworks over the years?

> https://scott.arciszewski.me/open-source/

> https://paragonie.com/security/advisories

> I wasn't in a hurry to pick up other peoples' technical debt.

Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position.

You aren't in a hurry to pick up others technical debt, but you rush ahead and create your own?

All I'm saying is you put out a post saying you designed this from the ground up to be secure, but did you really? Is rolling your own ORM and homegrown framework secure? Says who?

Yeah, you use modernish stuff like csp etc, but the code is still a typical PHP spaghetti of mixed concerns and hard-to-audit flows. It's not really a CMS, it's a NIH syndromed framework with a CMS on top of that. That's a typical source of bugs.

> That's simply a paranoia/convenience feature. If you've got a better way to automagically convert filename.txt into filename-5.txt if filename.txt, filename-2.txt, filename-3.txt, and filename-4.txt already exist, I'm all ears.

It could be done in a single query, I'm on my phone so i cant write you an example right now.

> 11. I don't see a problem with this?

> 12. I don't see a problem with this either.

They are both framework functions, and you wouldn't be writing them if you had written this from the ground up to be secure IMO. It's kind of code smell. Using a whitelist is good though.

Re: How We Engineered CMS Airship to Be Simply Secure

#15

Post by CiPHPerCoder »

orf wrote: post #14
CiPHPerCoder wrote: post #9

Earlier quoted context omitted.

Thank you for taking the time to look through the code. 1. Context matters: That's a CLI script used to build and sign core updates. We bundle it with the source code so anyone can fork our project and use only their own keys, easily. 2-4. This is a good point. https://github.com/paragonie/airship/issues/181 > Properly escaping SQL injection is great (and something PHP apps seem to have a continual problem with), but…

> Context matters: That's a CLI script. Ahh, my bad, it's still an odd way of doing this. And it's vulnerable to injection via the prompt parameter (not that it matters, but...). That pattern is repeated in a couple of places like the updater. > Because when Airship was started, everyone insisted on backwards compatibility for PHP 5 and I wanted to make use of strict typing. The master branch includes a static analyz…

> Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position.

Those are all my research findings. :P

> Is rolling your own ORM and homegrown framework secure? Says who?

Says the person who routinely finds exploitable vulnerabilities in other PHP frameworks and content management systems.

There will always be things to improve. Feel free to try to find an exploitable security hole.

> It's not really a CMS, it's a NIH syndromed framework with a CMS on top of that. That's a typical source of bugs.

It's not "NIH syndrome" it's "I don't trust any of these people to write a secure framework and I have the experience to justify this concern".

> They are both framework functions, and you wouldn't be writing them if you had written this from the ground up to be secure IMO.

Escaping-on-output still implies that escaping happens.

Re: How We Engineered CMS Airship to Be Simply Secure

#16

Post by xorraxrax »

My biggest problem with Paragon IE is the fact that its owner, Scott Arciszewski, continues trying to make it seem as though his company consists of anyone else other than just himself.

From the kitschy redundant name (is it an Initiative or an Enterprise?) to the awful typography, web design and logos[1], to the fact that all of his blog posts and commits are anonymized as "P.I.E. staff", "paragonie-security"... There is clearly no-one else working for him. I'm not saying that crypto and security work should only be entrusted to large corporations, but this makes him come across as dishonest right off the bat.

Scott, if you truly stand behind your software then you need to shed the corporate charade and promote it as yourself. And please get someone else to do your graphic design work in future.

[1]: https://airship.paragonie.com/

Re: How We Engineered CMS Airship to Be Simply Secure

#17

Post by orf »

CiPHPerCoder wrote: post #15
orf wrote: post #14

Earlier quoted context omitted.

> Context matters: That's a CLI script. Ahh, my bad, it's still an odd way of doing this. And it's vulnerable to injection via the prompt parameter (not that it matters, but...). That pattern is repeated in a couple of places like the updater. > Because when Airship was started, everyone insisted on backwards compatibility for PHP 5 and I wanted to make use of strict typing. The master branch includes a static analyz…

> Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position. Those are all my research findings. :P > Is rolling your own ORM and homegrown framework secure? Says who? Says the person who routinely finds exploitable vulnerabilities in other PHP frameworks and content management systems. There will always be things to improve. Feel free to try to find an ex…

> Those are all my research findings. :P

Yes, and well done! But there are not many framework specific issues you've found. None in Laravel for example. Is your homemade framework superior to Laravel? If so, how?

> Feel free to try to find an exploitable security hole.

I can't be bothered to learn your home grown half framework so i understand the convoluted logic. That's the point. There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. But like a lot of PHP projects that roll their own everything it's no trivial task to do a code review. If you had used a well made framework then you would have got rid of a lot of code that only you really understand.

> "I don't trust any of these people to write a secure framework and I have the experience to justify this concern".

Your code doesn't look like well written, secure code. I'm sorry to sound abrasive but it's true. You mix validation in random places, perhaps inconsistently, and your project tries to do everything. This is not how secure projects are typically designed.

> Escaping-on-output still implies that escaping happens.

It's only used in 8 places as far as i can see, in some seemingly random places.

Re: How We Engineered CMS Airship to Be Simply Secure

#18

Post by CiPHPerCoder »

orf wrote: post #17
CiPHPerCoder wrote: post #15

Earlier quoted context omitted.

> Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position. Those are all my research findings. :P > Is rolling your own ORM and homegrown framework secure? Says who? Says the person who routinely finds exploitable vulnerabilities in other PHP frameworks and content management systems. There will always be things to improve. Feel free to try to find an ex…

> Those are all my research findings. :P Yes, and well done! But there are not many framework specific issues you've found. None in Laravel for example. Is your homemade framework superior to Laravel? If so, how? > Feel free to try to find an exploitable security hole. I can't be bothered to learn your home grown half framework so i understand the convoluted logic. That's the point. There are vulnerabilities in there…

> Is your homemade framework superior to Laravel? If so, how?

Our cryptography is certainly superior to Laravel's.

https://github.com/illuminate/encryption

https://github.com/paragonie/halite

Beyond that, nobody has paid me to look deeper and I haven't had any reason to.

> There are vulnerabilities in there, I've seen enough code like that to almost guarantee you.

If so, then anyone reading this thread who's aware of any vulnerabilities will be interested in: https://hackerone.com/paragonie

Re: How We Engineered CMS Airship to Be Simply Secure

#19

Post by theamk »

CiPHPerCoder wrote: post #10
theamk wrote: post #6

> Since Airship self-updates, it needs to be able to write to itself. > chown -R myusername:www-data airship > chmod -R g+w airship Have you ever wondered why some people say that PHP is insecure? That's one of the major reasons. This app claims to care about security, but at the same time it self-updates and has no external code integrity control. This means that if the webapp has a vulnerability which was exploited…

What 'dchest said, but also: https://paragonie.com/blog/2016/10/guide-automatic-security-... Security at the expense of usability, comes at the expense of security. CMS Airship went with the "self-writing code" option because we believe the potential damage of a 1day vulnerability to be much a higher concern than theoretical "this isn't really following best practices grumble grumble". By all means, don't chmod/chown…

I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect.

Because there will be security vulnerability, and people will be exploited, and even if your update system runs every 4 hours, it will take dev team some time to write up a fix and push an update. And obviously, the first thing attacker would do will be to disable any integrity checks your auto-update does. So in the most common case, the host will stay compromised forever.

This looks pretty horrible to me. I am appealed that you call this "theoretical". But then, (in my experience) the security is not a strong side of PHP community.

The sad part, it is not hard to fix. You already have separate update script -- obviously "don't chmod/chown anything" is not enough, you at least want the cache directory to be writeable, and while I have not looked at the code, I suspect there may be other locations that web app will want to write to. You can change your Dockerfile to use secure setup. It will take a bit of work but it is definitely possible.

Until this is done, "simply secure" is only until the first compromise.

Re: How We Engineered CMS Airship to Be Simply Secure

#20

Post by CiPHPerCoder »

theamk wrote: post #19
CiPHPerCoder wrote: post #10

Earlier quoted context omitted.

What 'dchest said, but also: https://paragonie.com/blog/2016/10/guide-automatic-security-... Security at the expense of usability, comes at the expense of security. CMS Airship went with the "self-writing code" option because we believe the potential damage of a 1day vulnerability to be much a higher concern than theoretical "this isn't really following best practices grumble grumble". By all means, don't chmod/chown…

I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect. Because there will be security vulnerability, and people will be exploited, and even if your update system runs every 4 hours, it will take dev team some time to write up a fix and push an update.…

> I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect.

The auto-updater does nothing to make this worse. That's true of any vulnerable system. Once you're owned, you're owned.

> Because there will be security vulnerability, and people will be exploited, and even if your update system runs every 4 hours, it will take dev team some time to write up a fix and push an update.

It runs every 15 minutes, in the default configuration, and our usual turnaround time for getting a bugfix out is less than 1 hour.

> The sad part, it is not hard to fix.

It's not broken, it's a trade-off. Nothing to fix.

> You already have separate update script

That's the kicker: If your threat model prioritizes "don't let the httpd write to the web directory" higher than your usual non-power-user, then simply:

1. Set up a cronjob to run the update script, run by a more privileged user.

2. Don't chown/chmod.

The reason we do this by default is because our threat model is ensuring automatic updates work for everyone (including people who are not sophisticated enough to set up a cronjob).

> You can change your Dockerfile to use secure setup. It will take a bit of work but it is definitely possible.

I guess?

The Dockerfile was provided by the community and is maintained by the community; I don't use it nor do I touch it.

I'm not a Docker user. https://news.ycombinator.com/item?id=10269200

> Until this is done, "simply secure" is only until the first compromise.

That's literally true of anything. If you get compromised, burn the machine and recover from a backup.

Post reply on HN