This rule is controversial as rule RSPEC-106 already exists. Detecting the use of standard output and error streams should be visible in the quality gate in most cases. Thus it makes sense to keep RSPEC-106.
This rule (RSPEC-4805) would confuse our users as it would highlight the same thing. It should be implemented but later, once the Hotspot concept is well understood by our community.
* Any sensitive information written to the standard output and standard error streams might be exposed to an attacker.
* Those streams will be probably fed to another application. There is a good chance that it will be displayed in a terminal. An attacker can inject dangerous output that way.
* Information needed to monitor and analyse an attack might not be logged, thus increasing the chances of an attack being successful.
Don't print user input if you can avoid it. If it is required, sanitize all data before printing it on the standard output or standard error stream. You can't know what application will receive the output so there will always be a risk, but you should at the very least remove all non-printable characters so that the terminal cannot be attacked. It is also necessary to make sure that the encoding is the one asked by the system.
Always use loggers instead of standard output and standard error streams if your application is not a Command Line Interface (CLI) tool. This will make it easier to monitor and analyse security attacks.
Don't give access to those streams to untrusted code. Check that sub-processes don't have access to them if you run unsafe processes. [TODO: give concrete examples of stdin/stdout inheritance]
=== on 30 Aug 2018, 14:49:51 Nicolas Harraudeau wrote:
\[~ann.campbell.2] Thanks for noticing it. This rule is for now postponed as it would confuse our users. It still makes sense to implement it but later, once the Hotspot concept is well understood by all.
