¿Piensas activamente en la seguridad al codificar?

Cuando está codificando, ¿piensa activamente en que su código podría explotarse de una manera que originalmente no estaba destinada a hacer y, por lo tanto, obtener acceso a información protegida, ejecutar comandos u otra cosa que no desea que hagan sus usuarios?

Mas o menos. Descargo de responsabilidad: soy un tipo de seguridad;)

Entonces, mi forma de trabajar es que tengo mi modelo de amenaza, que describe qué tipo de ataques por qué tipo de atacantes son probables. Eso ayuda a resolver los requisitos de seguridad. Cuando realmente estoy codificando, hago las prácticas habituales de "codificación segura", como tener cuidado de que las variables del cursor siempre estén dentro de los límites, la entrada contaminada se desinfecta y se manejan las condiciones de error. Luego vuelvo a mi modelo de amenaza para ver qué módulos tienen más probabilidades de ser atacados por los atacantes; esos obtienen alguna revisión extra.

Utilizo prácticas estándar de la industria, como el uso de parámetros SQL. Utilizo plataformas "seguras", como .NET Framework, y aprovecho características de seguridad como tokens antifalsificación en ASP.NET MVC. No escribo mis propios algoritmos de cifrado, pero entiendo qué proporcionan esos cifrados en cuanto a beneficios de seguridad, y cuándo necesito usarlos para obtener esos beneficios de seguridad.

En resumen, uso las mejores prácticas, pero no desarrollo mis propias herramientas de seguridad. No soy un experto en seguridad en ese sentido; Confío en otros expertos en seguridad, que presumiblemente ya han pensado profundamente en estos problemas, y tienen una comprensión clara de los riesgos y beneficios.

Mi enfoque fundamental para la seguridad, más allá del simple uso de herramientas de seguridad, es eliminar todas las posibles entradas al sistema, excepto las que estoy esperando. Si tengo un campo de número de seguro social, los únicos caracteres que deberían aparecer son dígitos numéricos y guiones, en un patrón específico.

Valido la entrada del usuario tanto en el cliente como en el servidor.

Absolutamente.

La seguridad lo es todo. Y con el software numérico, eso va dos veces.
Justo el otro día, un usuario logró encontrar y explotar el error en uno de mis viejos programas. El daño fue irreparable. Vea abajo:

Solía ​​ser redondo.

No, porque no trabajo en un dominio problemático donde la seguridad es relevante (SW de visualización masiva de datos). Me hacer un montón de afirma en mi código (la comprobación de índices, la comprobación de la consistencia, etc.), no debido a preocupaciones de seguridad, sino porque me gusta código erróneo Early Crash y Crash visiblemente.

Absolutamente. Pienso en las vulnerabilidades de inyección, y también en cómo funcionará la lógica de mi negocio en un entorno de escritorio frente a un entorno web, y cómo se implementa la seguridad en ambos tipos de entornos.

No soy un experto en seguridad, pero cuando estoy codificando aplicaciones web siempre asumo que la entrada del usuario puede contener todo tipo de rarezas y siempre se debe escapar por completo y cosas así. Además, soy cuidadoso al hacer que Ajax devuelva las llamadas al servidor para verificar que el usuario haya iniciado sesión (si es que es para ese evento en particular) y que tiene los permisos para hacer lo que sea que esté tratando de hacer.

La base de código tiene un conjunto de filtros para entradas. Nunca verifico PHP $_GETo $_POSTmatrices directamente. En su lugar, les consulta mediante una función Request::get('parameter', 'filter')con filtros tales como int, texty algunos otros. (Y Request::post()para entradas POST, por supuesto).

Si. Cuando trabajé en un juego multijugador, todos estaban paranoicos de las hazañas y las formas de hacer trampa. Hacer trampa puede destruir un juego por completo, sin mencionar los modelos de negocios relacionados con la venta de cosas en el juego. Por lo tanto, las preocupaciones de seguridad y las medidas contra la manipulación eran muy importantes en la agenda. Me gusto mucho. He trabajado en otros proyectos antes donde tenías que sentirte culpable por trabajar más tiempo en el código solo para asegurarte de que fuera seguro.

Si. La seguridad es importante y no debe ser una ocurrencia tardía; Agregar seguridad después del hecho es generalmente más difícil que diseñarlo en la aplicación en primer lugar, y si lo agrega más tarde probablemente perderá algunas cosas (o simplemente no se molestará en agregarlo).

Comprenda los principios generales de seguridad (integridad, autenticación, autoridad) y luego lea algunos libros sobre cómo las personas han estado subvirtiendo estos pilares de seguridad durante milenios y estará a mitad de camino.

Luego lea algunos buenos libros sobre estrategias de diseño y prueba y aprenderá cómo diseñar la capacidad de prueba en su arquitectura.

Ahora llegamos al punto en que pienso en la seguridad. Estoy pensando en cómo puedo validar la fuente de datos, ¿importa si se manipulan los datos, quién es la fuente de datos, qué tan seguro estoy de eso? ¿Cómo podría haber sido alterado, etc ...

Esto afecta el diseño. Los archivos de configuración pueden tener secciones clave encriptadas, o campos particulares pueden estar en texto claro con un campo de firma asociado. Las cosas se vuelven más complejas con los servicios orientados a Internet, ya que debería esperar un mayor nivel de hostilidad allí.

Luego, en las pruebas, ¿cómo se prueba todo esto? ¿Cuáles son sus entradas de datos máximas, qué sucede si empuja el software más allá de esos límites, cómo lo maneja? ¿En qué confía? ¿Cómo puedes fingir esa confianza?

Si.

He tratado con suficientes hackers en el pasado para saber que constantemente están tratando de comprometer cualquier sitio grande, y hay suficientes bots por ahí que incluso los sitios pequeños no son seguros.

Trato de pensar como un hacker todo el tiempo ahora, hasta el punto de que a veces me preocupo de mis compañeros de trabajo con comentarios casuales sobre cómo se pueden jugar los sistemas que damos por sentado todos los días.

Debe ser algo que cualquier desarrollador construya en el proceso desde cero en mayor o menor grado, dependiendo de la aplicación, etc. Desafortunadamente, como los desarrolladores no tienden a cotizar por seguridad, los compradores no tienden a pensar en ello ( Lo sé, esto es un poco extraño, porque si los compradores quieren la cotización más barata, tal vez no incluya seguridad)

Como desarrollador, puede obtener una ventaja definitiva si es experto en esta área: estoy pensando específicamente en bancos y servicios financieros, pero otras industrias también son aplicables. En la actualidad, pueden presupuestar entre 70 y 100 mil en capacitación para que un nuevo graduado se ponga al día sobre los procesos, la seguridad y otros detalles específicos de esa organización. Si puedes ahorrarles 30k de eso, ¡es un buen CV plus!

En el Reino Unido, el Instituto de Profesionales de Seguridad de la Información , y en Escocia, el Centro de Excelencia en Seguridad y Ciberdelincuencia están trabajando en estrecha colaboración con las universidades para ayudar a revisar los materiales del curso, ofrecer conferencias sobre las implicaciones del mundo real de la mala codificación y facilitar las colocaciones de verano (p. Ej. desarrolladores de software ubicados en divisiones de fraude en la aplicación de la ley.) La mayoría de las organizaciones de apoyo lo hacen de forma gratuita, ya que tiene el potencial de ahorrarles una gran cantidad de dinero, me parece un valor.

(descargo de responsabilidad - He sido el tipo de seguridad para varias organizaciones globales)