Injection Rejection (2006)
thedailywtf.com
Injection Rejection (2006)
1–10 of 19 posts
Re: Injection Rejection (2006)
#2This 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).
Re: Injection Rejection (2006)
#3Ah yes, it would seem little "Bobby Tables"[0] strikes again.
Re: Injection Rejection (2006)
#4At least they didn't offer to "correct" the offending text, turning it into a clbuttic bug.
Re: Injection Rejection (2006)
#5This 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 posi…
Somehow, escaping is beyond the comprehension of many people, yet I find it a simple and straightforward concept.
Re: Injection Rejection (2006)
#6This 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 posi…
Somehow, escaping is beyond the comprehension of many people, yet I find it a simple and straightforward concept.
Doing your own escaping is digital whack-a-mole. Let the experts who wrote the prepared statement interface handle it. The knowledge of a team and/or years of experience compressed into an interface that’s trivial to use.
Re: Injection Rejection (2006)
#7(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.
Re: Injection Rejection (2006)
#8Earlier quoted context omitted.
Somehow, escaping is beyond the comprehension of many people, yet I find it a simple and straightforward concept.
Doing your own escaping is digital whack-a-mole. Let the experts who wrote the prepared statement interface handle it. The knowledge of a team and/or years of experience compressed into an interface that’s trivial to use.
Parameterized statements don't actually abstract over escaping; they entirely obviate the need for it, by moving the untrusted data out of band.
Re: Injection Rejection (2006)
#9This 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 posi…
Somehow, escaping is beyond the comprehension of many people, yet I find it a simple and straightforward concept.
Escaping isn't always straightforward. Or rather, it is in simple languages or in languages that are designed to make it straightforward, like HTML, but in SQL it's surprisingly tricky, and subtle bugs in escaping routines are an occasional source of vulnerabilities. E.g., https://stackoverflow.com/a/12118602. This is why modern best security practice is to use parameterized statements instead.
Re: Injection Rejection (2006)
#10There 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.