iis 7 default setting

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.
Howard

"Howard" wrote in message : 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

Hi Ken and Howard,
We've got this on our list of things to do. By the time IIS 7 ships (and maybe beta 2), this will be off by default in IIS 7.
Thank you, -Wade A. Hilmo, -Microsoft
"Ken Schaefer" wrote in message

"Howard" wrote in message : 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

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" wrote in message

"Howard" wrote in message : 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

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.
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
The attacker can determine field types based on whether the site responds properly, or generates an error.
David Litchfield (IIRC) has a paper on running blind SQL Injection attacks.
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).
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.
Cheers Ken
"Howard" wrote in message : 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" wrote in message : : > "Howard" wrote in message : > : > : 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 : > : > : :

Inline.
"Ken Schaefer" wrote in message

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" wrote in message : 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" wrote in message : : > "Howard" wrote in message : > : > : 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 : : : :