Acessibilidade
Refere a prática de inclusão em fazer com que os sites web possa ser usado por até mesmo pessoas que não tenham habilidade de navegação. Quando sites são corretamente projetados, desenvolvidos e editados, qualquer usuários podem ter acessos igualitários à informação e à funcionalidade.
Supondo que o usuário não tenha habilidade de execução do lado do cliente web, o código deve ser escrito para que visitantes tenham melhores experiências, mesmo com usuários com deficiência visual ou física e, certamente, deve-se evitar negar informações para estes visitantes.Os leitores de tela, utilizados por cegos e deficientes visuais, pode ser reconhecedores de JavaScript e assim podem acessar e ler a página DOM após o script alterá-lo.
O HTML deve ser o mais conciso, navegável e semanticamente o mais rico possível, queira os scripts sejam executado ou não.
JavaScript não deve ser totalmente dependente de mouse ou eventos específicos do teclado, pois um usuário pode ser fisicamente incapaz de usar esses dispositivos de entrada. Por esta razão, os eventos de dispositivos agnósticos (componentes que trabalham em vários sistemas sem requerer alguma especial adaptação) como onfocus e onchange são preferíveis aos eventos centrados no dispositivo, como onmouseover e onkeypress na maioria dos casos.
JavaScript não deve ser utilizado de uma forma que seja confuso ou desorientador para qualquer usuário da web. Por exemplo, é melhor evitar usar script para alterar ou desabilitar a funcionalidade normal do navegador, como alterando a forma como os botões "back" ou "refresh" funcionam.
Igualmente, desencadeando eventos em que o usuário não esteja ciente reduzirá o sentido controle do usuário, como mudanças inesperadas de script do conteúdo da página.
Muitas vezes, o processo de fazer com que uma complexa página web seja o mais acessível possível torna-se um problema não trivial,em que as questões se tornam assuntos de debate e de opiniões, e onde compromissos são necessários no final das conta.
SEGURANÇA
JavaScript e DOM fornecem possibilidade de autores maliciosos entregarem os scripts a serem executados em um computador de cliente através da web.Fornecedores de navegadores impedem esse risco usando duas restrições.
Primeiro, scripts são executados em uma sadbox (modo privativo de virtualização) na qual só lhe é permitido executar ações relacionadas à web, e não tarefas de programação de uso geral, como a criação de arquivos.
Em segundo lugar, os scripts são restringidos pela política da mesma-origem(estrita separação entre conteúdo fornecido por sites não autorizados): os scripts de um site não têm acesso a informações como nomes de usuários, senhas ou cookies enviados para outro local.
A maioria dos bugs de segurança relacionados com JavaScript são violações de qualquer das política da mesma-origem ou a sadbox.
Existem subconjuntos de JavaScript em geral - ADsafe, ECMA Script Seguro (SES) -, que oferecem maior nível de segurança, especialmente no código criado por terceiros (como anúncios).
O conteúdo de Política de Segurança é o principal método pretendido de assegurar que somente código confiável é executado em uma página web.
Vulnerabilidade a Cross-Sites
Um problema de segurança comum relacionado com o JavaScript é o script de cross-sites XSS, que pode ser utilizado por atacantes para contornar os controles de acesso, uma violação da política da mesma-origem. Isto permite que atacantes injetem script do lado do cliente em páginas vistas por outros usuários.
A vulnerabilidades a XSS ocorrem quando se é capaz de causar um ataque ao site de destino, como um site de banco on-line, podendo incluir um script malicioso na página web apresentada à vítima. O script neste exemplo pode então acessar o aplicativo bancário com os privilégios da vítima, potencialmente revelando informações secretas ou a transferência de dinheiro sem a autorização da vítima. Uma solução para as vulnerabilidades XSS é usar HTML para escape sempre que a exibição de dados não sejam confiáveis.
Alguns navegadores incluem proteção parcial contra ataques refletidos de XSS, em que o atacante fornece uma URL incluindo script malicioso. No entanto, até mesmo os usuários desses navegadores são vulneráveis a outros ataques XSS, como aqueles onde o código malicioso é armazenado em um banco de dados.
Apenas projetos corretos de aplicações webs no lado do servidor podem impedir totalmente XSS .A vulnerabilidades XSS também pode ocorrer por causa de erros de implementação de autores navegador.
Cross-Sites Request Forgery
Outra vulnerabilidade a cross-site é as requisições falsificadas de sites cruzados (cross-site request forgery ou CSRF). No CSRF, o truque do atacante é o código local no navegador da vítima, em que é levado a ações que o usuário não tem intenção de tomar em um site alvo (como a transferência de dinheiro em um banco). Ele funciona porque, se o site de destino depende apenas de cookies para autenticar as solicitações, então as solicitações falsificadas iniciadas pelo código no site do invasor vai levar as mesmas credenciais dos logins legítimos, como se fossem solicitações verdadeiras iniciadas pelo usuário.
Em geral, a solução para CSRF é exigir um valor de autenticação em um campo de formulário oculto para autenticar qualquer pedido que possa ter efeitos duradouros, e não apenas nos cookies. Verificação ao cabeçalho referente ao HTTP também pode ajudar.
JavaScript Hijacking
"Sequestro JavaScript" é um tipo de ataque CSRF no qual um tag <script> no local do atacante explora uma página no site da vítima que retorna informações pessoais, como JSON ou JavaScript. As soluções possíveis incluem :
- exigir um token de autenticação no POST e obter parâmetros para qualquer resposta que retorna informação privada.
- usando POST e nunca GET para os pedidos que retornam informações privadas.
Perdendo A Confiança No Cliente.
Os desenvolvedores de aplicações cliente-servidor devem reconhecer que os clientes, mesmo confiáveis, podem estar sob o controle dos atacantes.
Os desenvolvedores dos aplicativos não pode assumir que o seu código JavaScript será executado como pretendido (ou em todos), porque qualquer segredo embutido no código poderia ser extraído por um adversário determinado a isto.
Algumas implicações são:
- Desenvolvedores de sites não podem ocultar perfeitamente como o seu JavaScript funciona porque o código fonte de matéria deve ser enviada para o cliente. O código poderia ser ofuscado, mas ofuscação pode ser contornada com engenharia reversa.
- A validação de formulário JavaScript só oferece conveniência para os usuários, e não de segurança. Se um site verifica se o usuário concordou com seus termos de serviço, ou filtra caracteres inválidos de campos que deve conter apenas números, deve fazê-lo no servidor, não apenas no cliente.
- Scripts podem ser desativadas de forma seletiva, pelo que o JavaScript não pode ser invocado para impedir que operações como botão direito do mouse em uma imagem possa salvá-lo.
- É extremamente má prática incorporar informações confidenciais como senhas em JavaScript, porque pode ser extraído por um invasor.
Nenhum comentário:
Postar um comentário