Where Science Went Wrong (hilarious web site)

In article ,
Jonathan Schattke wrote:

There's nothing incredibly bad about this. It's perfectly normal to
error when you try to load a URL that doesn't exist. A really good
system might notice that the URL is very close to one that does exist,
and redirect you, but failing to do so does not make a system bad. This
particular system's failure mode is not pretty, and it really should be
more graceful, but that's just slightly bad, not "incredibly bad".

The point is not the error, but that it was unhandled, even though
calling for a nonsense index is a typical attack.

I don't think there's any particular link between unhandled exceptions
and attacks. You have a top-level catch-all handler which reports the
error to the client, and that's that.

really, the host script should have vetted for sanity before sending it
on to the data server.

Why? With any half-competent data layer, a good index will work and a
bad index will return an error. If your data layer can be exploited by
giving it a bad ID number, then your problem lies in the data layer.

The URL in question contains bad data in a format that's unexpected.
This caused the code to throw an exception (which, I must mention, is
the sort of thing that exceptions are *for*) which in turn causes the
page to return an error. The only bad thing I can see here is that the
error page is not at all user-friendly, and, well, welcome to the web....

--
Mike Ash
Radio Free Earth
Broadcasting from our climate-controlled studios deep inside the Moon

On Sun, 16 May 2010 08:46:58 -0400, Mike Ash wrote:

In article ,
Gene Wirchenko wrote:

On Sat, 15 May 2010 13:56:37 +0100, Martin Brown
wrote:

[snip]

Don't you just love MickeySoft product reliability!

It appears to be an application programmer error.

It is, in fact, because there's an apostrophe at the end of the URL.
Remove that, and the URL works.

I see. I think that I would still think of it as probably being
an app programmer error. The code was something like
entryIDstr=endofURL
entryID=strtoint(entryIDstr)
and should have been something like
entryIDstr=endofURL
if !isnumeric(entryIDstr)
displayerrorpage("Bad entryID")
stop page processing
entryID=strtoint(entryIDstr)

Sincerely,

Gene Wirchenko

In article ,
John F. Eldredge wrote:
On Sun, 16 May 2010 06:53:23 -0600, noRm d. plumBeR wrote:

Mike Ash wrote:


Which shows what incredibly bad software is supporting the thing.

The scary part is that it isn't all that unusual.

The tinyurl link worked OK.

As far as the linked-to page is concerned, while I feel sorry for the two
airmen who were blown up (one survived, one didn't), it sounds like they
didn't fully appreciate the risk. If I found that an enclosure was full
of a fuel/air mixture, I wouldn't sit down at the edge of the enclosure
to wait for my ride, I would get as far away from it as possible. I did
once have to deal with a propane leak inside a factory; I opened several
overhead doors for ventilation (manually, not using an electric hoist),
then got outside as quickly as possible. Had the concentration been as
high as what the two airmen found, I wouldn't have taken the time to open
the doors, I would just have run for my life.

When you have a maxed out concentration of some combustible gas in
air; do you ventilate (and bring in oxygen) or contain it (keeping
it in one place, only slowly to seep out).

At least with propane, gasoline and such, the maximum saturation in air
would be rapidly depleted of oxygen if it blew up, thereby dampening the
explosion damage. It will become a two-stage fire; first an explosion
and then an inrush fire when the oxygen gets back to the flame.

Just a question.

-- mrr

On May 16, 8:12*pm, Mike Ash wrote:

Why? With any half-competent data layer, a good index will work and a
bad index will return an error. If your data layer can be exploited by
giving it a bad ID number, then your problem lies in the data layer.

Expected behavior is that *any* invalid URL gives a nice neat 404
error.

Nothing is _ever_ passed on to any code which can cause an unhandled
exception, because the results of an error are, by their very nature,
unpredictable. They can potentially be exploited for attack purposes,
or they can have denial-of-service results just by accident - bringing
the system down, or causing an infinite loop.

In this case, the design error is to allow the untrusted outside world
to make a database request directly. Instead, there should be a layer
of bombproof code that parses URLs, sorts out valid ones from invalid
ones, and then, once it gets a valid one, passes on the request to the
database engine.

Which, of course, could still return information to the effect that
the sought-after item is not found, because the insulating layer can't
do the database's job.

John Savard

Mike Ash wrote:

In article ,
"noRm d. plumBeR" wrote:

Mike Ash wrote:

In article ,
Gene Wirchenko wrote:

On Sat, 15 May 2010 13:56:37 +0100, Martin Brown
wrote:

On 15/05/2010 12:55, William December Starr wrote:
In ,
Martin said:

The guy with the spanner was just a bit unlucky and a victim of
Murphys Law - the spanner really did fall where it could do most
damage.

Could've been worse. Could have been in a Titan II missile silo.

(Okay, that was actually just the socket from a socket wrench, not the
whole tool. It still sufficed though:http://tinyurl.com/2u6ly2,
http://www.encyclopediaofarkansas.ne...detail.aspx?en
try
ID=2543'.)

True to form where Murphy's Law is referenced that URL said:

smirk

Error converting data type nvarchar to int.
[snip]
An unhandled exception was generated during the execution of the current
^^^^^^^^^^^^^^^^^^^
web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.
[snip]
Version Information: Microsoft .NET Framework Version:2.0.50727.3603;
ASP.NET Version:2.0.50727.3082

Don't you just love MickeySoft product reliability!

It appears to be an application programmer error.

It is, in fact, because there's an apostrophe at the end of the URL.
Remove that, and the URL works.

Which shows what incredibly bad software is supporting the thing.

The scary part is that it isn't all that unusual.

There's nothing incredibly bad about this. It's perfectly normal to
error when you try to load a URL that doesn't exist. A really good
system might notice that the URL is very close to one that does exist,
and redirect you, but failing to do so does not make a system bad. This
particular system's failure mode is not pretty, and it really should be
more graceful, but that's just slightly bad, not "incredibly bad".

We'll need to disagree on this, Mike. In my view, any piece of
software that tells prospective hackers what kind of error they've
caused and gives them additional useful information qualifies as
"incredibly bad".

Error converting data type nvarchar to int.
[snip]
An unhandled exception was generated during the execution of the current
^^^^^^^^^^^^^^^^^^^
web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.
[snip]
Version Information: Microsoft .NET Framework Version:2.0.50727.3603;
ASP.NET Version:2.0.50727.3082


--
"Vengeance is mine" saith Montezuma

On May 15, 7:17 am, (William December Starr) wrote:

That's not to say that "big oil is a monolithic bloc" isn't
fallacious, but I think it's a lot _closer_ to being one than is the
"environmental movement" (when speaking or acting on matters that
affect the industry as a whole, of course).


The environmental movement, as regards lobbying of our
representatives, is pretty much a monolithic block when it comes to
nuclear energy generation. They are utterly, reliably consistent on
that topic.

On Mon, 17 May 2010 03:24:51 -0500, David Mitchell
wrote:

On Sat, 15 May 2010 01:04:29 -0500, David Mitchell wrote:

On Fri, 14 May 2010 14:06:58 -0700, Gene Wirchenko wrote:

I just checked the browse tab I have open to see if chapter 21
has been released yet. I have done this too many times already.

No, it has not been. And if it were, I would be crying for
chapter 22.

I've just signed up, so I can receive a story alert. I'll post here
if/when that happens.

Chapter 21 is up!

http://www.fanfiction.net/s/5782108/21/

Yup. I am already waiting for chapter 22.

Sincerely,

Gene Wirchenko

On 5/17/2010 2:56 PM, Gene Wirchenko wrote:
On Mon, 17 May 2010 03:24:51 -0500, David Mitchell
wrote:

On Sat, 15 May 2010 01:04:29 -0500, David Mitchell wrote:

On Fri, 14 May 2010 14:06:58 -0700, Gene Wirchenko wrote:

I just checked the browse tab I have open to see if chapter 21
has been released yet. I have done this too many times already.

No, it has not been. And if it were, I would be crying for
chapter 22.

I've just signed up, so I can receive a story alert. I'll post here
if/when that happens.

Chapter 21 is up!

http://www.fanfiction.net/s/5782108/21/

Yup. I am already waiting for chapter 22.

Get a jump on the crowd, start waiting for chapter 23.

--
Murphy was an optimist.

In article ,
David Mitchell wrote:
Chapter 21 is up!

http://www.fanfiction.net/s/5782108/21/

And Harry seems to be putting into practice the ideas mentioned in
the article linked from the root post of this thread.

--
David Goldfarb |"Federico Fellini brought his own security to
| tonight's show...and they were six of the
| toughest clown midgets I've ever seen."
| -- Billy Crystal

David Goldfarb wrote:
David Mitchell wrote:
Chapter 21 is up!

http://www.fanfiction.net/s/5782108/21/

And Harry seems to be putting into practice the ideas mentioned in
the article linked from the root post of this thread.

"I'd better leave it at that." Heh.

Dave
--
\/David DeLaney posting from "It's not the pot that grows the flower
It's not the clock that slows the hour The definition's plain for anyone to see
Love is all it takes to make a family" - R&P. VISUALIZE HAPPYNET VRbeableBLINK
http://www.vic.com/~dbd/ - net.legends FAQ & Magic / I WUV you in all CAPS! --K.