[Nikto-discuss] Bug: Nikto eating input from non-tty stdin

[dave at cirt.net]

Quoting Serge van den Boom <svdb at madison-gurkha.com>:
>> I've raised this as a bug:
>> http://trac2.assembla.com/Nikto_2/ticket/210#preview
> You write "or buffer up all of stdin at initiation" in that ticket.
> Do you mean that Nikto would read everything that it can from stdin?
> I don't see how that would solve anything in a batch run; you can't put
> the data back in stdin after Nikto ends.

It was a thought I had whilst writing the bug - as you've said it  
probably would break stuff.

>> As I'm a bit short of time at the moment I don't have time to fix  
>> it fully. Certainly the description of ReadKey implies that it may  
>> read from stdin - but what I don't get is why it's only reading  
>> some characters.
> Now that you mention it, I have actually seen that the scans stop
> unexpectedly after scanning a host, which would fit with Nikto eating
> all further input. It may have something to do with whether the HTTP
> service is accessible at all.

That may make sense. Looking further into ReadKey, the default stream  
seems to be STDIN; but this may be very platform dependant (hence why  
Sullo couldn't reproduce as he's one of them Mac users).

I need to spend some time testing this before I commit anything, as I  
don't want to break something on a platform that I can't test myself  
(e.g. Mac OS X).

>> The quickest way to resolve this may just be to add a -batch switch  
>> to disable interactive features, though then you could only quit  
>> via CTRL+C.
> I suspect that most users would not find out about this switch until
> things have gone wrong, and it may cost them a lot of time in the
> meantime. There is no reason why Nikto would need to read from stdin
> when it is not a tty, so a simple isatty() check would be enough.

Good point; though of course it may be a user requirement to use the  
interactive features whilst doing a loop; hence testing is needed on  
at least the big 3 platforms (Windows, Mac and Linux).

For now the only work around I can suggest is to avoid using stdin to  
pass stuff as you're doing at the moment (using something like the for  
loop I suggested earlier).