Práticas recomendadas de segurança JSON?

Ao pesquisar a questão do JSON vs XML , me deparei com essa questão . Agora, uma das razões para preferir o JSON foi listada como a facilidade de conversão em Javascript, ou seja, com o eval() . Agora, isso imediatamente me pareceu potencialmente problemático do ponto de vista da segurança.

Então, comecei a fazer uma pesquisa sobre os aspectos de segurança do JSON e em todo este post sobre como o JSON não é tão seguro quanto as pessoas acham que é . Esta parte ressaltou:

Atualização: Se você estiver fazendo JSON 100% corretamente, você terá apenas objects no nível superior. Arrays, Strings, Numbers, etc serão todos embrulhados. Um object JSON falhará em eval () porque o interpretador JavaScript pensará que está olhando para um bloco em vez de um object. Isso ajuda muito na proteção contra esses ataques, mas ainda é melhor proteger seus dados seguros com URLs imprevisíveis.

Ok, essa é uma boa regra para começar: objects JSON no nível superior sempre devem ser objects e nunca arrays, números ou strings. Soa como uma boa regra para mim.

Existe mais alguma coisa para fazer ou evitar quando se trata de segurança relacionada a JSON e AJAX?

A última parte da citação acima menciona URLs imprevisíveis. Alguém tem mais informações sobre isso, especialmente como você faz isso em PHP? Eu sou muito mais experiente em Java do que PHP e em Java é fácil (em que você pode mapear toda uma gama de URLs para um único servlet) enquanto que todo o PHP que eu fiz mapeou uma única URL para o script PHP.

Além disso, como exatamente você usa URLs imprevisíveis para aumentar a segurança?

A principal falha de segurança do blog (CSRF) não é específica do JSON. É tão grande buraco usando XML em vez disso. De fato, é tão ruim quanto nenhuma chamada assíncrona; ligações regulares são tão vulneráveis.

Quando as pessoas falam sobre URLs únicos, elas geralmente não significam http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement . Em vez disso, é mais comum fazer algo diferente sobre a solicitação única; ou seja, um valor na postagem FORM ou um parâmetro de URL.

Normalmente, isso envolve um token random inserido no FORM no lado do servidor e, em seguida, verificado quando uma solicitação é feita.

A coisa array / object é novidade para mim:

Script-Tags: O atacante pode incorporar uma tag de script apontando para um servidor remoto e o navegador irá efetivamente eval () a resposta para você, no entanto, ele joga fora a resposta e como JSON é toda resposta, você está seguro.

Nesse caso, seu site não precisa usar o JSON para ser vulnerável. Mas sim, se um invasor puder inserir HTML random em seu site, você será brinde.

Há vários ataques de segurança contra o JSON, especialmente o XSRF.

A vulnerabilidade ocorre quando um serviço da Web usa cookies para autenticação e responde com um array JSON contendo dados confidenciais em resposta a uma solicitação GET.

Se um invasor puder enganar um usuário que esteja conectado a um serviço, naive-webapp.com, a visitar o site (ou qualquer site que incorpore um IFRAME que ele controle, por exemplo, por meio de anúncios incorporados), ele poderá inserir uma tag com um SRC ao naive-webapp.com e, potencialmente, roubar os dados do usuário. Isso depende de uma peculiaridade do javascript com o construtor JavaScript Array como este:

      

O EcmaScript 5 corrigiu o comportamento confuso que causou o [] a procurar o Array no object global e muitos navegadores modernos não são mais suscetíveis a este ataque.

Aliás, o petróleo está errado sobre URLs imprevisíveis. Identificadores randoms criptograficamente seguros em URLs são uma ótima maneira de proteger resources. A segurança baseada em identidade não é uma panacéia, como sugere a Oil. Consulte http://waterken.sourceforge.net/ para obter um exemplo de um esquema de aplicativo distribuído seguro com base em identificadores criptograficamente seguros em URLs que não exigem um conceito de identidade.

EDITAR:

Ao considerar o JSON vs XML, você também deve estar ciente dos vetores de ataque específicos de XML.

XXE , ataques de entidades externas XML, usam o XML criado para acessar o sistema de arquivos e os resources de rede por meio do firewall.

  ]> ... &foo; 

O aplicativo incorpora a input (parâmetro "in", que contém o arquivo win.ini) à resposta do serviço da web.

ainda é melhor proteger seus dados seguros com URLs não previsíveis.

Ênfase minha. Que absurdo! É melhor proteger seus dados seguros com alguma autenticação adequada e possivelmente alguma criptografia além disso. As trocas de JSON ainda podem usar técnicas de autenticação existentes (por exemplo, sessões por meio de cookies) e SSL.

Confiar em alguém que não adivinhe uma URL (o que está efetivamente falando) será apenas uma técnica razoável (e, mesmo assim, apenas) quando você estiver usando o JSON para exportar dados para um terceiro anônimo (por exemplo, um serviço da web) . Um exemplo é a API de serviço da web do Google, na qual usuários anônimos acessam os dados do Google por meio de outros sites. Eles usam o referenciador de domínio e as chaves de API para garantir que o site man-in-the-middle tenha permissão para fornecer dados do Gooogle.

Se você estiver usando apenas o JSON para enviar dados privados de e para um agente do usuário conhecido e direto, use autenticação e criptografia reais. Se você está tentando fornecer um serviço da Web, isso realmente depende de quão “seguros” serão esses dados. Se forem apenas dados públicos e você não se importar com quem pode lê-los, não vejo sentido em criar um URL hash.


Edit: para demonstrar o que eles significam, considere isso. Imagine que seu banco forneceu uma API JSON para obter extratos. Se eu pudesse digitar http://yourbank.com/json-api/your-name/statement , você provavelmente não ficaria muito satisfeito.

Eles poderiam gerar uma string única para sua conta que era necessária em qualquer solicitação JSON, por exemplo: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement

Eu teria muito menos chance de ser capaz de adivinhar isso. Mas você realmente quer que esse seja o único amortecedor entre seus dados genuinamente seguros e potenciais ladrões de identidade? Não.