¿Qué puede salir mal al componer un nombre de método a partir de una cadena?

7

Tengo un fragmento de código que compone el nombre del método para llamar desde un parámetro de cadena. No creo que sea algo bueno, pero no estoy seguro de qué puede salir mal con esto.

Aquí hay un fragmento simplificado de ese código:

switchToFilter = function(filter){
    var filterMethod = 'switchTo' + filter;
    myObject[filterMethod]();
}
    
pregunta Mohsen 18.12.2013 - 20:12

6 respuestas

12

En el tiempo de ejecución, lo peor que podría pasar probablemente es que el método no existe, por lo que obtienes algún tipo de error en el tiempo de ejecución que dice ERROR: method: 'switchToFoo' could not be found in context blah blah blah...

No estoy seguro de si este tipo de código podría ser vulnerable a los ataques de inyección. ¿De dónde viene el valor para filter ?

Un problema mayor podría ser que cualquier herramienta de desarrollo que esté usando no podrá trabajar con esto. Por ejemplo, si desea que su IDE busque todos los lugares donde se llama a switchToFoo , no será posible encontrar los llamados por el fragmento que se muestra arriba. O si desea refactorizar switchToFoo a switchToFou , debe cambiar el nombre del método y luego cambiar el código que pasa el valor para filter . Usted sabrá todo acerca de esto, pero este tipo de cosas generalmente hace tropezar a los desarrolladores que son nuevos en el proyecto.

    
respondido por el FrustratedWithFormsDesigner 18.12.2013 - 20:19
19
  

¿Qué puede salir mal al componer un nombre de método a partir de una cadena?

Si myObject[filterMethod]() no existe, podría bloquear su aplicación.

Si su aplicación forma parte de los controles de seguridad para el control de misiles nucleares, podría estar deshabilitando los controles de seguridad críticos.

Si otro software para los controles no tiene en cuenta este bloqueo, podría permitir que cualquiera dispare misiles.

Si alguien está teniendo un mal día, pueden decidir intentar lanzar los misiles y sorprenderse al lanzarlos.

Si lanzan los misiles, podrías comenzar una guerra nuclear.

Si comienza una guerra nuclear, podría terminar con la civilización tal como la conocemos.

PARA EL AMOR DE LOS NIÑOS COMPRUEBE LAS COSAS QUE EXISTEN ANTES DE ACCEDER A ELLOS

    
respondido por el enderland 18.12.2013 - 20:25
4

El mayor riesgo es tratar de acceder a algo que no existe dentro de la estructura de la matriz. En el peor de los casos, eso bloqueará tu aplicación. En el mejor de los casos, no se realizaría ninguna operación percibida.

Si envolvías esa lógica con algunos controles de seguridad para asegurarte de que no estabas accediendo a algo que no estaba allí, sería un poco más sólido. También podría considerar agregar el registro para las solicitudes erróneas que aún logran ingresar. Con la información de registro, podría solucionar los problemas después del hecho.

    
respondido por el GlenH7 18.12.2013 - 20:20
1

Es una forma de reflexión, que tiene su uso en aplicaciones construidas dinámicamente (como un constructor de GUI, por ejemplo) o complementos, pero debe ser un último recurso fuera de esos contextos.

Además de las excelentes razones indicadas en otras respuestas, es una señal de que su jerarquía de clases probablemente necesita refactorización. Al hacerlo, lo más probable es que sea mucho más fácil razonar acerca de todo su código. Para un ejemplo refactorizado:

switchToFilter = function(filterName){
    var filter = filters[filterName];
    filter.switch();
}

Esto le permite usar la herencia para evitar la duplicación en las funciones del conmutador, y lo más probable es que tenga el efecto secundario de proporcionar un lugar conveniente para colocar otro comportamiento específico del filtro.

    
respondido por el Karl Bielefeldt 18.12.2013 - 22:01
0
  • Si filter proviene de una fuente externa como un usuario, tiene una fuente potencial de errores no intencionados, posiblemente un problema de seguridad según el contenido de myobject .
  • La búsqueda se realiza en tiempo de ejecución, por lo que no obtiene los beneficios típicos de la verificación de tipos (existencia, firma de llamada, firma de función, etc.)

Dicho esto, sí uso tablas de envío muy similares a las que tiene en su ejemplo. Son útiles en casos particulares. La clave es comprender cuáles son los costos (y los riesgos) y asegurarse de que no pesen más que los beneficios.

    
respondido por el dietbuddha 31.12.2013 - 12:17
-1

Si la cadena proviene de una fuente insegura (entrada del usuario, etc.) es absolutamente inaceptable. Usted voluntariamente agregó una vulnerabilidad de inyección de código a su código.

Puede escribir algún código que asignará una lista de nombres de funciones conocidas a funciones conocidas, donde se verificará que cada una de esas funciones puede llamarse sin efectos secundarios negativos.

    
respondido por el gnasher729 09.07.2015 - 16:16

Lea otras preguntas en las etiquetas