로그인 후 달라지는 요소
공개 페이지는 일반적인 HTTP 요청으로 가져올 수 있는 경우가 많습니다. 로그인된 페이지에는 대개 다음과 같은 여러 브라우저 상태가 필요합니다.- 사용자가 이미 인증했음을 증명하는 세션 쿠키
- 양식 제출 및 API 호출 시 사이트에서 요구하는 CSRF 토큰 또는 요청 헤더
- 단일 페이지 애플리케이션에서 사용하는 로컬 스토리지 또는 세션 스토리지 값
- 인증되지 않은 방문자를
/login으로 돌려보내는 리디렉션 로직 - 시간, 비활동, IP 변경 또는 보안 이벤트에 따라 세션을 무효화하는 만료 규칙
접근 방식 1: 실제 세션의 쿠키 재사용
가장 일반적인 접근 방식은 한 번 로그인한 뒤 생성된 쿠키를 저장하고 이후 스크래핑 실행에서 재사용하는 것입니다. 사이트가 세션을 몇 시간 또는 며칠 동안 유지하고 세션을 특정 기기나 IP 주소에 지나치게 강하게 결합하지 않을 때 효과적입니다. 코드에서는 다음과 같은 패턴을 사용합니다.접근 방식 2: 브라우저로 로그인
일부 사이트에는 실제 브라우저 로그인 절차가 필요합니다. 스크래퍼가 로그인 페이지를 열고 양식을 입력한 다음 제출하고 계정 페이지가 나타날 때까지 기다린 뒤, 나중에 실행할 수 있도록 브라우저 상태를 저장합니다.접근 방식 3: 로그인 API 재현
로그인 양식이 인증 엔드포인트에 단순한 POST 요청을 보내는 경우가 있습니다. 절차가 간단하고 사이트 약관에서 허용된다면 HTTP 클라이언트로 해당 요청을 직접 재현하고 반환된 쿠키를 수집한 뒤 사이트 탐색을 계속할 수 있습니다. 인증 절차에는 CSRF 토큰, 봇 검사, 기기 핑거프린팅, 계속 바뀌는 숨겨진 필드가 포함되는 경우가 많아 이 방법은 일반적으로 브라우저 로그인보다 불안정합니다. Network 탭을 검사하면 로그인 요청이 재현할 만큼 단순한지, 아니면 브라우저 세션을 사용하는 편이 안전한지 판단할 수 있습니다.MFA, SSO 및 보안 메시지
다단계 인증은 설계 방식을 바꿉니다. 스크래퍼가 MFA를 우회하려 해서는 안 됩니다. 대신 다음과 같이 설계하세요.- 사람이 로그인 과정에 참여한 다음 인증된 세션을 저장합니다.
- 사이트에서 제공한다면 공식 API나 서비스 계정을 우선적으로 사용합니다.
- 세션 만료를 예상하고 새로 고침 또는 재로그인 워크플로를 구축합니다.
- 무인 프로덕션 작업에는 개인 계정을 사용하지 않습니다.
세션 안전
인증된 스크래핑을 가볍게 다루면 계정이 잠기고 알림이 발생하거나 민감한 데이터가 노출될 수 있습니다. 다음 보호 조치를 적용하세요.- 작업별로 계정을 분리하세요. 같은 로그인 세션에 관련 없는 스크래핑 작업을 혼합하지 마세요.
- 한 세션 안에서 IP와 브라우저 ID를 안정적으로 유지하세요. 세션 도중 프록시를 전환하면 계정 탈취처럼 보일 수 있습니다.
- 작업 속도를 제한하세요. 로그인 영역은 공개 페이지보다 엄격하게 모니터링되는 경우가 많습니다.
- 로그아웃 페이지를 감지하세요. 스크래퍼는 로그인 페이지를 실제 데이터로 파싱하지 않도록 로그인 화면으로 리디렉션된 사실을 인식해야 합니다.
- 비밀 정보를 안전하게 저장하세요. 자격 증명, 쿠키, 스토리지 상태 파일은 모두 민감한 정보입니다.
- 접근 로그를 신중하게 기록하세요. 실패를 진단할 수 있을 만큼 실행 기록을 보존하되 비공개 페이지 콘텐츠나 자격 증명을 로그에 기록하지 마세요.