Cross Site Scripting (XSS) é uma vulnerabilidade em um aplicativo da web que permite a terceiros executar um script no navegador do usuário em nome do aplicativo da web. Cross-site Scripting é uma das vulnerabilidades mais comuns presentes na web hoje. A exploração de XSS contra um usuário pode levar a várias consequências, como comprometimento de contas, exclusão de contas, escalonamento de privilégios, infecção por malware e muito mais.

Nos seus primeiros dias se chamava CSS e não era exatamente o que é hoje. Inicialmente, foi descoberto que um site malicioso poderia utilizar JavaScript para ler dados de respostas de outro site incorporando-os em um iframe, executar scripts e modificar o conteúdo da página. Na época, era chamado de CSS (Cross Site Scripting). A definição mudou quando a Netscape introduziu a política da mesma origem e o script entre sites foi impedido de permitir a leitura de resposta entre origens. Logo foi recomendado chamar esta vulnerabilidade de XSS para evitar confusão com Cascading Style Sheets (CSS).

A possibilidade de obter XSSed surge quando um site não lida corretamente com a entrada fornecida por um usuário antes de inseri-la na resposta. Nesse caso, uma entrada criada pode ser fornecida que, quando incorporada na resposta, atua como um bloco de código JS e é executada pelo navegador.

Dependendo do contexto, existem dois tipos de XSS -

1. XSS refletido:
   se a entrada tiver que ser fornecida a cada vez para executar, esse XSS é chamado de refletido. Esses ataques são realizados principalmente com a entrega de uma carga diretamente à vítima. A vítima solicita uma página com uma solicitação contendo a carga útil e a carga útil vem incorporada na resposta como um script. Um exemplo de XSS refletido é o XSS no campo de pesquisa.

   

2. XSS armazenado:
   quando a resposta contendo a carga útil é armazenada no servidor de forma que o script seja executado a cada visita sem envio de carga útil, é identificado como XSS armazenado. Um exemplo de XSS armazenado é o XSS no tópico de comentários.

   

Há outro tipo de XSS chamado XSS baseado em DOM e suas instâncias são refletidas ou armazenadas. O XSS baseado em DOM surge quando dados fornecidos pelo usuário são fornecidos aos objetos DOM sem a higienização adequada.
Um exemplo de código vulnerável a XSS está abaixo, observe as variáveis fistname e lastname :

<?php
 
   if(isset($_GET["firstname"]) && isset($_GET["lastname"]))
   {   
 
       $firstname = $_GET["firstname"];
       $lastname = $_GET["lastname"];    
 
       if($firstname == "" or $lastname == "")
       {
 
           echo "<font color=\"red\">Please enter both fields...</font>";       
 
       }
 
       else            
       { 
 
           echo "Welcome " . $firstname. " " . $lastname;   
 
       }
   }
   ?>

A entrada fornecida pelo usuário é adicionada diretamente na resposta, sem qualquer verificação de integridade. O invasor uma entrada algo como -

<script> alert(1) </script>

e será processado como JavaScript.
 
Existem dois aspectos do XSS (e qualquer problema de segurança) -

1. Desenvolvedor:
   Se você for um desenvolvedor, o foco seria o desenvolvimento seguro para evitar falhas de segurança no produto. Você não precisa mergulhar muito no aspecto da exploração, apenas precisa usar ferramentas e bibliotecas enquanto aplica as melhores práticas para o desenvolvimento de código seguro, conforme prescrito pelos pesquisadores de segurança.

   Alguns recursos para desenvolvedores são -

   uma). Projeto de codificação OWASP: É uma biblioteca escrita em Java desenvolvida pelo Open Web Application Security Project (OWASP). É gratuito, de código aberto e fácil de usar.

   b). O cabeçalho “X-XSS-Protection”: este cabeçalho instrui o navegador a ativar o auditor XSS embutido para identificar e bloquear qualquer tentativa de XSS contra o usuário.

   c). A Folha de Dicas de Proteção XSS da OWASP: Este recurso enumera regras a serem seguidas durante o desenvolvimento com exemplos adequados. As regras cobrem uma grande variedade de casos em que um desenvolvedor pode perder algo que pode tornar o site vulnerável a XSS.

   d). Política de Segurança de Conteúdo: É uma solução autônoma para problemas do tipo XSS, ela instrui o navegador sobre fontes “seguras” além das quais nenhum script deve ser executado de qualquer origem.

2. Pesquisadores de segurança: os pesquisadores de
   segurança, por outro lado, gostariam de recursos semelhantes para ajudá-los a localizar instâncias em que o desenvolvedor se tornou péssimo e deixou um ponto de entrada. Os pesquisadores podem fazer uso de -

   uma). CheatSheets -
   1. Folha de dicas de evasão do filtro XSS por OWASP.
   2. Folha de dicas de XSS de Rodolfo Assis.
   3. Folha de dicas de XSS da Veracode.

   b). Laboratórios
   práticos - 1. bWAPP
   2. DVWA (aplicativo da Web vulnerável)
   3. prompt.ml
   4. CTFs

   c). Relatórios -
   1. Hackerone Hactivity
   2. Blogs pessoais de eminentes pesquisadores de segurança como Jason Haddix, Geekboy, Prakhar Prasad, Dafydd Stuttard (Portswigger) etc.