Let me pop in after a very busy day...
I am, however, VERY concerned on the unnecessarily very strong and utterly misleading language used for the scan results. My code is DEFINITELY not malicious, it's DEFINITELY not hidden and it's DEFINITELY not going through eval. The language used does not in any way suggest that the scanner may have screwed up.@nikosdion
: I can relate and understand your frustration, especially if your customer has taken the result as a 100% positive, despite many many remarks that (with help from Mandville and PhilD) I tried to emphasize in post, instructions, GitHub, readme file etc...
people just love not to RTFM ... I planned to include another warning block just before and after results block about the need of proper interpretation of the results, and the big possibility that results are false positives! I'm absolutely open for all suggestions and contributions from native English speakers in rephrasing the wordings in reports and all other aspects of JAMSS.
Also, the patterns will be refined in time, and this is also a point where (specially) other extensions developers can help us out here on JAMSS project - give us examples of code that JAMSS
signifies as positives! I'll try to see if there is some space for improvement in pattern to be more precise. But always keeping in mind one important thing that @PhilD says: it should be much more acceptable to see some false positives along the way, than having just one false negative!
I'll insert the alternate wording suggested by PhilD.Update: the #17 report text has been changed in 'forum' and 'master' branches
P.S. For PHP-competent beta testers - you can find a newer beta version in 'master' branch, which should give much less false positives, especially on pattern #1 that is now (probably) improved. Compare the results from 'forum' branch with this beta in 'master' branch.
Comments and bug-reports are very welcome.
VEL Team || Security Forum || PHP/Web Security Specialist || OWASP member
JAMSS author viewtopic.php?f=621&t=777957