When I talked about the tools I wrote for Owasp, I mentioned Owasp Orizon that it’s no longer updated since 7 months that it’s an huge amount of time.
Mainly because of mirage and Owasp ESAPI Ruby, the time I can dedicate to the project is very close to nil.

Before taking the action of declaring the project deceased, I’m calling a final deadline, 31 December 2011 with a very limited goal list.
Owasp Orizon will support only Java programming language and it will review the code for 2 security risks:

• XSS
• Injection flaws

No more.
I asked a friend of mine to give an help and it said ‘Ok’…

So, this is the source code repository… fork it… and help us to bring Orizon to be able to review the code for 2 security risks.

I’m Italian and as every latin person on this Earth I’m really passionate about what I love. I don’t want to give up on Owasp Orizon and I prefer to give a limited working tool than asking Owasp to delete the project.
So, please… help us.

It’s been a long time since last post and I had no work on Orizon since that.
Mainly because I changed my daytime job and I’m trying to start a freelancing career as software craftsman and appsec specialist.

As promised I actually continued working over project very connected to Owasp Orizon, the mirage engine. The ‘new’ mirage engine is a ruby port of the java counterpart you can find in Owasp Orizon 1.1x source code.

The idea is still to use the ‘new’ mirage with Orizon. Java and Ruby will talk each other since I’ll implemented an XMLRpc server (but I’ll do a REST version soon) into mirage so Orizon can talk to its newer engine in this way.

Next 8 February, I’ll be at Owasp Summit 2011 in Lisbon and I’ll engaged mainly for Owasp Esapi project but if anyone in that location would like to talk about Owasp Orizon, will be really great to me.

It’s better to admit that the overall project development is based on a best effort approach. Everyone has his own personal side projects, everyone has to drive his professional carrier and everyone has a family to take care too, of course.
What am I trying to say? The following:

• Q: Are you, Paolo, going to declare death the Owasp Orizon Project? A: Damn man, are you kidding me? No.
• Q: Are you Paolo going to leave the project in an orphaned state? A: You’re so funny. The answer is still no, I’ll do my best to achieve some valuable results in the very near future.
• Q: When the Owasp Orizon Project will be hitting the ground, helping the world to achieve a more secure code? A: I can’t predict the future. I can say that the updates you’ll find in this post will help me to be more productive in next goals, but I won’t drive a detailed roadmap anymore. It’s a failing action if you can’t work on your code everyday.

The first thing that drives me crazy and some Owasp fellows agreed to be a very key feature is the modeling engine.
The idea Stephen gave about relying on a parser generator is, of course, a winning one. But freecc parser generator seems to stall and the community support isn’t as strong as I supposed to be in a first time.
So, the idea is to rely on the more robust and widely accept as leader the facto parser generator: antlr.

Mirage is going to be completely rewritten from scratch, using antlr and its grammars. It will be a C language program.
I moved mirage to be a standalone project to achieve (I hope) more audience in the opensource developers community. Working on a multi language application modeler can drive on itself the attention by hackers and fellows that can be scared in working over a security static analysis tool. Yes, it seems that the word security keeps away developers. Don’t know why? I’ll check about this later.

So in the next months my energy will be directed to the mirage project. When we will have a reliable source code modeler, writing a security scan engine over it would be a quite affordable task.

Mirage will use redis as results storage during a scanning session so interaction between tools and the modeling engine will be as easy as possible.

So July is here.
Free time is lacking.
I’m working on other side projects and something more web oriented.
But mirage will be my summer project top priority.
And yes, we are not dead. Yet.

Some time ago, the Owasp Orizon engine was divided by its command line frontend, Milk.

It’s perfectly clear for anybody on this planet, that Milk project is dead and it’s not to be used anymore.

I received a bunch of months ago some emails from people interested in Milk. After I forwarded them to Owasp Orizon instead, they disappeared.
I hope they won’t be disappointed about Milk tool that I even don’t know if it’s running or not (and I don’t care about it).

So please if they’re reading this blog, give me a ping saying “Ehi, don’t mind. I used another tool, I stayed away form Milk crappy code”.

Since I’ve got a lot of code, and a lot of project to be published in the very next future, I chose github as platform and git as versioning tool.
Despite of the hype behind github, there is a great community over there and there is also the availability for some web space without the constraint of google’s wiki syntax. I hate wikis.

So this is the link you can find the project infos @github. Here users can follow updates, project lifecycle and most important downloads.
For people who wants to hack the source, this is the git url you can use to clone the project and start hacking.

Our language packs contain a parser/lexer pair generated with freecc tool. Freecc is a great tool but latest release is one year old and only few grammars are available in the wild.
Antlr is a parser generator far more difficult to use than freecc. However it is able to generate parsers in other languages than java and there are a lo of available grammars constantly updated and mantained.

Can be a straightforward decision to move mirage engine to use antlr in order to have more language packs available.

I think I’m going to move toward that direction.

But… ok… we’re live again and we want to deliver…

I purged a lot of stuff from build file. It won’t be possible anymore to regenerate language packs straight from the core build file. This is due to reflect the fact that language pack grammars don’t need to be updated so often.
So a developer who wants to hack the code have to launch freecc manually or using a shell script in the future I’m going to write. The trade off between having a lighter build system and having the grammars changed once a year is clearly for having a lighter build system.

So Orizon 1.30 has now a build number starting from 4 with ‘mint’ as codename.

​

The Jars created by the default ant target are the following

Basically, this code does… mmmh… nothing! It is a draft skeleton for Mirage engine and for Java/Jsp language pack. Remember that as we said in mailing list, the first goal is to support Owasp O2 Platform in modeling J2EE applications.
Mirage’s new look starts also from an identification phase that basically will try to figure it out the application kind and then model the application accordingly.

In the J2EE web app world, in example, Mirage will identify WEB-INF/web.xml file first and Mirage will found it, it will parse to figure it out the application starting page.
Than Mirage will start, parsing the JSPs first and then the business logic mergine together such information. This will give us the chance to better implement a good application model.

The same approach will be done also for .NET, Ruby on Rails, Grails, PHP after March 2010 first deadline (please look at Owasp Orizon mailing list archives for details).

We need a Maven Guru to fix pom.xml buils system…
Link: Owasp Orizon project feeds

To improve visibility and communication between the community, I will publish a montly report about the decisions take, what we done and which kind of help we need.

This is the first update.
In this slideshow we will discuss where do we start, the major goals to achieve and an improvement roadmap.

Check this out.