php

Seguridad Web

Medidas de seguridad PHP modo prevención

Cuando contratamos un servidor dedicado LAMP (linux, apache, mysql, php) , donde el sistema operativo aconsejamos que sea CENTOS,  normalmente el PHP viene habilitado con la mayor parte de funcionalidades «peligrosas» y de las que se nutren los atacantes.

Al contratar nuestro primer server, o si ya somos asiduos en el aquiler de servidores (Virtuales/Clouds/Dedicados) mi consejo es que deshabilitemos las siguientes funciones en nuestro fichero «php.ini» (Si no sabemos donde está, le hacemos un «find / – name php.ini» en nuestra consola.) :

 

disable_functions =»apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode»

 

(Al editar el archivo, buscamos primero la linea que empieza por disable_functions y añadimos todo el carro de funciones sensibles)

 

Finalmente y cuando un atacante intente usar dicha función, si es que lo consigue, verá el siguiente error:

Warning: exec() has been disabled for security reasons in /home/admin/domains/tudominio/test.php on line 86

 

* Por otro lado, si no vamos a usar Python ni CGIs, deberíamos deshabilitar su ejecución tambien, o bien contactar con vuestro hosting/datacenter para tal fin, ya que muchos scripts de phising y mailers los utilizan.

php

PHP Conference Barcelona II

Ya  se está preparando la nueva edición de la PHP conference Barcelona, la cual en su primera cita, fue todo un éxito, incluido el desayuno espléndido que hubo 🙂 espero que se repita.

PHP barcelona

 

Como se ve en la imagen se celebrará el próximo día 27 de Septiembre (Sábado, para los que salgan el viernes noche tendrán que madrugar). En esta ocasión el evento se celebrará en dos tracks paralelos para poder elegir el que más nos guste, debido a que se espera una afluencia mayor a la de la primera edición.
Aquí se puede ver el programa del evento

Nos vemos allí!

 

LINK: PHP conference Barcelona 2008
LINK: PHP Barcelona

php

Novedades en Zend Framework 1.6

Algunas de las novedades de la nueva versión (Que serán muchas):

– Integración con Dojo: Novedades para formularios, cargas de listados dinamicas sin ajax, etc …
– Infraestructura Unit testing: Tener la seguridad que toda la aplicación trabaje perfectamente y no solo los modelos.
– Soporte para Captcha: Para hacer frente al Spam que vivimos hoy día.
– Soporte Soap
– Soporte para Firebug de Firefox
– Soporte para paginaciones, indispensable con Zend_Paginator
– Etc.

Vídeo oficial, visto por estar suscrito al canal (14 de agosto):

Diseño web

Primera Barcelona PHP Workshop

El 7 de Junio el grupo PHP Barcelona organiza la Primera Barcelona PHP Workshop

PHP

Entre otras se podrá aprender:

  • Workshop de Symfony
  • Motores de Workflow en PHP
  • Editor VIM para PHP
  • Librerias AJAX
  • Seguridad contra XSS

Creo que es un iniciativa excelente para iniciarse en aquellos aspectos que parecen lejanos para «algunos»

Podeis inscribiros aquí (Yo no podré asistir por estar de vacaciones los 3 dias del fin de semana en Tenerife)

Apps Web, osCommerce, Tiendas online

Seguridad en nuestras Tiendas Virtuales

Volviendo un poco a la seriedad y siendo hoy el Día internacional de la seguridad, me estaba planteando en crear una pequeña primera Guia de Seguridad para tiendas online, que básicamente se podría portar a casi cualquier aplicación PHP.

Principales archivos a modificar:

php.ini (Configuración general del PHP, si phpsuexec activado, tendremos que editarlo en la carpeta de la aplicación que vayamos a programar)

httpd.conf (configuración del apache)

.htaccess (sobreescribir las directivas del php.ini si nos lo permiten y no está activado phpsuexec)

Para tener una primera vision de la configuración general, y valorar si tenemos puntos comprometidos, deberemos crear un archivo php con el siguiente código y visitarlo con nuestro navegador:

<?php phpinfo() ?>

Pasos a seguir:

1) No mostrar errores a nuestros intrusos, para ello definiremos en el .htaccess

[sourcecode=php]
php_flag display_errors Off
php_flag log_errors On
php_value error_log «Ruta completa al fichero de log»
[/sourcecode]

– Que no se muestren los errores en pantalla, y cambiarlo a que se guarden en la maquina en un fichero local solo accesible para el webmaster.

2) El famoso Register globals que por defecto ahora viene desactivado. En las tiendas oscommerce a partir de la RC1 ya no hace falta tenerla activada (en MS2 y anteriores si), por lo que ya no tendremos ese problema de configuración. Tenerlo activo no es un problema de seguridad en sí, si el código está bien implementado, pero si por defecto ya viene desactivado, estamos obligados a no jugar con «fuego» al poder pasar parámetros por GET y POST dentro de las variables globales de nuestra aplicación. Para desactivar esta directiva:

[sourcecode=php]
php_flag register_globals Off
[/sourcecode]

3) Usar SAFE_MODE o no… en mi opinión solo és útil para servidores compartidos, donde hay varios usuarios, y así evitar que unos accedan o incluyan los ficheros de los otros. El único y gran problema es que al tenerlo activo, tendremos incompatibilidades con otros módulos y funcionalidades. Habría que valorar si es realmente necesario tenerlo activo en nuestro servidor.

4) Doble protección de nuestros ficheros de administración. Por ejemplo… toda la carpeta administrador o backend de la aplicación implementar protección mediante formulario de login, y además añadir protección mediante apache desde nuestro panel de control de hosting o a mano.

5) Denegar el acceso a nuestros directorios y ficheros de configuración o «sensibles» con la siguiente instrucción en el .htaccess (dentro del directorio donde se encuentran los archivos a proteger)

Proteger ficheros php:

[sourcecode=php]

Order Deny,Allow
Deny from all

[/sourcecode]

Proteger todos los ficheros del directorio que se especifique:

[sourcecode=php]

Order Allow,Deny

[/sourcecode]

6) Sistemas de pago. El más sensible sin duda es la tarjeta de crédito. Los más seguros son los que usan webservices, y sin salir de la web, pero a día de hoy solo es viable con BBVA y algún otro banco.  Mi recomendación es usar el sistema TPV de servired, que podremos encontrar en casi todas las cajas y caixas (La caixa, Caixa catalunya, Caja madrid, etc) que através de una firma Sha1 completa ampliada y una clave personal se transmite la información de forma «segura» entre la página del banco (quien se encargará por nosotros de recoger los datos de la tarjeta y comprobar su veracidad) y nuestra tienda, que será la que reciba la confirmación y autorización del pago.