소스코드 정적 분석 대응

개발된 프로그램에 대한 소스코드 분석을 통해 개발자가 놓친 보안 등과 관련된 위험요소를 검출해 주는 프로그램으로 sparrow라는 프로그램이 있습니다. 성과물 제출전에 인수검사를 받는데, 그 과정에서 sparrow라는 프로그램을 통해 위험요소 검출을 자동으로 문서화해 각 개발사에게 전달하고 해결하라고 합니다. 일단 제가 해결해야 할 프로그램의 작성 코드에 대해 검출된 위험 요소를 나열해 봅니다.

• AvoidCatchingGenericException : 일반적인 예외를 try-catch 블록에서 처리하는 경우 이를 검출합니다.
• AvoidReassigningParameters : 메소드 작성시 입력받은 파라미터에 재할당 하는 구문을 검출합니다.
• BAD_EQUALITY_EXPRESSION.FLOAT : Float.compare(numFloat(num), num)로 비교할 것
• BAD_INIT.MISSING_AFTER_LOCAL_DECLARATION : 지역 변수를 선언 할 경우 반드시 초기화해야 합니다. 플래그 변수, 누적 카운터, 반환 코드를 저장하는 변수 등을 초기화 하지 않았을 경우를 검출합니다.
• ConstructorCallsOverridableMethod : 부모 클래스의 생성자 안에서 가상 메소드를 호출하게 되면 자식클래스의 필드가 초기화되기 전에 읽게 되는 문제가 발생합니다.
• EmptyFinallyBlock : Finally 블록이 비어있는 경우, 삭제 가능하므로 이를 검출합니다.
• EmptyStatementNotInLoop : Loop 문 이외에서 발견되는 비어있는 구문(단일 세미콜론)을 검출합니다.
• EXPOSURE_OF_SYSTEM_DATA : 시스템이나 디버깅 정보를 드러내는 것은 악의적인 공격을 계획하기 쉽게 만듭니다. 시스템이나, 디버깅 정보는 output stream 이나 logging 기능을 통하여 새어나가게 됩니다.
• FIELD_ASSIGNED_IN_CONSTRUCTOR_SHOULD_BE_FINAL : synchronization의 과다적용을 자제해야 합니다. 메소드 단위의 synchronization 보다는 블럭 단위의 synchronization 사용을 권장합니다.
• FORBIDDEN.STATEMENT_EXECUTE_QUERY : java.sql.Statement.executeQuery는 사용되는 쿼리문의 argument 보안에 취약해서 SQL Injection 공격에 노출될 가능성이 있습니다. Statement.excuteQuery() 대신에 PreparedStatement.executeQuery()를 사용하는 것이 더 안전합니다.
• HARD_CODED_USER_NAME_AND_PASSWORD : 하드코드 된 비밀번호는 위험하다고 간주합니다. java.sql.DriverManager.getConnection에서 암호에 해당하는 파라미터로 상수 문자열이 들어가는 경우 취약하다고 판정합니다. 비밀번호는 암호화하여 별도의 파일에 저장하여 사용하는 것이 바람직합니다.
• IMPROPER_CHECK_FOR_UNUSUAL_OR_EXCEPTIONAL_CONDITION : 프로그램 수행 중에 함수의 결과 값에 대한 적절한 처리 또는 예외상황에 대한 조건을 적절하게 검사하지 않을 경우, 예기치 않은 문제를 야기 할 수 있습니다.
• INTEGER_OVERFLOW : 동적 메모리 할당을 위해서 사용되는 변수가 이전 처리 과정에서 오버플로우에 의해서 음수값으로 변환될 경우를 검출합니다. 정수형 변수의 오버플로우는 정수값이 증가하면서, Java에서 허용된 가장 큰 값보다 더 커져서 실제 저장되는 값은 의도하지 않게 아주 작은 수이거나 음수가 될 수 있습니다. 이러한 상황을 검사하지 않고 그 값을 순환문의 조건이나 메모리 할당, 메모리 복사 등에 쓰거나, 그 값에 근거해서 보안 관련 결정을 하면 취약점을 야기할 수 있습니다.
• LEFTOVER_DEBUG_CODE : 디버거 목적으로 삽입된 코드를 검출합니다. 디버거 목적으로 삽입된 코드가 제거되지 않고 운영상에서 그대로 남아있게 되면, 사용자 식별과정을 우회하거나 의도하지 않은 정보가 유출될 수 있습니다.
• NULL_RETURN : 널 값이 반환되는 경우 널 확인을 하지 않고 역 참조하는 경우에 경고를 냅니다. 보통 모든 프로그램에서 널을 반환할 수 있는 함수들의 결과들은 항상 널 확인을 하고 사용해야 합니다. 이렇게 하지 않을 경우, 시스템의 기능을 멈추게 할 수도 있습니다.
• NULL_RETURN_STD : Java standard library 들 중에 널을 반환할 가능성이 있는 메소드 들로부터 값을 특정 변수에 할당한 뒤, 이 변수의 널 확인을 하지 않고 이 변수를 바로 역 참조하는 경우에 경고를 냅니다. 보통 모든 프로그램에서 널을 반환할 수 있는 함수들의 결과들은 항상 널 확인을 하고 사용해야 합니다. 이렇게 하지 않을 경우, 시스템의 기능을 멈추게 할 수도 있습니다.
• RESOURCE_LEAK : 특정 자원이 할당이 되었지만, Java 가상 머신의 garbage collector에 의해서 빠르게 자원회수가 되지 않을 경우에 발생합니다. 대부분의 Heap memory와 관련된 메모리 관리는 JVM이 책임지지만, Socket, Stream, Channel과 같은 자원은 그렇지 않습니다. 그러므로 이러한 자원은 프로그램 작성자가 적절히 해제를 해주는 코드를 작성하여야 합니다. 그렇지 못할 경우에는 성능저하, 시스템기능의 멈춤, DOS(Denial of Service), 또 다른 자원을 획득함에 있어서의 실패를 야기할 수 있습니다. Resource Leak 관련 CWE 설명: Resource Leak 오류는 프로그램의 유용성과 기밀성관련 문제를 야기합니다. 첫 번째인 유용성 문제는, 대부분의 해제가 되지 않은 자원은 소프트웨어의 신뢰성 문제를 야기합니다. 만약, 공격자가 고의적으로 Resource Leak을 유발한다면, 공격자는 자원 풀의 모든 자원을 고갈시켜서 DOS(Denial of Service) 공격을 시도할 수 있습니다. 두 번째인 기밀성 문제는, 민감한 정보가 포함된 자원이 재대로 해제가 되지 않는다면, 공격자는 이 정보를 유출시켜서 악의적인 방법으로 사용할 수 있습니다.
• SQL_INJECTION : SQL 삽입 공격은 클라이언트에서 응용프로그램으로 들어가는 입력데이터를 통하여 SQL 쿼리를 삽입 혹은 “주입”을 함으로써 이루어집니다. SQL 삽입에 성공하면, 공격자는 데이터베이스로부터 민감한 데이터를 읽거나, 수정하거나 (삽입/업데이트/ 삭제), 데이터베이스에 관리작업 명령어(i.e. 데이터베이스 종료)를 수행할 수 있고, 데이터베이스상에 존재하는 파일 중에, 운영체제관련 명령어들이 기록되어 있을 수 있는 파일을 얻어올 수 있습니다. SQL 삽입 공격들은 삽입공격 형식 중에 하나이고, SQL 삽입 공격은 미리 정의된 SQL 명령어들을 실행할 수 있도록 데이터수준의 입력 값에 SQL 명령어들이 삽입 됩니다. -공격자는 SQL 삽입을 통하여 신분을 도용하거나, 기존의 데이터를 조작할 수 있고, 트랜잭션을 무효화 하거나, 잔금을 변경하는 등의 지불거절 문제를 일으킬 수 있습니다. 또한 공격자는 시스템의 모든 데이터를 드러내거나, 삭제, 이용 불가능하게 할 수 있고, 데이터베이스 서버의 관리자 권한을 획득할 수 있습니다. -SQL 삽입은 이전 기능 인터페이스의 유행으로 인해, PHP 와 ASP 응용프로그램에서는 아주 흔하게 발생합니다. J2EE 와 ASP.NET 응용프로그램은 프로그램의 특성상, SQL 삽입 공격이 덜 발생합니다. -SQL 삽입 공격의 위험도는 공격자의 기술과 창의력, 데이터베이스 서버 링크 시 낮은 권한으로 링크를 하는 등의 보호조치가 얼마나 잘 되어 있는 지에 따라 좌우됩니다. 일반적으로 SQL 삽입은 위험성이 높은 공격이라고 간주합니다.
• SystemPrintln : System.out.print(), 혹은 System.err.print() 메소드 호출을 검출합니다.
• UNUSED_IMPORT : import된 클래스가 하나도 사용되지 않은 경우를 검출합니다.
• UnusedLocalVariable : 사용하지 않는 지역변수을 검출합니다.
• USE_BLOCK_SYNCHRONIZED : synchronization의 과다적용을 자제해야 합니다. 메소드 레벨의 synchronization 보다 블록 레벨 synchronization 을 사용하는 것이 바람직합니다.
• USING_DYNAMIC_CLASS_LOADING : 동적으로 코드를 로드할 필요가 있다면, 이해하기 쉽고 문서화가 잘되어야 합니다. 악의적인 코드는 동적으로 로드된 코드에 포함될 수 있습니다. 동적으로 로드된 코드는 공격자가 응용프로그램이 실행중에 악의적인 코드를 삽입할 수 있습니다.

위처럼 검출된 항목의 종류는 몇개 되지 않지만, 검출된 항목의 개수는 정확히 605개!! ㅡOㅡ; 그래도 다른 개발사에 비하면 반의 반도 되지 않는다는 것에 위안을 가지는.. 이런거에 위안 가지만 안되는데…..