CGI(Common Gateway Interface)는 기본적으로 사용자의 요구를 서버의 응용프로그램에 전달한 후 그 결과를 사용자에게 되돌리는 일을 수행한다. CGI는 HTTP의 일부로써 누구나 사용 가능하다. CGI스크립트는 웹서버에서 CGI 데이터를 처리하는 작은 컴퓨터 프로그램으로 볼 수 있다. 예를 들어, 웹페이지에서 폼(form)을 처리하는 방식이 바로 CGI다.
CGI는 잠재적으로 보안 허점을 갖고 있다. 인터넷 검색엔진에서 보안 취약성에 관한 키워드로 질의하면 특정 공격 방법에 취약한 사이트의 목록이 나오는 경우도 있다.(주민등록번호 따위)
방화벽의 또 다른 유형으로 프록시(proxy)가 있다. 성곽 안팎에 각각 한 명씩의 보초가 있는 상황을 생각해 보자. 밖에 있는 보초는 안에서 무슨일이 일어나는지 모르고, 마찬가지로 안에 있는 보초는 박에서 무슨일이 벌어지는지 모른다. 이런 상황에서 둘 사이에 패킷을 주고 받는다. 유저가 문서를 필요로하면 클라이언트 소프트웨어가 방화벽(안쪽의 보초)에게 요구하고, 방화벽(바깥쪽의 보초)은 해당 웹사이트로 가서 원하는 문서를 갖다주는 식이다. 또 다른 종류의 프록시 방화벽들은 저장 후에 전달하는(store-and-forward)프록시 인데, 이러면 정해진 규칙에 따라 데이터를 걸러낼 수 있다.
방화벽을 "잘난척하는 라우터"라고 표한한 사람이 있다. 강력한 보안 기능을 갖춘 라우터를 제대로 설정하기만 하면 방화벽보다 안전하다는 것이다.
----------------------------------------------------------------------
예전(1970년대)에는 컴퓨터 프로그램들의 덩치가 커서, 작성하기도 어렵고 관리하기도 어려웠다. 그 후에 누군가가 큰 프로그램을 작고 이해하기 쉬운 컴포넌트별로 나누는 방식을 생각했다. 그런 발상으로부터 객채지향 프로그래밍, C++, 모듈, 플러그인이 나왔다. 이러한 컴포넌트 기반 소프트웨어의 문제점을 보안에 훨씬 취약하다는 것이다.
브라우저에 있어서는 자바 가상 머신이 하나의 컴포넌트인데, 그 위에서 자바 애플릿이 동작한다. 어떤 자바 애플릿에는 플러그인들이 포함되어 있기도 하다. 워드프로세서나 스프레드시트에는 온갖종류의 매크로가 들어있다.
그리고 단일 프로그램으로 배포되는 브라우저도 실제로는 함께 작동하는 여러 가지 상이한 컴포넌트들로 구성되어 있다. 워드프로세서나 스프레드시트도 이런 식으로 만들어져 있다. 일례로 마이크로 소프트 워드 97에는 1000개 이상의 컴포넌트가 들어있다.
NT도 컴포넌트 위에 컴포넌트가 있다. 이런 것은 링크를 동적으로 실행한다는 점이다. 옛날 패러다엠에서는 판매가 이루어지기 전에 프로그램 조각들이 제작자에 의해 하나로 합쳐졌었다.(프로그래밍 언어로 이것을 linking이라고 한다.) 따라서 프로그래머들은 프로그램이 링크한 다음에 모든 요소가 제대로 동작하는지 확인하곤 했다. 그런데 오늘날의 컴포넌트는 대개 응용프로그램을 실행하는 시점에서 동적으로 링크된다. 윈도우 사용자들은 DLL(Dynamic Linking Library)이라는 용어를 많이 들어보았을 것이다. 유닉스나 매킨토시에서는 공유라이브러리(shared library)라고 부른다.
이런 것들은 각 모듈들을 신뢰할 수 없기 때문에, 여러 방법이 제시됬지만, 이론적으로만 그럴듯한 편이다. 격리에 의한 메모리 보호의 예로 자바 샌드박스(sand box)가 있는데, 컴포넌트들이 각각의 샌드박스 안에서만 실행되므로 다른 컴포넌트에 피해를 줄 수 없다. 이런 방식이 효과적인 경우도 있지만, 속도가 느려지는 단점이 있다.
CGI는 잠재적으로 보안 허점을 갖고 있다. 인터넷 검색엔진에서 보안 취약성에 관한 키워드로 질의하면 특정 공격 방법에 취약한 사이트의 목록이 나오는 경우도 있다.(주민등록번호 따위)
방화벽의 또 다른 유형으로 프록시(proxy)가 있다. 성곽 안팎에 각각 한 명씩의 보초가 있는 상황을 생각해 보자. 밖에 있는 보초는 안에서 무슨일이 일어나는지 모르고, 마찬가지로 안에 있는 보초는 박에서 무슨일이 벌어지는지 모른다. 이런 상황에서 둘 사이에 패킷을 주고 받는다. 유저가 문서를 필요로하면 클라이언트 소프트웨어가 방화벽(안쪽의 보초)에게 요구하고, 방화벽(바깥쪽의 보초)은 해당 웹사이트로 가서 원하는 문서를 갖다주는 식이다. 또 다른 종류의 프록시 방화벽들은 저장 후에 전달하는(store-and-forward)프록시 인데, 이러면 정해진 규칙에 따라 데이터를 걸러낼 수 있다.
방화벽을 "잘난척하는 라우터"라고 표한한 사람이 있다. 강력한 보안 기능을 갖춘 라우터를 제대로 설정하기만 하면 방화벽보다 안전하다는 것이다.
----------------------------------------------------------------------
예전(1970년대)에는 컴퓨터 프로그램들의 덩치가 커서, 작성하기도 어렵고 관리하기도 어려웠다. 그 후에 누군가가 큰 프로그램을 작고 이해하기 쉬운 컴포넌트별로 나누는 방식을 생각했다. 그런 발상으로부터 객채지향 프로그래밍, C++, 모듈, 플러그인이 나왔다. 이러한 컴포넌트 기반 소프트웨어의 문제점을 보안에 훨씬 취약하다는 것이다.
브라우저에 있어서는 자바 가상 머신이 하나의 컴포넌트인데, 그 위에서 자바 애플릿이 동작한다. 어떤 자바 애플릿에는 플러그인들이 포함되어 있기도 하다. 워드프로세서나 스프레드시트에는 온갖종류의 매크로가 들어있다.
그리고 단일 프로그램으로 배포되는 브라우저도 실제로는 함께 작동하는 여러 가지 상이한 컴포넌트들로 구성되어 있다. 워드프로세서나 스프레드시트도 이런 식으로 만들어져 있다. 일례로 마이크로 소프트 워드 97에는 1000개 이상의 컴포넌트가 들어있다.
NT도 컴포넌트 위에 컴포넌트가 있다. 이런 것은 링크를 동적으로 실행한다는 점이다. 옛날 패러다엠에서는 판매가 이루어지기 전에 프로그램 조각들이 제작자에 의해 하나로 합쳐졌었다.(프로그래밍 언어로 이것을 linking이라고 한다.) 따라서 프로그래머들은 프로그램이 링크한 다음에 모든 요소가 제대로 동작하는지 확인하곤 했다. 그런데 오늘날의 컴포넌트는 대개 응용프로그램을 실행하는 시점에서 동적으로 링크된다. 윈도우 사용자들은 DLL(Dynamic Linking Library)이라는 용어를 많이 들어보았을 것이다. 유닉스나 매킨토시에서는 공유라이브러리(shared library)라고 부른다.
이런 것들은 각 모듈들을 신뢰할 수 없기 때문에, 여러 방법이 제시됬지만, 이론적으로만 그럴듯한 편이다. 격리에 의한 메모리 보호의 예로 자바 샌드박스(sand box)가 있는데, 컴포넌트들이 각각의 샌드박스 안에서만 실행되므로 다른 컴포넌트에 피해를 줄 수 없다. 이런 방식이 효과적인 경우도 있지만, 속도가 느려지는 단점이 있다.
댓글 달기