웹 보안과 인증

임지선·2024년 8월 29일

JWT SQL injection Token XSS cookie cors csrf session sop

컴퓨터 네트워크

목록 보기

4/11

쿠키(Cookie)

쿠키는 사용자의 브라우저에 저장되는 작은 데이터 파일입니다. 웹 개발에서 사용자 정보를 관리하기 위해 자주 사용되는 기술로, 웹 사이트는 쿠키를 사용하여 사용자의 브라우저에 데이터를 저장하고, 이 데이터는 이후에 동일한 웹 사이트를 방문할 때 다시 사용할 수 있습니다.

쿠키 사용 방법

사용자 인증:

사용자가 로그인했을 때 쿠키에 인증 정보를 저장하여, 이후 방문 시에도 자동으로 로그인 상태를 유지할 수 있습니다.

사용자 설정:

웹사이트에서 사용자별로 언어 설정, 테마 설정 등을 기억하게 합니다.

추적:

사용자가 웹사이트를 어떻게 이용하는지 분석하는 데 사용될 수 있습니다.

쿠키 특징

저장 위치:

사용자의 로컬 브라우저에 저장됩니다.

수명:

쿠키는 만료 시간을 설정할 수 있으며, 세션 쿠키(브라우저를 닫으면 삭제되는 쿠키)와 영속 쿠키(설정된 만료 시간까지 유지되는 쿠키)가 있습니다.

보안:

쿠키는 클라이언트 측에 저장되기 때문에, 민감한 정보는 저장하지 않는 것이 좋습니다.

세션(Session)

세션은 서버에서 관리되는 사용자 정보입니다. 웹 개발에서 사용자 정보를 관리하기 위해 자주 사용되는 기술로,
사용자가 웹사이트를 방문하는 동안 서버는 사용자마다 고유한 세션 ID를 생성하고, 이 ID를 통해 사용자의 상태와 정보를 유지합니다.

세션 사용 방법

사용자 상태 관리:

사용자가 로그인한 상태를 서버에서 관리하여, 페이지를 이동하더라도 로그인 상태를 유지할 수 있습니다.

쇼핑 카트:

사용자가 쇼핑 사이트에서 상품을 선택할 때, 선택된 상품 정보를 세션에 저장하여 페이지를 이동해도 유지되도록 합니다.

세션 특징

저장 위치:

서버에 저장되며, 사용자의 브라우저에는 세션 ID만 저장됩니다.

수명:

세션은 일정 시간이 지나면 만료되며, 서버에서 설정할 수 있습니다. 사용자가 브라우저를 닫으면 세션이 종료되기도 합니다.

보안:

민감한 정보를 서버 측에서 관리하기 때문에 쿠키보다 보안이 강화됩니다.

인증

서버 기반 인증

특징

세션은 서버의 메모리 또는 DB에 저장되며, 세션이 많아질 경우 부하 문제가 발생합니다.
세션을 사용하면 서버를 확장하는 것이 어려워지는데, 각 서버의 세션 정보를 동기화 해줘야하기 때문입니다.

토큰 기반 인증

특징

토큰 기반 인증은 stateless 합니다. 즉, 서버 기반 인증처럼 세션을 서버 측에 유지하지 않습니다.
서버가 클라이언트에게 토큰을 발급해주면, 클라이언트는 매 요청시 토큰을 서버에게 보내서 인증 받는 방식입니다.
토큰에는 서버가 개인키로 만든 서명이 담겨 있으며, 서버는 토큰의 서명을 공개키로 검증할 수 있습니다. 즉 토큰 자체로 인증이 가능합니다.
서버 부하 문제가 해결되며, 서버 확장시 문제가 되지 않습니다.

JWT(JSON Web Token)

JWT(JSON Web Token)는 웹 애플리케이션에서 인증 및 권한 부여를 위한 토큰입니다. JWT는 세 가지 주요 부분으로 구성된 문자열로, 인증된 사용자 정보를 안전하게 전송하기 위해 사용됩니다. JWT는 간편하고 확장 가능한 인증 방법으로 널리 사용되며, 특히 RESTful API와 같은 무상태(stateless) 환경, 분산 시스템에서 자주 활용됩니다.

JWT의 구조

JWT는 .(점)으로 구분된 세 가지 부분으로 이루어집니다.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvbmRvZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

토큰의 타입과 해싱 알고리즘 정보를 포함합니다.

Payload(페이로드):

사용자와 관련된 클레임(claims)이라는 정보를 담고 있습니다. 클레임은 인증된 사용자에 대한 데이터로, 예를 들어 사용자 ID, 사용자 역할(role), 만료 시간(exp) 등을 포함할 수 있습니다.

Signature(서명):

헤더와 페이로드를 조합하고, 비밀 키를 사용하여 생성된 서명입니다. 서명은 토큰의 무결성을 보장하고, 토큰이 변조되지 않았음을 확인하는 데 사용됩니다.

JWT의 작동 방식

사용자 인증:

사용자가 로그인하면, 서버는 사용자의 정보를 바탕으로 JWT를 생성합니다.

토큰 전달:

생성된 JWT는 클라이언트(브라우저나 모바일 앱)로 전달됩니다.

토큰 저장:

클라이언트는 JWT를 로컬 스토리지나 쿠키에 저장합니다.

API 요청 시 JWT 사용:

클라이언트는 서버에 API 요청을 보낼 때 JWT를 함께 전송합니다.

(보통 HTTP 헤더에 Authorization: Bearer <JWT> 형태로 전달)

서버에서 검증:

서버는 JWT의 서명을 확인하고, 페이로드 정보를 바탕으로 사용자의 권한을 검사한 후 요청을 처리합니다.

JWT의 장점

무상태:

서버가 세션 상태를 유지할 필요가 없으므로, 확장성이 뛰어납니다.

간편한 전송:

Base64Url로 인코딩된 문자열이므로, URL, 헤더, 또는 쿠키에서 쉽게 전달할 수 있습니다.

보안성:

서명을 통해 데이터의 무결성을 보장하며, 정보가 변조되지 않았음을 확인할 수 있습니다.

JWT의 주의점

토큰 크기:

JWT는 페이로드에 많은 정보를 담을 수 있으나, 크기가 커질수록 네트워크 성능에 영향을 줄 수 있습니다.

만료 시간:

JWT는 보통 한 번 발행되면 수정할 수 없으므로, 만료 시간을 신중하게 설정해야 합니다. 만료된 JWT는 재사용할 수 없도록 해야 합니다.

보안 관리:

JWT는 클라이언트 측에 저장되므로, 비밀 키는 안전하게 관리되어야 하며, 민감한 정보는 페이로드에 포함하지 않는 것이 좋습니다.

SOP (Same-Origin Policy)

SOP는 웹 보안 모델에서 중요한 규칙으로, 서로 다른 출처(origin)에 속하는 리소스 간의 상호작용을 제한하는 역할을 합니다. 이 정책은 악의적인 웹사이트가 다른 웹사이트의 데이터를 무단으로 접근하거나 조작하지 못하도록 방지합니다. 단 이때 예외가 있는데, HTML 태그입니다. 이때 태그들은 다른 출처에서 리소스를 로드할 수 있지만, 이 태그를 통해 로드된 콘텐츠는 원본 출처와 상호작용할 수 없습니다.
<img>, <script>, <link>

출처의 정의

프로토콜:

예를 들어, http:// 와 https:// 는 서로 다른 출처로 간주됩니다.

호스트:

예를 들어, example.com 과 sub.example.com 은 서로 다른 출처로 간주됩니다.

포트:

예를 들어, http://example.com:80 과 http://example.com:8080 은 서로 다른 출처로 간주됩니다.

SOP의 역할

데이터 보호:

한 출처에서 로드된 스크립트가 다른 출처에서 로드된 데이터를 읽거나 쓰지 못하게 하여, 사용자의 데이터를 보호합니다.

안전한 실행 환경:

악성 코드나 공격자가 다른 도메인의 민감한 정보에 접근하지 못하게 함으로써, 웹 애플리케이션의 보안을 강화합니다.

CORS는 SOP의 제한을 완화하기 위한 메커니즘으로, 특정 조건하에 다른 출처에서 리소스에 접근할 수 있도록 허용하는 표준입니다.
CORS를 통해 서버는 어떤 출처에서 자신의 리소스에 접근할 수 있는지 브라우저에 명시적으로 알려줄 수 있습니다.

작동 방식

프리플라이트 요청(Preflight Request):

일부 민감한 요청(GET 외의 메서드나 커스텀 헤더가 있는 요청 등)은 본 요청 전에 브라우저가 OPTIONS 메서드를 사용해 서버에 요청을 보내어 허용 여부를 확인합니다.

응답 헤더:

서버는 특정 HTTP 응답 헤더를 사용해 어떤 출처(origin), 메서드(method), 헤더(header)가 허용되는지 브라우저에 알려줍니다.

Access-Control-Allow-Origin:

허용된 출처를 지정합니다. 예: *(모든 출처 허용) 또는 특정 도메인(https://example.com).

Access-Control-Allow-Methods:

허용된 HTTP 메서드를 지정합니다. 예: GET, POST, PUT.

Access-Control-Allow-Headers:

클라이언트가 요청에 사용할 수 있는 커스텀 헤더를 지정합니다.

Access-Control-Allow-Credentials:

자격 증명(예: 쿠키, 인증 헤더)이 포함된 요청을 허용할지 여부를 지정합니다.

CORS의 역할

유연한 리소스 공유:

서버 관리자가 신뢰할 수 있는 도메인에만 접근을 허용하도록 설정할 수 있어, 보안을 유지하면서 리소스 공유를 유연하게 처리할 수 있습니다.

보안 강화:

적절한 CORS 설정을 통해 의도하지 않은 도메인 간 데이터 공유를 방지할 수 있습니다.

XSS 공격

XSS(Cross-Site Scripting, 크로스 사이트 스크립팅) 공격은 웹 애플리케이션의 취약점을 이용해 악성 스크립트를 삽입하여, 사용자의 브라우저에서 실행되도록 하는 공격 기법입니다. 공격자가 삽입한 스크립트는 피해자의 브라우저에서 실행되며, 이를 통해 쿠키, 세션 토큰, 사용자 입력 등 민감한 정보를 탈취하거나, 웹 페이지의 콘텐츠를 조작하는 등의 악의적인 행위를 수행할 수 있습니다.

XSS 공격의 유형

Stored XSS (저장형 XSS):

공격자가 악성 스크립트를 서버에 영구적으로 저장해 두고, 다른 사용자가 해당 콘텐츠를 요청할 때마다 스크립트가 실행되는 형태입니다. 예를 들어, 게시판에 글을 올리거나, 프로필 정보를 업데이트할 때 악성 스크립트를 포함시키는 방식입니다.

Reflected XSS (반사형 XSS):

공격자가 악성 스크립트를 특정 URL에 포함시켜, 피해자가 그 URL을 클릭하면 스크립트가 실행되는 형태입니다. 주로 피싱 사이트나 이메일을 통해 악성 링크를 전송하여 공격합니다.

DOM-based XSS (DOM 기반 XSS):

웹 페이지의 클라이언트 측에서 JavaScript가 DOM(Document Object Model)을 조작할 때 발생하는 공격입니다. 서버로부터 전달된 응답이 아니라, 클라이언트 측 코드의 취약점을 이용해 스크립트를 삽입하고 실행시킵니다.

XSS 공격의 결과

쿠키 탈취:

공격자가 사용자의 세션 쿠키를 훔쳐서, 그 사용자로 가장할 수 있습니다.

페이지 조작:

악성 스크립트를 통해 웹 페이지의 내용을 변경하여 사용자에게 잘못된 정보를 제공할 수 있습니다.

피싱:

사용자로 하여금 가짜 로그인 페이지나 악성 링크를 클릭하게 유도할 수 있습니다.

기타 악의적 행위:

사용자의 브라우저에서 임의의 코드가 실행되도록 하여, 추가적인 악성 행위를 수행할 수 있습니다.

XSS 공격 방어 방법

XSS 공격을 방어하기 위해서는 다양한 방법을 조합하여 적용하는 것이 중요합니다.

입력 값 검증(Input Validation):

사용자가 입력하는 모든 데이터를 검증하고, 허용된 문자나 패턴만 허용하도록 합니다. 예를 들어, 이메일 입력 필드에는 이메일 주소 형식만 허용하고, 스크립트 태그와 같은 위험한 문자열은 거부합니다.

출력 값 인코딩(Output Encoding):

사용자 입력을 웹 페이지에 출력할 때, HTML 엔티티로 인코딩하여 브라우저가 이를 코드로 해석하지 않고 단순한 텍스트로 처리하게 합니다. 예를 들어, <는 <, >는 >로 인코딩합니다.

콘텐츠 보안 정책(CSP, Content Security Policy):

CSP 헤더를 사용하여 브라우저가 허용된 출처에서만 스크립트를 로드하고 실행하도록 제한할 수 있습니다. 이를 통해 외부에서 임의로 삽입된 스크립트의 실행을 차단할 수 있습니다.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com;

HTTPOnly 및 Secure 플래그 설정:

쿠키에 HTTPOnly 플래그를 설정하여 JavaScript에서 쿠키에 접근할 수 없도록 하고, Secure 플래그를 설정하여 HTTPS를 통해서만 쿠키가 전송되도록 합니다. 이를 통해 쿠키 탈취를 방지할 수 있습니다.

DOM 요소 접근 제한:

JavaScript에서 DOM을 직접 조작할 때, 사용자의 입력을 그대로 사용하지 않도록 주의해야 합니다. 신뢰할 수 없는 데이터를 직접 DOM에 삽입하는 것은 피해야 합니다.

라이브러리 및 프레임워크 업데이트:

사용하는 웹 프레임워크와 라이브러리를 최신 버전으로 유지하여, 알려진 XSS 취약점이 있는 구버전 사용을 방지합니다.

입력 필터링 및 화이트리스트 사용:

사용자의 입력에 대한 필터링을 강화하고, 가능한 경우 허용된 입력만 받도록 화이트리스트를 사용합니다.

CSRF 공격

CSRF(Cross-Site Request Forgery) 공격은 사용자가 의도하지 않은 요청을 공격자가 악용할 수 있는 웹 보안 취약점입니다. 이 공격은 주로 사용자의 웹 브라우저에 저장된 인증 정보(쿠키 등)를 악용하여 공격자가 피해자의 계정으로 요청을 보내는 방식으로 이루어집니다.

CSRF 공격의 동작 방식

사용자가 로그인한 상태에서 웹사이트를 방문합니다.
공격자는 피해자의 브라우저에서 요청을 강제로 발생시킬 수 있는 웹 페이지를 만들거나, 악성 코드를 삽입한 이메일 링크 등을 통해 피해자에게 전달합니다.
피해자가 공격자의 웹 페이지를 열면, 공격자의 웹 페이지에서 피해자가 로그인한 웹사이트에 자동으로 요청을 보내는 스크립트를 실행합니다.
이 요청은 피해자의 브라우저에서 발생하며, 로그인된 상태이기 때문에 웹사이트는 이를 정상적인 요청으로 처리할 수 있습니다.

CSRF 방어 방법

CSRF 토큰 사용

서버는 사용자가 요청을 보낼 때마다 고유한 CSRF 토큰을 생성하여 폼이나 AJAX 요청에 포함시킵니다.
서버는 요청을 처리할 때 해당 토큰의 유효성을 검사하여, 요청이 정상적인지 확인합니다.
이 토큰은 일반적으로 세션에 저장되며, 각 요청마다 새로 생성됩니다.

Referer 헤더 확인

서버는 요청의 Referer 헤더를 확인하여 요청이 적절한 출처에서 왔는지 검증합니다.
하지만 Referer 헤더는 사용자가 브라우저 설정이나 프라이버시 도구에 의해 차단될 수 있기 때문에, 이 방법만으로는 완벽한 방어가 어렵습니다.

SameSite 쿠키 속성 설정

쿠키의 SameSite 속성을 Strict 또는 Lax로 설정하면, 다른 사이트에서 이 쿠키를 포함한 요청을 보낼 수 없게 됩니다.
이 속성은 CSRF 공격을 예방하는 데 매우 효과적입니다.

시맨틱적 검증

중요한 요청을 처리할 때, 사용자에게 추가적인 확인 절차를 요구하거나 비밀번호를 다시 입력받는 방법도 사용할 수 있습니다.

사용자 행동 모니터링

비정상적인 요청 패턴을 감지하고, 이를 기반으로 추가적인 검증을 수행하는 방법도 고려할 수 있습니다.

SQL Injection 공격

SQL Injection(또는 SQLi) 공격은 악의적인 사용자가 웹 애플리케이션의 SQL 쿼리에 악성 코드를 삽입하여 데이터베이스를 조작하거나 정보를 탈취하는 공격입니다. 이 공격은 애플리케이션이 사용자 입력을 적절히 필터링하지 않을 때 발생합니다.

SQL Injection 공격의 동작 방식

사용자가 입력 필드나 URL 파라미터에 SQL 코드 조작을 포함한 데이터를 삽입합니다.
애플리케이션은 이 입력을 직접 SQL 쿼리로 전달하여 데이터베이스와 상호작용합니다.
데이터베이스는 악성 SQL 코드를 실행하여 공격자가 의도한 대로 데이터를 조회하거나 수정합니다.

SQL Injection 방어 방법

준비된 문장(Prepared Statements) 사용

SQL 쿼리에서 사용자 입력을 변수로 취급하여 SQL 코드와 데이터가 분리되도록 합니다.
예를 들어, 자바의 경우 JDBC에서 준비된 문장을 사용할 수 있습니다.

ORM(Object-Relational Mapping) 사용

Hibernate, Entity Framework 등 ORM 도구를 사용하면 SQL 쿼리를 자동으로 생성하고, 사용자 입력을 안전하게 처리할 수 있습니다.

입력 데이터 검증 및 정제

사용자 입력을 수신할 때, 예상되는 형식이나 범위에 맞는지 검증합니다.
특수 문자나 불필요한 문자열이 포함되지 않도록 필터링하거나 이스케이프 처리를 합니다.

최소 권한 원칙 적용

데이터베이스 계정에 최소한의 권한만 부여하여, 공격자가 데이터베이스에 대한 권한을 악용하지 못하도록 합니다.

에러 메시지 숨기기

데이터베이스 에러 메시지를 사용자에게 직접 노출하지 않고, 일반적인 오류 메시지를 제공하여 공격자가 시스템의 내부 구조를 유추하지 못하도록 합니다.

보안 도구 및 라이브러리 사용

OWASP의 SQL Injection 방어를 위한 도구나 라이브러리를 사용하여, 코드에서 SQL Injection 취약점을 자동으로 검사하고 방지할 수 있습니다.

참고 자료

JSCODE 스터디 자료
웹 취약점과 해킹 매커니즘#7 XSS(Cross-Site Scripting) : https://www.fis.kr/ko/major_biz/cyber_safety_oper/attack_info/security_news?articleSeq=3408

임지선

성장하는 프론트엔드 개발자입니다.

이전 포스트

DNS 알아보기

다음 포스트

웹 보안과 인증

컴퓨터 네트워크

쿠키(Cookie)

쿠키 사용 방법

사용자 인증:

사용자 설정:

추적:

쿠키 특징

저장 위치:

수명:

보안:

세션(Session)

세션 사용 방법

사용자 상태 관리:

쇼핑 카트:

세션 특징

저장 위치:

수명:

보안:

인증

서버 기반 인증

특징

토큰 기반 인증

특징

JWT(JSON Web Token)

JWT의 구조

JWT는 .(점)으로 구분된 세 가지 부분으로 이루어집니다.

Header(헤더):

Payload(페이로드):

Signature(서명):

JWT의 작동 방식

사용자 인증:

토큰 전달:

토큰 저장:

API 요청 시 JWT 사용:

서버에서 검증:

JWT의 장점

무상태:

간편한 전송:

보안성:

JWT의 주의점

토큰 크기:

만료 시간:

보안 관리:

SOP (Same-Origin Policy)

출처의 정의

프로토콜:

호스트:

포트:

SOP의 역할

데이터 보호:

안전한 실행 환경:

CORS (Cross-Origin Resource Sharing)

작동 방식

프리플라이트 요청(Preflight Request):

응답 헤더:

Access-Control-Allow-Origin:

Access-Control-Allow-Methods:

Access-Control-Allow-Headers:

Access-Control-Allow-Credentials:

CORS의 역할

유연한 리소스 공유:

보안 강화:

XSS 공격

XSS 공격의 유형

Stored XSS (저장형 XSS):

Reflected XSS (반사형 XSS):

DOM-based XSS (DOM 기반 XSS):

XSS 공격의 결과

쿠키 탈취:

페이지 조작:

피싱:

기타 악의적 행위:

XSS 공격 방어 방법

XSS 공격을 방어하기 위해서는 다양한 방법을 조합하여 적용하는 것이 중요합니다.

입력 값 검증(Input Validation):

출력 값 인코딩(Output Encoding):

콘텐츠 보안 정책(CSP, Content Security Policy):

HTTPOnly 및 Secure 플래그 설정:

DOM 요소 접근 제한: