Devo estar usando um SPA JavaScript projetado quando a segurança é importante

5

Perguntei algo parecido no stackoverflow com uma parte específica do código, mas quero tentar fazer isso em um sentido mais amplo.

Portanto, eu tenho este aplicativo da web que comecei a escrever no backbone usando uma Arquitetura de Página Única (SPA), no entanto, estou começando a adivinhar a mim mesmo por causa da segurança. Agora, não estamos armazenando e enviando informações de cartão de crédito ou algo assim por meio deste aplicativo da Web, mas armazenamos informações confidenciais que as pessoas estão enviando para nós e também poderemos fazer o download novamente.

A óbvia preocupação de segurança que tenho com o JavaScript é que você não pode confiar em nada que venha do JavaScript, mas em um aplicativo do Backbone SPA, tudo está sendo enviado por meio do JavaScript. Existem dois recursos de segurança que terei que construir em JavaScript; permissões e autenticação.

A parte de autenticação é apenas eu substituir o método Backbone.Router.prototype.navigate para verificar o fragmento que está tentando carregar e se o JavaScript application.session.loggedIn não está definido como verdadeiro (e eles não estão exibindo nenhum página autenticada), eles são redirecionados para a página de login automaticamente. O usuário poderia facilmente modificar o application.session.loggedIn para o mesmo valor true (ou modificar o método Backbone.Router.prototype.navigate), mas eles também não teriam que inserir dinamicamente um link na página (ou modificar um atual) tem as classes apropriadas, data- * attributes e valores href para então carregar uma página que só deve ser carregada quando o usuário tiver efetuado login (e tiver as permissões).

Portanto, eu tenho um objeto acl que lida com o material das permissões. Tudo o que alguém teria que fazer para visualizar páginas ou partes de páginas que não deveria poder é chamar acl.addPermission (recurso, permissão) com as permissões apropriadas ou modificar o acl.hasPermission () para sempre retornar true e depois sair e depois de volta para a página.

Agora, certas coisas é que o EMCAScript 5, como Object.seal () ou Object.freeze () ajudaria em algumas dessas, mas temos que suportar o IE 8, que não suporta essas partes de funcionalidade.

Agora, a API REST também realiza verificações de segurança em todas as solicitações de maneira técnica, mesmo que consigam ver partes da interface que não devem conseguir, mas ainda assim não devem poder afetar os dados.

Os principais benefícios para mim no desenvolvimento de um aplicativo JavaScript SPA são que o aplicativo é muito mais responsivo, pois está apenas transferindo a quantidade mínima de dados JSON para a ação solicitada e executando a quantidade mínima de trabalho também. Há também outras coisas que eu acho que são benéficas, como você vai ter que desenvolver uma API para os dados (o que é bom se você quiser expandir seu aplicativo para diferentes plataformas / tecnologias) ou a separação entre front-end e back-end, no entanto, se a segurança é uma preocupação, é realmente sensato ir no caminho de um aplicativo JavaScript SPA para o front-end?

    
por ryanzec 17.09.2012 / 18:27
fonte

2 respostas

2

Eu não confiaria no javascript do lado do cliente para informar se o usuário está logado. Isso pode ser facilmente alterado.

Nas duas vezes em que fiz interfaces web do tipo 'página única', fiz isso com duas 'páginas'. A primeira página encontrada foi uma página de login. Quando submetido, isso permitia a criação de uma sessão web tradicional no servidor e, em seguida, retornava a página 'application', que então carregava imediatamente tudo por solicitações ajax. Para todas as chamadas subseqüentes do ajax, o cookie foi enviado com a solicitação, então a autenticação funcionou da mesma maneira que nos aplicativos tradicionais. Portanto, não há nada específico que você precise fazer diferente em seu javascript para suportar isso. Cada resposta do lado do servidor deve, obviamente, validar a sessão.

Eu digo duas 'páginas', mas elas eram realmente as mesmas 'index.php' - ele apenas retornava uma página de login ou a página principal do aplicativo, dependendo se um 'login' válido foi definido na sessão do lado do servidor . No seu caso, você teria apenas o retorno de dois modelos de página diferentes.

    
por 17.09.2012 / 20:18
fonte
2

O SPA pode ser tão seguro quanto qualquer aplicativo da web. Eles não são menos seguros. Você tem muitas opções dependendo de seus requisitos de segurança. Alguns são discutidos nesta Pergunta do Security StackExchange . Há muita orientação na web para proteger os SPAs. Estou trabalhando em um projeto do SPA em que estamos usando uma combinação de autenticação básica e cookies para manter a identidade da sessão no servidor. Cada chamada para uma API REST para os métodos AJAX é autorizada no servidor. Se as autorizações falhar, retornamos um erro HTTP Proibido para o cliente e o manipulamos de acordo. Podemos ainda manter um aplicativo de página única usando uma caixa de diálogo modal da interface do usuário do jQuery para efetuar logon. Eu não manteria informações de sessão específicas para identidade no cliente ou definir permissões no cliente. E, claro, você ainda deseja usar HTTPS / SSL para proteger os dados na transmissão.

    
por 18.10.2012 / 21:38
fonte