M ore Secure Online Services Powered by the Microsoft SDL

1. More Secure Online Services Powered by the Microsoft SDL Bryan Sullivan Security Program Manager, SDL Microsoft

2. What We Will Cover • Brief background on the Microsoft Security Development Lifecycle (SDL) • SDL processes and tools currently used to protect online services • Preview future SDL online initiatives

3. Session Prerequisites • Knowledge of basic web application vulnerabilities • Familiarity with web programming concepts • ASP.NET is a plus Level 300

4. SDL BackgroundWhat is the SDL? Education Tools Process

5. SDL BackgroundSQL Server Before the SDL

6. SDL BackgroundSQL Server After the SDL

7. Online Service RequirementsOWASP Top Ten • Cross-Site Scripting • Injection Flaws • Malicious File Execution • Insecure Direct Object References • Cross-Site Request Forgery • Information Leakage • Broken Authentication • Insecure Cryptography • Insecure Communications • Failure to Restrict URL Access

8. Cross-Site Scripting (XSS)Input Validation • Ensure the data is what the application expects • Format • Length • Regular expressions (can) work great here • System.Text.RegularExpressions.Regex • System.Web.UI.WebControls.RegularExpressionValidator

9. Cross-Site Scripting (XSS)Use of Regular Expressions • Incorrect use of Regex: if (Regex.IsMatch(userInput, "[<>]")) // reject input • Correct use of Regex: if (Regex.IsMatch(userInput, “^[a-zA-Z]{1,9}$")) // accept input

10. Cross-Site Scripting (XSS)ValidateRequest • Page directive <%@ Page ValidateRequest="true"%> • Web.config setting <configuration> <system.web> <pages validateRequest="true" /> </system.web> </configuration> • More of a defense-in-depth measure

11. Cross-Site Scripting (XSS)Encode Output • Harder than it sounds! • 7 different cases • Plain HTML • HTML attribute • URL • JavaScript • VBScript • XML • XML attribute • Use Microsoft AntiXSS Library

12. Demonstration 1 Microsoft AntiXSS Library

13. Cross-Site Scripting (XSS)Static Analysis • XSSDetect Code Analysis Tool • Analyzes source-to-sink dataflow • Standalone or integrated into Visual Studio

14. SQL InjectionUse Stored Procedures • Bad code: SqlCommand command = new SqlCommand( "SELECT * FROM Customers WHERE CustomerId = '" + customerId + "'"); • Good code: SqlCommand command = new SqlCommand("GetCustomer"); command.CommandType = CommandType.StoredProcedure; command.Parameters.Add(new SqlParameter("@customerId",customerId);

15. SQL InjectionAvoid EXEC @sql • Moving the string concatenation to the stored proc code still leaves you vulnerable… EXEC ('SELECT * FROM Customers WHERE CustomerId = ''' + @CustomerId + ''') • The only approved use of EXEC is to call other stored procedures

16. SQL InjectionRemove Database Privileges • Allow only EXECUTE privileges on the necessary stored procedures • All other privileges on all objects must be removed • This is defense in depth

17. Cross-Domain ScriptingSame Origin Policy • Two frames/windows can only communicate with each other if they have the same origin • Origin is defined as having the same: • Domain • Port • Protocol • Also applies to XMLHttpRequest

18. Cross-Domain ScriptingSame Origin Policy Example • If my page is http://www.mysite.com/foo/bar.aspx Take a guess… Take a guess… Take a guess… Take a guess… Take a guess…

19. Cross-Domain ScriptingDocument.Domain • Two cooperating pages can lower their domain so they can talk to each other • Do not lower document.domain to the “two-dots” level or lower • foo.site.com is allowed • site.com is prohibited • .com is right out (prohibited by browsers too)

20. Cross-Domain ScriptingCross-Domain Access Policies • Used by Flash, Silverlight • crossdomain.xml • clientaccesspolicy.xml <cross-domain-policy> <allow-access-from domain="www.good.com"/> <allow-access-from domain="*.net"/> <allow-access-from domain="*"/> </cross-domain-policy>

21. Cross-Site Request ForgeryViewStateUserKey • Built-in canary defense for ASP.NET pages protected void Page_Init(object sender, EventArgs e) { this.ViewStateUserKey = Session.SessionID; }

22. Demonstration 2 ViewStateUserKey

23. Future SDL InitiativesSDL for Agile Development • SDL originally designed for long projects • Difficult to implement 100+ SDL requirements in two-week-long release cycles

24. Future SDL InitiativesSDL for Agile Development cont’d • Break SDL into two “classes” • Non-negotiable “every-sprint” requirements • “Bucket” requirements • Complete at least one from each bucket • Complete all requirements every six months

25. Session Summary • SDL can dramatically lower the number and severity of vulnerabilities in online services • Validate user input • Encode output • Use stored procedures • Avoid EXEC @sql • Limit cross-domain access • Use ViewStateUserKey

26. For More Information • SDL Web Site • http://www.microsoft.com/sdl • SDL Blog • http://blogs.microsoft.com/sdl • MSDN Magazine • September 2008, “Security Briefs: SDL Embraces the Web” • November 2008, “Agile SDL: Streamline Security Practices for Agile Development”

27. Questions and Answers • Submit text questions using the “Ask” button. • Don’t forget to fill out the survey. • For upcoming and previously live webcasts: www.microsoft.com/events/developer.mspx • Got webcast content ideas? Contact us at: http://go.microsoft.com/fwlink/?LinkId=41781