¿Es seguro manejar datos confiables de una manera insegura?

El significado de la confianza

El significado de trusted es extraño en seguridad informática. Si se confía en algo, entonces, por definición, no puede ser perjudicial de ninguna manera. Lo que probablemente está preguntando es si los datos que cree deben ser considerados de confianza o no. Responder esto dependerá en gran medida de su situación particular. Específicamente, lo que importa no es si te "piratearías" o no, sino si hay algo que un atacante puede obtener al comprometer el proceso que procesa los datos de forma insegura.

Una forma de verlo es si sería seguro si su archivo de configuración tuviera una opción exec=some_command que ejecutaría automáticamente el comando en el inicio de la aplicación (lo que no es particularmente raro). Si fuera seguro, entonces no hay una razón de seguridad inmediata para manejar la entrada de forma segura.

Lee, escribe

Hay un modelo de seguridad llamado Biba Integrity Model . Se caracteriza por la frase leer, escribir . Esto significa que un nivel de integridad más bajo (privilegio más bajo) no debería poder modificar los datos que tienen un nivel de integridad más alto. En otras palabras, puede leer más datos con privilegios, pero solo puede escribir en datos que tengan menos privilegios de los que ya tiene. Este modelo de integridad está diseñado específicamente para evitar que un proceso privilegiado confíe en los datos que un proceso menos privilegiado pueda modificar. A través de esto, puede ver que el modelo permite que un usuario determinado modifique los archivos de configuración de las aplicaciones ejecutadas por el mismo usuario, pero no permitiría que un usuario inferior modifique los archivos operados por un usuario más privilegiado. Si los datos se consideran de confianza , están exentos de restricciones. De acuerdo con este modelo de integridad, ¿sus datos son de confianza? ¿Existe la posibilidad de que cualquier escritura no deseada?

Hay tres propiedades regidas por el modelo Biba Integrity. Tomado de Wikipedia:

1. La propiedad de integridad simple establece que un sujeto con un nivel de integridad determinado no debe leer datos con un nivel de integridad inferior (lectura).

2. La propiedad de integridad * (estrella) establece que un sujeto con un nivel de integridad determinado no debe escribir en datos con un nivel de integridad más alto (escribir).

3. La propiedad de invocación establece que un proceso desde abajo no puede solicitar un acceso más alto; solo con sujetos de un nivel igual o inferior.

En otras palabras, ¿el programa que analiza sus datos tiene más privilegios de los que debería tener un programa para modificar los datos "confiables"? Si no tiene más privilegios, un atacante no puede modificar los datos para elevar sus privilegios. Lo más que pueden hacer es obtener los privilegios que ya tienen. Esta es la razón por la que /etc/passwd no es propiedad de su usuario, ¡pero las configuraciones de su reproductor multimedia sí lo son!

Advertencias

Hay algunas otras cosas en las que debería pensar antes de declarar que esta es una buena idea. Debe preguntarse si, filosóficamente y en la práctica, escribir código inseguro a sabiendas es una buena idea. Si no es excesivamente difícil procesarlo de manera segura, debe preguntarse algunas cosas.

• ¿Recordarás, en el futuro, que tu base de código es insegura, o podrías reusarla?
• ¿Alguien más usará tu código? ¿Tendrán el mismo modelo de amenaza que tú?
• ¿Alguna vez ejecutará la aplicación con privilegios, con archivos de configuración que se puedan escribir con privilegios más bajos?
• ¿Podrían los datos manejados de manera insegura resultar en errores confusos si se corrompe accidentalmente?
• ¿Te sientes cómodo acostumbrándote a escribir código inseguro? ¿Es un buen hábito para entrar?

Todo depende de lo que usted llama seguro y de lo que llama información segura. Si una aplicación serializa algunos datos, y luego esta aplicación u otra la deserializa mientras no se haya atemperado mientras tanto, no hay ningún problema de seguridad especial. Un ejemplo de caso de uso es la serialización de sesiones en aplicaciones web agrupadas. Si los datos se han atenuado aquí, realmente tiene problemas más serios que la simple deserialización ¹ .

Ahora imagine que almacena datos serializados durante bastante tiempo en una computadora personal e intente deserializarlos después de un tiempo. Mientras tanto, pueden haber ocurrido muchas cosas, y malwares o incidentes físicos podrían haber cambiado el archivo sin que el usuario lo notara. O la aplicación podría haber cambiado a un formato de serialización diferente. En ese caso, es probable que ocurran cosas malas en el momento de la deserialización.

¹ de todos modos, cuando lee datos de entrada que (una sola aplicación) no ha producido de inmediato, siempre debe estar preparado para un error y asegurarse de que su código no pueda romper todo lo que lo rodea. Lanzar una excepción generalmente está bien, pero escribir basura en una base de datos no.