Principios básicos de la Seguridad Web.

La seguridad web es una importante rama de la seguridad informática, en ella se emplea la creatividad y la astucia. El propósito de este artículo es más que nada discernir la seguridad web con otros campos especializados, ya que una de las principales causas de la ignorancia es con claridad la falta de cultura.

Habrá en la internet alguna frase con connotación egocéntrica mencionando que la seguridad web es una tontería o algo parecido a ello, a fin de “insultar” a los que se especializan en ello, y aunque insultar sea muy subjetivo, explicaré que es lo mejor sobre este tema. Un 70% aprox. de los sitios web tienen algún tipo de bug conocido en un 50% son de XSS, construir un sitio web y protegerlo bien es más difícil que “hackear” uno.

Todos los sitios son inseguros, algunos en mayor medida y otros en menor. Es una práctica que llena de regocijo, aumenta notablemente el ego y ocupa la cabeza al 100%. Teniendo en cuenta los anteriores puntos, es racional pasar a temas más técnicos, cómo son las vulnerabilidades más explotadas.
Cross Site Scripting (XSS):

Esta ocupa mayor relevancia en la lista, ya que es un ataque del cual derivan bastantes ramas, y muchísimas técnicas avanzadas, podría comentar que es el más explotado.
Structured Query Language Injection (SQLi):

También ocupa mucha relevancia, es un ataque que tiene bastantes variaciones, mucho depende de cómo esté configurado el servidor Web.
Remote Code Execution (RCE):
De este hay bastantes ramas, cómo son Local File Inclusion y Remote File Inclusion, es bastante probable que sea fatal en un servidor Web, ya que puede afectar directamente a las demás web’s alojadas en el servidor.
Disclosures:

No es de bastante relevancia, pero junto con alguno otro sería realmente fatal, después se hablará de ello.
Ahora, obviamente está el ataque pero es factible introducir temas relacionados con la aseguración de un sitio web, mucho depende del código creado, pero hay algunas cosas como la protección del panel de administración.
Indexeo de Bots

Últimamente es lo que se utiliza muy amenudo, dorkear un poco para que nos despliegue dónde está e cPanel, sí es que Google lo ha indexeado. Esta técnica se puede evitar con facilidad, pero el remedio nos puede vulnerar, así que trataremos de evitar que nos vulnere. Podremos usar el fichero robots.txt, pero revelaríamos la ubicación de nuestro cPanel lo cual es irracional, así que lo colocaremos lejos de raíz /xxx/yyy/_adminpanel/, así que quedaría así el fichero robots.txt

User-agent: *
Disallow: /xxx/
Disallow: /otro_Fichero/
Disallow: /otro_fichero/

Contenido de…
Primero que nada se tratará de poner un archivo index en todas las carpetas y que haga redirección al index de la web, sí no apetece podría especificar archivos index y especificar el error 404. Esto se puede hacer en .htaccess, simplemente se introduce lo siguiente:

# Definición de los archivos
DirectoryIndex index.html index.php
# Definición de nuestro error 404 personalizado
ErrorDocument 404 /xxx.php

Web Crawling

Este es un método bastante difícil de evitar, lo que hace básicamente este es rastrear todos los archivos. Éste no es lo mismo que las técnicas convencionales, es algo diferente, aunque llegaría siendo convencional. Por ello se necesitará ACAP version +1, para incluirlo en el fichero robots. Con esto se evitará crawling. Bueno, se deberá hacer casi lo mismo que con el Disallow, sólo que de esta manera:

ACAP-crawler: *
ACAP-disallow-crawl: /xxx/
ACAP-disallow-crawl: /otro_Fichero/
ACAP-disallow-crawl: /

Sí alguien realmente bueno en lo que hace consiguió acceso a la ruta dónde tenemos nuestro cPanel. Se podrá utilizar los errores 404 falsos, y una restricción de IP desde .htaccess.

Cómo sabemos un error 404 significa que se realizó una conexión al servidor, pero no se encontró el fichero requerido, una manera fácil y lógica de evitarlo es implementando un script en php que simule un error 404, no obstante, es un riesgo hacerlo.
[…]
$ip=$_SERVER['REMOTE_ADDR'];
if($ip!=="xxx.xxx.xx.x") {
header("HTTP/1.1 404 Not Found");
exit();
[…]

Lo correcto sería definir algunas reglas en el fichero .htaccess, claramente de Apache

# Definición de los archivos
DirectoryIndex index.html index.php
# Definición de nuestro error 404 personalizado
ErrorDocument 404 /xxx.php
#Empieza la definicion de nuestras reglas
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !XXX.XXX.XX.X
RewriteRule (.*) http://www.chambo.com/404/index.php