• Antes de nada, asegurate de que tienes instalados todos los parches de seguridad.
• Oculta la versión de Apache y otra información sensible.
• Asegúrate de que Apache se ejecuta con su usuario propio y su grupo de usuarios.
• Los ficheros fuera del web root no deben ser accesibles.
• Desactiva el listado de directorios.
• Desactiva los server side includes.
• Desactiva la ejecución de CGIs.
• No permitir que Apache siga los symbolic links.
• No permitas opciones de una única vez.
• Desactiva el soporte a .htaccess.
• Usa mod_security.
• Desactiva módulos innecesarios.
• Asegurate que solo el root tiene acceso al fichero de configuración de Apache y a los binarios.
• Disminuye el valor del timeout.
• Limita el tamaño de las requests.
• Limita el tamaño del cuerpo de un XML.
• Limita la concurrencia.
• Restringe el acceso mediante IP.
• Ajusta las opciones de KeepAlive.
• Ejecuta Apache en un entorno Chroot.

20 ways to Secure your Apache Configuration

• Validar todas nuestras entradas (variables de sesión y formularios). Los datos deben ser lo que se esperan, y si se esperan desde POST, que no vengan desde GET.
• Evitar el cross-site scripting (XSS) que es la introducción maliciosa de código mediante formularios que se ejecutará en nuestra aplicación.
• Modificar el fichero de configuración php.ini para que no use super globals, para mostrar todos los errores y que estos se muestren por fichero.
• Asegurar la conexión a la base de datos. Este método no lo conocía y la verdad es que me ha gustado bastante.
• Bloquear IPs de hackers, ya sea mediante PHP o htaccess
• Si el otro día hablábamos del LDAP, ahora nos hablan del LDAP injection, otra cosa que no sabía (no, si ya he dicho que es un buen artículo).
• Evitar que Google proporcione datos que no queremos (Google Hacking), para ello lo mejor es usar el robots.txt.
• Restringir el acceso mediante .htaccess

Protecting your Site

Vía / dzone

• Estadísticas expuestas: está bien saber quienes nos visitan, aunque lo que no es correcto es que esta información este disponible. Algunos programas de estadísticas tiene problemas de vulnerabilidad, a parte de que esa información debería ser confidencial.
  “Generated by Webalizer” intitle:”Usage Statistics”
  inurl:awstats filetype:pl
• Copias de seguridad: muchas veces los desarrolladores, al no disponer de un entorno de pruebas, crean copias de seguridad en el mismo servidor, normalmente renombrando como .old o .bak.
  filetype:bak inurl:”default”
  filetype:old inurl:”index”
  inurl:”Copy%20of%20″
• Tu sitio aparece en un sitio que recopila sitios con vulnerabilidades.
  sla.ckers.org
• Listado de directorios: no permitas que la gente pueda acceder a la lista de los ficheros contenidos en los directorios.
  “index of cgi-bin”
  intitle:”index of/” intext:”parent directory”
• Datos de login pasados en claro.
• Certificados SSL caducados: ¿cómo se puede confiar en un sitio que no paga unos cientos de dólares para tener su certificado en orden?.
• Uso de código ajeno: no se trata de no usar código de otros, sino de usarlo estando seguro de que no tiene errores de seguridad, para ello es bueno pasarse de vez en cuando por Secunia o SecurityFocus.
• Mensajes de error: cuidado con los mensajes de error que muestras, lo más recomendable es ponerle niveles a las trazas, así, si usas el nivel DEBUG los errores que cuando se muestran puedan ser peligrosos para nuestra aplicación solo se usaran cuando desarrollamos.
  “ORA-00921: unexpected end of SQL command”
  “Microsoft OLE DB Provider for ODBC Drivers error”
• Comentarios en nuestro código: aunque no aparezcan si se pueden leer mirando el código fuente, un error grave es poner comentarios para nuestro código PHP o JSP como comentarios HTML.
  // TODO lang:javascript
  // FIXME lang:javascript
• Si apareces en la lista de Zone-H Defacement Archive debes ponerte a trabajar ya mismo.

Top 10 Signs You Have an Insecure Web App

Vía / dzone

• Desactiva el acceso a ficheros remotos: las funciones fopen, file_get_contents, y include permiten el acceso a ficheros remotos (http://host/..), lo cual puede dar problema en temas de seguridad. Si necesitas acceder a ficheros remotos puedes usar fsockopen o funciones de CURL.

allow_url_fopen = Off

• Register globals: aunque ahora viene por defecto desactivado, en versiones anteriores de PHP, los parámetros de entrada se registraban como variables globales.

register_globals = Off

• Restringe a qué ficheros puede acceder PHP: normalmente PHP solo necesita acceder a ficheros situados en cierto path, por lo que para evitar que se acceda a otros paths, es conveniente restringir su acceso.

open_basedir = /www/ficheros

• Modo seguro: PHP dispone de un modo seguro, en el que Apache solo puede acceder a ficheros de los que sea dueño, aunque nos puede dar problemas sobre todo cuando se trabaja en grupo, la tranquilidad que nos aporta pesa más que este inconveniente. Para ello usaremos una propiedad para que solo ejecute scripts que le pertenecen y otra permite acceso a los ficheros que pertenecen al grupo de Apache aun cual sea el dueño.

safe_mode = Off
safe_mode_gid = On

• Acceso permitido a ficheros binarios: el modo seguro tampoco permite ejecutar ficheros binarios, pero se le puede indicar en que ruta si se pueden ejecutar.

safe_mode_exec_dir = /www/ejecutables

• Acceso a variables de entorno: tampoco está permitido acceder a variables de entorno en el modo seguro, pero se puede inluir una lista (separada por comas) de prefijos que se permiten para estas variables.

safe_mode_allowed_env_vars = PHP_

• Controlar límites: también es conveniente controlar ciertos límites, como el tiempo de ejecución, el de tamaño máximo subido y muchos otros.

max_execution_time = 30 ; Tiempo máximo de ejecución
max_input_time = 60 ; Tiempo máximo que trata la entrada
memory_limit = 16M ; Memoria máxima para la ejecución de un script
upload_max_filesize = 2M ; Tamaño máximo de un fichero para subir
post_max_size = 8M ; Tamaño máximo de un POST

• Control de acceso a ficheros mediante Apache: aunque en este caso se debe configurar Apache, tampoco biene mal el contarlo. Se trata de evitar que Apache acceda a ficheros importantes, por ejemplo ficheros .inc, .sql.

<FilesMatch "\.(inc|.*sql)$">
Order allow,deny
Deny from all
</FilesMatch>

• Evita el acceso a la shell: Taufpate nos recomienda también evitar que se intente acceder a la shell. Si tienes un server y das hosting tienes que tener cuidado con los usuarios que usan mambo, phpnuke, jooomla, etc.., sistemas que a diario reportan problemas de seguridad y nunca son actualizados por sus usuarios.

disable_functions = system, exec, shell_exec, passthru, pcntl_exec, putenv, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, popen, pclose, set_time_limit, ini_alter, virtual, openlog, escapeshellcmd, escapeshellarg, dl, curl_exec, parse_ini_file, show_source

Checklist for Securing PHP Configuration

Vía / dzone ]]> http://sentidoweb.com/2006/10/06/configura-tu-php-de-forma-segura.php/feed 0 http://sentidoweb.com/2006/09/19/firefox-depurara-su-codigo.php http://sentidoweb.com/2006/09/19/firefox-depurara-su-codigo.php#comments Tue, 19 Sep 2006 17:59:13 +0000 displaynone sw.luissacristan.com Mozilla pretende que las próximas versiones y funcionalidades que se incorporen a Firefox sean más seguras, para ello ha contratado a la anterior jefa de seguridad de Microsoft y ex-hacker. Según la nueva “Chief Security Something”.

Deseamos reducir el riesgo general de Firefox evaluando constantemente donde hay funcionalidad no aprovechada, desechando luego el código antiguo.

Mientras que las antiguas funcionalidades pretenden usarlas como extensiones y no como parte de código completo, también quieren aumentar la seguridad del navegador como integrando la nueva herramienta de anti-phishing de Firefox 2.0, y evitar que código maligno escriba en la memoria.

Este ataque se produce cuando a un usuario se le conceden permisos, confiando en él, pero no teniendo en cuenta que otra gente pueda aprovecharse de ello. Supongamos que tenemos una página de compra de artículos, cuya aplicación controla perfectamente los campos de entrada y que tiene una función que realiza la operación de compra de artículos.

Tenemos el formulario HTML:

<form action="compra.php" method="POST">
Artículo: <input type="text" name="articulo" />
Cantidad: <input type="text" name="Cantidad" />
<input type="submit" value="Comprar" />
</form>

El primer fallo que solemos cometer es leer las variables de entrada mediante $_REQUEST:

<?php
session_start();
if (isset($_REQUEST['articulo'] &&
isset($_REQUEST['cantidad'])) {
compra($_REQUEST['articulo'],
$_REQUEST['cantidad']);
}
?>

Una forma muy utilizada para realizar un ataque y que al autor del artículo le gusta mucho, es mediante el uso de una imagen:

<img src="http://ejemplo.org/compra.php?articulo=CAFETERA&cantidad=1000" alt="ads" />

Con esto conseguimos que el usuario que visita nuestra página tambien haga una petición a la página en cuestión sin que él lo sepa, claro, que esto solo funciona si el usuario a la vez tiene una sesión abierta en la página que se está atacando.

La solución es añadir una marca formada por un número “encriptado” y un tiempo para que tenga que renovarse esta marca. La marca se debe crear y pasar en el formulario por el que se envían los datos y a parte se debe controlar su existencia, si coincide y si no ha superado el timeout.

<?php
$marca = md5(uniqid(rand(), TRUE));
$_SESSION['marca'] = $token;
$_SESSION['tiempo_marca'] = time();
?>
<form action="compra.php" method="POST">
<input type="hidden" name="marca" value="<?php echo $marca; ?>" />
Artículo: <input type="text" name="articulo" />
Cantidad: <input type="text" name="Cantidad" />
<input type="submit" value="Comprar" />
</form>

<?php
if ($_POST['marca'] == $_SESSION['marca']) {
$diferencia_tiempo_marca = time() - $_SESSION['tiempo_marca'];
if ($diferencia_tiempo_marca <= 300) {
/* Menos de 5 minutos */
}
}
?>

Artículo original: Security Corner: Cross-Site Request Forgeries

Vía / backdraft