[시큐리티] 스프링 시큐리티 기본 개념 및 보안에 대한 개념

1. 스프링 시큐리티 개념

스프링 애플리케이션에 보안을 적용하는 과정을 크게 간소화하는 프레임워크

2. 스프링 시큐리티 방법

• 어노테이션, 빈, 메서드 등 스프링 방식의 구성 스타일을 이용해서 애플리케이션 수준의 보안을 정의한다
• 보안을 구성하는 방법은 본인 하기 나름이다. 간단하게 할 수도 있고, 복잡하게 할 수도 있다
  • 보통, 누가 작업을 수행할 수 있는지 결정(인증), 특정 사람이 특정 데이터를 이용할 수 있는지 결정(권한), 데이터 전송 및 저장 과정에서 올바른 전송 및 저장인지 결정하는 방식 사용
  • 인증: 애플리케이션이 사용자를 식별하는 방법
  • 권한 부여: 사용자 식별 후 나중에 이들이 무엇을 하도록 허용해야 하는지 결정

3. 보안이란

애플리케이션은 전화번호, 이메일 주소, 신용카드 번호 등의 정보에 접근, 변경 또는 가로챌 기회가 없게 해야 하며 의도된 사용자 이외의 대상은 어떤 식으로든 데이터와 상호 작용할 수 없게 해야 한다.

보안은 계층별로 적용해야 하며 각 계층에 다른 접근 방식이 필요하다. 여기서 계층이란 아래 표와 같은 계층을 의미한다.

애플리케이션	지속성
jvm
컨테이너, 오케스트레이션
운영체제
가상머신	베어메탈
네트워크

4. 보안이 중요한 이유

보안에 충분한 주의를 기울이지 않으면 원치 않은 대가를 치러야 할 수 있다. 대가에는 금전적 비용, 이미지 손상 등이 있다. 하지만 서비스의 종류에 따라 심각하게는 인명 피해까지 이어질 수 있다.

결국, 취약성을 예방하는 것이 공격받은 후 대처하는 것보다 비용이 적게 든다고 할 수 있다.

5. 웹 애플리케이션의 일반적인 보안 취약성

1) 인증과 권한 부여의 취약성

인증

애플리케이션이 이를 이용하려는 사람을 식별하는 프로세스

권한 부여

인증된 호출자가 특정 기능과 데이터에 대한 이용 권리가 있는지 확인하는 프로세스

인증 취약성

• 사용자가 악의를 가지고 다른 사람의 기능이나 데이터에 접근할 수 있다
• 스프링 시큐리티를 이용해 특정 역할이 있는 인증된 사용자만 특정 엔드포인트에 접근하도록 정의할 수 있다. 하지만 데이터 수준에 제한이 없으면 다른 사용자의 데이터를 이용할 수 있는 허점이 생길 수 있다.
• 예를 들어 로그인을 해서 인증 된 사용자는 /products/{name} 엔드포인트에 접근할 수 있다고 하자. 보통은 로그인 된 사용자의 name이 적용되어 본인의 제품만 확인할 수 있다. 하지만, 악의를 가진 사람이 일단 로그인을 한 후 name에 다른 사용자의 이름을 적어서 호출하면 다른 사람의 제품도 확인할 수 있게 된다.

2) 세션 고정

웹 애플리케이션이 인증 프로세스 중에 고유한 세션 ID를 할당하지 않아 기존 세션 ID가 재사용될 가능성이 있을 때 발생한다. 공격자는 이미 생성된 세션 ID를 재이용해 유효한 사용자를 가장할 수 있다.

3) XSS(교차 사이트 스크립팅)

서버에 노출된 웹 서비스로 클라이언트 쪽 스크립트를 주입해 다른 사용자가 이를 실행하도록 하는 공격. 이 취약성이 악용되면 계정 가장(세션 고정과 결합)이나 DDos와 같은 분산 공격 참여 등의 결과가 발생할 수 있다.

4) CSRF(사이트 간 요청 위조)

사용자 A, A가 사용하는 서비스 B, 공격자 C가 있다고 하자. A는 B에 로그인을 한다. 로그인 된 상태로 A는 C가 보낸 이상한 링크를 통해 어떤 사이트에 접속한다. 이 사이트에는 B에 광고성으로 글을 올릴 수 있는 위조된 코드가 들어있다. A가 B에 로그인을 한 상태로 위조된 코드가 있는 사이트에 들어갔는데 만약 B가 요청이면 무조건 승낙을 하는 보안 정책을 가지고 있다면 B에는 위조된 요청에 의해 A의 계정으로 광고성 글이 작성된다. 

이처럼 위조된 요청으로 서버에 어떤 작업을 시킬 수 있는 것이 CSRF이다.

5) 주입 공격

공격자는 시스템에 특정 데이터를 유입하는 취약성을 이용한다. 공격의 목표는 시스템에 피해를 주고, 원치 않는 방법으로 데이터를 변경하거나 원래는 접근할 수 없는 데이터를 검색하는 것.

6) 기밀 데이터 노출

기밀 데이터를 공개하게되면서 발생하는 문제. 실제 개발된 시스템에서는 모든 환경에서 민감한 정보를 볼 수 없어야 하고 적어도 운영 환경에서는 소수의 사람만 개인 데이터에 접근할 수 있어야 한다.

클라이언트 요청에 대한 응답으로 어떤 문제가 발생했는지 알려주지 않는 것이 좋다. 응답 상태 코드로 400이 되도록 하는 등의 방법이 있다.

7) 메서드 접근 제어 부족

컨트롤러 계층에 권한 부여를 적용했지만, 리포지토리에는 적용되지 않아서, 서비스가 현재 인증된 사용자에게 속하지 않은 계정을 요청해도 리포지토리는 정상 작동하게 된다.

따라서, 애플리케이션 수준에서도 한 계층에만 권한 부여를 적용하면 안 된다. 컨트롤러, 리포지토리 등 각 계층에 권한 부여가 이루어져야 한다. 

8) 알려진 취약성이 있는 종속성 이용

개발하는 애플리케이션이 아니라 기능을 만들기 위해 이용하는 라이브러리나 프레임워크 같은 종속성에 취약성이 있을 수 있다. 이용하는 종속성을 항상 주의 깊게 살펴보고 알려진 취약성이 있는 버전은 제거해야 한다.