• Mark (unregistered) in reply to Carra

    Well if he did, then he's even MORE stupid!

  • Anigel (unregistered) in reply to foo

    Hey take a bottle or two of valium. Its not my code, im not telling people how to spell thier names, im just saying that from the code presented, there are the possibility of many special cases that have now been rolled up and lost.

    Yes in an ideal world there shoudl be no need to muck at all with the user input, just validate it as being reasonable and make sure its not some xss and just go with that.

    However it appears from teh code that for who knows what reason it has alreayd been played with and lowercased somewhere else

  • Claxon (unregistered) in reply to feugiat
    Let's just hope he, you know, grepped the code for special cases before deleting it...

    Indeed... I mean what happens when it comes to this...?

        case "john":
            $day = date  ( "l" );
            if($day == 'Saturday' || $day == 'Sunday'){
                echo "Susan";
                echo "John";
  • Dennis (unregistered) in reply to Ben

    Not necessarily, it might make sense to fix that somewhere other than the uppercase function.

  • Iceman (unregistered) in reply to RazZziel
    You don't even need a builtin function, just *name -= 'a'-'A';

    Sigh the old times when men were men...

    And ASCII was the only encoding table you needed to worry about ...

  • dkf (unregistered) in reply to Iceman
    You don't even need a builtin function, just *name -= 'a'-'A';

    Sigh the old times when men were men...

    And ASCII was the only encoding table you needed to worry about ...
    Actually, the code above with 'a'-'A' was what you wrote when you wanted the code to work on both ASCII machines and EBCDIC machines. (The offset is twice the size and in the opposite direction with EBCDIC, but the code still works.)

  • Mel (unregistered) in reply to xzzy
    I could forgive missing the existence ucfirst(), it's not like php has any kind of identifiable pattern for naming functions. Would be pretty easy for a newbie to miss stuff like that.

    A naming convention for functions? No. Good documentation, where most things are relatively easy to find? Yes. Many times I've thought "Oh, I wonder if there's a built-in function that does ...", and a quick look through the string functions, array functions, whatever functions reveals - yes, there is one. No naming convention is not an excuse - failing all else, there's your good friend google (search for "uppercase php", 2nd result is PHP manual entry for ucfirst). Or even - god forbid - asking a real, live, breathing human being...

    Missing ucfirst, or any other particular function is not the WTF, the WTF is missing the concept one might exist and actually pulling your head out to look for it...

  • BitTwiddler (unregistered) in reply to foo

    Back at IBM, we got some junk mail one time addressed to "Mr. International B. MacHines", because some clever program attempted to abbreviate the middle name and handle the "special cases" (no pun intended) in last names.

  • iogy (unregistered) in reply to Mel
    Many times I've thought "Oh, I wonder if there's a built-in function that does ...", and a quick look through the string functions, array functions, whatever functions reveals - yes, there is one.
    Which shows usually that the guy who cobbled together that function lacked imagination and innovation, which is the cause of a lot of WTFs on this site, because people reinvent the square wheel. Rewriting it to ucfirst is not generalizing; taking a string input and changing the first character to uppercase is generalizing.
    No naming convention is not an excuse
    Yes, it is. It's not hard to do it, they've had enough time for this, it's not hard to alias functions afterwards and not hard to adjust the documentation so that your shitload of strfun() or funstr() or fun_str() or str_fun() are rewritten.

    There's also the fact that almost all those cute little functions with unique names take their arguments in different orders and there's absolutely no need for that, ether. Or, go the .Net or Java route which makes it something like String.UppercaseFirst, which is even more useful and great if you have Intellisense (which is even faster than Google - smaller dataset to search through and no reams of idiots posting HOW DO I DO THIS PLZ MAIL CODEZ.).

  • (cs) in reply to danopia
    ITYM SQL injection vulnerability.
    Another WTF... How is that SQL injection! XSS, yea, but where's the SQL injection vunerability?

    The person you quoted was referring to the post with the link to an xkcd comic in it, but forgot to quote it. The comic referenced an SQL injection vulnerability, not an XSS vulnerability, betraying the fact that the person who posted it didn't understand either concept.

  • Mr. Bean (unregistered) in reply to Carra
    Comment held for moderation.
  • Mr. Bean (unregistered) in reply to Mr. Bean
    Comment held for moderation.
  • Hugo (unregistered) in reply to Mr. Bean

    It seems there are names from several languages in that list, so perhaps it would capitalize with the correct locale in mind (which it guessed from the name). E.g:

    ijsbrant -> IJsbrant (dutch)

  • UncleWTF (unregistered) in reply to Tom Melly

    ucfirst() doesn't make sense for all first names. Ask my nephew D'Quione.

  • (cs) in reply to Claxon
    Indeed... I mean what happens when it comes to this...?
        case "john":
            $day = date  ( "l" );
            if($day == 'Saturday' || $day == 'Sunday'){
                echo "Susan";
                echo "John";

    In my case, the spelling of my name is user- and context-specific. Like so:

        case "kurtis":
            switch ($lUser) {
                case "Wendy":
                case "Stephen":
                    echo "Curtis";
                case "Cynthia":
                    if ($lUserAlcoholLevel > 0.05) {
                        echo "Karl";
                    } else {
                        echo "Keith";
                    echo "Korbet";

    Note to self: insert giant frowny face here...

  • AdT (unregistered) in reply to widget
    Comment held for moderation.
  • (cs) in reply to GalacticCowboy

    Wow... The real WTF is the stupid quote mechanism in the board software... The last sentence in the quote block in my post above is SUPPOSED to be outside the quote block, but what I wrote and what got rendered were two different things and of course the edit period expired...

  • Jabe (unregistered) in reply to gabba
    Can't wait for the next installment, in which we learn the process by which names are added to "the database".

    No, the next installment is where we learn the process by which last names are cleaned up.

  • John (unregistered)

    Ironically, refactoring the switch statement to ucfirst may produce incorrect results! Why not assume the user knows how to type their own name? Then allow them to modify or verify it.

  • Chris (unregistered)

    Maybe they prevent the XSS hack because the output is caught and filtered first...

    /just upset I didn't catch that first. //other commenter is right though, it's not a "new" bug

  • Cloak (unregistered) in reply to Jens
    Ah, there it is...last changed on January 2 of 1994, i was 11 back then:

    SCREEN 12 WINDOW (0, 0)-(640, 480) LINE (0, 0)-(640, 480), 1 LINE (1, 0)-(639, 480), 2 LINE (2, 0)-(638, 480), 3 LINE (3, 0)-(637, 480), 4 LINE (4, 0)-(636, 480), 5 LINE (5, 0)-(635, 480), 6 LINE (6, 0)-(634, 480), 7 LINE (7, 0)-(633, 480), 8 LINE (8, 0)-(632, 480), 9 LINE (9, 0)-(631, 480), 10 LINE (10, 0)-(630, 480), 11 LINE (11, 0)-(629, 480), 12 LINE (12, 0)-(628, 480), 13 LINE (13, 0)-(627, 480), 14 LINE (14, 0)-(626, 480), 1 LINE (15, 0)-(625, 480), 2 LINE (16, 0)-(624, 480), 3 LINE (17, 0)-(623, 480), 4 [snip] LINE (640, 466)-(0, 14), 13 LINE (640, 467)-(0, 13), 14 LINE (640, 468)-(0, 12), 1 LINE (640, 469)-(0, 11), 2 LINE (640, 470)-(0, 10), 3 LINE (640, 471)-(0, 9), 4 LINE (640, 472)-(0, 8), 5 LINE (640, 473)-(0, 7), 6 LINE (640, 474)-(0, 6), 7 LINE (640, 475)-(0, 5), 8 LINE (640, 476)-(0, 4), 9 LINE (640, 477)-(0, 3), 10 LINE (640, 478)-(0, 2), 11 LINE (640, 479)-(0, 1), 12

    great code. sometimes I think Windows was written this way (if it's too slow add better hardware)

  • kll (unregistered) in reply to Migala

    There is no vulnerability there. You should not escape input, only output.

    (because you may have to output in different contexts which require different escaping and/or processing could remove escaping)

  • Ľudovít Štúr (unregistered) in reply to Craig Beere
    Craig Beere:
    How about *name =& !32 or something? (haven't tested it)
    Except, of course, replace the logical not with the bitwise version *name =& ~32 oops

    That approach is a bad one because it relies on a numerical relationship between upper case letters and lowercase letters that is not always true. For example, it will fail if your name begins with Ā (capital a macron) with code 0x0100 since the lowercase version ā is code 0x0101.

    Yeah, tell me about it. And then š and ž have a difference of 16 between upper and lower case, as does œ.

    Of course TRWTF is that Zuzanny is just the plural of Zuzanna. What happened, did two of them turn up at once?

  • anonymous coward (unregistered)

    Hasn't the guy broken the code?

    Unknown names previously were left unchanged, but now they'll be capitalised. Who are we to say that this wasn't an important feature!

  • Pete (unregistered) in reply to Carra

    Ha, ya right-- a PHP generating Perl script. Ack, I think that my eyes just started to bleed!

  • Steve (unregistered) in reply to Tom Melly

    I think it says a lot about the state of PHP and the myriad of functions out there that are a PITA to find and use.

    ugh, how I hate PHP

  • tonyb (unregistered) in reply to FredSaw
    Back in the good old days (circa 1984), when I was writing 6809 assembler for the Tandy Color Computer, I would have ANDed the ASCII value of the first letter with hex DF. Whip out your little scientific calculator and try it.

    Dropping the 5th bit would make lower case 61h - 7Ah into lower case 41h - 5Ah but it would make any digits 30h - 39h into unprintable (machine dependent) 10h - 19h codes.

    What is sad is that all the hexadecimal codes are from memory and I haven't needed to look up anything :-(

  • Kai Grossjohann (unregistered)

    I wonder what user TJ will say.

  • zugy (unregistered) in reply to Carra
    Comment held for moderation.
  • omg (unregistered)

    so THAT is the most STUPID thing that i've EVER seen :D

  • billy puertas (unregistered) in reply to Carra

    Well, It is not the case with php. But some crappy "programming languages" don't support strings properly, and you finish doing things like that to implement a printf for non const strings.

    Yes, I'm talking about Texas Instruments GEL. Which is incorrectly specified in everything, and doesn't allow you to do anything right.

    I finished having to do

    if (data = 0x0041) print ("a") else ...

    Because, of course, they never thought making a switch statement was worth. Lazy language designers...

Leave a comment on “Reverse Brute Force”

Log In or post as a guest

Replying to comment #:

« Return to Article