This year we’ll be returning to RSA to deliver a couple of 1 day training classes: application security hands on and database security hands on. Both are introductory courses that aim to get students ramped up quickly on these important topics. Know anyone who’s interested?
It’s clear that your choice of web application framework makes a significant impact on the security of individual applications. Today we’re releasing a draft version of the Secure Web Application Framework Manifesto - a document that provides a set of security requirements to web application frameworks themselves. Once we’ve collected feedback from the community, we’d like to turn this into a living OWASP project that is updated annually.
We’re eagerly looking forward to any feedback you have. Please email us at labs [ a t ] securitycompass.com
This article is based on the Command Injection in XML Signatures and Encryption whitepaper authored by Bradley W. Hill from Information Security Partners.
XSLT is a simple language designed to facilitate cross platform content generation by selecting and merging datasets presented in an XML document. The vulnerability described in the whitepaper still exists in today’s XSLT processing engines, which are widely used in web service implementations. In this article, we will look into reproducing this attack on two of the common XSLT processing engines: Microsft’s MSXML and Xalan (Java’s XML processing library). In addition to an overview of reproducing the attack, this article also features video demonstrations of the exploit that we feature in our Training courses. In both these scenarios we are using the latest versions of the frameworks’ XSLT processing engine as of September 16, 2009.
MSXML implemented in a .NET Application:
MSXML, Microsoft’s XSLT processor, provides a scripting engine to allow for dynamic content generation. The
Xalan implemented in a Java Application:
Xalan, on the other hand provides versions of standard Java classes such as Java.lang.Runtime and Java.lang.Object that can be included with the XSLT signature. These classes can then be used in
Come check us out at OWASP DC. We’ll be speaking on the Security Analysis of Core J2EE Patterns and teaching classes on Threat Model Express and Java Source Code Review
We’re happy to announce that our Security Analysis of the J2EE Core Patterns is now officially an OWASP project! I’ll be the project leader and look forward to getting your input on constantly improving this doc. Thanks to everyone who has supported us in this effort thus far!
In our one-day training classes and conference talks we make judicious use of videos to demonstrate concepts. One of the most popular videos illustrates the true danger of Cross-Site Scripting (XSS) combined with Cross-Site Request Forgery (CSRF). We constructed a fake bank site and demonstrated that a single XSS vulnerability and money transfer functionality in the bank site could result in a user losing money just by visiting another site. In the example, the bank site isn’t over SSL but SSL would not prevent this attack in any way.
The malicious site in our example is completely attacker-controlled, but in reality the malicious site could actually be a Flash ad in a trusted site, Facebook / Myspace / LinkedIn applications or other mashups running untrusted code, or even malicious code running in another trusted site like a bulletin board.
In our example, the user visits the bank site and the attacker site in two browser tabs at the same time. In reality, the victim is exposed for the entire duration of his/her session on the server. That means if a user simply closes their browser window and doesn’t actually logout of the banking application, they are still vulnerable for a period of time – usually 15-30 minutes.
Jamie Rockhill* is the director of information security at DG&S, a medium-sized Manhattan-based financial services company. In the past twelve months some of the firm’s largest clients have either been acquired or have filed for bankruptcy protection. Although not as hard hit as some of their Wall Street peers, DG&S is anticipating a 20% loss against previous year’s earnings. The firm is facing a major restructuring and there is an across-the-board freeze on any training expenditures or major IT projects. Indeed, any expense over $1,000 requires Executive VP sign off.
Today Krish Raja, Sahba Kazerooni, and I are releasing a Security Analysis of the Core J2EE Patterns. In our view, this sort of analysis is long overdue: software vendors, enterprise developers, and the open source community all use patterns judiciously. While developers have access to patterns about security, they rarely have access to a security analysis of non-security-specific patterns.
This beta release outlines our security analysis: we’d love to hear your feedback to improve the quality of our analysis. In future releases, we intend to include source code examples to help elucidate the concepts we describe.
Welcome to Seccom Labs, our site dedicated specifically to helping developers, architects, testers, and everyone else involved in the SDLC with security. This page will include tools, blog entries, articles, videos, whitepapers, and security scenarios.
Some of you may be wondering why we’re releasing Seccom Labs when other great open resources like OWASP exist. To start, we wholeheartedly support the OWASP mission and in fact I personally head the OWASP Toronto chapter. The reasons we’re launching Seccom Labs are simple:
Seccom Labs represents a culmination of our shared experience in securing software. We hope you find it useful and we appreciate any feedback you have for us!
So you’ve learned the basics of application security. What happens next? Ongoing education isn’t as clear cut as taking a single course. Nothing beats real world experience, but not everyone has the luxury of time to ramp up on application security experiences.
Security scenarios are modeled after the Harvard Business Review Case Studies - they’re real world scenarios based on actual challenges faced by practitioners on the ground. Each scenario describes a fictional predicament faced by somebody involved in application security. The scenario ends with a challenge: what would you do in this situation? We supplement the scenario with expert opinions from within Security Compass and real world practitioners in industry.
Our first scenario involves Jamie Rockhill – a fictional Manhattan information security information practitioner who faces a growing set of application security threats while battling a severe financial downturn. Our founder Nish Bhalla and SANS instructor Jason lam weigh in with their opinions.
