• woohoo (unregistered) in reply to Laurent
    Laurent:
    Can't belive it :) dammit.. I'd do myself ara-kiri (how the hell do you write that ?) if I'd write such as waste ;)

    hara-kiri or harakiri, actually.

    you don't happen to be french, perchance? your name insinuates that and it'd explain the loss of the "h" if you only ever heard it and never saw it in written form ;o)

    BTW, the more formally correct term is "seppuku" (see wikipedia ;o)

  • Andrew (unregistered) in reply to Laurent
    Laurent:
    Can't belive it :) dammit.. I'd do myself ara-kiri (how the hell do you write that ?) if I'd write such as waste ;)

    The term is "hara-kiri", and it literally means "belly-cut". It's also bad slang. The right term is "seppuku" for ritual suicide.

    WTF, seppuku-ga aru!

  • (cs) in reply to mantis
    mantis:
    One time, I saw a Javascript authentication system in place for the partner extranet on the Web site of a major manufacturer of fingerprint scanners and biometric security equipment.

    The way it worked was, it downloaded a Javascript MD5 implementation, and a list of password hashes as a JSON object. When the onsubmit() event of the login form fired, the password input got hashed and compared against the list. If your password was in the list, the code set a cookie and redirected you to the extranet home page (which would, again through Javascript, redirect you back to the login page if you didn't have the cookie).

    There was no robots.txt file (there is now), so the hundreds of precious PDF files that you supposedly needed a paid extranet account to access, linked to by the extranet home page, were available to anyone smart enough to hack the system or disable Javascript, and to anything that wasn't a Web browser, like Google's indexer bot.

    The same site used Apache digest auth elsewhere, but that was compromised because the aforementioned JSON file was substantially the same list of MD5 hashes as the .htpasswd.

    I'd feel really "secure" using their products. The Department of Homeland Security is one of their biggest customers.

    Holy shit. I was just going to comment about that exact same site, except I can't remember what site it is. It's been about a year since I came across it, and IIRC, I did manage to bypass the security to get the info I needed.

    Out of curiosity, how did you come across that site? It's not often that I run into people in the biometrics industry out in the wild.

  • Stu (unregistered) in reply to Mythbester
    Mythbester:
    I'm assuming they're using IIS, so they completely ignored the built in IP and Domain Name restrictions. Unless of course they're hosting it on a Windows XP version of IIS which has that feature disabled, which would be a WTF in a whole other category.

    Or it's a shared hosting account.

  • (cs) in reply to mattnaik
    mattnaik:
    Mythbester:
    I'm assuming they're using IIS, so they completely ignored the built in IP and Domain Name restrictions. Unless of course they're hosting it on a Windows XP version of IIS which has that feature disabled, which would be a WTF in a whole other category.

    captcha = cognac (hic!)

    Especially considering that the XP version only allows something like 5 concurrent connections. "Sorry surfer number 6...wait your turn"

    Well, I could be wrong, and to be frank it's too much of a pain to verify. However, AFAIK, the default number of concurrent connections on a listening socket -- well, that's really only "queued" connections, since the socket gets forked off on an actual connection -- is five. This is a generic TCP/IP default, not an IIS limitation.

    Now, I don't know whether IIS turns the default into a hard limit, and in fact I don't even know whether I've got any of this right. It does seem a little unfair to bash IIS on this basis, though. All popular Web servers are crap, in my opinion. (Apache 1.3 and Apache 2.x are simply crap in totally different ways.)

    It's not their fault. It's just in the nature of Web servers.

  • whoosh (unregistered) in reply to Sgt. Preston
    Sgt. Preston:
    s|k:
    That's VB for you...
    You have got to be kidding. How do you figure JavaScript would be more secure? One can write plenty secure Web site security in VBScript and ASP and one can write just as poorly designed Web site security in any language one chooses. What is with this persistent knee-jerk reaction to VBScript and Visual Basic? The WTF is in the bad design, not in the choice of language.

    What was that sound of something going over your head, Pressed-on?

  • mantis (unregistered) in reply to BrownHornet

    I work on Web content management solutions. That company courted my company to do some work on their site, mainly cosmetic (which isn't what we usually do - we do large CMS/WCM builds), and I was assigned to reverse-engineer the existing functionality (which took about an hour, after the weeks it took to obtain server access). We ended up doing very little, because the company had a difficult internal IT team, a tight budget, and high turnover (a different POC every month for their account with us!), and -- in my opinion -- because we quickly recognized the account to be a liability minefield.

    The name of the company is the same as the common name of the blood test that is done to check for incompatibility between an organ transplant donor and a recipient.

  • Kasper (unregistered) in reply to Lastchance
    You can't discuss languages and WTFs without including Esperanto.
    The real WTF is Volapyk. It is a language invented around 1880. It quickly lost popularity with the introduction of Esperanto. The word volapyk is still used today in some languages, though the meaning has changed. A Danish-English dictionary will tell you, that the word now means gibberish.

    Captcha: tacos (It is trying to tell me I should go to a Mexican restaurant tonight)

  • Kasper (unregistered) in reply to Sgt. Preston
    The WTF is in the bad design, not in the choice of language.
    Something tells me you didn't have the necesarry knowledge to understand the irony in that statement. You cannot implement the same design with those languages, because ASP is executed server side and Javascript is executed client side. Of course the person making that comment knows that, and the real point is, that it would be even worse if you had done the same thing on the client. Unfortunately some sites do implement security that way.
  • Chris (unregistered) in reply to M. Dizzy
    M. Dizzy:
    I'm trying to figure why they do two checks. Also not using the shortcircuit orelse operator is a waste of cycles. At least this one isn't as eye-gougingly horrible as some recent ones.

    captcha: tastey (mmmmm...mmmm good)

    As near as I can tell, the programmer got tired of writing dozens of IPs on one line, so he coded a second test to take care of the rest.

    But while amazingly stupid, it's still not the real WTF; the real problem is that this "gateway" code doesn't protect anything. The attacker can access the "protected" URL by simply typing it directly into his address bar.

    Chris

  • (cs) in reply to Kasper
    Kasper:
    You cannot implement the same design with those languages, because ASP is executed server side and Javascript is executed client side.
    Both Javascript and VBScript can be executed on the server side, where the container is ASP, or on the client side, where the container is Internet Explorer.
  • prof_hobart (unregistered) in reply to Jonni
    Jonni:
    For a while I was thinking all that ip = foo was assignments! THAT would be a complete WTF!

    Although, I do think that mixing the assignment operator with the test-equality operator is a small WTF in itself.

    Still waiting for anyone to tell my why a language where someone trying to do
    if (a==b)
    and missing one of the = out results in a horrible bug is somehow better.

  • rjnewton (unregistered) in reply to Sgt. Preston
    Sgt. Preston:
    akatherder:
    JavaScript would be almost as secure and easy to maintain (NOT secure and a nightmarish). You could only forward on success, so those with JavaScript disabled aren't automatically forwarded. You'd need a way to jumble the URL too. Someone could look at the list of IP addresses and Class C's, but there would be much easier ways to bypass this Fort Knox-like security than spoofing your IP address.
    This is a server-side ASP application written in VBScript. I presume that if you switched to JavaScript you would still be writing a server-side ASP application and not a client-side application. The list of IP addresses would not be exposed to the client regardless of which language you used.

    Excuse me, but what are you talking about--"server-side Javascript"?!?! I'm really hoping that this is subtle sarcasm, and I missed the tags. Who knows, perhaps there is such an animal, running in a server-side browser, perhaps? To date though, I have not seen a Javascript file called from HTML that I could not download and read in plain text with a simple get request, nor an obfusciated JS function that I couldn't decompile with a few newlines, some indentation, and substitution of meaningful variable names once the general drift of the fucntionality became evident.

    Use Javascript to ensure that required fields have content, yeah, but not to maintain or validate security data.

    /C pirates: yeah, they'd have an easy time with JS-based security

  • colonel mustard (unregistered) in reply to rjnewton
    rjnewton:
    Sgt. Preston:
    akatherder:
    JavaScript would be almost as secure and easy to maintain (NOT secure and a nightmarish). You could only forward on success, so those with JavaScript disabled aren't automatically forwarded. You'd need a way to jumble the URL too. Someone could look at the list of IP addresses and Class C's, but there would be much easier ways to bypass this Fort Knox-like security than spoofing your IP address.
    This is a server-side ASP application written in VBScript. I presume that if you switched to JavaScript you would still be writing a server-side ASP application and not a client-side application. The list of IP addresses would not be exposed to the client regardless of which language you used.

    Excuse me, but what are you talking about--"server-side Javascript"?!?! I'm really hoping that this is subtle sarcasm, and I missed the tags. Who knows, perhaps there is such an animal, running in a server-side browser, perhaps? To date though, I have not seen a Javascript file called from HTML that I could not download and read in plain text with a simple get request, nor an obfusciated JS function that I couldn't decompile with a few newlines, some indentation, and substitution of meaningful variable names once the general drift of the fucntionality became evident.

    Use Javascript to ensure that required fields have content, yeah, but not to maintain or validate security data.

    /C pirates: yeah, they'd have an easy time with JS-based security

    um as joblini said:

    joblini :
    Both Javascript and VBScript can be executed on the server side, where the container is ASP, or on the client side, where the container is Internet Explorer.
  • Jon (unregistered) in reply to Unix Tool Geek
    Unix Tool Geek:
    you're aware that wget can happily ignore robots.txt if you pass it the right option, aren't you?
    That's OK; no-one reading the man page will ever find that option, even if they're looking for it.
  • Paolo (unregistered)

    The WTF is that there are: ip ip2 ip3

    I spotted immediately that they forgot ip1, and maybe also ip0 (if they want it to work with IPv6, of course)

  • (cs) in reply to mantis
    mantis:
    One time, I saw a Javascript authentication system in place for the partner extranet on the Web site of a major manufacturer of fingerprint scanners and biometric security equipment...

    ...snip...

    I'd feel really "secure" using their products. The Department of Homeland Security is one of their biggest customers.

    Biometric identification is joke. No one with half a brain in DHS actually use such systems to protect anything sensitive. Ever notice has no such system meets any of the FIPS guidelines? Hahaha, they wouldn't stand a chance against NIST.

  • MeNotYou (unregistered) in reply to Laurent
    Laurent:
    Can't belive it :) dammit.. I'd do myself ara-kiri (how the hell do you write that ?) if I'd write such as waste ;)
    ?? / ???? / harakiri

    To see the first 2 you have to have an os that doesn't suck (and this forum can handle other languages).

  • MeNotYou (unregistered) in reply to MeNotYou
    MeNotYou:
    ?? / ???? / harakiri
    Apparently the forum soft is garbage... WTF?

    CAPTCHA: burned - agreed, burn that thing!

  • (cs) in reply to real_aardvark
    real_aardvark:
    Well, I could be wrong, and to be frank it's too much of a pain to verify. However, AFAIK, the default number of concurrent connections on a listening socket -- well, that's really only "queued" connections, since the socket gets forked off on an actual connection -- is five. This is a generic TCP/IP default, not an IIS limitation.

    Now, I don't know whether IIS turns the default into a hard limit, and in fact I don't even know whether I've got any of this right. It does seem a little unfair to bash IIS on this basis, though. All popular Web servers are crap, in my opinion. (Apache 1.3 and Apache 2.x are simply crap in totally different ways.)

    It's not their fault. It's just in the nature of Web servers.

    The default backlog (i.e. queued but un-accepted requests on the listening socket) for Apache is 511. The default number of simultaneous connections (which is not the same thing, that's usually limited by the number of open files) is something like 4096.

    IIS has similar connection limits. But IIS on XP has a built-in limitation that prevents it from serving more than 5 connections at once, to prevent you from using XP in the manner in which they would like you to use Server 2003 Web Edition (which has no limits).

  • Bobby Brady (unregistered)

    Yeah - this is pretty typical of the website security I have seen some places try to pull off as being "secure"

    I have another good one - A benefits administrator (name withheld to protect their identity) has a Microsoft Access database sitting running their web portal - the database is stored under the virutal root of this site unencrypted and browsable from the web - all you need is IE and you can download the file. No filters to prevent it's download - and whats even worse about this you ask (asside from this obviously being a terrible security practice)? They are storing SSN's on it!!! And that's not all - the host for the site did not have a firewall (they didn't think anyone would bother poking around their puny little network so why bother?).

    I complained - but they pushed back and ignored my rants...

    Then one day the owner of this host came up to me and asked me "what's dameware"? (I can spare you the details of the rest of this part of the story).

    Needless to say - a Pix 501 was installed within the next couple of days - and the site was changed so that the MDB was at least not browsable from the outside world.

    Some kids these days... wtf!!

  • (cs) in reply to mantis
    mantis:
    I work on Web content management solutions. That company courted my company to do some work on their site, mainly cosmetic (which isn't what we usually do - we do large CMS/WCM builds), and I was assigned to reverse-engineer the existing functionality (which took about an hour, after the weeks it took to obtain server access). We ended up doing very little, because the company had a difficult internal IT team, a tight budget, and high turnover (a different POC every month for their account with us!), and -- in my opinion -- because we quickly recognized the account to be a liability minefield.

    The name of the company is the same as the common name of the blood test that is done to check for incompatibility between an organ transplant donor and a recipient.

    Nice analogy. It took me a bit of searching to figure it out. I had to integrate some of their hardware into our applications, and their API was full of WTFs. They merged with a competitor about 2 years ago, so that may explain their instablility at the time. The name of the company they merged with is a homonym for a part of the female anatomy (once it's broken, it's gone forever).

  • barf (unregistered) in reply to savar
    savar:
    I like how you have to scroll past dozens of existing comments to find the "Add Comment" link.

    Anyway, this is a nice WTF. I read the first part (ip) and thought "ehh, not surprsing"....snip

    REPLY and "QUOTE" work just fine, genius! :P

  • Dennis (unregistered) in reply to Jimmie
    Jimmie:
    Uhm... ok not even talking about firewalls, whats so hard about a one line SQL statement? (psuedo code, since I don't do that ASP garbage)
    SELECT COUNT FROM VALID_IPS WHERE IP_ADDR EQUALS ASP_VALUE_OF_IP
    
    if(count == 1){
      //yee haw
    } else {
      //redir goatse
    }

    Of course, IP_ADDR is unique in your table or you should do

    count >= 1

  • Milton (unregistered)
    Comment held for moderation.

Leave a comment on “The Insanity Defense”

Log In or post as a guest

Replying to comment #:

« Return to Article