Netsparker’s new “Automate That” [1] release is ready. It’s not just about bug fixes or improvements, we’ve also got two great new features and two big improvements. Command Line Support to automate and integrate your scans with other tools. Schedule Support so that you can scan stuff overnight or scan your application weekly and obtain reports. We decreased the request count during the attacking phase without sacrificing our coverage and added a bunch of new confirmation engines.
Schedule Support
One of the most requested features was Scheduling Support, finally we added it. It doesn’t require an extra service to install and will integrate itself to “Windows Task Scheduler”. It works correctly under Windows XP, Windows 2003, Windows Vista, Windows 7.
Command Line Support
Command line can be used to call Netsparker from another application for manual scanning, for example internally we’ve got a Firefox test extension which launches Netsparker with the current page’s URL by using the following command line:
Netsparker.exe /u [Current Page]
If you want to automate the whole scan, the best way to do is create a new profile from the “Start New Scan” window. Afterwards you can launch a new scan with your profile name. You can share these profiles between computers, they are stored in "My Documents\Netsparker Scans\Profiles".
Netsparker.exe /a /p QuickSQLI /u http://nightlybuild.example.com /rt "Vulnerabilities List (XML)" /r c:\reports\report-%date%-%time%.xml
This will scan the URL with the given profile and will save the XML report to c:\reports\ folder. %date% and %time% will be dynamically replaced with start date and time of the scan, so you don’t have to change the report name every time you run it. If you need a custom output you can use create your own report with Netsparker’s Custom Reporting API.
Command Line Parameters:
| /a, /auto | When other parameters are given correctly, the scan is carried out, the report is saved and the program is closed. |
| /p, /profile | Name of the profile to be used during the scan. If not specified, the preset profile will be used. |
| /u, /url | Address of the website to be scanned. If the profile file includes another website address, the address specified with this parameter will be taken into consideration. If two different URLs are specified in the profile and within this parameter, the one given with this parameter will be taken into consideration. |
| /pr, /proxy | Proxy server address. If the profile file includes another proxy server address, the address specified with this parameter will be taken into consideration. A valid proxy server address should be as follows: http://user:password@proxy.address/ If a user name and password are required for logging on the proxy server, these should be given in the shown format. |
| /r, /report | File path the report will be saved. It should be used in conjunction with the “-a” parameter. The full physical file path can be given; if only file name is given, the created report will be saved into the folder the command is run. |
| /rf, /reportformat | File format of the created report. If not specified, the report is created in “pdf” format; rtf, pdf, text, csv, xls or html formats are also supported. |
| /rt, /reporttemplate | Type of the created report. If not specified, first type in the list will be valid. |
Performance Improvements
- Amount of requests to identify vulnerabilities drastically decreased. We optimised all of our attacks, combined some attacks into one and in the end we started to send 35% less requests and we opened some space to make our coverage even better by decreasing the amount of requests . This means shorter attacking phase.
- Smart caching added to some detection engines to decrease CPU usage. If you have a powerful system you might not notice this at all. It’s an increase of about 2-3%.
New Security Checks
- ASP.NET ViewState analysis added
- ViewState is not signed
- ViewState is not encrypted
- ViewState view panel. When you go to “HTTP Request/Response”, if the page has ViewState in it, this panel will be visible automatically. If the ViewState is not encrypted, then you can see the data in it.
New Confirmation Engines
Confirmation engines ensure that you won’t have a false-positive and you will see less [Possible] vulnerabilities. When these vulnerabilities get confirmed you’ll see Netsparker’s famous 
Confirmed icon!
- RCE (Remote Code Evaluation) confirmation engine added.
- RFI (Remote File Inclusion) confirmation engine added.
- Command (Remote File Inclusion) confirmation engine added.
Improvements
- Cross-site scripting engine updated. The new engine is faster and gives out less possible errors, it also allowed us to add more XSS checks. However, there are some missing bits in the new engine. This might cause to miss some rare XSS cases. We are working on this problem.
- Permanent XSS detection improved. Currently there is no Confirmation engine for permanent XSS checks. We're working on this problem.
- Start new scan screen remembers the last used profile.
- Extra confirmation stage added to dashboard. Extra confirmation triggers in some Blind SQL Injection issues. It's a required step to avoid false-positives although it can take minutes depending on the vulnerability.
- Better coverage in many engines but mostly SQL Injection (new ORACLE, MySQL and SQL Server attacks added and optimised to work in more cases)
- Cross-site scripting issues now reported with alert() proof of concepts for easier copy & paste
- We added new default profiles. You can always create your own custom profiles.
- Full Scan – SQL Server (checks for everything but SQL Injection attacks optimised for SQL Server backend database which makes the scan faster)
- Full Scan – MySQL (checks for everything but SQL Injection attacks optimised for MySQL backend database which makes the scan faster)
- Fast – No JavaScript (checks for everything but Netsparker won’t parse / interpret JavaScript, which speeds up the scan, especially the crawling phase)
Bug Fixes
- A bug fixed in the JavaScript parser which was causing consistent crashes in some AJAX cases
- Parsing issues for some relative links addressed. It was affecting links starting with a question mark (?) without a path.
- Some SQL Injection attacks constructed correctly to bypass weak blacklisting and filters.
- An issue in dashboard causing display of incorrect figures in some scans addressed.
- A parsing bug addressed in pages with external JavaScript references
- The bug in the "[Possible] Source Code Disclosure" vulnerability addressed.
- A problem in Configure Authentication Tab addressed. This problem was affecting logout views with heavy JavaScript.
- There were some problems in Blind SQL Injection detection in ORACLE. Those issues were addressed, now Blind SQL Injection works correctly even with many grouped ORACLE SQL Queries .
- Null byte reporting in the XML file was addressed, which was causing problems in XML parsers. Currently all reported URLs are encoded correctly in the report.
- Issues weren't sorted correctly. Confirmed issues were listed after possible issues in the same severity.
- A bug addressed which was causing cookie save checkbox to be kept enabled in the profile save dialog.
[1] All alpha / beta releases of Netsparker had a release code name. Generally with a cheesy reference such as “Fast & Furious” Release, “So tell the girls I’m back in town” Release, “Getting There” Release. It was fun. We thought it’d be nice to give a code name to our public releases as well.