|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
IIS 7 default settingThe "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" <howdy0***@yahoo.com> wrote in message Hi,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. 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 Show quoteHide quote "Ken Schaefer" <kenREM***@THISadOpenStatic.com> wrote in message news:#crB79yOGHA.1192@TK2MSFTNGP11.phx.gbl... > "Howard" <howdy0***@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 > > 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 Show quoteHide quote "Ken Schaefer" <kenREM***@THISadOpenStatic.com> wrote in message news:%23crB79yOGHA.1192@TK2MSFTNGP11.phx.gbl... > "Howard" <howdy0***@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 > > 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 Show quoteHide quote "Howard" <howdy0***@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" <kenREM***@THISadOpenStatic.com> wrote in message : news:%23crB79yOGHA.1192@TK2MSFTNGP11.phx.gbl... : > "Howard" <howdy0***@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 : > : > : : Inline.
"Ken Schaefer" <kenREM***@THISadOpenStatic.com> wrote in message In 2006 if you are vulnerable to this type of attack SQL Injectoin is 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. probably the least of your worries. > The attacker may be able to run queries against system tables to get lists Keyword here is 'guess'.> 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 Yes but element enumeration is 10 x more difficult resulting in more time > properly, or generates an error. and a higher probability of them moving to an easier target. > David Litchfield (IIRC) has a paper on running blind SQL Injection Yes he does, however most of the times blind injection filters through the > attacks. 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 I agree, also if it's a 3rd party open source app all bets are off (the > 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). schema - and code is freely downloadable). > Hiding error messages is just "security through obscurity". Obscurity is Actually this is incorrect. You're not hiding data if there's no > 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. > 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'' Show quoteHide quote > "Howard" <howdy0***@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" <kenREM***@THISadOpenStatic.com> wrote in message > : news:%23crB79yOGHA.1192@TK2MSFTNGP11.phx.gbl... > : > "Howard" <howdy0***@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 > : > > : > > : > : > > 
Other interesting topics
Word 2003 cannot save files to http://host/site/folder/file.doc
Error 401.1 Post Image Data to Server from embedded user control in IE Application Pool without Anonymous Access Web services difficulties file system object List of all SSL pages NT Authentication - 2nd challenge/response HTTP to HTTPS specified request cannot...from current Application IIS 5 belonging to domain? |
|||||||||||||||||||||||
