[JS] Mapping DataFlow::Node to PrintAstNode

[Naman-ntc]

I am trying to build a data-structure combining information from both ASTs and DataFlow::Node. I am using PrintAst.qll for generating ASTs and use a separate path-problem query for generating the relevant data-flow.

Now I want to map the DataFlow::Nodes to PrintAstNode (whenever possible). I am aware of how to convert to ASTNode from a DataFlow::Node but can't seem to figure out converting them to PrintAstNode.

---

ElementNode in PrintAst.qll does seem useful but it is private. I can locally make it public locally however not clear about which ASTNodes are accounted for and if some better solution exists.

codeql/javascript/ql/lib/semmle/javascript/PrintAst.qll

Lines 160 to 171 in d3da790

	private module PrintJavaScript {
	/**
	* A print node representing an `ASTNode`.
	*
	* Provides a default implemention that works for some (but not all) ASTNode's.
	* More specific subclasses can override this class to get more specific behavior.
	*
	* The more specific subclasses are mostly used aggregate the children of the `ASTNode`.
	* For example by aggregating all the parameters of a function under a single child node.
	*/
	class ElementNode extends PrintAstNode, TElementNode {
	ASTNode element;

[erik-krogh]

As the libraries are right now you can't map from a DataFlow::Node to a PrintAstNode (or from an ASTNode to an PrintAstNode).

But I don't see why you would use PrintAstNode in the first place.
PrintAstNode is just a layer on top of Locateable that adds middle-nodes that makes the printAst.ql output pretty.
(e.g. TParametersNode. It just sits between a function and it's parameters, it doesn't really represent any AST node).

I also don't see the need for a data-structure that contains both ASTNode and DataFlow.:Node, but if I were to make one I would probably do a newtype with cases for both.
So e.g.

newtype TMyAst = 
  TMyAstNode(ASTNode node) or 
  TMyDataFlowNode(DataFlow::Node node)
  
class MyAst extends TMyAst { .. } 

class MyAstNode extends MyAst, TMyAstNode {...}

class MyDataFlowNode extends MyAst, TMyDataFlowNode {...}

[Naman-ntc]

Thanks for the response!

PrintAstNode is just a layer on top of Locatable that adds middle-nodes that makes the printAst.ql output pretty.
(e.g. TParametersNode. It just sits between a function and it's parameters, it doesn't really represent any AST node
From my understanding,

I see. Seeing the TJSXAttributesNode and TJSXBodyElementsNode classes, I assumed that PrintAstNode is more complete and handles such cases. Also, PrintAstNode toString command automatically prepends the type of ASTNode. Based on your suggestion, I created a custom copy of PrintAST.qll that operates solely on ASTNode and prints ast node type using the getQlClass function

I also don't see the need for a data-structure that contains both ASTNode and DataFlow.:Node, but if I were to make one I would probably do a new type with cases for both.

Actually, I am trying to combine PathNodes detected for a query under a vulnerability detecting configuration with the AST. So, in effect, for a particular codebase, I was planning to compute AST (found using PrintAST.qll) and annotate it with the #nodes and #edges returned by a vulnerability query.

[erik-krogh]

I see. Seeing the TJSXAttributesNode and TJSXBodyElementsNode classes, I assumed that PrintAstNode is more complete and handles such cases.

I think of it as a different view of the same data.
The TJSXAttributesNode and the TJSXBodyElementsNode classes just makes sure we have 2 print-nodes for some expressions.
An JSXElement instance (an expression) is represented both by the JSXNodeNode and JSXAttributesNode classes in PrintAst.qll.
And I don't think you want the same thing to show up twice for your use.

Based on your suggestion, I created a custom copy of PrintAST.qll that operates solely on ASTNode and prints ast node type using the getQlClass function.

That sounds like an OK solution.

Actually, I am trying to combine PathNodes detected for a query under a vulnerability detecting configuration with the AST. So, in effect, for a particular codebase, I was planning to compute AST (found using PrintAST.qll) and annotate it with the #nodes and #edges returned by a vulnerability query.

There's a feature of the VSCode extension that I think you might find interesting (if you don't know it already).
If you run a @kind problem query, then in the results view a checkbox named Show results in Problems view shows up.
If you click the checkbox, then all the problems identified by the query will be highlighted in your editor.
You can relatively easily rewrite any path-problem query to a problem query that highlights all the nodes between sources and sink.
I've done it below for js/unsafe-dynamic-method-access.

/**
 * @name Unsafe dynamic method access
 * @kind problem
 * @id js/unsafe-dynamic-method-access
 */

import javascript
import semmle.javascript.security.dataflow.UnsafeDynamicMethodAccessQuery
import DataFlow::PathGraph as PathGraph // <- the `query predicate` must not be in the global scope, otherwise a `@kind problem` query errors out.

from Configuration cfg, DataFlow::PathNode source, DataFlow::PathNode sink, DataFlow::PathNode node
where cfg.hasFlowPath(source, sink) and PathGraph::nodes(node)
select node, "Is a node from a source to a sink"

[Naman-ntc]

where cfg.hasFlowPath(source, sink) and PathGraph::nodes(node)
select node, "Is a node from a source to a sink"

That is a very smart solution!
However, the #nodes for a path-problem already computes this right, or am I missing something?

[erik-krogh]

Yes, that is exactly the same information.
But by doing it this way (a @kind problem query) you can get a nice view of the nodes inside VSCode.