Migrar mi sistema a la web? (II parte)

Esta entrega es la continuación de ésta.
Cómo vulneraban la solución:

Manoseo de parámetros
Las aplicaciones web comunmente confian el paso de su información entre páginas a los parámetros URL o controles en formularios, para trasladar información del cliente.En nuestro caso estudiado (empresa x) individuos ajenos a la organización lograron obtener información manoseando los parámetros url de la aplicación web.

Cross-site scripting
La aplicación fue también vulnerable a los ataques de cross-site scripting.
Esto funciona así: Un individuo ajeno a la organización embebe un script en, digamos, un formulario de compras y luego publica estas páginas.
Una vez que algún usuario usa ese formulario, el código maliciosos se ejecuta,enviando las credenciales del usuario hacia el hacker. El usuario permanece ignorante de lo ocurrido, ya que la transacción de todos modos se realiza. El tema es que la inormación robada al usuario luego puede ser manipuladapara fines deshonestos.

Consumo de recursos del servidor
Esto ocurría por intentos de ataques de inyección SQL. Quiero decir que la aplicación estaba validada para no permitir comillas simples, etc... en el traspaso de información, pero cuando se simulaba varios intentos de inyección SQL al mismo tiempo, la CPU consumía recursos que pa' qué te cuento!!
Maestrazo, la validación estaba bien... pero en el servidor?? no seas pendejo pes'.

Aquí van algunos tips a tener en cuenta:

1.- Mientras el usuario ingresa datos en los campos de un formulario, valida el ingreso de caracteres prohibidos, como guiones, comillas simples, etc ... según sea el caso obviamente.
Por ejemplo, un campo numérico no debería permitir el ingreso de caracteres.
Esto es muy simple de hacer con un poco de javascript y, aunque no lo creas, puede evitarte muchos dolores de cabeza.

Esto tiene que ver con lo que hace un rato les comentaba,
2.- Aprueba o rechaza la información ingresada por el cliente "en el cliente".
Esto no sólo evita que consumas recursos del servidor sino que, si te das cuenta, ya es una previa validación de los datos ingresados y aquí el 50% de intentos de hackeo culmina por aburrimiento... a menos que te topes con un hacker infatigable.

3.- Los hackers pueden evadir las validaciones que hiciste "en el cliente", copiando y modificando un formulario antes de submitirlo al servidor.
Por lo tanto, chequea las entradas de los usuarios nuevamente "en el servidor".

4.- Tener específicos puntos en tu arquitectura donde la data se valida, por ejemplo un middleware o a través de una aplicación que haga de firewall.
De esta manera tendrás específicos lugares que ajustar cuando sea necesario.

Para terminar, asume que a la aplicación recién terminada no tiene seguridad y, testéala exhaustivamente.
Recuerda que un browser puede ser accedido desde cualquier parte, lo cual la convierte en la puerta de entrada para los hackers.

Se consciente de las vulnerabilidades de tu aplicación y procura mitigarlas cuanto antes, de lo contrario simplemente estarás manteniendo una bomba de tiempo.