¿Debo preocuparme por la inyección de SQL para aplicaciones web internas?

Existen protecciones para abordar riesgo : las protecciones tienen un costo (tiempo / esfuerzo para codificar, en su caso) y esos costos deben compararse con los beneficios / costos de su implementación. Si el costo del riesgo realizado es menor que el costo de implementar protecciones, entonces no tiene sentido implementar protecciones.

Respuesta corta: ¡Sí! Implemente las mejores prácticas de seguridad en cualquier aplicación que almacene datos confidenciales, o que pueda acceder a otros servidores con datos confidenciales, independientemente de que sean públicos o no.

Explicación

Es una práctica demasiado común que las empresas inviertan solo en asegurar su perímetro. Esto significa que el acceso desde e incluso a Internet es altamente restringido y seguro, pero dentro de la red interna la seguridad es mucho más laxa.

Los hackers lo saben. Por lo tanto, a menudo intentan ingresar a la red interna y luego realizar ataques para aumentar el alcance de su acceso a través de la red. Como primer paso en un ataque, los piratas informáticos a menudo han tenido éxito en el envío de malware "de cabeza de playa" (es decir, un malware que les permite conectarse a una máquina en una red interna para establecerse) a través de ataques de phishing, ataques web y otros medios.

Así es como terminan ocurriendo las brechas, por ejemplo, La violación del himno. Una vez dentro de su red interna, a los piratas informáticos les resultó fácil acceder a las bases de datos con una gran cantidad de datos privados, ya que estaban mal protegidos. La suposición de que "está en la red interna, es segura" demostró ser una gran locura en este caso.

Al final, debe determinar cuál cree que es el riesgo de que un tercero acceda a su red interna; y luego, cuán perjudicial será el compromiso de esos datos. Si le preocupa un poco, le recomiendo implementar la inyección de SQL y otras protecciones de exploits en su aplicación interna.

No permito fallas de inyección SQL en nuestras páginas web internas. Las razones que ofrezco son:

• Proteja sus sitios web de personas maliciosas.
• No existe un sitio web interno. Cuando un usuario del sitio web interno tiene un navegador que también se usa para sitios web externos, no puede decir que el sitio web interno está segmentado desde Internet externo. Mi sitio interno confía en mi navegador y si mi navegador se ve comprometido por los scripts de sitios cruzados, el malware, el clickjacking, la falsificación de solicitudes entre sitios, una extensión defectuosa, un exploit de java, un exploit flash o cualquier otro ataque web común, entonces el atacante Puedo usar mi navegador para atacar sitios internos.
• Las fallas de inyección SQL en un objetivo de bajo valor pueden dar un punto de apoyo en atacar a un objetivo de alto valor.
• Protegerse de la inyección de SQL, especialmente si lo está haciendo mientras desarrolla sus aplicaciones, es una práctica de bajo costo con altas recompensas.