Re: vulnerability of COPY command - Mailing list pgsql-general
| From | Martin Gainty |
|---|---|
| Subject | Re: vulnerability of COPY command |
| Date | |
| Msg-id | BLU142-W268927523D3F53A0EF1DEBAEED0@phx.gbl Whole thread Raw |
| In response to | vulnerability of COPY command (Dennis Gearon <gearond@sbcglobal.net>) |
| Responses |
Re: vulnerability of COPY command
("Wappler, Robert" <rwappler@ophardt.com>)
|
| List | pgsql-general |
i have mixed feelings about parameterised statements.
On the one hand a parameterised statement would be more difficult for a Wireshark criminal to insert their own c**p into a database because they would have to know the schema a-priori for example they would have to know the names of the database, table and the datatypes of these 2 statements
Insert DateField1 INTO DateTable VALUES(1) would gack as 1 is not a valid date
Insert NumericField1 INTO NumericTable VALUES('A') would gack as well as A is not a valid number
But thats only one line of defence..Struts..JSF and other Frameworks have field validators so a good design would involve 2 tiered defence
1)The web folks would put some kind of JS function to disallow client know from enetering a invalid date
2)The back-end folks (me) would validate Database params in the servlet or the DTO as it makes its way to the VO and before any of the offending values get into the database
The net effect is wireshark criminals are succeeding in making everyone's lives a living hell..the least we can do is take their pitchfork away!
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Date: Sat, 29 May 2010 22:41:04 -0700
> From: gearond@sbcglobal.net
> Subject: [GENERAL] vulnerability of COPY command
> To: pgsql-general@postgresql.org
>
> I'm trying to build a way to bulk load from a script to a Dbase, postgres.
>
> Using single, parameterized statements is a pretty good defense against SQL injection, so I use Symfony as the main user input.
>
> But for this bulk loading, it's tooooooo slow.
>
> If I build a text based, COPY file for bulk purposes, to be input via the command line, is Postgres vulnerable to SQL injection from that?
>
>
> Dennis Gearon
>
> Signature Warning
> ----------------
> EARTH has a Right To Life,
> otherwise we all die.
>
> Read 'Hot, Flat, and Crowded'
> Laugh at http://www.yert.com/film.php
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started.
On the one hand a parameterised statement would be more difficult for a Wireshark criminal to insert their own c**p into a database because they would have to know the schema a-priori for example they would have to know the names of the database, table and the datatypes of these 2 statements
Insert DateField1 INTO DateTable VALUES(1) would gack as 1 is not a valid date
Insert NumericField1 INTO NumericTable VALUES('A') would gack as well as A is not a valid number
But thats only one line of defence..Struts..JSF and other Frameworks have field validators so a good design would involve 2 tiered defence
1)The web folks would put some kind of JS function to disallow client know from enetering a invalid date
2)The back-end folks (me) would validate Database params in the servlet or the DTO as it makes its way to the VO and before any of the offending values get into the database
The net effect is wireshark criminals are succeeding in making everyone's lives a living hell..the least we can do is take their pitchfork away!
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Sat, 29 May 2010 22:41:04 -0700
> From: gearond@sbcglobal.net
> Subject: [GENERAL] vulnerability of COPY command
> To: pgsql-general@postgresql.org
>
> I'm trying to build a way to bulk load from a script to a Dbase, postgres.
>
> Using single, parameterized statements is a pretty good defense against SQL injection, so I use Symfony as the main user input.
>
> But for this bulk loading, it's tooooooo slow.
>
> If I build a text based, COPY file for bulk purposes, to be input via the command line, is Postgres vulnerable to SQL injection from that?
>
>
> Dennis Gearon
>
> Signature Warning
> ----------------
> EARTH has a Right To Life,
> otherwise we all die.
>
> Read 'Hot, Flat, and Crowded'
> Laugh at http://www.yert.com/film.php
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started.
pgsql-general by date: