Últimas consideraciones y fallos comunes

Tabla de contenidos para Manual: Como instalar Magento en local a partir de nuestro Backup

  1. Descargar e instalar Xampp 5.6.12 para Windows
  2. Poner en marcha nuestro servidor Xampp 5.6.12
  3. Preparando el servidor Apache
  4. Últimas consideraciones y fallos comunes

Bueno pues si hemos hecho todos los pasos anteriores y una vez apache ha sido reconfigurado y reiniciado, toca retocar el archivo .htaccess en el directorio htdocs donde vaciamos el backup de nuestra tienda que en mi caso es  en /htdocs/magento/.htaccess donde buscamos la siguientes línea:

Y cambiamos la base de reescritura para que funcione con el Alias que escogimos en el paso anterior, magento en nuestro ejemplo. Debería quedar así:

Es importante no comerse el / del final. Ahora vamos con la Base de Datos. Entramos en el phpMyAdmin y nos vamos a la tabla que creamos con los datos de la de nuestro servidor. Al pinchar sobre la misma veremos que esta (o debería estar si no te corroyeron las prisas) vacía. Pinchamos en la pestaña opuesta a cuando hicimos el backup (Exportar), es decir, Importar. Seleccionamos el archivo donde tenemos la copia, y que deberías haber bajado comprimido si es muy grande, y dejando el resto como esta (comprobamos que este marcada la casilla de importaciones parciales, sobre todo si es muy grande) le damos a continuar. Ahora te puedes bajar al WC, fumar un cigarro, o llamar a un amigo por que tienes para un rato.
(más…)

Bug peligroso ante el atake de los hackers (noticia de la Web antigua)

catosino escribió

En muchos sitios esta dando vuelta la noticia de una nueva falla en el PHP-Nuke, que permite tomar el control de todo el sistema.
Pero hay cosas que muchos no tiene claro todavía, por eso aquí las explico, y doy mas detalles sobre el tema…..
Te puede descargar los archivos ya modificados AQUÍ

Primero: La falla NO es en el archivo modules.php, sino
que esta presente en los módulos Downloads y Weblinks, entre otros. El archivo modules.php solo se encarga de incluir los archivos de cada modulo para que así la URL quede mas presentable.

Por eso el advisorie:

http://www.securityfocus.com/archive/1/340664

Esta mal desde un principio. Otra cosa para aclarar, que podriamos llamar:

(más…)

Inyección de Código SQL

Modificación del comportamiento de nuestras consultas mediante la introducción de parámetros no deseados en los campos a los que tiene acceso el usuario.

La inyección SQL consiste en la modificación del comportamiento de nuestras consultas mediante la introducción de parámetros no deseados en los campos a los que tiene acceso el usuario.
Este tipo de errores puede permitir a usuarios malintencionados acceder a datos a los que de otro modo no tendrían acceso y, en el peor de los casos, modificar el comportamiento de nuestras aplicaciones.

Vamos a ver con un ejemplo que significa eso de “Inyección de código”:

Supongamos que tenemos una aplicación Web (realizada en ASP por sencillez) en la que el acceso a ciertas secciones está restringido. Para restringir ese acceso creamos una tabla de usuarios y contraseñas y sólo los usuarios que se validen contra esa tabla podrán acceder a esos contenidos. Una manera de que los usuarios se validen será colocar un par de cuadros de texto en nuestra página Web (por ejemplo txtUsuario y txtPassword) donde puedan introducir su nombre y su contraseña y enviar ese par usuario/contraseña a la base de datos para comprobar si es válido.

Primero creamos la tabla que vamos a usar y la rellenamos con datos:

Ahora veamos el código de las páginas que forman parte del proceso de login.

index.htm

Esta primera página es sencilla. Simplemente los dos cuadros de texto mencionados que enviarán los datos a la página de login.

Login.asp

 Code: arbitrary (select
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

<%
       Dim Usuario, Password, RS, SSQL
       Usuario = Request.Form("txtUsuario")
       Password = Request.Form("txtPassword")
       SSQL = "SELECT count(*) FROM Usuarios WHERE Usuario = '" & Usuario &
       "' AND password='" & Password & "'"
       Set RS = Server.CreateObject("ADODB.Recordset")
       RS.Open SSQL, "Cadena de conexion"
       If (RS.EOF) Then
          Response.Write "Acceso denegado."
       Else
          Response.Write "Te has identificado como " & RS("Usuario")
       End If
       Set RS = Nothing
%>

Y en esta segunda página creamos dinámicamente una sentencia SQL que enviamos a la base de datos para la validación.
Si el usuario escribe Admin y 1234 la sentencia creada será:

Y como esta sentencia nos devuelve un registro dejaremos que el usuario entre en la Web. Si el usuario escribe por ejemplo ‘Admin’ y de contraseña cualquier otra cosa, la sentencia no nos devolverá registros y no permitiremos entrar a esa persona.
Pero ¿qué ocurre si el usuario escribe ‘ or ‘1’=’1 como usuario y lo mismo de contraseña?
En este caso la variable Consulta contendrá la cadena:

Y obviamente esta sentencia nos devuelve registros con lo que el usuario entrará en nuestra Web sin tener permiso.
Pero esto no es lo peor. Lo peor será que el usuario utilice estos trucos de inyección de SQL para ejecutar código arbitrario en nuestro servidor. Sentencias DDL, cambiar permisos, utilizar procedimientos almacenados y un largo etcétera. Qué ocurriría si alguien escribiese de contraseña cosas como:

Cómo evitarlo

Y ahora lo más importante, ¿qué podemos hacer para evitar estos errores?
Pues hay varios sistemas para evitarlo. Por ejemplo podemos filtrar las entradas de los usuarios reemplazando la aparición de ‘ por ‘’ (dos comillas simples) e incluso evitando que los usuarios puedan pasar caracteres como / “ ‘ o cualquier otro que se nos ocurra que puede causar problemas. Estos filtros pueden ser tan sencillos como utilizar la sentencia replace de Visual Basic:

Otro factor importante en cuanto a la seguridad es limitar al máximo los permisos del usuario que ejecuta estas sentencias para evitar posibles problemas. Por ejemplo utilizando un usuario distinto para las sentencias SELECT, DELETE, UPDATE y asegurándonos que cada ejecución de una sentencia ejecute una sentencia del tipo permitido.
Por supuesto utilizar el usuario ‘sa’ o uno que pertenezca al rol ‘db_owner’ para ejecutar las sentencias de uso habitual de la base de datos debería quedar descartado.
Una solución definitiva sería trabajar con procedimientos almacenados. El modo en el que se pasan los parámetros a los procedimientos almacenados evita que la inyección SQL pueda ser usada. Por ejemplo utilizando el siguiente procedimiento almacenado:

También deberíamos validar los datos que introduce el usuario teniendo en cuenta por ejemplo la longitud de los campos y el tipo de datos aceptados. Esto lo podemos hacer en el cliente con los RegularExpressionValidator o con los CustomValidators del VB.NET. De todos modos si la seguridad es importante todas estas validaciones hay que repetirlas en el servidor.

Por ultimo, y ya que estamos pensando en entornos Web, podemos programar en ASP.NET yy utilizar siempre que sea posible las clases System.Web.Security.FormsAuthentication para que los usuarios entren en nuestras aplicaciones Web.

Ejecución remota de código PHP en phpMyAdmin

Se ha dado a conocer una vulnerabilidad en phpMyAdmin 2.x y 3.x que podría ser aprovechada por un atacante remoto para ejecutar código PHP arbitrario, pudiendo comprometer el sistema.

PhpMyAdmin es una popular herramienta de administración de MySQL a través de Internet escrita en PHP. Este software permite crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, administrar privilegios y claves en campos, exportar datos en varios formatos; y en general ejecutar cualquier sentencia SQL. Además está disponible en más de 50 idiomas bajo licencia GPL.

El fallo descubierto, catalogado como serio por el equipo de desarrollo de phpMyAdmin, está causado porque el valor de entrada pasado al parámetro “sort_by” en “server_databases.php” no se limpia de forma adecuada antes de ser utilizado. Esto podría ser aprovechado por un atacante remoto para inyectar y ejecutar código PHP arbitrario con los privilegios del servidor web, lo que le permitiría conseguir el control del sistema vulnerable. Para que el fallo de seguridad pueda ser explotado, es necesario que el atacante disponga de credenciales de autenticación válidas.

(más…)

Xoops 2.2.2 y 2.0.13.1 realizados

Recientemente se detectó que algunos archivos de Xoops podían revelar la ruta física del servidor ingresando la url del archivo directamente en el navegador.

El problema abarca tanto a la versión 2.0.13 (y anteriores) como a la reciente 2.2.1. Por ese motivo se lanzaron las correspondientes actualizaciones de aplicación inmediata.

Simplemente deben subir los archivos incluídos en las actualizaciones y todo estará parcheado.

En algunos módulos antiguos puede que este problema este presente y para corregirlo bastará con utilizar este código en el inicio de los archivos que correspondan:

if (!defined(“XOOPS_ROOT_PATH”)) {
die(“XOOPS root path not defined”);
}

(más…)

Página 1 de 212