Comments on: Sprajax? Security Scanner for AJAX http://www.pathf.com/blogs/2006/05/sprajax_securit/ Running commentary about agile development, user experience design and Ajax. Wed, 08 Oct 2008 06:49:21 +0000 http://wordpress.org/?v=2.5.1 By: Dan Cornell http://www.pathf.com/blogs/2006/05/sprajax_securit/#comment-715 Dan Cornell Thu, 01 Jun 2006 18:28:37 +0000 http://www.pathf.com/blogs/?p=559#comment-715 <p> I wrote the sprajax tool so I thought I would respond. That is a fair assessment of the tool in its current state. This is certainly an “alpha” release but work is progressing. Next up for sprajax:</p> <p> -Remove requirement for SQL Server 2005 - this is a huge barrier to getting more folks using the tool and being able to look at historical scan data from a database is a lower priority at this point than making it easy to get up and running.</p> <p> -Add support for the Google Web Toolkit. The interfaces for detecting, footprinting and then fuzzing frameworks need a little bit of work, but the goal is to make these fairly generic and modular so that it is easy to add support for additional AJAX toolkits. I suspect that once I have Atlas and GWT working it will be much easier to add support for DWR and others. And it should also be possible at this point to add more scanning for other non-framework-defined endpoints for additional fuzzing.</p> <p> I would however disagree that looking for known exploits would be a better approach than the fuzzing sprajax does right now. Tools like Nessus and Nikto already serve this function quite well - they can tell you if your server is misconfigured or using out of date software. The point of sprajax is to try and find flaws in the custom code written using these frameworks so it exercises the application and analyzes request and response patterns. This approach is good for finding “technical” flaws in applications usually based on coding flaws and bad input handling, but isn’t very good at finding “logical” flaws in applications. Unfortunately there really aren’t any good tools for finding “logical” flaws in the design assumptions of applications other than manual inspection and design review. So we automate what we can…</p> <p> Sprajax has a place in assessing the security of AJAX-enabled web applications. The press release might not have done a good job of pointing out its limitations - they never do ;) - but sprajax is still under development and its utility should grow over time.</p> <p> Thanks,</p> <p> –Dan</p> I wrote the sprajax tool so I thought I would respond. That is a fair assessment of the tool in its current state. This is certainly an “alpha” release but work is progressing. Next up for sprajax:

-Remove requirement for SQL Server 2005 - this is a huge barrier to getting more folks using the tool and being able to look at historical scan data from a database is a lower priority at this point than making it easy to get up and running.

-Add support for the Google Web Toolkit. The interfaces for detecting, footprinting and then fuzzing frameworks need a little bit of work, but the goal is to make these fairly generic and modular so that it is easy to add support for additional AJAX toolkits. I suspect that once I have Atlas and GWT working it will be much easier to add support for DWR and others. And it should also be possible at this point to add more scanning for other non-framework-defined endpoints for additional fuzzing.

I would however disagree that looking for known exploits would be a better approach than the fuzzing sprajax does right now. Tools like Nessus and Nikto already serve this function quite well - they can tell you if your server is misconfigured or using out of date software. The point of sprajax is to try and find flaws in the custom code written using these frameworks so it exercises the application and analyzes request and response patterns. This approach is good for finding “technical” flaws in applications usually based on coding flaws and bad input handling, but isn’t very good at finding “logical” flaws in applications. Unfortunately there really aren’t any good tools for finding “logical” flaws in the design assumptions of applications other than manual inspection and design review. So we automate what we can…

Sprajax has a place in assessing the security of AJAX-enabled web applications. The press release might not have done a good job of pointing out its limitations - they never do ;) - but sprajax is still under development and its utility should grow over time.

Thanks,

–Dan

]]>