2012-03-07 26 views
12

¿Existen vulnerabilidades de seguridad conocidas con el deserializador JSON de Django? Con respecto a los protocolos de deserialización de Python, el consenso general parece ser que son completamente inseguros, así que evite analizar datos que no sean de confianza.Django JSON Deserialización Seguridad

Sin embargo, estoy considerando una aplicación web distribuida donde diferentes servidores intercambian registros modelo, formateados como JSON. Los registros en sí mismos no contienen datos confidenciales, pero me preocupa la posibilidad de que un servidor pirateado vulnere otro servidor al enviar JSON con formato malicioso. es posible?

Normalmente veo el serializador JSON de Django en entornos públicos, así que espero que esté endurecido contra este tipo de cosas, pero no he podido encontrar ninguna documentación que aborde los problemas de seguridad.

+0

¿Está habilitando la protección CSRF? Eso debería recorrer un largo camino para garantizar la seguridad. –

+0

¿Qué es "json con formato malicioso"? – Marcin

+1

@Marcin, JSON formateado para explotar alguna vulnerabilidad en el analizador, permitiendo la ejecución de instrucciones arbitrarias en el servidor. – Cerin

Respuesta

3

Tengo problemas para encontrar lo que crees que podría ser inseguro (o seguro) sobre JSON.

JSON es un formato de intercambio de datos basado en texto. No tiene ninguna seguridad incorporada. Django viene con algunas funciones para serializar y deserializar querysets a JSON. Pero estos no pueden ser "maliciosos" o "inseguros", solo son datos.

Algunos protocolos de serialización, por ejemplo, decapado, pueden ser inseguros porque pueden contener código, por lo que podrían deserializarse para ejecutar algo que dañe el sistema. Los modelos serializados no tienen ese problema, porque no contienen código.

Por supuesto, si usaba JSON para (por ejemplo) pasar una lista de ID de modelos para eliminar, existe la posibilidad de que un usuario malintencionado incluya toda una carga de ID que no desea eliminar. Pero una vez más, esto no es culpa de JSON: depende de usted asegurarse de que su lógica comercial determine correctamente qué elementos puede eliminar o modificar un usuario.

+8

Pero si el decodificador está defectuoso, entonces [incluso] (http://www.securityfocus.com/bid/17365) [data] (http://technet.microsoft.com/en-us/security/bulletin/ms04- 028) [puede ser] (http://technet.microsoft.com/en-us/security/bulletin/ms04-025) [malicioso] (http://www.securityfocus.com/bid/51292). –

+0

@Ignacio, Exactamente. Muchas aplicaciones que solo leen datos (por ejemplo, visores de imágenes, reproductores de música, etc.) ocasionalmente han tenido este tipo de vulnerabilidad. No quiero asumir automáticamente que Django está exento. – Cerin

3

De forma predeterminada, cuando se utiliza simplejson, que es el deserializador predeterminado utilizado por Django, los tipos de objetos que se pueden convertir de JSON en un objeto de Python son limitados. La única forma en que este no es el caso es si está realizando algún tipo de descodificación especializada utilizando los argumentos opcionales para los métodos loads() o load() o su propio objeto JSONDecoder.

Por lo tanto, siempre que use la decodificación predeterminada, estará bastante seguro. Pero, si realmente está preocupado, debería estar validando los datos JSON cargados ANTES de hacer algo con ellos.

+0

Bien, este es un consejo general muy bueno: "valide el JSON cargado", ¿con qué lo valido? ¿Expresiones regulares? Comprueba si el tamaño es menor que X Pickle no es seguro por diseño, ya que puede llamar a constructores de objetos arbitrarios, y JSON es bastante pasivo. Sin embargo, la historia conoce casos como este: http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/ (esto fue en realidad por el uso de un analizador demasiado general: no específico de JSON). No podemos estar completamente seguros sin una gran confusión como un analizador sintáctico. –

Cuestiones relacionadas