61–70 of 70 posts
Nice interface, but it's a bit strange to me that it uses shell exec for every kind of measure. e.g. # uptime.php <?php echo (int) (shell_exec('cat /proc/uptime')/(60*60));
Earlier quoted context omitted.
> WRONG. Because you have to use mysql_REAL_escape_string. Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli. > The point is that I can't audit (and would rather not waste my time doing so) this PHP code. I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the C…
But the XSS issues have nothing to do with the language choice. Python, ruby and any other langauge do nothing by default to protect you against such things either. I agree this is a poor choice of code, and an attack vector, but the language used here is not to blame.
The biggest security issue that I've noticed with PHP is more cultural: Developers are far more likely to write ad-hoc pages with subtle security issues than use well-tested frameworks and libraries because it seems easier.
I would never expect to see Ruby or Python code that generates a JSON array like this [0], but I'm not at all surprised when I see it in PHP. It's too easy and tempting to do the wrong thing.
[0]: https://github.com/afaqurk/linux-dash/blob/master/sh/users.p...
Still, the interface is really cool!
Earlier quoted context omitted.
But the XSS issues have nothing to do with the language choice. Python, ruby and any other langauge do nothing by default to protect you against such things either. I agree this is a poor choice of code, and an attack vector, but the language used here is not to blame.
I was responding to the parent's unwillingness to audit the code, not so much about technical issues with PHP. The biggest security issue that I've noticed with PHP is more cultural: Developers are far more likely to write ad-hoc pages with subtle security issues than use well-tested frameworks and libraries because it seems easier. I would never expect to see Ruby or Python code that generates a JSON array like this…
Earlier quoted context omitted.
Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…
> WRONG. Because you have to use mysql_REAL_escape_string. Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli. > The point is that I can't audit (and would rather not waste my time doing so) this PHP code. I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the C…
I agree, you should be using prepared statements, but using mysql_real_escape_string is not inherently wrong. This is a theme with PHP: if you want to do thing X, you have three different ways, each with different naming conventions, different side effects, different APIs, and at least one of them will subtly lead you to shoot yourself in the foot.
Of course an experienced programmer can work around this issues, but I think this is not very relevant to the discussion.
>There's some XSS issues with the JSON output, the Content-Type header isn't set to 'application/json' so PHP decides to set it to 'text/html'. Now anyone that controls ipecho.net[0] or can execute commands as any user on the server[1] can XSS users of the panel.
This is the kind of thing I expected to happen. It's funny how PHP is supposed to be accessible to everyone but can only be used correctly by experts.
I know PHP started as a templating engine, and it isn't a very good one at that: all of the templating engines I have used escape HTML by default. PHP is the only one that doesn't. I don't know, draw your own conclusions.
Earlier quoted context omitted.
Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…
What you are talking about are core language decisions. Good developers have known how to work around register globals for years now, and it's not been a problem in any modern web app I've touched for the last 8 years (off the top of my head). The language being used here has absolutely nothing to do with the output. You could substitute the PHP shell_exec calls for something similar in python, ruby or any other lang…
A good programming language lets a good developer to focus on writing code, not wrestling with bullshit decisions. YES, good programmers can write good and safe PHP code. But in the same way, bad or unexperienced programmers WILL and DO write awful code. The most recent example is OP's code. I've clicked on a few links that people replying to me have posted, and honestly, I'm glad I didn't spend any more time looking at it.
>The language being used here has absolutely nothing to do with the output. You could substitute the PHP shell_exec calls for something similar in python, ruby or any other language.
Like I said in previous comments, substituting PHP by Python or Ruby wouldn't improve the situation very much; I agree with that. The correct way to do it is to separate the data collection from the web interface. I think that should be common sense, and I fear that PHP is eroding that by making it very easy to do it "the lazy way" (fuck it, we'll use shell_exec on the web, what's the worst that could happen right?).
However, multi-server support would make this even more amazing.
The interface looks very nice but no thanks, I'm not going to install PHP on my servers to have it. I'd totally set it up if it weren't for PHP. The risk is just too great to ignore.
Some server side code is required to obtain the data. Out of curiosity, what would it have to be written in to make you feel safe?
Back-end: a daemon process that runs at an interval, collecting data and writing it to a data store.
Front-end: connects to the data store, processes statistics, and formats for display.
By constructing your application in this way, the data store acts as a firewall between the system calls required to collect the data and the interface used to view the data. Your daemon application needn't listen on any network ports if it is running locally.
Your web application still needs to be secure, but you don't have the additional risk of many calls to system/shell exec commands that are a honey pot for exploitation.