[크롤링/06] 인증이 필요한 페이지

🚫인증이 필요한 페이지

• 웹 애플리케이션의 관리 기능이나 개인 정보를 다루는 경우가 대부분
• 공개하면 안되는 페이지를 포함한 경우
• 원칙적으로는 접근하면 안됨

---

그러나 필요한 경우가 있음

• 뱅크샐러드와 같이 은행과 증권 등 보유하고 있는 금융 계좌를 한 번에 관리하는 서비스
• 자산 총액 확인을 하기위해 은행을 각기 확인하는 것은 번거로움
• 이를 크롤러가 한꺼번에 수집해줌

 

분산형 미디어

• 직접 미디어 시스템을 가지지 않고 Facebook, Twitter, Instagram 등의 소셜 미디어 등의 미디어에 콘텐츠를 제공하는 것
• 동일한 콘텐츠를 페이스북, 트위터 등의 SNS에 올려야 하는 경우에 주로 운용
  • 딩고
• 미리 SNS에 접근할 권한을 확보 한 후 한번에 모든 SNS에 미디어를 업로드하고 사용자의 반응을 추출한 뒤 시각화를 통해 분석해주는 클라우드 서비스도 존재
  • Everypost, Buffer

위와 같은 시스템에는 사용자의 로그인 정보를 저장하고 인증을 통해 리소스를 크롤링하는 크롤러가 있음

하지만 크롤러는 HTML의 구조가 조금이라도 바뀌면 정보를 제대로 추출할 수 없기도 함

따라서 웹 API가 제공되는 경우 이를 적극적으로 사용하는 것이 좋음

 

 

---

지켜야할 것

 

프라이버시

• 다른 사람의 계정 정보를 사용해 정보를 추출할 때는 반드시 계정 소유자의 동의가 필요
• 인증이 필요한 리소스에 접근하는 애플리케이션이라면 어떤 리소스에 접근하는지의 범위도 명확하게 설명해야 함

 

규약 설정

• 계정 소유자인 사용자의 동의를 얻어도 크롤링 대상 사이트의 규약을 위반하는 것이 되기도 함
• 따라서 크롤링은 '사용자의 의사에 따라 하는 것'이라는 것을 규약에 명시해야 함
• 사용자가 자신의 계정 정보를 활용해 직접 리소스에 접근하는 것임을 반드시 명시해야 함
• SNS 등은 회원 가입할 때 회원만 볼 수 있는 정보를 외부에 공개하지 말 것을 규약으로 정해놓기도 함
• SNS에 있는 정보를 공개하는 것은 규약에서 원칙적으로 금지하는 사항

실제로 뱅크 샐러드 이용약관을 살펴보았다.(www.banksalad.com/policies/v3/terms)

데이터를 맛보다 | 뱅크샐러드

이용자의 동의하에 수집(크롤링)하거나 직접 입력한 정보를 확인하는 서비스라고 나와있다

뱅크샐러드 개인정보 처리방침을 읽어보았다.(www.banksalad.com/policies/v12/privacy-policy)

데이터를 맛보다 | 뱅크샐러드

어떤 정보를 수집하는지 상세하게 나와있다.

스크래핑은 이용자가 자신의 정보를 조회하기 위해 하는 것이라고 나와있다

 

 

보안

• 데이터 저장
• HTTP 통신은 암호화되지 않음
  • 통신을 SSL로 암호화
  • 통신 경로가 SSL로 되어 있지 않으면 세션 하이재킹이 발생할 수 있음
• 데이터베이스 관리
  • 정보 암호화 및 분산 저장, 네트워크 세그먼트 분리, 다중 방화벽 등 해킹 피해를 최소화해야 함

 

API 사용하기

• API로 필요한 정보를 추출할 수 있다면 크롤링보다는 웹 API
• API를 사용하면 정보 통신 및 권리 관계와 상관없이 API 사용 규약으로 제공자와 규약을 맺는 것
  • 문제가 발생하는 부분이 줄어듬

 

 

---

HTTP 인증

 

developer.mozilla.org/ko/docs/Web/HTTP/Authentication

HTTP 인증 - HTTP | MDN

 

HTTP 인증이란

• HTTP에서 정의하는 인증 방식
• HTTP는 액세스 제어와 인증을 위한 프레임워크를 제공
• 일반적으로 조직 내부 또는 개발 중인 페이지에서 많이 볼 수 있음

 

종류

• Basic 인증
  • 가장 일반적인 인증 방식
  • 인증 스킴은 RFC 7617에 정의되어 있는데, 이는 base64를 이용하여 인코딩된 사용자 ID/비밀번호 쌍의 인증 정보를 전달

curl -I http://www.example.com/

curl로 basic 인증이 걸려있는 콘텐츠에 접근하면 아래와 같은 응답을 받게된다.

HTTP/1.1 401 Unauthorized /* 상태 코드 */
.
.
(생략)
.
.
WWW-Authenticate: Basic realm="Restricted"

이러한 상태 코드를 받을 경우 Authorization 헤더를 사용해서 ID와 비밀번호를 전송할 수 있다.

crul -H 'Authorization: <type> <credentials>' http://www.example.com

ID와 PS를 URL에 포함해서 요청할 수도 있다.

curl http://id:password@www.example.com

주의할 점은 HTTP는 Stateless Protocol이라 HTTP 인증도 상태를 가지지 않는다. 따라서 페이지를 이동할 때마다 ID와 비밀번호를 요청에 포함시켜야 한다.

 

 

• Digest 인증       MD5    Digestaccessauthentication
  • 도청이나 조작을 막기 위해 비밀번호를 D5 해시로 만들어 전송

 

 

---

입력 양식 기반 인증

 

대부분의 웹 사이트가 로그인 전용 입력 양식을 사용해 인증함

 

• GIthub를 예로들면 로그인 창의 소스 코드를 확인해보면, form 요소의 action 속성과 method 속성을 확인해 보면 /session이라는 경로에 POST 메서드로 데이터를 전송함
  • enctype 속성이 지정되지 않아서 application/x-www-form-urlencoded로 URL 인코딩된 데이터가 요청 바디로 전송될 것임
• 입력 양식에 ID와 PS를 입력하고 로그인 버튼을 눌렀을 때 브라우저와 웹 서버 사이에 이루어지는 통신 확인하기
  • Google Chrome 개발자 도구 Network 탭에서 리다이렉트되는 모든 내용을 확인하기위해 Preserve Log 체크하고 로그인 버튼 누르기

CSRF(Cross-Site Request Forgery)

사이트 간 요청 위조

• 웹 애플리케이션에는 로그인한 상태에서만 조작할 수 있는 기능이 존재
• 이러한 기능을 구현할 때는 웹 서버와 클라이언트의 통신에 POST 요청을 사용하는 경우가 다수
• 공격자가 이러한 구조를 이용하면 웹 애플리케이션에 로그인한 사용자가 악의적인 사이트에 들어갔을 때 중요한 기능을 실행하게 만드는 POST 요청을 전송할 수도 있음
  • 이처럼 웹 애플리케이션이 다른 웹 사이트로부터 요청을 받아 처리할 수 있는 취약성을 사용한 공격이 CSRF
• 이러한 공격을 막기위해 도입한 것이 'authenticity_token'
  • 중요한 입력 양식을 출력할 때는 랜덤한 토큰을 함께 생성
  • 이러한 토큰을 사용자의 브라우저를 구별하는 속성(session_id)과 함께 기록
  • 사용자가 입력 양식 데이터를 전송하면 입력 양식에 들어 있는 토큰이 함께 전송
  • 최종적으로 전송된 토큰과 서버에 기록된 토큰이 일치하는 경우에만 처리를 진행

 

세션 관리

• 입력 양식 기반의 인증은 일반적으로 쿠키를 사용해 같은 사용자가 계속 요청한다는 것을 인지
• 이처럼 같은 사용자가 보내는 요청을 세션이라고 부름
• 쿠키는 HTTP 응답 헤더를 사용해 서버에서 응답을 받을 수 있는 작은 데이터로 키와 값의 조합으로 이루어짐

Set-Cookie: session_id=example

Set-Cookie를 받은 브라우저는 이후의 요청 때 자동으로 헤더에 추가해 서버에 전송한다.

대부분의 웹 프레임워크는 쿠키를 사용한 세션 관리 기능을 가지고 있고, 이를 사용해 요청이 들어오면 사용자를 구분한다.

 

* 세션 하이재킹 시 대처 방법 - HTTPS를 사용하고 쿠키에 secure 속성과 httpOnly 속성 지정하기, 적절한 방법으로 세션 ID 생성하기, 로그인하면 세션 ID 변경하기 등 

 

2단계 인증(비밀번호 + 일회용 토큰)

 

2단계 인증이 필수적인 웹 사이트는 크롤링할 수 없다. 다만, 사용자 인증과 별도로 외부 애플리케이션 연동 전용 OAuth 등을 제공하는 경우 이를 사용하면 가능하다. 

 

이 외의 BOT 대책으로는 CAPTCHA, reCAPTCHA(Google)가 있다.

 

---

 

웹 API를 사용해 정보 추출 하기 

 

• 대부분의 API는 사용자 별 과금과 접속 수를 제한하고, 보안상 중요한 데이터를 다루기 위해 인증을 사용함
• HTTP 인증/ 입력 양식 기반의 인증을 통해 웹 사이트에 접속하려면 크롤러가 사용자 중요 정보를 알고 있어야함
• 웹 API를 사용하면 크롤러가 접근 가능한 정보를 최소한으로 제한할 수 있다는 장점이 있음

접근키로 인증

• 어플리케이션별로 허가를 받는 프로그램에서 주로 사용
• 접근할 프로그램에게 토큰(접근키)을 발행하고 그 토큰을 사용해 요청을 걸게 하는 방법
• 서버측에서는 접근키를 사용해 클라이언트를 식별
  • 접근키는 프로그램에서 작성하지 말고 환경 변수에서 읽게 만들어야 함(비용 손실 방지)
• AWS 등의 클라우드 서비스는 터미널 또는 프로그램에서 리소스를 관리하게 해주는 SLI와 SDK를 제공
  • AWS는 AWS 내부의 EC2 인스턴스로부터의 접근은 접근키를 사용하지 않고 인스턴스 전용 권한을 사용해 접근을 제어 시킴(접근키가 유출될 가능성이 없어짐)

 

OAuth 2.0

• 사용자의 개인 정보에 접근하는 웹 API는 사용자의 개별적인 허가가 있어야함
• 이럴 때 사용자로부터 허가를 받기 위해 널리 사용되는 방법이 OAuth 2.0
• 애플리케이션의 로그인 서비스를 연동할 때 사용(네이버, 카카오 계정을 사용한 로그인 aka 소셜 로그인)
  • 로그인하려는 서버에게 비밀번호를 알려주지 않는다는 특징을 가지고 있음

네이버 D2의 OAuth 1.0, 2.0을 다룬 글> d2.naver.com/helloworld/24942

• 위의 글은 2012년에 쓰여져서 OAuth 2.0이 자세히 다뤄지지 않았고, 정식으로 발표되지 않았던 시점이다.
• OAuth 1.0에서는 API를 요청할 때 반드시 디지털 서명을 해야했고, 웹 애플리케이션만 가정해 설계되었다.
• 그러나 OAuth 2.0은 모바일 애플리케이션, 데스크톱 애플리케이션 등 다양한 환경에서 사용할 것을 가정하고 확장 설계되었다.
• 구글, 트위터 등 다양한 서비스가 모두 OAuth를 지원하고 있고, 현재 재공하는 API는 대부분 2012년에 표준화된 OAuth 2.0을 기반으로 구현되었다. 

생활코딩 OAuth 2.0 강의> opentutorials.org/course/3405

WEB2 - OAuth 2.0 - 생활코딩