PHP 5.2.1 disponible

ByLuis

PHPHa salido a la luz la versión 5.2.1 de PHP, en la cual se solucionan bugs de seguridad, siendo recomendable que se actualice a esta versión.
Los cambios realizados se pueden ver en la release note y cabe destacar protección heap interna, mejoras en Zend Memory Manager y la extensión ZIP.
PHP 5.2.1 Released!

Similar Posts

Obtener URLs para usuarios en Codeigniter

ByLuis

Codeigniter tiene una método para tratar con las URLs: http://dominio/controlador/metodo/param1/param2/… El problema viene cuando nuestra aplicación necesita URLs diferentes, como las de Twitter u otra red social, que son del tipo http://dominio/username.

Para ello primero se debe cambiar el archivo routes.php de la configuración:

//Excluir estos controladores cuando se generan las URLs
$route['(login|oauth|site|search)(.*)'] = '$1$2';  
 
//Las URLs de los usuarios
$route['[a-zA-Z0-9]+/(add|edit)'] = 'users/$1';
$route['[a-zA-Z0-9]+'] = 'users/profile';

Después habrá que modificar el .htaccess para usar APP_PATH:

RewriteEngine On
 
RewriteBase /
 
RewriteCond %{ENV:REDIRECT_APP_PATH} !^$
RewriteRule ^(.*)$ - [E=APP_PATH:%{ENV:REDIRECT_APP_PATH}]
 
RewriteCond %{ENV:APP_PATH} ^$
RewriteRule ^(.*)$ - [E=APP_PATH:/$1]
 
RewriteCond $1 !^(index\.php|img|css|js|robots\.txt|favicon\.ico)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]

Y por último modificar el config.php para indicar que debe usar el APP_PATH:

$config['uri_protocol']    = "APP_PATH";
 
$config['enable_query_strings'] = TRUE;

Codeigniter Vanity URLs

Vía / PHPDeveloper.org

XSS mediante HTML no estándar

ByLuis

Cuando se quieren evitar ataques XSS, normalmente en PHP se usan las funciones htmlspecialchars o htmlentities.

Ahora veo un ejemplo en el que un ataque puede evitar estas funciones cuando se crea la página con HTML no estándar. Tenemos el típico ejemplo de un texto que se introduce por un formulario y se presenta como un enlace.

$dato = htmlentities($_GET['dato'], ENT_QUOTES);
echo "<a href=pagina.php?dato=$dato>Enlace</a>";

Si os fijáis bien veréis que el enlace está mal formado y no tiene las comillas en el href. Si metieramos como dato de entrada lo siguiente: ” onclick=alert(null)” (sin las comillas), nuestra página sufriría un ataque XSS y mostraría un mensaje alert.

Non-Standard HTML Fuels XSS Attacks

|

Zend Framework: métodos estáticos

ByLuis

Antes de meternos a estudiar los componentes que nos facilita el framework de Zend, es necesario ver los métodos estáticos, los cuales a parte de sernos útiles, también se usan dentro de los distintos componentes.

  • loadFile(): carga cualquier archivo con código php, envuelve a la funcion include(). Tiene 3 parámetros, el nombre del archivo, el directorio dónde se situa, si es NULL buscará solamente en el include_path y un flag para indicar si se usa include o include_once. Si se produce cualquier error lanza una excepción Zend_Exception.
  • loadClass(): carga una clase, la cual se indica como parámetro, a parte se puede decir el directorio donde se encuentra. Si el directorio es null y el nombre de la clase tiene guiones bajos (_), usará los subrayados para localizar los directorios: p.e. Paquete_Componente_Clase lo sustituirá por Paquete/Componente/Clase.php. Si se produce algun error, se lanza una Zend_Exception.
  • loadInterface(): funciona igual que loadClass pero para interfaces.
  • isReadable(): es igual que la función is_readable de PHP pero con la posibilidad de buscar en el include_path.
  • dump(): ejecuta la función var_dump de PHP pero usando etiquetas pre de HTML y seleccionando se si realiza un echo o no.
  • register(): registra un objeto en el espacio de la aplicación, una vez registrado, cuando se recupera, siempre será la misma instancia. Se le debe pasar por parámetro el nombre y la variable.
  • registry(): devuelve una variable del registro cuando se le pasa su nombre por parámetro o una lista de todas las variables del registro cuando se pasa null.

Detectar código duplicado en PHP con PHPCPD

ByLuis

PHPCPD es una herramienta que nos permite detectar código duplicado en nuestros scripts PHP. Una utilidad muy interesante sobre todo para aquellos proyectos grandes en los que hay muchos ficheros y unos cuantos metiendo mano al código, ya que la falta de documentación o de comunicación hace que se repitan codigos en diferentes partes del proyecto, o también debido a malas prácticas a la hora de desarrollar. El código repetido hace que sea imposible de mantener y cueste horrores modificar una funcionalidad ya que hay que buscar en diversos lugares.
PHPCPD
Vía / PHPDeveloper.org

Suhosin: sistema de protección para PHP

ByLuis

Suhosin es un sistema avanzado de protección para PHP. Ha sido diseñado para proteger los servidores y a los usuarios de defectos conocidos y desconocidos del core de PHP y de las aplicaciones realizadas con PHP.
Viene en dos partes independientes que pueden ser usadas de forma separada o en combinación. La primera de ellas es un pequeño parche para el core de PHP que implementa unas protecciones de bajo nivel para solucionar vulnerabilidades desbordamiento del buffer y de formateo de cadenas de texto. La segunda parte es una extensión PHP que implementa las otras protecciones.
Suhosin es compatible a una instalación normal de PHP, lo cual significa que a su vez lo es de extensiones de terceros como ZendOptimizer.
Suhosin
Vía / PHP Security Blog

Traduce tu plugin para Gutenberg

ByLuis

Traducir los plugins desde WordPress es bastante fácil, tan solo tienes que ejecutar este comando para generar los ficheros .pot.

wp i18n make-pot .

Una vez generados los ficheros de traducción, yo uso PoEdit, el siguiente paso es generar los ficheros JSON, ya que Gutenberg es lo que usa.

Para ello utilizaremos la herramienta po2json, que podrás instalar ejecutando:

npm i -g po2json

Cuando se haya instalado tendremos que generar el fichero json ejecutando desde el directorio donde están los ficheros de traducción:

po2json mi-plugin-es_ES.po mi-plugin-es_ES-mi-plugin-handler.json -f jed

Ahora viene la parte más complicada, y digo complicada porque sinceramente he tenido que mirar el código porque algo me fallaba cuando seguía lo que decía la documentación.

El nombre del fichero JSON tiene el siguiente formato [dominio de traducción]-[idioma]-[handler del fichero].json, total nada.

  • Dominio será el que usemos para traducir, en el ejemplo sería mi-plugin:
__( 'Hola que tal', 'mi-plugin' );
  • Idioma es el código del idioma, en este caso es_ES
  • Y por último el handler del fichero es el primer parámetro que usamos en wp_enqueue_script

Lo podemos ver todo en un ejemplo final:

wp_enqueue_script(
	'mi-plugin-handler', // El handler mencionado anteriormente
	$blocks_script, // Nuestro path
	[
		'wp-i18n', // De referenciar al menos a wp-i18n
	],
);

wp_set_script_translations( 'mi-plugin-handler, 'mi-plugin', plugin_dir_path( __FILE__ ) . 'languages' );