SECCOM Labs logo
Resources for Secure
Software Engineering
from Security Compass

Next Release of Secure Web Application Framework Manifesto

By Rohit Sethi on May 5, 2010, about: Analysts, Architects, Beginner, Developers, Intermediate, Security, articles, whitepapers

A few months ago we released the first version of the Secure Web Application Framework Manifesto: a set of requirements intended to guide web application framework developers in making more secure web application frameworks from the start.

Today we’re pleased to announce our next draft of the manifesto. We’ve reformatted the requirements according to much of the feedback we’ve received.

Check it out: Secure Web Application Framework Manifesto v0.08

We need your help - for some of the requirements in the manifesto we couldn’t find easily find examples of frameworks already fulfilling that requirement. Know of any? Please email us at labs [ a t ] securitycompass.com! As always, we appreciate any feedback you may have. Once we’ve collected the responses from this draft we’ll turn it into an OWASP project!

Edit: Many people helped shape the contents of this document. We have an acknowledgements section inside of the doc but would like to explicitly thank the following people for their ideas and/or support:

  • Arshan Dabirsiaghi and the OWASP Intrinsic Security Working Group
  • James Landis
  • Jim Manico
  • Dinis Cruz
  • James McGovern
  • Paco Hope
  • Paul Johnston

Security Compass Youtube Channel

By Sahba Kazerooni on April 12, 2010, about: Analysts, Architects, Beginner, Developers, Intermediate, Security, Testers

From our various training courses, we have quite a few videos that demonstrate web application attacks. Some are basic, and some are advanced attacks that are otherwise difficult to explain on paper. You can now access some of these videos through our Youtube channel. We’ll continue to update this channel as we create more demo videos. Enjoy!

SDLC Security Audit Framework

By Rohit Sethi on March 30, 2010, about: Advanced, Analysts, Intermediate, Security

We’ve put together a framework based on the OWASP Security Assurance Maturity Model and some of its user-contributed checklists to perform a security assessment on an organization’s SDLC. The intent here is not to find specific flaws in an application, but rather to measure the level of security baked into the process. Today, this kind of assessment is often performed courtesy of the professional judgment of an application security expert without consistency. We wanted to make a repeatable, systematic process framed in the language of controls auditing. Ideally, organizations will be able to assess a potential software vendor’s SDLC security posture prior to purchasing commercial-off-the-shelf or custom-developed software. We’ve successfully used this framework in the past to identify gaps and provide recommendations for independent software vendors. Please let us know your thoughts by sending feedback to labs@securitycompass.com. We look forward to hearing from you!

The True Danger of XSS and CSRF

By Rohit Sethi on May 15, 2009, about: Analysts, Architects, Beginner, Developers, Intermediate, PM, SDLC Role, Security, Security Experience, Testers, whitepapers

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.

Read More…