2010-07-19 16 views
9

Estoy empezando a aprender todo sobre seguridad y programación segura.Dónde en Internet podemos aprender la Programación segura en c/C++

Siempre he oído hablar de cosas como la vulnerabilidad de desbordamiento de búfer.

Pero todavía no sé cómo se explotan esas vulnerabilidades. Y cómo podemos programar de forma segura para asegurarnos de que nuestro código sea sólido.

Cuando digo todo esto, mis lenguajes de programación de interés son c y C++.

  1. Estoy buscando tutoriales gratuitos, y recursos en internet donde puedo aprender cada ins-n-out de la programación segura.

  2. Consejos específicos de plataforma también son bienvenidos. Por ejemplo, sé que en la programación de Windows podemos usar funciones como "memmove_s" para tener código de seguridad. Pero, ¿cuáles son los equivalentes en Linux/Unix? ¿O es lo mismo allí?

  3. ¿Debería un programador de c/C++ preocuparse por las picaduras formateadas especialmente diseñadas (como la popular vulgaridad de las cadenas con formato PHP)?

Muchas preguntas aquí, pero idea general es que me refiero a aprender programación segura.

Gracias por cada ayuda.

+1

Bueno 0A0D, eso fue gracioso. También puedo buscar en Google, pero apreciaría algunos de sus consejos aprendidos personalmente en programación segura. Así es como ganamos conocimiento compartiéndolo. – bits

+8

@ 0A0D - Y la regla de seguridad número uno es ... no haga clic en los enlaces de tinyurl.com :) –

+1

¿Por qué solo busca _free_ resources? A menudo, la mejor información que se tiene se encuentra en los libros, que generalmente no son gratuitos. –

Respuesta

4

Voy a tirar un par por ahí y hacer de esta comunidad wiki:

  1. Nunca, nunca, nunca utilizar gets.

  2. No asuma que una cadena no tiene terminación a menos que realmente sepa que sí lo está.

  3. Nunca solo declare un gran buffer de tamaño fijo y simplemente suponga que será "lo suficientemente grande" para lo que está haciendo.

+0

¿También puede compartir qué está mal con el uso de "obtiene"? – bits

+5

@bits: Si no sabe qué está mal con 'gets()', le sugiero encarecidamente que obtenga uno de los libros de introducción que figuran en [The Definitive C++ Book Guide and List] (http: // stackoverflow. com/questions/388242/the-definitive-c-book-guide-and-list) y aprenda C++ antes de preocuparse por escribir programas con requisitos de seguridad críticos. –

+0

@James, he tenido y leído algunos de los libros mencionados allí. Por alguna razón, y sí, no sé qué hay de malo en "obtener" desde el punto de vista de la seguridad. Sería mejor si simplemente explicaras. – bits

3
  1. Afirmaciones, aserciones, aserciones. Si existe la posibilidad teórica de que algo no sea correcto, adelante y afirme que sí. Si algo no es exactamente lo que esperabas, quieres que tu programa muera de forma inmediata y espectacular. Asegúrate de que tus afirmaciones no se optimicen.

  2. Tenga mucho cuidado con los buffers. Hay algunas funciones (por ejemplo, get) que se escriben en un búfer sin saber qué tan grande es. No use estas funciones. Siempre verifique los tamaños de su búfer justo donde los necesita en lugar de confiar en los valores precalculados.

  3. Siempre verifique los códigos de retorno. Si no puede hacer nada significativo en un error (por ejemplo, malloc), entonces afirme el éxito, o mejor, escriba una función de envoltura que afirme el éxito para que no pueda devolver un valor de error y nunca use el original. Para ser extra-paranoico, haga que su compilador emita una advertencia si ignora implícitamente un valor de retorno.

  4. Trata cualquier dato que ingrese al programa como un posible ataque malicioso, porque lo es. Esto incluye archivos de configuración, así como la entrada del usuario.

  5. "La optimización prematura es la raíz de todo mal". Primero hazlo bien. Ni siquiera pienses en hacerlo más rápido a menos que a) tengas que hacerlo yb) hayas perfilado el código y sepas con precisión cuáles son tus cuellos de botella.

  6. Solicite a otra persona que compruebe su código.

Estos son solo algunos de los puntos de partida. Escribir código seguro es difícil.

+1

1. y 3 .: No use assert para verificaciones en tiempo de ejecución. Úselo para verificar la corrección del programa, p. si una función espera que un puntero no sea NULL, assert es perfecto para esto, porque es una condición previa para la función y es responsabilidad del programador cumplir con las condiciones previas. OTOH malloc return NULL es un error en tiempo de ejecución que puede ocurrir en cualquier momento sin su control, por lo que debe verificarse con un código normal. Si utiliza una envoltura siempre exitosa sin importar datos de usuario no guardados de todos modos, entonces si y salir es igual de bueno. – Secure

+0

Bueno, si ya está envolviendo malloc con un if/exit, también podría factorizar eso en una función. Si malloc falla en un sistema moderno, generalmente no hay mucho que pueda hacer para recuperarse, y no debe esperar hasta que haya un error para guardar los datos del usuario en primer lugar. –

+0

Ya estaba hablando de su "función de envoltura que afirma el éxito". ;) Lo que puedes hacer con un malloc defectuoso seguramente depende de tu estructura de manejo de errores y estrategia de recuperación, si es que hay alguno, por supuesto. ¿Qué tal si intentamos rescatar datos no guardados en un archivo temporal de recuperación de desastres? Si funciona, puede restaurarse en el siguiente inicio del programa. Si falla, no se dañará la información existente. Depende de la aplicación, sin dudas, y de la importancia que tengas de los datos del usuario. – Secure

2

La programación segura abarca las prácticas que reducen las posibilidades de uso indebido por parte de los mismos mantenedores de código.

Aquí está mi granito de arena: evite usar punteros donde pueda. En mi opinión, un puntero debería usarse solo cuando un valor NULL tiene un significado especial. Este principio se traslada a varios idiomas de codificación

  • vectores Uso STL en lugar de arrays
  • Uso pasar por referencia/pasar por valor al pasar tipos básicos a una función
  • Uso de paso a por -const-reference al pasar tipos definidos por el usuario a una función . Esto es tan eficiente como pasando un puntero.

La línea de fondo es que, si hay indicadores involucrados, hay una buena probabilidad de que alguien que eventualmente herede el código lo use indebidamente.

Cuestiones relacionadas