
개발자에서 보안업계 넘어오게 되면서 우연한 기회로 시작한 Fortify 엔지니어. 낮은 보안지식때문에 저녁부터 주말까지 열심히 공부해가면서 적응했었던 기억이 납니다. 그나마 수행업무는 Fortify를 이용한 진단수행 및 결과분석이였기 때문에 모의해킹도 못하고, 수동진단 또한 할 수 없었지만, 개발자 출신답게 코드는 읽을 수 있었고, 업무에는 빠르게 적응할 수 있었습니다. 그리고 2년간의 Fortify 엔지니어를 지내오면서 다양한 취약점과 취약코드를 알 수 있게 되었죠. 당시 개발보안에 대해 닥치는 대로 공부하고 있었던 터라, 진단원에 대해 알게되었을 때도 관심이 있었지만, 가이드를 있는 그대로 외우지 않으면 떨어진다는 동종업계 분들의 이야기에 관심을 접었었죠. 그러다 현재 회사로 이직을 하면서는 소스코드..

가. 원인 - 보안상 금지되었거나, 부주의하게 사용될 가능성이 많은 API를 사용하는 경우 나. 영향 - 위험한 API를 확인하지 않고 사용 시 보안문제를 야기 - 잘못된 방식으로 사용하여 보안문제를 야기 다. 보안대책 - 보안문제로 금지된 함수를 대체할 수 있는 안전한 함수를 사용 라. 안전한 코드 1. 보안기능을 제공하는 프레임워크의 메소드를 사용 ... // 보안기능을 제공받지 못하는 socket 대신 프레임워크의 메소드를 사용 //Socket sock = new Socket( "kisa.or.kr", 8080 );

가. 원인 - 도메인 명에 의존하여 보안결정을 하는 경우 나. 영향 - DNS 스푸핑 등을 통해 DNS 캐시가 오염될 경우, 사용자와 서버 사이의 트래픽이 공격자를 경유 다. 보안대책 - 보안결정에 DNS 조회결과를 사용하지 않도록 구현 라. 안전한 코드 1. IP로 보안결정 public doGet( HttpServletRequest req, HttpServletResponse res ) { ... String ip = req.getRemoteAddr(); // DNS로 보안결정할 경우 DNS 스푸핑에 취약 // InetAddress addr = InetAddress.getByName( ip ); // if ( !addr.getCaonicalHostName().endWith( "trustsite.com"..

가. 원인 - Public으로 선언된 메서드의 인자를 Private 배열로 저장하는 경우 나. 영향 - Private 배열을 외부에서 직접 접근하여 값을 수정이 가능 다. 보안대책 - Public으로 선언된 메서드의 인자를 Private으로 선언된 배열에 저장하지 않도록 구현 - 인자로 들어온 배열의 복사본을 생성하여 clone() 메서드를 통해 복사된 원소를 저장 - 전달받은 Public 배열의 레퍼런스 대신 값을 Private 배열에 할당 라. 안전한 코드 1. clone으로 복사본을 생성 public class UserManagement { private UserInfo[] myUsers; public void setUserInfo( UserInfo[] users) { this.myUsers = n..

가. 원인 - Private으로 선언된 배열을 Public 메서드로 반환하는 경우 나. 영향 - 외부에서 배열의 데이터를 직접 수정이 가능 다. 보안대책 - private 배열을 반환하지 않는다. - private 배열을 반환 시 배열의 복제본을 반환하도록 로직을 구현 - private 배열을 수정해야 할 경우 별도의 public 메서드를 생성하여 사용 라. 안전한 코드 1. private 배열의 복제본을 반환 public class MyClass { private String[] colors; public String[] getMyColor( ) { String[] copyColor = new String[ this.colors.lenght ]; // private 배열의 값을 복사한 별도의 배열을 리..

가. 원인 - 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이 아닐 경우에만 메모리 반환 // 이후 다시 해제하더라도..
- Total
- Today
- Yesterday