Manual: Autorización de imagen
Este artículo está dirigido a administradores de sistemas que desean restringir el acceso a imágenes y archivos según los permisos del usuario y/o grupo de usuarios.
Los archivos cargados generalmente son entregados directamente por el servidor web, no a través de MediaWiki. Si bien existe un nivel mínimo de seguridad a través de la oscuridad con ofuscación de ruta (por ejemplo, /c/c4/...), la ruta se puede calcular fácilmente a partir del nombre del archivo y no proporciona una protección real.
Esta no es una configuración recomendada. MediaWiki no está diseñado para ser un CMS ni para proteger datos confidenciales. Al contrario, fue diseñado para ser lo más abierto posible. Por lo tanto, no admite inherentemente una protección hermética y completa del contenido privado. Cualquier administrador que desee utilizar esta funcionalidad debe revisar cuidadosamente Security issues with authorization extensions.
Descripción general
De forma predeterminada, se puede acceder a todas las imágenes (y archivos) cargados directamente desde el servidor web. Si desea permitir el acceso sólo a usuarios autorizados dentro del marco de MediaWiki, se deben cumplir dos condiciones:
- El directorio actual debe estar protegido del acceso directo y;
- Se debe invocar la autorización de MediaWiki cuando se produce un acceso a una imagen/archivo mediante la ejecución de un script cuando se solicita cualquier URL que contenga ese directorio.
La implementación fundamental requiere:
- El directorio de imágenes ($wgUploadDirectory) debe moverse fuera de la raíz web en el sistema de archivos o protegerse de otra manera
- La ruta de carga ($wgUploadPath) debe apuntar a img_auth.php.
Los mecanismos para ambos dependen de la plataforma del servidor web. Este artículo proporciona instrucciones detalladas para dos plataformas:
- Apache (la mayoría de las versiones)
- Microsoft Internet Information Server (IIS), versión 6.0 y superior
Para todas las instrucciones, supongamos que mi MediaWiki está instalado en "/path/to".
Por ejemplo en:
http://wiki.example.org/MyWiki
"/path/to" es "/MyWiki"
¿Cómo funciona "img_auth.php"?
La autorización de imágenes funciona enrutando las solicitudes de archivos multimedia cargados a través del script img_auth.php, en lugar de permitir que el servidor web envíe el archivo directamente al navegador.
Esto se hace configurando $wgUploadPath en la ubicación del script img_auth.php ($wgUploadPath = "$wgScriptPath/img_auth.php";), en lugar del directorio de carga.
Esto hace que MediaWiki genere URL de archivos que se parecen a http://wiki.example.org/w/img_auth.php/01/01/Example.png.
Cuando el servidor web recibe una solicitud de dicha URL, sabrá que debe llamar al script img_auth.php y pasarle el resto de la URL como PATH_INFO.
El guión entonces comprobará si el usuario tiene acceso al archivo dado en el PATH_INFO, basado en el mecanismo normal utilizado para acceso gestor a wiki páginas.
Si img_auth.php determina que el usuario tiene acceso al archivo solicitado, lee el contenido del archivo y lo transmite al usuario, como si el servidor web estuviera sirviendo el archivo directamente desde el disco.
Sin embargo, si el usuario no tiene acceso al archivo, img_auth.php devuelve el error estándar 403 "Acceso denegado".
Configuración de carga de archivos
Antes de intentar esta configuración, es muy importante que comprenda cómo configurar las cargas de archivos. Tómese unos minutos para revisar y comprender este artículo: le ahorrará mucho tiempo.
Compatibilidad con PHP PATH_INFO
Esto requiere que su configuración PHP admita PATH_INFO (muchas configuraciones CGI no lo hacen) y necesita estar en modo $wgWhitelistRead o de lo contrario, no tendría sentido... a menos que simplemente desee una instalación de MW más segura. Ver abajo.
Otro escenario, motivado por la seguridad (SOLO Apache/Unix)
Incluso si no desea restringir el acceso a sus imágenes, es posible que desee utilizar el mecanismo img_auth.php: para evitar directorios de acceso público, donde el servidor web tiene permisos de escritura.
Si bien un directorio escribible en un servidor web no es inseguro en sí mismo, es la primera mitad de un ataque exitoso a su servidor web.
La segunda mitad entonces sería algún script (php) explotable, siendo MW o, muy probablemente, algún otro script.
Si el atacante puede explotar el script roto para cargar o generar otro script destinado a ayudarlo con más ataques/spam, etc., el atacante aún necesita un lugar para almacenar ese script, que pueda ser escrito por el servidor web... y lo tiene disponible y bien conocido en el directorio images de las instalaciones estándar de MW.
Una primera medida de seguridad contra esto será colocar un archivo .htaccess dentro del directorio images con este contenido:
# No hay ejecución de php en el área de carga
php_admin_flag engine off
¡Y ese .htaccess no debe ser escribible por el servidor web! Es una lástima que MW no venga con esto por defecto (al menos no en 1.6.10).
Pero aún mejor será mover también el directorio escribible images del servidor web fuera de la raíz del documento, renombrándolo con algo que no se pueda adivinar (por ejemplo, el hash MD5 de <lo que sea>) y transmitiendo las imágenes a través de img_auth.php, de modo que el nombre real del directorio nunca aparezca.
Para lograrlo siga estos pasos:
- Inicie sesión en un shell de su servidor web (acciones similares suelen ser posibles con su cliente FTP; si no, solicite ayuda a su proveedor)
- crea el directorio
images/upload, que no se puede adivinar, fuera de (en paralelo a) la raíz de tu documento (observa el/..al final de la ruta):cd </ruta/absoluta/a/su/doc_root>/.. mkdir <nombre_dir_imposible_de_descifrar>
- Hazlo legible y escribible para el servidor web:
chgrp <su_grupo_de_servidores_web> <nombre_dir_imposible_de_descifrar> chmod 770 <nombre_dir_imposible_de_descifrar>
- crea el archivo .htaccess como se indicó anteriormente y hazlo legible solo (esto es paranoia, porque el servidor web nunca mira aquí, solo PHP no se ocupa de los archivos
.ht*normalmente, pero es por si acaso este directorio alguna vez estará disponible para el servidor web directamente):cd <nombre_dir_imposible_de_descifrar> echo 'php_admin_flag engine off' > .htaccess chmod 444 .htaccess
- cambia tu archivo de configuración LocalSettings.php:
$wgUploadPath = "$wgScriptPath/img_auth.php"; $wgUploadDirectory = '</ruta/absoluta/a/su/doc_root>/../<nombre_dir_imposible_de_descifrar>'; $wgEnableUploads = true; # No queremos restringir el acceso, solo hacer que nuestra instalación de MW sea más segura $wgWhitelistRead = false;
que debería hacer lo correcto sin ninguna configuración adicional.
Esto debería funcionar para servidores web con PHP ejecutándose como un módulo Apache.
No son necesarios más cambios en el archivo de configuración de Apache.
Entonces nunca verás la ruta a tus imágenes, img_auth.php intercepta todos los accesos de lectura.
Pero se sirven todas sus imágenes, incluidas las miniaturas.
Si utiliza CGI para IIS, los resultados pueden variar.
Instrucciones de Apache
Apache Paso 1. Proteger el directorio de imágenes del acceso a Internet
En su directorio [/path/to]/images, cree un .htaccess que contenga una línea:
Deny from All
<span id="Apache_Step_2._Execute_Script_img_auth.php_for_all_Accesses">
Paso 2 de Apache. Ejecutar el script img_auth.php para todos los accesos
Paso 2.1 de Apache. Cambie $wgUploadPath por LocalSettings.php. Esto no es necesario si se realiza el paso 2.2 de Apache.
$wgUploadPath = "[/path/to]/img_auth.php";
[/path/to] es la ruta URL, no la ruta del sistema de archivos, por lo que si img_auth.php está en /usr/share/mediawiki pero se accede como http://example.org/mediawiki/img_auth.php, la línea se leería:
$wgUploadPath = "/mediawiki/img_auth.php";
Asegúrese de agregar una barra inicial / si img_auth.php está realmente en su directorio raíz.
Las imágenes no se mostrarán en absoluto si olvidas hacerlo:
$wgUploadPath = "/img_auth.php";
Paso 2.2 de Apache. Crear alias para ejecutar img_auth.php
Edite el archivo httpd.conf y agregue los dos alias siguientes:
Alias [/path/to]/images/ [/path/to]/img_auth.php/
Alias [/path/to]/images [/path/to]/img_auth.php
El segundo [/path/to] en cada línea debe ser la ruta absoluta en el sistema de archivos, y puede ser necesario agregar una barra diagonal final a img_auth.php (es decir, usar [/path/to]/img_auth.php/).
Paso 2.3 de Apache. Reinicie su servidor Apache
Instrucciones Apache sin PATH_INFO con mod_rewrite
Apache Paso 1. Descargue el script de autorización de imágenes que admite cgi
Cuando PATH_INFO no esté disponible, descargue el script de autorización de imagen compatible con CGI.
Guarde el script con el nombre cgi_img_auth.php en su directorio MediaWiki.
Paso 2 de Apache: Proteger el directorio de imágenes del acceso a Internet
En su directorio [/path/to]/images, cree un .htaccess que contenga una línea:
Deny from All
Paso 3 de Apache. Ejecutar el script cgi_img_auth.php para todos los accesos
Paso 3.1 de Apache. Cambiar $wgUploadPath en LocalSettings.php
$wgUploadPath = "[/path/to]/cgi_img_auth.php";
Paso 3.2 de Apache. Editar .htaccess
Edite el .htaccess para que se vea así
RewriteEngine on
RewriteRule ^/path/to/images(.*)$ /path/to/cgi_img_auth.php/$1 [R]
RewriteRule ^path/to/cgi_img_auth.php/(.*)$ path/to/cgi_img_auth.php?path=/$1
Sin embargo, tenga en cuenta que este paso es innecesario en algunas instalaciones.
Apache - Compatibilidad con URL limpias
Si su sitio web está reescribiendo URL a través de .htaccess, entonces necesitará una excepción antes de las reescrituras personalizadas:
RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]
(Esto significa: en caso de que se llame img_auth, hay reglas de stop)
Ejemplo de .htaccess:
RewriteEngine On
# First condition&rule:
RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]
# Rest of rules:
RewriteCond ...
RewriteRule ...
Apache - Denegar la lista de directorios
Si no desea que el usuario enumere su carpeta de imágenes, configure esto en su configuración de Apache:
<Directory /var/www/wiki/images>
Options -Indexes
</Directory>
Instrucciones de IIS
La implementación en IIS es más compleja porque carece de las capacidades de "tubería" inherentes de Apache o Unix en general. Sin embargo, utilizando algunos trucos, se puede lograr que IIS ejecute el CGI y logre protección.
 Advertencia: | El enfoque img_auth SÓLO funciona con el modo PHP ISAPI en la plataforma WIMP (Windows, IIS, MySQL, PHP). Si siguió las instrucciones de instalación estándar de Windows, su wiki utilizará CGI (php-cgi.exe) y tendrá que convertirlo a ISAPI. Las instrucciones para hacerlo se encuentran en el área de discusión. Hay un error en el enfoque php-cgi al analizar PATH_INFO que se mostrará como "Error CGI: La aplicación CGI especificada se comportó mal al no devolver un conjunto completo de encabezados HTTP" en algunos archivos en la ruta restringida. Este es un problema de PHP/IIS, no de MediaWiki. |
Paso 1 de IIS: Proteger el directorio de imágenes del acceso anónimo a Internet
Con IIS es importante que los usuarios no puedan acceder a imágenes o archivos mediante rutas URL alternativas para evitar la redirección del directorio virtual. Por lo tanto, se debe crear un nuevo directorio fuera de la raíz de MediaWiki.
Paso 1.1 de IIS Crear nuevo directorio físico
Crear un nuevo directorio físico. Este directorio no debe estar dentro de ningún otro directorio web existente ni de ningún directorio web virtual:
Ejemplo:
c:\inetpub\wwwroot\MyWikiImg
Paso 1.2 de IIS: Verificar/establecer la seguridad del directorio
La seguridad del directorio debe permitir la lectura, escritura y modificación de la cuenta de invitado de Internet (normalmente IUSR_[nombre del servidor]). No te preocupes, esto lo regularás en los pasos siguientes.
Paso 2 de IIS. Ejecutar el script img_auth.php para todos los accesos al directorio de imágenes
En IIS, esto se hace creando un directorio virtual con el mismo nombre que el directorio físico (si su directorio está fuera de la web raíz).
Paso 2.1 de IIS: Crear un directorio virtual con el mismo nombre que el directorio físico
Cree un nuevo directorio virtual utilizando Inicio->Herramientas administrativas->Administrador de Servicios de Internet Information Server (IIS) en el servicio web que esté usando para MediaWiki.
Haga clic derecho en el servicio web->Nuevo directorio virtual...
En el asistente, cree un nuevo directorio virtual con el mismo nombre que el directorio físico y apúntelo a ese directorio.
Paso 2.2 de IIS: redirigir el nuevo directorio virtual a img_auth.php
Aún en el Administrador de IIS, haga clic derecho en el nuevo directorio virtual->Propiedades, seleccione la pestaña 'Directorio virtual' y cambie 'El contenido de este recurso debe provenir de:' a 'Una redirección a una URL'. Complete el campo 'Redirigir a:' con la URL a img_auth en su MediaWiki.
Ejemplo:
http://wiki.example.org/MyWiki/img_auth.php
¡Recuerda hacer clic en Aplicar!
Paso 3 de IIS: Copiar directorio de imágenes antiguo al nuevo
Copie el contenido del antiguo directorio de imágenes ($ip/image) y subdirectorios en el nuevo directorio que ha creado.
Nota: El directorio image no existirá en el nuevo directorio.
El nuevo directorio no debería aparecer como:
Equivocado:
MyWikiImg
images
0
1
. . .
Bien:
MyWikiImg 0 1 . . .
Paso 4 de IIS Redirigir procesamiento de imágenes de MediaWiki
IIS Paso 4.1 Cambiar $wgUploadPath en LocalSettings.php
$wgUploadPath = "[NewVirtualDirPath]";
Ejemplo:
$wgUploadPath = "/MyWikiImg";
IIS Paso 4.2 Cambiar $wgUploadDirectory en LocalSettings.php
$wgUploadDirectory = "[NewVirtualDirImages]";
Ejemplo:
$wgUploadDirectory = "D:\Inetpub\wwwroot\MyWikiImg";
IIS Paso 4.3 Reinicie su servicio web IIS
IIS Paso 4.4 Solución de problemas de IIS PATH_INFO
Si su instalación no funciona, puede deberse a que img_auth.php requiere que el servidor devuelva PATH_INFO para saber exactamente a qué archivo desea acceder (por ejemplo, todo en la URL después del directorio virtual).
Han aparecido varios artículos y sugerencias de que algunas versiones de IIS pueden no permitir las variables de servidor PATH_INFO y PATH_TRANSLATE "por razones de seguridad". Si bien no tuvimos este problema en el servidor actual y el nivel de parche (IIS 6.0), es un problema conocido para IIS 4.0 (y posiblemente anteriores), es posible que desee investigar si img_auth.php no funciona para usted.
El artículo completo de la base de conocimientos se puede encontrar en Uso de PATH_INFO y PATH_TRANSLATED desde aplicaciones CGI. El artículo le indica cómo ejecutar un programa escrito en MS Visual Basic (es posible que necesite cargar CScript).