Saturday, 2 October 2010

With O2, I am a Curator of Open Source Software

A couple days ago I saw the amazing and highly recomended Jason Fried Web 2.0 Keynote – Be a Software Curator video presentation (from 37 Signals) where Jason made the argument that as software developers we have to be curators (as in a Museum Curator) when selecting the features we chose to implement for the software or web applications we are developing.

In that presentation, one of his strongest analogies is the fact that Software has no physical properties (as in weight, shape, smell, transparency, etc...) which makes it very hard for its users to provide immediate feedback on the software/webapp they are about to use, and, more importantly, it denies the developers with valuable information on how well ‘designed’ their application is (not designed as in 'look-and-feel + graphics', but ‘designed’ as in ‘Design the experience’)

This means that we as software developers must be very disciplined on which customers/users we listen to, and what we decide to do with our limited development resources.

And this is exactly what Curators do in Museums. They understand what their target audience wants, they find the artists + exhibitions items that match his/hers (the Curator) vision and then finally he/she ‘Designs’ the user experience in order to maximize the user’s benefit from attending the exhibition.

After thinking about this concept for a while, I realized that it also fits very well with what I try to do in the O2 Platform when I:
  • have a particular problem (let’s say I want to automate a Browser workflow/exploit/UnitTest), 
  • do a research on the currently available Open Source tools that could address that problem (Selenium, WatiN, .NET Browser Control, multiple CodePlex projects, etc...), 
  • try a couple that look like the best fit (writing APIs to help consuming them) 
  • use these APIs in real work engagements 
  • based on the success use of the original API + O2 Customizations (and Extension Methods Wrappers), arrive at a conclusion on which one is the best Open Source API to use (in this case WatiN) 
  • Package the chosen API in easy to use modules that are then exposed to the wider O2 community 
And since just about everything in O2 is a Script, the added value provided by O2 is the fact that its dynamic scripting/packaging environment is able to dramatically simplify the use and consumption of the chosen Open Source API

Basically, I’m a Curator for Open Source with the responsibility to research, test, select and customize APIs to solve specific Web Application Security problems.

Friday, 1 October 2010

Using O2 to Parse WSDL files and submit requests/payloads

The .NET's  SDK comes with a tool that creates a C# file from a WSDL (which is what Visual Studio uses when adding a Web Reference).

This file can can then be used to automatically enumerate methods + parameters, and provide nice C# stubs to send requests or fuzz payloads (and that is just a warm up on what you can do with it).

O2 has support for WSDL creation via this script: http://code.google.com/p/o2platform/source/browse/trunk/O2_Scripts/Languages_and_Frameworks/DotNet/DotNet_SDK_WSDL.cs

To see it in action here is a example of how to consume it using O2's C# Scripting Environment http://www.o2platform.com/index.php/DotNet/WSDL

Great Comments on the O2 Subscription Model

OWASP Leader Michael Coates had a some great comments on the O2 Subscription model when I asked a while back if it was compatible with OWASP's values and mission.

Here are his words (slightly edited since the original version was commenting on the previous version which had a couple extra OWASP membership related items):

"...To my knowledge, this is the first OWASP project that has attempted a financing model.  It is important for us (OWASP leaders) to be open and communicate the correct ways for OWASP projects to offer services that are not free.  Below I've included the OWASP principles and my thoughts on their relation to Dinis's idea.

OWASP Principles -
http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project

Free & Open

As Dinis mentioned, his code is open to everyone at no charge.  The O2 tool can be downloaded and used without paying any of the subscription fees. No problem here.

Governed by rough consensus & running code

Not relevant to this issue except that the overall consensus of the OWASP leaders should be considered.

Abide by a code of ethics

No problems here

Not-for-profit

OWASP itself is not for profit. But what about individual projects? The O2 project is rightfully (in my opinion) charging for Dinis's time to offer premium support to commercial customers. Many of us, Dinis included, volunteer large amounts of time to OWASP. However, volunteering and providing commercial grade support or two totally different things. This is a fine move in my opinion.  Many companies will not adopt an open source software if a formal support policy cannot be established.  So although I don't personally have any problems here, how do we reconcile this situation with our principles?  Perhaps the answer is related to point #2 (rough consensus) and this sort of email discussion

Not driven by commercial interests

Although O2 technically would become "commercial" in a small way I don't see any problem here. This item is meant to address the overall objectivity of OWASP in always promoting the best security advice that is not tainted by a particular company's motivation.

Risk based approach
Not a problem. In fact
O2 reinforces this principle.


Overall I think Dinis's approach to a
subscription model for support is not a problem. This model is used by other open source organizations such as red hat (https://www.redhat.com/wapps/store/catalog.html). In fact, if we want OWASP to continue to grow then I think we need to support these types of initiatives. Otherwise our tools and processes may be ignored by many companies that require these types of formal relationships.

...

 
Conclusion

  • I support Dinis's plan to offer a subscription service for commercial support of O2 and believe this type of model is necessary to take OWASP projects to the next level
  • I believe this is inline with OWASP principles
  • ....

..."


Update on O2 Subscription Model

Following the feedback received when I pushed the first version of the O2 Subscription model , I've made a number of changes which should be a better fit for the community and target user base.

As before, there are 3 Subscription levels, but this time around there is much bigger focus on the creation and support of an customized version of O2 for each subscriber (and based on the comments made I removed the OWASP-related options)

Here is a table that represents the new model:


Currently there are 3 companies subscribed and I'm working with them on their custom version of O2.











For more details see this  O2 - Commercial Services presentation or visit the O2 Subscriptions page at the O2 Website
------------------------------------------------
Important note: this is NOT a service provided by OWASP and the OWASP foundation has no direct involvement or responsibility in the delivery or fulfillment of these subscriptions

Sunday, 26 September 2010

Why do we think we can comment on the 'easiness' level of XSS?

Here is an important question: "What gives Security Consultants the right to comment on how 'easy' it is to fix an XSS vulnerability?"

After all, it is not the Security Consultant's that:

1) needs to figure out:
- the root-cause analysis of the XSS reported?
- where it should be fixed?
- what is the REAL impact to the business?
- what are the side effects of applying the code changes?
2) has to make business case to fix it (and delaying XYZ feature)
3) has to actually fix the vulnerability
4) will be fired if the fixed is applied wrongly
5) will be the one that has the deal any side-effects created by the fixes
6) has to pay for it

Surely the only people qualified (and entitled) to make this 'easiness' assessment (i.e. of how 'easy' it is to fix a particular vulnerability) are the application developers and business owners!

Now think about how it must feel from the other side (i.e. the developers) when we (security consultants) tell them that it is 'easy' to fix what we just reported them.

And just to add insult to injury, we also like to tell them (the developers) that they need 'Training' (i.e. "...we think that you should go back to School and learn about security before you are allowed to write more code...")

It is 'easy' to say that that is 'easy' to fix...

... specially by the crowd whose responsibility ends when the problem/XSS is reported


How many 'easy-to-fix' XSS have we fixed in the last 12 months

On the topic of 'easy-to-fix' XSS, one question that we should be able to answer (as an industry) is 'How many of those easy-to-fix have been actually fixed and pushed into production'.

After all, if they are 'easy' to fix (and cheaper to create,test, deploy, etc...) surely that means that the affected parties (application owners and developers) will have very little resistance in doing those fixes, right?

So where can I find these numbers? What I am after are three values:

1) # number of 'easy-to-fix' XSS discovered on real-world applications
2) # number of 'easy-to-fix' XSS discovered that were actually fixed and pushed into production
3) % of XSS discovered that fall into the 'easy-to-fix' category

If we don't have these numbers, how do we know we are being effective? and that they are indeed 'easy-to-fix'

On a Twitter thread after my previous blog post, Chris from Veracode commented that he guesses (i.e. no hard-data) that about 50% of the 'easy-to-fix' XSS that they have found at Veracode are now fixed and deployed into production.

Even assuming that that 50% number is correct (which looks a bit high to me, and if I remember correctly WhiteHat's numbers are much lower), shouldn't the 'easy-to-fix' number be much higher? After all they are 'easy-to-fix'

.....

As you can tell by my use of quotes on the 'easy-to-fix' concept, I don't buy that fixing XSS are easy to fix.

Even in the cases where the 'fix' is 'just' applying an encoding to particular method (let's say from Response.Write(Request["name"]) to Response.Write(AntiXSS.HtmlEncode(Request["Name"])) ) there is a big difference between 'making a code change' and 'pushing it into production'.

Here is a quick list of what should happen when a developer knows about an 'easy-to-fix' XSS vulnerability:

1) XSS is discovered by security consultant
2) XSS is communicated to the development team
3) Development team analyse the XSS finding:
- reproduce the XSS reported
- discover what causes the XSS (root-cause analysis)?
- what is the DOM context of the XSS injection point (Html, Attribute, Javascript block, CSS)
- was it a single instance/mistake or is it a systemic flaw?
- where can it be fixed?
- of the multiple places it can be fixed what is the one with the least impact?
- can it be solved/mitigated without making code changes, for example using an config setting or a WAF? (i.e. virtual patching)
- is there a clear understanding of the side-effects of applying the fixes?
- are there cases (or potential) for double encoding problems? (i.e. is there understanding of all the code + data paths that lead to the location of the fix?)
- were other parts of the application created with the assumption that there would be no encoding on that particular field? (which will break once the fix is applied)
- who is going to pay for the fix? the developers? the client?
4) Once a strategy is created to fix the XSS, put it on the development schedule and apply the fix
5) Test the fix and make sure:
- that the XSS was correctly resolved/mitigated (who will do this? the current testers/developers that were not aware of the XSS in the first place, or the original security consultant?)
- is there any business impact (i.e. does the application still behaves the same way and there is NO user-experience impact). Ideally this should be done by the QA team
6) Deploy the fix into production

(note that this is a simplified version of what tends to happen in the real world, since there are many other factors that affect this: from internal/external politics, to management support for security fixes, to lack of attacks, to the fact that the original team that created the application is long gone and the developer allocated to do the 'easy-to-fix' change doesn't really know how the application he/she is about to fix actually works,etc...)

Some would call the above process 'easy-to-fix' ....

For me 'easy-to-fix' code changes (if there is such a thing) are actions that:
- don't take much time,
- the amount of work (and side effects) that needs to be done is easy to understand/visualise
- are cheap
- can be deployed into production quickly and without worries
- DON'T have any potential to create business/user impact (this is the most important one)
- are in essence, invisible to just about all parties involved

I think the crowd that calls XSS 'easy-to-fix' are confusing 'looks easy to make the code change that I think would work' with 'making a code change that accurately resolves the reported problem without causing any impact to the application' (which is what matters to the developers/business-owners)

My fundamental problem with the 'easy-to-fix' concept is that it is calling the developers (and application owners):
- names (as in: "you guys are stupid for not fixing those problems, after all they are 'easy-to-fix'),
- it is alienating them, and
- it is showing them that we don't have a very good idea on how their applications and business work.

To see a more detailed explanation of this gap between security consultants 'recommendations' and what the business/developers think of it, see John Viega's Keynote at OWASP's AppSec Ireland conference

Saturday, 25 September 2010

Can we please stop saying that XSS is boring and easy to fix!

XSS (Cross Site Scripting) is probably one of the harder problems to solve in a web application because fixing it properly implies that one has a perfect understanding of what is 'code' and what is 'data'

The problem with XSS (and most other web injection variation) is that the attacker/exploit is able to move from a 'data' field into a 'code' execution environment.

So saying that XSS is easy to fix and eradicate is the same thing as saying that Buffer Overflows are easy to fix and eradicate.

Also, saying that we know how to solve XSS is a red-herring because we DON'T know how to solve it. What do know is how to mitigate it and for the cases where we DO understand were we are mixing code and data, we can apply special protections.

But even today, in 2010, protecting against XSS is something that the developers MUST do, versus something that happens (and is enforced) by default by the frameworks/APIs used.

Take .NET for example. Although there is quite a lot of XSS protection in the .NET framework (auto-detection against common XSS exploits, most controls have auto-encoding by default, etc...) we still see a lot of XSS on ASP.NET applications. The reason these exists is because it is very hard for developers to have a full understanding of the encoding and location of the outputs they are creating. And until we solve this 'visibility' problem, we will not solve XSS

On a positive note, the SRE (Security Runtime Engine) that ships with the Anti-XSS API is an amazing tool because it transparently adds encoding to .NET Web Controls (and it takes into account double encoding problems which is what makes it amazing)

The only way we will ever start dealing properly with XSS is if:
a) the framework(s) developers use have context-aware-encoding on ALL outputs
b) there is no easy way to write raw HTML directly to the response-stream
c) there is no easy way for developers to mix HTML code with Data
d) when HTML needs to be created programatically, that needs go be outputted via an HTML DOM aware encoding API/method (like the ones that .NET AntiXSS has)
e) there are static analysis rule packs for each of the frameworks that document (in rules) the programmatically combinations that make XSS possible (in that framework/API)
f) the developers have immediate (or before checking-in code into production) feedback when they create an XSS in their applications
g) web applications have a communication channel with browsers, which will allow browsers to better understand what is code and what is data (Mozilla CSP is a great step in this direction)

The key to really deal with XSS is e) and f) , since these take into account the scenario that developers will mix code, and even in the best designed APIs/Frameworks there will ALWAYS be combinations that create XSS. Also, without this understanding of the data/code mappings (which is where XSS lives) we will struggle to create mappings for g)

One of my key strategies when developing the O2 Platform was to create an environment that helps the creation and propagation of these 'Framework Rule Packs', since from my point of view, every version of every framework (and APIs) will need one of theses Rule Packs.

Remember that: security knowledge, that is not available, in an consumable format by tools or humans, AT the exact moment when it is needed (by developers, system architects, etc...), is almost as good as non-existent.

For example: "... an MSDN article that explains that the FormsAuthentication cookie is not invalidated on logout... " is not good enough

what we need is an "...alert or note that only appears when the developers use FormsAuthentication that explains (with PoCs) the fact that (on sign out) the only thing that happens is that the client side cookies are deleted from the user's browser...". The PoCs (dynamic or static) are very important in this example, since in most cases the real vulnerability will only be relevant in more feature-rich versions of the application.

Bottom line: Solving XSS means solving the separation of Code vs Data in web applications

And THAT ... is something that we are still quite far off

Monday, 9 August 2010

New O2 Subscription Model


------------------------------------------------------------------------------------------
In order to fully support to the companies that commit to using O2 and use it on commercial engagements, the following subscription-based services are now available:
Bronze : 1,000 USD per Quarter
  • Certified Monthly Build (with some customization of modules included)
  • Monthy Documentation (with some customization of modules included)
  • 1x copy of O2 Book(s) (when released)
  • 1x shared amazon EC Image (containing latest version of O2 and demo files)
  • Private discusion forum
  • 1x OWASP Individual Membership
  • Officially recognized as 'O2 Platform BRONZE Service Provider'
Silver: 5,000 USD per Quarter
  • Certified Monthly Build (with major customization of modules included)
  • Monthy Documentation (with major customization of modules included)
  • 3x copy of each O2 Book(s) (when released)
  • 3x shared amazon EC Images + 1x dedicated amazon EC Image (containing latest or the customized version of O2)
  • Private discusion forum (with 10x priority tickets)
  • 4h of Personalized Training (remote)
  • 2x Tickets to an OWASP Conference
  • 5x OWASP Individual Membership
  • Officially recognized as 'O2 Platform SILVER Service Provider'
Gold: 15,000 USD per Quarter
  • Certified Monthly Build (with customization of modules included and GUI Branding)
  • Monthy Documentation (with customization of modules included and GUI Branding)
  • 5x copy of each O2 Book(s) (when released)
  • 5x dedicated amazon EC Image (containing latest or the customized version of O2)
  • Private discusion forum (with 20x priority tickets)
  • 2 days of personalized training (either remote or locally (if logistically possible))
  • 5x Tickets to an OWASP Conference
  • 1x OWASP Corporate Membership (with the 40% of 5000USD membership allocated to the O2 Platform)
  • Officially recognized as 'O2 Platform GOLD Service Provider'
These subscription can be started or canceled at any time, and could follow periods of increased activity around O2. 

For custom or focused O2 development see the O2 Pledges
Note that this is NOT a service provided by OWASP and the OWASP foundation has no direct involvement or responsibility in the delivery or fulfillment of these subscriptions

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

OWASP/O2 US Tour Aug 9-17 (6 cities in 8 days)







Hi I'm about to embark on a great adventure and I hope you will be able to join me along the way.

For the next 8 days I will be traveling to 6 US cities, visiting the local OWASP chapter and doing OWASP/O2 presentations. This is also a great opportunity to meet a number of local chapter/project leaders and have a number of brainstorming sessions on OWASP.

Here is my itinerary:

If you are around this area and want to meet up to talk about OWASP or O2, then ping me directly and lets make it happen

See you on the road......

Friday, 30 July 2010

What is going on with you (Jul 2010) and are you at BlackHat / DefCon?

Since I have a number of similar questions on my Inbox, it will be easier to reply to them here :)

No, I'm at at BlackHat and DefCon (I'm an independent contractor now so I have no company to send the bills to and I was not able to get O2 to generate enough revenue to organize a BH/DC gathering)

Regarding what has been going on, here is a selection of blog posts that cover the last couple months:

O2 Platform, ideas on where to start


If you want to delve deeper into O2's world I would say that your first step is to replicate the BlackBox and WhiteBox examples that I have already created and published with O2 (check out the Demo's Tab in the main GUI).

Some pointers:
  • If you are on a 32bit box, I would recommend  that you use the latest version of O2 (which is only available via the ClickOnce install ) since it as a ton of new features
  • Install HacmeBank and WebGoat locally
  • Write a BlackBox script to exploit an SQL Injection in HacmeBank and an XSS in WebGoat
  • From HacmeBank's Source Code, build its MethodStreams and find the SQL Injections on the WebServices, and connect the WebLayer with the WebServices Layer
  • Transform the above scripts in Unit tests
  • Create a document with your experiments containing tons of screenshots about it
  • Create a video with your experiments (and publish it, or send it to me)
If you have any issues, join the O2 Platform mailing list and ask a question.

There is also an Amazon EC2 image that I have with O2 fully configured which I can give you access if you ping me directly

Wednesday, 28 July 2010

New funding model for O2's Development


This is the first of a series of blog entries that I will write on the topic of "O2 Funding model and the multiple Business Modules that are (in my point of view) 100% compatible with O2's Open Source positioning."
----- (content from the current version of  http://o2platform.com/wiki/O2_Pledges
With the objective to create a funding source for O2's development, the following Pledges have been set-up at Pledgie.com:

O2 Specific

Framework specific

Industry sector specific


Not an OWASP activity
Please not that the above pledges are NOT OWASP driven activities and OWASP has no responsibility on the allocation of the funds pledged. This is an experiment to see how this model could be used to generate funds for OWASP Projects.


Thursday, 8 July 2010

First major release of the OWASP O2 Platform - please download and try it

After 6 months of dedicated development, I'm happy to announce that I finally published a first major release of the OWASP O2 Platform (with an installer, documentation+videos and a number of key/unique capabilities).

There is a brand new GUI which makes a massive difference in finding the available scripts, tools and APIS that exist inside O2 (if you tried the previous versions you will really appreciate this) . You can see the new GUI and access the download link at this page: http://www.o2platform.com/wiki/O2_Release/v1.1_Beta 
This is the moment when I'm asking you to PLEASE TRY IT, and provide feedback on: what you like, what works, what doesn't work, what could be improved, etc... (if you want to file a bug, please use this web interface http://code.google.com/p/o2platform/issues/list)

There is enough functionality + capabilities + power in this version of O2, that I finally have the confidence to make this direct request for you, knowing that no matter what area of Web Application Security you are involved in, there will be an O2 Script/Module/Tool that will make you more productive.

Since the new GUI is very recent, most documentation and videos available start with the previous GUI. But since I can now easily create detailed WIKI documentation pages and/or videos using O2 , my plan is to reply to your questions that way (i.e. with a video or wiki page)

In addition to the new GUI, there are a number of key O2 features and capabilities that I was finally able to piece together last week (for example the creation of a 'complete trace+animation for an HacmeBank vulnerability' packaged as a UnitTest). I will be documenting these in the next days/weeks. I will also be posting soon details about a new funding & commercial-services model for O2 and 3rd party companies.

So, have a go, try it and please post on this list as much details on your 'O2 experience' as possible.

Thanks for the help

I'm looking for work (O2 related work :) ) and O2's Commercial Ecosystem

Now that the OWASP O2 Platform is finally ready for a wider audience, I'm focusing on my next challenge which is to create a vibrant and healthy commercial ecosystem around O2.

Since I'm probably the only guy in the world that today really knows how to get the most power out of O2, and, the one that is able to successfully use it in real-world commercial engagements, if you are looking to hire an O2 expert, the best person for you to hire is me (as you can see below, as the O2 Ecosystem grows, I will also put you in touch with other O2 experts)

Of course that I don't scale, and there is only a small number of security engagements that I can be involved at any given time.

My objective in personalising this request, is so that I can be exposed to new 'O2 related business' opportunities, which I will then push/expose to existing consulting security companies and/or security tool vendors.

Why? Because the higher the 'O2 related revenue streams' that these companies have, the more they will invest in O2 (namely the more time and effort they will put into integrating O2 into their current technology and business practices).

The challenge is how to kickstart this process?

My plan is to:

- Use me (as main O2 developer and reputable (I hope) security consultant) to attract clients that need application security reviews and expertise
- Funnel most of these 'O2 related' engagements to existing 'O2 Platform Accredited Service Providers' and work directly with them in the first couple engagements
- Create a number of 'non services related' revenue streams for O2, which I will then use to build a solid development and support team for O2

So, if you ever wanted to hire me to work on an security engagement or have a problem that you fell O2 can solve, now is the perfect time to talk :)

If you are a security consultancy company and want to be one of these 'O2 Platform Accredited Service Provider', drop me a line or wait for the announcement of how the process will work.

Update on OunceLabs+IBM story and "OWASP O2 Platform is ready for you (after 6 months solid development)"

So what is happening with the OWASP O2 Platform, with me, and why am I only writing this blog post now? (7th of July 2010)

For the past 6 months I have been following an opportunity that I was given by the IBM purchase of OunceLabs and the previous Open Sourcing of my research on static analysis (originally on top of the OunceLabs engine).

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