With regards to your comment about "the LiQL query will not give you access to the underlying SQL tables/db schema". Wouldn't you be able to construct a query that would add this to a WHERE term:
... OR true=true
... wouldn't that make the query return the entire content of the table, thereby possibly revealing too much information?
In other words: Can you categorically say, that an injection attack on a WHERE term can never result in additional information being returned in the result of the API 2.0 REST call?
Another excellent point. You are correct again, OR true=true might return everything but only to the extent what the user's permissions should allow them to see. Nothing more, nothing less. By design and by default, the user is able to interact with the API and get exactly the same information he or she is allowed to see via the GUI.
In other words, your design choices should not try to override what information is presented to the user solely on constructing a LiQL query.
Your design choices should not try to override what information is presented to the user solely on constructing a LiQL query. When using restadmin you should keep that principle in mind even more front and center. Think of restadmin as the exec() equivalent, just b/c it's there doesn't mean it's safe to use for every situation (unless you absolutely know what you are doing).
You have raised some very astute points, thanks for a very exciting and well informed discussion on this important topic. Feel free to open up a Support case and if you like I can call you to discuss further.
And last but not least, sorry for a shameless plug but I'm hiring a Lead Security Engineer, do you know anyone? Your kind of skill set and knowledge is essential to be successful at this role (based in San Francisco, CA).
-Faisal
