sungyup's.

understanding_the_digital_world / 통신 / 3.10 웹

3.10웹

웹의 개념과 주요 구성 요소 및 보안 관련 위험들

TL;DR

추억의 쪽지 시험

72. 월드 와이드 웹은 무료다

인터넷은 전 세계의 수많은 컴퓨터가 서로 쉽게 정보를 교환할 수 있게 하는 통신 인프라, 연결망이다. 인터넷이라는 단어와 종종 혼용되어 쓰이는 웹, 또는 월드 와이드 웹(World Wide Web)은 인터넷 위에서 작동하는 서비스 중 하나로 문서, 이미지, 링크 등으로 구성된 정보들을 연결한 시스템이다.

웹은 인터넷이 있다는 전제 하에 아래의 4가지 주요 요소로 이루어진다.

첫 번째는 URL(Uniform Resource Locator, 균일 자원 지시자)이다. URL은 https://www.sungyup.com처럼 정보 출처의 이름이다.

두 번째는 HTTP(Hypertext Transfer Protocol, 하이퍼텍스트 전송 프로토콜)이다. HTTP 클라이언트는 특정 URL에 대한 요청을 보내고 서버는 정보를 반환한다.

세 번째는 HTML(Hypertext Markup Language, 하이퍼텍스트 마크업 언어)이다. HTML은 서버가 반환하는 정보의 서식이나 표시 방식을 설명하는 언어다.

네 번째는 브라우저(Browser)다. 브라우저는 컴퓨터에서 실행되는 크롬, 사파리, 파이어폭스, 엣지 같은 프로그램으로 URL과 HTTP를 사용해 서버에 요청을 보내고 서버에서 반환한 HTML을 표시한다.

웹은 1989년에 제네바 근처의 CERN(유럽 입자 물리 연구소)이라는 연구소에서 근무하던 영국인 컴퓨터과학자 Tim Berners-Lee가 인터넷을 통해 과학 문헌과 연구 결과를 더 쉽게 이용할 수 있는 시스템을 만들며 시작되었다.

최초의 브라우저는 Mosaic으로, 1993년에 일리노이 대학 학생들이 만들었다. 모자이크가 나온지 1년 후 최초의 상용 브라우저인 Netscape Navigator가 나왔다. 이후 마이크로소프트가 Internet Explorer를 1995년에 출시했고, 가장 널리 사용되는 브라우저가 되었다. 마이크로소프트는 PC 시장을 지배했고, 여러 분야에서 반독점 관련 문제에 부딪혔는데 그 중 IE도 포함되어 있었다. 마이크로소프트는 미국 법무부와의 소송에서 패배했고, 이후 IE도 서서히 힘을 잃었다.

오늘날 가장 많이 사용되는 브라우저는 구글의 Chrome으로, 2008년에 나왔다. 마이크로소프트는 대항마로 Edge를 냈는데, 처음에는 마이크로소프트 자체 코드를 사용했지만 2019년부터는 구글의 오픈소스 Chromium 브라우저 코드를 기반으로 구현되었다.

웹의 기술적 진화는 비영리 조직인 W3C(World Wide Web Consortium)가 관리하거나 방향을 제시한다. W3C는 웹의 창시자 팀 버너스리가 설립했고 책임을 지고 있는데, 그는 2004년 기사 작위를 받았다.

Microsoft의 Internet Explorer는 오랜 기간 사용되었지만, 표준 미준수, 보안 취약점, 불편한 UI, 느린 속도 등으로 개발자들에게 외면을 받기 시작했고, 경쟁자인 Chrome, Firefox는 빠르게 발전하며 웹 표준을 준수하고 속도를 개선해 대체재로 떠올랐다. 결국 IE에서는 작동하지 않는 많은 사이트가 생기며 IE는 사용자들에게도 외면받는다.

브라우저는 공짜 프로그램인데 왜 기업들은 이 복잡한 프로그램을 만들까?

우선 기업들에게 돈이 되기 때문이다. 대부분의 브라우저는 기본 검색 엔진을 설정해 놓는데, 검색 엔진은 검색 트래픽 당 광고 수익을 얻는다. 크롬은 구글로, 엣지는 빙으로 기본 검색 엔진을 설정해 두기 때문에 각 회사에 검색으로 인한 광고 수익을 안겨준다.

또, 자사 생태계를 강화할 수 있다. 엣지를 통해 빙을 쓰면 마이크로소프트 계정을 쓰고 윈도우즈를 쓰는 등 연결이 되고, 크롬은 구글을 쓰면 Gmail/Docs도 자연스럽게 쓰게 되고 안드로이드가 편하게 느껴지게 된다. 즉, 브라우저는 자사 생태계를 연결하는 입구(게이트웨이) 역할을 한다.

마지막으로, 웹 표준 주도권을 확보할 수 있다. 브라우저 개발사는 웹 기술 표준(W3C나 WHATWG 등)에 의견을 내고 기술 방향을 선도할 수 있다. 예를 들면 Google의 WebP는 크롬을 통해 밀어붙여 생긴 표준이다. 이런 전략적 가치들 때문에 회사들은 브라우저를 개발한다.

73. URL의 의미

하이퍼텍스트(hypertext)는 웹의 핵심적 개념 중 하나로, 단순히 내용을 전달하는 텍스트를 넘어 문서를 다른 문서와 연결한다. 하이퍼텍스트는 주로 밑줄이 그어진 파란 텍스트로 표현되는데, 이러한 링크 위에 마우스를 올리면 브라우저 창 하단의 상태 표시줄에 링크가 가리키는 URL이 https://www.sungyup.com 같은 식으로 표시된다. 이 URL 뒤에는 보다 세부적인 경로(/study/understanding_the_digital_world/web 등)가 표시되기도 한다.

링크를 클릭하면 브라우저가 해당 도메인의 80번 포트로 TCP/IP 연결을 열고, URL의 뒷부분에서 제공하는 정보에 대해 HTTP 요청을 보낸다. 이 때, HTTP 프로토콜을 사용하면 브라우저는 클라이언트의 요청과 함께 보통 몇 줄의 추가 정보(HTTP Headers)를 보낸다. 이 추가 정보는 메타 데이터로, 누가 보냈는지, 어떤 브라우저인지, 어떤 언어를 선호하는지, 어떤 형식으로 데이터를 보낼 건지, 쿠키나 인증 정보가 있는지에 대한 정보가 담겨있다.

요청을 받은 서버는 수행할 작업을 결정한다. 요청이 서버에 있는 파일에 대한 것이면 서버는 해당 파일 및 데이터의 양과 종류에 대한 정보를 담은 여분의 행을 포함한 응답을 보내고, 클라이언트인 브라우저는 파일을 표시한다. 서버에서 반환하는 파일은 대개 HTML 형식이다.

URL은 정보를 인코딩한다. 첫 번째 부분인 http는 프로토콜 부분으로, 로컬 컴퓨터에서 가져온 정보는 file, 그리고 암호화된 http인 https도 자주 볼 수 있다. URL에서 :// 다음에는 서버의 이름을 지정하는 도메인 이름이 나온다. 도메인 이름 뒤에는 슬래시(/)와 문자열이 오는데, 이 문자열은 서버에 그대로 전달되며, 서버는 문자열을 원하는 방식으로 처리한다. 가장 기본적인 형태는 슬래시조차도 없는 것으로, 이 경우 서버는 index.html 같은 기본 페이지를 반환한다.

이 외에도 파일 이름이 올 수 있다. 예를 들어 아래의 예시를 보자.

https://example.com/image.jpg?size=large&format=webp

여기서 image.jpg는 요청하는 리소스의 경로 또는 파일이다. 이후 ?로 시작하는 문자열은 쿼리 문자열(Query String)으로, 서버가 물음표 앞 부분에 있는 이름의 프로그램을 실행하고 나머지 텍스트는 해당 프로그램에 전달해야 한다는 것을 의미한다. 이렇게 뒤에 있는 나머지 텍스트, 즉 서버에 전달할 추가 정보는 파라미터라고 부른다. 웹 페이지의 form에 입력된 정보가 처리되는 방법 중 하나가 이 파라미터이다.

도메인 이름 뒤에 오는 텍스트는 영문자와 숫자를 제외한 대부분의 문자(공백도)가 허용되지 않는다. 따라서 이러한 문자들은 인코딩되는데, +기호는 공백을 인코딩하며, 다른 문자들은 %와 두 개의 16진 숫자로 인코딩된다. 예를 들면 16진수 27은 작은따옴표, 22는 큰따옴표 등이다.

74. HTML과 CSS로 간단한 웹페이지 만들기

서버에서 오는 응답은 주로 HTML 형태인데, HTML은 내용과 서식 정보가 결합된 형식이다. 내용은 텍스트로, 서식은 내용의 시작과 끝에 tag를 붙여 나타낸다. 예를 들면 아래와 같은 식이다.

html
<html>
  <title> My Page </title>
  <body>
    <h2> A heading </h2>
    <p> A paragraph </p>
    <p> Another paragraph </p>
    <img src="wikipedia.jpg" alt="Wikipedia logo" />
    <a href="http://www.wikipedia.org">link to wikipedia</a>
  </body>
</html/>

HTML에 들어있는 이미지 파일은 HTML 파일과 같은 위치에서 가져오지만, 웹의 어디서나 불러올 수도 있다. alt 속성은 이미지 자체를 보여줄 수 없을때 보여주는 대체 텍스트를 제공하는데, 시각이나 청각에 문제를 겪는 사용자에게 도움을 주는 웹 접근성 기법의 한 예다.

<img />와 같은 태그는 단독으로 사용될 수도 있어서 시작과 끝이 없지만, <body>와 </body>처럼 시작과 끝을 명확히 지정해야하는 태그도 있다.

대부분의 HTML 문서에는 CSS(Cascading Style Sheets, 캐스케이딩 스타일 시트)라고 불리는 또 다른 언어로 된 정보도 있는데, HTML 문서의 스타일 속성에 관한 정보이다.

HTM과 CSS는 모두 '언어'이지만 '프로그래밍 언어'는 아니다. '언어'인 것은 정형화된 문법과 의미 체계가 있기 때문이지만, '프로그래밍 언어'가 아닌 것은 루프와 조건문이 없어 알고리즘을 표현할 수 없기 때문이다.

HTML은 설계 당시에는 브라우저에 표시할 일반 텍스트만 다뤘지만, 콘텐츠를 빨리 다운로드 받을 수 있는 대역폭과 이를 표시할 수 있는 처리 성능이 발전하면서 이미지나 음향, 애니메이션, 동영상 재생 기능도 추가로 지원되었다.

CGI(Common Gateway Interface, 공통 게이트웨이 인터페이스)라는 메커니즘도 있다. CGI는 웹이 단순한 정적인 HTML 문서에서 벗어나 동적인 콘텐츠를 보여줄 수 있도록 만든 웹 초기 기술 중 하나로, 웹 서버와 외부 프로그램(스크립트) 간의 데이터 교환을 위한 표준 인터페이스이며 서버 컴퓨터에 있다.

CGI는 클라이언트(브라우저)에서 서버로 정보를 전달할 때 사용되는데, 예를 들어 웹 폼(HTML <form> ... </form> 태그)에 이름과 비밀번호를 적거나 라디오 버튼/드롭다운 메뉴 등에서 선택한 항목 정보 등을 제출하면 웹 서버는 이 요청을 CGI 프로그램에 전달한다. 프로그램은 입력값을 처리하고, HTML 결과를 생성해 응답하고 웹 서버는 그 결과를 브라우저로 전달한다. CGI 덕에 웹에선 로그인, 회원가입 등 웹 폼을 처리할 수 있게 되었고 검색, 데이터베이스 질의 및 댓글 쓰기 등이 가능해졌다.

다만, 매 요청마다 프로세스를 생성(프로그램을 새로 실행)하기 때문에 속도가 저하되고, 세션 관리가 없어서 상태를 유지할 수 없었다. 또, 많은 사용자가 동시에 접속하면 서버 부하가 발생했고 입력값 검증이 없으면 명령어 삽입 공격이 가능하다는 보안 위험이 있었다. 이에 오늘날에는 PHP, Node.js와 같은 서버 언어가 CGI 프로그램이 하던 동적 처리 역할을 대신하고 있다.

초기 웹에서 쓰이던 CGI는 웹 서버(Apache, Nginx)가 요청을 받고, 필요한 처리를 CGI나 PHP같은 외부 처리기로 넘겨주던 구조였다. 여기서 처리를 끝내면 서버는 결과를 반환하고, 브라우저는 문서를 표시해줬다.

오늘날에는 Node.js가 자기 자신이 서버이자 애플리케이션이기 때문에 바로 클라이언트 요청을 받아 처리하고 응답한다.

75. 쿠키를 삭제하시겠습니까?

HTTP는 무상태(stateless) 프로토콜이다. 이 말은, HTTP 서버가 클라이언트가 요청한 페이지를 반환하기만 하면 다른 것(데이터 교환 기록 등)은 아무것도 기억하지 않아도 된다는 용어다.

하지만 생각해보면, 아이디와 비밀번호 같은 정보는 서버가 상호작용할 때 계속 묻지 않도록 같은 정보를 이미 제공했다는 사실을 기억해야할 때가 있다. 이러한 문제에 대한 해결책으로 1994년 넷스케이프는 쿠키(cookie)라는 기술을 발명했다.

쿠키는 프로그램 간에 전달되는 작은 정보 조각을 의미하는데, 보다 구체적으로는 서버가 브라우저에 웹 페이지를 보낼 때 함께 보내서 브라우저에게 저장하게 하는 최대 약 4,000바이트의 추가 텍스트 덩어리를 의미한다. 브라우저가 이후 같은 서버에 요청을 보낼 때, 브라우저는 그 쿠키를 도로 전송한다. 즉, 서버가 클라이언트 쪽의 메모리를 사용해서 클라이언트의 이전 방문에 대한 정보를 기억하는 시스템이다. 주로 서버는 클라이언트마다 고유한 식별 번호를 할당하고 이 번호를 쿠키에 포함해서, 해당 식별 번호와 관련된 영구적인 정보를 서버의 데이터베이스에 보관한다. 이러한 정보에는 로그인 상태, 장바구니 내용, 사용자 설정 등이 있다. 사용자가 사이트를 다시 방문할 때마다 서버는 쿠키를 이용해 사용자가 이전에 왔던 사람인지 식별해서 정보를 설정한다.

한 서버에 방문할 때마다 여러 개의 쿠키가 저장되며, 각 쿠키에는 이름이 있다. 쿠키는 저장되었다가 다시 전송되는 완전히 수동적인 문자열일 뿐으로, 프로그램이 아니다. 또한, 쿠키는 자신이 생겨난 도메인으로만 도로 전송된다. 쿠키는 유효 기간이 있어 그 이후에는 브라우저에서 삭제된다. 브라우저가 쿠키를 허용하거나 반환해야만 한다는 요구조건은 없다.

76. 어도비 플래시는 왜 퇴출됐을까?

웹에서 클라이언트는 범용 프로그램을 실행할 수 있는 컴퓨터이기 때문에, 단순히 사용자를 대신하여 서버에 요청을 보내고, 텍스트를 보여주는 것 외에도 많은 일을 할 수 있다. 초기에는 이같은 특성을 활용하지 못했지만, 웹 기술이 빠르게 발전해 곧 브라우저를 통해 웹에서 코드를 다운로드해서 실행할 수 있게 되었는데, 이를 액티브 콘텐츠(Active Contents)라고 부른다.

넷스케이프의 네비게이터 초기 버전에는 브라우저 내에서 자바 프로그램을 실행할 수 있었다. 자바는 Write Once, Run Anywhere라는 철학으로 만들어져 가전제품처럼 컴퓨팅 성능이 그다지 좋지 않은 환경에서도 설치될 수 있도록 설계된 언어이기 때문에, 브라우저에도 자바 인터프리터를 포함하는것이 기술적으로 가능했다. 그 덕에 브라우저에서 중요한 연산을 할 수 있다는 것이 드러났고, 사람들은 브라우저가 워드프로세서나 스프레드시트 같은 기존 프로그램은 물론, 운영체제 자체를 대체할 수 있다는 생각을 하게 되었다.

그러나 이는 워드프로세서나 스프레드시트, 그리고 운영체제를 주력으로 삼고 있던 마이크로소프트에게는 좋은 소식이 아니었다. 이에, 마이크로소프트는 자바의 가장 큰 장점인 플랫폼 독립성을 약화시키기 위해 자바를 자체적으로 수정해 Microsoft Java Virtual Machine이라는 것을 만들어 표준 Java API 일부를 빠뜨리고, 변경하고, Windows 전용 API를 추가하는 등 Windows에 자바를 종속시켰다. 즉, Windows에서만 실행되고 다른 OS에서는 깨지는 자바 코드라는, 기존 자바의 플랫폼 독립성 철학을 무너뜨리는 자바 코드가 쓰이게 되었다.

1997년, 자바의 개발사인 Sun Microsystems는 마이크로소프트가 자바의 호환성 유지 조건을 무시하고 라이선스 계약을 어겼다고 소송을 제기했고, 2001년에 마이크로소프트는 썬 마이크로시스템즈에 2,000만 달러를 지급하고 자바 지원을 중단하게 된다.

하지만 어찌되었건 자바가 오늘날 광범위하게 쓰이는 것과 별개로 브라우저와의 연동에서 확실히 자리를 잡지는 못했다. 넷스케이프는 자사 브라우저에 사용할 언어를 새로 만들었는데, 1995년에 등장한 자바스크립트다. 자바스크립트는 당시 유행하던 자바의 이름을 마케팅 용도로 땄지만 자바와는 큰 관련이 없다. 두 언어 모두 가상 머신을 구현해 사용하지만, 자바 소스 코드는 만들어진 곳에서 컴파일되어서 그 결과로 생성된 오브젝트 코드가 브라우저로 보내져 해석된다. 즉, 원래 자바 소스 코드는 어떻게 생겼는지 알 수가 없다. 반면 자바스크립트는 소스 코드가 브라우저로 보내지고 브라우저에서 컴파일한다. 따라서 클라이언트는 실행 중인 소스 코드를 볼 수 있으며, 이를 실행할 수 있을 뿐 아니라 연구해서 다른 용도에 맞춰 수정할 수도 있다.

다른 프로그래밍 언어와 콘텐츠도 브라우저 자체 코드 또는 어도비 플래시(Adobe Flash)와 같은 플러그인(plug-in)을 통해 처리된다. 플러그인은 필요할 때 브라우저에 동적으로 로드되는 프로그램으로, 일반적으로 서드 파티(third party, 외부 개발업체)에서 개발한다. 어떤 웹페이지에 방문했을 때 브라우저가 직접 처리할 수 없는 포맷의 콘텐츠가 있으면 '플러그인을 설치할지' 선택할 수 있는데, 이 말은 브라우저에서 실행할 새 프로그램을 다운받는 것을 의미한다.

플러그인은 설치되면 기본적으로 하고자 하는 무슨 일이든 할 수 있으므로, 플러그인 제공자를 신뢰하거나, 플러그인 설치를 포기하고 콘텐츠 이용도 포기해야 한다. 플러그인은 컴파일된 코드이기 때문ㅇ에 브라우저에서 제공하는 API를 사용해 사실상 브라우저의 일부가 되어 실행된다. 플래시는 비디오와 애니메이션용으로 널리 사용되며, 어도비 리더는 PDF 문서를 읽기 위한 플러그인이다. 플래시에는 중대한 보안 취약점 문제가 있었고, 2021년에는 대부분의 주요 브라우저에서 퇴출되었다. 오늘날엔 플러그인보다는 애드온, 즉 확장 프로그램(extension)이 주로 사용되는데 이 때문에 플러그인 대신 확장 프로그램에서 보안 문제가 보다 자주 발생하게 되었다.

플래시는 권한이 너무 많았다. 외부 코드 실행, 마우스 이벤트 조작, 파일 접근 권한이 있어 악성 코드 삽입, 해킹, 크래시 등 보안 문제가 끊이지 않았다. Adobe에서는 수많은 보안 패치들로 대응하려 했으나 플래시는 근본적으로 안전하지 않은 구조임을 인정할 수 밖에 없었다.

이런 상황에서, 모바일 환경이 발전했는데 플래시는 CPU를 많이 쓰고 배터리 소모가 심했기에 모바일에서는 적합하지 않았다. 심지어 2010년 등장한 iPhone은 플래시를 아예 지원하지 않았고, 스티브 잡스는 플래시가 모바일에 부적합하므로 HTML5를 밀겠다고 공식적으로 발표했는데 이 일로 플래시는 몰락하게 된다. 또, HTML5, CSS3, JS가 급성장하며 과거에는 플래시가 아니면 할 수 없었던 동영상, 애니메이션을 표준만으로도 만들 수 있게 되었다. 즉, 추가 플러그인 없이도 모든 브라우저와 모바일에서 동일하게 동작할 수 있으니 플래시라는 플러그인을 추가로 설치할 필요가 없어졌다.

브라우저는 전문화된 운영체제와 비슷해, 사용자들의 웹 브라우징 경험을 향상하기 위해 보다 복잡한 콘텐츠를 처리하도록 확장될 수 있다. 이 덕에 브라우저에서 실행되는 프로그램으로 보다 많은 것을 할 수 있지만, 브라우저에서 제3자가 작성한 확장 프로그램을 실행하는데 이는 늘 위험을 내포하고 있다.

77. 이메일 첨부파일을 함부로 클릭하면 안 되는 이유

액티브 콘텐츠는 이메일에서도 나타날 수 있다. 메일이 도착하면 메일 처리 프로그램이 내용을 표시하는데, 이때 텍스트를 표시하는 것은 당연하지만 다른 종류의 콘텐츠가 함께 들어있다면 어디까지 처리해야하는지의 문제가 발생한다.

예를 들어, 이미지를 표시하는 것은 보통은 문제가 없겠지만 메일 발신자가 메시지나 수신자에 대한 정보를 인코딩한 URL을 포함하고 있는 1*1 투명 픽셀 이미지(web beacon, 웹 비콘)를 포함한다면 이를 막을 방법은 없다.

예를 들어, 메일 본문에 아래의 이미지가 삽입되어 있다고 가정하자.

html
<img src="https://tracker.example.com/open.gif?user=abc123&email_id=456" width="1" height="1" />

사용자가 이메일을 열면,

  1. 브라우저/메일 앱이 이미지를 자동으로 요청(GET 요청)
  2. 해당 요청은 위의 트래킹 서버로 전송됨
  3. 서버는 해당 이메일이 열렸는지, 언제 열렸는지, 어떤 IP 주소/브라우저/위치에서 열렸는지, 몇 번 열었는지

등의 정보를 기록할 수 있다. 사용자 입장에선 메일을 연 것 외에 아무것도 클릭하지도 않았는데 추적이 되는 것이다.

메일 메시지에 자바스크립트가 포함되어 있으면 메일 프로그램은 그것을 실행해야 할까? PDF 파일은 자바스크립트 코드를 포함할 수 있는데, 메일 프로그램에서 PDF를 실행해도 될까? 이메일의 문서를 클릭하거나 함부로 여는 것은 바이러스 전파로 이어지기 쉽다.

78. 바이러스 전파

바이러스와 웜(worm) 두 용어는 모두 한 시스템에서 다른 시스템으로 전파되는 (보통은 악성) 코드를 의미한다. 바이러스는 스스로 전파될 능력이 없어서 사용자가 어떤 행동을 해야만 활성화되어 다른 시스템에 도달하는 반면, 웜은 사용자의 도움 없이도 전파될 수 있다.

웜의 첫 사례는 1988년 11월 코넬 대학 컴퓨터과학과 대학원생 Robert T.Morris가 만들었다. 모리스는 인터넷에 얼마나 많은 컴퓨터가 연결되어 있는지 측정하기 위한 실험의 일환으로 프로그램을 만들었는데, 이 프로그램은 스스로를 한 시스템에서 다른 시스템으로 복사(자기 복제)하는 방식으로 작동했다.

그런데 (순수히 인터넷 규모를 측정하기 위해서라면) 감염이 이미 된 컴퓨터에서는 복제가 되면 안되었지만 이 웜은 감염 여부와 상관없이 1/7 확률로 무조건 복제하려고 했기 때문에, 한 시스템에서도 중복 감염이 일어났고 다른 컴퓨터에서 넘어온 프로그램에서도 복제가 일어나는 문제가 발생했기 때문에 CPU 사용률이 100%에 가까워져 시스템이 마비되는 일이 발생하였다. 또, 네트워크 부하도 증가해 수천 대의 UNIX 시스템이 다운되고 인터넷을 끊어야만 했다.

이 때문에 모리스는 미국 최초로 컴퓨터 범죄 법률(Computer Fraud and Abuse Act)에 따라 유죄 판결을 받고, 벌금을 내고 사회 봉사 활동을 했다.

모리스는 이후 MIT 전산과 교수가 되었고, ViaWeb, Y Combinator 같이 성공적인 벤처 기업을 창업하기도 했다.

1990년대, 즉 인터넷이 널리 사용되기 전까지는 플로피 디스크가 PC간 데이터를 교환하기 위한 표준매체였다. 따라서 감염된 플로피 디스크가 바이러스가 전파되는 가장 흔한 경로였다.

1991년 마이크로소프트 오피스 프로그램, 특히 워드에 비주얼 베이직이 도입되며 바이러스 전파는 훨씬 쉬워졌다. 워드 대부분의 버전엔 비주얼 베이직 인터프리터가 들어있으며, 워드 문서는 비주얼 베이직 프로그램을 포함했다. 비주얼 베이직을 이용하면, 문서가 열렸을 때 윈도우 운영체제 전체의 통제권을 프로그램이 가져오게 할 수 있었다. 즉, 바이러스를 비주얼 베이직으로 작성해 문서에 넣어두면 피해자가 문서를 열 때 무엇이든 원하는대로 할 수 있었다.

예를 들면, 문서가 열리면 바이러스는 현재 주소록에 있는 모든 이메일 주소에 자신의 복사본을 넣은 메일을 보낼 수 있었다. 메일 수신자가 문서를 열면 바이러스가 새 시스템에 자기 자신을 설치하고, 이 과정이 반복된다. 1990년대 중후반에는 비주얼 베이직 바이러스가 많이 있었다. 당시 워드의 기본 설정은 사용자 동의 없이도 비주얼 베이직 프로그램을 실행하도록 허용했으므로 바이러스는 급속도로 퍼졌다.

트로이 목마(Trojan Horse)는 유익하거나 해롭지 않은 것처럼 생겼지만 실제로는 해로운 일을 하는 프로그램이다. 예를 들면, 시스템 보안 분석을 해준다고 하면서 실제로는 악성코드를 설치한다. 대부분의 트로이 목마는 이메일을 통해 전파되는데, 메일에 워드 파일을 첨부하고 만약 수신자가 워드 파일을 클릭하면 드리덱스(Dridex)라고 불리는 악성코드가 설치된다.

요즘에는 감염된 USB 플래시 드라이브가 바이러스 전파에 이용된다. 윈도우는 CD, DVD 또는 플래시 드라이브가 연결될 때 드라이브에서 프로그램을 자동으로 실행하는 '자동 실행' 기능이 있어, USB를 꽂으면 경고를 띄우거나 할새도 없이 악성 소프트웨어가 설치된다. 이에 대부분의 회사에서는 업무용 컴퓨터에 USB 드라이브를 연결하지 못하게 하지만, 자주 일어나는 감염 경로다. 가끔은 신상품 드라이브에 이미 바이러스가 있는 상태로 출하되기도 한다. 또, 회사의 로고가 붙어 있는 드라이브를 회사 주차장에 두고 드라이브에 '임원연봉.xls' 같이 흥미를 끄는 이름 파일이 있다면 자동 실행 기능의 도움을 받지 않고도 바이러스가 손쉽게 전파될 수도 있다.

79. 곳곳에 도사리는 위험

웹의 보안 위협은 크게 세 개로 나뉜다. 클라이언트 공격, 서버 공격 그리고 전송 중인 정보 공격이다.

클라이언트 공격

클라이언트를 공격하는 방법에는 스팸, 추적, 개인 정보 유출 등이 있다.

추적을 줄이려면 직접 방문한 사이트가 아닌 사이트에서 온 쿠키인 제3자 쿠키(third-party cookie)를 금지하고, 트래커를 비활성화하는 브라우저 애드온을 사용하면 된다. 보호 수준을 최대한으로 설정하면 많은 웹사이트를 제대로 사용할 수 없지만, 브라이언 커니핸은 이 정도 노력은 들일만하다고 생각한다.

스팸 메일은 거의 무료로 보낼 수 있기 때문에 정말 많은 스팸이 오간다. 스팸 메일은 머신러닝의 주요 응용 분야로, 스팸과 아닌 메일들로 구분된 훈련 집합으로 훈련하면 머신러닝 알고리즘은 스팸을 구분한다. 많은 스팸이 해킹된 개인용 컴퓨터에서 전송되며, 이런 컴퓨터는 주로 보안 허점이 존재해서 악성코드(malware) 설치를 허용한 바람에 통제권을 외부 시스템에 뺏긴 경우다.

피싱(phishing) 공격은 도용에 사용할 수 있는 정보를 수신자가 자발적으로 넘겨주도록 설득하는 방법이다. 대부분의 피싱은 교묘하게 합법적인 기관이나 친구인척 하며 웹사이트를 방문하거나 어떤 문서를 읽거나 자격 증명을 확인하도록 요청한다. 요청에 응하면 상대방은 우리의 컴퓨터에 뭔가를 설치하거나 정보를 얻고 공격한다. 타겟에 대한 정보를 아주 많이 파악해서 정확하게 표적 공격을 하는 것을 스피어 피싱(spear phishing)이라고 부르기도 한다.

스파이웨어(spyware)는 컴퓨터에서 실행되면서 사용자에 대한 정보를 다른 곳으로 보내는 프로그램이다. 대부분 악의적인 공격이지만, 가끔은 단순한 상업적 스누핑일 때도 있다. 예를 들면 최신의 운영체제는 설치된 소프트웨어의 업데이트 버전이 있는지 자동으로 확인하는데, 우리가 무슨 소프트웨어를 실행하는지 다른 사람이 알 필요는 없기 때문에 프라이버시 침해로 볼 수도 있다.

공격자가 개인용 컴퓨터에 좀비(zombie)를 설치하기도 한다. 좀비란 인터넷에 연결되어 스팸 메일 전송 같은 행동을 하라는 명령을 받을 때까지 기다리는 프로그램이다. 보통 이런 프로그램은 봇(bot)이라고 불리며, 공통으로 제어되는 봇들의 네트워크를 봇넷(botnet)이라고 한다.

클라이언트 컴퓨터를 해킹한 후 정보가 입력되는 시점에 도용하는 공격도 있다. 파일 시스템에서 정보를 찾거나, 몰래 설치한 키 로거(key logger)로 비밀번호나 기타 데이터 입력 시 캡처하는 방식이다. 키 로거는 클라이언트에서 일어나는 모든 키 입력을 모니터링하는 프로그램으로, 키가 입력될 때 비밀번호를 캡처한다.

랜섬웨어(ransomware)는 금액을 지급하기 전까지 컴퓨터에 있는 콘텐츠를 암호화하고 복호화 비밀번호를 알려주지 않는다. 랜섬웨어를 가장해 겁을 주는 스케어웨어(scareware)도 있다.

브라우저는 규모가 크고 복잡한 프로그램이다보니, 사용자에 대한 공격을 모두 막지는 못한다. 불필요한 정보를 공개하지 않고 다운로드를 임의로 허용하지 않도록 브라우저 환경을 설정해야 한다. 휴대전화에선 개인정보를 내보내는 앱을 설치하는 것이 자주 하는 위험한 행동이다.

서버 공격

서버는 클라이언트의 요청이 아무리 교묘하게 만들어졌더라도 인가되지 않은 정보를 유출하거나 무단 접근을 허용하지 않도록 주의 깊게 프로그래밍되어야 한다. 서버는 크고 복잡한 프로그램을 실행하므로 버그와 환경 설정 오류가 자주 일어나는데, 둘 다 공격자가 악용한다.

서버는 보통 데이터베이스의 지원을 받는데, 데이터베이스는 SQL(Structured Query Language)라는 표준 인터페이스로 접근한다. 서버에 자주 일어나는 공격 중 하나는 SQL 주입(SQL injection)으로, 사용자 접근을 신중하게 제한하지 않으면 공격자가 데이터베이스 구조를 드러내고 인가되지 않은 정보를 추출하며, 심지어 공격자의 코드를 서버에서 실행하기 위한 쿼리를 제출한다. 공격자의 코드가 전체 시스템에 대한 통제권을 획득할 수도 있다.

시스템이 해킹되어 버리면 피해는 무제한이다. 특히 공격자가 최고 수준의 관리자 권한인 '루트' 권한을 획득한다면 더 그렇다. 보안 침해 사고는 아주 흔히 일어나며, 때로는 대규모로 발생한다. 2017년 3월, 미국의 3대 신용보고기관 중 하나인 Equifax에선 수 테라바이트에 달하는, 1억 5천만 명의 개인 식별 정보가 외부로 복사됐다. Equifax는 알려진 취약점에 대비해 시스템을 최신 상태로 유지하지도 않았고, 사고 이후엔 보안 침해 사실을 공개하지 않았고 일부 고위 임원은 사실이 공개되기 전 주식을 매도했다.

서버 공격 중 또 자주 일어나는 것은 Dos(Denial of Service, 서비스 거부)이다. DoS 공격은 순전히 트래픽 용량만으로 사이트를 마비시키는 방법이다. 흔히 봇넷으로 조정된 수많은 해킹된 컴퓨터들이 특정 시간에 특정 사이트로 요청을 보내라는 명령을 받고 조직화된 트래픽 범람을 일으키는데, 이렇게 많은 출처에서 동시에 오는 공격은 특히 DDoS(Distributed Denial of Service, 분산 서비스 거부) 공격이라고 한다.

2020년 2월에 아마존 AWS 클라우드 서비스는 역대 최대였다는 DDoS 공격에 성공적으로 대처했는데, 최대 트래픽 속도가 2.3Tbps였다고 한다.

전송 중인 정보 공격

무선 시스템이 확산되면서 전송 중인 정보에 대한 공격 또한 심각한 문제로 떠올랐다. 개방형 무선 액세스 포인트를 제공하는 곳이라면 어디서든 공격자가 암호화되지 않은 연결을 프로그램으로 스누핑 할 수 있으며, 거의 감지하기 어렵게 사용자를 가장할 수 있다. 예를 들어, 신용카드 데이터 대량 도용 사건 중 하나는 매장에 있는 단말기 간 암호화되지 않은 무선 통신을 엿듣는 방식으로 일어났다. 매장 바깥에 주차한 범인들은 신용카드 정보가 전송될 때 그 정보를 캡처했다고 한다.

HTTPS는 HTTP의 TCP/IP 트래픽을 양방향으로 암호화한다. HTTPS를 사용하면 도청자가 내용을 읽거나 대화 당사자 중 하나로 가장하는 일이 불가능해진다.

중간자 공격은 공격자가 메시지를 가로채서 바꾼 다음, 마치 원래 출처에서 바로 온 것처럼 수신자에게 보내는 공격이다. 국가 방화벽은 중간자 공격의 일종으로, 트래픽을 느리게 하거나 검색 결과를 변경한다.

VPN(Virtual Private Network, 가상 사설망)은 두 컴퓨터 간에 암호화된 통신 경로를 설정하여 정보 흐름을 양방향으로 안전하게 보호한다. 기업에서는 VPN을 통해 직원들이 집에서 일할 수 있게 한다. 개인 사용자는 개방형 와이파이를 제공하는 카페나 다른 장소에서 더 안전하게 작업하기 위해 VPN을 사용한다.

하지만 VPN도 무작정 신뢰해서는 안된다. 2020년 8월에 연결 기록을 남기지 않는다고 주장했던 다수의 무료 VPN 서비스에 보안 침해 사고가 일어났고, 사용자 연결 기록 정보들이 유출되었는데 여기에는 단순히 연결 날짜, 시간, IP 주소 뿐 아니라 암호화되지 않은 비밀번호까지 포함되었다.

Signal, WhatsApp, iMessage 같은 보안 메시징 앱(secure messaging app)은 사용자 간 종단 간 암호화가 적용된 음성, 비디오, 텍스트 통신을 제공한다. 즉, 서비스 제공 업체도 모르고 종단들만 아는 키를 사용해 메시지가 발신지에서 암호화되고 수신지에서 복호화된다는 것이다. 이렇게 되면 이론적으로 아무도 도청하거나 중간자 공격을 가할 수 없다.

Signal은 오픈소스 소프트웨어이며, WhatsApp은 페이스북이, iMessage는 애플이 제공한다. Zoom은 AE-256(256비트 AES화 알고리즘)을 사용해 종단간 암호화를 제공한다고 주장해왔는데, 2020년 미국 연방거래위원회(FTC)에서 제출한 소장에 딸므녀 실제론 내부적으로 암호화 키를 보유했고, AES-128 암호화만 사용했으며 사파리 브라우저의 보안 메커니즘을 우회하는 소프트웨어를 몰래 설치했다고 한다.

80. 웹에서 나를 지키는 3단계 방어책

공격자는 약점 하나만 찾으면 되지만, 방어자는 가능한 모든 공격을 막아야 하기에 방어는 어렵다. 브라이언 커니핸은 아래와 같이 3단계 방어책을 제시한다.

매우 필수적인 방어책

  • 비밀번호를 아무도 추측할 수 없고 컴퓨터로 가능한 많은 조합을 시도해도 빨리 드러나지 않는 것으로 한다. 비밀번호를 자주 바꾸는건 역효과가 있을 수도 있다. 왜냐하면 너무 자주 바꾸면 마지막 숫자를 하나 증가하는것 같은 뻔한 방식으로 바꾸는 일이 많기 때문이다.
  • 은행이나 메일처럼 중요한 사이트에 다른 곳에 쓰는 비밀번호와 같은걸 쓰지 마라. 다른 사이트에 가입할 때 페이스북이나 구글 같은 단일 사이트 계정을 그대로 사용하지 마라. 이는 단일 장애 지점이 될 수 있다.
  • Lastpass 같은 비밀번호 관리 프로그램은 모든 사이트에 대해 안전한 무작위 비밀번호를 생성하여 저장한다. 하나의 주 비밀번호만 기억하면 되지만, 이 비밀번호를 잊거나 비밀번호를 보유한 회사가 해킹당하면 단일 장애 지점이 된다.
  • 가능하다면 이중 인증을 사용하라. 이중 인증은 비밀번호와 함께 사용자가 실제로 소유하고 있는 물리적 장치를 필요로 한다.
  • 낯선 사람이 보낸 첨부 파일이나 예정에 없이 받은 첨부 파일을 열지 마라. 마이크로소프트 오피스 프로그램에서 비주얼 베이직과 매크로를 허용하지 마라. 컴퓨터 뿐 아니라 휴대전화도 물론 마찬가지다.
  • 개방형 와이파이를 제공하는 곳에선 중요한 일을 하지 마라. 즉, 스타벅스에서 은행 업무를 보면 안 된다. 연결이 HTTPS를 사용하는것을 확인하되, HTTPS는 단지 내용만 암호화한다는 사실을 기억해야 한다. 통신 경로에 있는 모든 사람은 발신자와 수신자를 알고 있다.
  • 바이러스 검사 프로그램을 사용하고 최신 상태로 유지하라. 운영체제와 브라우저는 보안 수정 업데이트가 자주 일어나므로 최신 버전을 유지하라.
  • 애플의 Time Machine 같은 서비스를 이용해 자동으로 백업하거나, 정보를 직접 안전한 곳에 정기적으로 백업하라.

신중하고 조심스러운 방어책

  • 제3자 쿠키를 차단하라. 쿠키는 브라우저별로 저장되므로 사용하는 브라우저마다 방어 기능을 따로 설정해야 하며 쿠키를 활성화 하는 방법도 브라우저마다 다르지만, 그만한 가치가 있다.
  • 애드블록 플러스 같은 애드온을 사용해 광고, 추적, 그리고 그로 인해 활성화될 수 있는 잠재적 악성 코드를 차단하라. 고스터리를 사용해 자바스크립트 추적을 최대한 제거하라. 광고주들은 광고 차단 프로그램 사용자들이 대가 없이 사이트 정보를 이용하려 하기에 평등하지 않다고 주장하지만, 광고는 악성 코드를 전달하는 주요 매개체 중 하나다. 따라서 광고는 비활성화하는 것이 낫다.
  • 브라우저를 비공개 브라우징 또는 익명 모드로 설정하고, 각 세션이 끝날 때 쿠키를 삭제하라. 메일 프로그램에서 HTML과 자바스크립트를 비활성화하라.
  • 사용하지 않는 다른 운영체제 서비스를 꺼라. 예를 들어, 맥에서는 프린터, 파일, 장치를 공유하고 다른 컴퓨터에서 로그인해서 컴퓨터를 원격으로 관리할 수 있도록 허용하는 기능을 제공한다. 윈도우즈에도 비슷한 기능이 있다.
  • 방화벽(firewall)은 들어오고 나가는 네트워크 연결을 모니터링하고 접근 규칙을 위반하는 연결을 차단하는 프로그램이다. 방화벽을 켜라.
  • 비밀번호를 사용해 노트북과 휴대전화를 잠가라.

보안에 집착하는 방어책

  • 브라우저에서는 노스크립트를 사용하라.
  • 화이트리스트(허용 목록)에 직접 입력한 사이트를 제외한 모든 사이트의 쿠키를 차단하라.
  • 사이트에 임시로 회원 가입할 때는 가짜 이메일 주소를 사용하라.
  • 휴대전화를 사용하지 않을때는 휴대전화를 꺼라. 휴대전화를 암호화하라. 노트북도 암호화하라.
  • 익명으로 웹 브라우징하기 위해 Tor 브라우저를 사용하라.
  • 암호화된 통신을 위해 시그널, 왓츠앱, 아이메시지를 사용하라.

휴대전화는 갈수록 더 많은 공격자들의 대상이 되고 있다. 특히, 다운로드하는 앱과 콘텐츠를 주의해야 한다.

사물인터넷에도 비슷한 문제가 있지만, 사용자 입장에선 사물인터넷 기기에 대한 통제권이 별로 없기 때문에 예방책을 마련하기 더 어렵다.

81. 요약

웹은 1990년대에 등장해 오늘날에는 우리 삶의 필수적인 부분이 되었다. 웹은 각종 비즈니스를 변화시켰고, 우리 행동도 바꿨고, 심지어 배우자를 찾는 방법에까지 영향을 미쳤다. 웹은 우리가 세상을 알아가는 방식과 새로운 소식을 접하는 경로를 결정해, 사용자는 이제 인터넷 정보 제공자가 사용자에 맞추어 제공하는 필터링한 정보만 본다. 이를 Filter Bubble이라고 한다.

웹은 무수한 기회와 혜택을 제공하지만, 동시에 여러 문제와 위험을 낳았다. 우리는 한 번도 만난적 없는, 멀리 살고 있는 사람들에게도 노출되고 그들의 공격을 받는다.

웹은 관할권 문제도 제기한다. 예를 들어, 미국의 많은 주에선 주 경계 내에서 상품을 구매할 때 판매세를 부과하지만, 온라인 매장은 판매세를 징수하지 않는다. 구매자는 주 외부 구매를 신고하고 세금을 내야하지만, 아무도 그렇게 하지 않는다.

이외에도 명예 훼손 문제, 특정 활동의 합법성 문제(포르노, 온라인 도박, 정부 비판 등), 인터넷 실명제를 둘러싼 논의들(자유를 허용할 것인가, 타인을 괴롭히는 일을 막을 것인가) 등은 아직도 해결되지 않은 문제다.

🤠 개인 탐구

Origin과 CORS

CORS(Cross-Origin Resource Sharing)는 웹 개발을 하다보면 정말 자주 콘솔 창에서 마주친다. CORS는 웹의 보안 정책 중 하나로, 브라우저가 다른 출처(origin)의 리소스에 접근하는 것을 제어한다. CORS는 프로토콜은 아니고, HTTP 표준에 추가된 클라이언트를 보호하기 위한 보안 정책 중 하나로 브라우저에서 동작한다.

여기서 다른 출처, 즉 다른 origin의 리소스에 접근하는 것을 막는다고 했을때 origin이 같은지, 다른지는 어떻게 판단할까? Origin은 protocol, domain, port 이 3가지가 모두 같아야 같다고 판단한다. 예를 들면, 아래는 모두 같은 origin이 아니다.

www가 없이도 대부분의 웹 사이트가 접속되기 때문에 www가 중요한지 생각할 수 있는데, 이것은 대부분 DNS 설정에서 www.example.com은 example.com으로 자동 리다이렉트 되게 구성했기 때문에 생기는 일이지 실제로는 다르다.

초창기 인터넷 때, 파일 전송은 ftp, 메일 서버는 mail과 같은 기술적 하위 도메인도 쓰였기 때문에 웹 서비스라는 하위 도메인을 표시하기 위해 www를 붙이는 것은 정석이었다. 즉, example.com이 한 회사 전체의 도메인이었으면, www.example.com은 그 중 웹 서비스 담당이라는 하위 도메인 구분일 뿐이었다. 하지만 요즘은 선택사항이고, 사람들은 이걸 생략하는게 더 '모던'하다고 느끼는 경향이 있다.

CORS는 어떻게 작동할까? 클라이언트에서 bank.com 이라는 사이트에 접속한 이력이 있어 쿠키가 있다고 하자. 이 때, 실수로 evil.com 이라는 사이트에 들어갔는데 여기서 JS로 fetch("bank.com/account")를 요청한다면, 브라우저는 쿠키를 포함해 요청을 보낼 것이다. 서버는 이 요청을 받아 응답을 할 텐데, 이 때 서버의 응답에 Access-Control-Allow-Origin : https://bank.com과 같은 헤더가 존재하고, 이 헤더의 웹사이트 주소가 origin과 일치해야만 브라우저가 응답을 처리한다. 즉, evil.com 은 다른 origin에서 보낸 리소스 요청이기 때문에 브라우저가 처리하지 않고, 사용자의 계좌 정보 노출을 막을 수 있다.

CORS는 다른 origin에서 자바스크립트를 통해 리소스를 요청할 때만 적용된다. 즉, 주소창에 URL을 직접 입력하거나 <a href>로 페이지를 여는건 CORS 대상이 아니다. 브라우저에서 자바스크립트가 실행되어 "다른 origin"으로 fetch/ajax 요청을 보낼 때만 CORS가 동작한다.

요컨대, CORS는 웹에서 허용되지 않은 출처에서 자바스크립트를 통해 리소스를 요청하는 걸 막기 위한 장치이지, 페이지 접속 자체를 제한하는 수단은 아니다. 또, 서버를 보호하기 위한 정책이 아니라 클라이언트의 정보가 새나가는 것을 방지하기 위한 정책이다.

Previous인터넷
IT
Next데이터
IT