Resultados 1 al 3 de 3

Fallos en fragmentos de código

  1. #1 Fallos en fragmentos de código 
    Iniciado
    Fecha de ingreso
    Dec 2012
    Mensajes
    4
    Descargas
    0
    Uploads
    0
    Hola a tod@s:

    Os agradecería que me ayudarais a localizar posibles fallos de seguridad en los 2 fragmentos de código siguientes, y posibles soluciones para subsanarlos:

    1.

    [...]
    char *tmp_name;
    int tmpfd;
    tmp_name = “/tmp/tmpfile.XXXXX”;
    if( (tmpfd = open(tmp_name, O_RDWR | O_CREAT)) < 0) lnegra
    exit(-1);
    [...]
    unlink(tmp_name);
    /*
    ** remove the filename so that the file is not left on the
    ** file system when the program code completes or when
    ** the file descriptor is closed.
    */
    [...]


    2,

    [...]
    String comment = request.getParameter(“comment”);
    //Validate input for quotes and SQL especific chars
    [...]
    // End of SQL validation and begin XSS validation
    comment.replaceAll(“<script>”,””);
    comment.replaceAll(“</script>”,””);
    // Other cleanup operations
    [...]
    Citar  
     

  2. #2  
    Moderador Global Avatar de hystd
    Fecha de ingreso
    Jul 2005
    Ubicación
    1, 11, 21, 1211...
    Mensajes
    1.596
    Descargas
    58
    Uploads
    0
    Buenas, para el primer fragmento de código tienes una vulnerabilidad debida a considerar las operaciones de "acceso" y "lectura y escritura" sobre recursos como un fichero, como operaciones atómicas, no siendo así.

    Esto es, desde el momento en que haces "open()" sobre el fichero, hasta que realmente lees o escribes sobre él, alguien puede, mediante un proceso o hilo remoto hacerse con el control de ese fichero, otro fichero o incluso con otros recursos del sistema. Este tipo de vulnerabilidades es conocida como TOCTOU (Time Of Check to Time Of Use).

    SOLUCIÓN: Una posible solución, aunque no la única, se basa en usar excepciones controladas (mediante bloques try...except) para las operaciones de acceso y L/E, en vez de usar bloques (if...else), ya que así evitarás que cualquier atacante pueda escalar privilegios.

    ---------------

    Para el segundo fragmento de código en Java, sólo estás controlando que un atacante pueda hacer un XSS usando la cadena "<script>", pero no para cualquier otro tipo de cadena que llegue por el parámetro "comment", como por ejemplo un "<iframe>" que apunte hacia sitios de terceros que contengan código malicioso.

    SOLUCIÓN: El siguiente trozo de código quizás sea un poquito mejor que el que has puesto, en cuanto a "sanear" parámetros:

    Código:
    comment.replaceAll("<", "&lt;").replaceAll(">", "&gt;");
    comment.replaceAll("\\(", "(").replaceAll("\\)", ")");
    comment.replaceAll("eval\\((.*)\\)", "");
    comment.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
    comment.replaceAll("script", "");
    Con él, te evitarás que alguien pueda inyectar código Javascript y cualquier código HTML en general (por ejemplo meter etiquetas <iframe>, <frame>, <a>, <img>, <audio>, <video>, etc...).

    Un saludo.
    Última edición por hystd; 15-12-2012 a las 20:40
    El optimista tiene ideas, el pesimista... excusas

    Citar  
     

  3. #3  
    Iniciado
    Fecha de ingreso
    Dec 2012
    Mensajes
    4
    Descargas
    0
    Uploads
    0
    Excelente!!! Gracias.

    Cita Iniciado por hystd Ver mensaje
    buenas, para el primer fragmento de código tienes una vulnerabilidad debida a considerar las operaciones de "acceso" y "lectura y escritura" sobre recursos como un fichero, como operaciones atómicas, no siendo así.

    Esto es, desde el momento en que haces "open()" sobre el fichero, hasta que realmente lees o escribes sobre él, alguien puede, mediante un proceso o hilo remoto hacerse con el control de ese fichero, otro fichero o incluso con otros recursos del sistema. Este tipo de vulnerabilidades es conocida como toctou (time of check to time of use).

    solución: una posible solución, aunque no la única, se basa en usar excepciones controladas (mediante bloques try...except) para las operaciones de acceso y l/e, en vez de usar bloques (if...else), ya que así evitarás que cualquier atacante pueda escalar privilegios.

    ---------------

    para el segundo fragmento de código en java, sólo estás controlando que un atacante pueda hacer un xss usando la cadena "<script>", pero no para cualquier otro tipo de cadena que llegue por el parámetro "comment", como por ejemplo un "<iframe>" que apunte hacia sitios de terceros que contengan código malicioso.

    solución: El siguiente trozo de código quizás sea un poquito mejor que el que has puesto, en cuanto a "sanear" parámetros:

    Código:
    comment.replaceall("<", "&lt;").replaceall(">", "&gt;");
    comment.replaceall("\\(", "(").replaceall("\\)", ")");
    comment.replaceall("eval\\((.*)\\)", "");
    comment.replaceall("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
    comment.replaceall("script", "");
    con él, te evitarás que alguien pueda inyectar código javascript y cualquier código html en general (por ejemplo meter etiquetas <iframe>, <frame>, <a>, <img>, <audio>, <video>, etc...).

    Un saludo.
    Citar  
     

Temas similares

  1. Fallos Sintonizador
    Por mpeg en el foro TV CABLE
    Respuestas: 11
    Último mensaje: 03-01-2007, 19:32
  2. Mi decodificador de auna,fallos
    Por gokuh en el foro TV CABLE
    Respuestas: 5
    Último mensaje: 03-01-2007, 02:50
  3. La semana de los fallos en Oracle
    Por clarinetista en el foro NOTICIAS
    Respuestas: 0
    Último mensaje: 03-12-2006, 13:29
  4. Fallos con Emule
    Por Bifitera en el foro APLICACIONES
    Respuestas: 5
    Último mensaje: 02-08-2006, 20:38
  5. Fallos en cds con divx
    Por HAGEN en el foro MULTIMEDIA
    Respuestas: 0
    Último mensaje: 29-08-2003, 20:05

Marcadores

Marcadores