From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- files/pt-br/archive/b2g_os/security/index.html | 67 +++++ .../index.html | 94 +++++++ .../b2g_os/security/modelo_de_seguranca/index.html | 275 +++++++++++++++++++++ .../security/seguranca_de_aplicacao/index.html | 138 +++++++++++ 4 files changed, 574 insertions(+) create mode 100644 files/pt-br/archive/b2g_os/security/index.html create mode 100644 files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html create mode 100644 files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html create mode 100644 files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html (limited to 'files/pt-br/archive/b2g_os/security') diff --git a/files/pt-br/archive/b2g_os/security/index.html b/files/pt-br/archive/b2g_os/security/index.html new file mode 100644 index 0000000000..381696bef1 --- /dev/null +++ b/files/pt-br/archive/b2g_os/security/index.html @@ -0,0 +1,67 @@ +--- +title: Segurança +slug: Archive/B2G_OS/Security +tags: + - B2G + - Firefox OS + - Mobile + - Security +translation_of: Archive/B2G_OS/Security +--- +

Os artigos a seguir cobrem tópicos relacionados com a segurança do Firefox OS. Isso inclui todos os recursos de segurança, bem como segurança da aplicação e como o processo de instalação é seguro.

+ + + + + + + +
+

Documentação sobre a segurança do Firefox OS

+
+
+ O modelo de segurança do Firefox OS
+
+ Uma visão geral sobre o modelo de segurança do Firefox OS.
+
+ Segurança do sistema
+
+ Detalha os controles de segurança criados no ambiente de execução do Firefox OS.
+
+ Segurança das aplicações no Firefox OS
+
+ Uma visão geral de como as aplicações são seguras no Firefox OS.
+
+ Segurança para instalar e atualizar aplicações
+
+ Como funciona a segurança do Firefox OS para instalar e atualizar aplicações.
+
+ Permissões de software no Firefox OS
+
+ Um guia para saber que tipo de software tem permissão para executar várias tarefas no Firefox OS.
+
+  Depurando e testando a segurança com o Firefox OS
+
+ Esse guia mostra os passos básicos de teste de segurança, abrindo um depurador remoto de JavaScript para configuração de um proxy de interceptação HTTP(S) através de uma versão desktop do Firefox OS.
+
+

Veja mais...

+ 		+

OBTENDO AJUDA DA COMUNIDADE

+

Se você está trabalhando com Firefox OS, ou desenvolvendo aplicações que gostaria de rodar em dispositivos com Firefox OS, aqui estão alguns recursos da comunidade para te ajudar!

+
    +
  • Consultar o fórum do projeto Boot to Gecko: {{ DiscussionList("dev-b2g", "mozilla.dev.b2g") }}
    • +
+
    +
  • Faça sua pergunta no canal IRC da Mozilla - Boot to Gecko: #b2g
    • +
+

Não esqueça do uso da netiqueta...

+
+ + +
+

 

+
+  
diff --git a/files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html b/files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html new file mode 100644 index 0000000000..7c1102d699 --- /dev/null +++ b/files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html @@ -0,0 +1,94 @@ +--- +title: Instalando e atualizando aplicativos +slug: Archive/B2G_OS/Security/Installing_and_updating_applications +tags: + - Apps + - Atualização + - B2G + - Experiência do usuário + - Firefox OS + - Guía + - Instalação + - Princípios de design + - UX + - User experience +translation_of: Archive/B2G_OS/Security/Installing_and_updating_applications +--- +
+

Este artigo serve como um guia para o processo de atualização do aplicativo no Firefox OS.

+
+ +

Visão Geral da Implementação

+ +

Categorias de App

+ +

Existem três categorias básicas de aplicativos que são atualizadas utilizando esse mecanismo:

+ +
+
Aplicativos principais
+
Os aplicativos básicos (aqueles que são enviados como parte da base do Firefox OS, como o Dialer) são empacotados, certificados, pré-instalados, e não removíveis. Estes só são atualizados durante uma atualização completa do sistema ou uma atualização dos níveis Gonk e Gaia.
+
Aplicativos instalados pelo usuário
+
Os aplicativos instalados pelo usuário são hospedados ou empacotados. A política de atualização deles é o tema principal deste artigo.
+
Aplicativos pré-instalados de terceiros
+
Aplicativos que são pré-instalados pelo transportador ou pelo fornecedor, mas não fazem parte da plataforma de núcleo do sistema operacional, são atualizados e estão sujeitos às mesmas regras e diretrizes dos aplicativos instalados pelo usuário.
+
+ +

Suposições sobre os usuários

+ +

Para pelo menos as versões iniciais do Firefox OS, as seguintes suposições são feitas sobre os usuários:

+ + + +

Estas são as condições de uso comuns em muitos países, por isso é importante considerar estas suposições. Nosso objetivo é tentar otimizar a experiência de atualização para as pessoas nas quais ela se aplica. Estes pressupostos em geral não irão impactar negativamente os usuários que têm acesso barato a um WiFi rápido.

+ +

Parâmetros técnicos de design

+ +

Esta seção aborda alguns princípios de design para a implementação de atualizações de aplicativos do Firefox OS:

+ + + +

Considerações aos desenvolvedores

+ +

Existem algumas considerações importantes para os desenvolvedores, no que diz respeito ao modelo de atualização do aplicativo:

+ + + +

Experiência do usuário

+ +

Princípios de design

+ +

Afim de oferecer a melhor experiência de usuário possível durante a atualização do aplicativo, alguns princípios fundamentais serão mantidos em mente:

+ + + +

Tipos de atualizações

+ +

Existem três tipos básicos de atualizações:

+ +
+
Manual: individual
+
 Uma única atualização de aplicativo iniciada pelo usuário.
+
Manual: batch
+
Múltiplas atualizações de aplicativos iniciadas pelo usuário de uma única vez. 
+
Silent
+
Atualização automática de fundo.
+
diff --git a/files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html b/files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html new file mode 100644 index 0000000000..a5ae858791 --- /dev/null +++ b/files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html @@ -0,0 +1,275 @@ +--- +title: Visão geral sobre segurança +slug: Archive/B2G_OS/Security/modelo_de_seguranca +translation_of: Archive/B2G_OS/Security/Security_model +--- +

Introdução

+

Este documento apresenta uma visão geral sobre o framework de segurança do Mozilla Firefox OS, desenhado para proteger dispositivos móveis das ameaças para a plataforma, aplicativos e dados pessoais. No Firefox OS a fundação Mozilla implementou uma arquitetura de segurança abrangente, integrada, de várias camadas que traz maior segurança aos usuários dos dispositivos móveis.

+

Segurança da plataforma

+

A plataforma de segurança do Firefox OS é baseada num modelo multi-camada, desenhada para mitigar os riscos de exploração de falhas em todos os níveis. As medidas de combate da linha de frente é combinada com uma forte estratégia que provê uma proteção abrangente para qualquer ameaça.

+

Arquitetura segura

+

O Firefox OS conecta as aplicações web através ao hardware subjacente. É um conjunto de tecnologias integradas que consiste nos seguintes níveis:

+

+ +

Gecko é o guardião da plataforma que aplica políticas de segurança destinadas a proteger o dispositivo móvel do uso indevido. A camada do Gecko atua como um intermediário entre os aplicativos web (na camada Gaia) e o telefone.  Gonk oferece recursos de hardware do telefone celular diretamente para a camada Gecko. Os aplicativos Web acessam as funcionalidades do celular apenas através das Web APIs e somente se o Gecko permitir a requisição de acesso — não há acesso direto, nem “back door” no telefone. Gecko exige permissões e impede o acesso a solicitações não autorizadas.

+

Implantação de um sistema seguro

+

Firefox OS vem instalado no smartphone. A imagem original do sistema é criada por uma fonte conhecida e confiável — normalmente um fabricante por OEM — que é responsável pela montagem, compilação, teste e assinar digitalmente o pacote de distribuição.

+

As medidas de segurança são usadas através de um stack tecnológico. Privilégios de acesso ao sistema de arquivo são aplicadas por listas de controle de acesso do Linux (ACLs). Aplicativos do sistema são instalados em um volume com privilégio apenas de leitura (exceto durante as atualizações quando temporariamente é permitido a gravação), geralmente somente áreas com conteúdo do usuário podem ter privilégio de escrita. Vários componentes no hardware do dispositivo possui proteções internas que são implementadas com práticas padrão da indústria — fabricantes de chipset manufacturers, por exemplo, empregam técnicas de hardening para reduzir vulnerabilidades. e fortalecer a defesa contra ameaças potenciais na plataforma central (Gecko e Gonk) e recursos de hardening do compilador são usados quando aplicável. Para maiores detalhes veja Segurança do sistema.

+

Atualização segura do sistema

+

Atualizações e patches subsequentes da plataforma Firefox OS são instaladas usando um processo seguro da Mozilla que garante a integridade da imagem do sistema. A atualização é criada por uma fonte conhecida e confiável — normalmente o fabricante do dispositivo — que é responsável por montar, compilar, testar e assinar digitalmente o pacote de atualização.

+

As atualizações do sistema envolve toda ou uma parte do stack do Firefox OS. Se alterações no Gonk são incluídas na atualização, é utilizado o processo de instalação FOTA (Firmware Over the Air). Atualizações FOTA também incluem qualquer outra parte do stack do Firefox OS, incluindo o gerenciamento do dispositivo (FOTA, firmware e drivers), gerencialmento das configurações (configuração Firefox OS), atualizações de segurança, Gaia, Gecko e outros patches.

+

Atualizações que não envolvem o Gonk podem ser feitas utilizando o Utilitário de atualização do sistema da Mozilla. Firefox OS usa o mesmo framework de atualização, processos e o formato MAR (Mozilla ARchive) que o produto Firefox Desktop.

+

Um serviço de atualização instalado no próprio dispositivo — que pode ser fornecido pelo OEM — verifica se há atualizações do sistema disponíveis. Uma vez disponível é solicitada uma confirmação do usuário para instalá-la. Antes, é verificado se há espaço suficiente além de alguns detalhes da distribuição:

+ +

As seguintes medidas de segurança são usadas durante o processo de atualização:

+ +

Controles rigorosos, estão presentes para garantir que a atualização seja aplicada corretamente no dispositivo.

+
+

Nota: Para maiores informações sobre como as atualizações funcionam e como criar e distribuir as atualizações, leia Criando e aplicando pacotes de atualização do Firefox OS.

+
+

Segurança do Aplicativo

+

Firefox OS usa uma estratégia de defesa chamada defense-in-depth para proteger o dispositivo de aplicações intrusivas ou maliciosas. Essa estratégia emprega uma variedade de mecanismos, incluindo níveis de permissionamento implícito baseado em modelo de aplicativo do confiança, execução em sandbox em tempo de execução, acesso ao hardware apenas através de APIs, modelo robusto de permissionamento e um processo seguro de instalação e atualização. Para detalhes técnicos veja Segurança da aplicação.

+

No Firefox OS, todos os aplicativos são aplicativos web — programas escritos usando HTML5, JavaScript, CSS, mídias e outras tecnologias abertas (páginas que funcionam dentro do navegador não são referidos como aplicativos web neste contexto). Devido ao fato de não haver arquivos binários (nativos) instalados pelo usuário, todo o acesso ao sistema é mediado estritamente através de Web APIs. Mesmo o acesso ao sistema de arquivos é feito através das Web APIs e um banco de dados SQLite no back-end — não há acesso direto dos aplicativos aos arquivos armazenados no cartão de memória externo.

+

O Firefox OS limita e reforça o escopo dos recursos que podem ser acessados e utilizados por um aplicativo, enquanto também suporta um grande número de aplicativos com diferentes níveis de permissões. A Mozilla implementou um rígido controle sobre quais aplicativos podem acessar quais APIs. Por exemplo, somente aplicativos certificados (fornecidos com o telefone) pode acessar a API de telefonia. O aplicativo discador tem privilégios para poder acessar a API de telefonia, mas nem todos os outros aplicativos certificados podem acessar essa API.

+

Isso evita uma situação, por exemplo, no qual um aplicativo de terceiros possa acessar o discador e chamar indiscriminadamente um telefone qualquer.

+

Outro aplicativo OEM pode ser selecionado para ter acesso à API de telefoina. Por exemplo, um operador pode fornecer uma aplicação de gerenciamento que permite ao usuário verificar sua conta, incluindo a possibilidade de realizar uma chamada telefônica diretamente.

+

Aplicativos confiáveis e não confiáveis

+

Firefox OS categoriza os aplicativos de acordo com os seguintes tipos:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

Tipo

+ 		+

Nível de confiança

+ 		+

Descrição

+
+

Certificado

+ 		+

Altamente confiável

+ 		+

Aplicativos do sistema que devem ser aprovados pela Operadora ou OEM (devido ao risco de corromper o dispositivo ou causar um dano crítico de alguma funcionalidade). Somente para aplicativos ou serviços do sistema, não destinado a aplicações de terceiros.
+ Essa classificação é reservada apenas para um pequeno número de aplicações críticas. Por exemplo: SMS, Bluetooth, câmera, relógio do sistema, telefonia e o discador padrão (para garantir que os serviços de emergência estejam sempre acessíveis).

+
+

Privilegiado

+ 		+

Confiável

+ 		+

Aplicativos de terceiros devem ser revisados, aprovados e digitalmente assinados para serem autorizados dentro do Marketplace.

+
+

Web (todo o resto)

+ 		+

Não confiável

+ 		+

Conteúdo normal da web. Inclui os aplicativos instalados (armazenados no telefone) e aplicativos hospedados (armazendos remotamente, com somente um manifesto armazenado no telefone). O manifesto para aplicativos hospedados pode ser obtido no Marketplace.

+
+

O nível de confiança de um aplicativo determina, em parte, a sua habilidade de acessar as funcionalidades do telefone.

+ +

Algumas operações, como acesso à rede, possuem permissões implícitas para todos os aplicativos. Em geral, quanto mais sensível a operação (por exemplo, chamar um número de telefone ou acessar a lsta de contaos),  maior o nível de confiança exigido para executá-lo.

+
+

Nota: para maiores informações sobre as APIs disponíveis e seus níveis de permissão, consulte Permissões de aplicativos.

+
+

Princípio do privilégio mínimo

+

Para aplicações web, o framework de segurança do Fireofox OS segue o princípio do privilégio mínimo: começa com o mínimo absoluto de permissões e seletivamente concede privilégios adicionais somente quando for requisitado e for razoável. Por padrão um aplicativo começa com um nível de permissão muito baixo, que é comparável a um conteúdo web não confiável. Se o aplicativo faz uma chamada a uma Web API que requisita permissões adicionais, ele deve enumerar essas permissões adicionais no manifesto (a ser descrito mais tarde nesse documento). O Gecko vai considerar a concessão do acesso somente se estiverem explicitamente requisitados no seu manifesto e se o tipo do aplicativo (certificado, privilegiado ou web) é suficientemente qualificado para o acesso solicitado.

+

Processo de revisão para aplicativos privilegiados no Marketplace

+

Para que um aplicativo torne-se privilegiado, o desenvolvedor do aplicativo deve submetê-lo a aprovação no Marketplace que sumete o aplicativo a um rigoroso processo de revisão de código: verificando sua autenticidade e integridade, garantindo que as permissões requisitadas são usadas para os propósitos declarados (no racional da permissão), verificando que o uso implícito da permissão é apropriado e validando que qualquer interface entre o conteúdo privilegiado e não privilegiado do aplicativo possui as mitigações apropriadas contra possíveis ataques. O Marketplate tem a responsabilidade de garantir que o aplicativo não possui um comportamento malicioso com as permissões que lhe são concedidas.

+

Depois que o aplicativo passa nessa revisão, é aprovado para uso, o manifesto é assinado digitalmente pelo Marketplace e é disponibilizado para download para os usuários. A assinatura garante que caso a web store for atacada por hackers não há a possibilidade de instalar códigos maliciosos nos telefones dos usuários. Devido a esse processo, o Firefox OS fornece um elevado grau de confiança aos aplicativos baixados do Maketplace.

+
+

Nota: para saber mais sobre os Marketplaces incluindo o Firefox Marketplace, veja a seção do Marketplace.

+
+

Aplicativos hospedados e empacotados

+

Os aplicativos no Firefox OS podem ser empacotados (armazenado no dispositivo) ou hospedado (armazenado em um servidor web remoto, apenas com o manifesto armazenado no dispositivo). Existem algumas diferenças na forma de lidar com a segurança em cada uma das formas. No entanto, os aplicativos empacotados e hospedados estão sujeitos a aplicação do sandboxing, que é descrita mais adiante neste documento.

+
+

Nota: Você pode saber mais sobre aplicativos hospedados e empacotados no artigo opções de publicação de aplicativos.

+
+

Aplicativos empacotados

+

Um aplicativo empcotado consiste-se de um arquivo ZIP com os recursos (HTML5, CSS, JavaScript, imagens, mídias), bem como um manifesto que fornece uma lista explícita de ativos e seus hashes correspondentes. Aplicativos certificados e privilegiados devem ser empacotados porque o manifesto deve ser digitalmente assinado. Quando um usuário obtem um aplicativo empacotado, o arquivo ZIP é baixado no dispositivo e o manifesto é lido de um local conhecido dentro do arquivo ZIP. Durante o processo de instalação, os ativos do aplicativo são verificados e permanecem armazenados dentro do pacote. Todas as permissões explícitas são requisitadas em tempo de execução, mostrando ao usuário as intenções do aplicativo e persistido por padrão.

+

Ao referir-se aos recursos de um aplicativo empacotado, a URL deve começar por app: usando o seguinte formato:

+

app://identifier/path_within_zipfile/file.html

+

onde app:// representa o ponto de montagem do arquivo ZIP e identifier é uma UUID gerada quando o aplicativo é instalado no dispositivo. Esse mecanismo garante que os recursos são referenciados como aplicativo: URL estão contidos no arquivo ZIP. O caminha dentro de um aplicativo: é relativo, então links relativos para os recursos dentro do arquivo ZIP são permitidos.

+

Aplicativos empacotados destinam-se principalmente a serm utilzados por aplicativos certificados ou privilegiados, mas aplicativos comuns também podem ser empacotados. Porém, não há nehum ganho ou aumento na confiança ou permissões de acesso simplesmente devido ao fato de ser empacotado.

+

Aplicativos hospedados

+

São armazenados em um servidor web e carregados via HTTP. Apenas o manifesto do aplicativo fica armazenado no dispositivo. Todo o restante é armazenado remotamente. Algumas APIs estão disponíveis somente para aplicativos certificados, que exigem que sejam empacotados devido a requisitos de assinatura digital. Assim, um aplicativo hospedado não possuirá acesso a nenhuma operação de API que exige que o aplicativo seja certificado ou privilegiado.

+

Pelo ponto de vista da segurança, aplicativos hospedados funciona de forma similar a websites. Um aplicativo hospedado é carregado invocando uma URL descrita diretamente no código que aponta para uma página de início no diretório raiz do aplicativo armazenado em um servidor web. Uma vez que um aplicativo hospedado é carregado, o dispositivo conecta às páginas usando as mesmas URLs que são usadas ao navegar o website.

+

Manifesto do aplicativo

+

Um manifeseto de um aplicativo Open Web contém informações que um navegador Web necessita para interagir com um aplicativo. É um arquivo JSON que deve possuir pelo menos o nome e a descrição do aplicativo. Para maiores detalhes consulte Perguntas frequentes sobre manifestos.

+

Examplo de Manifesto

+

O código a seguir mostra um exemplo de manifesto com apenas algumas configurações:

+
{
+  "name": "My App",
+  "description": "My elevator pitch goes here",
+  "launch_path": "/",
+  "icons": {
+    "128": "/img/icon-128.png"
+  },
+  "developer": {
+    "name": "Your name or organization",
+    "url": "http://your-homepage-here.org"
+  },
+  "default_locale": "en"
+}
+

Configurações de segurança no manifesto

+

O manifesto pode conter outras configurações, incluindo as de segurança:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

Campo

+ 		+

Descrição

+
+

permissions

+ 		+

Permissões solicitadas pelo aplicativo. Devem ser listadas todas as Web APIs que pretende usar e que necessitam permissão do usuário. A maioria das permissões fazem sentido para aplicativos certificados ou privilegiados, mas não para aplicativos hospedados. Propriedades por API:

+
    +
  • description: Uma string especificando a intenção do uso da API. Campo obrigatório.
    • +
  • access: Especifica o tipo de acesso para a permissão. Permissões implícitas são concedidas no momento da instalação. Exigidas apenas por algumas APIs. Valores aceitos: read, readwrite, readcreate, and createonly.
    • +
+
+

installs_allowed_from

+ 		+

A origem do aplicativo, pode ser simples ou um conjunto de origens (esquema+hostname único) que podem disparar a instalação do aplicativo. Permite que fornecedores dos aplicativos permitam instalações somente de Marketplaces autorizados (como por exemplo https://marketplace.firefox.com/).

+
+

csp

+ 		+

Content Security Policy (CSP). Aplicado a todas as páginas carregadas no aplicativo. Utlizado para fazer um hardening no aplicativo protegendo contra bugs que possam permitir um ataque que injete código no aplicativo. Se não for especificado, aplicativos certificaso e privilegiaods possuem padrões definidos pelo sistema. Sintaxe:
+ https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp

+

Observe que essa diretiva somente pode acrescentar o CSP aplicado. Você não pode usar, por exemplo, para reduzir o nível de segurança de um aplicativo privilegiado.

+
+

type

+ 		+

Tipo do aplicativo (web, privilegiado ou certificado).

+
+

Firefox OS exige que o manifesto seja hospedado com um mime-type específico (application/x-web-app-manifest+json) e do mesmo nome de servidor (origem) no qual o aplicativo está hospedado. Essa restrição é reduzida quando o manifesto está na mesma origem da página que requisitou o aplicativo a ser instalado. Esse mecanismo é utilizado para garantir que não é possivel burlar um website através de um manifesto.

+

Execução no Sandbox

+

Applicação Sandbox

+

O framework de segurança do Firefox OS usa a técnica de sandboxing como estratégia de defesa para mitigar riscos e proteger o dispositivo, plataforma e dados. Sandboxing é uma forma de impor limites e restrições em torno no aplicativo durante a sua execução. Cada aplicativo é executado no seu próprio espaço e tem acesso somente às Web APIs e dados permitidos, bem como aos recursos associados com o seu espaço de trabalho (banco de dados IndexedDB, cookies, armazenamento offline, etc.)

+

A figura a seguir fornece uma visão geral do modelo de segurança.

+

+

Ao isolar cada aplicativo, suas tarefas ficam confinadas ao seus espaços de trabalho e não podem inteferir em nada (como outros aplicativos e seus dados) fora do seu limite.

+

Execução do Sandbox

+

B2G (Gecko) executa um processo com alto privilégio que tem acesso aos recursos de hardware no dispositivo. Em tempo de execução, cada aplicativo é executado dentro de um ambiente que é um processo filho do processo B2G. Cada processo filho tem um conjunto restrito de privilégios — por exemplo, um processo filho não pode ler ou escrever arbitrariamente no sistema de arquivos. Acessos privilegiados é fornecido através de Web APIs, que são mediadas pelo processo pai B2G, garantindo que quando um processo filho requisita uma API privilegiada, ela tem a permissão necessária para executar a ação.

+

Os aplicativos se comunicam somente com o processo principal B2G, e não com outros processos ou aplicativos. Eles não são executados independentes do B2G, nem podem abrir outros aplicativos. A única comunicação possível entre os aplicativos é indireta (por exemplo, quando um aplicativo configura um alarme de sistema e outro aplicativo dispara uma notificação do sistema como resultado da configuração), e é mediada pelo processo B2G.

+

Hardware é acessado somente via Web API

+

Os aplicativos somente tem um ponto de entrada para acessar as funcionalidades do telefone: as Web APIs do Firefox OS,  que são implementadas no Gecko. Que fornece o único gateway para o dispositivo e seus serviços. Não há uma API "nativa" e não há outras rotas que contornem esse mecanismo e interaja indiretamente com o hardware ou penetre na camada de baixo nível do software, ou seja: não há "back-doors".

+

Infraestrutura de Segurança

+

A figura a seguir mostra os componentes do framework de segurança do Firefox OS:

+

+ +

Gestão de permissões e sua aplicação

+

O sistema de segurança do Firefox OS é projetado para verificar e fazer cumprir as permissões concedidas às aplicações web..

+

O sistema concede uma permissão particular a um aplicativo somente se o mesmo a requisita e se estiver descrita no manifesto do aplicativo. Algumas permissões exigem uma permissão adicional do usuário, normalmente através de uma mensagem na tela do dispositivo (como por exemplo no caso do aplicativo requisitar acesso à localização atual do usuário). Esse framework baseado no aplicativo fornece um controle mais granular sobre as abordagens de permissão baseada no perfil (no qual é atribuído um conjunto de permissões a cada perfis).

+

Uma Web API possui um conjutno de ações e destinatários. Cada Web API possui um nível de permissão e cada vez que é chamada o Gecko verifica os requisitos de permissão baseado em:

+ +

Se a requisição não atender aos critérios de permissão o Gecko a rejeita. Por exemplo, aplicativos não confiáveis não podem executar APIs que são reservadas para aplicativos confiáveis.

+

Solicitando permissão do usuário

+

In addition to permissions that are implicitly associated with the web apps, certain operations require explicit permission from the user before they can be executed (for example, "can the web app access your camera?"). For these operations, web apps are required to specify, in their manifest, their justification for requiring this permission. This data usage intention informs users about what the web app intends to do with this data if permission is granted, as well as any risk involved. This allows users to make informed decisions and maintain control over their data.

+

Precesso de atualização de um aplicativo seguro

+

+

Para atualizar ou aplicar uma correção de um aplicativo privilegiado, os fornecedores submetem o pacote de atualização a um Marketplace autorizado onde é feita a revisão e se for aprovado é assinado e disponibilizado aos usuários. Nos dispositivos Firefox OS, um utilitário de atualização é executado periodicamente para verificar se há atualizações dos aplicativos. Caso exista, é perguntado ao usuário se deseja instalar a atualização. Antes da instalação é realizada a seguinte verificação no pacote:

+ +

Controles rigorosos são executados para garantir que a atualização é aplicada corretamente ao dispositivo. O pacote completo de atualização deve ser baixado numa localização específica e segura antes do processo iniciar. A instalação não sobrescreve nenhum dado do usuário.

+
+

Nota: Para maiores informações sobre atualização de aplicativo verifique esse artigo.

+
+

Segurança do Dispositivo (Hardware)

+

Os mecanismos de segurança para o hardware do dispositivo são tipicamente de responsabiliade do fabricante. Por exemplo, um fabricante pode oferecer uma proteção para o SIM (Subscriber Identity Module) em conjunto com um código PUK (PIN Unlock Key) para desbloquear o cartão SIM travado por um número determinado de erros na senha do cartão. Contacte o fornecedor para maiores detalhes. Firefox OS possibilita aos usuários configurarem senhas e bloqueio de tela, que será tratado na próxima seção.

+

Segurança dos dados

+

Usuários podem armazenar dados pessoais no seu dispositivo e mantê-los privados como contatos informações financeiras (detalhes de banco e cartões de crédito), senhas, calendários e etc. O Firefox é projetado com proteções contra aplicativos maliciosos que podem roubar, explorar ou destruir dados sensíveis.

+

Senha e bloqueio de tela por tempo

+

O Firefox OS permite aos usuários definir uma senha para acessar e utilizar o telefone. Também permite bloqueio da tela após um período configurável de inatividade solicitando uma senha para desbloquear o telefone.

+

Dados no Sandboxe

+

Como descrito anteriormente, os aplicativos são executados num sandbox. Isso evita que um aplicativo acesse os dados de outro a não ser que os dados sejam explicitamente compartilhados e o outro aplicativo possua permissões para acessá-los.

+

Serialização de dados

+

Os aplicativos web não possuem acesso direto de leitura ou escrita ao sistema de arquivos. Todo o acesso ao armazenamento é feito através de Web APIs. Que lêem e escrevem via um banco de dados SQLite. Não há um acesso direto de I/O. Cada aplicativo possue seu próprio local de armazenamento de dados que é serializado pelo banco de dados.

+

Destruição dos dados

+

Quando um usuário desinstala um aplicativo, todos os dados relacionados ao aplicativo (cookies, localStorage, IndexedDB, etc.) são apagados.

+

Privacidade

+

A Mozilla está comprometida a proteger a privacidade dos usuários e de seus dados de acordo com seus princípios (https://www.mozilla.org/privacy/), que sustenta o Manifesto Mozilla (http://www.mozilla.org/pt-BR/about/manifesto/). A política de privacidade Firefox Mozilla descreve como a Mozilla coleta e utiliza as informações dos usuários do navegador Firefox Mozilla, incluindo o que o Firefox envia para os websites, o que a Mozillar faz para proteger os dados, e etc. Para mais informações veja:

+ +

O Firefox OS implementa esses princípios colocando o controle dos dados dos usuários nas mãos ele, que é quem deve decidir para onde as informações pessoais devem ir. O Firefox OS provê os seguintes recursos:

+ diff --git a/files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html b/files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html new file mode 100644 index 0000000000..335fb17562 --- /dev/null +++ b/files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html @@ -0,0 +1,138 @@ +--- +title: Segurança de Aplicativos +slug: Archive/B2G_OS/Security/Seguranca_de_aplicacao +tags: + - Aplicativo + - Apps + - Firefox OS + - Guía + - Movel + - Segurança +translation_of: Archive/B2G_OS/Security/Application_security +--- +
+

Este artigo aborda detalhadamente o modelo de segurança de aplicativos no Firefox OS.

+
+

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

+ +

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.

+ +
+

Nota: Para informações adicionais sobre os três tipos veja a documentação do Manifesto do Aplicativo.

+
+

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:

+ +

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.

+
+

Nota: Existe um bug que causa a não apresentação ao usuário das permissões que o aplicativo pretende utilizar — veja o bug 823385.

+
+

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.

+

A diagram showing three Firefox OS apps all open is separate sandboxes, so none of them can affect each other.

+

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 {{ htmlelement("iframe") }} que aponta para a mesma origem, ambos A e B abrirem um <iframe> apontando para "http://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 http://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 http://maps.google.com has access to geolocation within App A. If App B then opens http://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 http://maps.google.com, then http://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 http://maps.google.com, it will receive a set of cookies for the http://maps.google.com website. If the user then navigates inside the <iframe mozbrowser> containing http://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 http://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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Tipos de aplicativos web
TipoDistribuiçãoModelo de permissõesInstalaçãoAtualização
WebHospedados ou empacotadosPermissões mais leves que não tenham perigo de exposição a conteúdo web não validado.Instalados de qualquer localPodem ser atualizadas de forma transparente ao usuário ou explicitamente através de um marketplace, dependendo de onde o aplicativo foi instalado e o metodo de distribuição.
PrivilegiadoEmpacotados e obrigatoriamente assinadosAPIs privilegiadas requerem a validação e autenticação do aplicativo.Instalados somente de um marketplace confiávelAtualizados através de um marketplace confiável, o usuário é solicitado a aprovar o download e instalação de atualizações manualmente.
Interno (Certificado)EmpacotadosAPIs potencialmente perigosas e poderosas não disponíveis para aplicativos de terceiros.Pre-Instalados no dispositivoAtualizadas somente através de atualizações do sistema como um todo.
+
+

Nota: Apezar de aplicativos web poderem ser instalados de qualquer site ou marketplace, Na versão 1.0 do Firefox OS os aplicativos privilegiados somente podem ser instalados do marketplace da Mozilla, isso se deve ao fato que o suporte para multiplos marketplaces confiáveis ainda não está terminado.

+
+

 

-- cgit v1.2.3-54-g00ecf