일반적으로 신뢰할 수 있는 채널로부터의 정보 (입력 및 결과) 만을 신뢰해라. 예를 들어 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].