8 comments

[ 2.2 ms ] story [ 35.5 ms ] thread
This is a common example of not fixing from root cause and try to fix from "outside valiation" that has bad side effects.

The correct way of fixing SQL injection is to use prepared statement and parameters.

Other examples: Windows allows software to do bad things, having no proper permission control (to maintain compatibility). Antimalwares scan applications by matching patterns of virus code, but has many false positives and false negatives. This causes many troubles (kill innocent software, scanning cost performance, etc.) because it does not fix from root case (proper permission management).

At least they didn't offer to "correct" the offending text, turning it into a clbuttic bug.
(This has nothing to do with the post, but the title is so similar that I had to include it. Written a few days after seeing "Inception".

Inception Rejection

(Why the dreams-within-dreams in the movie "Inception" could never happen as shown even if the technology worked as described.)

((Though this would have been a lot easier to do as an essay, the poeming was challenging and fun.))

The basis of "Inception", although it may leave you confused, is that in the brain while waking only five percent is used.

To process things in daily life this certainly has been plenty. That mental surplus means our dreams go faster by a factor of twenty.

The magic device that drives the film (the idea's at least sixty years old) allows dreams not only to be observed but changed as they they unfold.

When this device is dreamt of, unlikely as it seems, if used like in the real world, the result is dreams within dreams.

Inception's filled with dreams in dreams, each twenty times faster than before. Unfortunately, here's the problem this movie does ignore:

Level one's dream factor is twenty; four hundred at level two. Level three's factor's eight thousand - two hours there is less than a second for you.

In the first dream at twenty times the brain goes at full speed; there's no excess capacity that the next dream down would need.

A dream in a dream can only be dreamt by the real brain at the top. The faster brain that's in the dream is no more than a prop.

To go faster by four hundred, the dream at level two would need a brain twenty times as fast as the one you carry with you.

So the speed of the dreams that are further down could be no faster than the dream that's first. A quite ingenious plot device here has its bubble burst.

There is a Russian proverb (hi Mr Reagan!) which states that a cheapskate pays twofold. I suspect that the cost of this "overseas" project could easily cost 20x the low, low sticker price.
We had a project in an old but perfectly serviceable framework. The application was working fine, we just wanted some basic regular maintenance, and corporate decided we should outsource it as we didn't have a lot of time between us.

We gave the external team explicit instructions that they should continue to use the existing framework, as they'd asked to rewrite it in a newer framework. Just add simple features and maintain what's there.

The project comes back very troubled, barely working and just feels janky. Things that have worked fine for a decade are broken. None of us look at the code, as that was the goal, but instead we just keep sending back revisions. Every time they fix something, something else breaks.

Well after multiple rounds of back and forth failing to get a very basic form working correctly, we decide to dig in and fix it ourselves. We discover that instead of using the existing framework, they'd written a giant janky adapter layer translating their framework of choice to satisfy the existing framework. It completely undermined the point of keeping the existing framework which was to keep changes to a minimum. We wanted maintenance, not a rewrite.

The whole codebase was a confused mess no person in their right mind would want to maintain. I have never been so frustrated in my life. After we confronted them about it, and they adamantly defended it, we ended up firing them.

It's more common than you'd think, even today. A lot of sites I recently explored leave SQL injections as is (you can see the typical MySQL errors) and rely on some kind of "security plugin" provided by a third-party for their framework of choice which checks if a URL contains something which resembles an SQL injection attempt (such as "UNION SELECT" in query params).
All your injections are belong to us.