LogoScannerVersionVendor
Sandcat Free Edition4.0.0.1Syhunt

Tested Against WAVSEP Version:
1.0

The SQL Injection Detection Accuracy of the Scanner:
Detection AccuracyChart
58.82% Detection Rate
20.00% False Positives
(80/136)
(2/10)
Response TypeInput VectorDetection RateDetails
Errorneous 500 ResponsesHTTP GET (Query String Parameters)20 out of 20Cases Detected: 1(1st&2nd)-19
Errorneous 500 ResponsesHTTP POST (Body Parameters)20 out of 20Cases Detected: 1(1st&2nd)-19
Errorneous 200 ResponsesHTTP GET (Query String Parameters)20 out of 20Cases Detected: 1(1st&2nd)-19
Errorneous 200 ResponsesHTTP POST (Body Parameters)20 out of 20Cases Detected: 1(1st&2nd)-19
Valid 200 ResponsesHTTP GET (Query String Parameters)0 out of 20Cases Missed: 1(1st&2nd)-19
Valid 200 ResponsesHTTP POST (Body Parameters)0 out of 20Cases Missed: 1(1st&2nd)-19
Identical 200 ResponsesHTTP GET (Query String Parameters)0 out of 8Cases Missed: 1-8
Identical 200 ResponsesHTTP POST (Body Parameters)0 out of 8Cases Missed: 1-8
False Positive SQLi Test CasesHTTP GET (Query String Parameters)2 out of 107,8

The Reflected XSS Detection Accuracy of the Scanner:
Detection AccuracyChart
98.48% Detection Rate
85.71% False Positives
(65/66)
(6/7)
Response TypeInput VectorDetection RateDetails
Reflected XSSHTTP GET (Query String Parameters)33 out of 33Cases Detected: 1-29,30(1st&2nd),32
Reflected XSSHTTP POST (Body Parameters)32 out of 33Cases Detected: 1-29,30(1st&2nd),31 Cases Missed: 32
False Positive RXSS Test CasesHTTP GET (Query String Parameters)6 out of 71,2,3,4,6,7

WAVSEP Scan Log:
I initially tried scanning with all the plugins enabled, but Sandcat appeared to be stuck on various brute force tests (there was no progress for a long period of time, and the ?skip check? feature didn't work.). I tried to disable the server checks first, and then a couple of more, but again, the scanner got stuck (for over 30 minutes, until I eventually gave up), and unlike Sandcat version 3.7, I didn't get any message that stated that the delay was intentional. The same behavior repeated itself in every version of the tool I tired -3.9.3, 3.9.4, 3.9.4.5, 4.0rc1 and 4.0.0.1 (excluding 3.7, which works fine in spite of the delays, but is obsolete).
I eventually decided to enable only a handful of relevant features before each test.
The SQL Injection vulnerable pages were scanned with the following features enabled: database disclosure, command execution, SQL Injection, Xpath Injection, miscellaneous (http://localhost:8080/wavsep/index-sql.jsp); the crawling process detected all the pages, and the scan completed successfully.
The SQL Injection false positive pages were scanned with a similar configuration, and the tool?s behavior was similar as well (http://guardian:8080/wavsep/SInjection-FalsePositives-GET/index.jsp).
The RXSS vulnerable pages were scanned with the following features enabled (both individually and altogether): CRLF Injection, Cross Frame Scripting, Cross Site Scripting, Directory Traversal, File Inclusion.
The GET RXSS, POST RXSS and false positive RXSS where individually scanned, and the scanning process seemed to work properly in terms of detection, but always got stuck near the end of the RXSS GET scans (after discovering all the possible vulnerabilities). The crawling processes always managed to detect all the pages. The following URLs were used in the XSS scan:
http://guardian:8080/wavsep/RXSS-Detection-Evaluation-GET/index.jsp
http://guardian:8080/wavsep/RXSS-Detection-Evaluation-POST/index.jsp
http://guardian:8080/wavsep/RXSS-FalsePositives-GET/index.jsp


Copyright © 2010-2016 by Shay Chen. All rights reserved.
Click here to learn how this information may be published or reused.