 |
You can get your own Yasca t-shirt now that we’ve opened up a store front on Cafe Press! Send in pictures of yourselves in Yasca gear and I’ll post it up for the world to see!
In addition, you can vote for Yasca on the SourceForge Community Choice Awards!
I was informed that Yasca can sometimes throw a fatal error when it runs out of memory. The error might look like:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2222807 bytes) in C:\\yasca-1.3\plugins\Antic.php on line 47
This is due to the limited amount of memory available to PHP. By default, the value is 128MB, which should be enough for most cases. In case you need more, you can change the value of memory_limit in the resources/php.ini (or resources/php_linux.ini if you’re on Linux). For example, you can make it:
memory_limit = 256MB
This should solve the problem. Thanks to Diederik for pointing this out!
Yasca has joined the present day and now has a Twitter account. You can follow it at www.twitter.com/yasca. I will post all updates to this account and would love to get input directly from users as you use Yasca.
I’m pleased to announce that Yasca v1.3 has been released.
If you run into any problems running Yasca, please let me know.
I spent the tonight getting v1.3 ready for release. I’ve decided to include another major plugin, cppcheck, as well as PHPLint and JavaScript Lint. I will be testing this weekend and probably into the week, but if you want, you can get the latest bleeding edge version from Subversion.
I’m hard at work on getting version 1.3 ready for release. Change will include:
You can download the bleeding edge via Subversion, or wait a week or two for the official release.
Last night was the Yasca presentation at NYPHP. Thank you to everyone who came out! As promised, the presetation is available both on the NYPHP site as well as right here:
I released Yasca v1.2 last night on SourceForge. You can download it here. It includes a bunch of fixes, new plug-ins, and most notably, the inclusion of the PHP static analysis tool Pixy.
I promised another release in February and want to stick to that, so expect v1.3 to be for minor bug fixes and performance enhancements.
I’ll be speaking about the latest releaes of Yasca at NYPHP on February 24th. I’m looking forward to finally speaking in a public forum. It’ll be a lot of fun!
I also received feedback suggesting that I include Pixy within Yasca. I’ll be working on this over the weekend and will certainly have it ready by the v1.2 release date (mid-February).
Pixy is pretty interesting - It contains a parser for PHP 4 code (yeah, PHP 5 would be nice) and handles “source-to-sink” taint propagation. For those who aren’t familiar, it’s really why static analysis tools have come of age recently. Consider the following two functions:
public static void foo(HttpServletRequest req) {
String s = req.getParameter("someVar");
doFoo(s);
}
public static void doFoo(String s) {
PageContext.getOut().println(s);
}
“Taint” would be applied to data that is returned from certain “source” functions. The HttpServletRequest.getParameter function is one such function. It’s where bad data can be introduced into a running program. This taint would continue marking the data, even when moving through different variables. (The String ’s’ would become tainted.) This taint would pass into the doFoo() function under the local alias String ’s’, and then into the println() function. The println() function would be an example of a “sink”, which could be defined as a place where taint can go in order to create a vulnerability.
So this “source to sink taint propagation” is just looking at source code and asking, “Is there any way for nasty data to come in through a source and out into a sink without being validated?” (i.e. “Is there any way for nasty data to come in through a source and out into a sink without passing through specific “cleanse” functions?)
It’s cool stuff, and can detect a bunch of interesting vulnerabilities, including the big ones (XSS and SQL Injection). Unfortunately, it’s memory intensive and not easy to get right.
My next major task (for Yasca v2.0) is to write such a scanning engine for Java code. There’s one project out there that already does it, called LAPSE by Benjamin Livshits, but that project doesn’t seem to have been updated since 2006 and leverages the Eclipse framework to do scanning. It also makes it very slow, and not suitable to the needs of Yasca.
Getting back to Pixy, I think this is one of the best features of Yasca - the ability to absorb in other tools that do things better. I have a bunch of other ideas, such as a lightweight logging proxy that’ll just record all of the HTML/CSS/whatever actually sent to the web-browser, and then scanners that can look through that stuff. It’ll all be coming soon.
I noticed a search engine referral that asked “How to use Yasca”. Maybe it seems obvious to me only because I’ve been using it for over a year. Here are some examples of what you’ll probably want to do with it:
Scenario #1 - Simple PHP Project
Suppose you have a PHP project with source code in c:\work\myproject\src\. You could run:
yasca c:\work\myproject\src
The output is placed in a folder called Yasca on your desktop.
Alternatively, since you know you don’t have any Java, C, or C++ files there, you can exclude certain plugins that definitely won’t find anything to scan. (This is optional; if you ignore this, execution time will just take a few seconds longer.)
yasca -px FindBugs,Antic,JLint,PMD c:\work\myproject\src
Scenario #2 - Java Project, Output To File Share
Suppose you have a Java project in c:\work\myproject, but you want the output from Yasca to go to a file share (Z:\Yasca_Output). You could run:
yasca -o z:\Yasca_Output c:\work\myproject
Scenario #3 - Only See Critical Issues
You can “turn up the dial” and view only critical issues by using the –level parameter:
yasca --level 1 c:\work\myproject
These are some typical uses. Please leave a comment if you’d like examples of any others.
I’m busy working on the next minor release of Yasca, and I’ve got something that I think you’ll like. Ignore lists.
Suppose you have some code that you think a particular plug-in doesn’t scan some of your code accurately. If you don’t want to clutter up your report with those results, you only have three choices at the moment: disable the plugin by either removing it from the plug-in directory (./plugins by default), prefixing the name with an underscore (i.e. rename badplugin.php to _badplugin.php), or using the -px command line parameter to ignore that particular plugin (i.e. yasca -px badplugin).
In version 1.2, I’ve added the concept of an ignore list. From the HTML output (HTMLGroupReport), you’ll have a new anchor available that will toggle whether that particular finding is ignored or not.
After you’ve clicked off all of the findings you want to ignore, you can click on the “save ignore list” link at the top, which will show the XML. Save the XML as a file, and include it when running Yasca next (i.e. yasca --ignore-file ./ignore.xml).
I’m working on making this a bit more user-friendly. If you have any ideas, please drop me a line.
The next version of Yasca (v1.1) was released this afternoon on Sourceforge. It includes updated versions of FindBugs, PMD, and PHP, as well as new rulesets and bug fixes. Download the new version now!
So you’ve downloaded and installed Yasca, and like the results, but you want it to write your own plugin. This tutorial will show you how easy it is to do.
First, you should understand how Yasca is designed. Yasca is basically a file scanning engine with the ability to run plug-ins that find interesting things in those files and report the results back to the engine for inclusion into the report. Everything that goes into a report comes from a plugin. (Yasca can do nothing without them.)
Yasca comes with a number of plug-ins by default, including FindBugs, PMD, Jlint, and Grep. The first three are external tools that are maintained by others, but included because I think they provide great information. I wrote the Grep plugin to make it easy to create simple rules that only require regular expression matching. In the first part of this tutorial, we’ll create a new Grep plugin to search for something interesting.
Writing a Grep plug-in requires you to have a few pieces of information (and a few more optional pieces):
Let’s pretend you want to search for social security numbers within a code base. Create a new file called SocialSecurityNumber.grep. The base name of the file is not important, but the extension (.grep) is. The Grep plugin actually scans for .grep files in the plug-in directory and uses each of them. Here’s the contents of SocialSecurityNumber.grep:
category = Social Security Number Found grep = /\d{3}-\d{2}-\d{4}/
Additional parameters are also available, including:
For example, consider the a slightly modified version of the Formatting.MissingAMPM.grep pluigin:
name = Missing AM or PM in Time Format file_type = java,jsp grep = /hh:mm:ss\"/ category = Formatting: Missing AM/PM in Time Format severity = 2 description = <p> When specifying time formatting in Java, the phrase "hh:mm:ss" is based on 12-hour time, so 5:00 AM and 5:00 PM would both be rendered as "05:00:00", possibly confusing the user. Instead, use either "HH:mm:ss", which is based on 24-hour time, or include either AM or PM by using "hh:mm:ss a". </p> <p> <h4>References</h4> <ul> <li>TODO</li> </ul> </p> END;
You can also specify multiple grep patterns, which are logically ‘ORed’ during evaluation.
Place the file you created in the plugins directory and start Yasca. The Grep plugin will automatically find all .grep files within the plugins directory and use them.
In our next tutorial, you’ll learn how to write more complex plugins.
Yasca v1.0 has finally been released publicly. While there isn’t a party per se, we encourage you to throw one, and give out copies of Yasca to your friends and neighbors!
