🚫인증이 필요한 페이지
- 웹 애플리케이션의 관리 기능이나 개인 정보를 다루는 경우가 대부분
- 공개하면 안되는 페이지를 포함한 경우
- 원칙적으로는 접근하면 안됨
그러나 필요한 경우가 있음
- 뱅크샐러드와 같이 은행과 증권 등 보유하고 있는 금융 계좌를 한 번에 관리하는 서비스
- 자산 총액 확인을 하기위해 은행을 각기 확인하는 것은 번거로움
- 이를 크롤러가 한꺼번에 수집해줌
분산형 미디어
- 직접 미디어 시스템을 가지지 않고 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에서 정의하는 인증 방식
- 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
'Crawling' 카테고리의 다른 글
[크롤링/08]퍼머링크와 데이터베이스 설계 (0) | 2021.03.25 |
---|---|
[크롤링/07] 알고 있으면 유용한 조각 지식-01 (0) | 2021.03.23 |
[크롤링/05]효율적인 크롤링 하는 방법 (0) | 2021.03.22 |
[크롤링/04] HTTP 기본 총 정리 (0) | 2021.03.22 |
[크롤링/03] 라이브러리/프레임워크 (0) | 2021.03.22 |
🚫인증이 필요한 페이지
- 웹 애플리케이션의 관리 기능이나 개인 정보를 다루는 경우가 대부분
- 공개하면 안되는 페이지를 포함한 경우
- 원칙적으로는 접근하면 안됨
그러나 필요한 경우가 있음
- 뱅크샐러드와 같이 은행과 증권 등 보유하고 있는 금융 계좌를 한 번에 관리하는 서비스
- 자산 총액 확인을 하기위해 은행을 각기 확인하는 것은 번거로움
- 이를 크롤러가 한꺼번에 수집해줌
분산형 미디어
- 직접 미디어 시스템을 가지지 않고 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에서 정의하는 인증 방식
- 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
'Crawling' 카테고리의 다른 글
[크롤링/08]퍼머링크와 데이터베이스 설계 (0) | 2021.03.25 |
---|---|
[크롤링/07] 알고 있으면 유용한 조각 지식-01 (0) | 2021.03.23 |
[크롤링/05]효율적인 크롤링 하는 방법 (0) | 2021.03.22 |
[크롤링/04] HTTP 기본 총 정리 (0) | 2021.03.22 |
[크롤링/03] 라이브러리/프레임워크 (0) | 2021.03.22 |