Skip to content

Security: kveroneau/PascalPress

Security

docs/Security.md

Security: A First Priority

Most publishing frameworks, systems, and web applications all expose some sort of administrative endpoint over HTTPS for an administrator to use to update the content on the website. As seen in practice, this can lead to a constant flood of attacks, downed websites, defaced websites, and the list just goes on. I personally don't want my online blog to ever be victim to any of these sort of security issues, which is why I have started this project, as there aren't many or any blogging systems that allow this sort of system to administrate the content with. My first attempt at making such a system was with PuterBlogger which you can edit with either the Puter Admin App or the desktop app, rather than an HTTP end-point on the website itself. The main issue with those solutions is the extra effort required with the desktop app to manually upload the .json file exported by the blog desktop app. This can become a bit tedious over time.

Use-case Concept 1: User runs own cloud server and hosts blog

Are you like me, a single individual user and you will be the sole person to ever create content on your personal blog? Do you value security and don't really want to install Wordpress on your personal cloud server in fear of a potential security issue? PascalPress to the rescue! With PascalPress, all you need is a compatible database server, most personal cloud servers will usually have either PostgreSQL or MySQL installed or accessible via their service providers cloud network. This project current ships with support for PostgreSQL out of the repo, but it can be swapped with a bit of effort to use another database server of your choosing. I may soon make a way to either support multiple out of the repo with a simple configuration, or provide perhaps compile-time definitions which can allow the swapping of database servers. I'd rather not build in support for all of them, as it will do many things, increase the binary size, increase the amount of deps needed, and add more potential security issues. A database server should be selected at compile-time for the upmost security in my humble opionion.

In this use-case, you'd compile the RESTServer to communicate to your database server, and have it listen on a localhost FastCGI connection. Then your web server would host the WebClient software as it would any website, and connect to the FastCGI server end-point when requesting data from the database. Then you would use an SSH tunnel ssh -L 5432:localhost:5432 mycloud.com, then run the AdminApp with the database server being localhost, and entering in your database credentials. Then you will be-able to add and edit all the content on your blog with ease, and once you publish an article and press Save Database from the File menu, all of your visitors that refresh the page or new visitors will now see all the new content. Current visitors might in the future, but this will require the webclient to refresh it's own dataset from the server, which is possible, but I don't want to add too much additional network traffic to check this. Another less traffic intensive method might be added in the future.

Use-case Concept 2: Older Corporation with all in-house servers

Are you part of a traditional corporation whom still runs all of their servers, including the web servers on-prem? Do you want to limit what any external connection into your corporation can do? Well, look no further than PascalPress! With PascalPress, there are zero external administrative end-points required to publish any content, all the while, visitors can rest easy knowing that they can easily view the content without fear of any of it being attacked by hackers or other security issues. The code is easy to make quick adjustments to change the back-end database server, and to add additional content types(soon). If your goal is to just host a secure blog with zero externally accessible administrative end-points, then please consider PascalPress.

The desktop app may need to be modified if multiple employees need to be updating content at the same time, or have one dedicated employee be the one whom uses the AdminApp to take the content from the writers and to place that content onto the website. The only externally facing server API is that of the RESTServer, which by default is configured to be read-only, and really should remain in that state. Although, if a comments module is ever added, that table might need to be exposed, but, a comments module will always remain optional, and no module that needs to write back to the server will ever be a requirement.

Use-case Concept 3: Corporation with cloud servers

Most Cloud service providers these days actually provide VPN services directly into a specific network, say one that is running a managed instance of PostgreSQL. This will allow any employee with this VPN access to use the AdminApp to connect directly to the PostgreSQL database server to add and edit content. Essentially this secure VPN connection which your cloud hosting provider gives you is your administrative end-point, which is going to be much more secure than an administrative end-point exposed from HTTPS. The actual RESTServer and WebClient can be hosted inside a Docker container, so no actual cloud server would be needed. There is a Caddyfile in this repo which you can use as a reference on how to get Caddy working, which can run inside a Docker container to host the application. The RESTServer could also be hosted inside it's own Docker container, and even scaled if needed to support a lot more traffic. Technically, your company could write it's own compatible REST Server, and have the back-end written in a language you are most familar with, and still have the front-end in PascalPress, each part of this project is modular, in that your company can choose which pieces to use, and which it would rather write itself.

There aren’t any published security advisories