Michael Howard here with a quick update on MiniFuzz File Fuzzer.
We have received sporadic reports that a few MiniFuzz users are encountering an issue when attempting to run MiniFuzz on Windows Server 2003 or Windows XP platforms. This is a known issue that results from some missing registry keys on Windows XP and Server 2003 that are present in Vista and Server 2008 by default. We had documented this issue on the download site, but I wanted to also mention it here.
Below is a quick snapshot of the error and a simple command-line script that will automatically create the necessary registry settings and allow you to use MiniFuzz on these platforms. This should get you up and fuzzing immediately.
The error: The manual fix: Run the following command-line script to automatically create the necessary registry settings:
The error:
The manual fix:
Run the following command-line script to automatically create the necessary registry settings:
REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /f REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v DontShowUI /t REG_DWORD /d 1 REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v ExcludedApplications /t REG_MULTI_SZ
What we are doing about it: We will be fixing this issue in MiniFuzz and putting up a fixed version of MiniFuzz in the future.
What we are doing about it:
We will be fixing this issue in MiniFuzz and putting up a fixed version of MiniFuzz in the future.
Thank you for downloading MiniFuzz. We apologize for this inconvenience, but hope this manual fix will help you begin fuzzing your applications.
Hi everyone, Bryan here.
As we’ve talked about on this blog many times in the past, the SDL requires the use of the Microsoft AntiXss library to defend against cross-site scripting attacks. However, we haven’t talked about the fact that until now, there have been two separate versions of AntiXss: one freely available to external users, and one restricted to use only inside Microsoft hosted data centers. Both versions include functionality to encode HTML output, so that injected script will be harmlessly rendered as text instead of executed by the target’s browser. However, the internal version also includes functionality to sanitize user input and remove potentially malicious script.
We have wanted to bring this internal technology to the external developer community for some time, so I’m excited to announce that the Information Security Tools team is including the HTML sanitization functionality in the new public version of AntiXss (version 3.1) and releasing the entire library under the Ms-PL open source license. Let’s take a quick look at how this functionality works and when you might want to use it.
When used correctly, output encoding is very effective at preventing XSS. However, a side effect of this is that it’s also very effective at preventing any type of user-specified HTML markup, whether malicious or benign. Yes, “<script>document.location='evil.com'</script>” should probably be blocked, but what about “I like <b>strong</b> coffee”? This is not malicious in any way and it seems overly restrictive to block it. (I’ll leave it to your own sense of good taste to decide whether the use of the <marquee> tag is malicious under any circumstances.)
Until now, the preferred way to selectively allow only certain HTML tags like <b> and <i> was to regex the input to ensure it contained only valid Unicode letter and number characters and those specified tags, something like this:
if (!Regex.IsMatch(input, @"^([\p{L}\p{N}'\s]|<b>|</b>|<i>|</i>){1,40}$")) throw new Exception();
This approach will prevent all unwanted tags, but it will also prevent all attributes on the allowed tags. Sometimes this is good – attackers can add malicious script to onmouseover attributes of <b> and <i> tags – but again, sometimes this is overkill and blocks the use of benign attributes like lang or title. It would be theoretically possible to extend the regular expression to allow these attributes, as well as other safe HTML tags and their attributes, but realistically that would be an incredibly difficult regex both to develop and maintain.
AntiXss 3.1 takes care of all of this logic for you, using the same whitelist approach: it filters the input using a list of known good tags and attributes and strips out all other text. Simply pass the untrusted input through the AntiXss.GetSafeHtml or GetSafeHtmlFragment method to sanitize it:
string output = AntiXss.GetSafeHtml(input);
I strongly encourage everyone to download the new AntiXss 3.1 and incorporate it into your applications starting today. It’s a very effective defense, especially when used in conjunction with the output encoding functionality that’s been a part of AntiXss from the beginning. And again, both output encoding and input sanitization are required by the SDL.
Finally, I’d like to thank both the Exchange team (whose HtmlToHtml library provides the sanitization logic) and the Information Security Tools team for bringing this functionality to the public, where it can do the most good for the most people.
Jeremy Dallman here to announce the release of two new security tools that will help you test and verify the security of your software – and meet some of the most critical requirements of the SDL. In addition, we are responding to customer requests and providing a basic 7-step guide for manually integrating key elements of the SDL Process Template into your existing Visual Studio Team System project.
As secure coding becomes an increasingly important piece of software development across the industry, we realize that security tools become a critical piece of your “security tool belt” and help ease adoption of security development best practices in your organization. In today’s economy, the tools that will get deployed are the inexpensive (or free) tools that effectively identify security issues, work seamlessly with your existing development environment and help teams implement the basics of the SDL.
Today we are making available BinScope Binary Analyzer and MiniFuzz File Fuzzer as no cost downloads.
We put together a couple of demo videos also. You can find them here: BinScope video & MiniFuzz video.
Let me briefly introduce you to each of these tools and explain why we think they are ideal tools to download and immediately include in your development lifecycle to verify the security of your code.
The BinScope Binary Analyzer is an SDL-required security tool that has been used by Microsoft teams since the early days of the SDL. It analyzes your binaries for a wide variety of security protections with a very straightforward and easy-to-use interface. At Microsoft, developers and testers are required to use this tool in the Verification Phase of the SDL to ensure that they have built their code using the compiler/linker protections required by the Microsoft SDL.
The analyzer performs a diverse set of security checks. These checks include:
The BinScope Binary Analyzer can be downloaded as a standalone tool or as a tool that can be integrated into Visual Studio 2008. By offering these two options, this tool can easily and quickly help you build your code to meet the SDL compiler/linker protections.
(Figure above: stand-alone BinScope)
(Figure above: BinScope integrated in Visual Studio)
With an integrated installation of the BinScope Binary Analyzer for Visual Studio, validation is readily available in the development environment. In addition, BinScope integrates with Microsoft Team Foundation Server (TFS) to output results into work items. Finally, if your project is using the Microsoft SDL Process Template for VSTS, BinScope will seamlessly integrate with the template’s security work items and SDL Final Security Review reporting.
(Figure above: Easy output to TFS to create bugs and speed triage)
(Figure above: Seamless integration with the SDL Process Template reporting)
The MiniFuzz File Fuzzer is a very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their software development processes. A less capable and non-graphical version of this tool was originally published on the CD that came with the book The Security Development Lifecycle by Steve Lipner and Michael Howard. Since that tool was effective at finding quality bugs, we wanted to offer it more widely along with our other SDL tools, improve the user experience, and provide integration with Visual Studio and Team foundation Server.
Because fuzzing is effective at finding bugs, it is a required activity in the Verification Phase of the Microsoft Security Development Lifecycle (SDL). With the release of the MiniFuzz File Fuzzer, we have made a simple file fuzzer available to assist developer efforts to find and address more security bugs in code before it ships to customers. Simply provide the tool with a set of correctly formed files to serve as templates, and it will generate corrupted versions for testing. The effectiveness of fuzz testing can be increased by providing more variation in the template files.
When you install the MiniFuzz File Fuzzer, it is provided as a stand-alone fuzzing tool that can be launched from your Start Menu. However, if you are using Visual Studio 2008, you can easily include the tool in Visual Studio as an Add-in Tool and launch it from there. In addition, the tool can also output to Team Foundation Server and integrate with the Microsoft SDL Process Template for Visual Studio Team System similar to the BinScope Binary Analyzer.
The whitepaper can be downloaded here
After a successful release of the SDL Process Template for VSTS, we heard from some customers that they would like to include the key elements of the SDL into their existing team project. So, we figured out how to do that in 7 easy steps and wrote a whitepaper! This paper outlines the steps for manually extracting the key elements of the SDL Process Template and integrating them into an existing Visual Studio 2008 team project. By completing each of these manual steps, you can include the key elements of the SDL into your project without waiting until you start or build your next team project.
~~~~~~~~~~~~~~~~
That’s a lot of news for one day, but I hope you are as excited as we are to be releasing these tools and making it possible for more development teams to write secure code and adopt the SDL. We welcome your comments and questions as you download and begin using these tools!
[edited: 9/16/09 11AM - added links to videos]
Hi, this is Johannes Ullrich from SANS.
As CTO of the SANS Internet Storm Center www.isc.sans.org , I lead the development of complex and exposed applications. Recently, SANS www.sans.org became a member of the SDL Pro Network. I am happy that I will be able to teach the SDL curriculum in San Diego September 15th http://www.sans.org/ns2009/.
As a developer, you are faced with an almost impossible task. Even small projects process hundreds of pieces of input data, provide access control to multiple users and interact with multiple systems like databases and browsers. If you make one mistake, one single SQL injection flaw, one function with insufficient access control, you lose. On the other hand, an attacker only has to find one single flaw in order to breach the application.
How do you “win” given these unfavorable odds? One mistake made by developers is to worry too much about individual lines of code forgetting about the big picture. As part of teaching developers about secure coding and defending web applications, I have started to adopt a philosophy I describe as “application security street fighting”. This philosophy focuses on easy and repeatable coding techniques. These techniques do not require developers to become security experts. Instead the approach focuses on using the right tools and principles to guide developers to create secure applications that can be efficiently implemented and maintained.
1 – Simple repeatable coding techniques
One aspect of street fighting, as compared to martial arts practiced in dojos and exhibited in competition is the fact that complex techniques don’t work. A quick kick to the groin usually beats the complicated judo throw. For a developer, this means that standard problems have to be solved in simple, repeatable ways. For example, the ever-present issue of SQL injection is easily addressed. By writing a simple library to enforce the use of prepared statements, the need to implement and secure SQL statements one at a time will diminish.
Another example is user input validation. We typically teach developers to write two lines of code. One line is to retrieve the data from the user, and another line to validate that the data is in the expected format. In my opinion, this is one line of code too much. Instead, write a library once that will retrieve the data and validate it. Going forward, the developer will now only call one function, which will retrieve and validate the data. To illustrate, a little bit of pseudo code:
First the traditional way:
Userdata=GetInput(‘email’);
If ( ! is_email(Userdata) {
Error
}
Next the better version:
Userdata=GetEmail(‘email’);
2 – Threat Focused Coding
Once we get past simple issues like SQL injection and input validation, our developer is able to focus on more challenging security problems such as: How am I going to accurately describe the business logic?; or Which techniques could an attacker use to bypass access control restrictions? The developer’s focus will shift from individual lines of code to the larger threat. Threat modeling, an important part of the SDL, will now become much more meaningful to the developer. To apply a street fighting metaphor: Don’t look at your gun, look at your target. You need to know what is happening on a macro level and not get lost focusing on details.
3 – Training
Even simple techniques will not work if they haven’t been taught and practiced properly. There is a point for “dojo” style training in which you are presented with a set scenario and a safe environment in which to practice. This training needs to be applicable and based on real life situations in order to be effective. One thing I liked about the SDL curriculum developed by Microsoft is that it comes from a company that is able to apply these techniques in its own products. Software security training should not just come from security people, but be strongly influenced by developers. Aside from classroom training, there are plenty of other opportunities to learn and practice in your day-to-day job. It is also important to distinguish between training and practice. Training focuses on learning new skills, usually from an outsider. Practice on the other hand is all about applying what you learned and repeating it. Practice can benefit from outside feedback, but it can also be done on your own. Classroom training should illustrate how you are able to practice what you learned once you get back home. At SANS, one of our long-standing promises has been that what you learn in class, you will be able to apply the day you come home. If it would be any other way, we would only teach skills which you will never use and eventually forget.
4 – Conclusion
The SDL starts with training. Training your developers to reuse code and, to use simple and repeatable techniques to code securely will pay off later during implementation. Code reviews will be easier and faster if developers adhere to these guidelines. Even your response plan can harness the same principles by automating the detection and response to common attacks.
As I’ve discussed here, Application Security requires a combination of knowledge, basic skills and practice so that defending applications through secure coding is done instinctively. The MS SDL process is a great toolkit and leverages the hard lessons learned over the years in security. If you’d like to learn the basics in a one day class, I’ll be teaching the MS SDL in San Diego on September 15th. Check it out and register at http://www.sans.org/ns2009/.