5 ms·

Thank you for taking the time to look through the code. 1. Context matters: That's a CLI script used to build and sign core updates. We bundle it with the sour

Thank you for taking the time to look through the code. 1. Context matters: That's a CLI script used to build and sign core updates. We bundle it with the source code so anyone can fork our project and use only their own keys, easily. 2-4. This is a good point. https://github.com/paragonie/airship/issues/181 https://github.com/paragonie/airship/issues/181 > Properly escaping SQL injection is great (and something PHP apps seem to have a continual problem with), but why did you decide to roll your own framework for doing this? Because when Airship was started, everyone insisted on backwards compatibility for PHP 5 and I wanted to make use of strict typing. The master branch includes a static analyzer as part of continuous integration. > Are all of the well maintained, tested and great ones already available not suitable for some reason? Have you seen what I've done to PHP frameworks over the years? https://scott.arciszewski.me/open-source/ https://scott.arciszewski.me/open-source/ https://paragonie.com/security/advisories https://paragonie.com/security/advisories I wasn't in a hurry to pick up other peoples' technical debt, especially if we're paying money for vulnerabilities: https://hackerone.com/paragonie https://hackerone.com/paragonie 5. That's simply a paranoia/convenience feature. If you've got a better way to automagically convert filename.txt into filename-5.txt if filename.txt, filename-2.txt, filename-3.txt, and filename-4.txt already exist, I'm all ears. 6-10. Good eye. I think that can be refactored to repeat itself less. 11. I don't see a problem with this? 12. I don't see a problem with this either.

orf 10y ago
> Context matters: That's a CLI script. Ahh, my bad, it's still an odd way of doing this. And it's vulnerable to injection via the prompt parameter (not that it matters, but...). That pattern is repeated in a couple of places like the updater. > Because when Airship was started, everyone insisted on backwards compatibility for PHP 5 and I wanted to make use of strict typing. The master branch includes a static analyzer as part of continuous integration. Strict typing is great, but you don't have to write your own framework to benefit from it. Is PHP 5 not compatible with modern frameworks? > Have you seen what I've done to PHP frameworks over the years? > https://scott.arciszewski.me/open-source/ https://scott.arciszewski.me/open-source/ > https://paragonie.com/security/advisories https://paragonie.com/security/advisories > I wasn't in a hurry to pick up other peoples' technical debt. Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position. You aren't in a hurry to pick up others technical debt, but you rush ahead and create your own? All I'm saying is you put out a post saying you designed this from the ground up to be secure, but did you really? Is rolling your own ORM and homegrown framework secure? Says who? Yeah, you use modernish stuff like csp etc, but the code is still a typical PHP spaghetti of mixed concerns and hard-to-audit flows. 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. > That's simply a paranoia/convenience feature. If you've got a better way to automagically convert filename.txt into filename-5.txt if filename.txt, filename-2.txt, filename-3.txt, and filename-4.txt already exist, I'm all ears. It could be done in a single query, I'm on my phone so i cant write you an example right now. > 11. I don't see a problem with this? > 12. I don't see a problem with this either. 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. It's kind of code smell. Using a whitelist is good though.
- CiPHPerCoder 10y ago
  > 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

> Context matters: That's a CLI script. Ahh, my bad, it's still an odd way of doing this. And it's vulnerable to injection via the prompt parameter (not that it matters, but...). That pattern is repeated in a couple of places like the updater. > Because when Airship was started, everyone insisted on backwards compatibility for PHP 5 and I wanted to make use of strict typing. The master branch includes a static analyzer as part of continuous integration. Strict typing is great, but you don't have to write your own framework to benefit from it. Is PHP 5 not compatible with modern frameworks? > Have you seen what I've done to PHP frameworks over the years? > https://scott.arciszewski.me/open-source/ https://scott.arciszewski.me/open-source/ > https://paragonie.com/security/advisories https://paragonie.com/security/advisories > I wasn't in a hurry to pick up other peoples' technical debt. Indeed there are some vulnerabilities found in PHP libraries in those pages, but hardly enough to warrant your position. You aren't in a hurry to pick up others technical debt, but you rush ahead and create your own? All I'm saying is you put out a post saying you designed this from the ground up to be secure, but did you really? Is rolling your own ORM and homegrown framework secure? Says who? Yeah, you use modernish stuff like csp etc, but the code is still a typical PHP spaghetti of mixed concerns and hard-to-audit flows. 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. > That's simply a paranoia/convenience feature. If you've got a better way to automagically convert filename.txt into filename-5.txt if filename.txt, filename-2.txt, filename-3.txt, and filename-4.txt already exist, I'm all ears. It could be done in a single query, I'm on my phone so i cant write you an example right now. > 11. I don't see a problem with this? > 12. I don't see a problem with this either. 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. It's kind of code smell. Using a whitelist is good though.

CiPHPerCoder 10y ago
> 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