Re: ERROR: unsupported Unicode escape sequence - in JSON-type column

Поиск
Список
Период
Сортировка
Искать
От
Jan Bilek
Тема
Re: ERROR: unsupported Unicode escape sequence - in JSON-type column
Дата
Msg-id
63ae2d9c-fc24-1de8-63e2-10bb0b6c6e5a@eftlab.com.au
Ответ на
Список
Дерево обсуждения
PCI:SSF - Safe SQL Query & operators filter Jan Bilek <jan.bilek@eftlab.com.au>
Re: PCI:SSF - Safe SQL Query & operators filter Christophe Pettus <xof@thebuild.com>
Re: PCI:SSF - Safe SQL Query & operators filter Jan Bilek <jan.bilek@eftlab.com.au>
Re: PCI:SSF - Safe SQL Query & operators filter Christophe Pettus <xof@thebuild.com>
Re: PCI:SSF - Safe SQL Query & operators filter Jan Bilek <jan.bilek@eftlab.com.au>
Re: PCI:SSF - Safe SQL Query & operators filter Laurenz Albe <laurenz.albe@cybertec.at>
Re: PCI:SSF - Safe SQL Query & operators filter Jan Bilek <jan.bilek@eftlab.com.au>
ERROR: unsupported Unicode escape sequence - in JSON-type column Jan Bilek <jan.bilek@eftlab.com.au>
Re: ERROR: unsupported Unicode escape sequence - in JSON-type column Laurenz Albe <laurenz.albe@cybertec.at>
Re: ERROR: unsupported Unicode escape sequence - in JSON-type column Erik Wienhold <ewie@ewie.name>
Re: ERROR: unsupported Unicode escape sequence - in JSON-type column Tom Lane <tgl@sss.pgh.pa.us>
Re: ERROR: unsupported Unicode escape sequence - in JSON-type column Jan Bilek <jan.bilek@eftlab.com.au>
Re: ERROR: unsupported Unicode escape sequence - in JSON-type column Jan Bilek <jan.bilek@eftlab.com.au>
Re: PCI:SSF - Safe SQL Query & operators filter Laurenz Albe <laurenz.albe@cybertec.at>
Re: PCI:SSF - Safe SQL Query & operators filter Jeffrey Walton <noloader@gmail.com>
Re: PCI:SSF - Safe SQL Query & operators filter "David G. Johnston" <david.g.johnston@gmail.com>
On 2/28/23 01:17, Erik Wienhold wrote:
>> On 27/02/2023 13:13 CET Laurenz Albe  wrote:
>>
>> I'd be curious to know how the customer managed to do that.
>> Perhaps there is a loophole in PostgreSQL that needs to be fixed.
> Probably via some data access layer and not directly via Postgres.  It's easy
> to reproduce with psycopg:
>
> 	import psycopg
>
> 	with psycopg.connect() as con:
> 	    con.execute('create temp table jsontab (jsoncol json)')
> 	    con.execute(
> 	        'insert into jsontab (jsoncol) values (%s)',
> 	        [psycopg.types.json.Json('\0')],
> 	    )
>
> 	    with con.execute('select jsoncol from jsontab') as cur:
> 	        print(cur.fetchall())
>
> 	    try:
> 	        with con.execute('select jsoncol::jsonb from jsontab') as cur:
> 	            pass
> 	        raise AssertionError("jsonb should fail")
> 	    except psycopg.errors.UntranslatableCharacter:
> 	        pass
>
> Another reason to prefer jsonb over json to reject such inputs right away.
> The documentation states that json does not validate inputs in constrast to
> jsonb.
>
> Of course the OP now has to deal with json.  The data can be sanitized by
> replacing all null character escape sequences:
>
> 	update jsontab
> 	set jsoncol = replace(jsoncol::text, '\u0000', '')::json
> 	where strpos(jsoncol::text, '\u0000') > 0;
>
> But the data access layer (or whatever got the json into the database) must be
> fixed as well to reject or sanitize those inputs in the future.
>
> --
> Erik

Hi Erik,

No, it didn't go through any foreign data access layer - it went in 
straight through the Postgresql variable bind using pre-cached insert 
statement using PostgreSQL 14.5, connected over UNIX sockets.

Strange thing happened afterwards - that locating that record was on & 
off - I couldn't pin-point it in DB as it seemed to be failing on 
multiple places ... until using that trick from Laurenz. Felt like a 
PostgreSQL memory corruption, but system remained stable without any 
complaints.

Thanks & Cheers,
Jan

-- 
Jan Bilek - CTO at EFTlab Pty Ltd.

В списке pgsql-general по дате отправления
От: Jan Bilek
Дата:
От: Thorsten Glaser
Дата:
FAQ