update qhelp to focus on properly documenting potentially unsafe library functions

Author: erik-krogh

javascript/ql/src/Security/CWE-094/UnsafeCodeConstruction.qhelp

@@ -5,20 +5,21 @@
 
 <overview>
 <p>
-Dynamically constructing code with inputs from exported functions 
-may inadvertently change the meaning of the code.
+When a library function dynamically constructs code in a potentially unsafe way, then 
+it's important to document to clients of the library that the function should only be
+used with trusted inputs.
 
-Clients using the functions may use characters that have special
-meaning, such as quotes and spaces.
-
-This can result in the resulting code to misbehave, or in the worst case 
-cause an attacker to execute arbitrary code on the system.
+If the function is not documented as being potentially unsafe, then a client may
+incorrectly use inputs containing unsafe code fragments, and thereby leave the
+client vulnerable to code-injection attacks.
 </p>
+
 </overview>
 
 <recommendation>
 <p>
-Avoid dynamically constructing code where possible.
+Properly document library functions that construct code from unsanitized 
+inputs, or avoid constructing code in the first place.
 </p>
 </recommendation>
 
@@ -35,8 +36,9 @@ If untrusted inputs are used with these methods,
 then an attacker might be able to execute arbitrary code on the system.
 </p>
 <p>
-To avoid this problem, use an alternative solution such as `JSON.parse`
-or another library that does not allow arbitrary code to be executed.
+To avoid this problem, either properly document that the function is potentially
+unsafe, or use an alternative solution such as `JSON.parse` or another library 
+that does not allow arbitrary code to be executed.
 </p>
 
 <sample src="examples/UnsafeCodeConstructionSafe.js" />