Lineamientos utilizados con CodeIgniter 20x

De la documentacin (User Guide) de CI-2.0.x http://codeigniter.com/user_guide/libraries/security.html:

1. Filtrado XSS (Cross Site Scripting)

Por defecto, CI-2.0.x trae deshabilitado el filtrado XSS ya que el mismo implica una ligera sobrecarga de procesamiento. El filtrado puede ser activado globalmente editando el archivo:
application/config/config.php

Buscando la lnea:
$config['global_xss_filtering'] = TRUE;

ATENCIN: El filtrado, activado globalmente se ejecuta automticamente sobre COOKIES y POST. Para llamar a la funcin explcitamente se debe ejecutar el siguiente cdigo:
if ($this->security->xss_clean($file, TRUE) === FALSE) { // file failed the XSS test }

Para ver lo que representa el segundo parmetro de la funcin xss_clean(), leer la Gua de Usuario de CI. Como nota aparte, antes de utilizar los arreglos mgicos $_SERVER, $_POST, $_GET, o $_COOKIE es conveniente utilizar las correspondientes funciones "input" que provee CI: http://codeigniter.com/user_guide/libraries/input.html Adems, algunas de dichas funciones permiten como segundo parmetro (opcional) especificar explcitamente si ser quiere realizar un filtrado XSS sobre dicho INPUT. Por ejemplo
// Al obtener los datos de $_POST['some_data'], previo filtrado XSS $sd = $this->input->post('some_data', TRUE);

Utilizar codificacin adems de lo visto arriba, por que no hace chequeos sobre el cdigo javascript en su totalidad:
$myvar = urlencode($this->input->post(myvar)); $this->load->view(myview, array(myvar => $myvar));

fuente: http://ponderwell.net/2010/08/codeigniter-xss-protection-is-good-but-not-enough-byitself/

2. Cross-site request forgery (CSRF)

El destino ms habitual de una vulnerabilidad CSRF son los formularios, segn lo que se puede leer en: http://www.beheist.com/index.php/en/blog/csrf-protection-incodeigniter-2-0-a-closer-look . Un formulario que presenta vulnerabilidades CSRF generalmente acepta las peticiones o datos enviados al mismo sin chequear si los datos fueron cargados desde un formulario presentado desde la aplicacin. Es decir, un atacante que se aproveche de CSRF tratar de enviar datos por POST/GET a un formulario directamente y sin utilizar los formularios de la aplicacin. Para (en parte) prevenir estas situaciones, se recomiendan los siguientes 2 pasos: 1. Editar el archivo:
2. application/config/config.php

y activar la opcin:
$config['csrf_protection'] = TRUE;

3. Utilizar del Helper para formularios (Form Helper) la funcin:

4. form_open()

Esta funcin insertar automticamente en un campo oculto un TOKEN. Luego, al procesar el formulario, se debe verificar la existencia del TOKEN para poder comprobar que la peticin provino realmente del formulario en cuestin. Para ver cmo emplear esta caracterstica en sitios que utilicen AJAX: http://aymsystems.com/ajax-csrf-protection-codeigniter-20

3. Verificacin de nombres de archivos

Cuando se aceptan nombres de archivos desde alguna entrada de usuario, aplicarle la funcin "sanitize_filename()" para prevenir lo que se denomina directory traversal (acceso a otros directorios). Cabe aclarar que esto adems debe estar respaldado por una la correcta/correspondiente configuracin de Apache o servidor HTTP. Por ejemplo, para "sanitizar" un nombre de archivo proveniente desde $_POST['filename']:
$filename = $this->security->sanitize_filename($this->input>post('filename'));

4. Encriptacin de los datos de sesin en las COOKIES

Es altamente recomendable revisar en el archivo de configuracin:
application/config/config.php

Las siguientes opciones:

1. sess_encrypt_cookie: Preferentemente debe poseer el valor TRUE en el entorno

de produccin. 2. sess_expire_on_close: dem anterior. 3. sess_expiration: Duracin de la sesin en segundos (por defecto es de 2 Hs = 7200 Segs). NOTA IMPORTANTE: Tal como explica la documentacin de CI, el manejo de la sesin que mediante las funciones que incluye CI no hacen uso de las funciones nativas de PHP para le manejo de sesiones.

5. Manejo de datos "de ingreso" al sistema, o "que deben ser mostrados al usuario"
Por regla general se debe desconfiar al 100% de los datos que provengan del usuario (tambin se debe desconfiar de algunos datos almacenados, pero ya se ver esto ms adelante). Antes de utilizar o almacenar algn valor que provenga de la entrada de usuario, dicho valor: 1. Debe ser siempre validado a travs de la librera de CI, 2. No debe utilizarse nunca directamente en alguna sentencia que involucre "comillas mgicas" (aunque esta caracterstica se encuentra marcada como DEPRECATED en PHP-5.3.0), 3. ... Si los datos deben ser mostrados en pantalla, por ejemplo cuando se debe REPOPULAR UN FORMULARIO, es conveniente filtrar los datos antes de mandarlos a la salida (antes de enviarlos a un 'echo'), utilizando algunas de las siguiente funciones de PHP:
1. htmlspecialchars(), http://ar.php.net/htmlspecialchars. o, 2. htmlentities(), http://ar.php.net/manual/es/function.htmlentities.php, 3. Funciones prepping de CI,

http://codeigniter.com/user_guide/libraries/form_validation.html#preppingdata hay que buscar ejemplo de cmo se utilizan estas funciones en situaciones que NO sean el procesado de formularios) Estos filtrados previos deben realizarse con el fin evitar mostrar por pantalla contenido entre etiquetas especiales como <spript>. De esta forma, prevenimos la inyeccin de cdigo que pueda explotar vulnerabilidades XSS/CSRF que pueda ser ejecutado en el navegador del usuario. Escapar esto caracteres mediante entidades HTML evita el interpretado de los mismos.

6. Evitar SQL injection

Las consultas deben realizarse usando Query binding: http://codeigniter.com/user_guide/database/queries.html

Ademas los elementos de la consultas deben ser parmetros. Tampoco hay que incluir magic quotes. Ejemplo :
//INSEGURO $this->db->query("SELECT username FROM user WHERE id='$idUsuario'"); //SEGURO $this->db->query('SELECT username FROM user WHERE id=?', array($idUsuario));

Ejemplos : http://stackoverflow.com/questions/1615792/does-code-igniter-automatically-preventsql-injection http://stackoverflow.com/questions/3797613/sql-injection-and-codeigniter

Convenciones generales de desarrollo

1. Interaccin con Base de Datos
Si la aplicacin involucra la utilizacin de una DB, deber crearse un usuario y una DB dentro del motor de DB correspondiente y para uso exclusivo de dicha aplicacin. Si el framework en uso provee funciones especiales para realizar consultas a la DB (evitndonos escribir cdigo SQL directamente), entonces usar dichas funciones que brinda el framework. Por ejemplo CI provee algunas funciones para interactuar con la DB, mediante la implementacin de un patrn que se denomina "Active Record".

2. Diseo/implementacin de restricciones en las aplicaciones

En general, la seguridad/restriccin que se aplica sobre el contenido de la aplicacin no se implementa mediante la "OCULTACIN DE CONTENIDO". Lo que suele utilizarse es directamente la CANCELACIN DEL PROCESO/EJECUCIN del script que se est llamando en la solicitud del usuario. Por ejemplo, en CI suelen chequearse los privilegios del usuario (o auntenticar el mismo) en el constructor de un Controller. Si el usuario NO posee los privilegios necesarios, directamente se lo redirige a un controlador especial SIN MOSTRAR CONTENIDO ALGUNO del Controller que quiso acceder originalmente.

3. Comentarios dentro del cdigo PHP/HTML

Si los comentarios estn relacionados con los usuarios/permisos/privilegios u otra informacin delicada, es preferible documentar dicha informacin en la Wiki del proyecto. Es desaconsejable comentar dichos datos en PHP, y es un error comentar dicha informacin en HTML (ya que esto ltimo slo oculta dicha informacin a la vista del usuario, pero es visible en el cdigo fuente HTML).

4. Ejecucin de comandos externos a PHP

Cuando se ejecuta un comando externo a un script PHP, deben validarse los parmetros que se le pasan a la aplicacin. Particularmente, debe determinarse qu cosas se le pasar como argumentos a dicha aplicacin y descartar todo lo dems.

5. Evitar envenenamiento de Cookies

El contenido de las cookies debe estar encriptado y debe almacenarse en ellas la direccion del usuario(IP)(para validacin). Fuente: http://stackoverflow.com/questions/1633062/how-to-prevent-cookie-poisoning

LINKS
XSS: http://stackoverflow.com/questions/1996122/how-to-prevent-xss-with-html-php http://stackoverflow.com/questions/71328/what-are-the-best-practices-for-avoiding-xssattacks-in-a-php-site http://ha.ckers.org/xss.html SQLi: http://ha.ckers.org/sqlinjection/

Convenciones a utilizar con usuarios de prueba

1. Nombres de usuario y passwords
Los usuarios de prueba que posean privilegios de administrador en los sistemas en desarrollo, debern tener passwords no triviales: 1. Formadas por caracteres y nmeros, 2. Fciles de recordar, 3. En lo posible que posea algn carcter raro (pero permitido por la aplicacin) 4. Documentar los datos de dichos usuarios en la Wiki del proyecto correspondiente, especificando si el usuario ser vlido en los entornos de DESARROLLO/PRUEBA/PRODUCCIN. Por ejemplo, si la aplicacin se llama SSD, un usuario y password de ejemplos podran ser:
username: admin password: pss2011tcw.ssddmn // Notar que el pass es en realidad es la cadena "pass2011tcw.ssdadmin" SIN LAS VOCALES

Suponiendo que se utilicen varios usuarios de prueba, dicha cantida de usuarios deber mantenerse mnima (y controlarse al momento de desplegar el sistema en el entorno de PRODUCCIN/PRUEBA).

Bibliografa/documentacin sobre riesgos en aplicaciones web:

OWASP Top Ten Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

El Proyecto OWASP (Open Web Application Security Proyect) provee un rankinglistado de los 10 riesgos presentes en la mayora de las aplicaciones web anualmente. Cabe aclarar que dicho listado expone un ranking de riesgos y no de ataques a aplicaciones web. Esta diferenciacin entre los concepts "riesgo/amenaza y ataque" se debe a que el rnking tambin pondera otras caractersticas del riesgo como puede ser el grado de influencia en el sistema vctima (por ejemplo una amenaza puede realizar alteraciones leves de datos, mientras que otra amenaza puede representar una prdida total de datos).