• SteveB (unregistered)

    If only he'd read last week's post on SQL injection...

  • (cs)

    Universal Password!!! Brilliant!

  • (cs)

    So there is no key and the column "username" has the password.

    Methinks the coder was "simple"...

  • (cs)

    If i had goggles, they would do NOTHING.

  • (cs)

    I can't remember having seen a stronger invitation for a brute force attack. Logging in using a single piece of input..

  • notme (unregistered) in reply to snoofle
    snoofle:
    So there is no key and the column "username" has the password.

    Methinks the coder was "simple"...

    I think TRWTF was that the actual authentication consisted of redirecting the user to index.php (not exactly a hard to guess name, either). He didn't even note down a session variable saying "the user belonging to this session is authenticated" or something to that effect.

    Since the index.php is the page that is normally served by default, I wouldn't be surprised if even non-tech-savvy users could "hack" the site - "hack" as in they won't even notice the site was supposed to be password protected.

  • ph (unregistered)

    So I get it right:

    He runs through all usernames, and the last username in the list (in whatever order SELECT returns them) is the password?

    I am impressed.

  • (cs) in reply to ph
    ph:
    So I get it right:

    He runs through all usernames, and the last username in the list (in whatever order SELECT returns them) is the password?

    I am impressed.

    That's what I thought; then I read the last line of the post!

  • summerian (unregistered) in reply to snoofle

    He should be the dictionary definition of 'code monkey'.

  • Simple User (unregistered)

    Not only is it simple, it is Easy To Use (TM). I so hate it when I have to log in to a site, navigate 20 clicks through some obscure trail, and when I finally get to my favorite page I can't bookmark it because next time the site forces me through all those convoluted steps again!

    This site supports bookmarks! Just login once and no revalidation next time! No wonder he got hired by another company, probably a bank or someone with lots of money to burn.

    On second thought, couldn't be a bank. They couldn't work out how to make a site usable if it was the last step between them and a Congressional bailout!

  • (cs)

    Perhaps the application never gained more than one user. Plenty of room for growth!!

  • Gorfblot (unregistered) in reply to ph
    ph:
    So I get it right:

    He runs through all usernames, and the last username in the list (in whatever order SELECT returns them) is the password?

    I am impressed.

    Right. You would think this is a WTF, as SELECT without an ORDER BY clause does not guarantee order (As you stated). Except, as there is only a single username in that table, the order is relatively predictable.

  • (cs)

    I like how descriptive he gets when naming his variables. Who wouldn't know the meaning of $q and $chumbawumba ?

  • BK (unregistered)

    Classic example of bad naming. Had the table been named SingleWebPassword and its single column [password] , there wouldn't be WTF

  • Stephen Bayer (unregistered)

    I call bs on this one.. no one would be that stupid.

  • (cs) in reply to Stephen Bayer
    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.
    You must be new here. Welcome.
  • (cs)

    This is exactly why my company rejects job applications from anyone who listens to Chumbawumba. Or the Scissor Sisters. You just can't trust them.

  • (cs) in reply to Stephen Bayer
    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.
    Thank you, I needed a good hard laugh and the OP did not supply one, but you came through.
  • \ (unregistered) in reply to SteveB
    SteveB:
    If only he'd read last week's post on SQL injection...

    If only last week's post read this - no user input gets sent to the query, 100% SQL Injection Proof!

    I'll be using this in all my endeavours.

  • (cs) in reply to summerian
    summerian:
    He should be the dictionary definition of 'code monkey'.
    Nononono - he's only the dictionary definition of a very specific use of 'code monkey'. And frankly, I'd hoped a trained monkey wouldn't write code that bad...

    On the other hand, it does avoid the risk of SQL injection attacks... ;^) EDIT: Goodness, only three other people mentioned that whilst I was posting...

    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.
    You're joking. Right? Please tell me you're joking?!? You MUST BE JOKING!?!?!?!?!?
  • (cs) in reply to Stephen Bayer
    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.

    Nope. In a previous system I worked on, the original coder did the following to try and login a user:

    boolean login(String username, String password) {

    Statement s = c.createStatement();

    ResultSet rs = s.executeQuery("SELECT username, password FROM account");

    while (rs.next()) {
        if (rs.getString(1).equals(username) && rs.getString(2).equals(password)) {
            return true;
        }
    }

    return false;
}

    The account table had 1.7 million entries, and there was a perfectly good index on the username column. Logging in was slow, and he leaked connections by not closing them - if the database ran out of connections before the garbage collector kicked in he was straight outta luck.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.
    The account table had 1.7 million entries, and there was a perfectly good index on the username column. Logging in was slow, and he leaked connections by not closing them - if the database ran out of connections before the garbage collector kicked in he was straight outta luck.
    On the other hand: SQL Injection proof, AND it checks both the username and password! In the world of WTF, that's a WIN, surely? And we've all seen worse: 
    <input type="button" onclick='
if(document.getElementById("txtpass").value == "mypassword") 
    document.location="mysecretpage.html"' />
  • itsmo (unregistered) in reply to amischiefr
    amischiefr:
    Universal Password!!! Brilliant!

    You mean Brillant!

  • (cs)

    The real WTF here is the (common) misspelling of Chumbawamba. Who put the U in the wamba?

  • Rob (unregistered) in reply to SteveB
    SteveB:
    If only he'd read last week's post on SQL injection...

    Where do you see the possibility for SQL injection in this code?

  • noone (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    This is exactly why my company rejects job applications from anyone who listens to Chumbawumba. Or the Scissor Sisters. You just can't trust them.
    I got knocked down by your company. But I got up again. You weren't ever gonna keep me down.
  • Bejesus (unregistered)

    Sadly, that's significantly more elegant than most Single Sign On solutions I've encountered...

  • Bill (unregistered)

    Don't knock down this developer. He'll just get back up again, you're never gonna keep him down.

  • summerian (unregistered) in reply to JimM
    JimM:
    Nononono - he's only the dictionary definition of a very specific use of 'code monkey'. And frankly, I'd hoped a trained monkey wouldn't write code that bad...

    I must agree. Perhaps there should be another term - sth like 'code baboon' ...

  • silent d (unregistered)

    I get logged out, but I log in again, you're never gonna keep me out...

  • BrianK (unregistered) in reply to SteveB

    To quote a great movie... "INCONCEIVABLE!"

  • Ken B (unregistered) in reply to itsmo
    itsmo:
    amischiefr:
    Universal Password!!! Brilliant!
    You mean Brillant!
    No, he meant "Universal Pbuttword".
  • (cs) in reply to Bejesus
    Bejesus:
    Sadly, that's significantly more elegant than most Single Sign On solutions I've encountered...
    Interesting definition of "Single Sign On," though.
  • (cs) in reply to eehoo
    eehoo:
    The real WTF here is the (common) misspelling of Chumbawamba. Who put the U in the wamba?
    The same coder we're bashing did.

    And I don't think it is nowhere near being the real WTF here

  • (cs) in reply to JimM
    JimM:
    java.lang.Chris;:
    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.
    The account table had 1.7 million entries, and there was a perfectly good index on the username column. Logging in was slow, and he leaked connections by not closing them - if the database ran out of connections before the garbage collector kicked in he was straight outta luck.
    On the other hand: SQL Injection proof, AND it checks both the username and password! In the world of WTF, that's a WIN, surely? And we've all seen worse ...

    The reason it came to mind was the same programmers refusal to use parameterised statements. I spent a long time demonstrating an SQL injection vulnerability to him, and how to avoid them with the JDBC PreparedStatement. However, all that happened was that his code went from:

        Statement s = c.createStatement();
    s.executeQuery("UPDATE foo SET x = " + userSuppliedString);

    to:

        PreparedStatement s = c.prepareStatement("UPDATE foo SET x = " + userSuppliedString);

    At which point I refused to have him work on any of my projects.

  • I walked the dinosaur (unregistered) in reply to silent d
    silent d:
    I get logged out, but I log in again, you're never gonna keep me out...

    LOL!!!!!!

  • I walked the dinosaur (unregistered) in reply to I walked the dinosaur

    Pissing the WHERE away, pissing the WHERE away!

  • mauhiz (unregistered)

    Select commment from COMMENTS;

  • (cs) in reply to mauhiz
    mauhiz:
    Select commment from COMMENTS;

    Shouldn't that read

    SELECT comment FROM comments WHERE grey_background = TRUE;

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    Logging in was slow, and he leaked connections by not closing them - if the database ran out of connections before the garbage collector kicked in he was straight outta luck.
    I do not believe the "S" in "SOL" means what you think it means.
  • (cs)

    I'm guessing that it started out with a hard-coded password (possibly even some pathetic JavaScript validation), and somebody told him he should be using a database for authentication, and he didn't really understand what that meant but figured he'd give it the old college try.

  • (cs) in reply to eehoo
    eehoo:
    The real WTF here is the (common) misspelling of Chumbawamba. Who put the U in the wamba?

    JAM TIME! And a-one, and a-two, and a one-two-three-four :

    Who put the bomp in the bomp-a-bomp-a-bomp Who put the ram in the ram-a-lam-a-ding-dong Who put the bop in the bop-she-bop-she-bop Who put the dip in the dip-de-dip-de-dip
    Take it, eehoo!
    eehoo:
    Who put the U in the wa-a-amba?
    Who was that man, I'd like to shake his hand ...
  • anne (unregistered)

    He didn't even spell "Chumbawamba" right.

  • delenit (unregistered) in reply to fruey
    fruey:
    mauhiz:
    Select commment from COMMENTS;

    Shouldn't that read

    SELECT comment FROM comments WHERE grey_background = TRUE;

    Don't be silly rs = execute("SELECT * FROM comments"); while(rs.next()) { if(rs.get("grey_background") != FILE_NOT_FOUND){ println(rs); } }
  • Nobody (unregistered)

    Forgeting the login part for a moment I recognize this pattern. Using a table with one record as a kind of substitute for an Application variable.

    I see this more often than I'd like.

  • (cs)

    $q->query($sql);

    The real WTF, and something I see every day, is why just about everyone feels the need to abstract the mysql functions behind another layer of obfuscation?

    I've never heard a convincing reason for this and no doubt the first thing you have to do when looking at someone elses code is have to figure out the bizaare idiosyncrasies of their particular reimplementation.

  • M (unregistered) in reply to Stephen Bayer
    Stephen Bayer:
    I call bs on this one.. no one would be that stupid.
    I've seen something almost as bad (single user, username and password set to the same string, which was the three-letter acronym for the organization.) The username/password was not intended to provide strong security, just to prevent casual access. The app was internal and read-only, so not as bad as it might sound.
  • (cs) in reply to Nobody
    Nobody:
    Forgeting the login part for a moment I recognize this pattern.
    The Simpleton pattern?
  • (cs) in reply to DaveK
    DaveK:
    java.lang.Chris;:
    Logging in was slow, and he leaked connections by not closing them - if the database ran out of connections before the garbage collector kicked in he was straight outta luck.
    I do not believe the "S" in "SOL" means what you think it means.

    Damn shit it does.

  • (cs) in reply to Meep3d
    Meep3d:
    $q->query($sql);

    The real WTF, and something I see every day, is why just about everyone feels the need to abstract the mysql functions behind another layer of obfuscation?

    I've never heard a convincing reason for this and no doubt the first thing you have to do when looking at someone elses code is have to figure out the bizaare idiosyncrasies of their particular reimplementation.

    One convincing reason is that if you ever need to switch databases from MySQL to something else you don't have to rewrite all your code. Assuming that the SQL code is compatible you'd only need to rewrite the class that handles the API access.

    I also do it to simplify a few things. If for instance I know for an undeniable fact I will only receive a single value from a query then my database class has a function that can do exactly that: Return a single value from any given query.

    That takes a whole bunch of MySql function calls and reduces it to a single call from the application. Makes my life a whole lot easier.

    It also simplies cleanup as the moment my query class goes out of scope it is properly disposed of by the destructor. Same goes for database connections.

    So yea, there are a few reasons to put the API behind another layer. Hopefully however this layer is a layer that makes life easier, not obfuscates things.

Leave a comment on “Keeping It Stupid Simple”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article