about Security/SECURE CODING17 [코드오류] NULL Pointer 역참조 (5등급) 0. 개요 널 포인터(Null Pointer) 역참조는 '일반적으로 그 객체가 널(Null)이 될 수 없다.' 라는 가정을 위반했을 때 발생한다. 공격자가 의도적으로 널 포인터 역참조를 발생시키는 경우, 그 결과로 발생하는 예외 상황을 이용하여 추후의 공격을 계획하는 데 사용될 수 있다. * Null 역참조 : 프로그램에서 객체가 생성되면 메모리 공간에 할당되어 저장되고 이 객체의 값을 불러오기 위해서는 객체가 저장된 메모리의 위치주소가 필요하다. 이때 객체가 Null인 경우에는 객체가 없는 것으로 간주되어 메모리에 저장되지도, 저장된 주소값도 존재하지 않게 된다. 이런 상황에서 Null 인 객체를 호출하면 불러올 주소값이 존재하지 않아 프로그램이 정상적으로 작동할 수 없게 된다. 1. 보안 대책 - N.. 2021. 8. 10. [에러 처리] 오류 상황 대응 부재 (4등급) 0. 개요 오류가 발생할 수 있는 부분에 대해 예외 처리를 하지 않았을 때, 공격자가 오류 상황을 악용하여 개발자가 의도하지 않은 방향으로 프로그램이 동작하도록 할 수 있다. 1. 보안 대책 - 오류가 발생할 수 있는 부분에 대하여 제어문을 사용하여 적절하게 예외 처리를 한다. : JAVA >> try-catch C,C++ >> if, switch 2. 진단 방법 - 오류가 발생할 수 있는 구간에 에러발생시 적절한 예외처리 내용이 있는지, 잘 수행되는지 확인한다. 3. 코드 예시 # 1 - 오류 상황 대응 부재 - 안전하지 않은 코드 예시(JAVA) 위의 코드는 try 블럭에서 발생하는 오류를 catch는 하지만 그 오류에 대한 조치를 취하고 있지 않다. 이런 경우 오류가 발생하더라도 프로그램이 계속 실.. 2021. 8. 7. [보안 기능] 취약한 암호화 알고리즘 사용 (4등급) 0. 개요 SW 개발자들은 환결설정 파일에 저장된 패스위드를 보호하기 위해 간단한 인코딩 함수를 이용하기도 한다. 하지만 base64와 같은 지나치게 간단한 인코딩 함수로는 패스위드를 제대로 보호할 수 없다. 정보보호 측면에서 취약하거나 위험한 암호화 알고리즘을 사용해서는 안된다. 표준화되지 않은 암호화 알고리즘을 사용하는 것은 공격자가 알고리즘을 분석하여 무력화시킬 수 있는 가능성을 높인다. 또한 몇가지의 오래된 암호화 알고리즘은 컴퓨터의 성능이 상향되어 취약해져, 몇일, 몇시간내에 해독될 수 있다. 취약한 알고리즘 : RC2, RC4, RC5, RC6, MD4, MD5, SHA1, DES ... 1. 보안 대책 - 자신만의 암호화 알고리즘을 개발하는 것은 위험하다. : 학계 및 업계에서 이미 검증된 .. 2021. 8. 7. [입력 데이터 검증 및 표현] 정수형 오버플로우 (4등급) 0. 개요 정수형 오버플로우는 정수형 크기는 고정되어 있는데 저장할 수 있는 범위를 넘어선 큰 값을 저장하였을 때, 실제 저장되는 값이 의도치 않게 아주 작은 수 혹은 음수가 되어 프로그램이 의도치 않게 동작하는 경우를 야기한다. 특히 반복문 제어, 메모리 할당, 메모리 복사 등을 위한 조건으로 사용자가 제공하는 입력값을 사용하고 그 과정에서 정수형 오버플로우가 발생하는 경우 보안상 문제를 유발할 수 있다. 1. 보안 대책 - 언어 / 플랫폼별 정수 타입의 범위를 확인하여 사용한다. - 정수형 변수를 연산에 사용하는 경우, 결과 값의 범위를 체크하는 모듈을 사용한다. - 외부 입력값을 동적 메모리 할당에 사용하는 경우, 변수 값이 적절한 범위 내에 존재하는 값인지 확인한다. - 외부 입력값을 보안기능을 .. 2021. 8. 7. [입력 데이터 검증 및 표현] 위험한 형식 파일 업로드 (3등급) 0. 개요 서버 측에서 실행될 수 있는 스크립트 파일(asp, jsp, php 파일 등)이 업로드 가능하고, 이 파일을 공격자가 웹을 통해 직접 실행시킬 수 있는 경우, 시스템 내부명령어를 실행하거나 외부와 연결하여 시스템을 제어할 수 있는 보안약점이다. 2020.11.15 - [about Security/웹 해킹] - [웹해킹] # 파일 업로드 2020.11.15 - [about Security/웹 해킹] - [웹해킹 실습] # 파일 업로드 공격 1. 보안 대책 - 업로드 되어 저장되는 파일의 타입, 크기, 개수, 실행권한을 제한해야 한다. - 업로드 되어 저장되는 파일은 외부에서 식별되지 않아야 한다. - 화이트 리스트 방식으로 허용된 확장자만 업로드를 허용한다. * 화이트 리스트 방식 : 안전이 증.. 2021. 8. 7. [입력 데이터 검증 및 표현] HTTP 응답분할 (3등급) 0. 개요 HTTP 요청에 들어있는 파라미터가 HTTP 응답헤더에 포함되어 사용자에게 다시 전달될 때, 입력값에 CR이나 LF같은 개행문자가 존재하면 HTTP가 2개 이상으로 분리될 수 있으며 이때 공격자는 개행문자를 이용하여 첫 번째 응답을 종료시키고 두 번재 응답에 악의적인 코드를 주입하여 XSS 및 캐시 훼손(Cache Poisoning)공격 등을 수행할 수 있다. 1. 보안 대책 - 요청 파라키터의 값을 HTTP 응답헤더 (ex: Set-Cookie 등)에 포함시킬 경우 CR, LF와 같은 개행문자를 제거한다. - 외부 입력 값을 쿠키 및 HTTP 헤더정보로 사용하는 경우, HTTP 응답분할 취약점을 가지지 않도록 필터링하여 사용한다. 2. 진단 방법 - response 헤더에 변수가 사용되는지 .. 2021. 8. 7. [캡슐화] 제거되지 않고 남은 디버그 코드 (3등급) 0. 개요 디버깅 목적으로 삽입된 코드는 개발이 완료되면 제거해야 한다.즉, 설정 등의 민감한 정보나 시스템을 제어하도록 허용하는 부분을 담고 있는 디버그 코드가 남겨진 채로 배포될 경우, 공격자가 식별 과정을 우회하거나 의도하지 않은 정보나 제어 정보가 노출될 수 있다. 1. 보안 대책 - 소프트웨어 배포 전, 반드시 디버그 코드를 확인 및 삭제한다.: 특히 JAVA개발 경우 디버그용도의 코드를 main()에 작성한 후 삭제하지 않는 경우가 많다. 잘 삭제하도록 하자. 2. 진단 방법 - 개발 중 사용한 테스트 목적의 디버그 코드가 존재하는지 확인 3. 코드 예시 # 1 - 제거되지 않고 남은 디버그 코드 - 안전하지 않은 코드 예시(JAVA) # 1 + 제거되지 않고 남은 디버그 코드 - 안전한 코드.. 2021. 8. 7. [보안기능] 중요정보 평문저장 (3등급) 0. 개요 개인정보, 인증정보, 금융정보와 같은 중요 데이터를 암호화하여 저장하지 않아 제대로 보호되지 않을 경우, 보안이나 데이터의 무결성을 잃을 수 있다. 프로그램이 개인정보, 인증 정보등의 사용자 중요정보 및 시스템 중요 정보를 처리하는 과정에서 이를 평문으로 저장할 경우 공격자에게 민감한 정보가 노출될 수 있다. 1. 보안 대책 - 개인정보, 금융정보, 패스위드 등 중요정보를 저장할 때는 반드시 암호화하여 저장한다. : 서버의 DB나 파일 등에 저장되는 중요정보는 반드시 암호화한다. : 안전한 암호알고리즘과 암호기키를 적용한다. (보안요구항목) - 중요정보를 읽거나 쓸 경우에 권한인증 등을 통해 적합한 사용자만이 중요정보에 접근하도록 한다. : 설계 단계부터 주요정보가 다뤄지는 안전영역을 설정하고.. 2021. 8. 7. 이전 1 2 다음
