Cross-Site History Manipulation (XSHM)

Este tipo de ataque explora falhas de segurança na politica SOP (same origin policy). SOP é o conceito de segurança mais importante dos browsers modernos. Esta política diz que, páginas web de diferentes origens, por padrão, não podem comunicar-se entre si.
XSHM é baseado no fato de que os objetos de browser no client-side não são segmentados em uma base por site. Manipulando o histórico do browser, pode fazer com que o SOP seja comprometido, permitindo que CSRF’s bi-direcionais aconteçam, ocasionando diversos riscos como:
- violação da privacidade de usuários;
- login status detection;
- mapeamento de recursos, entre outros

Informações Inferência

É possível a inferência de informações sigilosas de uma página em uma origem diferente, se implementar num redirecionamento condicional. Suponha que em um aplicativo de RH que não seja publicamente acessível, onde o usuário pode pesquisar empregados por nome, salário e outros critérios. Se a pesquisa não tem nenhum resultado, um comando de redirecionamento é executado com um "Not Found" página. Ao apresentar a seguinte URL:

http://Intranet/SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500

e observando o redirecionamento NotFound, os atacantes podem inferir informações sensíveis sobre o salário de um trabalhador.
Isso pode ser feito usando o vetor de ataque que se segue:

1. Criar um IFRAME com src = "NotFound.aspx"
2. Lembre-se o valor atual da history.length
3. Alterar src do IFRAME para "SearchEmployee.aspx? Name = Jon& SalaryFrom = 3000 = 3500 & SalaryTo"
4. Se o valor da history.length permanece o mesmo, então sua pesquisa não tem resultados

Ao repetir o ataque acima e tentar diferentes valores de salário, um atacante pode reunir informações detalhadas de qualquer funcionário. Este é um vazamento de informação muito séria Cross-Site. Se um aplicativo tem uma função como uma página de pesquisa com redirecionamento condicional, então esta aplicação é vulnerável a XSHM e, essencialmente, é semelhante a uma exposição direta à Universal XSS – a aplicação em si é XSS-safe, mas executá-la a partir de um site diferente dentro de um IFRAME, torna vulnerável.
Exemplo - Condition Leakage
Condition leakage ocorre quando um atacante pode injetar valores sensíveis de um determinado conditional statement na aplicação atacada. Por exemplo, se um site utiliza a seguinte lógica:
Página A: se (condição) – Redireciona (página B)
Um atacante pode executar um Cross-site Request Fogery (já falado em outros artigos) e conseguir uma indicação sobre o valor da condição existente como feedback. Este ataque é executado a partir de um site atacante. O site então envia um Cross-site Request para o site vítima, e manipulando o History Object, obtem um feedback sobre a informação requerida que o site vitima irá expor.
Vetor de Ataque
1. Criar um IFRAME com src=Pagina B
2. Salve o valor atual do history.lenght
3. Modifique o src do IFRAME para página A
4. Se o valor do history.lenght for o mesmo, isso quer dizer que a condição é verdadeira.

Protegendo a aplicação
Para conseguir uma proteção eficiente contra XSHM, ambas as URLs do site de origem e a que será redirecionada, devem conter um token randomico. Por exemplo, redirecionando para uma pagina de Login, será seguro apenas no seguinte caso:

If ( !isAuthenticated)
Redirect(„Login.aspx?r=? + Random())

Para previnir um ataque de URL/Parameter enumeration, qualquer URL deve conter um forte token randomico.