Re: Consulta sobre standard_conforming_strings

2024-03-14 Thread felix gonzales 
gracias Horacio por tu aporte

On Thu, Mar 14, 2024 at 8:03 PM Horacio Miranda  wrote:

> no creo que esa persona sepa bien lo que es SQL Injection.
>
> Si bien un parametro puede hacer que sea más restrictivo el postgresql el
> concepto es simple, Prepared Statements. Si tu aplicación no las tiene, te
> pueden hacer SQL Injection
>
> SQL Injection | OWASP Foundation
> 
> owasp.org 
> [image: favicon.ico]
> 
> 
>
> Este parametro “standard_conforming_strings” se refiere a como tratar el
> caracter especial backslash “\” usualmente es un caracter comoding para
> indicar en expresiones regulares, trata el sigueinte caracter como string
> no como algo especial. por lo que dice es algo forzado en on y se puede
> apagar.
>
> Esto no tiene relación con un SQL Injection.
>
>
> On 14/03/2024, at 9:47 PM, felix gonzales  wrote:
>
> Buenas noches.
>
> Esperaba algún comentario a la consulta, que hice en la mañana, ya que
> necesito brindar una respuesta a las afirmaciones hechas por otra persona
> en mi empresa quien manifiesta que el parámetro
> "standard_conforming_strings en off, pondría en riesgo el servidor al nivel
> de dejar abierta la amenaza de  provocar inyecciones de SQL y problemas de
> seguridad similares"
> y hace referencia a esta documentación:
> https://www.postgresql.org/docs/14/sql-syntax-lexical.html
>
> Revisando dicho enlace hallé lo siguiente:
>
> "4.1.2.3. String Constants With Unicode Escapes
> .
> Also, the Unicode escape syntax for string constants only works when the
> configuration parameter standard_conforming_strings
> 
>  is
> turned on. This is because otherwise this syntax could confuse clients that
> parse the SQL statements to the point that it could lead to SQL injections
> and similar security issues. If the parameter is set to off, this syntax
> will be rejected with an error message."
>
> Este párrafo no me queda muy claro (en la última línea indica que si el
> parámetro está en off  la sintaxis se rechaza con un mensaje de error),
> por ello pedía opiniones.
>
> Tengo claro que actualizar la función es lo más conveniente para evitar
> mover el parámetro. Pero también necesito sustentar una respuesta que
> estando en off no es tan grave como lo indica o me equivoco?.
>
>
> On Thu, Mar 14, 2024 at 10:55 AM felix gonzales 
> wrote:
>
>> Buenos días grupo
>> Comentarles que tengo una base de datos con postgres-14, dentro de la
>> cual hay una función migrada desde postgres-9. Para que funcione
>> adecuadamente  debo cambiar el parámetro "standard_conforming_strings" a
>> off  y así evitar el warning.
>>
>> consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al
>> nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y
>> problemas de seguridad similares?
>>
>> Quedo atento a sus comentarios.
>>
>> Gracias
>> --
>> Felix Gonzales
>>
>>
>
> --
> Felix Gonzales
>
>
>

-- 
Felix Gonzales


favicon.ico
Description: Binary data

Re: Consulta sobre standard_conforming_strings

2024-03-14 Thread Horacio Miranda 
no creo que esa persona sepa bien lo que es SQL Injection.

Si bien un parametro puede hacer que sea más restrictivo el postgresql el 
concepto es simple, Prepared Statements. Si tu aplicación no las tiene, te 
pueden hacer SQL Injection

https://owasp.org/www-community/attacks/SQL_Injection

Este parametro “standard_conforming_strings” se refiere a como tratar el 
caracter especial backslash “\” usualmente es un caracter comoding para indicar 
en expresiones regulares, trata el sigueinte caracter como string no como algo 
especial. por lo que dice es algo forzado en on y se puede apagar.

Esto no tiene relación con un SQL Injection.


> On 14/03/2024, at 9:47 PM, felix gonzales  wrote:
> 
> Buenas noches.
> 
> Esperaba algún comentario a la consulta, que hice en la mañana, ya que 
> necesito brindar una respuesta a las afirmaciones hechas por otra persona en 
> mi empresa quien manifiesta que el parámetro "standard_conforming_strings en 
> off, pondría en riesgo el servidor al nivel de dejar abierta la amenaza de  
> provocar inyecciones de SQL y problemas de seguridad similares" 
> y hace referencia a esta documentación:  
> https://www.postgresql.org/docs/14/sql-syntax-lexical.html
> 
> Revisando dicho enlace hallé lo siguiente:
> 
> "4.1.2.3. String Constants With Unicode Escapes
> .
> Also, the Unicode escape syntax for string constants only works when the 
> configuration parameter standard_conforming_strings 
> 
>  is turned on. This is because otherwise this syntax could confuse clients 
> that parse the SQL statements to the point that it could lead to SQL 
> injections and similar security issues. If the parameter is set to off, this 
> syntax will be rejected with an error message."
> 
> Este párrafo no me queda muy claro (en la última línea indica que si el 
> parámetro está en off  la sintaxis se rechaza con un mensaje de error),  por 
> ello pedía opiniones.
> 
> Tengo claro que actualizar la función es lo más conveniente para evitar mover 
> el parámetro. Pero también necesito sustentar una respuesta que estando en 
> off no es tan grave como lo indica o me equivoco?.
> 
> 
> On Thu, Mar 14, 2024 at 10:55 AM felix gonzales  > wrote:
>> Buenos días grupo
>> Comentarles que tengo una base de datos con postgres-14, dentro de la cual 
>> hay una función migrada desde postgres-9. Para que funcione adecuadamente  
>> debo cambiar el parámetro "standard_conforming_strings" a off  y así evitar 
>> el warning.
>> 
>> consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al 
>> nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y 
>> problemas de seguridad similares?
>> 
>> Quedo atento a sus comentarios.
>> 
>> Gracias
>> -- 
>> Felix Gonzales
>> 
> 
> 
> -- 
> Felix Gonzales
>

Re: Consulta sobre standard_conforming_strings

2024-03-14 Thread felix gonzales 
Buenas noches.

Esperaba algún comentario a la consulta, que hice en la mañana, ya que
necesito brindar una respuesta a las afirmaciones hechas por otra persona
en mi empresa quien manifiesta que el parámetro
"standard_conforming_strings en off, pondría en riesgo el servidor al nivel
de dejar abierta la amenaza de  provocar inyecciones de SQL y problemas de
seguridad similares"
y hace referencia a esta documentación:
https://www.postgresql.org/docs/14/sql-syntax-lexical.html

Revisando dicho enlace hallé lo siguiente:

"4.1.2.3. String Constants With Unicode Escapes
.
Also, the Unicode escape syntax for string constants only works when the
configuration parameter standard_conforming_strings

is
turned on. This is because otherwise this syntax could confuse clients that
parse the SQL statements to the point that it could lead to SQL injections
and similar security issues. If the parameter is set to off, this syntax
will be rejected with an error message."

Este párrafo no me queda muy claro (en la última línea indica que si el
parámetro está en off  la sintaxis se rechaza con un mensaje de error),
por ello pedía opiniones.

Tengo claro que actualizar la función es lo más conveniente para evitar
mover el parámetro. Pero también necesito sustentar una respuesta que
estando en off no es tan grave como lo indica o me equivoco?.


On Thu, Mar 14, 2024 at 10:55 AM felix gonzales 
wrote:

> Buenos días grupo
> Comentarles que tengo una base de datos con postgres-14, dentro de la cual
> hay una función migrada desde postgres-9. Para que funcione adecuadamente
> debo cambiar el parámetro "standard_conforming_strings" a off  y así evitar
> el warning.
>
> consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al
> nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y
> problemas de seguridad similares?
>
> Quedo atento a sus comentarios.
>
> Gracias
> --
> Felix Gonzales
>
>

-- 
Felix Gonzales

Consulta sobre standard_conforming_strings

2024-03-14 Thread felix gonzales 
Buenos días grupo
Comentarles que tengo una base de datos con postgres-14, dentro de la cual
hay una función migrada desde postgres-9. Para que funcione adecuadamente
debo cambiar el parámetro "standard_conforming_strings" a off  y así evitar
el warning.

consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al
nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y
problemas de seguridad similares?

Quedo atento a sus comentarios.

Gracias
-- 
Felix Gonzales

Re: Error en barman

2024-03-14 Thread Jaime Soler 
Buenas Guillermo,

Con la info que has pasado, no se vé claro que puede ser. Tal como decía
Mario, será mejor que pongas el log en debug , un momento , y así capturas
más detalles del error
según aparece en el código de barman (
https://github.com/EnterpriseDB/barman/blob/26ed480cd0268dfd3f8546cc97660d4bd827772a/barman/config.py#L2054-L2070
)
Para ponerlo en debug, es cambiando el parámetro log_level =DEBUG , en el
fichero barman.conf

Un saludo

El jue, 14 mar 2024 a las 14:24, Guillermo E. Villanueva (<
guillermo...@gmail.com>) escribió:

> Les paso el diagnose y el contenido del archivo de configuración del
> server santacruz
> A pesar de que todo parece funcionar bien, el log sigue mostrando el error
> mencionado.
> /etc/braman.d/santacruz.conf
> [santacruz]
> description =  "PJud de Santa Cruz Pg (via SSH)"
> backup_directory = /home/barman/santacruz
> ssh_command = ssh postgres@192.168.172.33
> conninfo = host=192.168.172.33 port=5432 user=barman password=xxx
> dbname=postgres
> backup_method = rsync
> streaming_archiver = off
> archiver = on
>
>
> El mié, 13 mar 2024 a las 13:08, Jaime Soler ()
> escribió:
>
>> ¿ Puedes compartir la salida de barman diagnose y la configuración del
>> fichero de backup de tu servidor que se guarda dentro de /etc/barman.d ? ,
>> parece como si no parseara bien alguno de los ficheros de configuración y
>> lo que compartiste parece que está bien, por eso te pido el otro fichero.
>>
>> Un saludo
>>
>> El mié, 13 mar 2024 a las 14:24, Guillermo E. Villanueva (<
>> guillermo...@gmail.com>) escribió:
>>
>>> Hola buen día, en un debian 11 instalé barman 3.10, ya lo configuré para
>>> backups con rsync y parece que va todo ok, los wal llegan correctamente y
>>> el primer full funcionó correctamente pero en el log de barman, cada minuto
>>> tengo el siguiente error:
>>>
>>> .  [3029] barman.config ERROR: Cannot execute None: Expecting value:
>>> line 1 column 1 (char 0)
>>>
>>> El archivo barman.conf tiene lo siguiente:
>>> [barman]
>>> barman_user = barman
>>> configuration_files_directory = /etc/barman.d
>>> backup_options = exclusive_backup
>>> reuse_backup = link
>>> barman_home = /var/lib/barman
>>> log_file = /var/log/barman/barman.log
>>> log_level = ERROR
>>> compression = gzip
>>> immediate_checkpoint = true
>>> basebackup_retry_times = 3
>>> basebackup_retry_sleep = 30
>>> last_backup_maximum_age = 7 DAYS
>>> retention_policy = RECOVERY WINDOW OF 3 WEEKS
>>>
>>> barman check all tambien me da todo ok.
>>>
>>> ¿Qué podrá ser lo del error que muestra el log?
>>> Desde ya muchas gracias!
>>>
>>>

Re: Error en barman

2024-03-14 Thread Guillermo E. Villanueva 
Les paso el diagnose y el contenido del archivo de configuración del server
santacruz
A pesar de que todo parece funcionar bien, el log sigue mostrando el error
mencionado.
/etc/braman.d/santacruz.conf
[santacruz]
description =  "PJud de Santa Cruz Pg (via SSH)"
backup_directory = /home/barman/santacruz
ssh_command = ssh postgres@192.168.172.33
conninfo = host=192.168.172.33 port=5432 user=barman password=xxx
dbname=postgres
backup_method = rsync
streaming_archiver = off
archiver = on


El mié, 13 mar 2024 a las 13:08, Jaime Soler ()
escribió:

> ¿ Puedes compartir la salida de barman diagnose y la configuración del
> fichero de backup de tu servidor que se guarda dentro de /etc/barman.d ? ,
> parece como si no parseara bien alguno de los ficheros de configuración y
> lo que compartiste parece que está bien, por eso te pido el otro fichero.
>
> Un saludo
>
> El mié, 13 mar 2024 a las 14:24, Guillermo E. Villanueva (<
> guillermo...@gmail.com>) escribió:
>
>> Hola buen día, en un debian 11 instalé barman 3.10, ya lo configuré para
>> backups con rsync y parece que va todo ok, los wal llegan correctamente y
>> el primer full funcionó correctamente pero en el log de barman, cada minuto
>> tengo el siguiente error:
>>
>> .  [3029] barman.config ERROR: Cannot execute None: Expecting value:
>> line 1 column 1 (char 0)
>>
>> El archivo barman.conf tiene lo siguiente:
>> [barman]
>> barman_user = barman
>> configuration_files_directory = /etc/barman.d
>> backup_options = exclusive_backup
>> reuse_backup = link
>> barman_home = /var/lib/barman
>> log_file = /var/log/barman/barman.log
>> log_level = ERROR
>> compression = gzip
>> immediate_checkpoint = true
>> basebackup_retry_times = 3
>> basebackup_retry_sleep = 30
>> last_backup_maximum_age = 7 DAYS
>> retention_policy = RECOVERY WINDOW OF 3 WEEKS
>>
>> barman check all tambien me da todo ok.
>>
>> ¿Qué podrá ser lo del error que muestra el log?
>> Desde ya muchas gracias!
>>
>>
{
"global": {
"config": {
"backup_options": "exclusive_backup",
"barman_home": "/var/lib/barman",
"barman_user": "barman",
"basebackup_retry_sleep": "30",
"basebackup_retry_times": "3",
"compression": "gzip",
"configuration_files_directory": "/etc/barman.d",
"errors_list": [],
"immediate_checkpoint": "true",
"last_backup_maximum_age": "7 DAYS",
"log_file": "/var/log/barman/barman.log",
"log_level": "ERROR",
"retention_policy": "RECOVERY WINDOW OF 3 WEEKS",
"reuse_backup": "link"
},
"system_info": {
"barman_ver": "3.10.0",
"kernel_ver": "Linux Debian-05-V11 5.10.0-28-amd64 #1 SMP Debian 
5.10.209-2 (2024-01-31) x86_64 GNU/Linux",
"python_ver": "",
"release": "Distributor ID:\tDebian\nDescription:\tDebian GNU/Linux 
11 (bullseye)\nRelease:\t11\nCodename:\tbullseye",
"rsync_ver": "rsync  version 3.2.3  protocol version 31",
"ssh_ver": "",
"timestamp": "2024-03-14T10:19:37.108502-03:00"
}
},
"models": {},
"servers": {
"santacruz": {
"active_model": null,
"backups": {
"20240313T101426": {
"backup_id": "20240313T101426",
"backup_label": null,
"begin_offset": 40,
"begin_time": "2024-03-13T10:14:26.127719-03:00",
"begin_wal": "0001002D0049",
"begin_xlog": "2D/4928",
"compression": null,
"config_file": "/etc/postgresql/14/main/postgresql.conf",
"copy_stats": {
"analysis_time": 0.801669,
"analysis_time_per_item": {
"pgdata": 0.801669
},
"copy_time": 111.603679,
"copy_time_per_item": {
"config_file": 0.189547,
"hba_file": 0.190319,
"ident_file": 0.188415,
"pg_control": 0.185261,
"pgdata": 110.845212
},
"number_of_workers": 1,
"serialized_copy_time": 111.532835,
"serialized_copy_time_per_item": {
"config_file": 0.189547,
"hba_file": 0.190319,
"ident_file": 0.188415,
"pg_control": 0.185261,
"pgdata": 110.779293
},
"total_time": 112.474005
},
"deduplicated_size": 14030989187,
"end_offset": 1954448,
"end_time":