Inline.

"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:<uJHK0WBPGHA.532@TK2MSFTNGP15.phx.gbl>...

> Some SQL Injection attacks (for example, logging on by using the

> archtypical: ' OR 1=1 in the password field) require no knowledge of

> field/tablenames at all.

In 2006 if you are vulnerable to this type of attack SQL Injectoin is
probably

the least of your worries.

> The attacker may be able to run queries against system tables to get lists

> of databases, tables, and fieldnames.

>

> The attacker may be able to guess fieldnames (e.g. often a commerce site

> will have tables similar to Products, Customers etc) based on table names

Keyword here is 'guess'.


> The attacker can determine field types based on whether the site responds

> properly, or generates an error.

Yes but element enumeration is 10 x more difficult resulting in more time
and a higher

probability of them moving to an easier target.

> David Litchfield (IIRC) has a paper on running blind SQL Injection
> attacks.


Yes he does, however most of the times blind injection filters through the
95%

Of the script kiddies running automated tools like nummish's Absinthe of
x90.org (iirc)

although I think the latest version supports Blind SQL now.

> Lastly, if the product is a 3rd party product (e.g. you are running phpBB
> or

> ASPForum or something) then the attacker doesn't need to know anything
> about

> error messages if an exploit has already been discovered (or a tool knows

> the necessary exploit details).

I agree, also if it's a 3rd party open source app all bets are off (the
schema -



and code is freely downloadable).

> Hiding error messages is just "security through obscurity". Obscurity is

> good, but it's not real security. The underlying vulnerability is still

> there - you're just trying to hide it. Unfortunately it doesn't stop you

> being hacked.

>

Actually this is incorrect. You're not hiding data if there's no
vulnerability,

you are adding another layer of security by deliberately not helping the
attacker with

helpful error messages such as :

Unenclosed quotaion mark in query 'FROM Table Bar WHERE FOO=input''

> "Howard" <howdy0909@yahoo.com> wrote in message
> news:%23%23Oaun2OGHA.3264@TK2MSFTNGP11.phx.gbl...
> : The attacker would not know the name of the data table and column thus
> : unable to craft a malicious sql script.
> : Sure, they can always guess or run a dictionary attack but it's very
> : unlikely.
> :
> : Right?
> :
> : Wade,thanks for taking my suggestion.
> :
> : Howard
> :
> : "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
> : news:%23crB79yOGHA.1192@TK2MSFTNGP11.phx.gbl...
> : > "Howard" <howdy0909@yahoo.com> wrote in message
> : > news:%23Tn6PsxOGHA.456@TK2MSFTNGP15.phx.gbl...
> : > : The "Send errors to browsers" property under ASP debugging settings
> : > should
> : > : be turned off by default. Like in asp.net no debug info should be
> send
> : > to
> : > : the browser unless it is explicitly turned on.
> : > : This will prevent many attacks, such as sql injection.
> : >
> : >
> : > Hi,
> : >
> : > SQL Injection attacks occur because of vulnerabilities in the
> application
> : > *not* becase error messages are sent to the client. If your
> application
> : > isn't vulnerable, then it doesn't matter what messages get sent to the
> : > client. If your application is vulnerable, you'll still get hacked no
> : > matter
> : > whether you disguise your error messages or not.
> : >
> : > But you are correct that, by default, detailed error message should
> not
> be
> : > sent to remote clients by default.
> : >
> : > Cheers
> : > Ken
> : >
> : >
> :
> :
>
>