MSDN Magazine - September 2008 - (Page 105)

Bryan SuLLivan Security BriefS SDL Embraces The Web The Security Development Lifecycle (SDL) team recently released details of the SDL process that has been so successful in helping to make Microsoft products more secure. You can find these documents at microsoft.com/sdl. As you read through this SDL guidance you will find strategies for securing client/server applications. Mitigation strategies for buffer overflow vulnerabilities are also covered extensively. With no less than three required compiler and linker switches (/GS, /SAFESEH, and /NXCOMPAT), 20-or-so code analysis warnings (found with the /analyze option in Visual Studio® 2005 and later), and more than 150 banned API functions, overflow vulnerabilities seem to be public enemy number one for the SDL. What you won’t find in the publicly available SDL documentation is guidance specific to securing Web applications or online services. To be sure, most of the SDL non-implementation requirements apply equally to client/server and Web applications. It’s just as important to threat model your Web Forms applications as it is your Windows® Forms applications. Likewise, it is just as important to perform a Final Security Review for a SOAP service as for a Windows service. But what about Web-related vulnerabilities like cross-site scripting (XSS) and SQL injection? If the SDL pays so much attention to defending client/server applications against buffer overflows, why doesn’t it pay attention to defending online services against XSS attacks, the public enemy number one of the Web? The answer is, it does pay attention to these issues. The Microsoft® Online Services Security and Compliance team has been instrumental in identifying Web application security issues and addressing them in the SDL. However, these SDL requirements have previously not been available outside of Microsoft. The Web application-specific SDL requirements are some of the newest requirements, and the team wanted to make sure they were demonstrably effective before taking them outside the company. As online vulnerabilities rise across the industry, the team is confident enough in the effectiveness of the online service SDL requirements to share them here for the first time. Please note that the rest of this column assumes you are familiar with Web application security issues such as XSS and SQL injec- in many respects, crosssite scripting is just as dangerous as a buffer overflow. Clearly, XSS should be taken seriously. tion. If you are not comfortable with these concepts, please read up on them before continuing—good background material on these vulnerabilities can be found in the book 19 Deadly Sins of Software Security by Michael Howard, David LeBlanc, and John Viega (McGraw-Hill 2005). In many respects, an XSS vulnerability is just as dangerous as a buffer overflow. Security professionals—even Web security professionals—often disagree with me when I make this claim. But consider that some of the most damaging attack payloads of buffer overflow exploits are exactly the same as XSS payloads. XSS attacks can steal users’ personal data such as credit card or bank account numbers; they can steal users’ passwords; they can even create selfreplicating Web worms that spread throughout a site, choking its resources and slowing it to a crawl. XSS: The New Buffer Overflow Validate All Input Clearly, XSS should be taken seriously, and the SDL does take it seriously by requiring online services teams to follow certain development standards. First, all input to the application from a user, a component, or another program should be validated to ensure that the input is free from unsafe markup and script characters before processing that input. For example, let’s say a user enters the following text in a textbox: My name is Amy This input should be rejected entirely as malicious. Alternatively, the text could be stripped of its markup, back to the following: My name is Amy However, this sanitizing stripping approach is dangerous since there are many ways to escape special characters. The character < can be encoded as <, <, <, or %3c. Unless you know This article is based on a prerelease version of SDL guidance and tools. All information herein is subject to change. Send your questions and comments to briefs@microsoft.com. September 2008 105 http://microsoft.com/sdl

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.