Topic
  • 2 replies
  • Latest Post - ‏2011-07-14T14:28:14Z by SystemAdmin
SystemAdmin
SystemAdmin
49 Posts

Pinned topic MVC Framework support

‏2011-07-06T13:53:59Z |
Ok, here's a toughie :p

Can you provide some information on what MVC frameworks are supported by AppScan Source? I mean frameworks like Struts, Spring, JSF, flex, etc. On what level are they supported? ie. In which versions (developer plugins, Security Analyst, etc.) and what does the support provide?

Any information you can provide for both versions 7 (fully patched) and version 8 (any sub-version) would be greatly appreciated.

If there is a webpage devoted to this, feel free to just point me to it - I couldn't find one.

Thanks!
Updated on 2011-07-14T14:28:14Z at 2011-07-14T14:28:14Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    49 Posts

    Re: MVC Framework support

    ‏2011-07-06T16:02:46Z  
    Greetings Hoy,

    Unfortunately, I don't have the hard data you're asking for organized by release handy.

    I'll be happy to share with you what I do know:
    1. For all versions of AppScan Source up to 8.0.0.2 the scans are identical in Security, Dev Plugin, and Automation versions, so you don't have to worry about that. (In a future version, additional "quality" checks may be phased in to the product components in stages - those checks will be optional).

    2. When we say that we support a framework, we usually mean that we can perform data flow analysis into and out of the framework (at a minimum). There are a few frameworks which are really big and which might have half a dozen ways in which they can be implemented, in which case we occassionally implement support for that framework in stages and get results of varying quality for different applications scanned. Java Spring MVC for example is a beast of a framework which an evolving landscape of features and ways it can be implemented.

    3. In 8.0, we built a technology called the "Framework for a Framework" ("F4F"), which is an abstract meta-framework used by our product to describe frameworks written by others. This is implemented using a custom XML descriptive language called the "Web Application Flow Language" ("WAFL") which details how data will flow between components in the framework within a particular application. This technology was developed in a partnership with IBM's Watson research lab (and probably other research labs too) and is protected by several patents. Now that we have the nuts and bolts of F4F in good order, we expect to add high quality framework support at an even faster pace than we were able to in the past (we used to build framework support one at a time as "one-off" implementations). The first two frameworks we built support for in F4F were Spring and Struts (though those had both been supported for ages). There are several more frameworks either completed in the development stream or under active development including EJBs, .NET MVC, and others. And of course there is a roadmap for future frameworks - if you have any particular frameworks you want to see supported let us know because customer requests drive the order of implementation.

    4. This bullet point might sound a bit salesy so prepare yourself, but rest assured there is actual technical meat in here. AppScan Source has some features which are conspicuously absent in our competitors' products in the area of allowing users to build support for a framework. For example:
    a) Users can create "custom rules" through a simple GUI interface (no need to learn a new programming language). Those rules can specify how to handle data coming from or going to a framework (or dependency like a .jar or .dll). So let's say we don't support the XYZ framework either because it isn't common or because your organization wrote it and IBM has never seen it. In either case, you can mark the methods which are Sources of tainted data, Sinks which are vulnerable to attack if an attacker can get tainted data to them, Validators, known Non-Validators, and so on. For a simple to moderate framework this takes less than an hour - which is pretty remarkable considering it probably took the developers hundreds or thousands of hours to write that framework, and a pretty powerful feature that most of our competitors' products lack entirely or have implemented only half-way.
    b) Those custom API rules I just described are stored in the Core server and are distributed automatically and transparently to all of the scanning clients so you get consistent results whether you scan in Dev, Security, or Automation environments. This helps avoid rule versioning chaos, and saves you the trouble of having to implement your own rule distribution system based on copying files around your network. Personally I think this feature is awesome because it means you can have 1 smart analyst increasing the security of your entire enterprise, decreasing false positives and false negatives and limiting re-work with ease.
    c) Another neat feature is that if we're analyzing an application and we see data flow out of it into an unrecognized framework or dependency, we DO include a Finding for that and let you know that this has occurred (these findings are called "Lost Sinks" if you want to read up on them). This gives you the opportunity to create markup and improve your results. AFAIK, all of our competitors silently drop such data flow traces leaving you with significant false negatives and a false sense of security. Of course, you could simply ignore them in AppScan Source and you'd be on the same (shaky) footing as our competitors if you wanted. One of our consulting partners said, "this one feature means that I can actually use this product to do a code review and stand by the results. With (that other product) you have no way of knowing what you're missing."
    Well, I hope that helps!

    Send me direct message if you have any questions about specific frameworks you're using.

    Cheers,

    /eh
  • SystemAdmin
    SystemAdmin
    49 Posts

    Re: MVC Framework support

    ‏2011-07-14T14:28:14Z  
    Greetings Hoy,

    Unfortunately, I don't have the hard data you're asking for organized by release handy.

    I'll be happy to share with you what I do know:
    1. For all versions of AppScan Source up to 8.0.0.2 the scans are identical in Security, Dev Plugin, and Automation versions, so you don't have to worry about that. (In a future version, additional "quality" checks may be phased in to the product components in stages - those checks will be optional).

    2. When we say that we support a framework, we usually mean that we can perform data flow analysis into and out of the framework (at a minimum). There are a few frameworks which are really big and which might have half a dozen ways in which they can be implemented, in which case we occassionally implement support for that framework in stages and get results of varying quality for different applications scanned. Java Spring MVC for example is a beast of a framework which an evolving landscape of features and ways it can be implemented.

    3. In 8.0, we built a technology called the "Framework for a Framework" ("F4F"), which is an abstract meta-framework used by our product to describe frameworks written by others. This is implemented using a custom XML descriptive language called the "Web Application Flow Language" ("WAFL") which details how data will flow between components in the framework within a particular application. This technology was developed in a partnership with IBM's Watson research lab (and probably other research labs too) and is protected by several patents. Now that we have the nuts and bolts of F4F in good order, we expect to add high quality framework support at an even faster pace than we were able to in the past (we used to build framework support one at a time as "one-off" implementations). The first two frameworks we built support for in F4F were Spring and Struts (though those had both been supported for ages). There are several more frameworks either completed in the development stream or under active development including EJBs, .NET MVC, and others. And of course there is a roadmap for future frameworks - if you have any particular frameworks you want to see supported let us know because customer requests drive the order of implementation.

    4. This bullet point might sound a bit salesy so prepare yourself, but rest assured there is actual technical meat in here. AppScan Source has some features which are conspicuously absent in our competitors' products in the area of allowing users to build support for a framework. For example:
    a) Users can create "custom rules" through a simple GUI interface (no need to learn a new programming language). Those rules can specify how to handle data coming from or going to a framework (or dependency like a .jar or .dll). So let's say we don't support the XYZ framework either because it isn't common or because your organization wrote it and IBM has never seen it. In either case, you can mark the methods which are Sources of tainted data, Sinks which are vulnerable to attack if an attacker can get tainted data to them, Validators, known Non-Validators, and so on. For a simple to moderate framework this takes less than an hour - which is pretty remarkable considering it probably took the developers hundreds or thousands of hours to write that framework, and a pretty powerful feature that most of our competitors' products lack entirely or have implemented only half-way.
    b) Those custom API rules I just described are stored in the Core server and are distributed automatically and transparently to all of the scanning clients so you get consistent results whether you scan in Dev, Security, or Automation environments. This helps avoid rule versioning chaos, and saves you the trouble of having to implement your own rule distribution system based on copying files around your network. Personally I think this feature is awesome because it means you can have 1 smart analyst increasing the security of your entire enterprise, decreasing false positives and false negatives and limiting re-work with ease.
    c) Another neat feature is that if we're analyzing an application and we see data flow out of it into an unrecognized framework or dependency, we DO include a Finding for that and let you know that this has occurred (these findings are called "Lost Sinks" if you want to read up on them). This gives you the opportunity to create markup and improve your results. AFAIK, all of our competitors silently drop such data flow traces leaving you with significant false negatives and a false sense of security. Of course, you could simply ignore them in AppScan Source and you'd be on the same (shaky) footing as our competitors if you wanted. One of our consulting partners said, "this one feature means that I can actually use this product to do a code review and stand by the results. With (that other product) you have no way of knowing what you're missing."
    Well, I hope that helps!

    Send me direct message if you have any questions about specific frameworks you're using.

    Cheers,

    /eh
    Thanks for the quick response, Eric!