Segurança de Aplicativos

Os principais controles de segurança apresentados pelo Firefox OS são:

• Aplicativos Web são instalados e executados explicitamente, ao invés de serem simplesmente abertos em um navegador. Os aplicativos precisam ser instalados antes de serem utilizados, a atualização e remoção de aplicativos são reguladas por controles de segurança para proteger o usuário.
• Acesso a novas APIs Web são controladas por um sistema de permissões. O aplicativo precisa declarar as permissões que pretende usar antes da instalação. Para receber acesso a APIs mais poderosas, o aplicativo precisa atender certos requisitos, ser revisado, aprovado e assinado por um Marketplace.
• Aplicativos Web são isolados (sandboxed) de maneira que somente tem acesso aos seus próprios recursos (cookies, offline storage, bases de dados IndexedDB, e etc.). Mesmo se dois aplicativos vierem a carregar a mesma URL, essas duas páginas não são consideradas sendo de mesma origem pois estão executando dentro de aplicativos separados.

Tipos de aplicativos

O FirefoxOS suporta três tipos de aplicativos: "web", "privilegiado" e interno ("Certificado"). O tipo de um aplicativo é declarado no seu arquivo de manifesto e determina a lista de permissões que o aplicativo pode solicitar.

• Aplicativos Web: A maioria dos aplicativos de terceiros serão "web", que é o tipo padrão, não concedendo o aplicativo nenhuma permissão extra além daquelas já expostas para Web. Aplicativos Web podem ser instalados de qualquer site, sem nenhuma verificação adicional. Eles também podem ser empacotados (packaged) , empacotar não concede nenhuma permissão adicional.
• Aplicativos Privilegiados: Estes aplicativos podem solicitar permissões mais elevadas, por esse motivo eles precisam ser verificados e assinados por um Marketplace.
• Aplicativos Internos/Certificados: No momento este tipo de aplicativo somente pode vir pré-instalado no dispositivo, a escolha do fabricante.

Distribuição dos aplicativos

No Firefox OS os aplicativos podem ser distribuídos de duas formas diferentes: Sendo Hospedados ou Empacotados. Aplicativos "web" podem ser distribuídos por qualquer dos meios, sendo que os privilegiados e certificados precisam necessariamente ser empacotados.

Aplicativos hospedados

Um aplicativo hospedado consiste basicamente de um arquivo manifesto do aplicativo no servidor web do desenvolvedor, este contém um caminho de execução indicando que pagina deve ser aberta quando o aplicativo é inicializado. De uma perspectiva de segurança aplicativos hospedados funcionam de forma muito parecida com paginas web normais. Quando um aplicativo hospedado é carregado as URLs das paginas carregadas são as URLs normais onde aquelas paginas são acessadas no servidor onde estão hospedadas, mas se elas já estiverem no appcache elas serão carregadas do dispositivo.

Aplicativos empacotados

Um aplicativo empacotado é simplesmente uma aplicação web aberta que tem todo o seu conteudo como arquivos HTML, CSS, JavaScript, manifesto, e etc; contidos em um arquivo zip ao invés de ter seus arquivos hospedados em um servidor web. Para mais detalhes desse formato, veja Aplicativos empacotados. 

Origem dos aplicativos

Para aplicativos hospedados, a origem do aplicativo é a origem onde se localiza o manifesto do aplicativo.

Para aplicativos empacotados, a origem é o identificador único do aplicativo que é designado ao mesmo durante a instalação. Aplicativos Privilegiados e Internos também podem solicitar uma origem especifica ao informar o parâmetro origem no manifesto da aplicação.

Instalação de aplicativos

Aplicações são instaladas através da API JavaScript de Aplicativos:

• Aplicativos hospedados são instalados chamando:
  navigator.mozApps.install(manifestURL), onde manifestURL é a URL que informa a localização do aplicativo. Para mais detalhes, veja Instalando Aplicativos.
• Aplicativos empacotados são instalados chamando:
  navigator.mozApps.installPackage(packageURL). Para aplicativos empacotados o manifesto principal é armazenado dentro do próprio pacote para que ele seja assinado. Existe um segundo "mini-manifesto" que é usado somente para iniciar o processo de instalação. Para mais informações veja Instalando aplicativos empacotados e Aplicativos empacotados.

De modo a garantir que um aplicativo realmente solicitou ser instalado como uma aplicação web, nós temos que certificar não ser possível enganar um servidor a hospedar um manifesto de aplicação. Isto é feito obrigando o servidor a disponibilizar o arquivo manifesto com o seguinte mime-type, application/x-web-app-manifest+json. Essa validação não é feita quando o aplicativo e o arquivo manifesto tem a mesma origem da página que solicitou a instalação da aplicação.

Atualizações

O processo de atualização de aplicativos é descrito em Atualizando aplicativos.

Permissões

Privilégios adicionais podem ser concedidos para aplicativos além daqueles concedidos para websites normais. Por padrão um aplicativo tem as mesmas permissões que paginas web normais. Para conseguir permissões adicionais o primeiro passo é o aplicativo enumerar as permissões extras e solicitar as mesmas no manifesto do aplicativo.

Declaração no manifesto

Para cada permissão adicional que um aplicativo deseja utilizar, o aplicativo precisa enumerar a permissão no manifesto complementada com uma descrição significativa de porque o aplicativo precisa daquela permissão adicional. Por exemplo, se um aplicativo quer usar a API navigator.geolocation, ele precisa incluir o texto abaixo no seu manifesto:

"permissions": {
  "geolocation":{ 
    "description": "Necessária para autocompletar o local na tela compartilhar",  
  }
},

Isso irá permitir o aplicativo solicitar a permissão do usuário para utilizar a API de geolocalização da mesma forma que uma pagina web solicitaria. Para mais detalhes, veja Manifesto do aplicativo.

Concedendo permissões

Quando as permissões são solicitadas no manifesto, a permissão é configurada como Permitidas (allow) ou Solicitadas (prompt), dependendo da permissão solicitada. Permissões Permitidas são concedidas ao se declarar a mesma no manifesto sem aprovação direta do usuário a cada uso. Para permissões Solicitadas o usuário é consultado no primeiro uso da API relacionada, e tem a escolha de permitir ou não antes da API ser concedida para uso pelo aplicativo, O Firefox OS somente pergunta ao usuário sobre a concessão de permissões que tem um impacto em sua privacidade, e além disso seja razoável para o usuário entender o que está sendo perguntado. Por exemplo, acesso aos contatos é Solicitada, mas acesso para realizar uma conexão TCP é concedido implicitamente, porque não é razoavel que um usuário commum entenda as implicações de segurança de conceder essa permissão. Uso de permissões Permitidas são revistas no processo de segurança do Marketplace para garantir que os aplicativos disponiveis sejam seguros para os usuários.

Revogando Permissões

Os usuários tem o direito de mudar de ideia sobre permissões Solicitadas a qualquer momento, e podem revogar essas permissões através do aplicativo de configurações do Firefox OS. Entretanto, permissões Permitidas não podem ser alteradas pelo usuário.

Isolamento dos aplicativos web

Dados armazenados por aplicativo

Cada aplicativo é executado pelo Firefox OS em uma area isolada, isso significa que todos os dados armazenados por um aplicativo está separado de todos os dados armazenados por outros aplicativos. Incluindo dados de cookies, dados em localStorage,dados no indexedDB, e permissões locais.

Isso significa que se o usuário tem dois aplicativos instalados, aplicativos A e B, esses aplicativos terão um conjunto completamente diferente de cookies, dados locais e permissões diferentes. Isto se aplica mesmo se ambos os aplicativos abrirem um <iframe> que aponta para a mesma origem, ambos A e B abrirem um <iframe> apontando para "https://www.mozilla.org", Ambos irão abrir o site porém, o mesmo será baixado e exibido utilizando cookies diferentes nos dois aplicativos.

O resultado prático é que se o usuario acessar o Facebook enquanto utiliza o aplicativo A, isso não afeta como o aplicativo B manipula a pagina do Facebook. Se o cookie de acesso que o Facebook configurou quando o usuário acessou usando o aplicativo A só está disponivel para o aplicativo A. Se o aplicativo B abrir um <iframe> para o Facebook, o cookie não estará disponível e o Facebook irá exibir novamente a tela de acesso no aplicativo B ao invés da pagina que está aberta no aplicativo A.

Aplicativos não podem abrir uns aos outros

Aplicativos utilizando iframes não podem abrir outros aplicativos.  Se o aplicativo A cria um <iframe> com o src apontando para a URL do aplicativo B, este não irá abrir o aplicativo B no <iframe> e simplesmente abrirá a pagina web que se encontra naquela URL. Também não pode utilizar cookies do aplicativo B, portanto se comportando como se o aplicativo B não estivesse instalado no dispositivo do usuário.

Isso se aplica mesmo para aplicativos empacotados (mais detalhes abaixo). Se o aplicativo A tenta, utilizando um <iframe>, abrir o aplicativo empacotado B apontando para app://URLdoAplicativoB, simplesmente ocorrerá um erro ao abrir a URL. Se será um erro 404 ou outro tipo de erro isso será determinado no futuro, mas definitivamente irá ocorrer um erro ao abrir a página. Da mesma forma também ocorrerá erro independente do aplicativo B estar instalado no dispositivo do usuário ou não, de maneira que o aplicativo A não possa determinar através do erro se o aplicativo B está instalado ou não no dispositivo.

A mesma coisa acontece se o frame principal do aplicativo A, navegar para uma URL do aplicativo B. O sistema sempre sabe que aplicativo está aberto em que frame. Portanto existindo uma tentativa de abrir a URL do aplicativo B no frame do aplicativo A, irá ocorrer o mesmo erro citado acima. Isso também garante que os recursos do aplicativo B como cookies ou dados locais não poderão ser usados de forma alguma pelo aplicativo A.

Motivos

Existem vantagens e desvantagens da segurança ser implementada desta forma. A desvantagem é que se o usuário interage com um mesmo site a partir de aplicativos diferentes ele terá que conectar em cada um dos aplicativos separadamente. Da mesma forma, se um site quer guardar dados localmente e o usuário interage com esse site em aplicativos diferentes os dados serão duplicados em cada aplicativo, que pode ser um problema se for o volume de dados for grande.

A principal vantagem dessa implementação é que esse modelo é mais estável. Não permitimos que os aplicativos interajam entre si através de um site de terceiros e por exemplo um aplicativo parar de funcionar ao se instalar outro. Quando um aplicativo é deinstalado não é possivel que haja perda de dados de outro aplicativo, ou que um aplicativo pare de funcionar porque dependia do aplicativo desinstalado.

É um modelo mais seguro. Um usuário pode usar o seu "AppSocialSuperManeiro" para conectar no Facebook sem se preocupar que o seu "AppSuperSuspeito" possa realizar qualquer ataque para obter os dados do usuário no Facebook através de bugs ou falhas no site do Facebook.

Também existem beneficios a privacidade. O usuário pode tranquilamente instalar o "AppProcurandoEmprego" sem se preocupar porque o "AppDoFuncionarioDaMegaCorporação" não pode detectar que aplicativos estão instalados ou que dados ele criou no dispositivo.

Sandboxed Permissions

In the same way that web site data is sandboxed per app, so is permission data. If App A loads a page from https://maps.google.com and that page requests to use geolocation and the user says "yes, and remember this decision for all times", this only means that https://maps.google.com has access to geolocation within App A. If App B then opens https://maps.google.com, that page won't have access to geolocation unless the user grants that permission again.

And just like in the normal browser, permissions are separated by origin. If App A is granted permission to use Geolocation, this does not mean that all origins running in App A have the permission to use Geolocation. If App A opens an <iframe> to https://maps.google.com, then https://docs.google.com still has to ask the user for permission before geolocation access is granted.

Browser API Sandbox

To additionally secure applications that open a large set of URLs, such as browsers, we have added a browserContent flag. The browserContent flag allows each app to have not one, but two sandboxes: one for the app itself, and one for any "web content" that it opens. For example:

Say that the MyBrowser app is loaded from the https://mybrowser.com domain. This is the domain the scripts and resources are loaded within. The scripts and resources belong to this domain.

Now, if a page in this app creates an <iframe mozbrowser>, a different sandbox is created and used for this <iframe>, which is different from the sandbox used by the app. So for example if this <iframe> is navigated to https://mybrowser.com, it will result in different cookies being used inside the <iframe mozbrowser>. Likewise, the contents inside the <iframe mozbrowser> will see different IndexedDB and localStorage databases from the ones opened by the app.

This also applies if the MyBrowser app wants to create integration with, for example, Google Maps to implement location-based browsing. If the app opens an <iframe> to https://maps.google.com, it will receive a set of cookies for the https://maps.google.com website. If the user then navigates inside the <iframe mozbrowser> containing https://maps.google.com, this will use different cookies and different permissions to the top level app.

Another example where this is useful is in a Yelp-like app. Yelp has the ability to visit a restaurant's website directly in the app. By using <iframe mozbrowser> to open the restaurant website, the Yelp app ensures that the restaurant website can't contain an <iframe> pointing back to Yelp's app (which points to https://yelp.com). If it does, the website will only receive the Yelp website, rather than the Yelp app. So there is no way that the restaurant website can mount an attack against the app since the contained Yelp website won't share any permissions or data with the Yelp app.

Resumo da segurança de aplicativos

A tabela abaixo resume os diferentes tipos de aplicativos no Firefox OS, seus formatos,  e os processos de instalação e atualização para aplicativos web abertos rodando no Firefox OS.