¿Cómo se llama cuando le da una entrada a los hackers?

10

¿Hay un nombre para un sistema que está diseñado para ser pirateado?

(Alternativamente, puede haber un nombre diferente para un sistema que está diseñado para parecer como si estuviera pirateado, pero en realidad solo está emulando?)

¿Y hay un nombre para un ejecutable que parece interesante para un pirata informático (por ejemplo, decryptor.executable junto a temporary-backup.sql.encrypted ) pero está realmente / también diseñado para recopilar y transmitir información sobre el usuario que lo ejecuta?

    
pregunta George Bailey 29.12.2011 - 20:05
fuente

1 respuesta

20

Creo que el término que estás buscando es " honeypot ".

    
respondido por el pdubs 29.12.2011 - 20:14
fuente

Lea otras preguntas en las etiquetas

¿Hay alguna forma de probar que VPN no recopila datos? ___ inyección de qstnhdr ___ MongoDB Nosql en código python ______ qstntxt ___

Aquí está el fragmento de código para acceder a MongoDB.

%pre%

Me dijeron que este código es vulnerable a la inyección NoSQL ya que la variable de condición no está correctamente desinfectada. Pero no pude entender cómo funciona la inyección con python. ¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas o algunas referencias a un ataque de inyección relacionado? Por cierto, también hice algunas investigaciones por mi cuenta, pero solo encontré la inyección basada en Javascript y traté de no funcionar en este caso. Gracias.

    
______ answer83234 ___

El operador %code% en MongoDB es una característica que es mejor evitar. Su rendimiento es abismal, y no solo porque no se beneficia de los índices. Casi todos los casos de uso comunes se pueden resolver de manera mucho más eficiente con una consulta o agregación de búsqueda común, especialmente una tan trivial como esta. Pero esto es un intercambio de seguridad de pila, no un flujo de pila, así que concentrémonos en las implicaciones de seguridad.

La declaración %code% pasa un fragmento de código javascript a la base de datos que la base de datos ejecutará una vez para cada documento de la colección. Afortunadamente, este script no tiene acceso al objeto %code% ni a otras funciones de shell peligrosas y funciona en copias de los documentos, por lo que el atacante al menos no puede cambiar el contenido de la base de datos como ocurre con muchas inyecciones de SQL. Pero, por ejemplo, es vulnerable a los ataques donde el atacante quiere devolver otros resultados de los previstos.

Vamos a hacer un ejemplo. Digamos que tenemos un blog. Nuestro blog tiene muchos artículos que se pueden leer en público, pero también tenemos algunos artículos privados que son para nuestro uso interno y que no deben publicarse. Así que tenemos un campo %code% en nuestros documentos que puede ser %code% o %code% dependiendo de si nuestros visitantes deben ver el artículo o no. Nuestra consulta de MongoDB para obtener una lista de todos los artículos en una categoría determinada para mostrarla al visitante del sitio web es así:

%pre%

Eso debería asegurarnos de que nadie vea nuestros artículos ocultos. O lo hace? Cuando el usuario controla la variable %code% , puede establecerla en esta cadena:

%pre%

El fragmento de código Javascript resultante que se envía a la base de datos es el siguiente:

%pre%

Cuando tiene un fragmento de código javascript con varios comandos separados por %code% , se ejecutarán como una función y se necesita una declaración %code% para determinar qué valor se devolverá al llamante. Esta función siempre devolverá verdadero. Eso significa que el usuario también verá todos los artículos de nuestra colección, incluidos aquellos que se supone que están ocultos.

    
______ answer83261 ___
  

¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas?

Para su pieza concreta de código, esto debería funcionar:

%pre%

%code% se usa para escapar de la cadena y la instrucción, luego sigue el ataque real %code% (ataque DOS), y luego el %code% aún en pie se transforma en una sintaxis válida a través de %code% .

Hasta la versión 2.4 de MongoDB, el objeto %code% era realmente global, por lo que podría cambiar los datos en la base de datos, e incluso recuperar datos usando inyección ciega .

Como ya no es posible, lo máximo que puede hacer un atacante es DOS y la evasión del filtro descrita por Philipp (lo que no sería un problema para su ejemplo, pero puede ser un problema en general).

Eso todavía es bastante malo, por lo que deberías defenderte escapando %code% , %code% y %code% .

    
___