Experimente builtwith.com , ele informará tudo o que puder descobrir sobre a plataforma em que o servidor está sendo executado.
Existe uma maneira de dizer (como um cliente) se existe algum código do lado do servidor que está sendo processado (PHP / ASP.NET) ou se é simplesmente um arquivo HTML estático?
Experimente builtwith.com , ele informará tudo o que puder descobrir sobre a plataforma em que o servidor está sendo executado.
Você nem sempre pode saber com certeza. Aqui está um exemplo porque. Eu posso definir o apache para lidar com uma extensão específica da maneira que eu quiser. Eu posso fazer com que o php renderize um documento .html que contenha PHP.
Tudo o que o usuário verá é que ele é exibido em um documento HTML (extensão .html).
Na maioria das vezes, a extensão pode lhe dar uma dica, mas também se houver conteúdo dinâmico que seja uma boa dica.
Dependendo das configurações do servidor, e se você estiver no Linux, talvez seja possível usar a ferramenta de linha de comando curl com a opção -I para mostrar cabeçalhos como este; usando a Microsoft como exemplo:
curl -I www.microsoft.com/
Os cabeçalhos que a Microsoft retorna são os seguintes:
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 1020
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "67991fbd76a6c91:0"
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Sun, 12 Oct 2014 08:28:11 GMT
Então essa linha que lê X-Powered-By: ASP.NET ? Bem, acho que isso responde certo? Bem, na verdade não. Embora um servidor possa ser capaz de usar o ASP.NET, isso não significa que a página que você está visualizando esteja usando o ASP.NET.
E para tornar as coisas ainda mais complicadas, é claro que a Microsoft estaria usando o ASP.NET, certo? Mas adivinha o que? No mundo real, a maioria dos servidores existentes - pelo menos os que são bem gerenciados - não anunciam detalhes reais do software de servidor que usam. Isso é chamado de proteção do servidor. Por exemplo, vamos ver a saída do cabeçalho do site da BBC:
curl -I www.bbc.co.uk/
E a saída do cabeçalho é esta:
HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html
Content-Language: en-GB
Etag: "1d86e04c393ac9be31d256305b22b59e"
X-PAL-Host: pal116.telhc.bbc.co.uk:80
Transfer-Encoding: chunked
Date: Sun, 12 Oct 2014 08:32:46 GMT
Connection: keep-alive
Set-Cookie: BBC-UID=d524632ae30c5a5eebfec61e915b62ab64b472f7c4b4e10e5ae1a4c76eacdbc00curl/7.30.0; expires=Thu, 11-Oct-18 08:32:46 GMT; path=/; domain=.bbc.co.uk
X-Cache-Action: HIT
X-Cache-Hits: 827
X-Cache-Age: 88
Cache-Control: private, max-age=0, must-revalidate
Vary: X-CDN
A única coisa que podemos descobrir é que o site principal da BBC usa o Apache. Mas isso alimenta um bom pedaço da web. Sabemos qual versão do Apache? Sabemos o que é script nos bastidores? Não. De jeito nenhum.
E isso é intencional, já que a grande maioria dos scripts de malware / bot vasculha a Internet em busca de pontos fracos nos sistemas, certo? Bem, e se o site basicamente anunciasse: “Ei! Eu estou usando esta versão mais antiga do Apache, assim como uma versão mais antiga do PHP! ”Bem, adivinhe? Agora, o software malicioso sabe exatamente quais botões pressionar para obter acesso a pontos fracos do sistema. Ninguém quer isso. Assim, a grande maioria dos servidores bem gerenciados por aí não anuncia quem / o que eles são.
Entretanto, embora o endurecimento só possa retardar um ataque. Significado, digamos que existam 1.000 maneiras possíveis de atacar um servidor. O envio de cabeçalhos detalhados pode reduzir para 20, então um hacker pode entrar mais rapidamente. Mas um hacker determinado pode deixar todos os mil exploits tentarem passar. Portanto, não é um método infalível de impedir ataques. Mas é melhor que nada.
O que é tudo para dizer que os observadores casuais podem nunca saber o que exatamente roda um site. E se isso te frustrar, culpe o mundo em que vivemos onde bots / spiders maliciosos estão constantemente investigando o site. Suas más ações tornam a vida mais difícil para o resto de nós.
Tags html