Comment On EvalToInteger, 'gumdrops', and More

"I recently found this while going over some code in a Util library used by my project," Ian writes, "clearly, this method makes sure the job gets done." [expand full text]
« PrevPage 1 | Page 2Next »

Re: EvalToInteger, 'gumdrops', and More

2012-04-09 18:15 • by csmiller (unregistered)
378759 in reply to 378750
That's a goat, it's cloven footed. Asses are equids, and have only one hoof per leg.

Re: EvalToInteger, 'gumdrops', and More

2012-04-09 18:47 • by Jaime
378760 in reply to 378707
SCSimmons:
string sql = "exec spRequestInitechData '"
+ txtData.Text.ToString().Replace("'", "''") + "'";

Sometimes, I can't imagine the thought processes that lead to the WTF. I think it may be scarier when I can.

"We should escape the apostrophes when we build the SQL command, to prevent injection attacks."
"Actually, I've heard that the accepted standard is to use stored procedures."
"Oh. Hey, I've got an idea. Let's do both! Belt and suspenders, right?"
"Brillant!"
It's not belt and suspenders. Stored procedures encapsulate data access logic and proper parameter handling prevents injection. Anybody who thinks that poorly escaped calls to stored procedures will prevent injection should be fired immediately.

Re: EvalToInteger, 'gumdrops', and More

2012-04-09 20:39 • by Deanna (unregistered)
378761 in reply to 378755
geoffrey, MCP, PMP:

EvalToString obviously has to do something besides pass through the parameter passed in as a return value. Otherwise, why even have it there?


The same applies to most of the code SODs posted !

Re: EvalToInteger, 'gumdrops', and More

2012-04-09 22:16 • by Prakash (unregistered)
VeryHidden is used very less

Re: EvalToInteger, 'gumdrops', and More

2012-04-09 22:42 • by da Doctah
378767 in reply to 378759
csmiller:
That's a goat, it's cloven footed. Asses are equids, and have only one hoof per leg.

Also, asses hog the covers in bed. Goats are content to sleep across the foot of the bed, like dogs.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 00:02 • by SCSimmons
378768 in reply to 378760
Jaime:
SCSimmons:
string sql = "exec spRequestInitechData '"
+ txtData.Text.ToString().Replace("'", "''") + "'";

Sometimes, I can't imagine the thought processes that lead to the WTF. I think it may be scarier when I can.

"We should escape the apostrophes when we build the SQL command, to prevent injection attacks."
"Actually, I've heard that the accepted standard is to use stored procedures."
"Oh. Hey, I've got an idea. Let's do both! Belt and suspenders, right?"
"Brillant!"
It's not belt and suspenders. Stored procedures encapsulate data access logic and proper parameter handling prevents injection. Anybody who thinks that poorly escaped calls to stored procedures will prevent injection should be fired immediately.

Apparently, I forgot my BBCode [sarcasm] tags again.

Yes, I'm aware that the hypothetical exchange above resulting in the WTF code snippet is two individuals who have heard some buzzwords but don't actually understand what they're doing, managing to create something even more dysfunctional than what either of them would have created separately. To me, the amusing bit is that either would have created something that might have worked in the normal case, but failed when confronted with a malicious user. But by working together, they managed to create something that fails in cases of both malicious and normal users.

We don't see the code for the stored procedure, but I'll bet dollars to donuts that if it does something like a last name search, it will fail when the user enters O'Connell, once the EXEC command has been ruthlessly mangled by this abysmal front-end coding. Whether it's still vulnerable to injection attacks depends a lot on how competent the person who coded the stored proc was; hopefully this person was in no way related to the front-end coders.

The really sad part is how easy it is to code this correctly ...

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 02:40 • by Dave (unregistered)
378770 in reply to 378728
Coyne:
I think the visibility enumeration needs a few more enumerations. These come to mind: Sort of Hidden, Cleverly Hidden, Poorly Hidden, Extra Hidden, Forever Hidden, Optimally Hidden, Resolutely Hidden, Nervously Hidden, Unbelievably Hidden.


You forgot the most obvious one, FileNotFound.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 04:49 • by L. (unregistered)
378771 in reply to 378715
Programming 101:
if (!file_exists($dir) || !is_dir($dir))
if (!file_exists('test') || !is_dir('test'))
if (!TRUE || !FALSE)
if (FALSE || TRUE)
if (TRUE)

So if 'test' exists and is not a dir, a dir named 'test' will be created?


No . a dir will be created unless both dir and file exist w/ the name. and there will be an error

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 05:00 • by L. (unregistered)
Oh and by the way, anyone want to see my private carrot ?

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 05:09 • by Dave (unregistered)
378774 in reply to 378760
Jaime:
SCSimmons:
string sql = "exec spRequestInitechData '"
+ txtData.Text.ToString().Replace("'", "''") + "'";

Sometimes, I can't imagine the thought processes that lead to the WTF. I think it may be scarier when I can.

"We should escape the apostrophes when we build the SQL command, to prevent injection attacks."
"Actually, I've heard that the accepted standard is to use stored procedures."
"Oh. Hey, I've got an idea. Let's do both! Belt and suspenders, right?"
"Brillant!"
It's not belt and suspenders. Stored procedures encapsulate data access logic and proper parameter handling prevents injection. Anybody who thinks that poorly escaped calls to stored procedures will prevent injection should be fired immediately.


So...you're saying that some of the code included as part of a Daily WTF post isn't actually very good code?

Have the site owners been informed?

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 05:48 • by sagaciter (unregistered)
lol omigosh frist!!11!!

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 06:51 • by java.lang.Chris;
378777 in reply to 378728
Coyne:
I think the visibility enumeration needs a few more enumerations. These come to mind: Sort of Hidden, Cleverly Hidden, Poorly Hidden, Extra Hidden, Forever Hidden, Optimally Hidden, Resolutely Hidden, Nervously Hidden, Unbelievably Hidden.


You've missed the ultimate form of invisibility for a document - SavedToSharepoint

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 06:59 • by mmx (unregistered)
378778 in reply to 378758
>> Maybe so, but s.ToString() is redundant, and what's left is simple enough that you might want to compact it into one line:


s.ToString() is surely redundant, might also be a remnant of some refactoring or copy/paste, but is still very minor, not a WTF for sure unless that specific developer wrote that all the time.

I'm against compacting that into one line, which gains nothing and complicates debugging. We can debate that, of course, but I wouldn't call WTF on that code at all.


I also imply that EvalToString does some kind of "EVALUATION" of the statement argument. Like you can pass, say "=A1+B2" or "=$sdjfhskdfh" or whatever valid expression in whatever sublanguage it is, and it returns a value of some kind, otherwise it would be named "ConvertToString" probably.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 08:08 • by Qvasi (unregistered)
378779 in reply to 378771
L.:
Programming 101:
if (!file_exists($dir) || !is_dir($dir))
if (!file_exists('test') || !is_dir('test'))
if (!TRUE || !FALSE)
if (FALSE || TRUE)
if (TRUE)

So if 'test' exists and is not a dir, a dir named 'test' will be created?


No . a dir will be created unless both dir and file exist w/ the name. and there will be an error


Assuming this is php, file_exists will return true if either a file or directory exists; thus is_dir() == true implies file_exists() == true.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 08:41 • by Nagesh (unregistered)
378781 in reply to 378754
In 1986, India was being given 7 Polaroid camera from British govrenment. Most of the fotos are being lost. :(

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 09:18 • by oheso
378789 in reply to 378735
AB:
Hey, as a developer I may be terrible and devoid of any structure, but I resent being compared to that code.


Thank you.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 09:18 • by oheso
378790 in reply to 378739
Jay:
I don't see a WTF here at all. They have some function that does we know not what to a string, and gets a result that is another string. In at least some cases, this result is, in fact, parsable as an integer, so they have a second function that calls the first, gets the result, and then parses it to an integer. This seems like plain good coding to me. What would be preferable, to make another function identical to EvalToString except that it returns an int? Duplicating who knows how much code?


Geoffrey, you used the wrong log-in today.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 09:28 • by oheso
While you're all stumbling over yourselves to argue that evaltostring may or may not be a WTF, everyone seems content that there's an entire subroutine which is nothing more than a wrapper for int.parse and doesn't even handle exceptions. int.tryparse, anyone?

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 09:47 • by ThingGuy McGuyThing
378798 in reply to 378791
oheso:
While you're all stumbling over yourselves to argue that evaltostring may or may not be a WTF, everyone seems content that there's an entire subroutine which is nothing more than a wrapper for int.parse and doesn't even handle exceptions. int.tryparse, anyone?


Combined with your last post, I'm beginning to think that it is you who is Geoffrey.

* evalToString almost certainly evaluates its argument, and returns the result of that evaluation, not the original string

* evalToInteger isn't just a wrapper for int.parse, since it also performs the aforementioned evaluation

* Not everyone wants to handle exceptions immediately. Especially in a case like this where the appropriate response is probably to just let the FormatException bubble up to the caller.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 09:57 • by PiisAWheeL
378805 in reply to 378777
java.lang.Chris;:
Coyne:
I think the visibility enumeration needs a few more enumerations. These come to mind: Sort of Hidden, Cleverly Hidden, Poorly Hidden, Extra Hidden, Forever Hidden, Optimally Hidden, Resolutely Hidden, Nervously Hidden, Unbelievably Hidden.


You've missed the ultimate form of invisibility for a document - SavedToSharepoint
Now THAT is file_not_found.

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 10:45 • by Loren Pechtel
378817 in reply to 378731
FragFrog:
Loren Pechtel:
What's the problem with:

public static int EvalToInteger(string statement) {
string s = EvalToString(statement);
return int.Parse(s.ToString());
}

Note that the supplied string is named "statement"--I would assume EvalToString is doing some sort of evaluation, it doesn't just return what was passed in.

If there are any sort of naming conventions there, EvalToString will convert something to a string, just like EvalToInteger converts something to an integer. So now you have a string, which is evalled as a string, and then its string value is parsed.

That doesn't sound the least bit redundant to you?

Mind you, now I am assuming that a string variable's value is equal to it's .ToString value. Would not surprise me much if there is some weird null condition where that is not the case.


Given the variable name of "statement" I'm thinking that the original might contain some sort of markup rather than the final data. Say "Dear @Salutation @Firstname @Lastname".

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 11:15 • by Richard (unregistered)
378830 in reply to 378711
Why not replace with a blank string?

replace('/', '')

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 12:32 • by DaveK
378848 in reply to 378723
Fred:
VeryHidden Very Hidden. When the item is serialized out as xml, its value is "veryHidden".
Were it not for this line, the table could have been completely machine generated. But the three variations on "very hidden" suggest at least the possibility that some human drudge-drone was involved -- but not human enough to realize that an actual explanation might be useful.
Actually, if you follow the link to the original version on MSDN, you'll see that the poster has bogusly reformatted the table to make it look more stupid than it actually is. There are only two columns in the real one, "Member name" and "Description".

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 12:38 • by DaveK
378850 in reply to 378757
PiisAWheeL:
Richard:
PiisAWheeL:

And since we're on that topic... can we stop using the same 7 pictures of a 3rd world country over and over again everytime we want to demean the quality of work or people from india?
I don't know why you consider this picture demeaning. They have shoes (sorta) paved roads and even, it would appear, intermittent access to running water. Sounds like one of those Chamber of Commerce things trying to praise a place, not put it down.
I didn't consider the picture demeaning. Its context (fake nagesh using it with bad english and not saying anything funny) was designed to be demeaning. But that is not my point. There are like 7 of these pictures that get used in EVERY FUCKING THREAD! Its called the internet. Go find something a little more original and less worn out. That picture needs an arrow to the knee.
Adblock: "http://www.nytimes.com/images/2011/11/20*". There, a legitimate use for an adblocker even on an advertising-supported website!

Re: EvalToInteger, 'gumdrops', and More

2012-04-10 16:01 • by file minion (unregistered)
378877 in reply to 378749
PiisAWheeL:
Jay:
I'm really surprised that no one has pointed out the obvious error in the enum. Of course there should be FOUR values: Visible, Hidden, VeryHidden, and FileNotFound.
Wrong wrong wrong! Its an enum, not a BOOL. True, False, and File_not_found are the 2 BOOLEAN VALUES we can pick from. It has no place in enums.

Although, if hidden well enough, file may not be found...


FTFY

Re: EvalToInteger, 'gumdrops', and More

2012-04-11 05:25 • by L. (unregistered)
378923 in reply to 378779
Qvasi:
L.:
Programming 101:
if (!file_exists($dir) || !is_dir($dir))
if (!file_exists('test') || !is_dir('test'))
if (!TRUE || !FALSE)
if (FALSE || TRUE)
if (TRUE)

So if 'test' exists and is not a dir, a dir named 'test' will be created?


No . a dir will be created unless both dir and file exist w/ the name. and there will be an error


Assuming this is php, file_exists will return true if either a file or directory exists; thus is_dir() == true implies file_exists() == true.

Indeed . and that _IS_ scary . totally means you have to scan twice to know if it's really a file . good going php base functions ^^

Re: EvalToInteger, 'gumdrops', and More

2012-04-11 13:34 • by J-L (unregistered)
378967 in reply to 378708
WhoMe:
What exactly is wrong with this?

$dir = 'test';

if (!file_exists($dir) || !is_dir($dir))
{
exec('mkdir '.$dir);
}



The problem is that the "||" should be "&&". The way it is now, it's a little like saying:

if (gender != "male" || gender != "female")

{
print("Error: Unknown gender!");
}


At first glance, you'd think this code would print an error message whenever it got an unexpected input, like "12" or something like that. But in actuality, every input is either not equal to "male" or not equal to "female" (or both), making the condition equivalent to "if (true)", making users wonder why "male" and "female" are such esoteric genders.

So in the original code, the exec() command will get run no matter what, which is probably not what the programmer intended.

Re: EvalToInteger, 'gumdrops', and More

2012-04-12 03:42 • by Qvasi (unregistered)
378982 in reply to 378923
L.:

Indeed . and that _IS_ scary . totally means you have to scan twice to know if it's really a file . good going php base functions ^^


Well there is is_file() that returns true if the file exist and it's a regular file and is_link() that does the same for symbolic links.

The file file_exists() is returns true if there is anything (file, dir or link) with the supplied name in the directory, probably named as such because in Unix/Linux "everything is a file"...

Fixing this code (assuming there may be a file or link called "test") is not as easy, if the rest of the code assumes the a directory named "test" is created after this code is run... (But in practice; the directory will probably be controlled by this application anyway, so the assumption that no regular file or link with this name is present is probably safe)

Re: EvalToInteger, 'gumdrops', and More

2012-04-12 08:21 • by tin
378994 in reply to 378777
java.lang.Chris;:
You've missed the ultimate form of invisibility for a document - SavedToSharepoint


I keep hearing about this Sharepoint, and even got asked to "set it up" once... I even installed it. But I still can't figure out WTF it's meant to be.
I guess that makes it perfect Enterprise software?

Re: EvalToInteger, 'gumdrops', and More

2012-04-12 11:13 • by Bob (unregistered)
379027 in reply to 378750
That's not an ass.

Also, I think your complimentary internet stalker is morphing into Molesworth.

Re: EvalToInteger, 'gumdrops', and More

2012-04-13 08:05 • by IMil
379086 in reply to 378744
pjt33:
emurphy:
... on the same scale as BDate and EDate, where AFAICT the only WTF is that ToUpper() is unneeded.

Does DRY mean anything to you?

Come on, the code is repeated only twice.
Creating an extra function for formatting would be justified only if the formatting was likely to change often, unless there are N more date fields initialized in the same way.

Re: EvalToInteger, 'gumdrops', and More

2012-04-13 14:50 • by SockLess (unregistered)
379140 in reply to 378768
SCSimmons:
But by working together, they managed to create something that fails in cases of both malicious and normal users.

We don't see the code for the stored procedure, but I'll bet dollars to donuts that if it does something like a last name search, it will fail when the user enters O'Connell, once the EXEC command has been ruthlessly mangled by this abysmal front-end coding. Whether it's still vulnerable to injection attacks depends a lot on how competent the person who coded the stored proc was; hopefully this person was in no way related to the front-end coders.
Perhaps I'm missing something, but I'd expect the article's code to result in "exec spRequestInitechData 'O''Connel'" which is how you're supposed to escape single quotes. And thus it'll work quite well.

Are you saying that "exec spRequestInitechData 'O'Connel" Would be in any way better? Admittedly, the code crashing might be a relief for all involved. Also, the inside of the SP doesn't have to be involved in an injection attack in this case.

The really sad part is how easy it is to code this correctly ...
I guess something involving prepared statements that is two or three times as long?

Re: EvalToInteger, 'gumdrops', and More

2012-04-15 04:00 • by Daniel15
379156 in reply to 378746
that guy:
The first one looks like a part of this code, probably not a WTF.
http://odetocode.com/code/80.aspx

Looks like this is the case - That EvalToInteger is identical. In which case, EvalToString already has a .ToString() call, so doing s.ToString() in EvalToInteger is redundant.

Re: EvalToInteger, 'gumdrops', and More

2012-04-16 10:00 • by Ahto (unregistered)
379190 in reply to 378713
No, you can't. Both parameters of String.replace() are characters, not strings.

If you meant String.replaceAll(), then yes. But this was added to Java in 1.4, so it may or may not have been available when the code was first written. (And I know of a few servers that haven't still been upgraded from 1.3, so the code does not even have to be ancient for that to be true.)

Re: EvalToInteger, 'gumdrops', and More

2012-04-26 16:36 • by wgeek (unregistered)
379968 in reply to 378707
SCSimmons:
string sql = "exec spRequestInitechData '"
+ txtData.Text.ToString().Replace("'", "''") + "'";

Sometimes, I can't imagine the thought processes that lead to the WTF. I think it may be scarier when I can.

"We should escape the apostrophes when we build the SQL command, to prevent injection attacks."
"Actually, I've heard that the accepted standard is to use stored procedures."
"Oh. Hey, I've got an idea. Let's do both! Belt and suspenders, right?"
"Brillant!"

No, not at all.

That statement is building a string to be sent to the DB engine for parsing.

Exec spInitechData('O'Bryan');

See a problem with that statement?

Man, the quality of the reviewers on this site has really slipped lately. Y'all youngsters need to put on your thinking caps and think things through, and not be so quick to slam code that doesn't "make sense" to you.

Re: EvalToInteger, 'gumdrops', and More

2012-04-26 16:44 • by wgeek (unregistered)
379970 in reply to 379140
SockLess:
SCSimmons:
But by working together, they managed to create something that fails in cases of both malicious and normal users.

We don't see the code for the stored procedure, but I'll bet dollars to donuts that if it does something like a last name search, it will fail when the user enters O'Connell, once the EXEC command has been ruthlessly mangled by this abysmal front-end coding. Whether it's still vulnerable to injection attacks depends a lot on how competent the person who coded the stored proc was; hopefully this person was in no way related to the front-end coders.
Perhaps I'm missing something, but I'd expect the article's code to result in "exec spRequestInitechData 'O''Connel'" which is how you're supposed to escape single quotes. And thus it'll work quite well.

Are you saying that "exec spRequestInitechData 'O'Connel" Would be in any way better? Admittedly, the code crashing might be a relief for all involved. Also, the inside of the SP doesn't have to be involved in an injection attack in this case.

The really sad part is how easy it is to code this correctly ...
I guess something involving prepared statements that is two or three times as long?


You didn't miss anything. He's an idiot. The real WTF anymore on this site is the remarkable lack of comprehension, coupled with a true sense of arrogance.
« PrevPage 1 | Page 2Next »

Add Comment