[BUGS] BUG #1049: Invalid SQL Executed as JDBC Prepared Statement still executes embedded SQL
The following bug has been logged online: Bug reference: 1049 Logged by: Tom Hargrave Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.2 Operating system: Linux Description:Invalid SQL Executed as JDBC Prepared Statement still executes embedded SQL Details: If a piece of SQL is executed in a JDBC prepared statement that includes a semicolon and a valid piece of SQL, then the embedded valid piece of SQL still executes even though the overall statement is invalid. Example: select c1 from t1 order by;drop t2; c1 This causes security issues if the SQL is constructed from a web page that inputs strings that are used to construct a statement, since a hacker can embed SQL within a single field that executes regardless of the overall statement being invalid. See article: http://www.computerweekly.com/articles/article.asp?liArticleID=127470&liFla vourID=1 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1049: Invalid SQL Executed as JDBC Prepared Statement still executes embedded SQL
On Wednesday 14 January 2004 12:48, PostgreSQL Bugs List wrote: > The following bug has been logged online: > > Bug reference: 1049 > Logged by: Tom Hargrave > Email address: [EMAIL PROTECTED] > Description:Invalid SQL Executed as JDBC Prepared Statement still > executes embedded SQL > select c1 from t1 order by;drop t2; c1 Does JDBC not include the ability to escape supplied parameters so "dangerous" characters are handled properly? Or are you saying that it fails to deal with semicolons? > This causes security issues if the SQL is constructed from a web page that > inputs strings that are used to construct a statement, since a hacker can > embed SQL within a single field that executes regardless of the overall > statement being invalid. NEVER allow unchecked data from an untrusted user into your system. This is standard security practice. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1050: cannot restore db at postgresql 7.4.1
The following bug has been logged online: Bug reference: 1050 Logged by: Taku YASUI Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Debian GNU/Linux Description:cannot restore db at postgresql 7.4.1 Details: I tried to upgrade postgresql from 7.1.2(other host) to 7.4.1(localhost). However an error occured and failed restore. I tried following steps. % pg_dump --version pg_dump (PostgreSQL) 7.4.1 % pg_dump -b -Fc -h host -U user dbname -f dbname.dump % pg_restore -v -d dbname dbname.dump : pg_restore: restoring data for table "table_name" pg_restore: ERROR: invalid input syntax for integer: " " CONTEXT: COPY table_name, line 2, column column_name: " " pg_restore: [archiver (db)] error returned by PQendcopy pg_restore: *** aborted because of error This error does not occur 7.3.4. I found a modification from 7.3 to 7.4 to cause this problem. The release notes of 7.4 saids: COPY now can process files that use carriage-return or carriage-return/line-feed end-of-line sequences. Literal carriage-returns and line-feeds are no longer accepted in data values; use \r and \n instead. When I tried to use '-d' option to run pg_dump, pg_restore completed. Therefore, I think this modification causes the problem. I think this is bug and pg_dump/pg_restore should be fixed to keep with this modification. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1050: cannot restore db at postgresql 7.4.1
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > The release notes of 7.4 saids: > COPY now can process files that use carriage-return or > carriage-return/line-feed end-of-line sequences. Literal carriage-returns > and line-feeds are no longer accepted in data values; use \r and \n instead. > I think this is bug and pg_dump/pg_restore should > be fixed to keep with this modification. This was a deliberate change and will not be undone, even though it does create compatibility issues with dumps from very old PG versions. The best workaround I know of for dumping from such an old server is to use the "dump as INSERT commands" option. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
