세션 고정(Session Fixation)
**세션 고정(Session Fixation)**은 웹 애플리케이션에서 공격자가 미리 설정한 세션 ID를 사용자가 로그인할 때 그대로 사용하게 함으로써 세션을 가로채는 세션 하이재킹 공격입니다. 공격자는 피해자가 자신이 지정한 세션 ID로 로그인하도록 유도한 뒤, 동일한 세션 ID로 접근해 피해자의 권한을 얻고, 민감한 정보를 탈취하거나 시스템에 접근하는 방식입니다.
세션 고정 공격의 과정
- 공격자가 세션 ID 설정: 공격자는 애플리케이션에서 미리 발급받거나 임의로 생성한 세션 ID를 확보합니다.
- 세션 ID를 피해자에게 전달: 공격자는 이메일, 링크, URL 등에 세션 ID를 포함시켜 피해자가 이를 통해 로그인하도록 유도합니다.
- URL을 통한 전달: 공격자는 세션 ID가 포함된 URL을 피해자에게 전달합니다.
- 쿠키 설정: 쿠키를 통해 피해자의 브라우저에 세션 ID를 미리 삽입하는 방식입니다.
- 피해자가 세션 ID로 로그인: 피해자가 해당 세션 ID로 로그인하면, 공격자가 설정한 세션 ID가 로그인된 상태로 권한을 획득합니다.
- 공격자가 세션 탈취: 공격자는 동일한 세션 ID를 통해 피해자와 동일한 권한으로 시스템에 접근하게 됩니다.
세션 고정 공격의 방지 방법
- 로그인 후 세션 ID 재발급: 사용자가 로그인에 성공하면 기존 세션 ID를 폐기하고 새로운 세션 ID를 발급함으로써, 공격자가 기존 세션 ID로 접근하지 못하도록 합니다.
- 세션 타임아웃 설정: 세션 유효 시간을 짧게 설정하여, 오랫동안 사용하지 않은 세션 ID는 자동으로 만료되도록 합니다.
- IP 주소와 사용자 에이전트 확인: 세션이 시작된 IP 주소와 브라우저 정보(사용자 에이전트)를 확인하여 동일한 조건에서만 세션을 유지하도록 합니다.
- HTTPS 사용: HTTPS로 통신을 암호화하여 네트워크 상에서 세션 ID가 탈취되는 가능성을 낮춥니다.
세션 고정 공격은 공격자가 사용자의 신원을 가장하여 시스템에 접근할 수 있는 보안상의 큰 위험이기 때문에, 로그인 시 세션 ID를 재발급하고 타임아웃 설정을 통해 세션 보안을 강화하는 것이 중요합니다.
XSS(교차 사이트 스크립팅, Cross-Site Scripting)
**XSS(교차 사이트 스크립팅, Cross-Site Scripting)**은 공격자가 웹 사이트에 악성 스크립트를 삽입하여, 해당 사이트를 방문하는 사용자에게 악성 스크립트를 실행하도록 유도하는 웹 보안 취약점입니다. XSS 공격은 사용자 브라우저에서 실행되기 때문에, 사용자가 사이트 내에서 수행하는 작업을 공격자가 조작하거나 사용자의 민감 정보를 탈취할 수 있습니다.
XSS의 주요 유형
- 반사형 XSS(Reflected XSS):
- 공격자가 악성 스크립트를 포함한 URL을 생성하고 이를 사용자에게 전달합니다.
- 사용자가 이 URL을 클릭하면, 서버에서 해당 스크립트를 반사하여 브라우저에 표시합니다.
- 예를 들어, 검색 페이지에서 URL에 포함된 스크립트가 사용자 브라우저에서 그대로 실행되어 악성 행위를 합니다.
- 저장형 XSS(Stored XSS):
- 공격자가 악성 스크립트를 웹 애플리케이션의 데이터베이스에 저장합니다.
- 예를 들어, 공격자가 게시물 작성란에 악성 스크립트를 작성하면, 이를 보는 모든 사용자에게 악성 스크립트가 실행됩니다.
- 이 방식은 게시판, 댓글, 사용자 프로필과 같은 지속성이 있는 데이터에 주로 발생하며, 피해 범위가 넓습니다.
- DOM 기반 XSS(DOM-based XSS):
- 클라이언트 측에서 발생하는 XSS로, 웹 페이지의 DOM(Document Object Model)에서 스크립트가 직접 변조되어 실행됩니다.
- 서버가 아닌 클라이언트에서 DOM을 조작할 때, 외부 입력값을 적절히 처리하지 않으면 악성 스크립트가 실행됩니다.
XSS 공격의 피해
- 세션 하이재킹: 사용자의 쿠키나 세션 정보를 탈취하여, 사용자의 인증 세션을 가로챌 수 있습니다.
- 피싱 공격: 사용자에게 신뢰할 수 있는 웹사이트로 보이는 피싱 페이지를 표시하여, 사용자의 비밀번호나 카드 정보를 탈취할 수 있습니다.
- 키로깅(Keylogging): 사용자 브라우저에서 키 입력을 기록하여 중요한 정보를 탈취할 수 있습니다.
XSS 방어 방법
- 입력값 검증 및 필터링:
- 사용자 입력을 받는 모든 부분에서 악성 코드가 삽입되지 않도록, HTML, JavaScript, CSS 등의 태그와 속성을 필터링해야 합니다.
- 출력값 인코딩(Escaping):
- 서버에서 사용자 입력값을 HTML로 출력할 때, HTML 엔티티 인코딩을 적용하여 <, >, & 등과 같은 특수 문자가 스크립트로 실행되지 않도록 합니다.
- HTTPOnly 속성을 사용한 쿠키 보호:
- 쿠키에 HttpOnly 속성을 설정하여, 클라이언트 측 스크립트가 쿠키에 접근하지 못하도록 방지합니다.
- 콘텐츠 보안 정책(Content Security Policy, CSP):
- 브라우저에 특정 스크립트만 실행하도록 제한하는 CSP 헤더를 추가하여, 외부 스크립트나 인라인 스크립트가 실행되지 않도록 설정할 수 있습니다.
- 라이브러리 사용:
- OWASP에서 제공하는 XSS 방지 라이브러리 등 검증된 라이브러리를 활용하여 안전한 입력 검증 및 출력을 적용합니다.
XSS 공격은 사용자가 신뢰하는 웹사이트 내에서 사용자 브라우저에서 스크립트를 실행하기 때문에 위험성이 높습니다. 이를 방지하려면 웹 애플리케이션 개발 시 모든 입력과 출력을 안전하게 처리해야 합니다.
CSRF(사이트 간 요청 위조, Cross-Site Request Forgery)
**CSRF(사이트 간 요청 위조, Cross-Site Request Forgery)**는 사용자가 신뢰하는 웹사이트에 미리 인증된 세션을 통해 의도치 않은 요청을 하도록 유도하는 공격입니다. 공격자는 사용자가 로그인을 유지하고 있다는 점을 이용하여, 사용자가 브라우저에서 특정 요청을 실행하도록 만듭니다. 이때 피해자는 자신이 요청을 보냈다는 사실조차 알지 못한 채 공격자의 의도대로 시스템이 작동하게 됩니다.
CSRF 공격의 동작 방식
- 사용자 로그인: 사용자가 웹사이트에 로그인하면 세션 쿠키를 통해 인증된 상태가 유지됩니다.
- 악성 사이트 방문: 공격자는 악성 웹페이지나 이메일 링크 등을 통해 사용자가 특정 URL을 클릭하거나 폼을 제출하도록 유도합니다. 이때 요청은 사용자가 인증된 세션을 통해 보내집니다.
- 위조 요청 전송: 사용자가 악성 링크를 클릭하거나 페이지에 접근하면, 악성 코드가 실행되어 사용자의 인증 정보로 해당 웹사이트에 요청을 전송합니다.
- 서버 처리: 서버는 요청이 피해자로부터 온 것으로 인식하고, 정상적인 요청으로 처리하여 데이터 변경, 정보 전송, 계정 해지 등의 작업을 수행할 수 있습니다.
CSRF 공격 예시
예를 들어, 사용자가 은행 웹사이트에 로그인한 상태에서 악성 웹페이지를 방문했을 때 다음과 같은 위조된 요청이 실행될 수 있습니다.
- 공격자가 악성 웹페이지에 특정 폼을 숨겨 놓고, 사용자가 페이지에 접근하면 자바스크립트를 통해 자동으로 폼을 제출하도록 설정합니다.
- 사용자가 이를 클릭하면, 사용자의 인증 정보를 활용해 공격자가 설정한 금액과 계좌로 송금 요청이 전송됩니다.
이 과정에서 사용자는 자신이 어떤 요청을 보냈는지 모르기 때문에 큰 피해가 발생할 수 있습니다.
CSRF 방어 방법
- CSRF 토큰 사용:
- CSRF 방어를 위한 가장 효과적인 방법으로, 서버가 각 요청에 대해 CSRF 토큰을 생성하여 폼에 포함시키고, 요청을 받을 때 토큰이 유효한지 확인합니다.
- CSRF 토큰은 요청마다 다르게 생성되며, 요청할 때마다 토큰을 포함해 서버에 전달함으로써 위조된 요청을 방지할 수 있습니다.
- 참조 헤더(Referer Header) 검사:
- 요청 시 HTTP Referer 헤더를 검사하여, 요청이 올바른 출처에서 발생했는지 확인합니다.
- 다만, 일부 브라우저나 프록시 설정에서 Referer 헤더가 누락될 수 있기 때문에, 이 방법만으로는 완벽하지 않을 수 있습니다.
- 쿠키에 SameSite 속성 추가:
- 쿠키의 SameSite 속성을 설정하여, 동일한 사이트에서 발생한 요청에 대해서만 쿠키가 전송되도록 제한할 수 있습니다.
- SameSite 속성은 브라우저가 동일 출처의 요청에만 쿠키를 첨부하도록 하여, 다른 출처에서 요청이 발생했을 경우 쿠키가 포함되지 않도록 합니다.
- 인증 요청에 GET 대신 POST 사용:
- CSRF 공격이 주로 GET 요청을 통해 이루어지기 때문에, 중요한 작업을 수행하는 요청은 POST 방식으로 제한하여 방어할 수 있습니다.
- 사용자 입력 검증:
- 사용자가 예상치 않은 데이터를 전송할 경우, 서버에서 이를 검증하여 악성 요청을 차단할 수 있습니다.
CSRF는 사용자가 로그인된 상태에서 발생하기 때문에, 사용자의 의도와 관계없이 민감한 작업이 실행될 수 있습니다. 이러한 공격을 방지하기 위해서는 CSRF 토큰을 사용하는 방법이 가장 일반적이고 효과적이며, 이를 통해 사용자의 세션이 악용되지 않도록 하는 것이 중요합니다.
Credential(자격 증명)
**Credential(자격 증명)**은 시스템이나 서비스가 사용자 또는 애플리케이션의 신원을 확인하는 데 사용하는 인증 정보를 의미합니다. 이는 주로 사용자가 누구인지 식별하고, 특정 리소스에 접근할 권한이 있는지 인증 및 권한 부여할 때 사용됩니다.
Credential의 예
- 사용자 ID와 비밀번호: 가장 일반적인 자격 증명 방식으로, 사용자가 웹사이트나 애플리케이션에 로그인할 때 사용하는 ID와 비밀번호입니다.
- API 키: 애플리케이션이 다른 애플리케이션(API)에 접근할 때 사용하는 고유한 키입니다. API 키는 해당 애플리케이션이 인증된 사용자임을 증명합니다.
- 액세스 토큰 및 리프레시 토큰: OAuth 같은 프로토콜에서 사용되는 자격 증명입니다. 액세스 토큰은 특정 시간 동안 유효하며, 리프레시 토큰은 액세스 토큰이 만료되면 새로운 토큰을 발급하는 데 사용됩니다.
- 디지털 인증서: 암호화된 파일로, 주로 웹사이트와 같은 서버 인증이나 사용자 신원 확인에 사용됩니다. SSL/TLS 인증서가 대표적인 예입니다.
- 생체 인식 데이터: 지문, 얼굴 인식, 홍채 인식 등은 사용자의 신체적 특징을 기반으로 한 자격 증명 방식입니다.
Credential의 사용 목적
- 인증: 사용자가 시스템에 접근할 때 자격 증명을 통해 사용자가 본인임을 증명합니다.
- 권한 부여: 인증된 사용자에게 특정 권한을 부여해, 필요한 리소스에만 접근할 수 있도록 제한합니다.
- 보안 강화: 중요한 데이터나 시스템에 접근하기 위해 자격 증명을 요구함으로써 보안을 강화합니다.
Credential 보안 관리 방안
- 비밀번호 암호화 저장: 비밀번호와 같은 민감한 자격 증명 정보를 암호화하여 저장해, 탈취되더라도 쉽게 해독되지 않도록 합니다.
- 다중 인증(MFA): 비밀번호 외에 추가적인 인증 요소(예: 2단계 인증)를 사용해 보안을 강화합니다.
- 토큰 기반 인증 사용: 일정 시간 동안만 유효한 토큰을 사용하여 세션 관리를 안전하게 하고, 토큰이 만료되면 자동으로 갱신하도록 합니다.
- 주기적인 자격 증명 갱신: 일정 주기로 비밀번호 변경, API 키 재발급 등을 통해 보안을 유지합니다.
Credential은 사용자의 신원과 권한을 관리하는 중요한 역할을 하며, 자격 증명 정보가 유출되면 큰 보안 위협이 발생할 수 있으므로 철저한 관리와 보안이 필수적입니다.
'Study Memo' 카테고리의 다른 글
2024.11.08(금) { 액츄에이터(Actuator), 그라파나(Grafana), JmsTemplate과 @JmsListener, (0) | 2024.11.08 |
---|---|
2024.10.29(화) { 토큰&세션&JWT, 로그인 요청처리 } (0) | 2024.10.29 |
2024.10.25(금) { 동적 배치 트랜잭션, 커서와 ResultSet, placeholder (0) | 2024.10.25 |
2024.10.21(월) { spring과 node.js, 스프링 MVC와 스프링 부트의 차이, 환경변수는 리눅스에서 나온것 } (0) | 2024.10.21 |
2024.10.16(수) { CDN, MIME 타입, Accept 헤더, Vary 헤더, 아파치&톰캣 차이, addInterceptor } (1) | 2024.10.16 |