안전한 코드 작성 지침
업데이트: 2007년 11월
다음 지침에서는 보안 코드 작성을 위한 여러 가지 기술에 대해 설명합니다.
필수
코드 분석 도구를 사용합니다.
Visual Studio Team System Development Edition에는 코드의 보안 버그를 찾을 확률을 크게 향상시켜 주는 코드 분석 도구가 포함되어 있습니다. 이러한 도구는 적은 노력으로도 효과적으로 버그를 찾아냅니다. 자세한 내용은 C/C++ 코드 오류 검색 및 수정 및 관리 코드 오류 검색 및 수정을 참조하십시오.
보안 검토를 수행합니다.
모든 보안 검토의 목적은 이미 릴리스된 제품의 보안을 패치나 수정 파일을 통해 강화하거나 최대한 안전하다고 판단될 때까지 새 제품의 출시를 미루는 것입니다.
코드를 무작위로 검토하지 마십시오. 보안 검토를 미리 준비하고 신중하게 위협 모델을 만들어 검토를 시작합니다. 그렇게 하지 않으면 팀에 할당된 시간을 많이 낭비할 수 있습니다. 가장 중점적으로 보안 검토를 받고 보안 버그를 해결해야 하는 코드의 우선 순위를 지정합니다.
보안 검토에서 찾아야 할 사항을 구체화합니다. 구체적인 문제를 찾으면 대개 발견됩니다. 팀이 한 영역에서 여러 가지 보안 버그를 찾을 경우에는 더 엄격하게 검토해야 합니다. 이런 경우는 해결해야 할 아키텍처 문제가 있다는 의미일 수 있습니다. 보안 버그가 발견되지 않으면 대개 보안 검토가 제대로 이루어지지 않은 것입니다.
보안 검토를 각 과정에 대한 안정화의 일부로 포함하고 관리를 통해 설정된 큰 제품 라인을 유지합니다.
보안에 대한 코드 검토 검사 목록을 사용합니다.
소프트웨어 개발 팀에서 수행하는 역할에 관계없이 디자인과 코드를 최소한의 지표에 맞추기 위해 따라야 할 검사 목록을 갖추는 것이 좋습니다.
모든 사용자 입력의 유효성을 검사합니다.
응용 프로그램에서 직접 또는 간접적으로 사용자 입력을 받아들이는 경우 입력의 유효성을 확인한 다음 사용해야 합니다. 악의적인 사용자가 잘못된 데이터를 나타내도록 입력을 조작하여 응용 프로그램이 실패하도록 만들 수 있습니다. 사용자 입력에 적용되는 첫 번째 규칙은 입증되지 않은 모든 입력은 잘못된 입력이라는 것입니다.
정규식을 사용하여 사용자 입력의 유효성을 검사할 때는 주의해야 합니다. 전자 메일 주소와 같이 복잡한 식일 경우 완벽하게 유효성 검사를 수행하고 있다고 착각하기 쉽습니다. 동료에게 모든 정규식을 검토하도록 요청합니다.
내보낸 API(응용 프로그래밍 인터페이스)의 모든 매개 변수에 대해 유효성 검사를 철저히 수행합니다.
내보낸 API의 모든 매개 변수가 유효한지 확인합니다. 여기에는 지나치게 큰 버퍼 크기처럼 일관성 있어 보이지만 허용된 값 범위를 벗어난 입력이 포함됩니다. 릴리스 빌드에서는 어설션이 제거되므로 어설션을 사용하여 내보낸 API의 매개 변수를 검사하지 마십시오.
Windows 암호화 API를 사용합니다.
직접 암호화 소프트웨어를 작성하는 대신 제공된 Microsoft 암호화 API를 사용하십시오. Microsoft의 암호화 API를 사용하면 개발자들이 응용 프로그램 빌드에 집중할 수 있습니다. 암호화는 사소한 문제들을 효과적으로 해결하며, 전혀 새로운 방식으로 사용되는 경우가 많습니다. 자세한 내용은 MSDN Library의 암호화 개요를 참조하십시오.
금지 사항
버퍼 오버런
버퍼보다 큰 데이터를 복사하여 스택에 선언된 버퍼를 덮어쓰면 정적 버퍼 오버런이 발생합니다. 스택에 선언된 변수는 함수 호출자의 반환 주소 다음에 위치합니다. 버퍼 오버런은 힙에서도 발생할 수 있으며 위험합니다. 이 문제는 strcpy 등의 함수에 검사되지 않은 사용자 입력이 전달된 경우 발생하며, 그 결과 공격자가 선택한 주소가 함수의 반환 주소를 덮어쓰게 됩니다. 따라서 버퍼 오버런을 방지하는 것이 강력한 응용 프로그램 작성의 관건입니다.
외부 입력을 검사하기 위한 어설션
어설션은 정식 버전 빌드에 컴파일되지 않습니다. 어설션을 사용하여 외부 입력을 확인하지 마십시오. 내보낸 함수와 메서드의 모든 매개 변수, 모든 사용자 입력, 모든 파일과 소켓 데이터의 유효성을 신중하게 검사하고 오류가 있을 경우 거부해야 합니다.
하드 코드된 사용자 ID와 암호 쌍
하드 코드된 암호를 사용하지 마십시오. 설치 관리자를 수정하여 기본 제공 사용자 계정이 만들어질 때 관리자에게 각 계정에 대해 강력한 암호를 요구하도록 만듭니다. 이 방식을 사용하면 고객의 프로덕션 수준 시스템에 대한 보안을 유지할 수 있습니다.
암호화를 사용하여 모든 보안 문제 해결
암호화는 사소한 문제들을 효과적으로 해결하며, 전혀 새로운 방식으로 사용되는 경우가 많습니다.
정식 파일 경로 및 URL
파일 위치나 URL이 중요시되는 상황은 피합니다. 정식 파일 이름을 기반으로 하는 규칙 대신 파일 시스템 ACL을 사용하십시오.
권장 사항
응용 프로그램의 이전 보안 오류를 모두 검토합니다.
이전에 겪었던 보안 실수에 대해 잘 알아 두어야 합니다. 코드는 반복 패턴으로 작성되는 경우가 많으므로 한 사용자에 의해 특정 위치에서 발생된 버그는 다른 사용자에 의해 다른 위치에서도 똑같이 발생될 수 있습니다.
모든 오류 경로를 검토합니다.
오류 경로에 있는 코드는 종종 제대로 테스트되지 않으며 잠금 또는 할당된 메모리와 같은 모든 개체를 정리하지 않습니다. 이러한 경로를 신중하게 검토하고 필요하면 오류 삽입 테스트를 만들어 코드를 실행해 보십시오.
권장되지 않는 사항
관리자 권한으로 응용 프로그램 실행
응용 프로그램은 작업 수행에 필요한 최소한의 권한으로 실행되어야 합니다. 악의적인 사용자가 보안 취약성을 발견하고 프로세스에 코드를 삽입할 경우 호스트 프로세스와 동일한 권한으로 악성 코드가 실행됩니다. 프로세스가 관리자 권한으로 실행되면 악성 코드가 관리자 권한으로 실행됩니다. 자세한 내용은 MSDN Library에서 Developing Secure Applications를 참조하십시오.