Comment On EvalToInteger, 'gumdrops', and More

That's a goat, it's cloven footed. Asses are equids, and have only one hoof per leg.

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.

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 !

VeryHidden is used very less

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.

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 ...

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.

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

Oh and by the way, anyone want to see my private carrot ?

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?

lol omigosh frist!!11!!

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

>> 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.

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.

In 1986, India was being given 7 Polaroid camera from British govrenment. Most of the fotos are being lost. :(

AB:

Hey, as a developer I may be terrible and devoid of any structure, but I resent being compared to that code.

Thank you.

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.

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?

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.

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.

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".

Why not replace with a blank string?

replace('/', '')

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".

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!

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

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 ^^

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.

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)

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?

That's not an ass.

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

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.

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?

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.

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.)

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.

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.