Re: Passing a table as parameter

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Vibhor Kumar <vibhor(dot)kumar(at)enterprisedb(dot)com>
Cc: Jon Smark <jon(dot)smark(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Passing a table as parameter
Date: 2011-03-21 21:09:33
Message-ID: AANLkTikWYfafLK8_bgR1T2DO5vyta955ouogKNv_PFLP@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2011/3/21 Vibhor Kumar <vibhor(dot)kumar(at)enterprisedb(dot)com>:
>
> On Mar 22, 2011, at 1:52 AM, Pavel Stehule wrote:
>
>> simply thinks as using USAGE clause or functions quote_ident,
>> quote_literal are faster and absolutly secure :). Software like SQL
>
> I don't think usage of quote_ident in current requirement of user, would prevent sql injection.
> Running sql multiple times, someone can guess the tabename which can give data:
> ERROR:  relation "am" does not exist
> LINE 1: SELECT content FROM am ^QUERY:  SELECT content FROM amCONTEXT:  PL/pgSQL function "foo" line 2 at RETURN QUERY
>
> SQL Protect will make above message something like given below:
> ERROR:  SQLPROTECT: Illegal Query: relations
>

it is different view on security. When you have not a security gap,
then is irelevant if somebody has unlimited number of trials. SQL
Protect is "security by obscurity" - a logout can be a good sign for
blind injection.

well usage of quote_ident and quote_literal is a perfect protection
against sql injection. Wrong query doesn't mean a problem. Problem is
when attacker can change a semantic of SQL query.

Pavel

> Which stops user guessing relation.
>
> Thanks & Regards,
> Vibhor Kumar
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
> vibhor(dot)kumar(at)enterprisedb(dot)com
> Blog:http://vibhork.blogspot.com
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrej 2011-03-21 21:32:05 Re: postgresql install problem
Previous Message Vibhor Kumar 2011-03-21 20:47:26 Re: Passing a table as parameter