Uma vulnerabilidade de CSRF (cross-site request forgery) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.

Por padrão, as páginas do Visualforce são renderizadas com campos de formulário ocultos que servem como tokens anti-CSRF. Esses tokens são incluídos nas solicitações enviadas da página e o servidor verifica a validade dos tokens antes de executar os métodos de ação ou comandos correspondentes. No entanto, essa defesa integrada não se aplica a métodos de ação de página e construtores de controlador de página personalizados porque eles são executados antes que os tokens anti-CSRF sejam gerados durante o carregamento da página.

Exemplo 1: A página a seguir do Visualforce declara um controlador personalizado MyAccountActions e um método de ação de página pageAction(). O método pageAction() é executado quando o URL da página é visitado e o servidor não verifica se há tokens anti-CSRF.

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>

public class MyAccountActions {

    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

Um invasor pode configurar um site mal-intencionado que contém o seguinte código:

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

Se um administrador da página do Visualforce visitar a página mal-intencionada durante uma sessão ativa no site, ele excluirá involuntariamente as contas do invasor.

Uma vulnerabilidade de Cross-Site Request Forgery (CSRF) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.
2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.

Exemplo 1: No seguinte exemplo, um aplicativo Web permite que os administradores criem novas contas:

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  rb.sendRequest(body, new NewAccountCallback(callback));

Um invasor pode configurar um site mal-intencionado que contém o código a seguir.

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
  body = addToPost(body, "attacker";
  body = addToPost(body, "haha");
  rb.sendRequest(body, new NewAccountCallback(callback));

Se um administrador de example.com acessar a página mal-intencionada enquanto tiver uma sessão ativa no site, criará involuntariamente uma conta para o invasor. Isso é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.

Algumas estruturas incluem automaticamente nonces CSRF para proteger aplicativos. Se você desabilitar esse recurso, o aplicativo poderá ser exposto a riscos.

Exemplo 2: Esse aplicativo protegido do Spring Security desabilita explicitamente a proteção contra CSRF.

	<http auto-config="true">
        ...
        <csrf disabled="true"/>
	</http>

Uma vulnerabilidade de CSRF (falsificação de solicitações entre sites) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.



Um nonce é um valor criptográfico aleatório enviado com uma mensagem para evitar ataques de repetição. Se a solicitação não contiver um nonce que comprove sua proveniência, o código que trata a solicitação ficará vulnerável a um ataque CSRF (a menos que não altere o estado da aplicativo). Isso significa que um aplicativo da Web que usa cookies de sessão precisa tomar precauções especiais para garantir que um invasor não consiga enganar os usuários para que enviem solicitações falsas. Imagine um aplicativo da Web que permite que os administradores criem novas contas da seguinte forma:

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

Um invasor pode configurar um site mal-intencionado que contém o seguinte código.

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

Se uma administradora do example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.
A CSRF está em quinto lugar na lista dos 10 principais ataques do OWASP em 2007.

Uma vulnerabilidade de CSRF (falsificação de solicitações entre sites) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.

Um nonce é um valor aleatório criptográfico que é enviado com uma mensagem para impedir ataques de reprodução. Se a solicitação não contiver um nonce que comprove sua procedência, o código que a manipula será vulnerável a um ataque de CSRF (a menos que isso não altere o estado do aplicativo). Isso significa que um aplicativo Web que usa cookies de sessão precisa tomar precauções especiais para assegurar que um invasor não consiga enganar os usuários a ponto de que estes enviem solicitações falsas. Imagine um aplicativo Web que permite aos administradores criar novas contas enviando este formulário:

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

Um invasor pode configurar um site com o seguinte:

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

Se uma administradora do example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.

Uma vulnerabilidade de CSRF (falsificação de solicitações entre sites) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.



Um nonce é um valor aleatório criptográfico que é enviado com uma mensagem para impedir ataques de reprodução. Se a solicitação não contiver um nonce que comprove sua procedência, o código que a manipula será vulnerável a um ataque de CSRF (a menos que isso não altere o estado do aplicativo). Isso significa que um aplicativo Web que usa cookies de sessão precisa tomar precauções especiais para assegurar que um invasor não consiga enganar os usuários a ponto de que estes enviem solicitações falsas. Imagine um aplicativo Web que permite aos administradores criar novas contas enviando este formulário:

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

Um invasor pode configurar um site com o seguinte:

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

Se uma administradora do example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.

A CSRF está em quinto lugar na lista dos 10 principais ataques do OWASP em 2007.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ABAP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código ABAP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ActionScript consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + name;
  }

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código ActionScript lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável. No caso da XSS persistente, uma fonte não confiável é mais frequentemente o resultado de uma consulta de banco de dados e, no caso da XSS Refletida, uma solicitação da Web.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado geralmente é um segmento de código JavaScript, mas também pode ser HTML, Flash ou qualquer outro conteúdo ativo que possa ser executado pelo navegador. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código Apex consulta um banco de dados em busca de um nome de contato com um determinado ID e retorna o nome do funcionário correspondente, que mais tarde é impresso pelo código do Visualforce.

...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>

Esse código se comporta corretamente quando os valores de name estão bem definidos, assim como caracteres alfanuméricos, mas não faz nada para verificar se há dados mal-intencionados. Mesmo lido do banco de dados, o valor deve ser devidamente validado, pois o conteúdo do banco de dados pode ser proveniente de dados fornecidos pelo usuário. Dessa forma, um invasor pode ter comandos mal-intencionados executados no navegador da Web do usuário, sem a necessidade de interagir com a vítima como na XSS Refletida. Esse tipo de ataque, conhecido como XSS Armazenada (ou Persistente), pode ser muito difícil de detectar, pois os dados são indiretamente fornecidos para a função vulnerável e também têm um impacto maior devido à possibilidade de afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código do Visualforce lê um parâmetro de solicitação HTTP, username, e o exibe ao usuário.

<script>
document.write('{!$CurrentPage.parameters.username}')
</script>

O código neste exemplo foi concebido para receber apenas texto alfanumérico e exibir esse texto. No entanto, se username contiver metacaracteres ou código-fonte, ele será executado pelo navegador da Web.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem dois vetores por meio dos quais um ataque de XSS pode ser executado:

- Como no Example 1, o banco de dados ou outro armazenamento de dados pode fornecer dados perigosos ao aplicativo que serão incluídos no conteúdo dinâmico. Do ponto de vista do invasor, o melhor lugar para armazenar conteúdo mal-intencionado é em uma área acessível a todos os usuários, especialmente para aqueles com privilégios elevados, que são mais propensos a lidar com informações confidenciais ou realizar operações críticas.

- Como no Example 2, os dados são lidos na solicitação HTTP e refletidos de volta na resposta HTTP. A XSS Refletida ocorre quando um invasor pode ter conteúdo perigoso distribuído a um aplicativo Web vulnerável e, em seguida, refletido de volta para o usuário e executado por seu navegador. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é postada publicamente ou enviada por email diretamente para a vítima. As URLs criadas dessa forma são a essência de muitos esquemas de phishing, nos quais o invasor convence a vítima a visitar a URL. Depois que o site refletir o conteúdo de volta para o usuário, ele será executado e poderá realizar várias ações, como encaminhar informações confidenciais particulares, executar operações não autorizadas no computador da vítima, etc.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte Formulário da Web ASP.NET consulta um banco de dados em busca de um funcionário com uma ID de funcionário específica e imprime o nome correspondente a essa ID.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

Em que EmployeeName é um controle de formulário definido da seguinte maneira:

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

Exemplo 2: O seguinte segmento de código ASP.NET é funcionalmente equivalente ao Example 1, mas implementa todos os elementos de formulário programaticamente.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

Esses exemplos de código funcionam corretamente quando os valores de name apresentam um comportamento satisfatório, mas não fazem nada para impedir explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 3: O Web Form do ASP.NET a seguir lê um número de ID de funcionário de uma solicitação HTTP e o exibe para o usuário.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Em que Login e EmployeeID são controles de formulário definidos da seguinte maneira:

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

Exemplo 4: O seguinte segmento de código ASP.NET mostra a maneira programática de implementar o Example 3.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

Como no Example 1 e no Example 2, esses exemplos funcionarão corretamente se Login contiver apenas texto alfanumérico padrão. Se Login tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a clicar em um link. Quando as vítimas clicarem no link, elas reproduzirão involuntariamente o conteúdo mal-intencionado por meio do aplicativo Web vulnerável e refletido em seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1 e no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 3 e no Example 4, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Várias estruturas da Web modernas fornecem mecanismos para executar a validação de entrada do usuário (incluindo Validação de Solicitação do ASP.NET e WCF). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Com a Validação de Solicitações ASP.NET, também fornecemos evidências para quando a validação está explicitamente desabilitada. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.

2. Os dados são incluídos no conteúdo dinâmico que é enviado para um navegador da Web sem ser validado.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O segmento de código a seguir consulta um banco de dados por um funcionário com um ID específico e imprime o nome do funcionário correspondente.

...
EXEC SQL
  SELECT NAME
  INTO :ENAME
  FROM EMPLOYEE
  WHERE ID = :EID
END-EXEC.

EXEC CICS
  WEB SEND
  FROM(ENAME)
  ...
END-EXEC.
...

O código no exemplo funciona corretamente quando os valores de ENAME apresentam um comportamento satisfatório, mas não faz nada para impedir explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de ENAME é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de ENAME for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Armazenado, é especialmente insidioso porque o engano causado pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque afete vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O segmento de código a seguir lê um ID de funcionário, EID, de um formulário HTML e o exibe para o usuário.

...
EXEC CICS
  WEB READ
  FORMFIELD(ID)
  VALUE(EID)
  ...
END-EXEC.

EXEC CICS
  WEB SEND
  FROM(EID)
  ...
END-EXEC.
...

Como no Example 1, esse código funcionará corretamente se EID contiver apenas texto alfanumérico padrão. Se EID tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS armazenadas ocorrem quando um invasor

- Como no Example 2, os dados são lidos diretamente no Formulário HTML e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código CFML consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
  SELECT name
  FROM Employees 
  WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>

O código no exemplo funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para impedir explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código CFML lê uma ID de funcionário, eid, de um formulário da Web e a exibe para o usuário.

<cfoutput>
Employee ID: #Form.eid#
</cfoutput>

Como no Example 1, esse código funcionará corretamente se Form.eid contiver apenas texto alfanumérico padrão. Se Form.eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso de XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso de XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador da Web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.


Exemplo 1: O seguinte segmento de código Go lê um nome de usuário, user, de uma solicitação HTTP e o exibe para o usuário.

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

O código nesse exemplo funcionará corretamente se user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O segmento de código Go a seguir consulta um banco de dados em busca de um funcionário com determinada ID e imprime o nome do funcionário correspondente.

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como mostrado no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como mostrado no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código JSP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código JSP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Várias estruturas modernas da Web fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Struts 2). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: Este segmento de código Node.js consulta um banco de dados por um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

var http = require('http');
...

function listener(request, response){
  connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
    if (!err && rows.length > 0){
      response.write('<p>Welcome, ' + rows[0].name + '!</p>');
    }
    ...
  });
  ...
}
...
http.createServer(listener).listen(8080);

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: Este segmento de código Node.js lê uma ID do funcionário, eid, a partir de uma solicitação HTTP e a exibe ao usuário.

var http = require('http');
var url = require('url');

...

function listener(request, response){
  var eid = url.parse(request.url, true)['query']['eid'];
  if (eid !== undefined){
    response.write('<p>Welcome, ' + eid + '!</p>');
  }
  ...
}
...
http.createServer(listener).listen(8080);

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.
Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável. No caso de XSS persistente (também conhecida como armazenada) , a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso de XSS refletida, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente na resposta do servlet.

...
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O código a seguir lê uma ID de funcionário, eid, de uma solicitação de servlet HTTP e, em seguida, exibe o valor de volta para o usuário na resposta do servlet.

val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        val webview = findViewById<View>(R.id.webview) as WebView
        webview.settings.javaScriptEnabled = true
        val url = this.intent.extras!!.getString("url")
        webview.loadUrl(url)
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.


Várias estruturas da Web modernas fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Spring MVC). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados são inseridos em uma página da Web por meio de uma fonte não confiável. No caso do XSS persistente (também conhecido como armazenado), a fonte não confiável é normalmente um banco de dados ou outro repositório de dados de back-end, enquanto, no caso do XSS refletido, normalmente se dá por meio de componentes do usuário, manipuladores de esquema de URL, ou notificações externas.


2. Os dados são incluídos em um conteúdo dinâmico enviado a um componente WebView sem ser validados.


O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.



Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: Este segmento de código Objective-C lê a parte de texto de uma URL de esquema personalizado, a qual foi transmitida ao aplicativo e o invocou (myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.

...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {

    UIWebView *webView;
    NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
    [webView loadHTMLString:partAfterSlashSlash baseURL:nil]

...

Como os exemplos demonstram, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados no conteúdo HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O segmento de código PHP a seguir consulta um banco de dados para um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

<?php...
 $con = mysql_connect($server,$user,$password);
 ...
 $result = mysql_query("select * from emp where id="+eid);
 $row = mysql_fetch_array($result)
 echo 'Employee name: ', mysql_result($row,0,'name');
 ...
?>

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O segmento de código PHP a seguir lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

<?php
	$eid = $_GET['eid'];
	...
?>
...
<?php
	echo "Employee ID: $eid";
?>

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O segmento de código a seguir consulta um banco de dados por um funcionário com um ID específico e imprime o nome do funcionário correspondente.

...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
  HTP.headOpen;
    HTP.title ('Employee Information');
  HTP.headClose;
  HTP.bodyOpen;
    HTP.br;
    HTP.print('Employee Name: ' || name || '');
    HTP.br;
  HTP.bodyClose;
HTP.htmlClose;
...

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: Este segmento de código lê uma ID do funcionário, eid, a partir de uma solicitação HTTP e a exibe ao usuário.

...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
  HTP.headOpen;
    HTP.title ('Employee Information');
  HTP.headClose;
  HTP.bodyOpen;
    HTP.br;
    HTP.print('Employee ID: ' || eid || '');
    HTP.br;
  HTP.bodyClose;
HTP.htmlClose;
...

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: Este segmento de código Python lê uma ID do funcionário, eid, a partir de uma solicitação HTTP e a exibe ao usuário.

	req = self.request()  # fetch the request object
        eid = req.field('eid',None) # tainted request message
	...
	self.writeln("Employee ID:" + eid)

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: Este segmento de código Python consulta um banco de dados por um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

 ...
 cursor.execute("select * from emp where id="+eid)
 row = cursor.fetchone()
 self.writeln('Employee name: ' + row["emp"]')
 ...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.
Exemplo 1: Este segmento de código Ruby consulta um banco de dados por um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
  ...
  rs.each do |row|
    res.write("Employee name: #{escape(row['name'])}")
    ...
  end
end
...

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Os tipos alternativos de XSS podem não vir de um banco de dados, mas de outros locais prováveis de entradas do usuário. O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 2: Este segmento de código lê uma ID do funcionário, eid, a partir de uma solicitação HTTP e a exibe ao usuário.

eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
  ...
  res.write("Employee ID: #{eid}")
end

Como no Example 1, o código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos da Web vulneráveis é conhecido como XSS refletido, no entanto, observe que se você estiver usando Rack::Request#params() como no Example 2, ele verá os parâmetros GET e POST, então você pode estar vulnerável a vários tipos de outros ataques, e não apenas ter o código malicioso anexado à URL.
Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados são inseridos em uma página da Web por meio de uma fonte não confiável. No caso do XSS persistente (também conhecido como armazenado), a fonte não confiável é normalmente um banco de dados ou outro repositório de dados de back-end, enquanto, no caso do XSS refletido, normalmente se dá por meio de componentes do usuário, manipuladores de esquema de URL, ou notificações externas.


2. Os dados são incluídos em um conteúdo dinâmico enviado a um componente WebView sem ser validados.


O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.



Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: Este código lê o conteúdo de um UITextField e o exibe ao usuário dentro de um WKWebView:

...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...

O código neste exemplo operará sem problemas caso o texto noinputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém forneceria uma entrada a qual pode permitir que um código malicioso seja executado em seu próprio dispositivo? O perigo real é que um invasor pode usar email ou truques de engenharia social para atrair as vítimas a realizar tais ações. Caso isso tenha êxito, as vítimas refletem o conteúdo malicioso sem querer por meio do aplicativo web vulnerável de volta para seus próprios dispositivos. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 3: O segmento de código Swift a seguir lê parte do texto de um esquema de URL personalizado, que foi transmitido para e invocado pelo aplicativo (myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.

...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let name = getQueryStringParameter(url.absoluteString, "name")
    let html = "Hi \(name)"
    let webView = UIWebView()
    webView.loadHTMLString(html, baseURL:nil)
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...

Como os exemplos demonstram, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados no conteúdo HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O segmento de código ASP a seguir consulta um banco de dados por um funcionário com um ID específico e imprime o nome do funcionário correspondente.

        ...
        eid = Request("eid")
        strSQL = "Select * from emp where id=" & eid
        objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
        while not objRec.EOF
                Response.Write "Employee Name:" & objADORecordSet("name")
                objADORecordSet.MoveNext
        Wend
        ...

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O segmento de código ASP a seguir lê um ID de funcionário, eid, de uma solicitação HTTP e o exibe para o usuário.

	...
	eid = Request("eid")
	Response.Write "Employee ID:" & eid & "<br/>"
	..

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certos módulos de função de codificação, como cl_http_utility=>escape_html, impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se desses módulos de função de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS Refletida, uma fonte não confiável é mais frequentemente uma solicitação da Web e, no caso da XSS persistente (ou armazenada), essa fonte são os resultados de uma consulta de banco de dados.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ABAP lê uma ID de funcionário, eid, de uma solicitação HTTP, codifica essa ID em HTML e a exibe para o usuário.

...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
  EXPORTING
    UNESCAPED = eid
    KEEP_NUM_CHAR_REF = '-'
  RECEIVING
    ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O seguinte segmento de código ABAP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente codificado em HTML.

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
  EXPORTING
    UNESCAPED = itab_employees-name
    KEEP_NUM_CHAR_REF = '-'
  RECEIVING
    ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ActionScript lê uma ID de funcionário, eid, de uma solicitação HTTP, codifica essa ID em HTML e a exibe para o usuário.

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O seguinte segmento de código ActionScript consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente codificado em HTML.

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + escape(name);
  }

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Devido à grande quantidade de possíveis interações entre dados fornecidos pelo usuário e os analisadores de navegador da Web, não é sempre possível avaliar corretamente se a codificação aplicada é suficiente para proteger-se contra vulnerabilidades de XSS. Portanto, o Fortify Static Code Analyzer relata descobertas de execução de script entre sites mesmo quando uma codificação é aplicada, apresentando-as como problemas de execução de script entre sites: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, uma fonte não confiável é mais frequentemente uma solicitação da Web e, no caso da XSS persistente (ou armazenada), essa fonte são os resultados de uma consulta de banco de dados.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado geralmente é um segmento de código JavaScript, mas também pode ser HTML, Flash ou qualquer outro conteúdo ativo que possa ser executado pelo navegador. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código Apex consulta um banco de dados em busca de um nome de contato com um determinado ID e retorna o nome do funcionário correspondente, que mais tarde é impresso pelo código do Visualforce.

...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>

Esse código, apesar do uso de HTMLENCODE, não valida corretamente os dados fornecidos pelo banco de dados e é vulnerável a XSS. Isso acontece porque o conteúdo de variable é analisado por diferentes mecanismos (analisadores de HTML e Javascript) e, portanto, precisa ser codificado duas vezes. Dessa forma, um invasor pode ter comandos mal-intencionados executados no navegador da Web do usuário, sem a necessidade de interagir com a vítima como na XSS Refletida. Esse tipo de ataque, conhecido como XSS Armazenada (ou Persistente), pode ser muito difícil de detectar, pois os dados são indiretamente fornecidos para a função vulnerável e também têm um impacto maior devido à possibilidade de afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código do Visualforce lê um parâmetro de solicitação HTTP, username, e o exibe ao usuário.

<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>

O código neste exemplo foi concebido para receber apenas texto alfanumérico e exibir esse texto. No entanto, se username contiver metacaracteres ou código-fonte, ele será executado pelo navegador da Web. Além disso, neste exemplo, o uso de HTMLENCODE não é suficiente para prevenir o ataque de XSS, já que a variável é processada pelo analisador de Javascript.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem dois vetores por meio dos quais um ataque de XSS pode ser executado:

- Como no Example 1, o banco de dados ou outro armazenamento de dados pode fornecer dados perigosos ao aplicativo que serão incluídos no conteúdo dinâmico. Do ponto de vista do invasor, o melhor lugar para armazenar conteúdo mal-intencionado é em uma área acessível a todos os usuários, especialmente para aqueles com privilégios elevados, que são mais propensos a lidar com informações confidenciais ou realizar operações críticas.

- Como no Example 2, os dados são lidos na solicitação HTTP e refletidos de volta na resposta HTTP. A XSS Refletida ocorre quando um invasor pode ter conteúdo perigoso distribuído a um aplicativo Web vulnerável e, em seguida, refletido de volta para o usuário e executado por seu navegador. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é postada publicamente ou enviada por email diretamente para a vítima. As URLs criadas dessa forma são a essência de muitos esquemas de phishing, nos quais o invasor convence a vítima a visitar a URL. Depois que o site refletir o conteúdo de volta para o usuário, ele será executado e poderá realizar várias ações, como encaminhar informações confidenciais particulares, executar operações não autorizadas no computador da vítima, etc.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ASP.NET lê um número de ID de funcionário de uma solicitação HTTP, codifica esse número em HTML e o exibe para o usuário.

<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>

Em que Login e EmployeeID são controles de formulário definidos da seguinte maneira:

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

Exemplo 2: O seguinte segmento de código ASP.NET implementa a mesma funcionalidade que o Example 1, ainda que de forma programática.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);

O código nesses exemplos funcionará corretamente se Login contiver apenas texto alfanumérico padrão. Se Login tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a clicar em um link. Quando as vítimas clicarem no link, elas reproduzirão involuntariamente o conteúdo mal-intencionado por meio do aplicativo Web vulnerável e refletido em seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 3: O seguinte segmento de código ASP.NET consulta um banco de dados em busca de um funcionário com uma ID de funcionário específica e imprime o nome codificado em HTML correspondente a essa ID.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>

Em que EmployeeName é um controle de formulário definido da seguinte maneira:

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

Exemplo 4: De mesma forma, o seguinte segmento de código ASP.NET é funcionalmente equivalente ao Example 3, mas implementa todos os elementos de formulário programaticamente.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);

Como no Example 1 e no Example 2, esses segmentos de código são executados corretamente quando os valores de name apresentam um comportamento satisfatório, mas não fazem nada para evitar na ausência desse comportamento. Mais uma vez, esses exemplos de código podem parecer menos perigosos porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1 e no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3 e no Example 4, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Várias estruturas da Web modernas fornecem mecanismos para executar a validação de entrada do usuário (incluindo Validação de Solicitação do ASP.NET e WCF). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Com a Validação de Solicitações ASP.NET, também fornecemos evidências para quando a validação está explicitamente desabilitada. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS Refletida, uma fonte não confiável é mais frequentemente uma solicitação da Web e, no caso da XSS persistente (ou armazenada), essa fonte são os resultados de uma consulta de banco de dados.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O segmento de código a seguir lê no parâmetro text de uma solicitação HTTP, codifica esse parâmetro em HTML e o exibe em uma caixa de alerta entre tags de script.

	"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";

O código nesse exemplo 1 funcionará corretamente se text contiver apenas texto alfanumérico padrão. Se text tiver uma aspa simples, um parêntese e um ponto-e-vírgula, ele terminará a caixa de texto alert e, em seguida, o código será executado.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- O aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (cross-site scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso de XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso de XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador da Web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.


Exemplo 1: O seguinte segmento de código Go lê um nome de usuário, user, de uma solicitação HTTP e o exibe para o usuário.

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}

O código nesse exemplo funcionará corretamente se user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O segmento de código Go a seguir consulta um banco de dados em busca de um funcionário com determinada ID e imprime o nome do funcionário correspondente.

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", html.EscapeString(name))
}

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como mostrado no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como mostrado no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas construções de codificação, como a tag <c:out/> com o atributo escapeXml="true" (o comportamento padrão), evita alguns ataques de criação de scripts entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, poderão assumir um metassentido. Valer-se dessas construções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado, que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados são exibidos estaticamente, o Fortify Static Code Analyzer relata descobertas de criação de script entre sites mesmo quando uma codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS Refletida, uma fonte não confiável é mais frequentemente uma solicitação da Web e, no caso da XSS persistente (ou armazenada), essa fonte são os resultados de uma consulta de banco de dados.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código JSP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário por meio da tag <c:out/>.

Employee ID: <c:out value="${param.eid}"/>

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O seguinte segmento de código JSP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente por meio da tag <c:out/>.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <c:out value="${name}"/>

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(URLEncoder.encode(url));
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Várias estruturas modernas da Web fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Struts 2). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como problemas de Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso do XSS baseado em DOM, os dados são lidos a partir de um parâmetro de URL ou de outro valor dentro do navegador e gravados de volta na página com o código do lado do cliente. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação. No caso do XSS baseado em DOM, o conteúdo malicioso é executado como parte da criação do DOM (Document Object Model) sempre que o navegador da vítima analisar a página HTML.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo: Este segmento de código JavaScript lê uma ID do funcionário, eid, a partir de uma solicitação HTTP e a exibe ao usuário.

<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como o exemplos demonstra, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- O aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas construções de codificação, como a tag <c:out/> com o atributo escapeXml="true" (o comportamento padrão), evita alguns ataques de criação de scripts entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, poderão assumir um metassentido. Valer-se dessas construções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado, que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados são exibidos estaticamente, o Fortify Static Code Analyzer relata descobertas de criação de script entre sites mesmo quando uma codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-site scripting) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável. No caso de XSS Refletida, uma fonte não confiável é mais frequentemente uma solicitação da Web. No caso de XSS Persistente (também conhecida como armazenada), são os resultados de uma consulta ao banco de dados.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.



O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.



Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        val webview = findViewById<View>(R.id.webview) as WebView
        webview.settings.javaScriptEnabled = true
        val url = this.intent.extras!!.getString("url")
        webview.loadUrl(URLEncoder.encode(url))
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.


Várias estruturas da Web modernas fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Spring MVC). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

O uso de certas construções de codificação, como ESAPI ou AntiXSS, impedirá alguns, mas nem todos os ataques de criação de script entre sites. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, &, e ", que são codificados em HTML, e aqueles além de <, >, &,", e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas construções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado, que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados são exibidos estaticamente, o Fortify Static Code Analyzer relata descobertas de criação de script entre sites mesmo quando uma codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados são inseridos em uma página da Web por meio de uma fonte não confiável. No caso de XSS refletido, a fonte não confiável é, normalmente, por meio de componentes do usuário, manipuladores de esquema de URL ou notificações, enquanto que, no caso do XSS persistente (também conhecido como armazenado), essa fonte é, normalmente, um banco de dados ou outro repositório de dados de back-end.


2. Os dados são incluídos em um conteúdo dinâmico enviado a um componente WebView sem ser validados.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Estes exemplos destacam instâncias XSS exploráveis codificadas usando uma API de codificação:

Exemplo 1: Este segmento de código Objective-C lê a parte de texto de uma URL de esquema personalizado, a qual foi transmitida ao aplicativo e o invocou (myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.

...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
    UIWebView *webView;
    NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
                         [DefaultEncoder encodeForHTML:partAfterSlashSlash],
			 @"')\" />"];
    webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
    [webView loadHTMLString:htmlPage baseURL:nil];
...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Novamente, esse código pode parecer menos perigoso porque o valor name é lido de um banco de dados e é codificado em HTML. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. O ataque feito pelo invasor poderia ignorar os caracteres codificados ou colocar uma entrada em um contexto que não seja afetado pela codificação HTML. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como os exemplos demonstram, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados no conteúdo HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de determinadas funções de codificação, como htmlspecialchars() ou htmlentities(), impedirá alguns, mas não todos os ataques cross-site scripting. Dependendo do contexto em que os dados são apresentados, os caracteres diferentes dos básicos <, >, & e " que são codificados em HTML, e aqueles além de <, >, &, " e ' (somente quando ENT_QUOTES está definido), que estão codificados em XML podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como problemas de Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS Refletida, uma fonte não confiável é mais frequentemente uma solicitação da Web e, no caso da XSS persistente (ou armazenada), essa fonte são os resultados de uma consulta de banco de dados.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O segmento de código a seguir lê no parâmetro text de uma solicitação HTTP, codifica esse parâmetro em HTML e o exibe em uma caixa de alerta entre tags de script.

<?php
    $var=$_GET['text'];
    ...
    $var2=htmlspecialchars($var);
    echo "<script>alert('$var2')</script>";
?>

O código nesse exemplo 1 funcionará corretamente se text contiver apenas texto alfanumérico padrão. Se text tiver uma aspa simples, um parêntese e um ponto-e-vírgula, ele terminará a caixa de texto alert e, em seguida, o código será executado.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- O aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: Este segmento de código lê uma ID do funcionário, eid, a partir de uma solicitação HTTP, a codifica em URL, e a exibe ao usuário.

...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
  HTP.headOpen;
    HTP.title ('Employee Information');
  HTP.headClose;
  HTP.bodyOpen;
    HTP.br;
    HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
    HTP.br;
  HTP.bodyClose;
HTP.htmlClose;
...

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: Este segmento de código consulta um banco de dados por um funcionário com uma determinada ID e imprime o nome do funcionário correspondente codificado em URL.

...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
  HTP.headOpen;
    HTP.title ('Employee Information');
  HTP.headClose;
  HTP.bodyOpen;
    HTP.br;
    HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
    HTP.br;
  HTP.bodyClose;
HTP.htmlClose;
...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: Este segmento de código Python lê uma ID do funcionário, eid, a partir de uma solicitação HTTP, a codifica em HTML, e a exibe ao usuário.

        req = self.request()  # fetch the request object
        eid = req.field('eid',None) # tainted request message
        ...
        self.writeln("Employee ID:" + escape(eid))

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: Este segmento de código Python consulta um banco de dados por um funcionário com uma determinada ID e imprime o nome do funcionário correspondente codificado em HTML.

 ...
 cursor.execute("select * from emp where id="+eid)
 row = cursor.fetchone()
 self.writeln('Employee name: ' + escape(row["emp"]))
 ...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: Este segmento de código lê uma ID do funcionário, eid, a partir de uma solicitação HTTP, a codifica em HTML, e a exibe ao usuário.

eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
  ...
  res.write("Employee ID: #{eid}")
end

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos da Web vulneráveis é conhecido como XSS refletido, no entanto, observe que se você estiver usando Rack::Request#params() como no Example 1, ele verá os parâmetros GET e POST, então você pode estar vulnerável a vários tipos de outros ataques, e não apenas ter o código malicioso anexado à URL.

Exemplo 2: Este segmento de código consulta um banco de dados por um funcionário com uma determinada ID e imprime o nome do funcionário correspondente codificado em HTML.

...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
  ...
  rs.each do |row|
    res.write("Employee name: #{escape(row['name'])}")
    ...
  end
end
...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada de todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de determinadas construções de codificação, como ESAPI ou AntiXSS, impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, &, e ", que são codificados em HTML, e aqueles além de <, >, &,", e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas construções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado, que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados são exibidos estaticamente, o Fortify Static Code Analyzer relata descobertas de criação de script entre sites mesmo quando uma codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados são inseridos em uma página da Web por meio de uma fonte não confiável. No caso de XSS refletido, a fonte não confiável é, normalmente, por meio de componentes do usuário, manipuladores de esquema de URL ou notificações, enquanto que, no caso do XSS persistente (também conhecido como armazenado), essa fonte é, normalmente, um banco de dados ou outro repositório de dados de back-end.


2. Os dados são incluídos em um conteúdo dinâmico enviado a um componente WebView sem ser validados.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Estes exemplos destacam instâncias XSS exploráveis codificadas usando uma API de codificação:

Exemplo 1: O segmento de código Swift a seguir lê parte do texto de um esquema de URL personalizado, que foi transmitido para e invocado pelo aplicativo (myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.

...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let name = getQueryStringParameter(url.absoluteString, "name")
    let html = "Hi \(name)"
    let webView = UIWebView()
    webView.loadHTMLString(html, baseURL:nil)
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Novamente, esse código pode parecer menos perigoso porque o valor name é lido de um banco de dados e é codificado em HTML. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. O ataque feito pelo invasor poderia ignorar os caracteres codificados ou colocar uma entrada em um contexto que não seja afetado pela codificação HTML. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 3: Este código lê o conteúdo de um UITextField e o exibe ao usuário dentro de um WKWebView:

...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...

O código neste exemplo operará sem problemas caso o texto noinputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém forneceria uma entrada a qual pode permitir que um código malicioso seja executado em seu próprio dispositivo? O perigo real é que um invasor pode usar email ou truques de engenharia social para atrair as vítimas a realizar tais ações. Caso isso tenha êxito, as vítimas refletem o conteúdo malicioso sem querer por meio do aplicativo web vulnerável de volta para seus próprios dispositivos. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como os exemplos demonstram, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados no conteúdo HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 3, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

O uso de certas funções de codificação impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ASP lê um ID de funcionário, eid, de uma solicitação HTTP, a codifica em HTML e a exibe para o usuário.

        ...
        eid = Request("eid")
        Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
        ..

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O segmento de código ASP a seguir consulta um banco de dados por um funcionário com um ID específico e imprime o nome do funcionário correspondente codificado em HTML.

        ...
        eid = Request("eid")
        strSQL = "Select * from emp where id=" & eid
        objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
        while not objRec.EOF
                Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
                objADORecordSet.MoveNext
        Wend
        ...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ABAP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O seguinte segmento de código ABAP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ActionScript lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O seguinte segmento de código ActionScript consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + name;
  }

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.