HisarBlok · documentation
Security and visitor input
The published site is nothing but files, out of reach of the largest classes of attack. The rest is about how the admin and the single visitor door are protected.
For version 0.13.1.
The security model
Reading a page runs no code
If an anonymous visitor's request runs no code, running code through that request becomes very hard.
An admin apart from the site
At its own address: a nonce-based Content Security Policy, a CSRF token on every form, Argon2id passwords, session binding, sign-in limits and optional TOTP.
Author HTML is cleaned
Against an allow-list, with PHP's HTML5 parser, on save and on every build. A result that changes on a second pass falls back to plain text.
`data/` outside every document root
The database, configuration, backups and rate-limit records. The wizard will not go on while that directory can be reached from outside.
Signed updates
Nothing unpacks without a valid signature; the tool refuses to run as root, and the admin never writes code.
No dependencies, no tracking
No CDN, no web fonts from elsewhere, no third-party scripts. The only third-party part is the admin's editor, served from your server.
One visitor door
A comment, a contact form or a sign-up is a reader writing, and writing has to reach something. HisarBlok answers that with one door, not with a dynamic site: the site's go.php (POST only) and get.php for counted links. Nothing else on the site accepts a request; one door is a door that can be watched.
At the door, in order:
- Same origin: a form posted from another site is refused before any module sees it.
- Form token: stateless and signed; bound to the site, the action and the page, valid for seven days. A token taken from another page does not work here.
- Time gate and honeypot: a form sent back too fast, or a form filler that fills the hidden field, is refused.
- A budget for accepted submissions: 20 per address and 300 per site in 15 minutes; over either, nothing is stored. A busy site sets its own numbers in the configuration.
- Nothing slow in the request: notification mails are queued, merged per recipient and sent after the answer has gone.
Visitors get no session and no cookie; a static page has to stay the same for everyone. There is no CAPTCHA, on purpose: a puzzle taxes every reader, and the usual ones send them to a third party. A refused form comes back as the form itself instead of a bare error page: each error beside its field, everything typed kept.
To be plain about what the token is not: proof of a person, or single-use. Every reader of a static page gets the same token. What stops a script holding one is the budget, not the token.
Accounts and sites
One installation can publish several sites with one list of accounts. An account reaches every site unless it is limited. Under People → Sites an account can be limited to some sites, with a role per site; a limited account never manages people, modules, updates, backups or email.
The sites still share one PHP user, one data/ directory and one database. Sites run by people who must not reach each other's content at all (two customers, say) belong in separate installations.
Cookieless statistics
HisarBlok counts views on the site's own server. Collected: views per page, visitors counted once a day, only the host name of a referring site, and the share of phones and computers; all as daily totals. Not collected: cookies or browser storage, IP addresses, browser strings, screen sizes or any other fingerprint. People are told apart within a day by a secret key that changes daily and is deleted when the day is over. Browsers that ask not to be tracked, robots and requests from other sites are not counted. Statistics are on by default and switched off per site on the Statistics screen.
Reporting a vulnerability
If you have found a vulnerability in HisarBlok, please report it to security@kodhisar.com before writing about it anywhere public. We take reports seriously and say plainly in the release notes what was fixed.