wSAST Support

Our activation server had a problem updating which may have made activation of wSAST fail - if you encountered this please try again it should all be fixed now!

My @IOActive hack::soho talk on wSAST is finally online! If static code analysis interests you then you may enjoy hearing a little about the journey, trials and tribulations of building a SAST engine from scratch! youtu.be/QEBRx42uk50?si…

Finally the latest wSAST update is released. This adds a number of optimisations for repeated function calls, fixes some bugs in rules engine instance sharing, and adds more rules courtesy of GPT. Full changes here: github.com/wsast/docs/blo… User guide: github.com/wsast/docs/blo…

… the latter will help focus rule creation and hopefully creation of shims for common frameworks. I plan to look into using GPT to automate this from reported missing code

Development of wSAST continues! A number of bugs have been fixed when handling interface types, a race condition in the common rules engine, and functionality to dump missing imports, types and methods to file soon incoming…

Thanks everyone who came out to @IOActive hack soho to see my talk on wSAST! I’ve put my slides online here: wsast.co.uk/ioa-hs-winter2…

I had an idea for @wsastsupport - I might write a “parser” that allows you to specify language components in a regex form (how to extract a class name, method, statements, expressions, etc.) and have wSAST look up based on the source file extension how to do this “light” form of parsing of the source file. These could then be converted to WSIL with more or less information and analysed. Then all the regular generic rules could be run over the information as extracted (CWE, data rules for things like SQLi, etc.) as well as a new regex rule type that can “grep” the source of the specific code being analysed. This would allow a huge number of languages to be supported in a light fashion and wSAST intelligence for things like control flow analysis to be applied alongside simpler techniques such as regex. Interesting concept and all possible within the bounds of what the framework supports!

@brsn76945860 Thanks for reporting it, much appreciated. Is there any chance you could drop me an email on support@wsast.co.uk? If you’re able to determine a minimal test case please could you attach it and I’ll investigate and issue a fix.

@wsastsupport I ran into a crash running WSAST and was wondering what your preferred method of bug report would be? I can't share the code base but happy to provide as much other info as possible.

@CisoDiagonal @filip_dragovic I just left my humble prompt at the altar of the AI gods and hoped for the best 😂

@wsastsupport @filip_dragovic Why did you ask for an xmas hacking sausage on a Mac? With mustard even?? 😂

wSAST v0.1-alpha (release date 18-12-2023) is now public! This release contains support for annotation-based rules, and support for filtering entry points when launching scans, as well as several important improvements to path finding, rule matching. github.com/wsast/docs/blo…

Development of wSAST is still actively ongoing - soon an update will be released which should substantially improve pathfinding, fix a few issues with analysis, provide new annotation-based rules for popular frameworks, reduce FPs and increase accuracy for static and df scans!

Following a slight hiatus in development annotation based rules are now working in the common rules engine; this should allow attributes such as Serialized or QueryParam to taint variables being traced. Further improvements underway and hope to release in a few weeks.

wSAST v0.1-alpha (release date 25-08-2023) is now public. This adds a basic JSP processor and includes quite a number of minor fixes and improvements to Java parsing and general analysis. Full list of changes: github.com/wsast/docs/blo… Mustache compiler call graph for eyecandy!

Apologies for the wSAST site being down today; the Azure subscription needed updated billing. It should be back now! Coming this weekend, a number of fixes and improvements to Java parsing, and JSP support.

Soon incoming, some further minor Java language processor fixes, and basic JSP processor enabling scanning of JSP files. Planned are annotation-based rules allowing parameters marked e.g. QueryParam or entire classes marked Serialized etc. to be sources.

The --filter-root feature allows graphing calls where only the root call matches the specified filter rather than requiring source and/or dest to match. Useful for investigating flows from a specific function or family of functions.

wSAST v0.1-alpha (release date 07-08-23) is now available for download from wsast.co.uk/download.html This fixes a number of bugs in analysis, graphing and adds a few useful features for manual analysis such as --filter-root (see image). Changes here: github.com/wsast/docs/blo…

A small update for wSAST will be released in the next few days, fixing a couple of bugs in graphing and path discovery and containing some minor improvements to Java translation.

Today I am pleased to announce the release of a code analyser I’ve been working in my free time - wSAST (wsast.co.uk) wSAST aims to make code analysis easier for application security consultants by providing tools to graph relationships, find paths between functions, and identify entry points into codebases as well as perform full dataflow and static analysis using a powerful rules engine. Rules for analysis can propagate taints, express arbitrary relationships between variables, and attach arbitrary data to variables as they flow through the application during simulated execution. Rules can be written as simple XML format rules (for simpler types such as function rules, variable and type rules, and data rules), or in .NET for completely customised rules which can then be as convoluted as you like. Multiple sources can be attached to any variable and multiple sinks to any trace, which then come and go from execution scope per a specified scope anchor. Since wSAST is implemented over a custom intermediate language (WSIL) to which all supported languages are translated it will be able to support multiple languages. At the moment only Java core language support has been completed, and C support is about 95% complete but has no rules at this time. My plan for the moment is to keep the core engine closed source but make all the rules, the front end, rules engine all open source and .NET based. I plan to make further steps towards this by releasing the code for these components to the wSAST GitHub when developer guides are finished. It will be possible for developers to add custom language support (if they’re brave enough!) using the interfaces provided, and the C to WSIL translator will be open source as an example. I hope people find this useful! Don’t hesitate to contact me if you have any questions, on here or on @wsastsupport