Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP OWASP Plan - Strawman Ashish Popli Aspiring OWASP Member Microsoft

OWASP 2 Web Application Security  Web Application Attacks  Common Countermeasures  How Microsoft-IT does Application Security?

OWASP What we will discuss today Attack Patterns  Injection Something  Cross Site Scripting  SQL Injection  File Canonicalization  Replay Something  One Click/CSRF/  Crypto Bugs  Overflow Something  Integer Overflow Countermeasures  Anti-XSS Library  Input Validation  ViewStateUserKey  Nonce  C# Checked Keyword 3

OWASP What is Cross-Site Scripting?  A technique that allows attackers to:  Appear to rewrite the text of your web site  Abuse the user’s trust in your website to…  Steal Web session information and cookies  Hijack client sessions  Potentially access the client computer

OWASP XSS Attack Patterns  XSS attacks can be classified in two categories:  Persistent Generally affects web-based applications (e.g., message forums) which persist user-supplied data for later display  Non-Persistent Generally affects web-based applications which echo data back to the client who supplied it

OWASP What is SQL Injection?  SQL injection is:  The process supplying carefully crafted input to alter (or create) SQL statements  Can be used by malicious users to compromise confidentiality, integrity or availability of your application:  Probe databases  Bypass authorization  Execute multiple SQL statements  Call built-in stored procedures

OWASP Defending Against SQL Injection  Abandon Dynamic SQL  Use stored procedures or SQL parameterized queries to access data  Can have SQL Injection in stored procedures  Sanitize all input  Consider all input harmful until proven otherwise – test for valid data and reject everything else  Run with least privilege  Never execute as “sa”  Restrict access to built-in stored procedures  Do not display errors directly from database.

OWASP What is One-Click Attack?  Site offers persistent sign-in option  Cookies or Windows Authentication  Victim user navigates to (or opens) an HTML page – perhaps a “once in a lifetime offer”  One or more actions are carried out using the trust of the victim user which is completely unsuspecting to that user

OWASP Defending Against One-Click Attack  Browser’s cross-frame security limits this to a “write- only” attack  Concept for defense: require a data element in the request which the attacker can’t supply  (Overkill) Re-authenticate the user  Can ask for confirmation  Check Referrer field  document.location or window.open() don’t post Referrer

OWASP Defending Against One-Click Attack (cont.)  Classic ASP  Generate a unique session ID once user authenticates, encrypt it and bind it to each response sent to user  In.Net 1.1 & 2.0 use ViewStateUserKey  Value assigned to it must be unique to the current user  This value is used as a factor in the ViewState MAC

OWASP Defending Against One-Click Attacks override protected void OnInit(EventArgs e) { //... ViewStateUserKey = User.Identity.Name; //... }

OWASP What are Canonicalization Issues  There is usually more than one way to name something  Alternate representations exist for:  File names  URLs  Devices (such as printers)  Malicious users may exploit code that makes decisions based on file names or URLs

OWASP Integer Overflow  Set of common integer arithmetic mistakes that can lead to  Overflow and underflow error  Signed versus unsigned errors  Truncation  Lead to buffer overflows and logic errors

OWASP ASP.NET C# checked keyword  placing all the calculations in a checked block to turn on overflow checking, then wrap the whole thing in a try block that catches OverflowException.

OWASP ASP.NET C# checked keyword overflow checking works for simple arithmetic operations (addition, subtraction, and multiplication) uint a = uint.MaxValue; uint c = checked(a * 2);

OWASP C# checked keyword  Don't use the unchecked/checked keywords unless an overflow condition is possible.  Use unchecked when you expect overflow but want to ignore it.  Use checked where it is a possible error condition which you want to catch.  Turn on overflow checking globally in debug builds to detect bugs.  Turn off overflow checking globally in release builds for efficiency.

OWASP Replay Attack User Vulnerable Application Attacker Request Attacker gets hold of a Valid Request Request

OWASP Security Development Life Cycle for IT High Level Approach -Identify Threats at Design Time -Build Threat Models -Perform Security Code Reviews at Develop Time -Manual and Power Assisted -Perform Deployment Reviews at Production Time -Manual and Power Assisted

OWASP Security Development Life Cycle for IT High Level Approach -Do not allow applications to go in production if -Threat Model has not been built -High Severity Bugs are not fixed -Facilitate Awareness -Provide Secure Application Development Training -Hold Application Teams Accountable -Reward for good results.

OWASP Security Development Life Cycle for IT What we have learnt -Nothing works without executive buy in -“Security is not a tax” -A parallel security process is a must -Developer Awareness goes a long way -Use tools cautiously -Do not rely exclusively on tools -Machines still cant think like humans