Decentralized search engine & automatized press reviews

Version 1.7.7 : security audit

As a last step planned in late 2019 and announced here, the NLnet (via the NGI0 consortium which was granted funds from the European Horizon 2020 project) and the RadicallyOpenSecurity company was providing a security audit.

The new v1.7.7 release is the result of this audit, with mainly (small) security improvements.

After some delays (in months) in the planning of the audit, everything went smoothly. First I provided credentials to get an account in RadicallyOpenSecurity infrastructure (including a private GitLab repository hosting the audit results and a web chat).

Then came some more waiting (in weeks) for a penetration tester to select for its next task (and reviewing a WebExtension seemed not so common). Once a courageous pen.-tester showed up, we started with a video-conference during which we discussed about what is and what it intends to do. I was also asked about what potential security issues I would foresee and I was pleased to list points I was wanting to get checked.

Results came during the next weeks with some text chat to keep heading in the right direction. The collaboration was efficient : I learnt a lot, was happy to get mainly good results and finally quite occupied with the effective findings to fix and the recommendations to implement.

The methodology was simple : inspect the castle walls. What comes in, what goes out. All the dependencies were checked, and then the data from fetched sources (with an elaborated network frame inspection setup) and the exported files.

The basics principles of were confirmed (no third-party trackers are activated while using, source data were correctly sanitized (except in the exotic scenario of JSON-responding sources, which is fixed by this release) and the recommended Two-Factor Authentication (2FA) was already activated for all online services relies on (domain name registration, web hosting, Mozilla Addons repository…).

I was advised to further document intended behavior regarding security aspects in addition to how-to report security issues to the project. Stricter Content Security Policy (CPS) rules were also advised as this was already my naïve implementation of this mechanism that got me covered against severe issues in the JSON-responding sources scenario. A fire-wall approach with everything disabled by default and only what’s needed allowed was elected and implemented (which required quite some work to avoid inline CSS for instance).

To finish with security, I’ve been introduced to ReDOS attacks : denial of service through regular expression slow edge-case feeding. Now on, source-definitions will be tested against Nicolaas Weidman RegexStaticAnalysis tool (despite the fact that it’s written in Java :-p).

Then, as I updated dependencies I activated the CodeMirror json-lint plugin which allows to underline malformed JSON content in the source creation textarea. I also traded 15 small try/catch blocks in the code against one big that ensure every searches will now have an end (even if a source is causing a bug in with an unanticipated answer). Try/catch blocks were non-optimizable portions of code since a long time but things have evolved. Let me know if you hit measurable performance penalties.

A last word about statistics, we can guess that the majority of the users are French (not only because Mozilla reports 75% of french-speaking users, or because I mainly presented to french audiences) but also because statistics are dramatically dropping during holidays : from 800 users a day to 550 in mid-august.

Fortunately, the number of sources is still growing, with currently 310 !

PS: A new way of supporting has recently been introduced, it’s HelloAsso. It allows one shot donations and to get 100% of your donation sent to the new non-profit association (if you click to remove their self-added tip). For the record, the complete list of how to support is available here.