가. 원인 - Exception 발생 시 시스템 / 관리자 / DB정보 등의 시스템 내부정보가 사용자에게 노출되는 경우 나. 영향 - 오류정보를 통해 시스템 / 관리자 / DB정보 등의 중요정보가 노출 - 노출된 정보를 이용하여 추가적인 공격에 활용 가능성 다. 보안대책 - Exception 발생 시 시스템 내부정보가 화면에 출력되지 않도록 개발 - Exception 발생 시 오류와 관련된 정보가 노출되지 않도록 getMessage( ) 메서드를 사용제한 - 오류발생 시 디폴트 오류 페이지가 사용자에게 전달되도록 환경설정 라. 안전하지 않은 코드 1. getMessage( ) 사용 try { ... catch ( Exceptoin e ) { // getMessage 대신 정보노출이 되지 않는 수준의 오류..
가. 원인 - 디버깅 목적으로 삽입된 코드가 제거되지 않은 경우 나. 영향 - 민가정보나 시스템 제어를 허용하는 디버그 코드가 존재할 경우, 인증우회 / 정보노출 등이 발생 가능 다. 보안대책 - SW 배포 전 디버그 코드를 반드시 확인 및 삭제 - 디버그 목적으로 사용하는 main 함수를 삭제 라. 안전하지 않은 코드 1. 디버그 함수 및 코드 존재 class LoginManagement{ ... // 디버그 목적의 main 함수 존재 public static void main( String[] args ) { ... } public boolean requestLogin( String id, String password ) { boolean bLogined = false; // 관리자 계정으로 자동 로..
가. 원인 - 다중 스레드 환경에서 싱글톤 객체의 멤버변수를 사용하는 경우 나. 영향 - 다중 스레드 환경에서 싱글톤 객체 필드에 경쟁조건이 발생 - 싱글톤 객체의 멤버변수를 여러 스레드에 의해 공유되면서 다른 스레드에 정보를 노출 다. 보안대책 - 싱글톤 패턴을 사용 시 변수의 범위에 주의하여 사용 - Java HttpServlet / JSP / Controller 에서 멤버 필드 사용 금지 라. 안전하지 않은 코드 1. JSP에서 멤버변수 사용 //
가. 원인 - C언어에서 스택 메모리에 저장하는 변수를 초기화하지 않고 사용하는 경우 나. 영향 - 초기화 하지 않은 변수는 이전 함수에 사용되었던 내용을 포함하고 있음 - 메모리에 저장되어 있는 값을 읽거나 특정코드를 실행 다. 보안대책 - 모든 변수를 사용전에 반드시 올바른 초기값을 할당 라. 안전한 코드 1. 변수에 초기값 설정 int x = 0; int y = 0; ... switch( position ) { case 0: x = 10; break; defualt: y = 10; break; } setCursorPosition( x, y ); 마. 진단방법 1. 변수를 선언하는 코드를 확인 2. 선언 시 변수를 초기화 하는지 확인 바. 정/오탐 케이스 1. 별도의 변수를 초기화 하지 않는 디폴트 ..
가. 원인 - 개발자가 직접 메모리 해제를 수행해야 하는 경우, 해제된 자원을 다시 해제하거나, 사용할 경우 나. 영향 - 해제한 자원을 다시 참조할 경우, 오류가 발생하거나 비정상 실행 다. 보안대책 - 동적으로 할당한 자원을 해제 후 포인터에 NULL을 저장하여 해제된 자원에 접근하지 않도록 구현 라. 안전한 코드 1. 자원해제 여부 확인 int function( char *argv ) { ... char *data; data = (char *)malloc( BUFFER_SIZE ); ... memcpy( data, argv, BUFFER_SIZE -1 ); data[BUFFER_SIZE-1] = '\0'; ... // 할당한 메모리가 null이 아닐 경우에만 메모리 반환 // 이후 다시 해제하더라도..
가. 원인 - 사용 후 반드시 자원해제해야 하는 메모리 / 파일 / DB연결 / 소켓 등의 유한한 자원이 사용이후 반환되지 않을 경우 나. 영향 - 해제하지 않은 자원이 고갈되어 더 이상 할당할 수 없는 상태 - 자원해제 코드가 잘못된 루틴에 존재하여 시스템 오류 발생 다. 보안대책 - 유한한 자원은 반드시 반환되도록 제어문이나 예외처리를 작성 - 자바의 경우 반환코드는 finally 블록에 구현하여 반드시 실행되도록 작성 라. 안전한 코드 1. finally 구문에서 자원해제 ... PrintWriter out = null; try { out = new PrintWriter( new FileWriter( "/read.txt" ); ... } catch (IOException e ) { ... } cat..
가. 원인 - 객체가 Null이 될 수 없다는 가정이 위반되었을 경우 발생 - Null로 설정된 참조변수를 참조하는 경우 나. 영향 - Null Pointer 역참조를 통해 발생되는 예외사항을 이용하여 추후 공격에 활용 다. 보안대책 - Null이 될 수 있는 참조변수를 사용하기 전 Null인지 여부를 검사 후 사용 라. 안전한 코드 1. Null Pointer 검사 후 사용 ... String user_id = request.getParameter("userID"); if ( user_id == null ) { showAlert( "Input User ID" ); break; } else { UserInfo objUserInfo = getUserInfo( user_id ); ... if ( objUse..
가. 원인 - 여러 개의 코드에 하나의 try 블럭을 설정하여, 모든 예외에 대해 하나의 방식으로 예외를 처리하는 경우 나. 영향 - 각각의 예외처리에 대해 적절한 대응이 불가 - 부적절한 리소스 관리로 시스템 중지 초래 - 예외 상황에 대한 적절한 로깅이 되지 않아 사후처리가 어려움 다. 보안대책 - 광범위한 예외처리 대신 구체적인 예외처리를 수행 - 각각의 예외 상황에 맞춰 적절한 예외 처리를 수행하도록 구현 라. 안전한 코드 1. 구체적 예외처리 BufferedReader rd = null; try { rd = new BufferedReader( new FileReader( new File( fileName ) ) ); String line = rd.readine(); SimpleDateFormat..
가. 원인 - 프로그램에서 발생한 오류에 대해 어떠한 조치도 수행하지 않아 비정상적인 상태로 실행되는 경우 나. 영향 - 개발자가 의도하지 않은 방향으로 프로그램이 동작 - DB연결 상태에서 예외 발생 시 열결해제 작업이 제대로 수행되지 않을 경우, DB연결을 수행할 수 없음 - 예외 상태에 대한 로깅정보가 존재하지 않을 경우, 오류 상황에 대한 사후처리가 어려움 다. 보안대책 - 오류가 발생할 수 있는 부분에 대해 적절한 예외처리를 구현 - Exception 발생 시 특별히 수행할 작업이 없을 경우, 간단한 메시지라도 로그로 기록 라. 안전하지 않은 코드 1. 안전하지 않은 오류처리 try { String strCnt = request.getParameter( "count" ) int count = I..
가. 원인 - 실행환경 / 사용자 등과 관련된 민감정보를 포함한 오류 메시지를 생성 및 외부에 출력 시 - Exception 발생 시 Exception 정보를 출력 시 나. 영향 - 공격자는 오류 메시지를 통해 공격에 활용될 수 있는 상세 오류 정보를 확인 - 공격자가 프로그램 내부구조를 쉽게 파악 다. 보안대책 - printStackTrace() 메서드를 사용하지 않도록 로직구현 - 오류 메시지를 유용한 최소한의 정보만 포함하여 사용 - Exception 발생 시 내부적으로 처리하고, 민감정보를 포함한 오류는 출력하지 않도록 미리 정의한 메시지를 제공 라. 안전한 코드 1. 최소정보 로깅 try { rd = new BufferedReader( new FileReader( new File( fileNam..
- Total
- Today
- Yesterday