0

I have a token that is restricted to read only access. If someone obtains that token, can they use it to do a sql injection attack?

Given that the token is permissioned for read only, can someone embed a delete query in the request, have it read on the server side, and it actually does a delete?

nanonerd
  • 157
  • 1
  • 1
  • 7
  • 2
    What do you mean by "a token that is restricted to read only access"? A token is just a piece of data, without knowing _how_ someone using that token is restricted to read only access we can't tell you anything. – AndrolGenhald Jul 19 '18 at 16:45
  • 1
    Why you're asking? To elaborate, this is a very wrong question to ask. A protection from sql injection should be all-embracing, protecting any kind of data, including any tokens as well. So if you have a protection, you don't have to worry about tokens. If you don't, then tokens or no tokens you are busted. – Your Common Sense Jul 19 '18 at 16:46
  • 1
    Token itself is irrelevant, but I think the point the author wants raise is whether *authorization* (i.e. access privileges) can help prevent SQL injection - the title should be edited to reflect this. – HTLee Jul 19 '18 at 17:39

1 Answers1

2

First and foremost: If the token is concatenated into a SQL query (without sufficient escaping), then yes, it can be used for SQL injection. Don't build queries by concatenation!

Tokens, by themselves, have no permissions; they are just identifiers. The app's logic determines what permissions to give the bearer of the token, but it's up to the app to enforce that, and a (successful) SQL injection bypasses such checks. Databases also have permissions (at least, the better ones do), and the app will have certain permissions on the database that determines what a query the app sends to the DB can do (and all that a SQL injection is, from the perspective of the DB, is a query that the app sent over). A very security-conscious app will use the Principle of Least Privilege (which says you should never give anything more permissions than are needed to do its task), such that (for example) a DB query that is supposed to be read-only will be made using a connection with read-only permission on the DB, and in such a case an embedded DELETE subquery would indeed fail. However, in practice very few developers do this, and the app usually makes all queries using a connection with full permissions on the DB.

The permissions of the token-bearing identified entity (presumably a user of a web app or similar) have no bearing whatsoever on the permissions that the app has when talking to its database. In fact, since a SQL injection requires modifying the token, it's no longer actually the correct identifier for that user, so it definitely isn't going to be subject to user-specific access checks.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • I would suggest to avoid the term "escaping" for being too vague and misleading. An average PHP user would feel safe in such a common case as *escaping* a value and then adding it as a numeric literal to the query. I would use the term "formatting" instead, as to make no reference to a notorious escaping function. – Your Common Sense Jul 20 '18 at 07:39