"return flase" causes PHP website to be hacked
Moderator: Moderators
"return flase" causes PHP website to be hacked
I was just reading the article here: https://medium.com/@DanielC7/remote-cod ... f8773df767
In the programming language PHP, "return flase;" ends up returning the literal string "flase", which is interpreted as the boolean value 'true'. This is just insane.
In the programming language PHP, "return flase;" ends up returning the literal string "flase", which is interpreted as the boolean value 'true'. This is just insane.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: "return flase" causes PHP website to be hacked
Dynamically typed languages are great, aren't they? *eyeroll*
Also, that code is either very old or the author is brain-damaged and doesn't know about PHP's type-strict comparison operators like === and !==, which PHP calls "strict comparisons". JavaScript has the same abomination. Enjoy these PHP truth charts that help indicate what a lot of present-day webcrap PLs do.
Makes you wonder if what we have today is truly better than what we had 30 years ago.
Also, that code is either very old or the author is brain-damaged and doesn't know about PHP's type-strict comparison operators like === and !==, which PHP calls "strict comparisons". JavaScript has the same abomination. Enjoy these PHP truth charts that help indicate what a lot of present-day webcrap PLs do.
Makes you wonder if what we have today is truly better than what we had 30 years ago.
Re: "return flase" causes PHP website to be hacked
"Those are flase accusation!" 

- ISSOtm
- Posts: 46
- Joined: Fri Jan 04, 2019 5:31 pm
- Location: France, right of a pile of consoles
- Contact:
Re: "return flase" causes PHP website to be hacked
Dynamically-typed languages are OK imo, the wrong part about PHP and JS is trying to make shortcuts (such as 0 == "0"), because it only tends to create breakage and unreadable code and people are going to move away from those.
Here's a thing that makes me like JS way less than I'd like to:
Throw more errors, dammit! (That's also a thing with PHP - errors being mostly silent, and logging being done to an obscure file somewhere. Sure, you can change the config to disable that, but it should be default behavior.)
Here's a thing that makes me like JS way less than I'd like to:
Code: Select all
>>> [] + []
""
>>> [] + {}
"[object Object]"
>>> {} + []
0
>>> {} + {}
NaN
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
https://github.com/ISSOtm
ASMu is laifu <3
Re: "return flase" causes PHP website to be hacked
In PHP 7, this was changed. It sends a lot more errors as exceptions rather than as PHP 5's semi-silent warnings. For those that remain, you can add the ErrorException boilerplate to your program:ISSOtm wrote:(That's also a thing with PHP - errors being mostly silent, and logging being done to an obscure file somewhere. Sure, you can change the config to disable that, but it should be default behavior.)
Code: Select all
function exception_error_handler($severity, $message, $file, $line) {
// If this error code is included in error_reporting, throw
if (error_reporting() & $severity) {
throw new ErrorException($message, 0, $severity, $file, $line);
}
}
set_error_handler("exception_error_handler");
Re: "return flase" causes PHP website to be hacked
When talking about Javascript like that, you need the link to the talk from DestroyAllSoftware:
https://www.destroyallsoftware.com/talks/wat
https://www.destroyallsoftware.com/talks/wat
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: "return flase" causes PHP website to be hacked
I was watching a presentation on Youtube yesterday in which someone actually rejected the complaint "it's buggy" with "it's software". The whole room laughed. 
Computers don't make mistakes. Programmers make mistakes. Every programming language that spots less mistakes than its predecessors is a step backwards.

Computers don't make mistakes. Programmers make mistakes. Every programming language that spots less mistakes than its predecessors is a step backwards.
Re: "return flase" causes PHP website to be hacked
I dunno.
With the typical 32 GB of DRAM in PC's these days, there's probably a "mistake" (bit-flip) happening in a computer as often as once a week.
Does it usually matter? No. But I'm just wondering when's the time for everyone to start using ECC across the board.
My work laptop has already bluescreened twice due to an uncorrectable ECC error since last summer.
I also surmise that if a programming language has syntax that is commonly but silently screwed up, it becomes the fault of the language author and not the programmer.
With the typical 32 GB of DRAM in PC's these days, there's probably a "mistake" (bit-flip) happening in a computer as often as once a week.
Does it usually matter? No. But I'm just wondering when's the time for everyone to start using ECC across the board.
My work laptop has already bluescreened twice due to an uncorrectable ECC error since last summer.
I also surmise that if a programming language has syntax that is commonly but silently screwed up, it becomes the fault of the language author and not the programmer.
Re: "return flase" causes PHP website to be hacked
The issue of ECC is so off-topic it's not even funny. :-)
I agree wholeheartedly though -- ECC (even if just single-bit correcting) is something that should be commonplace these days, but it isn't, and that's because it's all about cost-savings (compounded by gamers who are like "UHHH UHHH UHHH I NEED ANOTHER 4 FPS!" -- companies lover gamers cuz they're cash cows). With CPU manufacturers having moved MCHs on-die (read: northbridge now lives in the physical CPU itself), no longer can motherboard manufacturers offer stuff like boards that use desktop CPUs but with ECC-supporting northbridges. I used the latter heavily throughout Parodius' existence, as I refused to pay the exorbitant cost for Xeons; you're now forced to buy Xeon ("server-class") CPUs if you want ECC, even though they really don't offer much more in the ways of performance (there's lots of marketing blahblah trying to say otherwise). This applies to Intel exclusively BTW; AMD so far has yet to pull something like this, but I imagine it's only a matter of time before their marketing goons decide to milk it. Oh, and to clarify: AFAIK, on-die L1/L2/L3 cache use ECC, even on desktop CPUs.
On the flip side, one of the complications ECC brings with it are lots of fun MCEs that users can't decode or comprehend. "Is it external DRAM that's causing the MCE? Is it L2 cache? It just says 'memory'! How do I know which DIMM?" Most of the time users get it wrong. The only way to figure out what the cause is, is to replace one part at a time. These MCEs literally vary per every CPU model, so quite often when a new CPU or chipset comes out, an OS update is required to support properly parsing/handling new MCEs (some of which are generated under normal operation, believe it or not). OSes like FreeBSD have extremely neglected MCE handling code, so newer CPU or chipsets often spew stuff that's possibly harmless -- but you can't be sure without decoding it, which is difficult.
Back on topic: I could talk for days about this typing thing, but honestly I have colleagues/peers who grasp it (esp. the importance of strict types) way better than I do. But it doesn't matter, because the "webshit-o-sphere" with its ever-growing number of horrible cargo-cult PLs and loudly-vocal advocates will continue to deny the importance of strong/strict typing. What saddens me greatly is when I see people who are old enough to know better, guys like Rob Pike, making stuff that caters to that horrible mentality. I think it all boils down to people not wanting to have to type things like string_of_bool or int_of_string (to use native OCaml functions as an example), as well as explictly cast (at declaration time) what type something is. They believe, truly, that the PL should at run-time figure these things out magically and be able to know what they intended. When it goes awry, like in the case of the above example, I can only shake my head.
I agree wholeheartedly though -- ECC (even if just single-bit correcting) is something that should be commonplace these days, but it isn't, and that's because it's all about cost-savings (compounded by gamers who are like "UHHH UHHH UHHH I NEED ANOTHER 4 FPS!" -- companies lover gamers cuz they're cash cows). With CPU manufacturers having moved MCHs on-die (read: northbridge now lives in the physical CPU itself), no longer can motherboard manufacturers offer stuff like boards that use desktop CPUs but with ECC-supporting northbridges. I used the latter heavily throughout Parodius' existence, as I refused to pay the exorbitant cost for Xeons; you're now forced to buy Xeon ("server-class") CPUs if you want ECC, even though they really don't offer much more in the ways of performance (there's lots of marketing blahblah trying to say otherwise). This applies to Intel exclusively BTW; AMD so far has yet to pull something like this, but I imagine it's only a matter of time before their marketing goons decide to milk it. Oh, and to clarify: AFAIK, on-die L1/L2/L3 cache use ECC, even on desktop CPUs.
On the flip side, one of the complications ECC brings with it are lots of fun MCEs that users can't decode or comprehend. "Is it external DRAM that's causing the MCE? Is it L2 cache? It just says 'memory'! How do I know which DIMM?" Most of the time users get it wrong. The only way to figure out what the cause is, is to replace one part at a time. These MCEs literally vary per every CPU model, so quite often when a new CPU or chipset comes out, an OS update is required to support properly parsing/handling new MCEs (some of which are generated under normal operation, believe it or not). OSes like FreeBSD have extremely neglected MCE handling code, so newer CPU or chipsets often spew stuff that's possibly harmless -- but you can't be sure without decoding it, which is difficult.
Back on topic: I could talk for days about this typing thing, but honestly I have colleagues/peers who grasp it (esp. the importance of strict types) way better than I do. But it doesn't matter, because the "webshit-o-sphere" with its ever-growing number of horrible cargo-cult PLs and loudly-vocal advocates will continue to deny the importance of strong/strict typing. What saddens me greatly is when I see people who are old enough to know better, guys like Rob Pike, making stuff that caters to that horrible mentality. I think it all boils down to people not wanting to have to type things like string_of_bool or int_of_string (to use native OCaml functions as an example), as well as explictly cast (at declaration time) what type something is. They believe, truly, that the PL should at run-time figure these things out magically and be able to know what they intended. When it goes awry, like in the case of the above example, I can only shake my head.
Re: "return flase" causes PHP website to be hacked
Yeah, but one could also blame the programmers and companies that are using that language.whicker wrote:if a programming language has syntax that is commonly but silently screwed up, it becomes the fault of the language author and not the programmer.
Re: "return flase" causes PHP website to be hacked
Or in the specific case of PHP, particularly in the pre-5.4 era, blame the shared web hosting providers that gave a deep discount on the monthly or annual rate for using PHP compared to using Perl, Python, or any other language.
- ISSOtm
- Posts: 46
- Joined: Fri Jan 04, 2019 5:31 pm
- Location: France, right of a pile of consoles
- Contact:
Re: "return flase" causes PHP website to be hacked
It's hard to blame someone for using a language when there's no alternative. PHP is commonly already set up on a lot of hosting provides, so it's basically a must for people who don't have the technical knowledge to set up something like Jekyll, Hugo, Pelican or what have you themselves. Also, for example, scripting in web pages? JS!nocash wrote:Yeah, but one could also blame the programmers and companies that are using that language.whicker wrote:if a programming language has syntax that is commonly but silently screwed up, it becomes the fault of the language author and not the programmer.
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
https://github.com/ISSOtm
ASMu is laifu <3
Re: "return flase" causes PHP website to be hacked
Some purists on forums I frequent might say:ISSOtm wrote:Also, for example, scripting in web pages? JS!
"Better yet, don't use client-side scripting in web pages in the first place. Instead, use semantic HTML5 for the document, CSS for its presentation, CSS for expand and collapse, link navigation or form submission for interaction, HTML5 input attributes for validation before submission, server-side scripting for authoritative validation, and downloadable native applications with published source code for those things that HTML, CSS, and server-side scripting can't handle."
But then these purists are also the sort of people who recommend playing a physical sport or a tabletop game instead of a video game in order to compensate for the failure of the free software community to devise a business model for funding production of video games as free software.
Re: "return flase" causes PHP website to be hacked
It's not the dynamic typing, it's the automatic, warning-less conversion from string "false" to boolean true which is the source of the error. Type conversion should always be explicit, not automatic. Statically typed C and C++ suck just as much in this regard : String "false" might be evaluated as it's pointer which is non-zero thus "true". However at least this will produce a compiler warning.Dynamically typed languages are great, aren't they? *eyeroll*
Re: "return flase" causes PHP website to be hacked
There's no separate compiler, and all warnings/errors go to a log file, and not to something immediately visible by the programmer.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!