OWASP AppSec Ireland and DC

OWASP AppSec Ireland is a week away! If you happen to be in Dublin, Ireland next Friday, come by and say "Hi!" I will be presenting "Microsoft's Security Development Lifecycle for Agile Development".  More information is available here:

http://www.owasp.org/index.php/OWASP_IRELAND_2010#Agenda_and_Presentations_-_September_17

I was also accepted to speak at OWASP AppSec DC on November 10th or 11th. This will be the first time I will give the SDL-Agile presentation at a conference in the United States!  The conference home page is: http://www.owasp.org/index.php/OWASP_AppSec_DC_2010

Rails 3 HTML Encodes by Default

Rails 3 came out recently, and the developers made a significant change that really improves the security posture of Rails 3.  They really embraced the "secure by default" security principle in their efforts to eliminate cross-site scripting.  Previously, unsafe user data had to be explicitly HTML encoded in order to avoid cross-site scripting.  This was done using the "h" tag.  For example:
<%= h(@unsafe_user_input) %>

In Rails 3, the default is to automatically HTML encode.  The "h" tag is no longer necessary.  Instead, developers must go out of their way to output HTML content to the page using the "raw" tag.  For example:
<%= raw(@unsafe_user_input) %>

I think the Rails developers took a really strong stance on this issue and it will result in a safer Ruby on Rails ecosystem.

Please see the video below for more details:
http://rubyonrails.org/screencasts/rails3/xss-ujs

There is also a really great Rails security guide found here:
http://guides.rubyonrails.org/security.html

OWASP AppSec Research 2010 Stockholm Conference Videos Posted!

The presentation videos from the OWASP AppSec Research 2010 Conference in Stockholm, Sweden are now available!

My Presentation slides can be found here:

• http://www.owasp.org/images/4/44/OWASP_AppSec_Research_2010_Microsoft_SDL_Agile_by_Coblentz.pdf

A video of the presentation is also available:

• http://owasp.blip.tv/file/3918259/

The rest of the videos and presentation slides can be found here:

• http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=June_23
• http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=June_24

Martin Holst Swende and Alan Davidson, members of the organizing committee, took pictures at the OWASP AppSec Research 2010 Conference.  Those pictures can be found here:

• http://www.flickr.com/photos/holiman/sets/72157624428046528/
• http://www.flickr.com/photos/51810233@N04/sets/72157624316862061/
• http://www.flickr.com/photos/51810233@N04/sets/72157624438812472/
• http://www.flickr.com/photos/51810233@N04/sets/72157624441596030/

I will be giving this presentation again at the OWASP AppSec Ireleand 2010 Conference on September 17, 2010 (http://www.owasp.org/index.php/OWASP_IRELAND_2010) .

OWASP AppSec Research 2010 Pictures

The OWASP AppSec Research 2010 Conference in Stockholm, Sweden ended today. I took a quite a few pictures and I thought I would post a couple of them. Please enjoy!

Aula Magna (Conference Venue)

Track 1

Day 1 Keynote with Chris Evans, Google

Day 2 Keynote with Steve Lipner, Microsoft

Gala Dinner at Stockholm City Hall

Conference Closing Remarks and Thanks

I'm Presenting at OWASP AppSec Research 2010 Conference

The OWASP AppSec Research 2010 conference is being held on June 23rd and 24th 2010 in Stockholm, Sweden.  I will be speaking on the 24th at 11:10 AM on "Microsoft's Security Development Lifecycle for Agile Development".  Here is a link to the schedule for June 24th:
http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=June_24

I hope to see lots of people there!

.NET User Group Presentation - Microsoft SDL-Agile

I had a great time giving my Microsoft SDL-Agile v2 presentation last night at the Kansas City .NET User Group Meeting.  Several people asked for the slides, so I made them available as a PDF document here: Microsoft SDL-Agile Presentation - Nick Coblentz V2 2010-03-23.pdf

Many also wanted links to the tools I mentioned during the presentation.  Here is a list of those tools:

• SDL Process Guidance 4.1a (includes SDL-Agile towards the bottom of the document
• CAT.NET v2, Web Protection Library (Includes Anti-XSS Library and Security Runtime Engine), and the Web Application Configuration Analyzer 
• web.config security analyzer
• Microsoft FxCop 1.36
• Microsoft Code Analysis Tool .NET (CAT.NET) v1 CTP - 32 bit (Old version of CAT.NET)
• Microsoft Code Analysis Tool .NET (CAT.NET) v1 CTP - 64 bit (Old version of CAT.NET)
• BinScope Binary Analyzer
• MiniFuzz File Fuzzer
• MSF-Agile plus Security Development Lifecycle Process Template for VSTS 2008
• Microsoft SDL Process Template For Visual Studio Team System
• Microsoft SDL Threat Modeling Tool

Finally, here are links to the code used to demonstrate the Web Protection Library:

• Default.aspx
• Default.aspx.cs
• Default.aspx.designer.cs
• Web.config

Please feel free to email me with any questions or comments about the presentation.

Reducing Information Disclosure in WCF Data Services

Previously, I wrote an article titled "Reducing Information Disclosure in ASP.NET Web Services".  The article identified steps developers can take to eliminate detailed error messages, stack traces, web service description pages, and WSDLs from their production applications. This article will offer similar recommendations for WCF Data Services.  Since this article builds of the previous one, I will not repeat the background information.

Reference WCF Service
We will use the following WCF service as a starting point.

Here is a successful SOAP request.

The WCF Help Page and WSDL are accessible as shown below.

The following two errors occur when parameters are omitted in the web service call or when we try to divide by zero.

ASP.NET Custom Errors: No Help At All
Unlike ASP.NET web services, exception handling in WCF data services is not the least bit affected by enabling custom errors.  When custom errors are enabled, full stack traces, local file paths, and other information is returned to the consumer.

Explicit Try/Catch Blocks: 100% Effective, But What If You Miss One
Try/Catch blocks are just as effective as in ASP.NET Web Services.  Here's the code.

And the result.

As stated in the ASP.NET Web Services article, there is always a chance that we could miss a try/catch block.  We need some sort of backup solution to catch any exceptions that we miss.

includeExceptionDetailInFaults="false": A Great Backup to Try/Catch Blocks
In WCF Data Services, this functionality seems more complete and it is just as easy to implement as in the last article.  Simply set the "includeExceptionDetailInFaults" attribute to "false" in the "serviceDebug" XML element of the Web.config file.

Stack traces and other detailed error information are now suppressed.

Removing the WSDL and WCF Help Pages
Help pages and the WSDL can easily be removed for WCF services.  The "serviceMetadata" and "serviceDebug" XML elements in the Web.config file have attributes to specifically control these items.

When the appropriate attributes are set to "false", the help page and the WSDL show up as blank pages.

Once this change has been made, it will be necessary to communicate WSDLs or web service signatures with partners through some other channel.

WCF Metadata Exchange (MEX)
There is one additional issue to address with WCF Data Services, and that is to disable the Metadata Exchange (MEX) endpoint.  Clients and attackers can query MEX endpoints to learn about web service signatures and configuration.  For more information about MEX, see the following articles:

• What is a metadata exchange (MEX) binding?
• Publishing Metadata

An example HTTP request and response used to query a MEX endpoint is shown below.

Additionally, an attacker can utilize the WCF Test Client to capture this data and query the service.

This behavior can be disabled by removing the MEX end-point.  In the Web.Config file below, the end-point is commented out.

After the configuration change, the MEX endpoint is no longer accessible.

Reducing Information Disclosure in ASP.NET Web Services

*Note: This article does not directly apply to WCF Data Services

Many applications use external web services to allow partners, WPF/Silverlight applications, cloud components, or other entities to access information and functionality.  Trusted parties can use SOAP, REST, or AJAX requests to communicate with ASP.NET Web Service end-points.

Since standard protocols are used to connect with these components, malicious users can also issue requests to your web services.  In some cases, web services provide detailed information regarding the method calls and parameters available, as well as detailed error messages for failed attacks.  It's important to reduce the amount of information provided to attackers by ASP.NET web services.

Reference Web Service
First, let's start with a basic ASP.NET Web Service.  The code is provided below.

This web service accepts a dividend and a divisor and it returns the quotient.  Since this is a simple demonstration, the code does not include any functionality or data that an attacker would likely target, but the concepts that are demonstrated still apply.

If we run this application and visit the Math.asmx page, a description page is displayed.  The description page lists all the web service methods, parameters, and even provides example SOAP requests for calling the methods.  Since I am accessing the service locally, it also provides an HTML form to test the functionality.  Depending on the settings in the Web.Config file, this form may or may not be available to external users.

In addition to the description page, the WSDL document is also accessible.

A client can call this service using a SOAP or REST request, as shown below.

By default, the application displays detailed error messages.  Two example exceptions are shown below.  The first exception is due to a divide by zero condition; the second is due to missing parameter values in the SOAP request.

ASP.NET Custom Errors: 80% Effective

ASP.NET applications have a Custom Error Handler that can be used to control the detail level of error messages provided to clients.  It is very easy to configure the Custom Error Handler in the Web.Config file.  See the "customErrors" XML element in the screenshot below.

After enabling Custom Error Handling, the error messages for the divide by zero condition shows much less detail. We have eliminated the stack trace information; however the title of the error is still present. In a real world web service, SQL Exceptions such as "Unclosed Quotation Mark" would still be shown. Simply enabling Custom Errors is not enough to resolve this information disclosure issue.

Explicit Try/Catch Blocks: 100% Effective, But What If You Miss One
It's considered a best practice to catch and correctly handle any exceptions that occur within code.  This technique is also important for preventing detailed error messages from reaching the client.  Consider the code below.

In this sample, we catch the divide by zero exception and then just return 0.  In a real world application, a much more robust solution should probably be implemented.  This new code results in no business functionality related exception being shown the user.

While this solution is effective at preventing verbose error messages from reaching the client, there are cases when a try/catch block could be missed.  One could wrap all code in a try/catch block for the generic Exception class, but this is not a very elegant solution.

Suppress Returning Exceptions: A Great Backup to Try/Catch Blocks
Wouldn't it be nice if there was a "customErrors" style solution for web services? The "diagnostics" XML element within the web services section of the ASP.NET Web.Config file can provide this type of functionality.

This configuration change results in the following limited error message for the divide by zero condition.

This solution is very effective; however there is one caveat.  Both explicit try/catch blocks and the Web.Config change still will not control error conditions that occur due to missing parameters or incorrect value types.

This solution provides a great catch all for situations where an explicit try/catch block may be missed.

Removing the WSDL and Service Description Pages
A quick Web.Config change can be used to disable WSDLs and description pages.

Once this change has been made, it will be necessary to communicate WSDLs or web service signatures with partners through some other channel.

How Often Should I Reassess My Web Applications?

There are a couple approaches for determining when an application should be undergo a security assessment. First, organizations often require new tests after a fixed period of time. This period of time may vary based on the risk level the organization has attributed to each application or application type. It's common for organizations to conduct security assessments of high and medium risk applications every six months to one year. For low risk applications, the time period is often a year to two years. The risk level of an application is often determined based on the type of data and functionality within the application. For example, an Internet facing application that handles credit card transactions would be considered high risk; while an application that simply provides product information and is not subject to regulatory, compliance, or legal requirements may be low risk. Periodic assessments usually supplement the next two approaches.

The second approach is associated with major changes implemented in the application. There are a variety of changes that should trigger a new application assessment. Any changes to a security mechanism should undergo validation. Security mechanisms usually include things like authentication processes, authorization controls, session management features, and data validation and encoding components (think cross-site scripting, SQL injection, etc.). Changes that add or modify a feature in the application should trigger a retest based on the risk level of the application and the sensitivity of data or functionality that the change effects. So, a new feature that adds an “about” tab to a website probably doesn’t need to undergo rigorous security testing; however, a new feature that collects users’ social security numbers absolutely should undergo testing (including evaluation whether collection of this PII complies with the organization’s policies, that there is a need to know for this sensitive data, that the sensitive data is adequately protected at rest and in transit, and that only authorized, authenticated parties can reach this data). Organization’s typically set up criteria and standards around PII, credit card information, and other sensitive data types that automatically trigger a reassessment when an application change related to those data types occurs.

The third approach is to use application security testing as a security gate within an organization’s development process. In this case, specific application types or risk levels would require an assessment before they can be deployed to production. This is usually one of the final steps in a secure software development process and acts as a sanity check or a process improvement opportunity rather than a catch-all for security issues. These types of tests are often highly targeted and would not encompass an assessment of the whole application; instead the security assessment would focus on high risk, new, or updated components introduced in the application.

Previously, I wrote an ISSA article, Titled “Web Application Security Portfolios”, which covered some of this detail. An expanded version of this article can be found in my post here. The article discusses ideas around managing portfolios for each application within an organization, identifying data types and compliance requirements, and tracking security activities.