Wordpress Exploid Scanner, se encarga de revisar por nosotros los ficheros de nuestro Wordpress para econtrar posibles puntos débiles por los que nos podrían atacar mediante un exploid a la base de datos. Posee una lista de posibles ataques que comprueba cuando lo solicitamos. [Descargar]
Contenido
Wordpress Exploid Scanner 0.1, checkea la seguridad de tu blog
aNieto2k hace 7 días en: Asides, Wordpress, plugins
Botón de identificación del sitio de Firefox 3
aNieto2k hace 58 días en: Tecnologia, estandares, web, webdev
Firefox 3 incorpora muchas mejoras y muchas nuevas funcionalidades para facilitar la vida al usuario. Entre ellas está el sistema de identificación de sitios, un sistema con el que se intenta evitar los problemas de phishing que actualmente sufren muchos usuarios.
Actualmente, los usuarios de Firefox2, únicamente somos capaces de diferenciar un sitio de uno “seguro” mediante el sistema de encriptación, que cuando detecta que has pasado a ese sistema nos cambia la barra de dirección a un color amarillo pastel.
En Firefox3 van un paso más adelante y además de detectar si un sitio está usando un encriptación para asegurar nuestro datos, nos mostrará 3 colores que indicarán el nivel de seguridad del sitio. Ideal para sitios destinados a almacenar, manipular y trabajar con datos sensiles del usuario.
Gris, azul y verde, indicarán el nivel de seguridad de cada sitio.
Gris - No hay información de identidad
No se ha encontrado información sobre la identidad del sitio, la conexión entre el servidor y el navegador no está encriptada por lo tanto no se puede asegurar que sea seguro usar datos sensibles.
Azul- Información de identidad básica
Indica que el sitio ha sido validado, que la conexión entre navegador y servidor está encriptada, por lo tanto tenemos un cierta garantía de seguridad.
Verde - Información de identidad completa
Indica que el sitio está completamente validado, la conexión está encriptada y el sitio está usando el nuevo Extended Validation Certificate, un certificado especial que requiere un verificación de identidad más rigurosa que otros certificados. Podemos confiar en el sitio.
Amarillo - Certificado de identidad inválido
Nos aparecerá de este color, indicando que el certificado está caducado, necesita renovación, …
Rojo - Reporte de ataque

Indica que el sitio ha sido reportado como peligroso y que no deben introducirse sitios datos confidenciales en él.
10 plugins para mejorar la seguridad de nuestro Wordpress
aNieto2k hace 79 días en: Wordpress, plugins
Hace ya un tiempo vimos algunos consejos con los que podríamos mejorar sensiblemente la seguridad de nuestro Wordpress. Estas ideas básicas han dado lugar a un serie de plugins que facilitan considerablemente el trabajo de los usuarios de Wordpress con los que podrán mejorar sustancialmente la seguridad de sus blogs.
Las páginas blancas de la seguridad Wordpress
aNieto2k hace 247 días en: Wordpress, webdev
Los chicos de BlogSecurity, han desarrollado un PDF llamado “How to Secure Wordpress” o “Como asegurar Wordpress” en el que nos indican una serie de puntos a tener en cuenta a la hora de mejorar la seguridad de nuestro Wordpress.
El fichero incluye 10 páginas en las que nos dará unas pautas con las que asegurar nuestro Blog, partiendo desde los permisos necesarios y recomendados para las tablas y los usuarios de MySQL hasta la configuración de los fichero .htaccess y .htpasswd, pasando por las restricciones en ficheros como wp-content y wp-includes.
Me atrevo a hacer una traducción rápida del contenido de dicho PDF.
Instalando Wordpress
La instalación de Wordpress, es la base de nuestra seguridad, así que debemos prestar especial atención a este punto para evitar sufrir más adelante.
Accediendo a las tablas de Wordpress
Antes de empezar a instalar tu blog, necesitarás elegir bien los permisos del usuario de base de datos. La idea detrás de este punto vitál es la limitar el uso del usuario destinado a trabajar con las tablas de Wordpress a solo eso, Wordpress.
Por este motivo, el usuario root, nunca debe ser usado para acceder a la base de datos, es más, incluso aconsejan deshabilitarle esta posibilidad desde aplicaciones como phpmyadmin o similares.
El usuario de base de datos no debería tener privilegios globales SQL, esto limitará el acceso a la base de datos en donde esté Wordpress alojado. Solo sería necesario que tuviera permisos para las tareas del día a día.
Para datos: SELECT, INSERT, UPDATE, DELETE Para estructura: CREATE, ALTER, DROP
Si estás alojado en un servidor en el que hay varios usuarios usando la misma base de datos, los permisos deberían ser más restrictivos.
Para datos: SELECT, INSERT, UPDATE, DELETE Para esctructura: ALTER
De esta forma, en el peor de los casos, si alguien pudiera conseguir los datos del usuario de base de datos, únicamente podría acceder a una parte muy limitada de ella, sin comprometer el resto del servidor.
Cambia el prefijo de las tablas
Por defecto Wordpress, te da la opción de usar wp_ como prefijo para las tablas que alojarán los datos de Wordpress (posts, comentarios,…) pero como recomendación, siempre debería cambiarse. De esta forma alguien con mala intención debería conocer el prefijo de las tablas para poder acceder a ellas.
Quizas la solución más correcta sea la de usar un prefijo aleatorio, algo como 34eedrr_ algo que nunca nadie pueda conocer por intuición.
Para conseguir esto, basta con modificar el prefijo antes de iniciar la instalación, en cuanto estamos informando de los datos del usuario de base de datos, modificaremos la línea:
$table_prefix = 'wp_';
por algo así
$table_prefix = '1qw23e_';
Y continuamos con la instalación.
Si ya tenemos Wordpress instalado y queremos cambiar el prefijo de las tablas, existen plugins que te permite cambiar el prefijo casi sin tener que hacer nada. Uno de ellos es WP Prefix Table Changer, igual de claro como su nombre.
El fichero wp-config.php
Este fichero, es nuestro tesoro, con el conectamos a la base de datos, informamos el idioma de nuestro blog incluso activamos a desactivamos el uso de caché. Así que hemos de prestar una especial atención.
Por ese motivo, los permisos de este fichero deberían ser 644, convirtiendolo en un fichero de solo lectura.
Preparando el blog
Ahora tu blog ya está instalado, ya tenemos cierta seguridad aplicada y ahora tenemos que ponernos manos a la obra para depurar esa seguridad.
Cambiando tu usuario Administrador
Debemos cambiar el nombre del usuario administrador por defecto (admin), de esta forma mitigamos los intentos de ataques por fuerza bruta a nuestro Wordpress.
Debes asumir que los atacantes conocen tu nombre de usuario, así que piensa en una buena contraseña para asegurarte.
¿Como cambiar el usuario administrador?
Logueate con tu cuenta de Administrador, crea un usuario al que le darás permisos de administrador, usa un nombre dificil de predecir (nada de root, god, …) y asignale un password igual de complicado (te recomiendo que uses carácteres no alfanuméricos), le pondremos el mismo email que el admin inicial y borraremos la cuenta admin en la que estamos logueado.
Create un usuario con acceso limitado
En el PDF, recomiendan que instalemos Role Manager, un plugin para gestionar los permisos de los usuarios, a modo de barrera contra posibles intrusiones. Una vez instalado el plugin, crearemos un nuevo usuario al que limitaremos con las funcionalidades que vayamos a usar.
Para asegurar nuestro Wordpress, se recomienda que el nuevo usuario no sea más que un Contribuidor.
Los permisos por defecto del Contribuidor no son suficientes para un uso diario de Wordpress, pero con el plugin Role Manager, podemos añadirle permisos adicionales para hacer este perfíl más flexible pero igual de seguro.
Si tienes multiples usuarios, lo mejor que puedes hacer es crear un nuevo rol con los permisos que quieres que tengan todos los usuarios.
Cuando creamos usuarios, tenemos que tener especial cuidado en las opciones de:
- Subir ficheros
- Accesso al menú de plugins
- Editar páginas / posts/ ficheros
- Importart
Ya que es tas opciones, dan mucho poder al usuario.
Endureciendo Wordpress
Todo lo hecho anteriormente no sirve de nada si dejamos una ventana abierta por la que se pueda acceder, hemos de cerrar todos posibles acceso para evitar sopresas.
Restringiendo los directorios wp-content y wp-includes
Son sin duda los dos directorios más usados por Wordpress, por lo tanto hemos de protejerlos. Para ello, usaremos el fichero .htaccess para limitar el uso de cada directorio. Para empezar veremos una estructura básica para el fichero .htaccess de nuestro directorios wp-content y wp-includes.
Order Allow,Deny
Deny from all
<Files ~ ".(css|jpe?g|png|gif|js)$">
Allow from all
</Files>
De esta form estamos evitando que se pueda acceder a cualquier fichero directamente, por ese motivo tendremos que revisar los plugins y themes que esten pensados para acceder a ellos y añadirlos al listado (por ejemplo Share This (Compartelo)).
Restringiendo wp-admin
El directorio wp-admin, es donde tenemos todo lo necesario para administrar nuestro blog, por eso tenemos tambien que asegurar el fuerte por este flanco.
Bloque todas las IP’s menos la tuya
Si eres un único administrador, tienes IP estática y solo administras el blog desde un único PC, deberías bloquear el acceso a todo el resto de IP’s. Para ello únicamente tendremos que usar el fichero .htaccess alojándolo en el directorio wp-admin/ con el siguiente contenido.
Order deny,allow
Allow from a.b.c.d #TU IP ESTÁTICA
Deny from all
Añadele un password al directorio wp-admin
Otra opción igual de válida es la de añadirle un password al directorio wp-admin/, de esta forma tendremos un doble candado para acceder a nuestro panel de administración.
Para ello tendremos que usar el fichero .htaccess y .htpasswd
.htaccess
AuthUserFile /srv/www/user1/.htpasswd #this file should be outside your webroot.
AuthType Basic
AuthName “Blog”
require user youruser #making this username difficult to guess can help mitigate password
brute force attacks.
Y el fichero .htpasswd, incluirá el nombre de usuario y password encriptado, generarlo podemos usar herramientas Online que nos hacen la encriptación necesaria.
Plugins que debemos tener
No todos los plugins, son posibles fallos de seguridad para nuestro blog, tembian hay algunos que se encargan de ayudarnos a conocer los puntos débiles. Siempre viene bien tenerlos a mano para ir mirando la seguridad cuando actualizamos.
- WPIDS, detecta intrusiones
- Wordpress Plugin Tracker, asegurate que estas a la última en cuanto a plugins
- Wordpress Online Security Scanner, revisa el peligro que corres con tu blog.
Javascript para Hackers
aNieto2k hace 277 días en: Asides, Programacion, estandares, javascript, web, webdev
El que javascript sea un lenguaje ejecutado en el cliente permite que haya documentos como estos, “Javascript para hackers“, con una recopilación de métodos para comprometer la seguridad de las páginas web…. o métodos para asegurar nuestras aplicaciones web contra este tipo de ataques ![]()
Mejora la seguridad de tus scripts con sprintf() y printf()
aNieto2k hace 298 días en: PHP, Programacion, Proyectos, webdev
Por desgracia las aplicaciones web no son seguras, nos guste o no, lo que hoy es seguro mañana no lo será. Alguién encontrará una forma de hacer añicos tu trabajo con una sucesión de carácteres a modo de exploid. Aprovechando aguna vulnerabilidad que por descuido o desconocimiento has dejado ahi, esperando a que nunca nadie la encuentre…
Para evitar que nunca nadie las encuentre, nuestro deber como desarrolladores es formarnos constantemente y estar al tanto de las nuevas mejoras y funcionalidades que van saliendo referente al lenguaje que estamos usando asiduamente. Quiero aportar un granito de arena recomendando esta forma de controlar nuestras peticiones a base de datos al puro estilo Google Gears.
sprintf(), protegiendo las peticiones
sprintf() es una función de php, (portada de C/C++) en la que podemos especificar el formato que ha de tener una cadena. Esta función nos permite hacer cosas como estas.
$sql = sprintf("SELECT nombre FROM tabla WHERE id = %d;",$numero);
mysql_query($sql);
De esta forma tan simple, estaremos indicando que la variable $sql, solo contendrá un número como parámetro para la consulta por id. Previamente a la utilización de $numero, deberemos tratarla para evitar que esto sea otra cosa que un número entero. En caso de pasarle un valor diferente a un entero la SQL dará un error de formateo al no reemplazar el valor.
Otros operadores
- % - un caracter de porcentaje literal. No requiere argumento.
- b - el argumento es tratado como un entero, presentado como un número binario.
- c - el argumento es tratado como un entero, y presentado como el caracter con ese valor ASCII.
- d - el argumento es tratado como un entero, y presentado como un número decimal (con signo).
- e - el argumento es tratado como notación científica (p.ej. 1.2e+2).
- u - el argumento es tratado como un entero, y presentado como un número decimal sin signo.
- f - el argumento es tratado como un flotante, y presentado como un número de punto flotante (teniendo en cuenta la localidad).
- F - el argumento es tratado como un flotante, y presentado como un número de punto flotante (no tiene en cuenta la localidad). Disponible desde PHP 4.3.10 y PHP 5.0.3.
- o - el argumento es tratado como un entero, y presentado como un número octal.
- s - el argumento es tratado y presentado como una cadena.
- x - el argumento es tratado como un entero y presentado como un número hexadecimal (con letras minúsculas).
- X - el argumento es tratado como un entero y presentado como un número hexadecimal (con letras mayúsculas).
Siguiendo la lógica
Siguiendo la lógica, ya que estamos tratando sprintf() deberíamos plantearnos desechar el polifacético echo() por printf(), de esta forma podríamos controlar la salida por pantalla al igual que en las peticiones a base de datos. El problema de usar estos métodos de forma exclusiva nos pone en el otro diléma que todo programador tiene que tener presente, el rendimiento.
Debido a sus mayores funcionalidades y opciones, sprintf(), printf(), … consumen mayor tiempo de procesador que echo() que únicamente muestra por pantalla. Por ello debemos tener presente donde usar estas funciones y donde usar otras.
Mi recomendación
Personalmente soy partidario de usar printf(), y sprintf() para todo lo referente a datos obtenidos de fuentes externas, ya sea un XML, una base de datos, otras webs,… así estaremos controlando lo único que es fácilmente alterable. Y para datos fijos, etiquetas, estructura,… usaremos echo() que aliviarán una pizca nuestro servidor.
Ampliando la seguridad
Además del uso de sprintf() y printf() tenemos a nuestra disponsición mysql_real_escape_string(), que se encarga de permitirnos validar esos parámetros sensibles de nuestros scripts. Veamos un ejemplo de como implementarlo.
$sql = sprintf("SELECT nombre FROM tabla WHERE id = %d;",mysql_real_escape_string($numero));
mysql_query($sql);









