¿Puede saber si una página existe incluso si arroja un 404?

El error 404 de lanzamiento para cada solicitud no válida podría ser cuestionable, un atacante puede comenzar a sospechar este comportamiento, especialmente si conoce el servicio al que se dirige.
¿Esto ayuda a proteger su servicio? Esto realmente depende de la perseverancia del atacante.

Editar :

El atacante puede detectar la diferencia si no crea el encabezado de respuesta 404 correctamente como lo haría el servidor

Aquí hay un caso de servidor PoC para Java (Tomcat8):
Este es un estado 404 'veraz' devuelto por el propio servidor para cualquier recurso no encontrado:

Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1

Este es devuelto por el servlet:

Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1

Observa que el valor del parámetro "Longitud del contenido" en ambos casos, podría atraer la atención del atacante.

Cuidado, ocultar el código de error real huele un poco como ofuscación. No hay nada realmente malo desde el punto de vista de la seguridad, pero agrega poca seguridad si la hay. ¿Realmente crees que los atacantes aceptan ciegamente códigos de error? Sabes que se pueden cambiar a voluntad, y lo hacen también. Ok, puede ser útil contra los chiquillos del guión pero no enfrentar un ataque serio, por lo que deberías pensar en cuál es tu modelo de amenaza antes de ir por ese camino.

Y podría haber un inconveniente aquí. A menos que cree un sistema de registro especial que registre el error interno, finalizará en los registros que contienen solo 404 errores. Eso significa que usted ha perdido cualquier posibilidad de análisis de registro para intentar descubrir ataques a su sitio y posibles fallas de seguridad. El código de error IMHO es más útil para el mantenedor de una aplicación que para un atacante ...

La misma idea se aplica con la autenticación de usuario.

La mayoría de los servicios web que ha visto, no le dirán qué es lo que está mal en su nombre de usuario y contraseña. Le dará un aviso general diciendo que algo con todo el par no era válido. Esto deja al atacante sin saber si el nombre de usuario es incorrecto, la contraseña era incorrecta o el par en sí era incorrecto.

Es mucho más rápido determinar si el usuario existe en comparación con si el usuario existe y si la contraseña es correcta . Algunos atacantes tendrán esto en cuenta cuando intenten acceder a un sistema por tiempo.

Del mismo modo, lo mismo se aplica a 404 (No encontrado) vs. 403 (No autorizado). Es más rápido para el servidor web devolver un 404 que un 403, pero los tiempos aquí pueden ser tan pequeños que el margen de error podría hacerse cargo.

No es inaudito siempre escupir un 404 en lugar de ambos 404/403. Un servidor web como Apache puede personalizar su respuesta a una solicitud de página web. Es un poco más difícil cambiar el código de retorno HTTP, pero ciertamente es más fácil modificar la página que ve el usuario. Al igual que con la idea de nombre de usuario / contraseña, el atacante se queda con dos casos:

• ¿Existe realmente este recurso?
• ¿Debo estar autorizado antes de tener acceso a esto?

Ahora es más común que el código del lado del servidor maneje la autorización y la autenticación sin que el servidor web devuelva un código 404/403. El código del lado del servidor normalmente manejará dichas solicitudes, y el servidor web simplemente devolverá un código 200 o 300. El contenido de la página puede decir 403, pero el código HTTP será 200 o 300. 403 se utiliza para la autenticación HTTP que ha perdido popularidad con el tiempo.