How We Engineered CMS Airship to Be Simply Secure
paragonie.com
How We Engineered CMS Airship to Be Simply Secure
1–10 of 25 posts
Re: How We Engineered CMS Airship to Be Simply Secure
#2I'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 running only for them to easily change content? Content creators should have an offline app, make changes, press publish and have those changes uploaded to a static server. The whole CMS control panel paradigm seems kinda flawed to me.
Re: How We Engineered CMS Airship to Be Simply Secure
#3What 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.
Re: How We Engineered CMS Airship to Be Simply Secure
#4After 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 (and something PHP apps seem to have a continual problem with), but why did you decide to roll your own framework for doing this? Are all of the well maintained, tested and great ones already available not suitable for some reason? It's just your app turns into a hard to check, inefficient[5] sludge, full of lots of code for handling framework related things like an ORM, caching[6] (that code is practically duplicated in a lot of places[7][8][9][10]), escaping[11], mime whitelisting[12] etc and not much about a CMS. This is where security bugs appear.
1. https://github.com/paragonie/airship/blob/eb4293aee5be59e329...
2. https://github.com/paragonie/airship/blob/c4c9384d4d7860738d...
3. https://github.com/paragonie/airship/blob/c4c9384d4d7860738d...
4. https://github.com/paragonie/airship/blob/95af23ca782e8ecb10...
5. https://github.com/paragonie/airship/blob/63cf0661ba21cbb3f3...
6. https://github.com/paragonie/airship/blob/master/src/view_fu...
7. https://github.com/paragonie/airship/blob/master/src/view_fu...
8. https://github.com/paragonie/airship/blob/master/src/view_fu...
9. https://github.com/paragonie/airship/blob/63cf0661ba21cbb3f3...
10. https://github.com/paragonie/airship/blob/2a8a87934921ecda85...
11. https://github.com/paragonie/airship/blob/eb4638eb31510028f4...
12. https://github.com/paragonie/airship/blob/eb4638eb31510028f4...
Re: How We Engineered CMS Airship to Be Simply Secure
#5I'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 pulling information from a central resource, which is going to be over the internet, whether its on a different server or not.
Not to mention, by having it 'offline', you can't have mobile apps to edit content on your site.
Static definetely has advantages, but when scaled and working with data its not that simple.
Re: How We Engineered CMS Airship to Be Simply Secure
#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, it will be very hard to detect it -- was this file changed by auto-updater or by malware? you don't know. And even if the new version of webapp was released which fixes the bug, you can not be sure that infection is gone -- because the update process may also be compromised. And you cannot easily remove code dir and re-download -- the settings are mixed-in with the code.
Compare it with any other stack -- Ruby on Rails, Django, JAR files, whatever. Code cannot modify itself. The only writable thing is the database. Additionally, the repository is often under git control. If there is a vulnerability, update software and restart the server (if in doubt, backup the database and nuke/rebuild the server instead). Even if you made a configuration error and left code dir writable, "git status" is enough to tell you any changed/added files.
And this is why you, as an admin, should avoid PHP if you care about security. Sure, you can use sane techniques even with PHP code -- I am sure that's what Facebook and Wikipedia do -- but most random PHP projects will require writable code dir. When choosing a web app, choose non-PHP one first.
Re: How We Engineered CMS Airship to Be Simply Secure
#7After 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…
SQL injection is a solved problem, just use parameterized queries.
Re: How We Engineered CMS Airship to Be Simply Secure
#8> 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…
Airship has most paranoid auto-update system I've ever seen. You can read about it here: https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cry...
It also convers the "external code integrity control":
Keyggdrasil makes sure everyone sees the same public keys, prevents anyone from rewriting history, and makes targeted attacks noisy.
Autoupdating is not a feature specific to PHP. You can do manual updates as you described with it too, so I'm not sure why you even contrast it to other languages or CMS.
It's pretty much established that properly implemented autoupdates increase security, not reduce it. I agree that writeable and executable directory is a huge risk, though.
Re: How We Engineered CMS Airship to Be Simply Secure
#9After 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 why did you decide to roll your own framework for doing this?
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.
> Are all of the well maintained, tested and great ones already available not suitable for some reason?
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, especially if we're paying money for vulnerabilities: https://hackerone.com/paragonie
5. 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.
6-10. Good eye. I think that can be refactored to repeat itself less.
11. I don't see a problem with this?
12. I don't see a problem with this either.
Re: How We Engineered CMS Airship to Be Simply Secure
#10> 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 anything, and run continuum.sh as a more privileged user if that's what you want.
Just don't disable automatic updates.