6 ms·

Having done some work on static analysis of PHP applications, I agree that the language is very poorly designed. It seems the designers add any feature that th

Having done some work on static analysis of PHP applications, I agree that the language is very poorly designed. It seems the designers add any feature that they think will make it easier to write code, regardless of its effects on readability or security. It's an ongoing problem, too. One might have had some sympathy for an inexperienced language designer who pushed something out into the world because he thought it was cool, but then when people pointed out the problems with it, studied language design and learned to make better decisions. That's not happening with PHP; even some relatively recent design decisions are just mind-bogglingly bad. I am particularly frustrated by the choice, a few years ago, to remove the requirement that arguments being passed by reference be marked with an '&' at the call site (as well as on the function parameter receiving the reference). Since in general you don't know until runtime what function is called at a variable call site (e.g. '$f(...)'), you can't tell by looking at such a call which arguments, if any, are being passed by reference! But, all that said, I think you can write an unsafe library or framework or app in any language. In fact I recall a vulnerability in a widely-used Ruby library in which one of the API functions normally expected some kind of object, but if you passed it a string instead, it would call 'eval' on it for you and use the result. This "helpful" behavior was not documented. My point is that there's more to educating the masses about writing secure code than just telling them not to use PHP.

zmonx 9y ago
Thank you for this! Interestingly, the cases you mention cannot arise in Prolog, because Prolog terms are never evaluated implicitly. They are just terms, and you write predicates that reason over them. In pure Prolog, there is no way to pass something "by reference" either. If you are determined enough, you can definitely write an unsafe library or app also in Prolog, and security mistakes are also routinely found in Prolog implementations, just as in PHP or Java implementations. The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs, due to the more direct, symbolic way you reason about data in Prolog, and additional mechanisms such as the mentioned quasiquotations which allow safe embeddings.
- nickpsecurity 9y ago
  " The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs" This is true. While we're at it, I think it's worth bringing up that the most powerful use of Prolog is embedding it in a LISP that is "batteries included." One like Racket. That way, one can use a safe, easy-to-analyze, functional style for most of the application, one or more DSL's for the templating (esp HTML), and Prolog operating on LISP structures when Prolog is best thing to handle it with. Alternatively, Shen uses something like Prolog as its type system so you can hand-roll a custom, type system for each component which might include security properties. Far as good design, web, and security-oriented, the best I've seen is Opa language for doing that plus being productive. http://opalang.org/ http://opalang.org/ Too bad they moved the backend to Node. Probably to latch onto an ecosystem getting momentum which is a lesson from Worse is Better philosophy. Most IT tech that didn't disappeared into history at some point. I'd have preferred it be Go if one of the new, popular things given its fast, simpler, and safe enough. Hell, if libraries aren't a concern, they can even output safe subset of C with all the checks enabled like Pieter Hintjens did with iMatix DSL's.
  - ScottBurson 9y ago
    I thought Opa looked very interesting when I first heard about it, but I don't see much recent activity on the GitHub repo. Is it still alive?
    - nickpsecurity 9y ago
      I didn't even realize the last blog post as Sep 2013: http://blog.opalang.org/ http://blog.opalang.org/ Hell, it might be dead. I'll have to email them some time this week to find out what's up. Fortunately, it's open-source so others can pick up where they left off if they want. Or do a clean-slate work with similar capabilities.
    - nickpsecurity 9y ago
      Got word from a developer that the project is on hold. He claimed no residual vulnerabilities since it extracts to Node.js which is maintained. He said dome are using it in production. They still welcome contributors. Yeah, it seems dead for now.
nickpsecurity 9y ago
"I agree that the language is very poorly designed. It seems the designers add any feature that they think will make it easier to write code, regardless of its effects on readability or security. " That's exactly what they do. It's why it succeeded at original goal, got popular, and is currently a mess for folks who've seen better-designed things. Further, I'll add that it doesn't appear to have been designed at all so much as a hacked together pile of features that were useful to the author at the time then extended over time. Just like C was when I researched it. It's even worse than the two of you think. It gets worse during the times they tried to "design" some aspect of it. The hashing of names was worth bookmarking: http://news.php.net/php.internals/70691 http://news.php.net/php.internals/70691 re static analysis I had one project on that saved back in the PHP 5 days. What's the current state-of-the-art in static analysis tools for PHP in both commercial and FOSS? And does that sub-field have any that can prove the absence of common, severe errors like Astree Analyzer does for C and SPARK for Ada? The PHP equivalent of severe errors anyway. Especially anything allowing code injection. "widely-used Ruby library in which one of the API functions normally expected some kind of object, but if you passed it a string instead, it would call 'eval' on it for you and use the result. This "helpful" behavior was not documented." When eval will happen or whether risky constructs like that are used at all is one of the things that would be on my list of requirements for static analysis tools. I should be able to spot those kinds of issues in one pass before using a library. In theory anyway. "My point is that there's more to educating the masses about writing secure code than just telling them not to use PHP." It takes some books and practice. Also, you can get pretty far telling them to use Airship CMS since it was designed for security. I don't know anything else about it, though, since I don't do web apps or PHP.
- ScottBurson 9y ago
  > What's the current state-of-the-art in static analysis tools for PHP in both commercial and FOSS? I don't know, sorry. I pay very little attention to PHP. > And does that sub-field have any that can prove the absence of common, severe errors like Astree Analyzer does for C and SPARK for Ada? Not to my knowledge.

zmonx 9y ago

Thank you for this! Interestingly, the cases you mention cannot arise in Prolog, because Prolog terms are never evaluated implicitly. They are just terms, and you write predicates that reason over them. In pure Prolog, there is no way to pass something "by reference" either. If you are determined enough, you can definitely write an unsafe library or app also in Prolog, and security mistakes are also routinely found in Prolog implementations, just as in PHP or Java implementations. The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs, due to the more direct, symbolic way you reason about data in Prolog, and additional mechanisms such as the mentioned quasiquotations which allow safe embeddings.

nickpsecurity 9y ago
" The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs" This is true. While we're at it, I think it's worth bringing up that the most powerful use of Prolog is embedding it in a LISP that is "batteries included." One like Racket. That way, one can use a safe, easy-to-analyze, functional style for most of the application, one or more DSL's for the templating (esp HTML), and Prolog operating on LISP structures when Prolog is best thing to handle it with. Alternatively, Shen uses something like Prolog as its type system so you can hand-roll a custom, type system for each component which might include security properties. Far as good design, web, and security-oriented, the best I've seen is Opa language for doing that plus being productive. http://opalang.org/ http://opalang.org/ Too bad they moved the backend to Node. Probably to latch onto an ecosystem getting momentum which is a lesson from Worse is Better philosophy. Most IT tech that didn't disappeared into history at some point. I'd have preferred it be Go if one of the new, popular things given its fast, simpler, and safe enough. Hell, if libraries aren't a concern, they can even output safe subset of C with all the checks enabled like Pieter Hintjens did with iMatix DSL's.
- ScottBurson 9y ago
  I thought Opa looked very interesting when I first heard about it, but I don't see much recent activity on the GitHub repo. Is it still alive?
  - nickpsecurity 9y ago
    I didn't even realize the last blog post as Sep 2013: http://blog.opalang.org/ http://blog.opalang.org/ Hell, it might be dead. I'll have to email them some time this week to find out what's up. Fortunately, it's open-source so others can pick up where they left off if they want. Or do a clean-slate work with similar capabilities.
  - nickpsecurity 9y ago
    Got word from a developer that the project is on hold. He claimed no residual vulnerabilities since it extracts to Node.js which is maintained. He said dome are using it in production. They still welcome contributors. Yeah, it seems dead for now.

nickpsecurity 9y ago

"I agree that the language is very poorly designed. It seems the designers add any feature that they think will make it easier to write code, regardless of its effects on readability or security. " That's exactly what they do. It's why it succeeded at original goal, got popular, and is currently a mess for folks who've seen better-designed things. Further, I'll add that it doesn't appear to have been designed at all so much as a hacked together pile of features that were useful to the author at the time then extended over time. Just like C was when I researched it. It's even worse than the two of you think. It gets worse during the times they tried to "design" some aspect of it. The hashing of names was worth bookmarking: http://news.php.net/php.internals/70691 http://news.php.net/php.internals/70691 re static analysis I had one project on that saved back in the PHP 5 days. What's the current state-of-the-art in static analysis tools for PHP in both commercial and FOSS? And does that sub-field have any that can prove the absence of common, severe errors like Astree Analyzer does for C and SPARK for Ada? The PHP equivalent of severe errors anyway. Especially anything allowing code injection. "widely-used Ruby library in which one of the API functions normally expected some kind of object, but if you passed it a string instead, it would call 'eval' on it for you and use the result. This "helpful" behavior was not documented." When eval will happen or whether risky constructs like that are used at all is one of the things that would be on my list of requirements for static analysis tools. I should be able to spot those kinds of issues in one pass before using a library. In theory anyway. "My point is that there's more to educating the masses about writing secure code than just telling them not to use PHP." It takes some books and practice. Also, you can get pretty far telling them to use Airship CMS since it was designed for security. I don't know anything else about it, though, since I don't do web apps or PHP.

ScottBurson 9y ago
> What's the current state-of-the-art in static analysis tools for PHP in both commercial and FOSS? I don't know, sorry. I pay very little attention to PHP. > And does that sub-field have any that can prove the absence of common, severe errors like Astree Analyzer does for C and SPARK for Ada? Not to my knowledge.