Feature request: exit with non-zero code when problems are found

[eheydrick]

Exiting with a non-zero code when problems are found would enable using wpscan to automate monitoring of wordpress security.

[erwanlr]

What's the command you were running and error output ?

It should exit with code 1 when an error occurs, 0 otherwise

[eheydrick]

Just running wpscan --url whatever. I'd like a mode where it exits non-0 when a vulnerability is found and 0 when all is good.

[pvdl]

@eheydrick
This is a work-around: wpscan.rb --url www.yourtarget.com --no-color | grep "[!]"

[eheydrick]

that's basically what I ended up doing.

[firefart]

will fix this now, should be easy

[firefart]

@eheydrick can you please try the new implementation?

1 is returned on error
0 when no warning or critical message is printed
> 0 (=count of warning and critical messages) if smth was found

PS: currently investigating why 0 is always returned :(

[firefart]

@eheydrick now it's fully working :)

[eheydrick]

@firefart exit code is working great. 👍 Thanks!

[brandonsturgeon]

Curious then, how do you test if the code actually fails? Like errors out? How do you distinguish between a REAL error, and just there being a vulnerability?

[jopfre]

What code is returned if one warning/crit is found? The same as the code for an error? Also sometimes null is returned, does that mean anything?

[firefart]

@jopfre for every critical or warning output the return code is increased by 1. So everything above 0 means something was found.

[jopfre]

@firefart Ok so what is the code for an error? null?

[firefart]

@jopfre anything above 0

[jopfre]

@firefart but do you see what I mean.
0 is nothing found OR error.
1+ is the number of warnings.

Seems like it would be good to differentiate between nothing found and errors

Above you said:

1 is returned on error
0 when no warning or critical message is printed
0 (=count of warning and critical messages) if smth was found

[firefart]

No. Everything warning+critical is > 0. So every error counts too.

0 is only returned when nothing was found

[brandonsturgeon]

@firefart I would like to know what happens when the application itself runs into an unrecoverable error. What is the return code then?

[firefart]

@brandonsturgeon as said before: something greater than zero. There is no specific app error return code

[brandonsturgeon]

@firefart We were just talking about how these codes help with automation, but any good automation tool will have to check for failures in its tools. This seems to be a pretty big flaw in this regard.

[ethicalhack3r]

Pull requests welcome!

…

On 26 Jan 2017 4:48 p.m., "Brandon Sturgeon" ***@***.***> wrote: @firefart <https://github.com/FireFart> We were just talking about how these codes help with automation, but any good automation tool will have to check for failures in its tools. This seems to be a pretty big flaw in terms of automation. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#796 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATuKZ2lpI0QZ3I2nRGLpTzhJvkPmlSSks5rWMBggaJpZM4D5glg> .

[brandonsturgeon]

I see the benefit to having a return code that is relevant to the results, but looking at return code conventions, this is a bit of an antipattern. The general rule is: 0 for success, 1 for error (and then >1 for specific error codes).

Here's a compromise, let me know what you think;

• 0 for a successful run with no wpscan warnings/ wpscan errors (meaning vulnerabilities)
• 1 for an application error
• 2 for a successful run with wpscan warnings / wpscan errors found

And then we can even go a bit further and maybe say 2 is just for warnings found, 3 is when wpscan errors are found

[jopfre]

Yeah exactly what @brandonsturgeon is saying. When I was saying errors before I meant application errors. For example sometimes the scan is interrupted ([!] The target seems to be down) or I get ECONNRESET so I think these should return a different code to a successful run with or without discovered vulnerabilities.

0 for a successful run with no wpscan warnings/ wpscan errors (meaning vulnerabilities)
1 for an application error
2 for a successful run with wpscan warnings / wpscan errors found
And then we can even go a bit further and maybe say 2 is just for warnings found, 3 is when wpscan errors are found

Looks good to me.

[ethicalhack3r]

I think the proposed exit codes make sense. This change may break backwards compatibility for users who have implemented the current logic. This would require a major version bump to warn users of the breaking change.

@erwanlr do you know if the above exit codes are the same as what is currently supported by wpsan v3? or does it do something else?

It may be worth leaving this as-is, and releasing the re-written v3 with the suggested exist codes.

[brandonsturgeon]

I agree, this would definitely be a breaking change (Some of my code included!). Is there somewhere we can write this down to make sure it "stays on the radar" ?

[erwanlr]

Exit codes in v3 can be found there: https://github.com/wpscanteam/CMSScanner/blob/master/lib/cms_scanner/exit_code.rb

[ethicalhack3r]

I think that looks like what was suggested more or less. Shall we just make v3 public and start getting feedback from users? On 26 Jan 2017 6:47 p.m., "erwanlr" <notifications@github.com> wrote: Exit codes in v3 can be found there: https://github.com/wpscanteam/ CMSScanner/blob/master/lib/cms_scanner/exit_code.rb — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#796 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATuKYwruPXNFlLpxK1NpErId62-7yERks5rWNw4gaJpZM4D5glg> .

[jopfre]

@ethicalhack3r ship it

[ethicalhack3r]

Here you go chaps https://github.com/wpscanteam/wpscan-v3 :)