Quando um aplicativo Android precisa de acesso a recursos confidenciais no dispositivo, os desenvolvedores do aplicativo usam o modelo de permissões. Embora o modelo possa ser bastante simples de usar, os desenvolvedores geralmente cometem erros ao usar permissões e isso leva a problemas de segurança.

Neste blog, vamos primeiro explorar alguns tipos diferentes de permissões e, em seguida, explicar os erros comuns que os desenvolvedores cometem ao implementar o modelo de permissões e como evitá-los.

Deseja verificar seus aplicativos móveis para esses tipos de vulnerabilidades? Nós podemos fornecer soluções automáticas e personalizadas que ajudam a detectar vulnerabilidades em aplicativos módeis Android e iOS. Você pode integrar nossa I.A. Yachay em seu processo de desenvolvimento e verificar se o seu código está seguro e indicadores que te ajudarão a certificar que está indo no caminho certo.

Declaração de permissões e seus tipos

As permissões ajudam a restringir o acesso a determinados componentes do Android, como atividades, receptores de transmissão, serviços e provedores de conteúdo. Um desenvolvedor pode declarar vários tipos de permissão no AndroidManifest.xmlarquivo do aplicativo.

As permissões também são usadas em tempo de execução para verificar se o aplicativo tem direitos para acessar informações confidenciais ou executar ações perigosas. Por exemplo, para que um aplicativo tenha acesso aos contatos, o desenvolvedor deve incluir uma declaração uses-permission em seu arquivo AndroidManifest.xml:

<uses-permission android:name="android.permission.READ_CONTACTS" />

Esta é uma permissão interna que tem o protectionLevelconjunto para dangerous. Ao implementar este nível de permissão, o sistema Android pergunta ao usuário durante a instalação se ele está disposto a conceder tais direitos a este aplicativo. Se o usuário recusar, o aplicativo não será instalado.

Se um desenvolvedor deseja criar sua própria permissão, ele deve declará-la no manifesto da seguinte forma:

<permission android:name="com.mycoolcam.USE_COOL_CAMERA" android:protectionLevel="dangerous" />
<activity android:name=".CoolCamActivity" android:exported="true" android:permission="com.mycoolcam.USE_COOL_CAMERA">
    <intent-filter>
        <action android:name="com.mycoolcam.LAUNCH_COOL_CAM" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Então, se um aplicativo de terceiros quiser usar a funcionalidade deste exemplo, ele precisará fazer uma declaração como esta:

<uses-permission android:name="com.mycoolcam.USE_COOL_CAMERA" />

e após a instalação (e uso, se for uma permissão de tempo de execução), peça ao usuário para conceder permissões.

Além desses, existem também alguns outros níveis de permissão que você deve conhecer, como:

  • normal: esta permissão é “não visível” para o usuário. Um usuário não sabe que o aplicativo está solicitando acesso a esse recurso porque os direitos são concedidos automaticamente durante a instalação.
  • dangerous: conforme mencionado anteriormente, esse nível exige que o usuário confirme se um aplicativo pode acessar um determinado recurso.
  • signature: o aplicativo que usa esse nível de permissão deve ser assinado com o mesmo certificado do aplicativo que o declarou. Isso impede que um invasor crie uma uses-permissiondeclaração para esse nível porque o Android não permite a instalação do aplicativo.
  • Existem vários outros níveis, como systeminstallerprivileged, etc. que são usados ​​pelos aplicativos do sistema. Estes devem ser considerados como um signaturenível do ponto de vista de um invasor, ou seja, as permissões que usam isso protectionLevelnão podem ser declaradas emuses-permission

Agora vamos ver alguns erros comuns que os desenvolvedores cometem ao trabalhar com permissões.

Esquecendo protectionLevel

O que acontece se você não mencionar o protectionLevel na declaração permission?

<permission android:name="com.mycoolcam.USE_COOL_CAMERA" />

Você adivinhou! Ele será marcado como normal padrão e isso permite que qualquer aplicativo possa usá-lo. Um erro semelhante foi cometido pelos desenvolvedores de um aplicativo integrado da Samsung, o que levou à possibilidade de outros aplicativos no telefone lerem o histórico de chamadas da vítima, mensagens SMS, etc.

Erros do ecossistema

Vamos supor que o desenvolvedor tenha um ecossistema de dois aplicativos: My Cool CamMy Cool Reader. O aplicativo leitor usa a funcionalidade do aplicativo da câmera.

O manifesto do aplicativo da câmera:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mycoolcam">
    <permission android:name="com.mycoolcam.USE_COOL_CAMERA" android:protectionLevel="signature" />
    <uses-permission android:name="com.mycoolcam.USE_COOL_CAMERA" />

    <application android:label="My Cool Cam">
        <activity android:name=".CoolCamActivity" android:exported="true" android:permission="com.mycoolcam.USE_COOL_CAMERA">
            <intent-filter>
                <action android:name="com.mycoolcam.LAUNCH_COOL_CAM" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
        <!-- ... -->
    </application>
</manifest>

O manifesto do aplicativo leitor:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mycoolreader">
    <uses-permission android:name="com.mycoolcam.USE_COOL_CAMERA" />

    <application android:label="My Cool Reader">
        <provider android:name=".AllUserNotesContentProvider" android:authorities="com.mycoolreader.notes_provider" android:exported="true" android:permission="com.mycoolcam.USE_COOL_CAMERA" />
        <!-- ... -->
    </application>
</manifest>

À primeira vista, pode parecer que tudo está bem e seguro, pois apenas aplicativos do ecossistema podem acessar informações confidenciais armazenadas no arquivo AllUserNotesContentProvider.

Mas, o que acontece se o dispositivo da vítima tiver apenas o aplicativo leitor instalado? Nesse caso, o sistema Android não saberá nada sobre a com.mycoolcam.USE_COOL_CAMERAdeclaração de permissão e, portanto, o nível de permissão será marcado como normalpadrão.

Para evitar isso, certifique-se de que cada permissão de um ecossistema de vários aplicativos também seja declarada individualmente em cada aplicativo.

Erros de digitação em nomes de permissão

É extremamente comum que os desenvolvedores cometam erros de digitação nos nomes das permissões:

<permission android:name="com.mycoolcam.USE_COOL_CAMERA" android:protectionLevel="signature" />
<activity android:name=".CoolCamActivity" android:exported="true" android:permission="com.mycoolcam.USE_COOL_CAM">
    <intent-filter>
        <action android:name="com.mycoolcam.LAUNCH_COOL_CAM" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

A permissão para com.mycoolcam.USE_COOL_CAMERA terá protectionLevelsignaturecom.mycoolcam.USE_COOL_CAM será definida como normal. Isso permite que qualquer aplicativo faça uma uses-permissiondeclaração com com.mycoolcam.USE_COOL_CAMa qual, por sua vez, dará acesso à CoolCamActivityatividade.

Erros de digitação em declarações de componentes

<permission android:name="com.mycoolcam.USE_COOL_CAMERA" android:protectionLevel="signature" />
<activity android:name=".CoolCamActivity" android:exported="true" android:uses-permission="com.mycoolcam.USE_COOL_CAMERA">
    <intent-filter>
        <action android:name="com.mycoolcam.LAUNCH_COOL_CAM" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

No exemplo acima, em vez de usar o android:permissionatributo (que define o nível de acesso ao componente), diz android:uses-permission. Isso permitirá que qualquer aplicativo de terceiros o acesse, pois significa que o componente não possui nível de proteção.

Proteção insuficiente de permissões

Alguns aplicativos não protegem completamente as permissões que usam, o que deixa espaço para um aplicativo de terceiros explorar o aplicativo vulnerável e obter direitos.

Vamos entender isso melhor com um exemplo simples.

Arquivo AndroidManifest.xml:

<uses-permission android:name="android.permission.READ_CONTACTS" />
<provider android:name=".ContactsProvider" android:authorities="com.exampleapp.contacts" android:exported="true" />

Arquivo ContactsProvider.java:

public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
    return getContext().getContentResolver().query(ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
            projection,
            selection,
            selectionArgs,
            sortOrder);
}

Nesse caso, você pode ver claramente que acessar o URI ContactsContract.CommonDataKinds.Phone(alias para content: //com.android.contacts/data/phones) requer a permissão android.permission.READ_CONTACTS. No entanto, nenhum direito é necessário para acessar content://com.exampleapp.contacts.

Para evitar isso, os aplicativos devem garantir a proteção de quaisquer permissões recebidas por eles.

Perguntas frequentes sobre como trabalhar com permissões

P: O que acontece se um aplicativo tentar acessar um componente sem ter permissão para isso?

R: No caso de uma intenção explícita, o Android lança automaticamente um arquivo SecurityException: Permission Denial. No entanto, no caso de uma atividade implícita, a atividade terá um ActivityNotFoundExceptionerro. Para receptores, a transmissão será ignorada e os serviços não poderão ser iniciados com intenções implícitas.

P: É possível substituir a declaração de permissão?

R: Se o aplicativo analisado já estiver instalado e você tentar instalar seu próprio aplicativo com o mesmo nome, não será possível substituir a declaração de permissão, pois o sistema gerará um erro INSTALL_FAILED_DUPLICATE_PERMISSION.

No entanto, isso não se aplica a aplicativos assinados com o mesmo certificado e, nesse caso, para evitar as vulnerabilidades descritas anteriormente, as permissões devem ser declaradas novamente.

P: As permissões de outros aplicativos podem ser interceptadas?

R: Isso não é possível diretamente. No entanto, existem vários desvios que podem permitir que outro aplicativo execute ações privilegiadas, como no exemplo acima. Também existem possibilidades em que a interceptação do acesso a provedores de conteúdo pode ser possível se o aplicativo vulnerável tiver acesso a eles ou se eles estiverem protegidos com permissões pertencentes ao aplicativo vulnerável.

Proteja seus aplicativos HOJE!

Pode ser um desafio acompanhar os problemas de segurança que aparecem diariamente durante o processo de desenvolvimento do aplicativo. Fale conosco e ajudaremos você a automatizar esse processo internamente, economizando toneladas de recursos.

4 thoughts on “Erros comuns ao usar permissões no Android”

Leave a Reply

Your email address will not be published. Required fields are marked *

× Fale conosco