Tuesday, 29 June 2010

O2 Platform support for WebGoat

(just sent to the OWASP WebGoat mailing list)

Hi WebGoat Crowd

I finally started adding support for WebGoat to the OWASP O2 Platform by creating an API for Web Goat and showing how to automate a number of WebGoat's tasks and lessons. I've started to documentat how to use it and how it works, which you can read it (or watch the video) here: http://o2platform.com/wiki/WebGoat/First_Example_of_O2_WebGoat_API 

At the moment there is a first pass at an API for WebGoat (see API_WebGoat.cs) and a number of Unit Tests (see WebGoat_BlackBox_Exploits.cs). Both these files are available locally when you install the O2 Platform and the WebGoat_BlackBox_Exploits.cs can be executed by double-clicking on it or dragging'n'dropping it into a loaded O2 instance (see video for an example)

O2 Platform: MSI download, VB/C# conversion, Amazon S3 Browser and WebGoat API

Couple updates while I prepare for the big launch for HackInTheBox later this week:
if you are wondering, how I created those videos using O2, check out:

Sunday, 20 June 2010

O2 now has Javascript AST support (plus XSS PoC builder)

The latest version of O2 contains support for parsing Javascript (and building its AST), which you can see in action in these two scripts:

Also, for the BlackBox crowd, to showcase O2's automation capabilities, I wrote a XSS PoC Builder which allows the quick development, testing and deployment of XSS PoCs

You can read all about it here: Web - XSS PoC Builder  (in O2's wiki)

Saturday, 5 June 2010

First pass at try-o2.com Theme

(as emailed to the O2 Platform mailing list)

Humm, I just spent some time installing a number of Drupal Themes at the TRY O2 website, and found a couple themes that are are quite nice.


Check out how
http://try-o2.com looks at the moment: (the top banner images rotates on page load):

6_5_2010_12_32_24_AM_tmp25E9.jpg

I also like the way the text I wrote for o2-platform.com's home page, looks really nice when placed in prime time position


I think that this text really encapsulates what I'm trying to do with O2:

"Welcome to OWASP O2 Platform's website. The O2 platform represents a new paradigm for how to perform, document and distribute Web Application security reviews. O2 is designed to Automate Security Consultants Knowledge and Workflows and to Allow non-security experts to access and consume Security Knowledge."

Does this text make sense to you?

Friday, 4 June 2010

try-o2.com, o2-platform.com and OWASP.org

I'm the process of setting up the try-o2.com website and so far it seems that Drupal is a good fit for what I need (using a TurnKeyLinux.org image which was very easy to setup). Btw, any good Drupal power-users out there that can give a hand in building this? So far I've managed to install a new theme and configure it to use OpenID :)

Why Drupal? Well, now that I am in full swing on the efforts to build a community around O2 (from core developers, to users, to clients), I needed to find a web technology which provided strong social-network/community features, such as: Blogs, Forums, Voting/Rating, CMS and even (eventually) an e-commerce engine.

On the other hand, there is also a need to create solid documentation and books around the O2 Platform (which I think the MediaWiki is a much better medium)

Add to the mix the O2 Platform pages at the OWASP website, and we have some mapping to do here :)

So, how are all this different websites going to work together?

My plan is that by having different focus for each one, it will make sense:

* the Drupal-based www.try-o2com website (I also have the use-o2.com domain) will be focused on the community that is trying to 'use O2' (this is where all the 'social-tools' will be hosted)
* the MediaWiki based www.o2-platform.com website will be focused on the core O2 developers (i.e. the ones that are customising or creating APIs). This is where the detailed technical documentation will exist and where (eventually) O2 books will be made from (this tight editorial control will also make sense due to more-and-more support/capability that O2 will have for consuming data from this website (from vulnerability rules, documentation and C# scripts))
* the MediaWiki based O2 pages at the OWASP website will be focused in presenting the most mature O2 modules and also on making the connection with the multiple OWASP projects O2 will be integrated with.

One interesting question is: Why 2 MediaWiki websites.

Well, in addition to the fact that I can be much more experimental with the O2-Platform.com MediaWiki that I can/should with the OWASP's MediaWiki engine (for example in trying extensions and themes), there is also some content that I want to
create/maintain that will be hard to do at OWASP (for example, providing technical details about the multiple 3rd party Commercial Tools that exist and how they integrate with O2).

Also, the discussion of how to handle Commercial services around OWASP tools/projects is still in a very early stage, and there are no clear guidelines on how to present/maintain this 'commercial' information in a way that is compatible with OWASP's mission, values and culture.

Thursday, 3 June 2010

O2 Services: Online Training, Remote Support, Custom development

A key component of the 'O2 Platform Commercial Business Model' is the provision and delivery of commercial services to clients who are using (or planning to use) the O2 Platform.

Two days ago I started this process by launching a couple O2 related training courses (see Forthcoming Commercial O2 Training Courses in London blog entry)

Today I'm launching the 'Online Training, Remote Support, Custom development' services for the O2 Platform:

Here is the Wiki page with service's description Online Training, Remote Support, Custom development and here is the EventBrite page containing the current pricing structure http://o2services.eventbrite.com

In the short-term these services will provided and delivered by me.

In the medium-term, the plan is to build a network of security companies and consultants that provide these services (whereby I'm only involved in selected O2 engagements, most likely as a consultant for those 'O2 Enabled' companies)

Note that these services have nothing to do with OWASP and the OWASP Foundation.

O2 Script: ViewState Decoder for .NET 2.0

I just published to the O2 Platform Wiki a good example of O2's powerful scripting capabilities (including the ability that I have (using O2's MediaWiki editor tool) to quickly create technical articles containing tons of screenshots)

The tool is a ViewState decoder for .Net 2.0 and the article is here: http://o2platform.com/wiki/DotNet/ViewState_Decoder_ASP.NET_2.0

Here are the features of this tool:

* Enter any url or browse to any website, and the list of all values present in the ViewState will be shown on the right (note that the refresh is fired on the browser's OnLoad event (which means that you will get multiple views for urls that load more that one page))
* The list of url's is cached in the ComboBox used to enter the url to load (top left)
* There are two view modes
* the simple mode (by default) which presents a TextBox with all values found in the ViewState
* the 'Show all Details' mode (tick the checkbox) which shows: a TreeView of the ViewState, the ViewState Xml, the ViewState values (same as simple mode) and the same info (TreeView, Xml and Values) for the ControlState values
* All relevant code required to create this tool is being dynamically compiled on the fly (note how the source code included at the end of the post is quite small, and the couple supporting classes (included as File references) are also not that big)
* I wrote this entire tool in couple hours today (using O2's scripting environment). Here was my workflow:
* had the need to decode HacmeBank's viewstate
* found a good code sample of the decoding process (which I got from PluralSight's ViewState Decode example)
* created and tweaked the Tool's GUI
* created a couple supporting 'DotNet ViewState' APIs
* consumed the APIs from the GUI
* created the documentation WikiPage

For me, the power of the O2 Platform, lies not in the fact that I can build tools like this, but the fact that I can do it in a couple hours.

Of course, that now that I have an API for DotNet's ViewState, I will be able to perform much complex vulnerability analysis workflows (for example find data leakage or authorisation issues by analysing the ViewState collected from multiple user's sessions)

Wednesday, 2 June 2010

New technology needs to be faster and more convenient

Part of the reason why I don't blog more ofter is because I find the current workflow hard and non practical.

From the moment I have an idea on a blog post, I have to:
* Open a browser
* Go to my blog (& remember the address)
* Enter my credentials
* Select the option to write a new blog post
* start writing the post
* deal with blogger UI (which sucks)
* post it
* click again to view it
* (in most cases) realise that the fonts/spacing are all wrong and edit the post
* grab the link to the post
* go to the 'edit posts' page on Blogger, select the recently posted blog entry, and when it loads copy the title (since the Theme that I currently use shows the Blog title as an image)
* open twitter, paste the title, paste the link to the blog post (if too big, first pass via bit.ly)

huff... no wonder I don't blog more offten.

In addition to the number of steps there is another problem which is that the time that it takes for me to start writing the blog is too long (i.e. by the time I get ready to write it the mojo is gone).

I'm now trying something else.

Using my new IPad (Yes I'm trying to find reasons to justify the purchase :) ), I just installed the BlogPress App and am writing this blog post using it.

My first reactions:

* it is much faster to go from blog idea to blog post
* I have a IPad keyboard so I am writing as fast as I do on a computer
* I really like the setup, the size of the IPad looks like the perfect length for a blog post and I like the 'undivided attention' that it forces me
* I also like the 'proof reading' mode where I use the touch screen to follow my reading and to quickly make changes
* I like not having to deal with Blogger HTML formatting and messy UI
* all I need is to find a way to tweet about this blog entry and I'm done :)
--> Correction: Before I wrote this post I added my twitter account details to it, and after I posted this, BlogPress automatically created a bit.ly address and posted a tweet with the title+address on my tweeter account :) Very nicccccceeeeeeee :)

So what is the moral of the story here?

New technology (like the OWASP O2 Platform) regardless of its potential future impact and benefit, if it doesn't add immediate value to the user and makes him/her faster and more efficient from the day one, it will struggle to be adopted.

This means that:

"It must be faster to 'do it' using the new tool for the first time than it takes to 'do it' manually"

Only then will the user take the risk in trying something new

Location:A315,Hounslow,United Kingdom

Tuesday, 1 June 2010

Forthcoming Commercial O2 Training Courses

Just published 4 new training courses at the O2 external website: http://www.o2platform.com/

These courses are a good place to start if you want to learn about how to use O2:
The courses are going to be delivered by me and cost £200.00 (for 1 day  training)
Note that this is not an OWASP delivered course and it not related to the OWASP Foundation (I'm organizing this independently)

The beginning of O2's Documentation

(ss emailed to the O2 Platform mailing list)

After a week of solid O2 use (and a bunch of new features), I am finally staring to document how O2 works and its main features


One of the many web APIs now supported by O2 is the MediaWiki engine, so I have been using it on the http://o2platform.com website to create O2 documentation (for example the 'O2-Sceenshot-to-Clipboard-Tool + Paste + Auto-Upload-to-MediaWiki' workflow is really powerful and explains why there are so many images/screenshots in there :) ).  

From http://o2platform.com home page, here are the main links to O2's documentation:



Documentation


Last friday I did an O2 presentation at the OWASP London Training Event and there was great reaction from the attendees (I also was able for the first time to do my presentation mainly using previously created scripts and videos, most executed from Paulo Coimbra's laptop (which is a great sign of O2's maturity :) ))

There is a fresh new version of O2 at the web based O2 Installer, so give it a test-drive and post here your feedback. 

Thanks

Monday, 24 May 2010

Major O2 Milestone: 'Complete Vulnerability Trace' for an HacmeBank Sql Injection vulnerability

(As emailed to the O2 Platform mailing list)

Finally, after tons and tons of features, I was able to create a 'Complete Vulnerability Trace' for an HacmeBank Sql Injection vulnerability.


And by 'Complete Vulnerability Traces' I mean a trace that:
  • starts on the Exploit Layer (i.e. the browser entry point), 
  • then goes through the Web Layer code, 
  • then does a jump over the 'internet' into the Web Services layer,
  • and ends up in the vulnerable .NET System.Data method :)
Using O2's MediaWiki API, I created the following 'draft with tons of screenshots' wiki page (containing details of what this trace looks like): http://o2platform.com/wiki/O2_.NET_AST_Scanner_-_HacmeBank_-_SQL_Injection_PoC

The example is shown in the "O2 .NET Ast Engine" module,  and tomorrow I will post details on how to consume (most of) it from the "O2 .NET Ast Scanner" module (which will be easier to use)

Tuesday, 18 May 2010

Major new version, O2 .NET Ast Scanner and first batch of videos


(As emailed to the O2 Platform mailing list)

Hi, I just pushed a new version of the O2 XRules Database (which you 
can install from here).

As usual there are tons of new features and bug fixes, but probably the most important one is the inclusion of the first working prototype of the O2 .NET Ast Scanner (which is an Open Source taint flow analysis engine which is able to create the code-paths for HacmeBank's Sql Injection)

In my efforts to try to document O2, I've started to create a number of webpages and videos (current hosted at the http://o2platform.com website).
I think finally O2 is a position to really add value to the work you do, so please have a go and let me know how I can help

Sunday, 31 January 2010

(circa 2006) Why Novell should take on the 'type-safe platform' challenge

Following a recent twitter thread with Miguel de Icaza, I (successfully) googled up a older post to the SC-L list written in 2006,where I tried to make the business case for Novell to invest in CAS (Code Access Security). After reading and realizing that (sadly) most of it is still relevant today, I'm reposting it here (to make it easier for later relinking)

(for more CAS and Sandboxing related ideas see this PPT 'Making the case for Sandbox v1.1 - Dinis Cruz - SD Conference.ppt ' and this blog post 'Past research of Sandboxing and Code Access Security (CAS)')

Here is the SC-L post that I wrote in 10 May 2006 (link to original which was a reply to Gary's Microsoft's Missed Opportunity Dark Reading post):

Dinis Cruz wrote:

> The ones that I wish were listening are Novell and the Mono project.
> The path to a type-safe platform could start there.

Following this comment made on the previous thread, here are the reasons why I wished Novell and the Mono project where listening to that conversation (note: an edited version of this post was sent directly to several Novell contacts who asked me 'What is it you wish we would listen to?' :

---------------------------------

Dear Novell

What I meant by my comment, is that there is an opportunity today (2006) for somebody (namely a company + community) to really grab the 'type-safe' + 'sandboxing' flag and run with it.

Here is a quick analysis of where we stand today:

    - Vista failed to deliver a OS based on a type-safe platform
    - 99% (or close) of the .Net Framework and Java code is executed in an environment with no sandbox (i.e. executed: a) in Full Trust, or b) with the Security manager disabled, or c) with no verification). Given the amount of code deployed out there, there is no chance that a real change will occur any time soon. Currently there is no interest from Microsoft or Sun to address this issue and invest the time, energy and resources required to solve it.
    - Microsoft failed to make the paradigm shift from Full Trust to Partial Trust when they released v2.0 of the .Net Framework (which would had been the perfect time to do it)
    - There is good grass roots support for type-safety
    - There is a growing need to create secure and trustworthy applications (with growing support from Governments, Large Corporations and ultimately the end users)
    - Sandboxing at the OS level, like the one in Vista's 'Integrity Level / Privilege Isolation' and in Suse's AppArmour (sorry Crispin for not replying to your posts on the previous SC discussion about Sandboxing (it is on my to-do-list)) will NOT prevent exploitation of the user's assets (like for example the user's email). These techniques are designed to 'control' and 'Sandbox' unmanaged code, which is something that I don't believe can be done today. A short term solution (before we get to type-safe OS) would be to have environments like these (which do add some security protection to the OS) supported by a managed/verifiable environment responsible for executing the managed/verifiable  (potentially malicious) code.
    - Apple has an amazing OS (which I am using at the moment) but doesn't seem to be focused on type-safe / sandboxing issues too. Apple also seems to (like most of the Open Source community) think that it is immune to security vulnerabilities (just look at the way they handle security patches at the moment)
    - Novell has gained a huge amount of respect for its support for the Mono-Project and for its support for Open Source
    - Basically, Microsoft has lost the plot on Security and (as Gary McGraw says) is too focused on bugs and not on architecture. They (Microsoft) will have tough times ahead when Vista proves to be as secure as XP SP2 was.
    - IBM has seen the future and is re-organizing itself around the concept of 'delivering enterprise solutions on top of Open Systems and Open Architectures'

So, like I said above, there is a big opportunity for an Open Source project, lead by a major company and based on a solid platform, to lead the way in the move from unmanaged/unsafe code (where I am including Full Trust .Net code in this category) to managed, verifiable and type-safe code (which can be safely executed in Sandboxes and malicious activity easily detected / mitigated)

Novell and Mono fits this bill perfectly.

And it would also give mono an unique point of sell, since at the moment it is still a 'pour cousin of the .Net Framework'.

Ultimately the goal would be to build an OS on of top of a type-safe platform. But before that the user-land world needs to be conquered.

A lot of research and effort must be placed on how to create powerful, feature-rich and fast GUI applications built on type-safe code. This is something that can only be done by a large community focused on a powerful goal: creating secure applications for execution on secure/sandboxed environments.

Imagine if this idea could be developed to such a state where (on Windows) it would be safer to execute C# applications on Mono than on the .Net Framework itself! (another area where mono could do really well is in Hosting of Asp.Net applications (for example based on a Linux distribution of a LAMM environment, hosted by a VirtualServer or VMware host))

I believe that we are watching today the limitations, of both Open Source world (with its 'many eyeballs') and Proprietary Code (with its Secure Development Lifecycle) to create code that doesn't contain critical security vulnerabilities (i.e. both can't do it (with maybe some notable exceptions)).

What is needed is a new paradigm (well not that new if you ask Gary McGraw) that creates a financial-model that rewards the companies that are able to create secure applications that can be executed on secure environments(the idea is not to prevent bugs/vulnerabilities from existing, but to prevent the damage caused by their exploitation).

Ultimately all source-code will have to be released and made public (not necessarily on an Open Source format, but at least available to peer review and external (i.e. independent) analysis) , and again here Novell and the other Open Source development companies have an advantage.

The other major asset which the Open Source distributions have (and one which will be crucial in the future) is the centralized distribution of Software (i.e. packages). In the future we will need entities that certify the security of Software applications, which in an unmanaged-code world (for example: C++ & Full Trust .Net ) is almost impossible to do (i.e. say for sure that Application XYZ does not contain a keyboard hook and direct access to the Internet), but quite possible in a managed, type-safe and verifiable world.

Of course that more CLRs (with custom GC, Security managers, Class loaders, verifiers, etc...) will need to be build, since the requirements of a powerful Windows Application, are very different from an Asp.Net Form, which are very different from a Device Driver.

Looking forward to your comments,

Best regards,

Dinis Cruz

Wednesday, 20 January 2010

OWASP for Charities: Haiti relief effort

There are days that I am really proud of being part of the OWASP community, today is one of those days :)

The email below was just sent to all subscribers of an OWASP mailing list or has an @owasp.org address (about 10,000)



OWASP Members and Supporters,

OWASP was founded, and is supported as a non-profit organization, by a group of dedicated volunteers who believe that all applications should be secure and trusted.  As our organization matures we have taken those beliefs broader, and have started setting up ways for our members to donate to the global community.  Among these initiatives are:
  • OWASP has an active Kiva lending team who have donated $9,125.00 to date.  http://www.kiva.org/community/viewTeam?team_id=522
  • OWASP in response to the need in Haiti has set up a secure and trusted way for those within the OWASP community to donate funds to help the people of Haiti. This allows our OWASP community to help another with a single global voice.  100% of the collected donations will be transferred directly to victims for disaster relief such as food and medical requirements.  Please visit www.owasp.org and click the link for G33k-4-HAITI.  In a time of crisis, OWASP can help those who are in great need. The OWASP community can help organize, support , and promote efforts outside of application security.
OWASP is well aware there is a movement for phishers to utilize this tragedy to get unsuspecting people to donate to a “cause” without having a legitimate business back end and ultimately funneling all the money directly into their own pockets.  The OWASP community is uniquely qualified to help protect from this type of attack and educate about attacks as well.

As the world becomes more dependent on technology and particularly web applications, there are many who need protection who simply have no options to protect themselves.  These include small companies, individuals, charities, and others.  The OWASP community can help by connecting qualified, trusted resources willing to volunteer their time to those organizations which qualify. OWASP is setting up an outreach program, which will be under the name project name of OWASP for Charities.

We hope you will support OWASPs efforts to make a difference  in any of the above ways. We are also open to suggestions in regards to where you feel the OWASP Community can be of service.

Regards,


Your OWASP Board


Kate Hartmann
OWASP Operations Director
9175 Guilford Road
Suite 300
Columbia, MD  21046

Wednesday, 13 January 2010

A couple more comments on ESAPI and ESTAPI

Following my recommending ESAPI? post, there has been some great answers and comments (on both SC-L and esapi-user list). Here is a great recent blog post on EASPI : What is the ESAPI?

To help to clarify why I asked those questions (and my chain of thought) here are two extra entries with my personal opinion. The first one is a post that that I started writing a couple days ago, and the 2nd one,  is a response I just posted on the SC-L and esapi-user mailing lists: 




1st one
(note that some of the questions asked here are already answered in some of the comments to the original post)

My position is that ESAPI is a great example of what an enterprise security API should look like. But we have to be very careful when we say 'use ESAPI', because we risk that people actually use ESAPI on their applications (i.e. download the jar and copy it into their application, and use it)

I think we need to be careful to do this recommendation for several reasons.  The first one is that when we say 'use EASPI', we are basically positioning ESAPI in competition with all the other frameworks (including J2EE in this case, for the Java side of things).

The second one is we have to provide much more visibility to the bits of ESAPI that are ready to be used in production.  My understanding is that there are a lot of modules in ESAPI and not all of them have the same level or quality or readiness.

Some of our target audience is going to be developers without a lot of experience in application security, but who want to implement their security controls/features right, So we have to be very, very clear, whether we are providing them with the right advice on ESAPI, namely on which modules are actually enterprise-ready. (for ex: Is it just the encoding module or the logging module?  Or is the authentication module also ready for enterprise or application use?)


For me, part of the solution is to explicitly break ESAPI into three parts.  


The first one is the interfaces.  Basically, the security controls that an ESAPI API or ESAPI compliant framework should have.  

The second one should be a reference implementation(s), which is what we have today (and is the one that should be commercially supported by third parties).

The third one, are unit tests for the interfaces.  This is a bit where I'm actually quite interested, and I call these the
ESTAPI, which is the Enterprise Security Testing API.  



I think that is a really valuable asset that we need to implement asap (staring by extracting what is already inside the ESAPI implementations). With ESTAPI , we will have a particular set of tests for a particular 'security sensitive behaviour', for example: "...If you are doing encoding for HTML, this is what you should do.  If you are doing encoding for Javascript, this is what you should do.  If you are doing encoding for HTML attributes, this is what you do.  If you are doing encoding for exec inside a Javascript block...., if your are doing authentication...., if you are doing authorization, ... if you are implementing a password reset... ,..etc., etc.  ..."

With the ESTAPI,  I'll be able to run these tests against all supported frameworks, whereby for each framework, all I need are little connecters between the ESAPI interface and the particular framework functionality/behaviour. Then we will be able to test the frameworks for their security capabilities.  I think this will actually provide a much more pragmatic and much more objective analysis of the framework, 
 allow the mapping of the supported security controls & behaviour, and allow the framework's clients to have much more visibility into what's happening on those frameworks.  


Again, I don't want to put ESAPI down.  I think ESAPI is a great project.  I think it's one of the most successful and powerful projects for OWASP and we just need to clarify it a little bit.  In fact, I think the more successful ESAPI is, the more this becomes a problem.  I don't think ESAPI  has blown up yet because ESAPI hasn't reached a wide level of adoption by software developers or commercial applications.  



Remember that one day we will have to deal with the problems of applications built on top of ESAPI that have security vulnerabilities or that are being successfully compromised by malicious hackers.




2nd one (posted on on mailing lists)

My view is that the key to make this work is to create the ESTAPI, which is the Enterprise Security Testing API



This way we would have (for every language):
  • ESAPI Interfaces - which describe the functionality that each security control should have
  • ESTAPI - Unit Tests that check the behaviour of the security controls
  • ESAPI Reference Implementation(s) - Which are (wherever possible) 'production ready' versions of those security controls (and  in most cases a one-to-one mapping to the ESAPI Interfaces)
  • Framework XYZ ESAPI 'connectors' - Which wrap (or expose) the security controls defined in the ESAPI Interfaces in Framework XYZ
What I really like about this world, is that we (Application Security Consultants) we start to create standards for how Security Controls should behave. and (as important) are able to work with the Framework developers without they felling that ESAPI is a 'competitor' to they Framework. After all, the way we will really change the market is when the Frameworks used by the majority of developers adopt ESAPI (or its principles)

Of course that the Framework developers are more than welcomed to grab large parts (or even all) of the code provided by the ESAPI reference implementation(s). But the key is that they (the framework developers) must: a) take ownership of the code and b) respect the ESAPI Interfaces.

And hey, if the Framework developers decide NOT to implement a particular security control, that is fine too. 

BUT! 

I would at least expect them to provide detailed information why they made that decision and why they chose NOT to implement or support it (which would allow us (Security community) to respectably agree or disagree with their choices (hey for some Frameworks, being insecure is a feature :) )

Finally, In addition to all the advantages that we will have when frameworks adopt these security controls, there is one that for me is probably the MOST important one: An 'ESAPI compliant app' (which btw is a term we still have to agree what exactly means),is an app that is providing explicit information about where they (the developers) think their (the app) security controls are located.

In another works, via the ESAPI Interfaces (and the ESTAPI tests) the developers are actually telling us (the security consultants): 
  a) what they think their application's attack surface is and  
  b) what is the security behaviour that they have already tested for

Of course that they can game the system, which is why we (Security Consultants) will still be needed (we will also need to make sure that they implemented the security controls properly). But compare that to today's (2009) world, were we are lucky to get an up-to-date application diagram and a reasonable accurate description of how the application was actually coded and behaves. 

This would also (finally) give the application security tools (white, black, glass, gray, pink, blue) a fighting change to automatically, or operator-driven, understand what is going on and report back: 
  - what it knows (security vulnerabilities) and (as important) 
  - what it doesn't know / understand
(ok there is a lot more that these tools will provide us (for example ESTAPI tests) but that is a topic for another post)

So, for me, the key added value of the ESAPI Interfaces, is that it will provide us (Security Consultants) a way to understand how the app works (from a security point of view) and to be able to finally be able to give the clients what they want: Visibility, Assurance and the ability to make 'knowledgeable Risk-based decisions'.

Monday, 11 January 2010

On Comments on Static Tools thread and Frameworks

Here are some comments on the comments made on the .. thread:

@Andrew: you touched on a very important point which is the importance of the 'operator' (i.e. the knowledgeable user). As per the points you make, I really think that we need to take into account its impact.

Sunday, 10 January 2010

Update #4 on OunceLabs/IBM Relationship

Following the previous posts on this topic (see Update on O2 & Ounce & IBM, Update #2 on O2 & IBM - 02 Sep 09 , Update #3 on O2 & IBM ) here is an update of how the first chapter was concluded.

After some internal debate, IBM decided that the time was not right for them to provide commercial support for O2, so instead of waiting around in IBM land, I made the decision to not accept the contract that I was offered (see why I said NO to IBM for now), which had the practical consequence that my contract with IBM ended on December 31 2009.

The Need for Standards to evaluate Static Analysis tools

In Jan 2010, on the security static analysis space (also called SAST for Static Application Security Testing (you can download the Gartner's Magic Quadrant report from Fortify's website)) there are a number of security focused commercial products (and services) for analyzing an application's source code (or binaries):  Fortify SCA, IBM with Source Edition (was OunceLabs) and Developer Edition, Armorize CodeSecure, CodeScan, Vericode Security Review, Microsoft's CAT.NET, Coverity Static Analysis, Klocwork TruePath, Parasoft Application Security Solution and Art-of-Defence HyperSource (I didn't include any Open Source tool because I am not aware of any (actively used) that is able to perform security focused taint-flow analysis)

Recommending ESAPI?


(I just posted this on the SC-L mailing list and ESAPI users list)

Following the recent thread on Java 6 security and ESAPI, I just would like to ask the following clarifications: 

1) For an existing web application currently using a MVC framework (like Spring or Struts) are we today (9th Jan 2009) officially recommending that this web application development team adds OWASP's ESAPI.jar to the list of 'external' APIs (i.e. libs) they use, support and maintain?

2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL they need to add? or are there other dependencies (i.e. jars) that also need to be added, supported and maintained? (for example on the 'Dependencies' section of the ESAPI Java EE page (i.e. Tab) it seems to imply that there are other *.jars needed)

3) Where can I find detailed information about each of the 9 Security Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography, 6) Error handling and logging, 7) Communication security, 8) HTTP security and 9) Security configuration? (I took this list of controls from the Introduction to ESAPI pdf)

4) When adopting EASPI.jar, are we recommending that the developers should adopt or retrofit their existing code on the areas affected by those 9 Security Controls? (i.e. code related to: Authentication, Access control, Input validation, Output encoding/escaping, Cryptography, Error handling and logging, Communication security, HTTP security and Security configuration) 

5) Should we recommend the adoption of ALL 9 Security Controls? or are there some controls that are not ready today (9 Jan 2009) for production environments and should not be recommended? (for example is the 'Authentication' control as mature as the 'Error handling and logging' control?)

6) Are there commercial (i.e. paid) support services available for the companies who want to add ESAPI.jar to they application?

7) What is the version of ESAPI.jar that we should recommend? the version 1.4 (which looks like a stable release) or the version 2.0 rc4 (which looks like it is a Release Candidate)

8) Where can I find the documentation of where and how ESAPI should be used? More importantly, where can I find the information of how it CAN NOT or SHOULD NOT be used (i.e. the cases where even when the EASPI.jar are used, the application is still vulnerable)

9) if there list of companies that have currently added ESAPI.jar to their applications and have deployed it? (i.e. real world usage of EASPI)

10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been through a security review? and if so where can I read its report?

11) when Jim says "... you can build a new secure app without an ESAPI. But libs like OWASP ESAPI will get you there faster and cheaper....",  do we have peer-reviewed data that suports this claim? 

12) Is there a roadmap or how-to for companies that wish to adopt ESAPI.jar on an a) new application or b) existing real-world application'?

13) What about the current implementations of ESAPI for the other languages. Are we also recommending their use?

14) If a development team decides to use (for example) Spring and ESAPI together in their (new or existing) application, what are the recommended 'parts' from each of those APIs (Spring and EASPI) that the developers should be using? (for example: a) use Encoding from ESAPI, b) use Authentication from Spring, c) use Authorization from ESAPI, d) use Error Handling from Spring, e) use Logging from ESAPI, etc...)

Thanks

Saturday, 9 January 2010

Every API is (at some level) vulnerable

When doing source code analysis, one of the things that we tend to spend a lot of time talking about is if a particular API (i.e. function) is vulnerable or not (note that (whenever possible) I am a big believer of having working exploits for each unique "vulnerability pattern").  


But, when you look at the code, the reality is that as soon as a function has a capability (i.e. it is able to do something), most likely that function is going to be vulnerable to a particular type of attack or exploit. 


In most cases these vulnerabilities will be considered 'exploitable' when the function/application allows an remote attacker to do things that he is not supposed to do; manipulating HTML data or SQL queries, changing the behavior of the application, accessing non-authorized areas.


I quite like the picture where we visialize the application as a series of functions that have vulnerabilities on them and the exercise is to see if any of those functions connect to the outside world.  


A good example is a data-layer function that receives as string an SQL statement to execute (which btw most of the dotnet API's allow!). Note how that function is vulnerable by design to SQL injection! But the question is, can the attacker put a payload on it?  


I think that one of the good exercises to carry out, is to find out where the 'layers' of vulnerability are and start mapping them upwards (i.e via the functions that consume it), until you identify (or not) the problems.  


Even when you can't identify 'exploitable' problems, you probably will be able to identify when they were very close, or cases where they were one step away from creating a vulnerability.


Of course, that depending on the language (and C++ can be more problematic than .Net), you might want to raise those 'not really exploitable today' issues with a 'to fix asap' rating.  (you should also map systemic problems versus one-off problems).


From a secure design point of view, ideally, you want to see  APIs built in a way that they don't expose vulnerabilities to the outside world.  These API will wrap their internal vulnerabilities in a way that they actually are not vulnerable (i.e. even if the data consumed is maliciously controlled, it is not possible to exploit them)


For example, this is what (since .NET 1.4) Microsoft does with Code Access Security (CAS). They treat the CAS world (i.e. the partial trust world boundaries) as the attack surface.