Seguridad web para Paranoicos

La seguridad web es para paranoicos, y es lo que deberiamos ser todos y cada uno de nosotros. Aquellos que tenemos una web online. La plataforma de la cuál disertare sera la LAMP, aquellos que no saben que es le comento que son las siglas de Linux+Apache+Mysql+PhP, y el host que esta vez citaremos será CPANEL …

Bien, sigamos… Cuando diseñamos un sitio en joomla, wordpress … , muchos nos preocupamos de cómo quedara el mismo, y buscamos los componentes y modulos, plugins… para crear un joomla / wordpress u otros, que nos dignifique y que en cierta manera alimente nuestro ego, pero nos quedamos ahí, porque poco hacemos por la administración y seguridad de nuestro sistema.

Es mejor ser un Paranoico de la seguridad web

Solemos confiar en las bondades de Cpanel, y en la maga de nuestra memoria, pero no hacemos los respaldos importantes en la zona critica de nuestra web, que son los directorios que descansa nuestro joomla, además de dejar contraseñas por defecto, cuando en realidad debemos trabajar muy seriamente en este tema. Porque la puerta de su casa , la puede dejar abierta , pero quedese tranquilo, que entrarán por ella, y no justamente  sus amigos.

Siguiendo el ejemplo de solojoomla, podemos deducir que user de solojoomla son los primeros digitos de creada la cuenta, lamentablemente este fantastico soft ( cpanel ), trabaja creando cuentas preprogramadas, con digitos de 8 caracteres, asi que podemos llegar a pensar que la admin de cpanel de nuestro amigo redlo es solojoomla , nos queda la clave, que estoy seguro que nuestro estimado administrador creo una llave segura, para evitar invitados NO DESEADOS.

Invito a uds, a generar sus propias llaves simetricas que recomende en su día, y en este caso, usemos todos el mismo ejemplo que cito aquí, para comprender como debemos operar con este pequeño script, en primer lugar en username colocaremos estas palabras sqGhAbC6PfVw ( recuerden, tomenlo de ejemplo ), en la parte de encripción podemos asignar la siguiente clave mamacora.

Si hizo las cosas bien seguramente obtendra esta clave itQYPL7CtNO3c, bien el tema es el siguiente en su Username tiene que usar letras y números como el ejemplo (itQYPL7CtNO3c ) y en el pass tiene que usar claves del estilo (  jz77sK49A6TfU ) , si tomamos de este ejemplo la clave ( itQYPL7CtNO3c ) como username y cambiamos la clave , obtendremos una clave fuertisímas de quebrar a traves de fuerza de diccionario, por no decir infranqueable..

Señores, usen claves de este estilo para su Cpanel o Plesk, para su administrator de joomla / WordPress si volvemos a solojoomla encontraremos en la ruta https://www.solojoomla.com/administrator/ encotraremos en famoso admin de joomla no hace falta decir que tendremos que haber cambiado el username que vienen por defecto en la instalacion por algo robusto como tambien su clave de acceso, recomiendo que usen lápiz y papel, ademas de abrir una cuenta  google y generar un archivo doc, para todos sus username y pass y subirla a ella, eso sí tiene que ser secretísima.

NADIE ,debe saber de ella, sea paranoico, que solo los paranoicos sobreviven..Recuerdelo.

Ahora de nuevo , quiero saber si Redlo, en que descansa su sitio que tipo de respuesta me devuelve para https://www.paramiweb.com/hola configuro un 404 para no saber en que versión corre el cpanel instalado, ya volveremos a él..

En este punto vale la aclaración de no permitirse el listado  contenido de directorios: A veces ponemos www.bazarsocial.com/scripts/ y el resultado es una lista interminable de scripts que muchas veces no funcionan y al tratar de ejecutarlos terminan arrojando errores que indican la ruta donde está instalada la página web dentro del sistema.

Un niño metido puede incursionar en el arbol /home/usuario/, lo cual le dara una hermosa forma de visualizar el nombre de la cuenta de usuario bajo la cuál corre la página  página web.  En este caso podemos solucionarlo con crear un index. html  sin nada en todos los directorios para que nadie husmee el contenido de su directorio.

Pero tengo algo más sencillo, que en esta ocasión sugiero visitar https://cooletips.de/htaccess/ , para aquellos que no saben hacerlo por si mísmo el cambio del htaccess, cuando cree el suyo , este seguro de usar su programa de ftp favorito , para cambiar el que viene por defecto en joomla, pero hagalo si esta seguro, si no deje las cosas como estan, que con el tiempo lo lamentara..jja..

Estas pequeñas modificaciones, haran que su mente tenga más presente el tema de seguridad. No olvide cambiar sus pass de sus correos electronicos, en cpanel tiene multiples soft para operar como servidores de correo, recomiendo HORDE, sobre todo, en el caso de los cpanel tenemos la siguiente dirección  http://www.xxxx.com:2095/, recuerde siempre que si NO se ocupa de su novia , otros se ocuparan de ella.

No se lamente después. En el caso de nuestra base de datos, por favor, use clave de root para su MySql, en lo personal NO recomiendo usar php admin , pero si le hace fácil la vida, recomiendo que use claves como le explique al directorio php/admin., recuerde que la mayoria de los ataques a sitios de joomla van directamente a la base de datos del cpanel.

No subestime a su oponente, use como estrategia la prevención con la menor perdida posible, haga backup completos de su sitio en forma semanal.

Algoritmos

Debo comentarle que las bases de nuestro joomla descansan en las bondades del MD5 que es un algoritmo. Se trata de uno de los mas populares algoritmos de generacion de signaturas, debido en  gran parte a su inclusión en las primeras versiones de PGP.

Este procesa los mensajes de entrada en bloques de 512 bits, y produce una salida de 128 bits. Siendo m un mensaje de b bits de longitud, en primer lugar se alarga m hasta que su longitud sea exactamente 64 bits inferior a un multiplo de 512.

El alargamiento se lleva a cabo anadiendo un 1 seguido de tantos ceros como sea necesario. En segundo lugar, se añaden 64 bits con el valor de b, empezando por el byte menos significativo. De esta forma tenemos el mensaje como un número entero de bloques de 512 bits, y además le hemos añadidod información sobre su longitud. Seguidamente, se inicializan cuatro registros de 32 bits con los siguientes valores hexadecimales 1:

A = 67452301

B = EFCDAB89

C = 98BADCFE

D = 10325476

Bueno no me extendere más en este asunto , en otro momento quizás lo detalle en profundidad  lo explicado es una breve reseña de cómo opera este algoritmo.  Ahora bien, todo muy lindo, pero este algoritmo puede ser atacado por fuerza de diccionario a través de la siguiete página tenemos un claro ejemlo https://md5decrypt.net/en/, y verán como su clave cifrada en joomla, es descubierta.

Por eso , volviendo a la cuenta google, usela  para guardar el archivo configuration.php que es el corazón de su joomla, renombren ese archivo, a poemas.txt , y guardelo, si pasa algo con su base datos solo tiene que descargarlo , renombrarlo y subirlo de nuevo al servidor.

Tenga cuidado lo que instala en su Joomla, vaya a lo seguro, pero nada es seguro, pero entre lo medio elija siempre lo mejor, por eso evite subir componentes o modulos que hacen vistosos su diseño pero que no tienen las actualizaciones pertinentes, porque curiosamente al creador se le murio el perrito ayer , y tiene una gran depresión y no volverá hasta dentro de un año, así que por favor, sea cauteloso, no carge su joomla, sea prudente.

Recuerde: del otro lado hay chicos con acne que estan jugando con exploits para dañarlo. Por eso, busque ESTAR SIEMPRE ACTUALIZADO, tanto en su joomla como sus componentes y modulos.

Hagame caso. Evitara problemas. Podrá disfrutar de su bien más preciado: SU TIEMPO, se lo agradecerán su esposa, sus hijos, amigos, familiares y los etcétera. Por eso, no use la misma clave para su administrador de joomla, ni para su cpanel , ni para su base de datos, rote las claves, cambios mensuales.

Si sigue con su tesitura de usar las mismas claves para todo entonces es probable que tenga ataques de inclusión remota de archivos para mostrar el contenido de los scripts de configuración con los datos de las bases de datos.

Recuerde lo que explico aquí es para que ustedes, reserven su  su preciado tiempo, me tome el trabajo de escribir este post , para regalarle a una forma amena de proteger su sistema.

Les sugiero que si trabajan con php, aquellos usuarios que conocen del hiperlenguaje habiliten la seguridad en php ini, puede traerle graves problemas de cabeza si el mocoso del otro lado juega con ataques remotos , por eso , tenga la certeza de haber habilitado las siguientes directivas

php_expose=off y safe_mode=on.  

En este ultimo si el muñequito con acne y lentes grandes, puede acceder a través de un script, que permita inclusiones al system cat/etc/shadow , lo cual devolveria las contraseñas cifradas. Por eso es de suma importancia la necesidad de sustituir todos los protocolos en claro por equivalentes cifrados.

Conclusiones

Deben ser memorizadas

Una contraseña jamás debe ser escrita en un papel, por razones  obvias.

Suficientemente complejas

Una buena contraseña debe constar de al menos ocho letras. Pensemos que si empleamos  únicamente seis caracteres alfanumericos (números y letras), tenemos _unicamente unos dos mil millones de posibilidades. Teniendo en cuenta que hay programas para PC capaces de probar más de cuarenta mil claves en un segundo, una clave de estas características podrán  ser descubierta en menos de 30 horas.

Carecer de signifícado

Una contraseña jamás debe significar nada, puesto que entonces aumentará la probabilidad de que aparezca en algún diccionario. Evitemos los nombres propios, en especial aquellos que pertenezcan a lugares o personajes de historias o ficción.

Deben ser modicadas con frecuencia

Es muy recomendable que nuestras contraseñas sean cambiadas en forma periodica , si sospecha de algo cambie las clave urgentemente.

Esta ley es para todos los programadores web o aquellos administradores de redes: “ los potenciales clientes no compran el talento que tiene para hacer lo que hace. Compran el talento que tiene para ser quien es “. Por ende, trasmita que ud es definitivamente bueno en lo que hace. Esto significa que lo que Ud, vende, es su honestidad..

Para reducir al mínimo problemas de seguridad usted debe realizar una actualización regular de todo su software de servidor, incluyendo Joomla / WordPress / Drupal / Prestashop etc…

Los nuevos problemas de seguridad se encuentran todo el tiempo, y los reveladores de cada paquete de programas informáticos remiendan los usos para cerrar debilidades . Mantenga sus versiones al día,  de todas las extensiones que usa para su portal en Joomla, de esta manera sea menos vulnerable a los ataques.Ahora tocaremos los Tipos de ataque. 

Tipos de ataque

Libros enteros se han escrito en aspectos de cortar ataques, así que una lista completa está más allá del alcance de este éscrito. No obstante, hay un número de métodos comunes del ataque ( ataque mediante fuerza bruta sobre las contraseñas, SQL Inyección, cross-site scripting, y así sucesivamente) que es extremadamente extenso.

Cualquier admininistrador que trabaje con portales CMS debe tener por lo menos una comprensión de paso de cómo trabajan.

Las secciones siguientes proporcionan una breve descripción de las estrategias ordinarias usadas por los llaneros del espacio para acceder o para criticar un sistema.

La idea de este trabajo es que usted aprenderá cómo configurar su web server, el sistema del PHP, y la instalación de Joomla para reducir al mínimo la probabilidad de la penetración por éstos u otros métodos. Si usted quiere obtener más detalle en esta área de asunto, mucha de información sobre seguridad del Internet está disponible con une el equipo de la preparación de la emergencia de la computadora de los estados (US-CERT).

Hay muchos publicaciones libremente disponibles para los usuarios técnicos y no técnicos que son accesibles en el Web site de US-CERT (http://www.us-cert.gov). 

Ataques mediante fuerza bruta

Hoy los programas que intentarán practicar una apertura de seguridad de un sitio con ataques automatizados de “fuerza bruta” contra el sistema de la contraseña. Lo más comúnmente posible, estos ataques se realizan usando un diccionario de términos comunes y de contraseñas comunes.

Es siempre asombroso descubrir cuántos usuarios utilizan la palabra “contraseña” o “1234” como su contraseña del sistema. Un método de promover la buena usuario-selección de contraseñas seguras es animar a travès  de estas pautas:

Hacer una contraseña por lo menos de siete caracteres largos.
Minúsculas mayúsculas y del uso no cotidiano.
Siempre incluya caracteres numéricos. 

Los usuarios deben incorporar dos palabras y un número en sus contraseñas. Si una de esas palabras es no-Inglesa (quizás incluso “Joomla, WordPress, Drupal, Prestashop etc… «), las ocasiones de un diccionario o el ataque de la fuerza bruta que tiene éxito casi es nada.

En las películas de Hollywood, los “piratas informáticos” utilizan técnicas como el método de la fuerza bruta para romperse en una cuenta de solo usuario, pero los piratas informáticos verdaderos son mucho menos remilgados.

La mayoría de ataques con aciertos considerados que utilizan ataques de diccionario no varía la contraseña tanto como el username. Puesto que la palabra “contraseña” es tan común, que un llanero espacial trabajarra con sus programas con esta contraseña contra una lista de usuario para ver si cualquier persona tiene una cuenta con esa llave de entrada.

Por lo tanto, es recomendable blindar su lista de usuario del acceso general. 

Inyección del SQL

Una de las formas mas comunes y más eficaces de ataque en Internet es el ataque de la inyección de SQL. En un ataque de inyección, un pirata informático intenta enviar código desautorizado del SQL con una pregunta sin filtro de SQL.

El código del SQL del pirata informático puede hacer cualquier cosa y permite que la información que viaja en forma segura se vuelva a ejecutar con un procedimiento destructivo.

Con precauciones básicas, se puede proteger contra este tipo de violación de la seguridad.

La regla empírica básica para la protección contra la inyección es asegurarse de que su código del programa nunca confía en las informaciones en bruto pasajeras de un proceso exterior (incluso si ese proceso es una forma que usted ha creado). Todas las informaciones en bruto aceptadas fuera del sistema deben ser procesadas y ser validadas antes de que sean utilizadas por el uso. 

Campos sin filtro del texto

Por ejemplo, una forma del HTML puede aceptar un campo para un nombre. Mientras que un usuario normal entraría en un simple el nombre en el campo, el pirata informático inyecta código del SQL en la declaración que altera la ejecución de la pregunta. Si el código del PHP para la pregunta puso el nombre incorporado en el $name variable y preguntado con él, el código para la secuencia de la pregunta pudo mirar algo similar:

$sql = “Select * From jos_users Where name = ‘“ . $name . “‘;”;

El pirata informático incorporaría simplemente un apellido que leyó como sigue:

Select * From jos_users Where name = ‘dummytext’ or ‘a’ = ‘a’;

El código del SQL generado de este valor leería como sigue:

Seleccione * de los jos_users donde dummytext del nombre = del `o a del `= a’; del `

Cuando se ejecuta la pregunta, la prueba del ‘a’ = ‘a’ delvolvería un valor verdadero para cada fila, y la pregunta devolvería la lista de usuario entera. Esto sigue: cualquier código válido del SQL puede ser inyectado, como se muestra aquí:

dummytext’; Drop Table jos_users; Select * From jos_polls Where title = ‘

Ese código destruiría la tabla de usuario de Joomla enteramente. El envío del texto de entrada de la forma con una rutina de proceso simple eliminaría cualquier peligro de tal ataque. 

Manipulación de campos del texto en Joomla y el PHP Joomla

Incluye rutinas para generar los caracteres de escape para cualquier carácter que no se pueda almacenar correctamente dentro de una secuencia de la base de datos.

Por ejemplo, el apóstrofo (`) no se puede almacenar sin la modificación en una declaración estándar del parte movible del SQL. Por lo tanto, una secuencia de escape proporcionada por la barra (\) el carácter en los sistemas de MySQL permite que los caracteres especiales sean incluidos. Así, una barra seguida por la regla (\ ‘) almacenaría el apóstrofe en un campo de la base de datos.

Creando una secuencia de escape de la secuencia user-supplied invalida el ataque de la inyección porque el apóstrofe se toma no más como carácter literal para la ejecución del SQL.

En lugar, la cotización (y cualquie código que fuera pensado para la inyección) se almacena simplemente como parte de la secuencia. El resultado probable de tal secuencia de la pregunta sería la vuelta de un error, puesto que no se encontraría ningunos sentencias que emparejen ese valor.

Para el código recto del PHP, usted puede en lugar de otro utilizar un método base de datos-específico de generar una secuencia que cree los códigos de salidad para los caracteres especiales.

Para MySQL, el PHP incluye mysql_real_escape_string () función. Puede ser utilizada para dar formato a una secuencia como esta:

$name = mysql_real_escape_string ($name);

Joomla proporciona un método abstraído llamado getEscaped () que vuelva la secuencia escapada sin importar la base de datos este en blanco. Aunque Joomla apoye actualmente solamente MySQL, en el futuro cuando más fuentes de datos se agregan, código usando el método de Joomla en vez del PHP directo todavía trabajarán correctamente.

Usted puede conseguir la secuencia escapada del objeto de JDatabase como esto:

$db =& JFactory::getDBO();
$name = $db->getEscaped($name);

Si el primer ejemplo del ataque de la inserción del SQL fuera escapado, generaría la secuencia inofensiva siguiente:

dummytext \ ‘o \ ‘a \ ‘= \ ‘a

El segundo ejemplo parecería esto:

dummytext\’; Drop Table jos_users; Select * From jos_polls Where title = \’

Hay una característica en el PHP conocido como “magic quotes” que agregan automáticamente barras a todos los campos de la entrada recibidos de una fuente exterior (tal como un web browser).

En la versión 6 del PHP, se ha eliminado la opción magic quotes. Por lo tanto, es mejor cifrar la salida manual que procesa como se muestra de modo que su código funcione con seguridad en los servidores del PHP en el futuro sin la modificación. Campos Untyped Otra forma de ataque de la inyección puede ocurrir cuando los valores que no se escriben (fijan para ser un número entero, un flotador, y así sucesivamente) se pasan directamente al motor de la base de SQL.

Por ejemplo, un valor de la identificación recuperado de una secuencia de la pregunta se pudo pasar directamente en una pregunta del SQL con una línea como esta:

$sql = “Select * From jos_users Where id = “ . $id . “;”;

El mismo tipo de código de la inyección se podía utilizar como la secuencia unescaped:

1; Drop Table jos_users;

Por lo tanto, siempre que usted acepte valores de una secuencia de la pregunta o forme la fijación, esté seguro de escribirlos a través del PHP. Por ejemplo, para escribir  el $id en un número entero, usted podría utilizar el código siguiente del PHP:

$id = intval($id);

El código escrito francamente eliminará automáticamente cualquier código de inyección incluido en el campo, o generará un error cuando el código haga su intrusiòn. Si usted utiliza el JRequest:: getVar () o JRequest:: consiga () los métodos para obtener la forma y para preguntar la secuencia de  los datos, esta forma protege su sistema ya porque estas funciones proporcionan un filtro seguro de todos los datos entrantes. 

Cuestiones requeridas – especialmente con Ajax

Los ataques de la inyección del SQL no sólo vienen a través de las páginas de la entrada. Cada vez más, los Web sites están ejecutando la tecnología de Ajax que hace las peticiones de los datos del sistema que bordean la mayoría de las rutinas comunes de validación de datos.

Eso significa que la explosión del uso de Ajax abre una gran variedad de puntos potenciales de la violación de seguridad. Por lo tanto, la especial atención debe ser prestada a las porciones de un sistema que proporcionan respuestas a las preguntas de Ajax.

Al diseñar a un respondedor de Ajax, hágase las preguntas siguientes: ¿El me escribiò todos los datos de la petición? – Cada fragmento de información que viene del exterior debe ser procesado y ser escrito.

Eso prevendrá casi toda clase básica de ataque de inyección. Los límites se deben también poner en secuencias para evitar que cualquier clase de comportamiento extraño en su sistema lo haga vulnerable. Ningún apellido debe ser más de 50 caracteres, tan a porqué no ajuste la secuencia a esa longitud ¿prevenga la entrada falsa?

¿Debo limitar el alcance de los datos accesibles?

Por ejemplo, un componente de Ajax puede proporcionar a Exhibición del WHOIS que demuestra el país de orígen del usuario. Sin embargo, la pregunta se hace de la tabla entera del contacto donde un ataque de la inyección del SQL podría revelar posiblemente la información personal tal como una dirección de comienzo de la pista en disco.

MySQL apoya una opinión de la tabla que proporcione un filtro para los datos de la tabla. Incluyendo solamente los datos usados por el componente de Ajax en la visión de registros, incluso una penetración revelaría no más que la información disponible.

¿Es esta la información que usted quiera proporcionar con Ajax?

Muchas compañías hacen directo disponible Ajax pide bases de datos o catálogos enteros. Sin embargo, un programa simple se puede construir a haga las peticiones secuenciales al respondedor de Ajax y coseche toda la información en la base de datos. Asegúrese de que usted entienda los datos que usted expondrá o un competidor puede utilizar su poseer la base de datos para su ventaja competitiva.

Éstos son apenas algunas de las consideraciones que usted debe examinar en esta nuevos comienzos en la  puesta en práctica de Ajax. Recomiendo que si tiene interes en usar esta nueva nueva tecnología recuerde: que esta latente la amenaza de que pueda recibir un enorme número de violaciones de la seguridad antes de las debilidades del sistema se entienden y se puedan protegen.

Como toda tecnologìa nueva no hay un profundo estudio sobre sus injerencias por eso si piensa ejecutar una solución de Ajax, esté seguro de leer la mayoría de la literatura actual de la seguridad de modo que usted pueda entender las más nuevas amenazas del pirata informático.

El cross-site scripting es un método de insertar algunas referencias del código o del objeto del Javascript de la ejecución en el HTML cifra cuando un redactor del HTML se pone a disposición el usuario. Este código puede abrir una ventana ocultada en el usuario los artículos del sistema y del expediente tales como nombres del usuario y contraseñas entraron en otras ventanas de vista.

Puesto que ocurre esta vulnerabilidad cuando un sitio permite el contenido usuario-fijado (una piedra angular del Web 2.0 interacción dinámica), es muy peligroso y debe ser guardado contra estos futuros ataques. Estos tipos de ataques pueden ser controlados cuando se intentan a través del interfaz utilizador de Joomla.

Sin embargo, el predominio de las extensiones disponibles que permiten la entrada del código del HTML (de libro de visitas, foros y componentes que inserten comentarios) significa que usted debe estar en la alarma a prevenir estos tipos de ataque. Asegúrese de que cualquier nueva extensión filtre las etiquetas usadas con este método de ataque (principalmente y) antes de que usted despliegue la extensión en su sitio.

Vale recordar que Twitter una plataforma que utiliza el microblogging cayo en las redes de  un joven newyorkino de 17 años creó un gusano que sembró el pánico en Twitter. El exploit explotaba la vulnerabilidad de tipo cross-site scripting creando miles de tweets automáticos desde las cuentas infectadas.
Según comento el joven Mikkey, lo hizo por mero aburrimiento y por su buena fé ( jajaja ) ,reportó el problema a Twitter. Aunque dicen las malas lenguas que trataba de demostrar que su site StalkDaily.com erá mejor que el original.

Como veran este chico en sus palabras llama aburrimiento, yo lo llamo un retrorago mental, porque en vez de joder con Twitter pensarìa màs en violar la seguridad de un banco. Broma, este tipos de pendejos , son los que citaba mas arriba de este contnido, ellos no tienen la màs palida idea de horas de trabajo  y sueños-.

Igual , es importante aclarar No es la primera vez que Twitter tiene problemas de seguridad, ya comentamos en el blog que fue un enero negro para Twitter, entre el phishing y el robo de credenciales mediante ataque de diccionario.

Después en marzo salió otro ataque por virus via XSS que forzaba a los usuarios logados a postear mensajes. simplemente pinchando en un link. Twitter, da la sensación de ser muy poco robusto y no paran de salirle bugs. Si comparamos el historial de Twitter con cualquier servicio de Google, la diferencia deja muy mal parado al servicio de micro blogging.

Entre esto y detalles como cambiar sobre la marcha de Ruby-On-Rails a SCALA, Twitter da la sensación de tener un grado de ‘amateurismo’ superior a cualquier proyecto universitario colgado en sourceforge. Para seguir con el tema PHP tiene algunas funciones incorporadas que puedan ayudarle. La función de los strip_tags () revelará todas las etiquetas del HTML, de XML, y del PHP de una secuencia pasajera y volverá el texto crudo.

Esto se puede utilizar muy eficazmente si su uso no está contando con el formato de texto rico como entrada. Para el formato, usted podría utilizar BBCode, se deja que inafectado por esta función.

Los htmlentities () funcionan en el PHP convertirán todos los caracteres no-alfanuméricos (tales como cita marcas, mayores que muestras, y así sucesivamente) al formato del HTML. Usted puede también utilizar expresiones regulares para pelar todo de campos de la entrada excepto caracteres alfanuméricos. Para un campo del apellido, usted puede ser que utilice a la declaración tiene gusto de esto:

$myString = preg_replace(“/[^a-z 0-9]/i”, “”, $myString);

Exploración de directorio

Muchos web server tienen la opción fijada para permitir el directorio que hojea. Sobre una conexión del HTTP, un visitante puede hojear a un directorio y ver todos los archivos contenidos allí, a condición de que no hay default.htm, default.asp, index.html, o archivo de index.php encontrado en el directorio.

El directorio que hojea está deja abierta la invitación para que REDLO descubra mucha de información sobre su sistema. Todo de nombres de fichero de la configuración a la información de sistema general puede ser docto si ese pirata informático tiene conocimiento del  USO de anfitrión y lógicamente del sistema operativo.

Por abandono, la mayoría de los web server ahora tienen esta opción inhabilitada. Si su sitio es recibido en un servidor más viejo, esté seguro de comprobar que este directorio no está fijado.

Esta forma de cortar es más probable ser realizada manualmente por un pirata informático, puesto que el conocimiento completo del administrador se debe utilizar para reconocer la debilidad de un sistema.

Si recomiendo, y hacerlo en forma manual a todos aquellos que necesitan saberlo que como medida preventiva, Joomla incluye un archivo simulado de index.html en cada directorio del sitio y sub-directório del sitio para prevenir esta intrusión posible.

Igual cerciorese observando cada directorio y subdirectorio, no peque de inocente, hagalo. Se ahorra dolores de cabeza y podra usar su tiempo disponible para disfrutarlos con sus seres queridos.  La mayoría de las extensione y  plantillas, sin embargo, no hacen este tipo reprogramado por eso tome esta medida preventiva, como usted debe hacer con todas las agregaciones que usted cree para el sistema de Joomla. 

Negación del ataque del servicio (DOS)

La negación del ataque del servicio (DOS) es una tentativa de negar uso del servidor o del otro recurso a los usuarios autorizados. La forma más común de este ataque inunda simplemente un ranurador o un servidor con tan muchas peticiones que la máquina está abrumada y no puede responder a las peticiones auténticas.

En otro ataque común del DOS, se hace una tentativa de forzar un reajuste del servidor o del ranurador, que hacen los recursos inasequibles durante el proceso de recomienzo. Por supuesto, una vez que el reajuste es completo, las peticiones del atacante otro reajuste y continúan repitiendo este proceso.

Para prevenir el seguimiento de los piratas informáticos y también alcanzar una masa crítica de peticiones falsas, el ataque del DOS se pone en marcha a menudo con un virus o un gusano que separe el código que ataca a las computadoras inocentes. Esto se conoce como negación distribuida del ataque del servicio.

En una hora y una fecha particulares, el código activa y las computadoras previamente amistosas atacan simultáneamente al blanco La mayoría de los ataques del DOS se deben desviar en el nivel del hardware, así que si usted está funcionando con el servidor de anfitrión, estén seguros de tener un buen firewall en el lugar.

Los firewall especiales conocidos como cortafuegos reconocerán automáticamente la diferencia entre el buen tráfico y el tráfico del DOS, y evitarán que el tráfico inválido sea pasado sobre la red.

El filtro picofaradio llamado programa del paquete de OpenBSD apoya una característica llamada el synproxy que se sienta entre un servidor y un tráfico de Internet. Realiza el mismo papel que un cortafuego en el bloqueo de tráfico falso. Usted puede encontrar más información sobre el picofaradio en http://www.openbsd.org/faq/pf/

El saber del http

La naturaleza de los medios de comunicación del Web la información enviada y recibida se analiza en pequeños pedazos de paquetes llamados datos y de la difusión sobre Internet.

Los paquetes encuentran de manera eventual la difusión a la computadora que será el ataque directo, pasando a través de una variedad de computadoras y de ranuradores antes de que alcancen sus destinaciones. Esto hace posible para una computadora que se sienta en alguna parte entre el locutor y el blanco a la copia o “para oler” los paquetes que pasan cerca.

Los datos del Web se envían y se reciben en el formato del HTTP encapsulado dentro de los paquetes. Un succionador del HTTP (EffeTech El succionador del HTTP, por ejemplo) recolecta y descifra los paquetes que contienen la información en el protocolo del HTTP. El succionador después reconstruye la sesión de HTTP y puede los archivos abiertos y los datos que intercepta.

Para un sitio de Joomla (o cualquier otro sitio que tenga una conexión unencrypted), un succionador del HTTP puede potencialmente interceptar la información incorporada del username y de contraseña.

Para un despliegue del Internet de Joomla, es bastante poco probable (y muy difícil) colocar un sniffer en línea para hacer tal interceptación posible. En un intranet de Joomla funcionado en una red de área local, sin embargo, las oportunidades y los puntos de la penetración se aumentan grandemente.

En esas circunstancias, usted puede ser que considere comprar un Security Certificate del SSL para permitir la encripctación del tráfico entre una ruta y el web server.

Compruebe hacia fuera el Web site de Verisign (www.verisign.com) para saber si hay una explicación completa de cómo los certificados trabajan y la manera que proporcionan la encripción de datos. Una vez que usted tiene un certificado del SSL instalado en su web server, usted debe poder tenerle acceso con un URL como https://www.example.com. La dirección de https:// representa el “HTTP seguro.” El puerto del defecto usado por https:// está 443 en vez del puerto 80 para la interacción normal del Web. 

Seguridad del web server

El nivel más bajo del ataque y de menos lugar probable para la penetración es el web server. Apache Web Server y Microsoft IIS están recibiendo literalmente millones de Web site con pocas aperturas publicadas.

Aunque tal adopción extensa no prevenga la posibilidad de un problema de seguridad, los servidores están muy bien eliminando errores y protegiendo los sistemas mediante actualizaciones. Apache es incluso menos probable ser el vector de un ataque, puesto que la ejecución de las escrituras del Web (tales como PHP o Perl) no es manejada por el web Server en sí mismo.

Puesto que los motores de la ejecución de la escritura son quizás lo más directamente posible los vulnerables al ataque, el Apache Web Server en sí mismo no hace que mediar con ataques de forzamiento.

Apache Server, fuera del sistema, es extremadamente seguro. Puesto que Apache funciona en grandes proporciones en los web server del mundo, se ha probado y se ha sondado de cada que manera. Por lo tanto,el sistema apache ofrece ciertas cambios aparentes,los ajustes de la configuración que ofrecen son muy solidos.

No obstante, hay algunos lugares en donde usted puede agregar seguridad un poco adicional. Aunque Apache sea muy seguro por abandono, puede fácilmente ser hecho inseguro por una opción pobre del ajuste.

Por lo tanto, esté seguro de dar el estudio detallado antes de que usted corrija ajustes de defecto uces de los. configuración de .htaccess Con Apache Server, los permisos del archivo y de la carpeta se pueden almacenar en un archivo llamado .htaccess. Acceso el permiso, la protección de contraseña, el PHP que bloquea, y otros ajustes de la seguridad se pueden especificar en el archivo.

Debido a la posibilidad disponible a través del archivo, Apache incluye (por defecto) una configuración para hacer el archivo inaccesible fuera del sistema a través de un ruteador. Los usuarios de Joomla utilizan generalmente el archivo de .htaccess para fijar los permisos para permitir el uso del mod_rewrite a cree los URL amistosos del Search Engine (SEF).

La instalación de Joomla incluye los htaccess usables que archivan htaccess.txt nombrado que usted pueda activar para la permisión del mod_rewrite si su sistema no se fija actualmente para utilizarlo.

Para activarlo, retitule simplemente el archivo de htaccess.txt a .htaccess en lugar de otro. En Windows, el interfaz del archivo del explorador no permitirá que usted retitule un archivo a un nombre de fichero vacío con una extensión (que es cómo .htaccess aparece al sistema).

Usted puede cualquiera agregar un directorio a el archivo de httpd.conf para buscar el archivo del acceso debajo de un diverso nombre o usted puede abrir el comando la ventana y utiliza el comando del ren.

Directorio de ServerSignature Cuanto más información que un pirata informático caso Redlo obtiene sobre su sistema, más exactos los métodos que él o ella puede usar contra su sitio. Mientras que será bastante obvio para Redlo conocer que tipo de web server hace funcionar con, proporcionando información adicional tal como el número de versión, el sistema operativo, y así sucesivamente, no está en sus mejores intereses.

Desafortunadamente, mucha de esta información es proporcionada por el ServerSignature siempre que el servidor genere una página (tal como un mensaje de error de servidor). La adición del directorio siguiente a su archivo de httpd.conf apagará la firma hecha salir: ServerSignature apagado.

Directorio de ServerTokens

Mucha de la información suministrada por la firma también se devuelve con cada petición de página. El directorio de ServerTokens le deja fijar la cantidad de información sobre el servidor para proporcionar la petición de página.

Hay seis ajustes disponibles para este directorio. En orden decreciente, éstos incluyen por completo, OS, mínimo, de menor importancia, principal, y golpecito. Usted debe agregar un directorio para proporcionar la menos información, como esto: Golpecito de ServerTokens Negación del acceso a las extensiones de archivo-

Un rasgo de seguridad provechoso incluido en Apache es la capacidad para negar el acceso a los tipos particulares de archivos de un web browser.

Usando esta capacidad, usted puede negar el acceso exterior a cualesquiera tipos de archivo que no tengan ninguna razón para ser tratado por un visitante (tal como archivos de .log). Su archivo del defecto httpd.conf debe contener una entrada para negar un acceso del visitante al archivo de .htaccess. Examinando el archivo de configuración, usted debe ver un código como este:

<FilesMatch “^\.ht”>
Order allow,deny
Deny from all
</FilesMatch>

Esta orden permite, negar a los ojos de todos cualquier archivo de su Joom. Este código dice a Apache negar el acceso del visitante a todos los archivos de .htaccess (y a los archivos de .htpasswd, también). Para negar el acceso a los ficheros , usted puede copiar la sección anterior y después modificar la declaración de FilesMatch como esto:

<FilesMatch ~ “\.log$”>

Para negar a todos los visitantes tener acceso a un directorio particular, usted necesitan utilizar el elemento del directorio como esto:

<Directory ~ “C:/Program Files/Apache Software
Foundation/Apache2.2/htdocs/libraries”>
Order allow,deny
Deny from all
</Directory >

Ejecute una orden que niegue a todos los visitantes que puedan tener acceso a archivos en \ directorio o subdirectorios. Genere una página 403 prohibido o 404 para remitir a su visitante nuevamente  a la portada de su sitio. Niegue, Niegue, Niegue. Sea malo. Muy malo..Es su sistema, AMELO COMO A UN HIJO.

Seguridad de PHP

La seguridad del PHP será probablemente la tecnología más importante del servidor a asegurar porque es la más vulnerable al ataque y también tiene un número de configuraciones administrativas que puedan abrir a los agujeros de seguridad.

Si un atacante puede ejecutar con éxito código de la escritura fuera de limitaciones estrechas, hay el gran potencial que el bandido puede tomar a control total del sistema. El primer paso en la reducción al mínimo de peligro potencial a su sistema se está asegurando de que no hay archivos en su servidor que llaman la función del phpinfo ().

Mientras que esta función es magnífica para examinar su sistema y determinando ajustes de la configuración, puede proveer de un pirata informático una ventana completa en su sistema del PHP. Esa información puede dar pistas en exactamente cómo una apertura de su sistema pudo ser realizada.

Después de que usted se haya cerciorado de que su servidor no se expone, hay un número de directorios del PHP que pueden sellar encima del servidor para asegurarse de que no es una blanco prometedor para el pirata informático que visita nuestro sitio.

Aunque un servidor de Joomla pueda funcionar correctamente sin estas precauciones de la seguridad en el lugar, usted potencialmente se ahorrará mucha bronca , muchos dolores de cabeza, si usted se asegura de que su servidor de Joomla esté configurado con seguridad.

En la versión 6 del PHP, tres características comunes (globals del registro, magic cuotes, y modo seguro) han sido eliminado. En el caso de magic cuotes (véase la sección “inyección del SQL” anterior en este tratado), el retiro de la característica requerirá a principiantes prestar una atención más cercana a su codificación. 

Modo seguro del PHP

Cuando el modo seguro se activa en un web server, las escrituras de la ejecución pueden tener acceso solamente a archivos dentro de su propio directorio del Web site. Esto evita que los piratas informáticos en un sistema compartido ejecuten una escritura en un directorio que pueda leer archivos y la información de un directorio que no pertenezca a ellos.

El modo seguro también limita el tiempo de ejecución de la escritura, utilización de la memoria, y acceso a ciertas funciones de sistema (tales como exec (), desate (), y copia ()). Es bueno hacer el modo seguro girar en muchas situaciones, aunque no funcionen algunos programas y componentes totalmente si se permite este modo. El modo seguro se activa en la mayoría de los anfitriones alojados compartidos del PHP.

Usted puede comprobar si el modo es fijado a encendido ejecutando la función del phpinfo () y mirando en la base del PHP del ? de la configuración para el directorio del safe_mode. Usted puede cambiar el ajuste buscando para el directorio del safe_mode en su archivo de php.ini.

Si usted está funcionando con el PHP en Microsoft IIS, usted no necesita utilizar modo seguro, puesto que cada anfitrión virtual se puede configurar funcionar de una cuenta de usuario separada. Mientras los privilegios de las cuentas de usuario se fijen correctamente, no hay necesidad de prohibirlo.

El modo seguro se quita en la versión 6 del PHP y arriba. Las restricciones que proporcionó se piensan para dar a sensación de seguridad falsa. De su puesta en práctica inicial, era una medida del substituto hasta web server (donde el problema debe ser manejado) había alcanzado un nivel de sofisticación donde no más sea necesario. Los servidores han estado en ese nivel por algún tiempo. Doc_root del PHP .

El directorio del doc_root acepta una secuencia que especifique el directorio de raíz de la ejecución para las escrituras del PHP. Si se permite el safe_mode, después no se permitirá ningunas escrituras ejecutar el exterior del directorio citado. el directorio se debe fijar en el archivo de php.ini como esto:

doc_root = “C:\Program Files\Apache Software Foundation\Apache2.2”

Disable_functions del PHP: Con el modo seguro del PHP desaprobado, hay un número de otras funciones que se pueden utilizar para asegurar artículos individuales en el PHP. Por ejemplo, los disable_functions directivos se pueden fijar para desactivar detalle de funciones que se pudieron explotar por un pirata informático. En su archivo de php.ini, la inserción del directorio siguiente desactivará las funciones enumeradas sin afectar a la operación de Joomla:

disable_functions = file,fopen,popen,unlink,system,passthru,exec,popen,
proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec

En un servidor que despliegue, usted puede considerar incluir la función del phpinfo en la lista de la neutralización. Eso manera, si existen algunos archivos errantes que llamen la función, incluso si un pirata informático localiza ese archivo, él no lo puede explotar para la información que suministraría para su intrusiòn.

Antes de que usted haga esta clase de cambio de configuración, asegúrese de que usted entienda el PHP bastante a fondo. Si no, usted es probable inhabilitar una función que sea utilizada por una extensión, y de tal modo limitar la funcionalidad de su Web site. 

Disable_classes del PHP: Como disable_functions, el directorio de los disable_classes acepta una lista coma-delimitada de artículos listado.

Esta función desactivará la clase orientada al objeto especificada de la ejecución bajo PHP. Mientras que este directorio ha limitado solamente utilidad en fecha esta escritura, en el futuro, cuando los armazones de la clase (marco incluyendo de Joomla) se convierten en riesgos para la seguridad más extensos y más actuales, este ajuste prueba ser muy útil. Para inhabilitar la clase del directorio, incluya este directorio en su archivo de php.ini…

disable_classes=Directory Display_errors

Recuerde que el que controla esto sera usted que por cierto querrá casi ciertamente grado de seguridad en su servidor y quiere definitivamente apagado en un servidor del despliegue es la determinación de los display_errors. Cuando se permite esto, cualesquiera errores o advertencia que ocurran durante la ejecución del PHP se repiten al visar , junto con el archivo y la línea número donde ocurrió el error.Usted puede permitir esta opción en el archivo de php.ini con este directorio: display_errors = activo 

Durante el desarrollo, usted querrá todos los errores exhibidos para permitir la resolución rápida, y todas las advertencias exhibidas porque tenderán a ser pasadas por alto si se incorporan solamente en los registros de errores. Con este ajuste inhabilitado, los mensajes del sistema no serán perdidos.

Si está activado o desactivado, errores y las advertencias se escriben en el archivo de error.log del \ del directorio de los registros en un Apache Server como de largo pues los log_errors se dejan permitidos (que es el defecto). Esté seguro de fijar este parámetro a apagado en su servidor . Si está habilitado, cualquier error puede proveer de un pirata informático una variedad información sobre su web server, incluyendo nombres de fichero, trayectorias de directorio, variables, y ajustes de permiso.

Éstos se pueden explotar para proporcionar el acceso desautorizado o el daño a su sitio. Expose_php del PHP El Apache ServerTokens mencionado anterior envía la información del servidor con cada petición de página.

El directorio del expose_php añadirá la información sobre el servidor del PHP a la información devuelta durante una petición de página. Por abandono, se permite esta opción, pero para la mejor seguridad, usted debe inhabilitarla en su servidor del despliegue. Para desactivar la fuente de la información del servidor del PHP, fije este directorio en su archivo de php.ini: expose_php = apagado Seguridad de MySQL

El servidor de base de datos de MySQL puede llevar a cabo mucha de información privada importante. Si la plataforma de Joomla se utiliza para la gerencia o el comercio electrónico del contacto, el acceso potencial a la información privada de la identidad del usuario puede ser substancial. Por lo tanto, usted debe leer la guía breve (pero significativa) de los “problemas de seguridad generales” de MySQL que usted encontrará en el URL siguiente: http://dev.mysql.com/doc/refman/5.0/en/security.html

El sistema de Joomla se crea para proporcionar mucha de seguridad de llaves, incluso si una instalación del defecto será bastante seguro. Sin embargo, hay un número de ajustes finos que usted puede hacer para reforzar algunos puntos débiles de Joomla.

Los nuevos problemas de seguridad se presentan todo el tiempo mientras que los piratas informáticos idean nuevos métodos de practicar una apertura seguridad.

Usted debe siempre mantener su instalación de Joomla puesta al día a la versión disponible más reciente. El mejor método de permanecer informado sobre los problemas de seguridad posibles de Joomla es suscribirse a los que ofrecen los foros de seguridad en Joomla “avisos relacionados con la seguridad.” Usted recibirán los email que relacionan la información de seguridad y cualquier alarma que requieran la especial atención.

Archivos de la instalación de la cancelación

Esté seguro que, una vez que usted ha terminado la instalación, usted suprime la carpeta \ de la instalación y todos los archivos en ella. Si un pirata informático pudiera reactivar el proceso de instalación en un servidor existente, sería posible limpiar el sitio limpio. Para cerciorarse de esto no sucede bajo ninguna circunstancias, esté seguro que los archivos de la ejecución de la instalación están quitados de su web server.

Redactor del HTML de Joomla Si usted permite a contribuidores en su Web site, hay el potencial alguien usando una cuenta para atacar el sistema con un ataque de XSS, según lo descrito anterior en este articulo en la sección, “Cross Scripting (XSS).”

Esté seguro de limitar las capacidades de los redactores que están disponibles para los contribuidores. A través del encargado activo, usted puede tener acceso a los parámetros para los editores usados por Joomla. Estos redactores contienen casi siempre la funcionalidad que permite el desmontaje automático del contenido potencialmente peligroso de contenido usuario-insertado. 

Ejecución dentro del sistema

Cuando un pirata informático puede ejecutar directamente un archivo del PHP fuera del sistema, todas las clases de travesura son posibles. Si usted está desarrollando las nuevas extensiones (módulos, componentes, o enchufes), agregue siempre el código que se asegura de que la extensión esté siendo funcionada por Joomla sí mismo. En la tapa de su archivo del código, agregue la línea siguiente:

defined( ‘_JEXEC’ ) or die( ‘Restricted access’ );

Si el parámetro del _JEXEC no se define (el significado Joomla no está ejecutando el proceso), la ejecución del código termina. Incluso una extensión primitiva de la prueba debe incluir la línea apenas en caso que se deja instalada en el servidor y olvidada, sólo para ser encontrado más adelante por un pirata informático y para ser explotado. 

Prueba y desarrollo

Si usted va a desplegar un sistema protegido de Joomla, usted debe poder probar configuraciones y extensiones en un sistema seguro. Esta prueba si la puede desarrollar la recomiendo utilizando Joomla a modo de pruebas con un trabajo previo a travès de modo de prueba puede observarse fallas de extensiones ademàs de incluir todos los tipos de extensiones y de código ásperos.

Un servidor de prueba es aún más importante para la seguridad si usted está realizando el desarrollo. Las escrituras de la prueba y las extensiones del ejemplo son solamente dos de los artículos que usted necesitará para ejecutar cuando realiza el desarrollo que puede crear las entradas grandes de su portal para que un pirata informático entre.

Los ataques ocurren generalmente en el punto más débil de un sistema, y un sistema de desarrollo tendrá muchos. Una vez que el desarrollo es completo, usted debe mover el sistema configurado a un servidor activo.

Usted no debe mover los archivos de configuración tales como php.ini y httpd.conf porque el servidor activo debe tener ajustes sumamente diversos. Cuando ciertas porciones del sistema se rompen bajo el nuevo despliegue más terminante (y ellas), rastree el problema en vez de inhabilitar el ajuste del problema. Esto llevará a un despliegue más fuerte de Joomla y a un código más sólido.

Resumen

Joomla es intrínseco un sistema muy seguro. Pero, su coordinación de las tecnologías múltiples del Web lo hace vulnerable a menos que se entiendan las amenazas de la seguridad y las contramedidas apropiadas se ponen en lugar. Este articulo no habrìa sido posible sin la colaboración y aguante que tuvo Redlo, en cuanto a este trabajo, mi amigo español, hizo que lo difícil lo haga sencillo, apoyandome animando a que termine este articulo.

Solamente resta decir que espero de todos que lo disfruten, que puedan aportar sugerencias y criticas, que todas ellas seràn recibidas, y si nada de eso ocurre, me conformarè con que saluden ¡!! Los temas tratados en este articulo pueden ser tratados haciendo el siguiente orden:

Tipos de ataques que se pueden intentar contra un web server.

Mejorar los ajustes de la configuración de seguridad del Apache Server.

Refinar el archivo de php.ini para limitar la ejecución y el acceso que crea una política de seguridad de MySQL para prevenir el acceso de información desautorizado.

Configurar los parámetros de Joomla para prevenir ataques potenciales.

Crear una política de seguridad de MySQL para prevenir el acceso de información desautorizado.

La seguridad de ataques del exterior es muy esencial, pero tener control eficaz del acceso de usuario dentro de un sistema es muy importante también. Desafortunadamente, esta área es una que está careciendo algo en Joomla.