¿Alguna vulnerabilidad de seguridad al usar nombres de archivos generados desde la base de datos?

Question

¿Alguna vulnerabilidad de seguridad al usar nombres de archivos generados desde la base de datos?

#1 de Anders (4 votos)

3

Bien, por ejemplo, supongamos que tiene las configuraciones almacenadas en una base de datos donde el usuario selecciona el idioma del sitio.

Por ejemplo, diga que el idioma que eligieron era inglés y ahora tiene una configuración de en .

Luego, dentro de su lenguaje de scripting, como PHP , genera la ruta al archivo y lo incluye como de costumbre, como:

<script type="text/javascript" src="<?=$home_url?>/languages/<?=$lang?>.js"></script>

Sé que este valor debería ser seguro y realmente si algún usuario malintencionado de alguna manera ha obtenido acceso a la base de datos, entonces es probable que tengamos más problemas de qué preocuparnos, pero creo que es posible que haya un error de seguridad en algún lugar. Es posible poder corromper el valor de este campo e insertar algunos datos inesperados y maliciosos.

¿Aunque supongo que no podrían hacer nada demasiado desagradable, ya que la inclusión de <?=$home_url?> debería evitar que alguien incluya archivos desde un servidor remoto?

web-application attacks php directory-traversal

pregunta Brett 21.11.2016 - 20:06

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application attacks php directory-traversal

Sistema de cápsula de tiempo digital Identificar inundaciones sospechosas de SMS (¿explotar el teléfono?) [cerrado]

score 4 · Accepted Answer

Aunque solo estoy de acuerdo con usted en que un atacante que tiene acceso a la base de datos no valga la pena protegerse, todavía diría que esto no es un gran problema por un par de razones:

Dado que la inclusión es del lado del cliente y no del lado del servidor, no se arriesga a exponer ningún archivo confidencial que aún no esté expuesto. Si hubiera sido un PHP include() , tendría mayores riesgos, ya que puede alcanzar archivos que no se pueden alcanzar a través de HTTP.
Probablemente solo se pueden incluir los archivos en su dominio (pero el uso de /../ podría permitir que un atacante pase por otros directorios). Pero si tiene una vulnerabilidad de redireccionamiento abierta, podría utilizarse para incluir archivos de otros dominios. Eso sería peligroso.
Tal como lo entiendo, el usuario solo puede configurar su propio idioma. Entonces, incluso si esto fuera explotable, sería difícil "entregar" el exploit a otros usuarios.

Pero aún así, no hay razón para tomar riesgos innecesarios, incluso si son pequeños. Esto se puede defender fácilmente contra:

Valide los datos en la capa de aplicación, para que el usuario no pueda configurar un idioma que no esté en su lista de idiomas. Por lo tanto, si intentan configurar ../evil_javascript.js , fallará.
Asegúrese de que solo los códigos de país puedan almacenarse en esa columna de la base de datos, por ejemplo, mediante el uso de una clave externa en una tabla languages o tal vez una restricción de verificación. De esta manera, usted sabe que un usuario no puede colarse en ningún valor extraño, incluso si la validación en la capa de aplicación debería fallar de alguna manera.
Luego valide los datos tal como salen de su base de datos. Podría hacer una comprobación como esta (pero quizás con un mejor manejo de errores):
```
if(!in_array($lang, $language_list)) die("Unknown language!");
```
O simplemente hacer esto sacaría los dientes de cualquier ataque:
```
<script src="<?=$home_url?>/languages/<?=substr($lang, 0, 2)?>.js">
```

Esto puede parecer un poco execivo para una cosa de bajo riesgo. Pero al menos el primer y segundo punto son buenas prácticas de todos modos, incluso si no tiene en cuenta la seguridad.