¿Debo agregar protecciones donde no entiendo cómo un pirata informático puede romper el sistema?

6

Digamos que hay una aplicación AJAX donde el usuario puede enviar artículos, comprarlos.

Y había un código

IF ($_POST[items] > 20) {
   echo 'error';
}
else {
   do_buy($_POST[items]);
   echo 'success'
}

Aquí, se comprueba si items no es más de 20. En el lado del cliente, no debería ser posible elegir más de 20 elementos.

El sistema funcionaría sin problemas, incluso si se enviaran 21 (o más) elementos (el usuario simplemente pagaría por cada elemento). Si bien me doy cuenta de que debe querer gritar no confíe en el cliente , ¿hay algún daño al hacerlo si no hay consecuencias, como ocurre aquí?

Uno podría argumentar que la sobrecarga del carrito podría causar inestabilidad en el sistema, pero parece que el peor de los casos sería que el tiempo de espera de algunos scripts. Si se deshabilitan los errores, el usuario simplemente no recibirá ninguna respuesta.

En general: ¿Tiene sentido codificar las protecciones para un ataque que viola una invariante de su sistema?

Actualizar:

$ _POST ['items'] Quise decir que es una matriz, no un entero. Y cada elemento tiene propiedades propias: identificación y cantidad, que se verifican más adelante antes de completar la operación de compra.

Sobre la inyección de SQL: por lo general uso frameworks, y ellos se encargan de la protección de la inyección.

Actualizar

Una razón más por la que pregunto esto es que quiero tanto código limpio como sea posible y también cuando alguien lo lea, pensará por qué demonios es necesario, este programador no sabe qué está programando y por qué. Entonces, para todo el código, quiero tener una razón clara de por qué existe ese fragmento de código y, si no está en el comentario, entonces, al menos yo mismo, tendría un claro entendimiento de por qué hago esta verificación para poder explicar si otro programador pregunta.

    
pregunta Darius.V 13.07.2014 - 09:51
fuente

5 respuestas

5

Sí, debe agregar protecciones, pero deben ser apropiadas para la situación.

Todas las entradas del usuario deben ser validadas. El principio fundamental es que usted no define qué es una entrada "mala", define qué es una entrada "buena" y rechaza todo lo demás. Para tomar tu ejemplo, has definido "elementos > 20" como malos. Pero, ¿qué pasa si "artículos" es -1? ¿Y si es la cantidad );DROP TABLE Orders;-- ?

La técnica básica es que observa cada campo de entrada del usuario y define cómo se ve un valor "bueno", teniendo en cuenta tanto las capacidades de su software como las reglas de su negocio. Por ejemplo, "artículos" puede ser "un número entero, mayor que 0, menor que 20 e inferior o igual a la cantidad en stock": esto rechaza pedidos demasiado grandes, pedidos demasiado pequeños e insumos exóticos como Inyección SQL, sin tener que preocuparse por lo que un atacante podría estar tratando de hacer o cómo podría reaccionar su software.

Esto debe hacerse en el lado del servidor. La validación del lado del cliente está ahí para ayudar al usuario honesto; un usuario deshonesto solo puede ser detenido del lado del servidor, ya que controla al cliente.

Para usar la analogía de su casa, todas las entradas del usuario son parte de la puerta.

    
respondido por el Mark 13.07.2014 - 10:28
fuente
1

No siempre se puede saber cómo las cosas realmente pueden ir mal. En su ejemplo actual, el atacante puede enviar un valor muy grande que cause un desbordamiento aritmético o de pila o una excepción no controlada que provoque que el servidor se apague y provoque un problema de disponibilidad.

Así que siempre haga las comprobaciones, siempre considere lo peor que puede pasar y piense en el atacante como alguien que es capaz de hacer "cualquier cosa". Siempre haga listas blancas, no listas negras. En la lista, considere los métodos de ataque estándar (XSS, CSRF, inyección, etc.) y verifique los rangos.

Selle las puertas y ventanas lo más que pueda y siempre revise su diseño, su código Y su entorno.

    
respondido por el Alireza 13.07.2014 - 09:33
fuente
1

Respuesta corta: no, ¡y toma un curso intensivo de seguridad con urgencia si estás haciendo un sitio web de ventas!

No debe agregar restricciones arbitrarias, controles y "protecciones" solo porque no sabe lo que está pasando. Si lo hace, es más probable que agregue problemas y deje abiertas las vulnerabilidades de seguridad que cualquier otra cosa. Obviamente, la razón por la que hay profesionales de la seguridad es porque están capacitados para identificar las protecciones necesarias.

Comience por definir los activos en su sistema , tanto el suyo como su clientela'. Necesitas saber lo que es valioso porque para eso vendrán los hackers. Incluye datos personales, datos de valor financiero (información de cuentas bancarias, etc.), los productos que vende, las computadoras de sus clientes (que se pueden usar en una red de bots en el caso de, por ejemplo, ataques de scripts entre sitios y también su propio servidor, base de datos y servidor web.

Una vez que sepa qué hay que proteger, debe definir qué debe sucederle para que su sistema funcione correctamente. Esencialmente, debe hacer una lista de lo que permite que sus clientes hagan en su sitio web. Por ejemplo, este límite arbitrario de 20 elementos es completamente injustificado .

El segundo paso será entender quiénes podrían ser tus adversarios y qué pueden hacer . Sea creativo pero sea realista. Es menos probable que le interese a la NSA que un hacker solitario con intereses financieros para un sitio web de ventas. Este proceso se llama modelado de amenazas . Usted debe:

  • define tus adversarios para cada activo
  • defina sus capacidades (lo que requiere mucho conocimiento de seguridad)
  • defina las amenazas a sus activos (¿qué pueden hacer esas capacidades para que lo haga un atacante?

Ahora que sabes lo que te puede pasar, debes definir las Propiedades de seguridad que debe mantener sus activos , y luego debe elegir los mecanismos que garantizan esas propiedades. Esos mecanismos, a su vez, se convierten en activos críticos de su sistema que también deben protegerse. Esto se conoce como Trusted Computing Base .

Cuando estés allí, puedes comenzar a pensar en cambiarte a beta. Tendrá que evaluar su seguridad, a través de las pruebas de penetración que generalmente realiza una empresa externa. Pero eso ya debería mantenerte ocupado;)

Editar: dedique un tiempo a leer los programas de software más comunes que convertir en vulnerabilidades . Permitir que los usuarios compren más de 20 artículos no es uno de ellos.

    
respondido por el Steve DL 13.07.2014 - 17:36
fuente
1

Si algún malware en el lado del usuario hace que el cliente compre 2 millones de artículos en su sitio, y su sitio realiza la transacción sin generar ninguna alerta, entonces algunas personas, en particular el cliente estafado, pueden quejarse en voz alta y afirmar que su servidor es un poco laxo Se podría argumentar (¡en la corte!) Que usted sería culpable por no hacer algunos cheques "sensatos". Incluso puede haber algunas regulaciones aplicables que obligan a realizar algunas verificaciones del lado del servidor (al menos los bancos realizan comprobaciones de "actividad anormal" en las tarjetas de crédito y bloquean las transacciones que parecen particularmente extrañas).

En el caso general, agregar controles adicionales para situaciones anormales es una práctica de programación sensata. Usted sabe que el lado del cliente no debe permitir más de 20 elementos. Si algún error en la interfaz del lado del cliente le permite a un cliente poner 21 elementos, entonces debería solucionarse, y será más fácil si se le avisa lo antes posible, por ejemplo. con una verificación del lado del servidor.

(Sin embargo, tiene un lado oscuro: si agrega el cheque en el lado del servidor, luego decide aumentar el límite a 25, debe modificar el cliente y el servidor. Sin embargo, esto debería detectarse fácilmente durante las pruebas previas a la implementación, así que no se abstenga de agregar pruebas de cordura.)

    
respondido por el Thomas Pornin 13.07.2014 - 16:15
fuente
1

Dirigiendo solo la primera pregunta, que es esencialmente "¿Está bien codificar la validación del lado del cliente?".

Sí, es una buena experiencia de usuario, la respuesta inmediata es buena. La validación del lado del cliente no es realmente seguridad, sin embargo, es más una conveniencia. Su propósito es acelerar el proceso, poner el formulario en un estado que pase la validación.

Como probablemente sepa, la validación del lado del cliente siempre debe ser secundaria a la validación del lado del servidor. Si la validación del lado del cliente y del servidor no coincide, el servidor es, en última instancia, la fuente de la verdad. Si el servidor no lo valida, entonces realmente no se está validando.

De todos modos, sí, la validación del lado del cliente es perfectamente legítima y es una gran mejora en UX.

Y para las protecciones de inyección de SQL, parece que ya está tratando las entradas de los usuarios como materiales peligrosos allí y frotándolas con un marco probado y confiable, por lo que puede ir allí. Solo desconfíe de cualquier cosa derivada de la entrada del usuario, no solo al guardar / actualizar. Incluso otras variables / lógica pueden ser manipuladas por la entrada del usuario si tienen un conocimiento íntimo de su sistema.

    
respondido por el Andrew Hoffman 15.07.2014 - 16:21
fuente

Lea otras preguntas en las etiquetas