웹 보안 면접 질문

XSS는 Cross-Site Scripting의 약자로, 공격자가 웹 사이트에 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되도록 하는 공격입니다. 이를 통해 쿠키 탈취, 세션 하이재킹, 사용자 정보 탈취 등 다양한 악성 행위를 할 수 있습니다.

XSS는 크게 Stored XSS, Reflected XSS, DOM-based XSS 세 가지 유형으로 나눌 수 있습니다. Stored XSS는 악성 스크립트가 서버에 저장되어 지속적으로 사용자에게 영향을 주는 반면, Reflected XSS는 사용자의 요청에 악성 스크립트가 포함되어 즉시 실행됩니다. DOM-based XSS는 서버를 거치지 않고 클라이언트 측에서 발생하는 공격입니다.

XSS를 방어하기 위해서는 다음과 같은 방법들을 사용할 수 있습니다. 첫째, 사용자로부터 입력받는 모든 값에 대해 유효성 검사를 철저히 수행하고, 위험한 문자들을 제거하거나 이스케이프 처리해야 합니다. 둘째, 웹 페이지에 출력되는 모든 데이터에 대해 HTML 엔티티 인코딩과 같은 적절한 인코딩을 적용하여 스크립트가 실행되지 않도록 해야 합니다. 셋째, Content Security Policy (CSP)를 설정하여 허용된 출처의 스크립트만 실행되도록 제한할 수 있습니다. CSP는 브라우저에게 어떤 리소스를 로드할 수 있는지 알려주는 역할을 합니다.

CSRF는 "Cross-Site Request Forgery"의 약자로, 웹사이트가 사용자의 의도와 다르게 악성 요청을 보내도록 속이는 공격입니다. 공격자는 사용자가 신뢰하는 웹사이트를 통해 사용자의 권한으로 특정 작업을 수행합니다.

CSRF 방어 방법으로는 다음과 같은 것들이 있습니다.

• CSRF 토큰 사용: 서버에서 생성한 예측 불가능한 토큰을 폼에 포함시켜 요청을 보낼 때마다 검증합니다.
• SameSite 쿠키 속성 설정: SameSite 속성을 Strict 또는 Lax로 설정하여 다른 사이트에서 쿠키가 전송되는 것을 제한합니다.
• Referer 검증: 요청의 Referer 헤더를 확인하여 요청이 예상된 도메인에서 왔는지 확인합니다. 하지만 Referer 헤더는 위조될 수 있으므로 완벽한 방법은 아닙니다.
• Double Submit Cookie: CSRF 토큰을 쿠키와 요청 파라미터 모두에 포함시켜 서버에서 두 값을 비교하여 검증합니다.
• Origin 헤더 검증: Origin 헤더를 확인하여 요청이 예상된 도메인에서 왔는지 확인합니다. Referer 헤더보다 더 안전하지만, 모든 브라우저에서 지원하지 않을 수 있습니다.

이러한 방법들을 조합하여 사용하는 것이 CSRF 공격을 효과적으로 방어하는 데 도움이 됩니다.

SQL Injection은 웹 애플리케이션의 보안 취약점 중 하나로, 사용자가 입력한 값을 제대로 검증하지 않고 SQL 쿼리에 포함시켜 데이터베이스를 공격하는 방식입니다. 공격자는 악의적인 SQL 코드를 삽입하여 데이터베이스의 정보를 탈취하거나 변조, 심지어 삭제까지 할 수 있습니다.

SQL Injection을 예방하는 가장 효과적인 방법은 Prepared Statement를 사용하는 것입니다. Prepared Statement는 SQL 쿼리의 구조와 데이터를 분리하여, 사용자 입력 값을 쿼리 문자열이 아닌 파라미터로 전달합니다. 이렇게 하면 입력 값이 SQL 코드로 해석될 가능성을 원천적으로 차단할 수 있습니다.

ORM(Object-Relational Mapping) 프레임워크를 사용하는 것도 좋은 방법입니다. ORM은 데이터베이스 쿼리를 직접 작성하는 대신 객체 지향적인 방식으로 데이터베이스를 다루도록 도와주므로, SQL Injection 공격의 위험을 줄여줍니다.

또한, 사용자 입력 값에 대한 철저한 검증은 필수적입니다. 허용된 문자만 사용하도록 제한하거나, 특수 문자를 필터링하는 등의 방법을 통해 악의적인 입력 값을 차단해야 합니다. 데이터베이스 계정에 필요한 최소한의 권한만 부여하는 것도 SQL Injection 공격으로 인한 피해를 최소화하는 데 도움이 됩니다.

면접관님, 인증과 인가는 보안에서 중요한 개념인데요, 쉽게 말해 인증은 '누구인지' 확인하는 과정이고, 인가는 '무엇을 할 수 있는지' 확인하는 과정입니다.

예를 들어, 웹사이트에 로그인할 때 아이디와 비밀번호를 입력하는 것은 인증 과정입니다. 웹사이트가 제가 누구인지 확인하는 거죠. 인증이 성공하면, 웹사이트는 제가 어떤 권한을 가지고 있는지 확인합니다. 이것이 인가입니다. 예를 들어, 관리자 계정으로 로그인했다면 게시글을 삭제할 수 있는 권한이 있을 것이고, 일반 사용자 계정이라면 게시글을 읽는 권한만 있을 수 있습니다.

OAuth 2.0 같은 경우, 사용자가 특정 서비스(예: 구글)에 인증되면, 다른 서비스(예: 웹사이트)가 사용자의 구글 계정에 접근할 수 있도록 인가를 요청할 수 있습니다. 이때 사용자는 어떤 정보에 접근을 허용할지 선택할 수 있습니다.

인증(Authentication)에서 신원 확인은 사용자가 누구인지 증명하는 과정입니다. 주로 사용자 ID와 비밀번호 같은 자격 증명을 기반으로 합니다. 사용자가 제공한 정보가 저장된 정보와 일치하는지 확인하여 신원을 확정합니다.

인가(Authorization)에서 권한 확인은 인증된 사용자가 특정 리소스나 기능에 접근할 수 있는지 판단하는 과정입니다. 이는 사용자의 역할, 권한 목록, 또는 정책 등을 기반으로 합니다. 예를 들어, 관리자 역할은 모든 기능에 접근 가능하지만, 일반 사용자는 제한된 기능만 접근할 수 있습니다.

로그인 이후 매 요청마다 이 두 가지는 다음과 같이 적용됩니다.

1. 인증 (신원 확인): 사용자가 처음 로그인할 때 사용자 ID와 비밀번호를 제출하여 신원을 확인합니다. 성공하면 서버는 보통 세션 ID나 JWT(JSON Web Token)와 같은 인증 토큰을 발급합니다. 이 토큰은 사용자의 신원을 증명하는 역할을 합니다.

2. 인가 (권한 확인): 이후 사용자가 어떤 요청을 보낼 때마다, 요청 헤더에 이 인증 토큰을 포함시킵니다. 서버는 이 토큰을 검증하여 사용자가 누구인지 다시 한번 확인하고(인증), 해당 사용자가 요청한 작업(예: 특정 데이터 조회, 파일 수정)을 수행할 권한이 있는지(인가)를 확인합니다. 권한이 있다면 요청을 처리하고, 없다면 접근을 거부합니다.

RBAC는 사용자에게 직접 권한을 부여하는 대신, '역할'이라는 중간 단계를 두어 권한을 관리하는 방식입니다. 예를 들어, '관리자' 역할에 특정 권한들을 묶어두고, 사용자에게는 '관리자' 역할을 부여하는 식이죠.

이 방식의 가장 큰 장점은 관리 용이성과 확장성입니다. 사용자 수가 늘어나거나 권한 변경이 필요할 때, 개별 사용자에게 일일이 권한을 수정하는 대신 역할에 대한 권한만 변경하면 되므로 훨씬 효율적입니다. 또한, 새로운 역할만 정의하면 되므로 시스템 확장에도 유연하게 대처할 수 있습니다. 결과적으로 보안 관리도 더욱 체계적이고 간편해집니다.

OAuth 2.0의 Authorization Code Grant 플로우에서 인가 코드와 액세스 토큰을 분리하는 주된 이유는 보안 강화입니다.

인가 코드는 브라우저와 같은 프론트 채널을 통해 클라이언트 애플리케이션으로 전달됩니다. 이 과정에서 인가 코드가 노출되더라도, 이는 일회성으로 사용되며 제한된 권한만을 가지므로 즉각적인 큰 피해를 막을 수 있습니다.

반면, 액세스 토큰은 클라이언트 애플리케이션의 백엔드 서버와 인증 서버 간의 안전한 통신(백 채널)을 통해서만 교환됩니다. 액세스 토큰은 실제 리소스 접근 권한을 가지므로, 이를 직접 브라우저로 노출시키면 토큰 탈취 위험이 매우 커집니다. 인가 코드를 사용함으로써, 민감한 액세스 토큰은 안전한 백 채널을 통해서만 전달되도록 하여 토큰 탈취 위험을 최소화하는 것입니다.

HTTPS는 HTTP 프로토콜 위에 TLS라는 보안 계층을 얹어 안전하게 통신하는 방식입니다. TLS는 전송 계층 보안 프로토콜이고, 이전 버전인 SSL을 계승했습니다.

HTTPS 통신은 TLS 핸드셰이크 과정을 거쳐 암호화된 연결을 설정합니다. 먼저 클라이언트가 서버에 접속 요청을 보내면, 서버는 인증서를 클라이언트에게 제공합니다. 클라이언트는 인증서 발급 기관을 통해 인증서의 유효성을 검증합니다.

인증서 검증이 완료되면, 클라이언트는 서버와 공유할 비밀 키를 생성하고, 서버의 공개키로 암호화하여 서버에게 전송합니다. 서버는 자신의 개인키로 암호화된 비밀 키를 복호화합니다.

이후 클라이언트와 서버는 공유된 비밀 키를 사용하여 대칭키 암호화 방식으로 데이터를 주고받습니다. 대칭키 암호화는 비대칭키 암호화보다 훨씬 빠르기 때문에 효율적인 통신이 가능합니다. 이렇게 TLS 핸드셰이크를 통해 안전하게 암호화된 HTTPS 연결이 이루어집니다.

대칭 암호화와 비대칭 암호화는 암호화 방식과 키 관리에 차이가 있습니다. 대칭 암호화는 암호화와 복호화에 같은 키를 사용해서 빠르지만, 키를 안전하게 공유하는 문제가 있습니다. AES가 대표적이고, 대량의 데이터를 암호화할 때 주로 사용됩니다. 예를 들어, 보안 메신저에서 메시지 내용을 암호화할 때 사용될 수 있습니다.

반면, 비대칭 암호화는 공개 키와 개인 키를 사용합니다. 공개 키로 암호화하고 개인 키로 복호화하죠. RSA가 대표적이며, 키 교환이나 전자 서명에 유용합니다. 속도는 느리지만, 키를 안전하게 공유할 수 있다는 장점이 있습니다. 웹사이트의 HTTPS 연결에서 서버 인증서를 통해 안전한 통신을 설정하는 데 사용됩니다. 전자 서명을 통해 문서의 무결성을 보장하는 데도 활용됩니다.

JWT는 웹 표준 인증 방식 중 하나로, Header, Payload, Signature 세 부분으로 구성됩니다.

Header는 토큰 타입과 암호화 알고리즘 정보를 담고, Payload는 사용자 정보나 권한 같은 클레임 정보를 JSON 형태로 담습니다. Signature는 Header와 Payload를 합쳐 비밀키로 암호화한 값으로, 토큰의 무결성을 검증하는 데 사용됩니다.

인증 방식은 서버가 사용자를 인증한 후 JWT를 생성하여 클라이언트에게 전달하고, 클라이언트는 이후 요청 시 JWT를 담아 서버에 전달합니다. 서버는 Signature를 검증하여 토큰의 유효성을 확인하고, Payload에 담긴 정보를 활용하여 사용자를 인증합니다.

보안을 위해서는 HTTPS를 사용하여 토큰 탈취를 막고, Payload에 민감한 정보를 직접 담지 않도록 주의해야 합니다. 또한, 토큰 만료 시간을 설정하여 토큰이 탈취되더라도 피해를 최소화해야 하며, XSS 공격에 대비하여 클라이언트 측에서 토큰을 안전하게 저장하고 관리해야 합니다.

OAuth 2.0은 특정 서비스(Resource Server)의 자원에 접근 권한을 위임받기 위한 표준 프로토콜입니다. 핵심은 사용자의 ID/PW를 직접 전달하지 않고, "Access Token"이라는 임시 키를 발급받아 사용하는 것입니다.

OAuth 2.0에는 여러 흐름(Grant Type)이 있는데, 가장 많이 사용되는 것은 다음과 같습니다.

• Authorization Code Grant: 웹 서버 기반 앱에 적합하며, Authorization Server로부터 Authorization Code를 받아 Access Token을 요청하는 방식입니다. 보안성이 높습니다.

• Implicit Grant: 클라이언트 사이드 앱(JavaScript 앱)에 적합하며, Authorization Server로부터 Access Token을 직접 받는 방식입니다. 보안에 취약하여 사용이 권장되지 않습니다.

• Client Credentials Grant: 백엔드 서비스 간 통신에 사용되며, Client ID와 Secret을 사용하여 Access Token을 요청하는 방식입니다.

• Resource Owner Password Credentials Grant: 사용자의 ID/PW를 직접 사용하여 Access Token을 요청하는 방식입니다. 신뢰할 수 있는 환경에서만 사용해야 합니다.

• PKCE (Proof Key for Code Exchange): Authorization Code Grant의 보안을 강화하기 위해 사용되며, 특히 모바일 앱과 같은 공개 클라이언트 환경에서 CSRF 및 Authorization Code Interception 공격을 방지합니다.

Access Token은 만료 기간이 있으며, 만료된 Access Token을 갱신하기 위해 Refresh Token이 사용됩니다.

면접관님, 세션 기반 인증과 토큰 기반 인증은 웹 애플리케이션에서 사용자 인증을 처리하는 방식인데요, 주요 차이점은 서버의 상태 유지 여부에 있습니다.

세션 기반 인증은 서버가 사용자 세션 정보를 저장하고 관리합니다. 사용자가 로그인하면 서버는 세션 ID를 생성하여 쿠키를 통해 클라이언트에 전달하고, 이후 요청 시 쿠키에 담긴 세션 ID를 통해 사용자를 식별합니다. 장점으로는 구현이 비교적 간단하다는 점이 있지만, 서버에 세션 정보를 저장해야 하므로 서버 확장에 제약이 있을 수 있습니다. 또한, 세션 ID가 탈취될 경우 공격자가 해당 세션을 사용할 수 있습니다.

반면, 토큰 기반 인증은 서버가 사용자 정보를 담은 토큰(예: JWT)을 발급하고, 클라이언트는 이 토큰을 저장하여 요청 시마다 서버에 전달합니다. 서버는 토큰의 유효성을 검증하여 사용자를 인증합니다. 서버는 토큰 자체를 저장하지 않으므로 Stateless하며, 확장에 용이합니다. 토큰이 탈취되더라도 토큰 만료 시간을 짧게 설정하거나, 토큰을 무효화하는 방식으로 대응할 수 있습니다. 다만, 세션 기반 인증에 비해 구현이 복잡할 수 있습니다.

CORS는 웹 브라우저의 보안 정책인 Same-Origin Policy 때문에 발생하는 교차 출처 리소스 공유 문제를 해결하기 위한 메커니즘입니다. Same-Origin Policy는 스크립트가 다른 Origin(프로토콜, 도메인, 포트가 다른 경우)의 리소스에 접근하는 것을 제한하는데, CORS는 서버가 특정 Origin에서의 요청을 허용하도록 응답 헤더를 통해 명시적으로 허가하는 방식입니다.

주로 Access-Control-Allow-Origin 헤더를 사용하여 허용할 Origin을 지정합니다. 예를 들어, Access-Control-Allow-Origin: https://example.com 와 같이 설정하면 https://example.com 도메인에서 오는 요청만 허용됩니다. 복잡한 요청의 경우, 실제 요청 전에 OPTIONS 메서드를 이용한 Preflight Request를 보내 서버의 허가를 확인하는 과정을 거치기도 합니다.

비밀번호를 안전하게 저장하는 것은 매우 중요합니다. 단순히 비밀번호를 해싱해서 저장하는 것은 위험합니다. 왜냐하면 레인보우 테이블 공격이나 사전 공격에 취약하기 때문입니다.

그래서 솔트(Salt)를 사용해야 합니다. 솔트는 각 비밀번호마다 임의의 문자열을 추가하여 해싱하는 방식입니다. 이렇게 하면 동일한 비밀번호라도 해시 결과가 달라져서 공격이 어려워집니다.

더 안전하게 하려면 bcrypt나 Argon2와 같은 키 스트레칭(Key stretching) 함수를 사용하는 것이 좋습니다. 이 함수들은 해싱을 여러 번 반복하여 연산량을 늘려 공격자가 해독하는 데 더 많은 시간을 소요하도록 만듭니다. bcrypt는 솔트 생성과 해싱을 내장하고 있고, Argon2는 더 현대적인 알고리즘으로 메모리 사용량까지 조절하여 공격을 방어합니다.

암호화는 비밀번호 저장에 적합하지 않습니다. 암호화는 복호화가 가능해야 하는데, 비밀번호는 복호화할 필요 없이 인증 시에만 비교하면 되기 때문입니다.

SSRF는 서버가 공격자의 의도대로 다른 서버에 요청을 보내도록 만드는 공격입니다. 예를 들어, 공격자가 서버를 통해 내부 네트워크에 접근하거나, 클라우드 환경의 메타데이터를 탈취할 수 있습니다.

방어 방법으로는 크게 세 가지가 있습니다. 첫째, 허용된 URL 목록(화이트리스트)을 사용하여 요청 목적지를 제한합니다. 둘째, 클라우드 환경의 메타데이터 엔드포인트(예: 169.254.169.254)에 대한 접근을 차단하거나 인증을 강화합니다. 셋째, 요청을 보내기 전에 URL의 유효성을 철저히 검사하여 내부 IP 주소나 예상치 못한 호스트로의 요청을 막아야 합니다. 이러한 방어 조치를 통해 SSRF 공격의 위험을 크게 줄일 수 있습니다.

Zero Trust 보안 모델은 "절대 신뢰하지 않고, 항상 검증한다"는 원칙에 기반합니다. 기존 경계 보안은 네트워크 내부 사용자를 신뢰했지만, Zero Trust는 내부/외부를 구분하지 않고 모든 접근 시도를 검증합니다.

주요 차이점은 다음과 같습니다.

• 신뢰 모델: 경계 보안은 내부를 신뢰하는 반면, Zero Trust는 모든 사용자와 장치를 의심합니다.
• 접근 제어: Zero Trust는 최소 권한 원칙을 적용하여 필요한 권한만 부여하고, 다단계 인증(MFA)을 통해 사용자 신원을 강화합니다.
• 검증 방식: Zero Trust는 지속적인 모니터링과 인증을 통해 보안 상태를 유지하며, 마이크로 세분화를 통해 공격 범위를 최소화합니다.

기존 경계 보안은 네트워크 내부 침투 시 공격자가 자유롭게 이동할 수 있다는 취약점을 가지고 있지만, Zero Trust는 이러한 측면을 보완하여 더욱 강력한 보안을 제공합니다.

보안 취약점 공개 정책(Responsible Disclosure)은 보안 취약점을 발견했을 때, 해당 취약점을 즉시 공개하는 것이 아니라, 먼저 해당 소프트웨어 또는 시스템의 벤더에게 알리고, 벤더가 문제를 해결할 수 있도록 충분한 시간을 주는 정책입니다.

이 정책이 중요한 이유는 다음과 같습니다. 즉시 공개할 경우 악의적인 공격자가 해당 취약점을 악용하여 피해를 발생시킬 수 있기 때문입니다. 벤더에게 먼저 알림으로써, 벤더는 보안 패치를 개발하고 배포하여 사용자들을 보호할 수 있습니다.

일반적으로 취약점 보고 후 벤더와 협력하여 패치 개발 및 배포 일정을 조율하고, 충분한 시간이 지난 후 취약점을 공개합니다. 일부 기업은 Bug Bounty 프로그램을 운영하여 취약점 발견자에게 보상을 제공하기도 합니다. 이러한 정책은 선제적인 보안 강화와 기업의 신뢰도 향상에 기여합니다.

JWT의 stateless 장점을 유지하면서 즉시 폐기를 구현하는 것은 흥미로운 문제입니다. 몇 가지 전략을 고려해볼 수 있습니다.

가장 일반적인 접근은 Refresh Token을 사용하는 것입니다. Access Token은 짧게 만료시키고, 사용자가 로그아웃하거나 토큰이 탈취되었다고 의심될 때 Refresh Token을 무효화하는 방식입니다. Refresh Token은 서버 측에서 관리하며, 유효한 Refresh Token이 있어야 새로운 Access Token을 발급받을 수 있습니다.

또 다른 방법은 Token Blacklist를 사용하는 것입니다. 로그아웃하거나 토큰을 무효화해야 할 때, 해당 토큰의 ID(jti 클레임 등)를 서버의 캐시나 데이터베이스에 블랙리스트로 등록합니다. Access Token 검증 시 이 블랙리스트를 확인하여 무효화된 토큰인지 판단하는 거죠. 다만, 이 방법은 stateless의 장점을 일부 희생하게 됩니다.

짧은 만료 시간을 가진 Access Token을 사용하는 것도 방법입니다. 만료 시간을 매우 짧게 설정하면 토큰이 탈취되더라도 유효한 시간이 짧아 피해를 최소화할 수 있습니다. 물론, 사용자 경험을 위해 Refresh Token과 함께 사용해야 합니다.

마지막으로, 토큰 버전 관리를 고려할 수 있습니다. 사용자별로 토큰 버전을 관리하고, 로그아웃 시 해당 사용자의 토큰 버전을 업데이트하는 방식입니다. Access Token 검증 시 현재 사용자의 토큰 버전과 일치하는지 확인하는 거죠.

각 전략마다 장단점이 있으므로, 서비스의 요구사항과 트레이드오프를 고려하여 적절한 조합을 선택하는 것이 중요합니다.

OAuth2 Authorization Code Grant는 클라이언트가 사용자 대신 리소스 서버에 접근할 수 있도록 하는 강력한 메커니즘입니다. 하지만 SPA나 모바일 앱 같은 public client는 클라이언트 비밀(client secret)을 안전하게 저장할 방법이 없기 때문에, 인가 코드 탈취 공격에 취약했습니다.

PKCE는 이러한 public client의 보안을 강화하기 위해 도입되었습니다. Authorization Code Grant 과정에서 클라이언트는 code_verifier라는 임의의 문자열을 생성하고, 이를 해싱한 code_challenge를 인가 요청 시 함께 보냅니다. 인가 서버는 이 code_challenge를 저장해 둡니다.

이후 클라이언트가 인가 코드를 받아 토큰을 요청할 때, 저장해 두었던 code_verifier를 함께 전송합니다. 인가 서버는 받은 code_verifier를 저장된 code_challenge와 동일한 방식으로 해싱하여 일치하는지 확인합니다. 만약 인가 코드가 중간에 탈취되더라도, 공격자는 code_verifier를 알 수 없기 때문에 토큰을 발급받을 수 없습니다. 즉, code_verifier는 동적인 비밀처럼 작동하여 인가 코드의 유효성을 검증하는 역할을 합니다.

SPA나 모바일 앱은 클라이언트 비밀을 코드에 직접 포함시키거나 안전하게 저장하기 어렵기 때문에, code_verifier는 이러한 환경에서 인가 코드 탈취 공격을 효과적으로 방어하는 필수적인 보안 계층입니다.

OIDC의 ID Token과 OAuth2의 Access Token은 목적과 검증 방식이 다릅니다.

ID Token은 사용자 인증 정보를 담고 있으며, '누가 로그인했는지'를 나타냅니다. 이는 JWT 형식으로 발급되며, 클라이언트가 ID Token을 검증하면 사용자의 신원을 확인할 수 있습니다.

반면 Access Token은 '무엇에 접근 가능한지'를 나타내는 인가(Authorization) 토큰입니다. 리소스 서버에 대한 접근 권한을 부여하며, ID Token처럼 사용자 신원을 직접적으로 나타내지는 않습니다.

만약 클라이언트가 Access Token을 ID Token처럼 사용하면, 사용자의 신원을 잘못 판단하거나 권한 없는 접근을 허용할 수 있습니다. 반대로 ID Token을 Access Token처럼 사용하면, 사용자에게 부여되지 않은 리소스 접근 권한을 부여하게 되어 심각한 보안 문제가 발생할 수 있습니다. 각 토큰의 목적에 맞게 사용하고 검증하는 것이 중요합니다.

JWT 서명 검증 시 alg 헤더 관련 취약점은 크게 두 가지입니다.

첫째, alg:none 허용 취약점입니다. 이는 서명 없이 토큰을 발급하도록 허용하여, 공격자가 토큰의 페이로드를 조작하고 서명 없이도 유효한 토큰처럼 사용할 수 있게 합니다.

둘째, Key Confusion 공격입니다. RS256으로 발급된 토큰을 HS256으로 검증할 때 발생하며, 공격자는 RS256의 공개키를 HS256의 비밀키로 사용하여 토큰을 위조할 수 있습니다.

이러한 취약점을 방지하기 위해 검증 로직은 토큰의 alg 헤더를 신뢰하지 않고, 서버가 기대하는 특정 알고리즘(예: RS256)만을 강제해야 합니다. 즉, 토큰의 alg 값이 서버에서 설정한 허용 알고리즘 목록에 없으면 즉시 거부해야 합니다. 또한, RS256 검증 시에는 반드시 공개키를 사용하고, HS256 검증 시에는 반드시 비밀키를 사용하도록 명확히 구분하여 구현해야 합니다.