Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security.
However, I'd rather not have a program execute a shell command when it receives a PHP request. Written in PHP or not. It's just wrong.
Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner.
>Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security.
Yes like Ruby and Active Records SQL injection debacle where Github was pwned and the developers din't seem to care?
I can't argue that PHP is better than other languages, but holding it to f*ck ups from over 5+ years ago, most of which have been fixed, is a low.
If you can find something vulnerable within this open source coded, then I happy to hear you out and would prefer that than your unregistered paranoia.
Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind.
>Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner.
Well, the vast majority of people would not consult the documentation for register_globals when it was the default. Sure, it's deprecated now, but... what the hell, who thought it was a good idea in the first place? Oh yeah, the same people who built PHP as a hack designed for a very specific purpose that grew out of proportion too quickly.
> Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner.
The Active Record stuff was a vulnerability in a LIBRARY. The register_globals stuff was a vulnerability in THE CORE LANGUAGE. Those are two very, very different things. Also, it's a bug rather than a design decision.
>Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind.
I encourage as many people as I can to contribute to open source. I also consider myself an experienced software developer, so I feel like it is my responsibility to educate people and prevent them from shooting themselves in the foot. PHP makes it very easy to do this.
Genuinely curious, how would you implement something like a cron web interface? Certainly it would require you to have a program execute a shell command upon some HTTP request. Granted this project focuses on displaying data but there are many, many serious web libraries that execute commands on the server depending on what the person is trying to do.
Think of all the libraries that are just abstraction layers to imagemagick or ffmpeg. Do you really think there no legitimite use case for executing commands via some web program?
The libraries that are abstraction layers to imagemagick or ffmpeg are, in fact, that: libraries. There is a very critical distinction between a library/module and a command-line wrapper. Your programming language probably has a module that exposes the imagemagick API. However, this doesn't mean that it uses shell commands for anything; it just exposes the functions to your programming language of choice.
I wrote the backend and processing system for a website[1] that deals with converting files, and incidentally uses imagemagick and ffmpeg, amongst other things. You'll notice that everything that that calls external programs is handled very carefully. One example of this careful handling is that all of the commands that can be executed are in a single file[2], and very easy to think about. Compare that to OP's software, where there are multiple commands scattered across different files. Also, although this is a bit harder to see superficially, but no HTTP request triggers any external program call directly. This is by design.
Coming back to your question,
>Genuinely curious, how would you implement something like a cron web interface? Certainly it would require you to have a program execute a shell command upon some HTTP request.
You set up a cron job[3] that gathers the data and stores it somewhere like a database, or even a file. The idea here is that you have a strictly one-way flow of data, which prevents a large number of attacks (register_globals is the easiest)
[3] Or a daemon, whatever; the point is that the website can only communicate with it through a specific channel with a very small attack surface (i.e a UNIX socket where the messages are very limited), whereas doing it on the script that generates the website exposes a very large attack surface
However, I'd rather not have a program execute a shell command when it receives a PHP request. Written in PHP or not. It's just wrong.
[1] http://www.php.net/manual/en/security.globals.php
[2] https://bugs.php.net/bug.php?id=47796