16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
68 lines
2.8 KiB
Plaintext
68 lines
2.8 KiB
Plaintext
*==This rule is postponed for now==*
|
|
|
|
|
|
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.
|
|
|
|
|
|
Note the difference between the two RSPECS:
|
|
|
|
* RSPEC-4805 will highlight every use of stdout/stderr, as it needs to be audited.
|
|
* RSPEC-106 focuses on the best practice of logging instead of using the streams, and will try to avoid the Command Line Interface cases.
|
|
|
|
*========================*
|
|
|
|
|
|
Writing to Standard Output and Standard Error streams is security sensitive. It has led in the past to the following vulnerabilities:
|
|
|
|
* [TODO]
|
|
|
|
Three kind of vulnerabilities exist in this case:
|
|
|
|
* 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.
|
|
|
|
|
|
== Ask Yourself Whether
|
|
|
|
\[TODO]
|
|
|
|
|
|
== Recommended Secure Coding Practices
|
|
|
|
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.
|
|
|
|
Document your output so that users will be warned that some dangerous user input will be printed.
|
|
|
|
|
|
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 print sensitive information on those streams.
|
|
|
|
|
|
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]
|
|
|
|
|
|
== See
|
|
|
|
\[TOOD]
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 29 Aug 2018, 19:36:53 Ann Campbell wrote:
|
|
FYI [~nicolas.harraudeau]: RSPEC-106
|
|
|
|
=== 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.
|
|
|
|
|
|
endif::env-github,rspecator-view[]
|