Forms Authentication Token Termination in ASP.NET WCF Services

In my last post (Session Fixation & Forms Authentication Token Termination in ASP.NET), I talked about ways to mitigate two types of session related vulnerabilities in an ASP.NET MVC 4 application. One of these vulnerabilities is also present in many WCF web services. In one mode of operation, WCF web services can authenticate users and issue forms authentication cookies. Since this token contains an encrypted set of values and resides only on the client-side, the server cannot choose to invalidated that token and end a user’s authenticated session. This allows attackers to continue using stolen tokens, even after the user logs out.

Continue reading this article on the Security PS Blog: http://blog.securityps.com/2013/07/forms-authentication-token-termination.html

Session Fixation & Forms Authentication Token Termination in ASP.NET

Read the whole article at the Security PS Blog: Session Fixation & Forms Authentication Token Termination in ASP.NET

ASP.NET applications commonly have one or more vulnerabilities associated with the use of ASP.NET_SessionId cookies and forms authentication cookies. This article briefly discusses those common vulnerabilities and explains one method of mitigating them in an ASP.NET MVC 4 application. Explanation of the exploits are not included, but I linked many of the keywords to OWASP or MSDN articles to provide more details. The security best practices for session cookies and use of sessions in general are provided in the OWASP Session Management Cheat Sheet.

Background
ASP.NET_SessionId cookies and forms authentication cookies can be used alone or together to maintain state with a user’s browser. Each cookie works a little bit differently. The ASP.NET_SessionId cookie value is an identifier used to look up session variables stored on the server-side; the cookie itself does not contain any data. The forms authentication cookie, named .ASPXAUTH by default, contains encrypted data, stored only on the client-side. When it is submitted in a request to the server, it is decrypted and used by custom application code to make authorization decisions... Read More at the Security PS Blog.

Burp Suite Plugin: WCF Binary SOAP Scanner Insertion Point

In my last Burp Suite plugin post, I demonstrated a plugin for viewing and modifying binary encoded WCF SOAP messages. This new post builds on the previous one by allowing Burp Suite's native scanning interface to inject payloads into messages:

• http://blog.securityps.com/2013/05/burp-suite-plugin-wcf-binary-soap.html

Non-Negotiable Elements of a Secure Software Development Process: Part 3 - Validation Criteria

Read the whole article at the Security PS Blog: Non-Negotiable Elements of a Secure Software Development Process: Part 3 - Validation Criteria

In September, I gave a presentation focused on helping quality assurance professionals understand how they fit into a secure software development process (SSDP) and how they can take an active role in improving software security.  In that presentation, I discussed essential elements that make up a successful SSDP.  These elements are: security requirements (expectations); secure architecture, configuration, and coding patterns (how to satisfy an expectation); and validation criteria (verification that expectations have been met).  These elements allow an organization to be transparent regarding its security goals and performance.  They also facilitate communication with customers, developers, managers, and other project stakeholders.

This article is part 3 in the Non-Negotiable Elements of a Secure Software Development Process series and focuses on defining validation criteria. In part 1 of the series, we discussed how security requirements set clear and reasonable expectations that development teams can plan for and meet to satisfy a specific level of security assurance.  Part 2 discussed how to use secure architecture, configuration, and coding patterns to satisfy security requirements and reduce the ongoing cost of developing secure code.

Why Validation Criteria?
Many organizations measure how secure their applications and infrastructure are using assessments.  They might use application security assessments, penetration tests, design reviews, threat models, or many other fault finding activities.  These can be good risk indicators, and they are often important activities to include within an application security program, but they fall short in actually telling us whether our application is secure. They focus on finding problems, telling us when an asset is insecure, and remain silent about everything else.

With the declaration of security requirements and secure architecture, configuration, and coding patterns (secure patterns), we now have a list of positive characteristics about the application that we would like to affirm. If we can validate these elements, then we can get a more comprehensive understand regarding how our application is secured.  We can then focus on using assessments to identify missing security requirements and improve our overall process as a whole instead of a single application.

Read the following additional sections of the article at the Security PS Blog: Non-Negotiable Elements of a Secure Software Development Process: Part 3 - Validation Criteria

• Why Validation Criteria?
• What to Validate?
• Validation Criteria Approaches
• Test Case Techniques
• How to Win at Software Security

Burp Suite Plugin: View and Modify WCF Binary SOAP Messages

Microsoft’s WCF Web Services have a binary encoded SOAP messaging mode available that Silverlight, WPF, and other thick client applications can use to communicate with an application server. This format cannot be digested natively by Burp Suite, making it time consuming to analyze requests and responses. This post describes how the new extension API for Burp was used to overcome this challenge:

• http://blog.securityps.com/2013/02/burp-suite-plugin-view-and-modify-wcf.html

Non-Negotiable Elements of a Secure Software Development Process: Part 2 - Secure Architecture, Configuration, and Coding Patterns

In September, I gave a presentation focused on helping quality assurance professionals understand how they fit into a secure software development process (SSDP) and how they can take an active role in improving software security.  In that presentation, I discussed essential elements that make up a successful SSDP.  These elements are: security requirements (expectations), secure architecture, configuration, and coding patterns (how to satisfy an expectation), and validation criteria (verification that expectations have been met).  These elements allow an organization to be transparent regarding its security goals and performance.  They also facilitate communication with customers, developers, managers, and other project stakeholders.

This article is part 2 in the series discussing non-negotiable elements of a secure software development process. In part 1 of the series, we discussed how security requirements set clear and reasonable expectations that development teams can plan for and meet to satisfy a specific level of security assurance.  This article focuses on secure architecture, configuration, and coding patterns that equip development teams to meet those requirements.

What are Secure Architecture, Configuration, and Coding Patterns?
Secure architecture, configuration, and coding patterns are language specific implementations of code, frameworks, configuration, and application designs that satisfy a security requirement.  They provide development teams with positive examples and instructions to successfully adhere to security practices without requiring them to be a security expert...  [Article Posted on the Security PS Blog: Non-Negotiable Elements of a Secure Software Development Process: Part 2 - Secure Architecture, Configuration, and Coding Patterns]

Current Blog Posts on Security PS Blog

Recently, I have been posting new content to the Security PS blog found at:

• http://blog.securityps.com

My latest posts include:

• New Burp Suite (>= 1.5.01) Extensibility and an Example Editor Tab Plugin
• Non-Negotiable Elements of a Secure Software Development Process: Part 1 - Security Requirements
• Alternatives to Microsoft's WPL Sanitizer

In the future, I will continue to link to my articles on the Security PS blog.