Mensajes

Sí el servidor no tira error y puedes ver que está escuchando en el puerto 8080 lo más seguro que sean las reglas del firewall, ¿usas ufw o iptables, o qué s.o tienes?

err_connection_timed_out es un error de establecimiento de conexión, se pasó del tiempo de espera para una respuesta, tu servidor no está dando ningun req al cliente y por eso tira error, otra cosa también es que si ya estás escuchando en un puerto determinado el socket ya se bindeo a ese puerto, no tienes que especificar /ejecucion/ así basta:

Código [Seleccionar] Expandir


var socket = io('http://midominio.com:8080');

Sube completo server.js y los otros estáticos a ver si le podemos dar solución.

[res.render('index.pug',{ .. })]

Código [Seleccionar] Expandir

app.get('/', function (req, res) {
  res.render('index', { title: 'Hey', message: 'Hello there!' })
});

Si no se da una extensión al archivo a ser renderizado express
lo determina, te serviría res.render('index.pug',{ .. })

Necesito que me digas más para poderte ayudar, ¿era eso o necesitas hacer otra cosa?, además , ¿por qué quieres renderizar del lado del servidor? Consume muchos recursos y eso lo podemos hacer con Angular JS
de fomar dinámica.

No es un directorio. Se parsea mediante el servidor web. En llaman reglas de reescritura o rewrite rules. En este caso, es un ejemplo de lo que no hay que hacer ya que es poco intuitivo y mal interpretado por muchos buscadores pero simplemente apunta al archivo root (normalmente un index) del directorio principal.

Es decir, en realidad podría quedar como:
http://www.ejemplo.com/index.aspx/SEARCHED/ST=mi_busqueda/gbpws.aspx

Por que puede. En realidad ese archivo no lo llama directamente el navegador. Es un parámetro para el archivo principal que como he dicho antes, seguramente sea el archivo root del directorio principal.

No puedes jugar con parámetros GET ya que estan mal estructurados en esa pagina. En SQLMAP tendrías que indicar un parametro propio como parte de la url.

Esto es, crear un punto de inyección añadiendo un asterisco * donde quieras que inyecte. En este caso, seria:

http://www.ejemplo.com//SEARCHED/ST=algo*/gbpws.aspx

Puedes leer mas sobre esto aquí:
https://github.com/sqlmapproject/sqlmap/wiki/Usage#uri-injection-point




Ten en cuenta que el servidor puede interpretar muchas cosas de muchas maneras. De hecho, esto es una url perfectamente valida:

http://ejemplo.com/index.php/test.php/hola.php?param=holaKase/ola=kase

Esta mal estructurada en un principio, pero es completamente valida. En nGInx esto por ejemplo se configuraria asi:

Código [Seleccionar] Expandir

location / {
   try_files $uri $uri/ /index.php?$query_string;
}

En PHP por ejemplo podrias tener un index asi:

Código (php) [Seleccionar] Expandir

<?php
echo '<pre>';
echo $_SERVER['REQUEST_URI'];
print_r(explode('/', $_SERVER['REQUEST_URI']));
?>

Entonces al ejecutar esa url, te devolvería:

Código [Seleccionar] Expandir

/index.php/test.php/hola.php?param=holaKase/ola=kase

Array(
   [0] =>
   [1] => index.php
   [2] => test.php
   [3] => hola.php?param=holaKase
   [4] => ola=kase
)


Y si, es recomendable que practiques un poco de programación, sobre todo lo que son los enrutadores (routers) y el protocolo HTTP.

Saludos

Sabes por qué $uri/ da un forbidden 403? Siempre que utilizo ese parámetro en try_files tira error.

 

No es PHP, es vbscript, corriendo en un Windows Server con tecnología IIS y Windows Host Scripting (procesador asp).

Tampoco creo que parsee los query_strings, déjame enseñarte algo:

URI:
http://www.google.com/path.php?id=query&strings=true

URL:
www.google.com

PATH:
path.php

QUERY
?id=query&strings=true

QUERY STRINGS
query, true

Ahora bien, query_strings es el que recibe el servidor para pasar métodos $_GET al procesador php (el procesador php puede correr como mod_php dentro de un solo thread en el caso de apache O ejecutarse en diferentes pools para hacer load balancing de las ejecuciones del procesador osea, aumentar el rendimiento en nginx)

Bien, los módulos rewrite toma la URI y construye una QUERY con query_strings en PATH, para servir un servicio estático de backend (a veces es diferente con Express js y node).

Estoy muy seguro que es igual en IIS, aprender PostgresSQL te facilitará, además te recomiendo aprender un lenguaje nativo y .NET es uno que comparte la plataforma Windows Phone, ASP, VBScript y Autoit. Es importante conocer de backend si deseas hacer un mass defacement, si no no podrás escalar privilegios.

Siempre recomiendo aprender a programar y administrar servidores, antes de embarcarse a la auditoría web, en mi experiencia ayudó a comprender de que forma se consituyen las aplicaciones web, qué limites y que posibilidades hay dentro de la web.
.aspx es un script en VBscript del lado del servidor (si tienes acceso a este, identificarás el VBscript cuando usen <% %> en vez de <?php ?> caracteristico.

No tengo mucha experiencia con IIS, pero en nginx en el nginx.conf que define cómo nginx va a tratar las peticiones HTTP provenientes, dentro del bloque de directiva http -> server -> existe una directiva llamada location. Una vez que se recibe

Código [Seleccionar] Expandir

HTTP 1.1 GET /

el servidor busca en las directivas location el siguiente: /, y si autoindex está activado busca index.html para servirlo.

El módulo rewrite de apache y nginx toma una URI ejemplo /articulo-1923-index.html vuelca el query_string, y el $path a los servicios backend como /articulo.php?id=1923&page=index.html.

Espero te de una idea de lo que SEARCHED/ST=mi_busqueda/file.aspx está haciendo.
Por supuesto, instalate IIS y lee la siguiente documentacion para comprender el funcionamiento interno de las redirecciones internas del servidor https://docs.microsoft.com/en-us/iis/configuration/configpaths/

Lado del cliente: recomiendo Firebug, Live HTTP Headers y Hackbar (plugins de firefox)

Tenemos suites como BurpSuite, que es un all-in-one fuzzer de aplicaciones web. (No conozco ninguno más, no es aconsejable usar herramientas pre-fabricadas, y si necesito solo uso debuggers y  fuzzers)

Y del lado del servidor, puedes usar nmap.

Creo que en las aplicaciones web, lo que necesitas es navegar por el sitio web intentando introducir querys de forma contra-intuitiva, buscar un panel de control, buscar full-disclosure que te ayudará a conocer más sobre los servicios que están ejecutandose en el servidor, intentar saber que módulos (de nginx o de Apache, o que servicios de IIIS está ejecutando)

Te recomiendo mucho dejar la auditoría web, yo preferí aprender a programar antes de aprender a vulnerar y es más enriquecedor, más productivo, después viene la auditoría, cuando ya entiendes el código.

De acuerdo con W3C, cualquier binario CGI o script es susceptible a ataques, desde ejecución remota de comandos, desbordamiento de pila, format string, etc.

Primero quisiera que removieras /cgi-sys/ de la carpeta raiz de tu aplicacion web, es sabido que trae problemas de seguridad tener cualquier carpeta backend accesible al publico, además de ser una mala practica de programacion, si conoces la arquitectura MVC querrás siempre tener el backend completamente separado del frontend.

Especificamente count.cgi tiene dos agujeros de seguridad que te permite introducir un archivo de tipo .gif, por supuesto la aplicación practica consiste más bien en un ejemplo de esteganografia /count.cgi?img= [local include file], segundo, puedes lograr un stack overflow ( mas informacion sobre como utilizar count.cgi https://intranet.cs.hku.hk/csintranet/contents/technical/howto/count_cgi.jsp ) que te permite realizar ejecuciones en sistemas UNIX/Linux.

Es una vulnerabilidad bastante vieja ya, pero todavía aplicable puesto que muchos servidores utilizan scripts CGI a la vista y vulnerables.Y existen ejemplos de más y más scripts con agujeros de seguridad, yo lo considero una mala práctica, pero bue, cada quien.