Entries in Fortify (3)


Building Fortify Custom Rules for Spring MVC

Looking for a Fortify rule that combines the power of structural rules with dataflow analysis capabilities? The (currently not well documented) CharacterizationRule is an awesome type of rule that will let you go beyond the restrictions of traditional dataflow analysis rules by allowing you to define dataflow parsing instructions based upon a code structural match.

Here’s an example of a rule, used against a Java Spring controller class, that will identify tainted data from parameters mapped using Spring specific annotations. This can be used to identify XSS flaws using static analysis that were only previously identified through dynamic testing.

<CharacterizationRule formatVersion="3.17" language="java">
        Function f: f.parameters contains [Variable v: v.annotations[0] matches "org.springframework.web.bind.annotation.RequestParam" ]
        TaintEntrypoint(v, {+XSS})

Used on a class similar to the following, this would essentially add the taint flag ‘XSS’ to any parameters specified with the @RequestParam mapping annotation (fully qualified class names being required) contained within the query string of the requested controller.


@RequestMapping(value = "/url")

public class PageController  {

@RequestMapping(value = "/action", method = RequestMethod.GET)

public String action(@RequestParam(value = "q", required = false) final String parameter )  {

As mentioned earlier, this type of rule is currently not fully documented but some syntax guidance is available within Fortify SCA’s structural type system documentation. You can also leverage the Fortify custom rule editor to benefit from syntax completion and XML structure validation.


Early Look at Tracer 2.0 Beta 

So, continuing in the vein of testing Fortify's various Beta products (see Andrew's SCA 5.0 sneak peak), I recently got to work with the Fortify Tracer 2.0 beta, which I've gotta say was very interesting. If you're not familiar with Tracer, here's a little background - out of the box, Tracer inserts monitors into your deployable code, tracks all known inputs, and flags instances where the use of certain API's with those inputs are either un-validated or used in an insecure manner. This sets the table for more thorough coverage when you're performing Black Box testing. It is well known that many "set and forget" automated scanners almost never hit every available page which leads to gaps in testing and lots of frustration. Tracer fills those voids and is especially handy for performing Black Box app testing when in a time crunch.

Older releases of Tracer were ideally geared towards use by security professionals. However, with Tracer 2.0, the user only needs to be able to crawl the entire application. Whether it's manual or automated, no penetration testing procedures are needed. This is a bonus for those non-security professionals that want to be able to easliy add this tool to their pre-deployment check-list.

Another nice addition included in Tracer 2.0 is the increased ease of setting up the tool. Previously with Tracer 1.1, you would run the compile-time instrumentation against your J2EE executable (deployable WAR or EAR file) using the supplied command line tool. You would then have to manually deploy the WAR file that you just instrumented into your environment.

Example of 1.1 command line syntax:
C:\>tracer.bat -a Tomcat5 --appserver-home "C:\Program Files\Fortify Software\Fortify Tracer 1.1\Core\tomcat" --coverage "com.order.splc.*" splc.war

Tracer 2.0 Beta has made the instrumentation process MUCH easier. They've introduced a new method called "load-time weaving," where the monitors are introduced when the class files are loaded rather than before the application is deployed. This makes for a very fast instrumentation process and you don't have to redeploy your application anymore.

To instrument using load-time weaving, Tracer 2.0 comes with an app called Tracerltw (Figure 1). This web application allows you to just give it the web root directory of the application you want it to monitor. Users will find this point and click instrumentation much easier and more intuitive than the previous command line options.


Figure 1 ' Tracerltw application

Another nice feature is support for .NET applications. Previous releases were strictly limited to J2EE applications. In general, Fortify seems to be broadening their language coverage for all their products. Just look at SCA 5.0 and its support for 4 more languages.

This is a very green beta, so as new functionality comes out in future beta releases, I'll keep you updated.


Fortify Partner ' SCA 5.0 Sneak Peak

Just got through attending a Fortify webinar where J.B. demo'd the latest beta 5.0 version of SCA. Firstly, it was very impressive.

Language support has now been added for classic ASP, COBOL, JavaScript and PHP, along with several new analyzers, a couple of which are interestingly aimed at "deviation" and false path detection.

However, one of the most apparent changes is the continual evolution of Audit Workbench (AWB) from a predominantly result's only /verification tool towards a true one stop "work bench". This includes new "right-click" custom rule generation (complete with slick and more intuitive interface) which will dramatically speed up new rule generation based on what is appearing in the code. Of course, the ability to then easily re-run scans from within AWB follows on nicely to help verify new rule accuracy.

More detail to follow once we get our hands on a 5.0 beta version. The current full 5.0 release timeframe appears to be towards Dec/Jan, - further new feature information can be found on the Fortify site.