6

Postgres allows dynamic code execution, which might leave it vulnerable to SQL injection.

What protective measures does it have against this?

LINUX G33NYUS
  • 245
  • 3
  • 6

2 Answers2

9

The same as any other database using SQL, use the following (taken from the OWASP cheat sheet)

  • Option #1: Use of Prepared Statements (Parameterized Queries)
  • Option #2: Use of Stored Procedures
  • Option #3: Escaping all User Supplied Input
  • Also Enforce: Least Privilege
  • Also Perform: White List Input Validation
LINUX G33NYUS
  • 245
  • 3
  • 6
Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • But these are all things that you have to configure, is that correct? If Postgres isn't specifically configured to defend against SQL injection, is it vulnerable? – LINUX G33NYUS Mar 07 '17 at 22:15
  • Same as any database that uses SQL, if you use all the functionality, yes it will be vulnerable. So you do the same as you do with other databases - standard protection. That then removes the vulnerability to SQLi – Rory Alsop Mar 07 '17 at 22:34
7

SQL injection is an application threat, not a database threat. In the end, all relational databases execute the SQL which is passed to them as a string. And it is the responsibility of the application developer to make sure that SQL string is not harmful.

SQL injection is a way to cause an application to send SQL strings to the database which are harmful, and doing so in a way that may not be obvious in the first view to the application developer. E. g. if the application contains code like

string sql_stmt = "select a from t where k = '" + textfield.text + "'"

where textfield.text would be some text entered by the user in the application, and you send sql to the database, then a clever user could enter

';drop table t; --

into the text field, which would result in the string

select a from t where k = '';drop table t; --'

being sent to the database, and table t would be dropped.

But this is a fault of the application developer, not the database. The database just executes whatever sql is sent to it. And in the end it has to have the possibility to drop tables.

As @RoryAlsop already stated in his answer, Postgres - like many other databases - offers some support for application developers to ease developing secure code (permissions, prepared statements, etc.), but in the end it is the responsibility of the application developer to use these or other methods to protect the application against SQL injection, as that is where it can occur. Databases are not the level where this is a threat, they are only where the effect of the fault occurs.

FrankPl
  • 191
  • 2