Ignition Exchange resource vetting

Ignition
1

I was shown the Ad Hoc Trends resource.
I am reading through the events, methods, and scripts.

How do I know if an ignition exchange resource prepqueryupdates are sanitized against injection attack?
How do I sanitize prepqueryupdates against injection attacks?

I was told there is a way to check against a list of valid.
I haven’t seen how precisely.

2

The short answer is you don’t, without fully reading and understanding the code. We do some amount of vetting of resources on the exchange, but I wouldn’t consider that a substitute for reviewing them yourself.

Using Exchange resources should be as measured of a decision as pulling in an external dependency in a software project, which itself should be a very measured decision.

Supply chain attacks are a very real concern.

3

How do I sanitize prepqueryupdates against injection attacks?
I was given a description how to do it before.

I think I need to see it though.

I believe they said to check entered values against valid values.

4

There are two distinct things to be aware of.
First, if ‘Legacy DB Access’ is allowed, anyone who is able to authenticate with your gateway can issue any arbitrary SQL query by impersonating the client and sending an appropriately formed message. This isn’t really SQL injection, but is relevant to any discussion of DBs and security in Ignition.

Second, preventing SQL injection boils down to: never construct a query body from arbitrary user input.
If you use named queries and don’t use the query string parameter type, this is automatically handled for you. This is the safest, easiest advice to follow.

Beyond that, it’s general principles. Assume that any input from the client can be ‘spoofed’, and therefore cannot be trusted.
Say you had a gateway message handler to construct a query against a dynamic table name.
If you accept a tableName parameter and directly pass it into your query:
query = "SELECT * FROM %s" % params["tableName"]
You’re vulnerable to SQL injection, because tableName can be anything.
Instead, _on the backend, you could (for instance) have a whitelist of allowed table names; if you supply anything that’s not in the list, nothing will happen:

allowed_tables = {
	"table1",
	"table2"
}

if params["tableName"] in allowed_tables:
	query = "SELECT * FROM %s" % params["tableName"]
else:
	raise ValueError("Invalid table name %s" % params["tableName"])

Your exact validation strategy is up to you. If you’re not sure what you’re doing, I would just default to named queries without query strings.

3 Likes
5

Thanks

It might have been explained to me once before, but I think I caught it this time.
Thanks for the help.

Are the methods in Ad Hoc Trends accessible from the client sessions?
Do I need to check every method and event to see if there are inputs that might be vulnerable, or it is more about if there is a spot to enter text?

I can recognize query strings as vulnerabilities to avoid.
I don’t now what in those methods would be a concern for sure, but some of the methods are creating tables.

6

None of the queries in the Ad Hoc Trends use user supplied input to construct queries, so you should be safe from SQL injection. Though it’s worth your time and effort to go through this yourself and validate.

Converting the scripted queries to named queries is not difficult, and you might learn a few tricks along the way.

7

are the methods on the root table only on the backend and not the client?