4

I'm new into REST APIs and developing an API that is going to be used for iOS/Android/Web apps, but I'm unfamiliar with the kind of threats the APIs face once published. I see these same tips all over:

  • Use oAuth 2 to allow transactions,
  • Receiving and sending only encrypted JSON Web Tokens,
  • Use SSL/TTL.

I think using SSL/TLS and JWT should be enough security for sending/receiving data, but even with that, I fear the possibility of SQL injection if someone stole credentials.

Should I check the requests for SQL injection strings (such as this one)? And if I'm going to support user login, would it make more sense to use oAuth instead of JWT?

Dialvive
  • 356
  • 7
  • 19
  • The best way, for me, is to differentiate data transfer objects(DTOs) and database objects, and use an ORM instead of making SQL queries directly from the backend. That way, you assemble your database queries from a predictable structure(from the DTO), and do object-based queries, which remove the risk of SQL injection. Take a look at [gorm](https://gorm.io/index.html) – Mikael Jan 01 '21 at 18:31
  • "and other attacks" makes this question impossibly broad.... as there are an unlimited number of attacks (and new ones discovered all the time) – Jonathan Hall Jan 01 '21 at 21:15
  • Possible duplicate of https://stackoverflow.com/q/26345318/13860 – Jonathan Hall Jan 01 '21 at 21:17
  • Does this answer your question? [How can I prevent SQL injection in PHP?](https://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php) – symcbean Jan 02 '21 at 00:32
  • @symcbean Nope, not using PHP, and the use case is different – Dialvive Jan 02 '21 at 01:03

1 Answers1

2

sql-i

  1. using prepared statements will get you a lot of the way (further reading)

  2. consider using ORM layers to interface with your db (eg: gorm)

security principles

  1. always validate user input before performing any operations on it

  2. for every operation, if you know of the universal set of options, opt for an allow-list approach vs a deny-list approach (i.e., I will only allow a string to pass through if it belongs to my known list)

auth

  1. jwt is just a token format (similar to your identity card), and you can use oauth for the underlying authz (checking your identity card before giving you access to some resource) -- read more here
  2. bearer tokens (like jwt) should always be sent over TLS/SSL to prevent intruders from getting access to the plaintext jwt (rfc7523)
  3. as the product matures, you might want to move to a model where you start assigning session tokens that are stored on the phone, but this usually comes with the complexity of handling revocation (eg: when/how do I rotate session tokens?)
Community
  • 1
  • 1
Debosmit Ray
  • 5,228
  • 2
  • 27
  • 43
  • Alright, so let's say single object GET methods are public, but we want AAA security for sensible data and other operations. All data will be transferred/requested using TLS/SSL. But to access or modify sensible data, the API should issue bearer tokens (with JWT) once it was provided by the user's session a valid oAuth token? – Dialvive Jan 01 '21 at 19:04
  • 1
    @Dialvive pretty much! the bearer token will be passed in headers; the first thing your endpoint should do is perform some oauth-ish authorization policy checks on it – Debosmit Ray Jan 01 '21 at 19:19
  • 2
    There's no reason to use an ORM to prevent SQL injections. If you choose to use an ORM becuase you want an ORM, fine, but do it for a valid reason. – Jonathan Hall Jan 01 '21 at 21:16
  • @Flimzy I think ORM can help to avoid human written vulnerabilities while manipulating the DB. And user input should be checked for SQL syntax right? – Dialvive Jan 01 '21 at 23:33
  • 1
    No, user input should not be checked for SQL syntax. It should be either quoted, or passed as a variable--then SQL syntax is utterly irrelevant. And an ORM isn't needed for either of those things. – Jonathan Hall Jan 02 '21 at 09:17