ecmascript 5 DATESTYLE
in [PgSql]
|
Prev: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next: Stefan's bug (was: max_standby_delay consideredharmful)
From: Pavel Stehule on 19 May 2010 04:54 2010/5/19 Mike Fowler <mike(a)mlfowler.com>: > Pavel Stehule wrote: >> >> 2010/5/19 Peter Eisentraut <peter_e(a)gmx.net>: >> >>> >>> On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote: >>> >>>> >>>> ecmascript 5 is the most recent specification for JavaScript and i >>>> would think that having a DATESTYLE format to simplify >>>> interoperability with JavaScript applications would be highly >>>> desirable. >>>> >>> >>> Note that we haven't got any other datestyles that are intended to >>> support interoperability with some language. Â It is usually the job of >>> the client driver to convert PostgreSQL data (plural of datum) to the >>> appropriate type and format for the client environment or language. Â Is >>> there any reason why JavaScript would be different? >>> > > I wouldn't be keen to see dedicated language specific handling of > date/datetime formats. It would lead to an explosion of functions with new > languages needing adding as and when their users jumped up and down on us. > However a generic format could be very useful and would give the opportunity > for people who need a language specific short cut the opportunity to do a > CREATE FUNCTION wrapping the generic one with a hard coded format specifier. > > Other platforms have generic support for this kind of task, for example > SQLServer: http://msdn.microsoft.com/en-us/library/ms187928.aspx. I wouldn't > recommend the SQLServer way, I think numeric format specifiers are clumsy. > Perhaps a mechanism like Java which is nicely summarized here: > http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html > > Pavel: Why do you believe a generic format function would lead to SQL > injections attacks? see google: lateral sql injection oracle NLS_DATE_FORMAT I would to like this functionality too - and technically I don't see a problem - It's less than 100 lines, but I don't need a new security problem. So my proposal is change nothing on this integrated functionality and add new custom date type - like cdate that can be customized via GUC. Regards Pavel > >> JavaScript isn't special language, but JSON is wide used format for >> interoperability. And same is true for XML datestyle format. >> >> Regards >> Pavel >> > > I think that the postgres handling of those data types should handle the > date encoding themselves. For example, a XMLELEMENT call that was passed a > date would format the date string to the xs:date format (e.g. 2010-05-19) > and when passed a timestamp format to xs:datetime (e.g. > 2010-05-19T09:29:52+01:00). I would see the JSON handling as being no > different. > > Thanks, > > -- > Mike Fowler > Registered Linux user: 379787 > > "I could be a genius if I just put my mind to it, and I, > I could do anything, if only I could get 'round to it" > -PULP 'Glory Days' > > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mike Fowler on 19 May 2010 06:15 Pavel Stehule wrote: > see google: lateral sql injection oracle NLS_DATE_FORMAT > > I would to like this functionality too - and technically I don't see a > problem - It's less than 100 lines, but I don't need a new security > problem. So my proposal is change nothing on this integrated > functionality and add new custom date type - like cdate that can be > customized via GUC. > > Regards > Pavel OK I found www.databasesecurity.com/dbsec/lateral-sql-injection.pdf. From the way I read this, the exploit relies on adjusting the NLS_DATE_FORMAT to an arbitrary string which is then used for the attack, To me this is easy to code against, simply lock the date format right down and ensure that it is always controlled. IMHO I don't see an Oracle specific attack as a reason why we can't have a generic format. Surely we can learn from this known vulnerability and get another one up on Oracle? Thanks, -- Mike Fowler Registered Linux user: 379787 "I could be a genius if I just put my mind to it, and I, I could do anything, if only I could get 'round to it" -PULP 'Glory Days' -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 May 2010 06:21 2010/5/19 Mike Fowler <mike(a)mlfowler.com>: > Pavel Stehule wrote: >> >> see google: lateral sql injection oracle NLS_DATE_FORMAT >> >> I would to like this functionality too - and technically I don't see a >> problem - It's less than 100 lines, but I don't need a new security >> problem. So my proposal is change nothing on this integrated >> functionality and add new custom date type - like cdate that can be >> customized via GUC. >> >> Regards >> Pavel > > OK I found www.databasesecurity.com/dbsec/lateral-sql-injection.pdf. From > the way I read this, the exploit relies on adjusting the NLS_DATE_FORMAT to > an arbitrary string which is then used for the attack, To me this is easy to > code against, simply lock the date format right down and ensure that it is > always controlled. IMHO I don't see an Oracle specific attack as a reason > why we can't have a generic format. Surely we can learn from this known > vulnerability and get another one up on Oracle? I am not a security expert - you can simply don't allow apostrophe, double quotes - but I am not sure, if this can be safe - simply - I am abe to write this patch, but I am not able to ensure security. Regards Pavel > > Thanks, > > -- > Mike Fowler > Registered Linux user: 379787 > > "I could be a genius if I just put my mind to it, and I, > I could do anything, if only I could get 'round to it" > -PULP 'Glory Days' > > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mike Fowler on 19 May 2010 06:37 Pavel Stehule wrote: > 2010/5/19 Mike Fowler <mike(a)mlfowler.com>: > >> Pavel Stehule wrote: >> >>> see google: lateral sql injection oracle NLS_DATE_FORMAT >>> >>> I would to like this functionality too - and technically I don't see a >>> problem - It's less than 100 lines, but I don't need a new security >>> problem. So my proposal is change nothing on this integrated >>> functionality and add new custom date type - like cdate that can be >>> customized via GUC. >>> >>> Regards >>> Pavel >>> >> OK I found www.databasesecurity.com/dbsec/lateral-sql-injection.pdf. From >> the way I read this, the exploit relies on adjusting the NLS_DATE_FORMAT to >> an arbitrary string which is then used for the attack, To me this is easy to >> code against, simply lock the date format right down and ensure that it is >> always controlled. IMHO I don't see an Oracle specific attack as a reason >> why we can't have a generic format. Surely we can learn from this known >> vulnerability and get another one up on Oracle? >> > > I am not a security expert - you can simply don't allow apostrophe, > double quotes - but I am not sure, if this can be safe - simply - I am > abe to write this patch, but I am not able to ensure security. > > Regards > Pavel > Well you've rightly identified a potential security hole, so my recommendation would be to put the patch together bearing in mind the Oracle vulnerability. Once you've submitted the patch it can be reviewed and we can ensure that you've managed to steer clear of introducing the same/similar vulnerability into postgres. Am I right in thinking that you're now proposing to do the generic patch that Robert Haas and I prefer? Thanks, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 May 2010 06:43
2010/5/19 Mike Fowler <mike(a)mlfowler.com>: > Pavel Stehule wrote: >> >> 2010/5/19 Mike Fowler <mike(a)mlfowler.com>: >> >>> >>> Pavel Stehule wrote: >>> >>>> >>>> see google: lateral sql injection oracle NLS_DATE_FORMAT >>>> >>>> I would to like this functionality too - and technically I don't see a >>>> problem - It's less than 100 lines, but I don't need a new security >>>> problem. So my proposal is change nothing on this integrated >>>> functionality and add new custom date type - like cdate that can be >>>> customized via GUC. >>>> >>>> Regards >>>> Pavel >>>> >>> >>> OK I found www.databasesecurity.com/dbsec/lateral-sql-injection.pdf. From >>> the way I read this, the exploit relies on adjusting the NLS_DATE_FORMAT >>> to >>> an arbitrary string which is then used for the attack, To me this is easy >>> to >>> code against, simply lock the date format right down and ensure that it >>> is >>> always controlled. IMHO I don't see an Oracle specific attack as a reason >>> why we can't have a generic format. Surely we can learn from this known >>> vulnerability and get another one up on Oracle? >>> >> >> I am not a security expert - you can simply don't allow apostrophe, >> double quotes - but I am not sure, if this can be safe - simply - I am >> abe to write this patch, but I am not able to ensure security. >> >> Regards >> Pavel >> > > Well you've rightly identified a potential security hole, so my > recommendation would be to put the patch together bearing in mind the Oracle > vulnerability. Once you've submitted the patch it can be reviewed and we can > ensure that you've managed to steer clear of introducing the same/similar > vulnerability into postgres. > > Am I right in thinking that you're now proposing to do the generic patch > that Robert Haas and I prefer? I'll look on code and I'll see Pavel > > Thanks, > > -- > Mike Fowler > Registered Linux user: 379787 > > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |