hoje e estou vendo muitas pessoas que pensam que os sites podem ser invadidos sem ter nenhum conhecimento do servidor da web ou do aplicativo da web. Aqui estão algumas informações que serão úteis para qualquer pessoa interessada em aprender sobre hacking de aplicativos da web.

Ao segmentar um site, normalmente opero com a seguinte metodologia:
1.) Recon:
Eu uso uma ferramenta chamada theHarvester (https: // github.com/laramies/theHarvester) para coletar informações sobre o site de destino, como contas de e-mail, nomes de subdomínio, hosts virtuais, portas/banners abertos e nomes de funcionários de diferentes fontes públicas . No entanto, eu realmente só uso essa ferramenta para encontrar e-mails associados ao domínio porque existem ferramentas melhores para usar quando se trata de encontrar subdomínios e abrir portas/banners. em seguida, aplique as táticas mencionadas no capítulo um a todos os e-mails encontrados.

Em seguida, uso uma ferramenta chamada aquatone (https: // github.com/michenriksen/aquatone) para encontrar subdomínios, fazer uma captura de tela de cada subdomínio e, em seguida, testar as vulnerabilidades de aquisição de subdomínio.

Em seguida, uso a popular ferramenta Nmap para escanear cada subdomínio em busca de portas abertas, normalmente crio um arquivo chamado hosts.txt contendo cada subdomínio (1 subdomínio por linha). Em seguida, uso um comando que normalmente se parece com algo assim:

udo nmap -sS -iL hosts.txt -oN nmap-scan.txt --script=banner

Você pode ter que alterar um pouco o comando com base na configuração de rede de destino.

Em seguida, vejo os resultados da varredura de porta e procuro os serviços que estão usando, tento identificar a versão do serviço e, em seguida, procuro módulos no framework metasploit (https: // metasploit.com/) ou scripts em https: // explore-db.com e, em seguida, execute-os no destino. Se eles tiverem algum serviço da Web em execução, geralmente tento descobrir se eles estão executando algum aplicativo da Web específico, como um CMS ou plug-in e, em seguida, tento identificar a versão, pesquiso o software e o número da versão no google com a palavra " Exploit" depois, ou seja: "Struts2 Exploit"

Agora, se ainda não identifiquei uma vulnerabilidade, procurarei diretórios e arquivos ocultos com dirb (http: // dirb.sourceforge.net/) e, em seguida, procurarei no site por vulnerabilidades, fuzzing parâmetros de entrada do usuário e cabeçalhos. Eu uso o Burp Suite (https: // portswigger.net/burp) como um proxy de interceptação e spider, bem como o recurso intruso (taxa limitada na edição gratuita) se você tiver a edição paga, o cliente colaborador burp é muito útil. A edição gratuita é suficiente e muito poderosa, no entanto, a versão paga oferece mais recursos que são muito úteis ao fuzzing de um aplicativo da web para vulnerabilidades. Para cargas úteis difusas, eu realmente gosto de usar SecLists (https: // github.com/danielmiessler/SecLists), PayloadsAllTheThings (https: // github.com/swisskyrepo/PayloadsAllTheThings) e fuzzdb (https: // github.

Phishing:
Sempre personalize seus e-mails de phishing para atacar especificamente. Seja criativo e o mais crível e profissional possível. Uma ferramenta muito boa para usuários de phishing é o Social Engineering Toolkit ( https

: // github.com/trustedsec/social-engineer-toolkit)

.
recursos/metodologia
https: // blog.cobaltstrike.com/2013/10/03/email-delivery-what-pen-testers-should-know/
http: // securitytube.net/video/7007
Man In The Middle:
Um homem no ataque do meio é exatamente o que parece. Você pode interceptar informações realizando um ataque de falsificação ARP na rede. Você também pode combinar isso com envenenamento de cache DNS, que pode ser muito útil ao tentar hackear um alvo. Uma ferramenta útil para realizar esse ataque é o MITMf (https: // github.com/byt3bl33d3r/MITMf), especialmente quando você tem acesso físico à rede. Se você está pensando em fazer isso remotamente, precisará abrir uma das caixas na rede deles, de preferência abrindo uma sessão de medidor de desempenho na caixa e gerar chaves ssh para você usar. Depois de obter acesso ssh, uma boa ferramenta para usar é ssh-mitm (https: // github.com/jtesta/ssh-mitm) BÔNUS: Faça root na caixa usando um exploit de root local.
Exploração de aplicativos da Web:
quando se trata de fuzzing em um site, você precisa entender o que é fuzzing e como identificar vulnerabilidades. Considerando que existem livros inteiros escritos sobre a exploração de aplicativos da Web, não entrarei em muitos detalhes, mas explicarei as possibilidades, fornecerei algumas dicas e fornecerei todos os recursos necessários.

Cross Site Request Forgery (CSRF): Essencialmente, você cria uma solicitação que executa uma ação em um site. Digamos que haja um formulário que altere a senha de um usuário e não exija a senha atual do usuário e não haja tokens para impedir o CSRF. Digamos que seja uma solicitação GET, mas geralmente será uma solicitação POST. A solicitação se parece com esta: 'https: // target.com/change_password.php?new_password=H4x3d&confirm_password=H4x3d' se você quiser alterar a senha dos usuários, tudo o que você precisa fazer é fazer com que eles executem essa solicitação. Isso pode ser feito criando uma página da Web personalizada e hospedando-a em algum lugar, incorpore a solicitação em um <iframe> de 1 x 1 pixel e apenas faça o usuário clicar no link. Se eles já estivessem logados no site, este ataque teria apenas alterado sua senha para H4x3d.
Injeção de HTML (HTMLi):
essa vulnerabilidade ocorre quando um invasor pode incorporar seu próprio html no site de destino devido à entrada do usuário não ser sanitizada. Geralmente, esse ataque pode ser aproveitado para Cross Site Scripting, mas em alguns casos isso não é possível. Um exemplo de ataque seria injetar uma sobreposição <iframe> em tela cheia que exibe uma página de login falsa que rouba a senha do usuário.
Cross Site Scripting (XSS):
Essa vulnerabilidade ocorre quando a entrada do usuário não é sanitizada e um invasor consegue executar seu próprio javascript. Existem quatro tipos de vulnerabilidades XSS - Refletida, Armazenada, Cega e baseada em DOM. XSS refletido é quando uma entrada é refletida de volta para o usuário devido a uma carga útil especialmente criada. Um exemplo de XSS armazenado seria um livro de visitas, se um invasor postar um comentário que contenha javascript e a entrada não estiver sendo sanitizada adequadamente, qualquer pessoa que visualizar o comentário do livro de visitas executará o javascript do invasor, neste caso, o javascript que seria executado. Blind XSS é essencialmente uma vulnerabilidade XSS armazenada, mas você não pode vê-la porque não tem acesso à página, um exemplo seria um sistema de tíquetes de suporte ao atendimento ao cliente em que a consulta de suporte não é adequadamente sanitizada e as únicas pessoas com acesso são os funcionários do atendimento ao cliente. Uma boa maneira de identificar o Blind XSS é usar uma ferramenta chamada XSS Hunter em xsshunter.com ou você pode executar sua própria instância do XSS hunter (https: // github.com/mandatoryprogrammer/xsshunter). O XSS baseado em DOM é uma vulnerabilidade de XSS que é executada no DOM (Document Object Model) do navegador, portanto, do lado do cliente e não será exibida nos logs dos servidores. Às vezes, as vulnerabilidades XSS precisam ser encadeadas com a falsificação de solicitação entre sites para funcionar corretamente. Se um invasor for capaz de executar seu próprio javascript, ele poderá roubar os cookies dos usuários e roubar sua sessão. Muitas vezes você terá que revisar manualmente os valores refletidos/armazenados no documento HTML e pensar em como interromper o carregamento da página, muitas vezes você terá que contornar tentativas de sanitização ou um bloqueio de firewall de aplicativo da web seu pedido. Seja criativo.
Minhas cargas úteis preferidas:

If injected within HTML:
<a b=c>XSS
<svg/onload=alert(1)>
<svg/onload=(alert)(1)>
"><svg/onload=alert(1)>
"><svg/onload=(alert)(1)>
"><img src=x onerror=alert(1)>

If injected within <a href="FUZZ">Click Me</a> and FUZZ is the parameter value that is reflected/stored:
javascript:alert(1)
javascript://%0aalert(document.domain)

If Reflected within Javascript:
"-alert(1)-"
'-alert(1)-'

Aqui está uma ótima fonte para algumas técnicas avançadas de desvio de WAF:
https: // brutelogic.com.br/blog/cheat-sheet/
Carregamento arbitrário de arquivo:
esta vulnerabilidade ocorre quando um site tem um recurso de carregamento que permite que um usuário carregue conteúdo malicioso. Há uma tonelada de payloads diferentes que você pode usar para explorar isso, e muitas vezes você terá que descobrir como ignorar as técnicas de filtragem. Um exemplo desse ataque seria um site que não permite uploads que terminam em .php, mas permite .php5. Agora você pode fazer upload de um arquivo que executará o código no lado do servidor, levando a um comprometimento total. Se você puder fazer upload de documentos HTML ou SVG, poderá obter um XSS armazenado.

Referência
https: // owasp.org/index.php/Unrestricted_File_Upload
Referência de Objeto Indireto (IDOR):
Este ataque é bastante vago, mas ainda pode ser muito útil. Um exemplo disso seria se houvesse uma página da Web que exibisse as informações da conta do usuário em um URL como "https: // target.com/userinfo.php?id=5102" se esta página exibisse informações confidenciais sobre você (usuário ID 5102) e você altera o URL para "https: // target.com/userinfo.php?id=5101" e ele exibe as informações confidenciais de outra pessoa que você acabou de criar IDOR.

Referência
https: // owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)
Inclusão de arquivo local (LFI):
Essa vulnerabilidade ocorre quando um invasor pode incluir um arquivo localizado no sistema de arquivos em uma página da Web. Um exemplo disso seria se o URL fosse "http: // target.com/view.php?page=page001.php" se o invasor alterasse o URL para http: // target.com/view.php?page= /etc/passwd e o arquivo /etc/passwd é retornado, você acabou de identificar o LFI. Outro exemplo seria se a url fosse "http: // target.com/view.php?page=page001", que inclui o nome do arquivo do valor do parâmetro da página + '.php' anexado ao valor do parâmetro no lado do servidor. Uma maneira de ignorar ".php" sendo anexado no lado do servidor é usar um byte nulo (%00), agora tudo o que um invasor precisa fazer é carregar "http: // target.com/view.php?page=/etc/ passwd%00" que retorna o arquivo /etc/passwd. Existem várias técnicas para alavancar o LFI na execução remota de código (RCE), como usar o manipulador data://, envenenamento de log fazendo uma solicitação com o código do lado do servidor como agente do usuário e, em seguida, incluindo o arquivo de log de acesso, por exemplo "http: // target.com/view.php?page=/var/log/apache2/access.log" desde que você fez uma solicitação contendo o código do lado do servidor quando o arquivo access.log é incluído, o código do lado do servidor será executado. Existem vários locais diferentes onde o arquivo de log de acesso pode ser armazenado, dependendo do servidor da Web e de sua configuração. Você também pode usar os vários manipuladores de arquivos para obter o código do lado do servidor para executar, como data:// zip:// php:// e muitos mais. Outra maneira de executar o código do lado do servidor é proc/self/environ e incluir o código do lado do servidor no cabeçalho User-Agent.

Referência:
https: // owasp.org/index.php/Testing_for_Local_File_Inclusion
Inclusão de arquivo remoto (RFI):
Um exemplo de inclusão de arquivo remoto seria "http: // target.com/view.php?page=http: // google.com" se a página inicial do Google for carregada na resposta que você acabou de identificar Remoto Inclusão de arquivo, muitas vezes isso pode ser aproveitado para execução remota de código, incluindo um arquivo contendo código do lado do servidor. Além disso, esse tipo de ataque às vezes pode ser usado para obter acesso a uma rede interna usando o Server Side Request Forgery (SSRF).

Referência
https: // owasp.org/index.php/Testing_for_Remote_File_Inclusion
Falsificação de solicitação do lado do servidor (SSRF):
esse tipo de vulnerabilidade ocorre quando um invasor pode usar o servidor de destino para fazer solicitações. Por exemplo, se a página for "http: // target.com/proxy.php?url=http: // google.com" e http: // google.com carregar, mas você não conseguir executar o código do lado do servidor, você pode tentar obter acesso à rede interna. Por exemplo, "http: // target.com/proxy.php?url=http: // 192.168.1.1" pode carregar a página inicial do roteador. Há também o Blind SSRF, que faz a solicitação do lado do servidor, mas não mostra a resposta. Isso pode ser usado para escanear a porta de uma rede interna a partir de uma fonte externa.

Referência
https: // owasp.org/index.php/Server_Side_Request_Forgery
Injeção de modelo do lado do servidor:
essa vulnerabilidade ocorre quando um aplicativo da Web que utiliza um mecanismo de modelo inclui entrada não sanitizada do usuário em um modelo que é renderizado pelo mecanismo de modelo, executando assim o código do lado do servidor. Esse tipo de vulnerabilidade geralmente pode ser confundido com XSS. Um exemplo seria "http: // target.com/?name=John" que retorna 'Hello John' na resposta. Se o invasor inserir "http: // target.com/?name=${7*7}" e 'Hello 49' for retornado, você acabou de identificar o SSTI. Uma ferramenta útil para explorar vulnerabilidades de injeção de modelo é o tplmap (https: // github.com/epinna/tplmap).

Referência:
http: // blog.portswigger.net/2015/08/server-side-template-injection.html
SQL Injection (SQLi):
esta vulnerabilidade ocorre quando a entrada do usuário que não foi sanitizada é passada para uma consulta SQL. O SQLi é simples de aprender, mas pode ficar bastante avançado. Uma maneira fácil de testar a injeção de SQL é inserir um ' em um parâmetro e, se ocorrer um erro de sintaxe SQL na página que você acabou de identificar, a injeção de SQL. No entanto, pode ficar muito mais avançado, então sugiro pesquisar isso. Muitas vezes, a injeção de SQL pode levar à execução remota de código, obtendo acesso a painéis de administração se as senhas no banco de dados estiverem armazenadas em texto simples ou se você conseguir quebrar uma senha com hash. Se o banco de dados estiver sendo executado como administrador do banco de dados, você normalmente pode colocar um shell na caixa. Uma boa ferramenta para automatizar os testes e explorar a injeção de SQL é o sqlmap (https: // github.com/sqlmapproject/sqlmap)

Referência
https: // owasp.org/index.php/SQL_Injection
https: // owasp.org/index.php/Blind_SQL_Injection