Skip to content

MASTG-TEST-0025: Teste de Injection Flaws

Visão Geral

Para testar falhas de injeção), é necessário primeiro confiar em outros testes e verificar funcionalidades que possam ter sido expostas:

Análise Estática

Um exemplo de um mecanismo de IPC vulnerável é mostrado abaixo.

Você pode usar ContentProviders para acessar informações de banco de dados e pode sondar serviços para ver se eles retornam dados. Se os dados não forem validados adequadamente, o content provider pode estar suscetível a injeção SQL enquanto outros aplicativos interagem com ele. Veja a seguinte implementação vulnerável de um ContentProvider.

<provider
    android:name=".OMTG_CODING_003_SQL_Injection_Content_Provider_Implementation"
    android:authorities="sg.vp.owasp_mobile.provider.College">
</provider>

O AndroidManifest.xml acima define um content provider que é exportado e, portanto, disponível para todos os outros aplicativos. A função query na classe OMTG_CODING_003_SQL_Injection_Content_Provider_Implementation.java deve ser inspecionada.

@Override
public Cursor query(Uri uri, String[] projection, String selection,String[] selectionArgs, String sortOrder) {
    SQLiteQueryBuilder qb = new SQLiteQueryBuilder();
    qb.setTables(STUDENTS_TABLE_NAME);

    switch (uriMatcher.match(uri)) {
        case STUDENTS:
            qb.setProjectionMap(STUDENTS_PROJECTION_MAP);
            break;

        case STUDENT_ID:
            // SQL Injection quando um ID é fornecido
            qb.appendWhere( _ID + "=" + uri.getPathSegments().get(1));
            Log.e("appendWhere",uri.getPathSegments().get(1).toString());
            break;

        default:
            throw new IllegalArgumentException("Unknown URI " + uri);
    }

    if (sortOrder == null || sortOrder == ""){
        /**
         * Por padrão, ordenar por nomes de estudantes
         */
        sortOrder = NAME;
    }
    Cursor c = qb.query(db, projection, selection, selectionArgs,null, null, sortOrder);

    /**
     * registrar para observar alterações em um URI de conteúdo
     */
    c.setNotificationUri(getContext().getContentResolver(), uri);
    return c;
}

Enquanto o usuário fornece um STUDENT_ID em content://sg.vp.owasp_mobile.provider.College/students, a instrução de consulta está suscetível a injeção SQL. Obviamente, prepared statements devem ser usados para evitar injeção SQL, mas validação de entrada também deve ser aplicada para que apenas entradas esperadas pelo aplicativo sejam processadas.

Todas as funções do aplicativo que processam dados provenientes da interface do usuário devem implementar validação de entrada:

  • Para entrada na interface do usuário, Android Saripaar v2 pode ser usado.
  • Para entrada de IPC ou esquemas de URL, uma função de validação deve ser criada. Por exemplo, a seguinte função determina se a string é alfanumérica:
public boolean isAlphaNumeric(String s){
    String pattern= "^[a-zA-Z0-9]*$";
    return s.matches(pattern);
}

Uma alternativa às funções de validação é a conversão de tipo, com, por exemplo, Integer.parseInt se apenas inteiros forem esperados. A OWASP Input Validation Cheat Sheet contém mais informações sobre este tópico.

Análise Dinâmica

O testador deve testar manualmente os campos de entrada com strings como OR 1=1-- se, por exemplo, uma vulnerabilidade de injeção SQL local tiver sido identificada.

Em um dispositivo com root, o comando content pode ser usado para consultar os dados de um content provider. O comando a seguir consulta a função vulnerável descrita acima.

# content query --uri content://sg.vp.owasp_mobile.provider.College/students

A injeção SQL pode ser explorada com o seguinte comando. Em vez de obter apenas o registro de Bob, o usuário pode recuperar todos os dados.

# content query --uri content://sg.vp.owasp_mobile.provider.College/students --where "name='Bob') OR 1=1--''"