디버그 바이너리를 생성하도록 Android 응용 프로그램을 구성할 수 있습니다. 이러한 바이너리는 자세한 디버깅 메시지를 제공하므로 운영 환경에서 사용해서는 안 됩니다. <application> 태그의 debuggable 속성은 컴파일된 바이너리에 디버깅 정보를 포함할지 여부를 정의합니다.

디버그 바이너리를 사용하면 응용 프로그램이 사용자에게 가능한 한 많은 정보를 제공하게 됩니다. 디버그 바이너리는 개발 또는 테스트 환경에서 사용하기 위한 것이며 운영 환경에 배포할 경우 보안 위험을 초래할 수 있습니다. 공격자는 디버깅 출력에서 얻은 자세한 정보를 이용하여 응용 프로그램이 사용하는 프레임워크, 데이터베이스 또는 기타 리소스를 공격할 수 있습니다.

Java 표준에 따르면 해당 매개 변수가 null인 경우 Object.equals(), Comparable.compareTo() 및 Comparator.compare()의 구현은 지정된 값을 반환해야 합니다. 이 약정을 따르지 않으면 예기치 못한 동작이 발생할 수 있습니다.

예제 1: 다음 equals() 메서드의 구현은 해당 매개 변수와 null을 비교하지 않습니다.

public boolean equals(Object object)
{
   return (toString().equals(object.toString()));
}

Privacy violation은 다음 경우에 발생합니다.

1. 사용자 개인 정보가 프로그램에 입력됩니다.

2. 데이터는 콘솔, file system 또는 네트워크와 같은 외부 위치에 작성됩니다.
예제 1: 다음 코드에는 데이터베이스에 추가되는 레코드를 로그 파일의 콘텐트에 저장하여 추적하는 로깅 명령문이 있습니다.

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

Example 1의 코드는 일반 텍스트 암호를 파일 시스템에 기록합니다. 많은 개발자가 파일 시스템을 안전한 데이터 저장소로 신뢰하지만 무조건 신뢰해서는 안 됩니다. 특히 개인 정보가 관련된 경우가 대표적입니다.

개인 정보는 다음의 두 가지 이유 때문에 모바일 환경에서 크게 대두되는 문제 중 하나입니다. 그중 하나는 장치 분실 가능성이 훨씬 더 높다는 점이고, 다른 하나는 모바일 응용 프로그램 사이에서 프로세스 간 통신이 이뤄진다는 점입니다. 모바일 플랫폼에서는 다양한 소스에서 다운로드된 응용 프로그램이 같은 장치에서 함께 실행됩니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 응용 프로그램 작성자는 장치에서 실행되는 다른 응용 프로그램으로 주소가 지정된 메시지에 포함하는 정보를 주의하여 선택해야 합니다. 모바일 응용 프로그램 사이에 진행되는 프로세스 간 통신에 민감한 정보를 포함해서는 안 됩니다.

예제 2: 다음 코드는 Android WebView 저장소에서 지정된 사이트의 사용자 이름과 암호를 읽은 다음 등록된 모든 수신자에게 브로드캐스트합니다.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

이 예는 몇 가지 문제를 보여줍니다. 첫째, WebView 자격 증명은 기본적으로 일반 텍스트로 저장되고 해시되지 않습니다. 사용자가 루팅된 장치나 에뮬레이터를 사용하는 경우 지정된 사이트에 저장된 암호를 읽을 수 있습니다. 둘째, 일반 텍스트 자격 증명은 등록된 모든 수신자에게 브로드캐스트되어 SEND_CREDENTIALS 작업을 통해 인텐트를 수신 대기하도록 등록된 모든 수신자가 메시지를 수신합니다. 이 경우 수정 방법으로 권한을 사용하지 않는 것이 좋지만, 브로드캐스트는 수신자 수를 제한하는 권한으로도 보호되지 않습니다.

개인 정보는 다음과 같은 다양한 방식으로 프로그램에 입력됩니다.

- 암호 또는 개인 정보의 형태로 사용자가 직접 입력

- 응용 프로그램이 데이터베이스 또는 기타 데이터 저장소에서 접근

- 협력업체 또는 타사를 통해 간접적으로

일반적으로 모바일 환경에서 이 개인 정보는 암호, SSN 및 기타 일반 개인 정보에 따라 다음 사항을 포함합니다.

- 위치

- 휴대폰 번호

- 일련번호 및 장치 ID

- 네트워크 연산자 정보

- 보이스메일 정보


개인 정보로 명명되지 않은 데이터도 상황에 따라 개인 정보로 해석될 수 있습니다. 예를 들어, 학생 ID 번호는 명시적이고 공개적으로 각 학생의 개인 정보에 매핑되지 않기 때문에 보통 개인 정보로 간주하지 않습니다. 하지만 학교에서 학생의 주민 등록 번호를 기반으로 ID 번호를 생성하는 경우 ID 번호는 개인 정보로 간주해야 합니다.

보안 및 개인 정보 문제는 서로 상충하는 것처럼 보일 때가 있습니다. 보안 관점에서 보면 이후에 비정상적인 활동을 식별할 수 있도록 모든 중요한 작업을 기록해야 합니다. 하지만 개인 정보가 관련된 경우 이 방법은 위험이 따릅니다.

개인 정보를 위험하게 처리하는 방법은 여러 가지가 있겠지만 공통적인 위험은 잘못된 신뢰에서 비롯됩니다. 프로그래머는 프로그램이 실행되는 운영 환경을 신뢰하기 때문에 개인 정보를 파일 시스템, 레지스트리 또는 기타 로컬로 제어되는 리소스에 저장해도 무방하다고 생각합니다. 하지만 특정 리소스에 대한 액세스가 제한되어 있는 경우에도 액세스 권한을 가진 개인을 신뢰할 수 있다고 보장할 수 없습니다. 일례로, 2004년, AOL의 한 비양심적인 직원이 해외 도박 웹 사이트를 대상으로 영업하는 스패머에게 약 9천 2백만 개의 고객 전자 메일 주소를 팔았습니다[1].

이런 대형 익스플로이트 사건에 대응하여 개인 정보 수집 및 관리에 대한 규제가 점점 엄격해지고 있습니다. 조직의 위치, 업종 및 취급하는 개인 정보의 속성에 따라 조직은 다음의 연방 정부 및 주 정부의 규제를 하나 이상 준수할 의무가 있습니다.

- 세이프 하버 협정(Safe Harbor Privacy Framework)[3]

- GLBA(Gramm-Leach Bliley Act)[4]

- HIPAA(Health Insurance Portability and Accountability Act)[5]

- California SB-1386 [6]

이런 규제에도 불구하고 privacy violation은 우려할 만한 빈도로 계속 발생하고 있습니다.

Query string injection 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.



2. 데이터를 사용하여 SimpleDB 쿼리 문자열을 동적으로 생성합니다.

예제 1: 다음 코드는 사용자가 지정한 제품 카테고리와 일치하는 송장을 검색하는 SimpleDB select() 쿼리를 동적으로 생성하고 실행합니다. 또한 사용자는 결과가 정렬되는 열을 지정할 수도 있습니다. 응용 프로그램이 이미 적절하게 인증되고 이 코드 세그먼트 전에 customerID의 값을 설정했다고 가정합니다.

...
String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
...
AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
            + productCategory + "' and customerID = '"
            + customerID + "' order by '"
            + sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));
...

이 코드가 실행하려는 쿼리는 다음과 같습니다.

select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc

하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는 productCategory 및 price에 작은따옴표 문자가 들어 있지 않은 경우에만 정확하게 동작합니다. 그러나, 공격자가 productCategory에 대한 "Fax Machines' or productCategory = \"" 문자열 및 sortColumn에 대한 "\" order by 'price" 문자열을 제공하면, 쿼리는 다음과 같습니다.

select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc

또는, 다음과 같이 보다 읽기 쉬운 형식을 사용합니다.

select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc

이러한 입력을 통해 공격자는 customerID에 필요한 authentication을 무시할 수 있으며, 모든 고객에 대한 'Fax Machines'와 일치하는 송장 레코드를 볼 수 있습니다.

Query string injection 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.



이런 경우, Fortify Static Code Analyzer는 데이터 소스를 신뢰할 수 있는 것으로 판단하지 않습니다.

2. 데이터를 사용하여 SQLite 쿼리를 동적으로 생성합니다.

SQLite query string injection으로 인해 악의적인 사용자가 무단으로 레코드를 볼 수 있으나, 어떤 방식으로도 데이터베이스의 상태를 변경할 수는 없습니다.

예제 1: 다음 코드는 고객 및 사용자가 지정한 제품 카테고리와 관련된 송장을 검색하는 SQLite 쿼리를 동적으로 생성하고 실행합니다. 또한 사용자는 결과가 정렬되는 열을 지정할 수도 있습니다. 프로그램이 이미 적절하게 인증되고 이 코드 세그먼트 전에 customerID의 값을 설정했다고 가정합니다.

  ...
  productCategory = this.getIntent().getExtras().getString("productCategory");
  sortColumn = this.getIntent().getExtras().getString("sortColumn");
  customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
  c = invoicesDB.query(Uri.parse(invoices), columns, "productCategory = '" + productCategory + "' and customerID = '" + customerID + "'", null, null, null, "'" + sortColumn + "'asc", null);
  ...
  

이 코드가 실행하려는 쿼리는 다음과 같습니다.

  select * from invoices
  where productCategory = 'Fax Machines'
  and customerID = '12345678'
  order by 'price' asc
  

그러나, 쿼리는 상수 기반 쿼리 문자열 및 사용자 입력 문자열 productCategory를 연결하여 동적으로 생성됩니다. 그러므로 쿼리는 productCategory 및 sortColumn가 작은 따옴표 문자를 포함하지 않은 경우에만 올바르게 작동합니다. 공격자가 productCategory에 대한 "Fax Machines' or productCategory = \"" 문자열 및 sortColumn에 대한 "\" order by 'price" 문자열을 제공하면, 쿼리는 다음과 같습니다.

  select * from invoices
  where productCategory = 'Fax Machines' or productCategory = "'
  and customerID = '12345678'
  order by '" order by 'price' asc
  

또는 다음과 같이 보다 읽기 쉬운 형식을 사용합니다.

  select * from invoices
  where productCategory = 'Fax Machines'
  or productCategory = "' and customerID = '12345678' order by '"
  order by 'price' asc
  

이러한 입력을 통해 공격자는 customerID에 필요한 authentication을 무시할 수 있으며, 모든 고객에 대한 'Fax Machines'와 일치하는 송장 레코드를 볼 수 있습니다.