Design checks are about source file design (how many class are contained in a source? how many methods? what is the scope of the method A?).

+

−

+

−

=== source code statistics ===

+

−

&lt;design

+

The stats check XML schema has been changed from version 1.0, so this applies starting from version 1.1 and later

−

subj="stats"

+

&lt;stats

−

name=[loc | loC]

+

subj=[code | comment | complexity]

−

verb=[lt | gt | le | ge | ne | eq | ratio]

+

verb=[lt | gt | le | ge | ne | eq | ratio]

−

[ direct_object= [loc | loC] ]

+

[ direct_object= [loc | loC] ]

−

value=''numeric value''

+

[modifier = "percentage"]

−

/&gt;

+

value=''numeric value''

+

/&gt;

where:

where:

−

* name is the statistics name and can be one of the following:

+

* Subject can be one of the following:

−

** loc: line of code

+

** code: line of code

−

** loC: line of Comment

+

** comment: line of comments

+

** complexity: ciclomatic complexity index

* verb is the boolean comparison operator between the subject and the value:

* verb is the boolean comparison operator between the subject and the value:

Line 46:

Line 33:

** ratio: indicates the ratio subj versus direct_object

** ratio: indicates the ratio subj versus direct_object

+

== Design check ==

+

This is a work in progress section. Actually I'm collecting all the security checks coming from other tools and trying to figure it out the XML schema to use to

+

describe security checks.

+

thesp0nge, 07.12.2008

−

&lt;design

+

=== Classes ===

−

subj=[class|field|attribute]

+

−

name=''the subject name when appliable''

+

−

verb=[contains|count|has_scope]

+

−

value=''the value being checked''

+

−

/&gt;

+

−

&lt;design

+

&lt;design

−

subj="class"

+

subj="class"

−

verb=[extends|implements]

+

name=<i>ignored</i>

−

value=''the value being checked''

+

verb=[counts|contains|extends|implements|has]

−

/&gt;

+

direct_object=[scope|attribute]

+

value=''the value being checked''

+

&gt;

+

&lt;/design&gt;

+

The class design will be evaluated for the number in the source file, the classes it extends or implements and for modifiers such as scope and attribute.

+

With the <i>counts</i> verb, it will be evaluated how many classes are contained into a specific source file. For a non object oriented program, the class it will be ignored and inteded to be the whole program.

−

* keyword_check, about keyword specific checks

+

Example.

−

&lt;keyword

+

−

name=''keyword name''

+

If we need to have our J2EE applications comprised of source files containing 5 classes each, this is the correspondent security check

−

/&gt;

+

&lt;design subj="class" verb="counts" value="5" /&gt;

−

* execution_check: extra care must be taken for parameter in this desing...

+

The <i>extends</i> verb must be used if a security check needs to evaluate the class extended by the one being evaluated.

−

&lt;exec

+

−

caller_class=''a class name''

+

Example

−

caller_method=''a method name''

+

−

/&gt;

+

If a security check needs to evaluate if a class extends org.owasp.orizon.About, the check can be written using the following notation

verb is the boolean comparison operator between the subject and the value:

lt: lesser than

gt: grater than

le: lesser or equal than

ge: greater or equal than

ne: not equal than

eq: equal than

ratio: indicates the ratio subj versus direct_object

Design check

This is a work in progress section. Actually I'm collecting all the security checks coming from other tools and trying to figure it out the XML schema to use to
describe security checks.
thesp0nge, 07.12.2008

Classes

The class design will be evaluated for the number in the source file, the classes it extends or implements and for modifiers such as scope and attribute.
With the counts verb, it will be evaluated how many classes are contained into a specific source file. For a non object oriented program, the class it will be ignored and inteded to be the whole program.

The extends verb must be used if a security check needs to evaluate the class extended by the one being evaluated.

Example
If a security check needs to evaluate if a class extends org.owasp.orizon.About, the check can be written using the following notation
<design subj="class" verb="extends" value="org.owasp.orizon.About" />

The implements verb is the same as the previous except that the check is intended to be applied for interfaces or abstract classes the one being reviewed implements.

The has verb is the only one that makes meaningful the direct_object attribute with this rationale:

scope: the parameter to be evaluated is the class scope

Example
If in your organization you must check that all Java classes has to be public for such a reason we don't know to care about, you can write the security check this way
<design subj="class" verb="has" direct_object="scope" value="public" />

attribute: an attribute can be if the class is inner or not

keyword_check, about keyword specific checks

<keyword
name=keyword name
/>

execution_check: extra care must be taken for parameter in this desing...

<exec
caller_class=a class name
caller_method=a method name
/>

The Orizon Input file XML schema

Orizon 1.0 will bring 3 new subsystems in Jericho engine:

local analisys (control flow graph)

global analisys (call graph)

taint propagation analisys (data graph)

Each of this subsystems will use a different input file provided by the translator, so each source file will be translated in 3 different XML files with different schema of course.

Local analisys

Global analisys

Taint propagation analisys

This subsystem is devoted to analyze variable content and how data is managed by the application.

Here is the schema to be used to describe a generic operation over a variable or a socket or a generic I/O operation.