4 ms·

> Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position. Those are all my research findings.

> Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position. Those are all my research findings. :P > Is rolling your own ORM and homegrown framework secure? Says who? Says the person who routinely finds exploitable vulnerabilities in other PHP frameworks and content management systems. There will always be things to improve. Feel free to try to find an exploitable security hole. > It's not really a CMS, it's a NIH syndromed framework with a CMS on top of that. That's a typical source of bugs. It's not "NIH syndrome" it's "I don't trust any of these people to write a secure framework and I have the experience to justify this concern". > They are both framework functions, and you wouldn't be writing them if you had written this from the ground up to be secure IMO. Escaping-on-output still implies that escaping happens.

orf 10y ago
> Those are all my research findings. :P Yes, and well done! But there are not many framework specific issues you've found. None in Laravel for example. Is your homemade framework superior to Laravel? If so, how? > Feel free to try to find an exploitable security hole. I can't be bothered to learn your home grown half framework so i understand the convoluted logic. That's the point. There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. But like a lot of PHP projects that roll their own everything it's no trivial task to do a code review. If you had used a well made framework then you would have got rid of a lot of code that only you really understand. > "I don't trust any of these people to write a secure framework and I have the experience to justify this concern". Your code doesn't look like well written, secure code. I'm sorry to sound abrasive but it's true. You mix validation in random places, perhaps inconsistently, and your project tries to do everything. This is not how secure projects are typically designed. > Escaping-on-output still implies that escaping happens. It's only used in 8 places as far as i can see, in some seemingly random places.
- CiPHPerCoder 10y ago
  > Is your homemade framework superior to Laravel? If so, how? Our cryptography is certainly superior to Laravel's. https://github.com/illuminate/encryption https://github.com/illuminate/encryption https://github.com/paragonie/halite https://github.com/paragonie/halite Beyond that, nobody has paid me to look deeper and I haven't had any reason to. > There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. If so, then anyone reading this thread who's aware of any vulnerabilities will be interested in: https://hackerone.com/paragonie https://hackerone.com/paragonie
  - orf 10y ago
    > Our cryptography is certainly superior to Laravel's... Ok, but cryptography is only a small portion of what a framework does and not necessarily the most important bit. I was asking more about your routing, view layer, ORM, code layout, templating, validation, caching, ACLs etc. > Beyond that, nobody has paid me to look deeper and I haven't had any reason to. Look, you can't put up a blog post titled "How We Engineered CMS Airship to Be Simply Secure" and say that when asked "well, how did you actually engineer it to be secure?". In your post you talk about problems all solved by a framework, and apparently you haven't even evaluated what is out there already and rushed headfirst into building it all yourself. This is not engineering a project to be "simply secure", in the sense that it is definitely not simple and probably not secure! > If so, then anyone reading this thread who's aware of any vulnerabilities will be interested... This is great! I wish more companies did this. However, as stated previously, the ad-hoc nature of the code and the single-developer nature[1] makes this pretty hard to do from a code review point of view. Again, using a framework makes your code way easier to review and a lot smaller to boot. Anyone with Django experience can pick up a Django app and start to review it, rather than have to learn whatever bespoke framework the developers of the project dreamed up. Also I just wanted to add that I don't mean to come across as a dick, your project looks interesting for sure and a lot of work has gone into it. PHP CMS's need to start taking security seriously, things like Joomla and random Wordpress plugins are a blight and anything taking security seriously is great! As someone who works in the security industry it's just a bit tiring to see yet another homegrown PHP half-framework full of it's own intricacies and potential issues with the ever familiar problems described in all my comments above, coupled with a post saying how it was engineered to be secure from the ground up. 1. It's hard to tell, in this graph (https://github.com/paragonie/airship/graphs/contributors https://github.com/paragonie/airship/graphs/contributors) is 'paragonie-security' a single person?
    - CiPHPerCoder 10y ago
      > Look, you can't put up a blog post titled "How We Engineered CMS Airship to Be Simply Secure" and say that when asked "well, how did you actually engineer it to be secure?". In your post you talk about problems all solved by a framework, and apparently you haven't even evaluated what is out there already and rushed headfirst into building it all yourself. I've looked at Laravel, about two years ago. http://seclists.org/fulldisclosure/2015/Apr/57 http://seclists.org/fulldisclosure/2015/Apr/57 I haven't looked deeper at what it's done since then, since nobody is paying me to do so. I wasn't impressed then, and instead of waiting for them to get around to doing things right (while figuring out how to preserve backward compatibility), I started from zero. You don't have to like that decision, but that's the decision I made. > Again, using a framework makes your code way easier to review and a lot smaller to boot. Sure, use a framework. And then this happens: https://kivikakk.ee/cryptography/2016/02/20/breaking-homegrown-crypto.html https://kivikakk.ee/cryptography/2016/02/20/breaking-homegro... I designed my own because, unfortunately, most of the PHP community either doesn't prioritize security enough to be trustworthy, or is simply in over their heads. We use third party libraries (Twig for templates, HTML Purifier for allowing some HTML but avoiding XSS vulnerabilities) because they're well-studied and trustworthy libraries. However, I do not trust most other PHP developers to do anything security-critical correctly. And thus, I will not design something meant to be secure based on an insecure foundation. If your only reason for Airship's status as "probably insecure" is because it's "ad-hoc" and/or "bespoke": Sorry, that's insufficient. Got a PoC handy? Otherwise: we're talking about pure hypotheticals that are far removed from the real world and there's not much point in that. You can frame your criticism as "things to make the code easier to read/understand" and whatnot, and they stand alone. Citing them as "probably a vulnerability" is questionable, however. > It's hard to tell, in this graph (https://github.com/paragonie/airship/graphs/contributors https://github.com/paragonie/airship/graphs/contributors) is 'paragonie-security' a single person? For the moment, I'm the only technical person at Paragon. That will change, and that account will be delegated to signing/committing the code changes made by other employees. > As someone who works in the security industry it's just a bit tiring to see yet another homegrown PHP half-framework full of it's own intricacies and potential issues with the ever familiar problems described in all my comments above, coupled with a post saying how it was engineered to be secure from the ground up. You've raised legitimate concerns over: - Apparent NIH-syndrome, which in this case is justified - Minor code quality nits, which are now fixed - Bus factor ...but none of those are, directly, a security problem. :)

orf 10y ago

> Those are all my research findings. :P Yes, and well done! But there are not many framework specific issues you've found. None in Laravel for example. Is your homemade framework superior to Laravel? If so, how? > Feel free to try to find an exploitable security hole. I can't be bothered to learn your home grown half framework so i understand the convoluted logic. That's the point. There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. But like a lot of PHP projects that roll their own everything it's no trivial task to do a code review. If you had used a well made framework then you would have got rid of a lot of code that only you really understand. > "I don't trust any of these people to write a secure framework and I have the experience to justify this concern". Your code doesn't look like well written, secure code. I'm sorry to sound abrasive but it's true. You mix validation in random places, perhaps inconsistently, and your project tries to do everything. This is not how secure projects are typically designed. > Escaping-on-output still implies that escaping happens. It's only used in 8 places as far as i can see, in some seemingly random places.

CiPHPerCoder 10y ago
> Is your homemade framework superior to Laravel? If so, how? Our cryptography is certainly superior to Laravel's. https://github.com/illuminate/encryption https://github.com/illuminate/encryption https://github.com/paragonie/halite https://github.com/paragonie/halite Beyond that, nobody has paid me to look deeper and I haven't had any reason to. > There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. If so, then anyone reading this thread who's aware of any vulnerabilities will be interested in: https://hackerone.com/paragonie https://hackerone.com/paragonie
- orf 10y ago
  > Our cryptography is certainly superior to Laravel's... Ok, but cryptography is only a small portion of what a framework does and not necessarily the most important bit. I was asking more about your routing, view layer, ORM, code layout, templating, validation, caching, ACLs etc. > Beyond that, nobody has paid me to look deeper and I haven't had any reason to. Look, you can't put up a blog post titled "How We Engineered CMS Airship to Be Simply Secure" and say that when asked "well, how did you actually engineer it to be secure?". In your post you talk about problems all solved by a framework, and apparently you haven't even evaluated what is out there already and rushed headfirst into building it all yourself. This is not engineering a project to be "simply secure", in the sense that it is definitely not simple and probably not secure! > If so, then anyone reading this thread who's aware of any vulnerabilities will be interested... This is great! I wish more companies did this. However, as stated previously, the ad-hoc nature of the code and the single-developer nature[1] makes this pretty hard to do from a code review point of view. Again, using a framework makes your code way easier to review and a lot smaller to boot. Anyone with Django experience can pick up a Django app and start to review it, rather than have to learn whatever bespoke framework the developers of the project dreamed up. Also I just wanted to add that I don't mean to come across as a dick, your project looks interesting for sure and a lot of work has gone into it. PHP CMS's need to start taking security seriously, things like Joomla and random Wordpress plugins are a blight and anything taking security seriously is great! As someone who works in the security industry it's just a bit tiring to see yet another homegrown PHP half-framework full of it's own intricacies and potential issues with the ever familiar problems described in all my comments above, coupled with a post saying how it was engineered to be secure from the ground up. 1. It's hard to tell, in this graph (https://github.com/paragonie/airship/graphs/contributors https://github.com/paragonie/airship/graphs/contributors) is 'paragonie-security' a single person?
  - CiPHPerCoder 10y ago
    > Look, you can't put up a blog post titled "How We Engineered CMS Airship to Be Simply Secure" and say that when asked "well, how did you actually engineer it to be secure?". In your post you talk about problems all solved by a framework, and apparently you haven't even evaluated what is out there already and rushed headfirst into building it all yourself. I've looked at Laravel, about two years ago. http://seclists.org/fulldisclosure/2015/Apr/57 http://seclists.org/fulldisclosure/2015/Apr/57 I haven't looked deeper at what it's done since then, since nobody is paying me to do so. I wasn't impressed then, and instead of waiting for them to get around to doing things right (while figuring out how to preserve backward compatibility), I started from zero. You don't have to like that decision, but that's the decision I made. > Again, using a framework makes your code way easier to review and a lot smaller to boot. Sure, use a framework. And then this happens: https://kivikakk.ee/cryptography/2016/02/20/breaking-homegrown-crypto.html https://kivikakk.ee/cryptography/2016/02/20/breaking-homegro... I designed my own because, unfortunately, most of the PHP community either doesn't prioritize security enough to be trustworthy, or is simply in over their heads. We use third party libraries (Twig for templates, HTML Purifier for allowing some HTML but avoiding XSS vulnerabilities) because they're well-studied and trustworthy libraries. However, I do not trust most other PHP developers to do anything security-critical correctly. And thus, I will not design something meant to be secure based on an insecure foundation. If your only reason for Airship's status as "probably insecure" is because it's "ad-hoc" and/or "bespoke": Sorry, that's insufficient. Got a PoC handy? Otherwise: we're talking about pure hypotheticals that are far removed from the real world and there's not much point in that. You can frame your criticism as "things to make the code easier to read/understand" and whatnot, and they stand alone. Citing them as "probably a vulnerability" is questionable, however. > It's hard to tell, in this graph (https://github.com/paragonie/airship/graphs/contributors https://github.com/paragonie/airship/graphs/contributors) is 'paragonie-security' a single person? For the moment, I'm the only technical person at Paragon. That will change, and that account will be delegated to signing/committing the code changes made by other employees. > As someone who works in the security industry it's just a bit tiring to see yet another homegrown PHP half-framework full of it's own intricacies and potential issues with the ever familiar problems described in all my comments above, coupled with a post saying how it was engineered to be secure from the ground up. You've raised legitimate concerns over: - Apparent NIH-syndrome, which in this case is justified - Minor code quality nits, which are now fixed - Bus factor ...but none of those are, directly, a security problem. :)