• (disco)

    I was frist expecting episode 2, and now I am mildly upset.

    Though, god exception handling makes me feel a bit better.

    [...] and was getting ready to leave, when something else caught his attention.

    There was a single breakpoint in the code, right on the Server.Transfer line.

    Not noticing the breakpoing not breaking the code already deserves to be a WTF.

  • (disco)

    Obviously, there's a better way to do this - the error page doesn't have to expose the exception to the outside world, and you could keep all the exception detail without exposing it - but the last paragraph makes it sound like the consultant is wrong to say that you shouldn't expose this information.

    It's part of many security best practices not to expose this information. Finding error/exception cases is often part of figuring out how to break a system. If you're writing something for use by the US Government, it's a violation of the DISA guidelines to expose it, so even if you think it's daft to have that rule, it's not crazy that someone would want to follow it. It's just crazy that they don't know that you can keep detail for yourself without displaying it on an error page.

  • (disco) in reply to Gawaine

    Gawaine, MS saw the need for custom error pages without stacktrace, too. There is a single line somehwere, which hides the Stacktrace. The default as seen here is a developer feature, so that errors while developing can be found fast.

  • (disco)

    "security"

    riiight.

    Manuel, here; you need this more than I do today

    http://galleryplus.ebayimg.com/ws/web/180878882972_1_0_1/1000x1000.jpg

  • (disco)

    Set this value in Machine.config to avoid exposing debug information on production servers:

    <configuration>
    <system.web>
          <deployment retail=”true”/>
    </system.web>
</configuration>
  • (disco)

    Actually the consultant should get a credit here. Code traces really shouldn't be exposed to outside. However there is a better way to handle the error instead of simply discarding the error message.

  • (disco) in reply to leeyc0

    Incorrect.

    The consultant should have known that by default this information is only exposed in the development environment. And any programmer should have known that generating an HTTP response in an exception constructor is madness

  • (disco) in reply to Tim_Robinson
    Tim_Robinson:
    And any programmer should have known

    what part of consultant confused you? ;-)

  • (disco) in reply to leeyc0
    leeyc0:
    Actually the consultant should get a credit here. Code traces really shouldn't be exposed to outside. However there is a better way to handle the error instead of simply discarding the error message.

    Credit for doing something conceptually right? This isn't fucking preschool, you shouldn't get a gold star for being incompetent.

  • (disco) in reply to leeyc0
    leeyc0:
    Actually the consultant should get a credit here. Code traces really shouldn't be exposed to outside. However there is a better way to handle the error instead of simply discarding the error message.

    The consultant only gets a credit if Manuel didn't already know that. And he loses at least three credits for the awful and unnecessary "solution".

  • (disco)

    I don't know how they do it in ASP, but in soviet PHP, the production apache setup omits publicly visible errors from output, while on the development environment, people can actually fucking see what they're doing.

    The consultant is WTF for thinking this question of security vs maintainability hadn't been answered before. I hope he was a recent graduate.

  • (disco) in reply to leeyc0
    leeyc0:
    Actually the consultant should get a credit here. Code traces really shouldn't be exposed to outside. However there is a better way to handle the error instead of simply discarding the error message.

    In the interests of world peace, let's kill all the humans. World peace achieved.

  • (disco) in reply to Shoreline
    Shoreline:
    In the interests of world peace, let's kill all the humans. World peace achieved.

    Or not.

    http://en.wikipedia.org/wiki/Gombe_Chimpanzee_War

  • (disco)
    [image] This didn't happen to me before. Is this some DNS nonsense that my work computer is just now catching up to, or what?
  • (disco) in reply to hungrier
    hungrier:
    This didn't happen to me before. Is this some DNS nonsense that my work computer is just now catching up to, or what?

    It's been happening for the last few articles. It is indeed DNS related, because they're serving the images from a subdomain.

    Relevant discussion starts here.

  • (disco) in reply to Simen

    There you go again, proposing a perfectly reasonable solution to the problem that in no way involves a wooden table.

  • (disco) in reply to Keith
    Keith:
    It's been happening for the last few articles. It is indeed DNS related, because they're serving the images from a subdomain.

    Relevant discussion starts here.

    I know, I was in that thread. I'm just surprised that it's failing now where it was working for me on that subdomain before. I tried testing it with yesterday's article, and sure enough when I force-refreshed the image it gave me a DNS error.

    So the wtf is likely with my work's ISP.

  • (disco) in reply to hungrier
    hungrier:
    This didn't happen to me before. Is this some DNS nonsense that my work computer is just now catching up to, or what?

    You're not missing too much, though.

  • (disco)

    Um... 'customerrors mode="On"' anyone?

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    You're not missing too much, though.

    He's missing a beard.

  • (disco) in reply to Keith
    Keith:
    He's missing a beard.

    It has the makings of a damn good one, too.

  • (disco) in reply to boomzilla
    boomzilla:
    It has the makings of a damn good one, too.

    It's quite perky.

  • (disco)

    ...and now it works.

    And wow what a beard.

  • (disco) in reply to Anonymous
    Anonymous:
    Not noticing the breakpoing not breaking the code already deserves to be a WTF.

    Seconded.

  • (disco) in reply to Keith
    Keith:
    It's been happening for the last few articles. It is indeed DNS related, because they're serving the images from a subdomain.

    Relevant discussion starts here.

    Yeah, my work DNS just caught up today.

  • (disco)

    Multiple WTFs here.

    Of course, messing with exceptions.

    And then, not knowing that you can change the web.config to handle this.

    Also, not handling the Application_Error event in the Global.asax class to clear the errors.

    But mainly, this:

    As expected, the error page appeared as soon as he clicked "Debug".

    Any competent developer changes their Start Action to "Don't open a page. Wait for a request from an external application."

    Also, congrats to @Maciejasjmj/macie letter soup on the writing gig. I really enjoyed today's article. You let the WTF actually be the WTF. :grinning:

  • (disco)

    Sounds a lot like the mindset of the original developers of the code I have to maintain... Turn off PHP's errors, AND warnings (even in development), because well, why fix the code?--it's only a warning! Use '@' to suppress exceptions, and if there is some error, just redirect to the home page, because why would you want to inform your users that something went wrong, and their request wasn't acknowledged? Just leave them clueless instead.

  • (disco)

    The TRWTF is using the overload that takes a message!!! (NOT!)

    Even worse, this has nothing to do with the exception being thrown....it occurs when the exception is created!

  • (disco) in reply to Michael
    Michael:
    Turn off PHP's errors, AND warnings (even in development), because well, why fix the code?--it's only a warning! 
    error_reporting(E_ALL);
ini_set("display_errors", 1);

    Top of my master include file, tyvm...

    Sometimes, it's the developer, not the language. Granted, in case of PHP it's mostly the language.

    Filed under: Covering for @Arantor

  • (disco) in reply to Onyx

    I'd be okay with it, if only they'd have handled errors properly. Instead they leave the user clueless, and other developers confused.

  • (disco)

    I've seen this model before. We had a third party product that was developed this way and basically, their error handling was:

    try { operation; } catch (Throwable t) { };

    Every single operation that could fail was wrapped in this, including null pointer problems and user mis-inputs. The code would just keep muddling along and who knows what you would get when it actually returned.

    But, "Hey, no problem, because nothing on computers ever fails these days." And, "Well, even if I were to grant it might fail (which it never would) sending an error message to the user is bad."

    And that was just the most recent third part product.

    There was another years ago that ignored all database errors (before exceptions, you had to check the error code). The customer lost an entire day's work because a table was full; the program ignored all the "table full" codes and dumped the day's batch full data in the bit bucket...then deleted the batch.

  • (disco)

    "Visible stacktraces OMG" is a pain in the ass when the security auditors come up with it, but it at least has some merit. In rare situations it can give a hacker insight into a vulnerability. The one you've really got to be careful for is "The ASP.NET version number is visible in the HTTP Server header. Panicpanicpanic". Good job catching that, security consultant who bills per-issue

  • (disco) in reply to mruhlin

    Two of our customers have had audits done of our web app. In both cases the auditors fussed about "potential sql injection vulnerabilities."

    I told the customer "if the auditor can actually find an actual vulnerability, please let me know so I can fix it." Progress' ODBC driver is wacky[1]. For one thing, it doesn't support comments, so the old or 1=1;' trick simply doesn't work--I've tried it.

    [1] in this case, that's actually a good thing.

  • (disco) in reply to FrostCat

    Can they get your app to send invalid SQL to the DB? Then they've got a bug. Even if it's not exploitable (and you probably cannot guarantee that) it is still a valid bug.

  • (disco)

    What we do, when we get an uncaught exception at the top level of the code, is to generate an issue number, include the issue number in the details we write to our system logs, then include the issue number in the "something went pear-shaped, contact support" message we display to the user.

  • (disco) in reply to Jeff_Dege
    Jeff_Dege:
    What we do, when we get an uncaught exception at the top level of the code, is to generate an issue number, include the issue number in the details we write to our system logs, then include the issue number in the "something went pear-shaped, contact support" message we display to the user.

    Every single time? So when an idiot user tries the same thing over and over and over again, you end up with 50 "issues"?

  • (disco) in reply to PleegWat
    PleegWat:
    Can they get your app to send invalid SQL to the DB?

    I don't think they tried--they noticed we weren't using parameterized queries, which, sadly, ADODB doesn't seem to support, so as far as I can tell, they just said "oh, possible SQL injection" without attempting to verify. I did some testing, although I wouldn't call myself an expert in that area, and was unable to find a way to actually break things.

    The other consultant found a potential XSS vuln, but--again, as far as I can tell--they didn't test it. As far as I can tell, there's not an actual vuln, because the vector uses URL Encoding. I might post on the Coding Help sub-forum at some point because I'd like to either fix the problem or tell my customer it's not one, and I don't know enough to be able to tell which.

  • (disco) in reply to chubertdev
    chubertdev:
    Any competent developer changes their Start Action to "Don't open a page. Wait for a request from an external application."

    Why? 99.9% of the time, I'm going to be using F6 to build, and refresh on the tab that I already have open to the development server. The .1% of the time is when I'm starting to work on a project for the day, and having the browser automatically open to the address where my site is hosted (local hostname or random IIS Express port) is convenient when I hit ctrl+F5.

    I suppose it would make debugging slightly faster (F5) since I don't have to close out the automatically opened tab to get to the page I wanted to debug (roughly 500ms saved per debug launch); but that time is actually saved because it takes more than a few seconds to restart an ASP.NET application - meaning, eventhough I closed that tab, having that tab hit the page right after the build started the process of restarting the application. So it's actually time saved.

    I fail to see how this makes me not "competent."

  • (disco) in reply to FrostCat
    FrostCat:
    I don't think they tried--they noticed we weren't using parameterized queries, which, sadly, ADODB doesn't seem to support, so as far as I can tell, they just said "oh, possible SQL injection" without attempting to verify. I did some testing, although I wouldn't call myself an expert in that area, and was unable to find a way to actually break things.

    That makes sense. They may be using an automated scanning tool of some form too.

    Your initial reply seemed to indicate 'you can't inject because adodb only does single queries' which IMNSHO doesn't fly.

  • (disco) in reply to chubertdev

    We do this only for defect messages - an uncaught exception is a programming error that needs to be tracked down and fixed.

    We don't create issue numbers for handled exceptions. Not even the ones that generate "don't do that" messages for the user.

  • (disco) in reply to PleegWat
    PleegWat:
    Your initial reply seemed to indicate

    Oh--no, like I said, the common techniques of using comments don't work. The particular driver treats them as a syntax error.

  • (disco) in reply to Jeff_Dege
    chubertdev:
    Jeff_Dege:
    issue number
    Every single time?

    Generating an issue in issue tracking system would sure be overkill, but I don't think that is (and hope it isn't) what was meant. But just a number that gets written to the output and also to the log, so the reported problem can be quickly correlated to the relevant part of the server error log makes a lot of sense.

  • (disco) in reply to FrostCat
    FrostCat:
    using comments

    You don't need comments to disable password or permission check. If ' or 1 = 1; -- does not work, the ' or 1 = 1 or ' is next in line.

    PleegWat:
    only does single queries

    And even if it only did single queries too, it would only prevent injections that are trying to damage the database (and even then not all of them; if you get injection to an update statement…). Injections that simply disarm password or permission checks don't need multiple statements.

  • (disco) in reply to boomzilla
    boomzilla:
    Chimpanzee War

    I wonder if they employ (smirk) Gorilla Tactics! (wheeze)

  • (disco) in reply to Shoreline
    Shoreline:
    I wonder if they employ (smirk) Gorilla Tactics! (wheeze)

    That joke was ape-palling...

  • (disco) in reply to Bulb
    Bulb:
    You don't need comments to disable password or permission check.

    I was unable to make that work either.

  • (disco) in reply to Keith
    Keith:
    That joke was ape-palling...

    Would you guys quit monkeying around?

  • (disco) in reply to mott555
    mott555:
    Would you guys quit monkeying around?

    Oh, lemur them alone. It's just some harmless fun.

  • (disco) in reply to FrostCat

    Seems like the best security scanning process is to put white-box scanners in the hands of the devs so they can be informed while they're working, but use black-box scanners for the actual audit, so if the devs decline to fix a real problem it'll be proven by exploiting it. Does that sound right?

    (I'm actually trying to get a handle on security scans in general for work, so a real answer would be useful)

  • (disco) in reply to Yamikuronue

    I guess. These audits were done for our customers, by 3rd parties, so all I know is I was given a report which lists several potential vulnerabilities, several of which I was immediately able to determine aren't real problems, and some of which I should fix, and so on.

Leave a comment on “Exceptionally Secure”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article