1. 1

    https://dustri.org — mostly about computer security

    1. 2

      Nice logo animation)

      1. 1

        Done in pure css :)

        1. 1

          Ios support?

          1. 1

            No idea :/

      1. 1

        https://dustri.org → a bit of javascript for the landing page, Pelican for the blog.

        1. 6

          Pelican since 2012 for my blog, but I’m using (and would recommend) hugo for new project, mostly because the former is super-duper-slow.

          1. 1

            It is surprising that all vulnerabilities listed are mitigated, my hypothesis is that only mitigated vulnerabilities were looked for, making the perfect score.

            Also the numbe of attack vector that this security module prevent show how much php is insecure. It also let suppose that some are not covered.

            The majority of hosting don’t use this security module I would say, starting with wordpress.com, making this solution only for a happy few.

            1. 2

              Well, no. The blog post does list vulnerabilities not mitigated by the module.

              1. 2

                I’m the lead dev of Snuffleupagus and author of the article, and I’ll be happy to add whatever less-than-two-years-old major vulnerability you suggest to my blogpost. I did my very best to add all the relevant ones: I went through Drupal, Wordpress, Joomla, the RIPS blogposts, bugbounties programs, WAF rules, … but I’m sure I might have missed some.

                PHP has some shortcomings when it comes to security, this is why Snuffleupagus was created. About the vulnerabilities not covered, well, as explained at the end of the articles, some can’t mitigated by Snuffleupagus.

                Snuffleupagus is licensed under LGPL, so everyone is more than welcome to use it. The article was written to show that it’s an efficient solution to PHP-related security issues, in the hope that more people would deploy it. Its features aren’t upstreamed because most of them wouldn’t be accepted anyway.

                1. 1

                  Sorry for my wrong hypothesis, your product has better coverage of php vulnerabilities than I thought: congrats.

                  1. 1

                    Do you have a table of mitigations and how/why they could or could not be upstreamed? (I’m assuming your goal is to be obsoleted in the long term of php ever becomes more secure, but maybe that’s unreasonable to hope for :-))

                    1. 3

                      My bet is that php is very very conservative on not breaking backward compatibility, and as much I understand, all this mitigations break it in typical legitimate program even if they don’t exist in typical program. For example, filtering metacharacters before calling system will break some legitimate use of system.

                      The best thing that could happen is to ship it as an optionnal module, but everything which is not default miss the major target.