• (cs) in reply to Lorne Kates

    TRWTF is that most of the people in the comment section can't understand a simple block of code...

    Also, notepad. Also the submitter's actions. Also the insufficient details from the OP to understand what really happened.

    Lorne Kates:
    In this one thing, the original programmer is blameless. That's all me. Indenting in a WYSIWYG is hard.
    WYSIWYG editors are for lusers. ;)
  • foo (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    foo:
    da Doctah:
    Dan F:
    As soon as I saw "Real Estate Agent" I knew it was going to be good. Every single agent I have ever met (and I meet lots in my line of work) has been a shallow, superficial, arrogant Luddite.
    I always chuckle when I think of the colleague who, while moonlighting, set up a Realtor's site with music that plays automatically and can't be shut off (which we'll call WTF #1), and how proud she was that she'd discovered the ideal piece of music for the purpose (which we'll call WTF #2):

    Pachelbel's Canon in D.

    For some distraction from Bobby Tables, the obligatory Pachelbel reference: http://www.youtube.com/watch?v=JdxkVQy7QLM

    Blah blah blah, Akismet, blah blah blah, no spam, blah blah blah, see you in hell, blah blah blah ...

    Funny seeing that on here. Just this morning I was watching the Four Chords Song, which covers the same basic theme.

    The real funny thing is that this is 4 chords and Pachelbel is 8 chords, yet they have at least 4 songs in common ...

  • foo (unregistered) in reply to Lorne Kates
    Lorne Kates:
    Or that's what I thought until I looked at it again and noticed that the "End If" and "Loop" indents didn't match the start of their blocks. TRWTF is programmers who can't indent properly.

    In this one thing, the original programmer is blameless. That's all me. Indenting in a WYSIWYG is hard.

    The sweet irony. Last time I checked, WYSIWYG meant "what you see is what you get". So you saw that you get a bad indentation, but were unable to fix it?

  • Pita (unregistered) in reply to Dan F
    Dan F:
    As soon as I saw "Real Estate Agent" I knew it was going to be good. Every single agent I have ever met (and I meet lots in my line of work) has been a shallow, superficial, arrogant Luddite.
    But you wouldn't buy a home without one :)
  • (cs)

    So...ummmm...where's the WTF? Any third-party software sales rep will tell you the only thing that matters is the clean, beautiful, creative, and unique, user interface.

    Reliability? It's reliably pretty! Correctness? It uses all the best grammar! Security? Yes, it has a password field. Quality? Just see that beautiful flashing display!

    Ignore the man behind the curtain...

  • pantsman (unregistered)

    TRWTF is that the OP made up the bit about the SQL injection attack demonstration, to spice up the story, and is now too proud to remove it. The story and the code do not match.

  • (cs)

    Wow, I can't believe I forgot this reference until now:

    "Security is for closers."

  • Jazz (unregistered) in reply to Techpaul
    Techpaul:
    DCRoss:
    Ross Presser:
    There was no injection attack because what was entered in the form was never sent to the SQL server at all. You can't get the heroin in the vein if there's no syringe to use.

    That's what's confusing. How did Emmett spot the SQL injection vulnerability on the login page, and how did he log in with the username "' OR 1=1;--"?

    (Edit: Yeah, what he said.)

    Because he used that as the USERNAME, and in fact ANY username including blank would work as long as the password was 'star'.

    Right, so how exactly did he know to type "star" as the password when he typed "' OR 1=1;--" as the username?

    He claimed to have a working proof of concept of the vulnerability just by typing "' OR 1=1;--" in the username field. How could he possibly have gotten that result if he didn't know to type "star" in the password field?

  • (cs)

    The only editors that are hard to do anything properly in are those that don't support my WITIWIM attitude.

  • sql injection (unregistered)

    TRWTF is the number of people commenting who like the OP don't seem to understand how SQL injections actually work.

  • john (unregistered)

    Made-up story is made-up.

    Made-up story implies that injection was discovered, yet the code permits successful authentication only if the password submitted == 'star'.

    What's the likelihood that a password was even submitted when the injection string (submitted as the user name) closes the SQL statement?

    Made-up story is made-up.

  • C-Derb (unregistered) in reply to Lorne Kates
    Lorne Kates:
    The password field must have been already filled in (saved?) from a previous login?

    Correct.

    If this is in fact true, that the password field on the web page contained the password "star" that was typed in from a previous login attempt, then we have yet another WTF in this story. You are implying that the login form didn't even use a password input field, but a plain text field? So the user would type in a password and it was clearly visible in plain text to anyone who might be looking over their shoulder?

    Honestly, Lorne, you should have just posted the damn code snippet and left the story in your WYSIWYG editor. #storyfail

  • (cs)

    Holy (fuck) that (was) annoying (to) read.

  • (cs) in reply to john
    john:
    Made-up story is made-up.

    Made-up story implies that injection was discovered, yet the code permits successful authentication only if the password submitted == 'star'.

    No, look at it carefully. It didn't check the username and password that were entered, at all. If anyone in the database had the right password, the login would be successful. The stock SQL injection trick worked, but it only worked by accident because any login would have worked.

  • Brian (unregistered)

    I saw that at least one other person caught the fact that the MoveNext is OUTSIDE the loop.

  • (cs) in reply to foo
    foo:
    Lorne Kates:
    Or that's what I thought until I looked at it again and noticed that the "End If" and "Loop" indents didn't match the start of their blocks. TRWTF is programmers who can't indent properly.

    In this one thing, the original programmer is blameless. That's all me. Indenting in a WYSIWYG is hard.

    The sweet irony. Last time I checked, WYSIWYG meant "what you see is what you get". So you saw that you get a bad indentation, but were unable to fix it?

    No. I saw indentation. I didn't get what I saw.

  • john (unregistered) in reply to Mason Wheeler 
    If Request("Password") = "star" Then

    If the submitted password is equal to 'star'. It's very clear, no?

  • john (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    john:
    Made-up story is made-up.

    Made-up story implies that injection was discovered, yet the code permits successful authentication only if the password submitted == 'star'.

    No, look at it carefully. It didn't check the username and password that were entered, at all. If anyone in the database had the right password, the login would be successful. The stock SQL injection trick worked, but it only worked by accident because any login would have worked.

    If Request("Password") = "star" Then

    If the submitted password is equal to 'star'. It's very clear, no?

  • (cs) in reply to Lorne Kates
    Lorne Kates:
    In this one thing, the original programmer is blameless. That's all me. Indenting in a WYSIWYG is hard.
    WYSIWYG editors are TRWTF.
  • thegoddamnbatman (unregistered) in reply to Mason Wheeler

    Whether the story is true or not, I am curious to see how it ends. Will our stalwart hero convince the Judy S. Kirkland (5 Star something-or-rather) to upgrade the website security? Will the project become an entirely new WTF? Or will one of the other Super-Realtor-Villans take the #1 spot?

    Stay tuned! Same WTF-Time, Same WTF-Channel.

  • Abico (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    john:
    Made-up story is made-up.

    Made-up story implies that injection was discovered, yet the code permits successful authentication only if the password submitted == 'star'.

    No, look at it carefully. It didn't check the username and password that were entered, at all. If anyone in the database had the right password, the login would be successful. The stock SQL injection trick worked, but it only worked by accident because any login would have worked.

    Look at it carefullier. Yes, it did check the password that was entered. The Request object is what comes from the browser.

  • (cs)

    Don't forget:

    login.asp?Password=star
  • Jockamo (unregistered)

    How does this confuse you all so much?

    This: If Request("Password") = "star" Then

    IS ALWAYS TRUE.

  • john (unregistered) in reply to Jockamo
    Jockamo:
    How does this confuse you all so much?

    This: If Request("Password") = "star" Then

    IS ALWAYS TRUE.

    No. Here, as a conditional statement, the equality sign means equality and not assignment.

  • Abico (unregistered) in reply to Jockamo
    Jockamo:
    How does this confuse you all so much?

    This: If Request("Password") = "star" Then

    IS ALWAYS TRUE.

    Not all languages have ==.

  • Nappy (unregistered)

    "[b]Not[/] a proof of concept (successful login with username: ' OR 1=1;--) "

    There was no proof of concept (that would usually test something like .....)

  • C-Derb (unregistered) in reply to Nappy
    Nappy:
    "[b]Not[/] a proof of concept (successful login with username: ' OR 1=1;--) "

    There was no proof of concept (that would usually test something like .....)

    Bad try. The sentence before that one is the key: "But nothing could convince Judy S. Kirkland (Gold Star Closer) to spend money on beefing up the code's security. Not a proof of concept...Not....Not..."

  • (cs) in reply to john
    john:
    Jockamo:
    How does this confuse you all so much?

    This: If Request("Password") = "star" Then

    IS ALWAYS TRUE.

    No. Here, as a conditional statement, the equality sign means equality and not assignment.

    This is one of the rare cases where Basic is actually superior to C++; another is Select Case vs. switch.

  • (cs)

    Decline of TDWTF comments. WTF you guys

  • (cs) in reply to Lorne Kates
    Lorne Kates:
    That's all me. Indenting in a WYSIWYG is hard.
    Honestly I'd prefer a simple WYSIWTF editor...
  • DB (unregistered)

    Fail. (Blah Blah Blah Blah Blah).

  • logged in guy (unregistered)

    But what does it mean to be "logged in" ?

    Maybe having a "star" in the passwords just means that the website works. Remove the star and the site is disabled.

  • Meanie (unregistered) in reply to foo
    foo:
    Alexander Harris:
    JC:
    JC:
    For the people who still don't get this:

    The code is enumerating all the passwords in the database, as long as any one of them is "star" the user is logged in.

    Thus, it doesnt matter if you typed, "star", "OR 1=1--" or "letmein" in the password field, as long as the database had a user with password "star", you're logged in.

    No SQL Vulnerability, submitter just tried a common exploit and it worked - at which point s/he assumed SQL Injection was the cause.

    Ignore that, just looked again and its enumerating the records, but checking the field had "star" in it. Now im just as confused as everyone else why "OR 1=1--" worked.

    The password field must have been already filled in (saved?) from a previous login?

    I think the explanation is quite simple: Too much creative writing going on (ETDWTF). If we get the original story, it will probably make sense.
    I'll take it a step further and suggest that aside from a lot of creative writing, there's occasionally a WTF that the writer doesn't fully understand - but if it's related to DB's it must have been an SQL injection vulnerability.
  • John (unregistered) in reply to Andrew
    Andrew:
    Nevermind, I misread the code. C-Derb is correct. "' OR 1=1; --" could not have worked without a password.
    I think the article and the code have been anonymized - badly. For every password in the database, compare a constant string with the variable on the form.

    I think the badness here is exaggerated a lot

  • Mike (unregistered) in reply to AnonymouseUser
    AnonymouseUser:
    It matters because that's the first thing any developer should ask. I don't recall ANY real estate sites where there was a login section, anything other than viewing was done over the phone.
    Serious? Go look for some realestate sites. They all seem to have logins. In fact, I think it's practically illegal these days to have a website with no logins. You'll never make it in the real world (TM).

    I think with Real Estate sites, one of the reasons is so you can set up monitors on properties of interest...Useful? Probably not, but I can sort of see why people would do it...

  • (cs) in reply to chubertdev
    chubertdev:
    Don't forget: 
    login.asp?Password=star

    For those that aren't familiar with ASP, the Request object has five collections:

    1. ClientCertificate
    2. Cookies
    3. Form
    4. QueryString
    5. ServerVariables

    So to properly pull from a form field, you would use this:

    Request.Form("Password")

    And to pull from a URL:

    Request.QueryString("Password")

    I know that Request("Password") will pull from the Form and QueryString collections, not sure which of the other three it could pull from.

    Either way, not a huge security risk, just sloppy. I definitely have the feeling that this is another case of someone who "likes" computers trying programming, and creating code that shows the wide divide between knowing how to get something working, and doing a job correctly.

  • foo (unregistered) in reply to Meanie
    Meanie:
    foo:
    Alexander Harris:
    JC:
    JC:
    For the people who still don't get this:

    The code is enumerating all the passwords in the database, as long as any one of them is "star" the user is logged in.

    Thus, it doesnt matter if you typed, "star", "OR 1=1--" or "letmein" in the password field, as long as the database had a user with password "star", you're logged in.

    No SQL Vulnerability, submitter just tried a common exploit and it worked - at which point s/he assumed SQL Injection was the cause.

    Ignore that, just looked again and its enumerating the records, but checking the field had "star" in it. Now im just as confused as everyone else why "OR 1=1--" worked.

    The password field must have been already filled in (saved?) from a previous login?

    I think the explanation is quite simple: Too much creative writing going on (ETDWTF). If we get the original story, it will probably make sense.
    I'll take it a step further and suggest that aside from a lot of creative writing, there's occasionally a WTF that the writer doesn't fully understand - but if it's related to DB's it must have been an SQL injection vulnerability.
    Maybe gool ol' Bobby Tables isn't quite as over-quoted as some think ...
  • Smarty Tablets (unregistered)

    Let me join the war too...

    I suspect what might have happened is....

    Real Acetate agent is logged in.
    Emmet does his 'SQL Injection test' Emmet assumes (since the Session hasn't actually loggerd out with the new login attempt) that his SQL Injection works Emmet discovers about 500 WTF's in 5 lines of code....

    Let's recap

    1. There is no SQL injjection
    2. The password is checked (repeatedly), but not against anything in the DB
    3. Once someone is logged in, subsequent logins from the same machine will remain logged in (with the same privileges).
    4. (I'm guessing) there is exactly 1 password in the DB and it's "star", but the RE agent doesn't realise it could be "FRED" and everything would still work (or not work) the same....
  • Derp (unregistered)

    So many people not grasping the facts. A few that do.

    1. the RS.MoveNext is inside the loop, it's the crappy indentation that's throwing anyone who believes otherwise

    2. it's not comparing against any field in the recordset, it's comparing the Request Form/Querystring variable "password" for the value "star". The recordset enumeration is pointless. As there's no querying or modification using any parameters from the user, it's most likely immune to SQL injection, assuming there are no unicorns or rainbows.

    3. ASP (which, server-side uses VBScript) does not have = and == for assignment and comparison, only = which does both depending on context

    4. Request("Password") - if you omit the collection name to enumerate from Request, then ASP will enumerate ALL collections in this order: -

    1. QueryString
    2. Form
    3. Cookies
    4. ClientCertificate
    5. ServerVariables

    This is a WTF (in my opinion) on ASP's part; good practice would IMO be to always be explicit and not really on magic to handle defaults.

    I think the intention is to capture it from either the form or querystring, form most likely.

    1. The sequence of events in this poor guy's story was, I believe: -
    1. Discover SQL injection attack ( OR 1 = 1)
    2. Prove this to dumbass client
    3. Re-write login method to what we can see in the article

    TRWTF is most of the responses here.

    That is all.

  • (cs)

    The database query IS used, it makes the page take a little bit longer so that it looks like it's thinking, enhancing the user experience. :)

  • (cs) in reply to chubertdev
    chubertdev:
    The database query IS used, it makes the page take a little bit longer so that it looks like it's thinking, enhancing the user experience. :)

    Also, if the recordset is empty, then login fails regardless of the password.

  • Meep (unregistered) in reply to Stev
    Stev:
    Yeah I'm sure this WTF is plainly obvious to most web developers out there but us mere mortals haven't a clue what's actually happening - an SQL injection, or a hardcoded password?

    You really can't follow a simple loop stepping through a SQL result set?

  • Abico (unregistered) in reply to Meep
    Meep:
    Stev:
    Yeah I'm sure this WTF is plainly obvious to most web developers out there but us mere mortals haven't a clue what's actually happening - an SQL injection, or a hardcoded password?

    You really can't follow a simple loop stepping through a SQL result set?

    I'm guessing Stev meant it's not obvious to a non-web developer which is happening. The story complicated things by making it sound like an SQL injection attack worked, when I think the author meant it appeared to work.

  • Rohit (unregistered)

    I like Java PreparedStatement, it atleast save from this SQL Injection

  • noland (unregistered) in reply to Michael
    Michael:
    should be "...Or worse? Who would trust their home with someone who used Comic Sans?"
    This, my Sir, was the hand-picked font, all set tastefully in chartreuse.

    Imagine this being replaced by Times Roman Regular – what a thought, no more Most Requested Upper Echelon Realtor Website of the Year (2012)!

  • Brian (unregistered) in reply to Brian

    Man, I'm an idiot. Damn you horrible indentation!

  • (cs)

    Real estate people, where to begin. A while ago (it was around 15 years ago) they setup the local MLS to have pictures. The IDs were 9 digits long, and they had a special program that would take any bunch of text and find the 9 digit numbers then fetch pictures. Of course they had to have their own private network that you needed to dial in (no internet, to unsecure!) so it involved specialized programs. They all worked well until the 9 digit field overflowed and they started using numbers starting with zero. Then they didn't have 9 digit numbers any more and it all failed. Oh, well.

    Bunch of "self important" people.

  • Ardi (unregistered) in reply to chubertdev

    Yes, bookmarking the url that has the password is bad. Anything entered in the log in fields will log you in. But no one has mentioned, you might as well bookmark /realtor_home.asp and completely skip the log in screen. That's Real Security. Google has probably already indexed the "secure" page and has it in search results with a direct link :)

  • Another Andrew (unregistered)

    Ok, TRWTF is the story.

    The Proof of concept wouldn't work against the offending code as presented at the end of the article; ever. The SELECT query was doing nothing regardless.

    I suppose the other WTF's were everyone tripping over assignment and equality in the vbscript or mistaking request("password") for something like rs("password").

    If we are to believe that the block of code presented at the end of the article is the solution that the developer came up with then we have another RWTF and that is this guy writing code. A better solution would have been to use request.form() to prevent query stirng submissions, write a function to sanitize anything that hits the database and use stored procedures and tokens instead of SQL queries.

  • Turd Whiskers (unregistered)

    So why exactly is Pachelbel's Canon etc. supposed to be a WTF?

Leave a comment on “Real Security”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article