
스프링 애플리케이션에서 애플리케이션 수준의 보안을 구현할 때 가장 우선적인 선택이며 인증, 권한 부여 및 일반 적인 공격에 대한 방어를 구현하는 세부적인 맞춤 구성 방법을 제공한다.
스프링 시큐리티는 스프링 애플리케이션에서 애플리케이션 수준 보안을 구현하기 위한 사실상의 표준이다. 스프링 프레임워크의 철학이 스프링 컨텍스트의 관리로 시작되기 때문에 스프링 시큐리티도 어노테이션, 빈, 일반적인 스프링 방식의 구성 스타일을 사용해 보안을 정의한다.
데이터는 저장 데이터(Data at Rest)와 전송 중 데이터(Data in Transit)로 구분된다. 이 맥락에서 저장 데이터는 컴퓨터 스토리지에 있는 데이터를 의미하며, 전송 중 데이터는 한 위치에서 다른 위치로 교환 중인 모든 데이터를 의미한다. 데이터의 유형에 따라 다른 보안 조치를 적용해야 한다.
일반적인 취약성의 목록
인증(Authentication) : 이용자를 식별하는 프로세스
권한 부여(Authorization) : 이용자가 특정 기능과 데이터에 대한 접근 권한이 있는지 확인
인증 프로세스 중에 고유한 세션 id를 할당하지 않아 기존 세션 id를 재사용할 가능성이 있을 때 발생.
서버에 노출된 웹 서비스로 클라이언트 쪽 스크립트를 주입해 다른 사용자가 이를 실행하도록 하는 공격.
따라서 원치 않은 스크립트의 실행을 막기 위해 요청을 검토하는 과정이 필요하다.
특정 서버에서 작업을 호출하는 url을 추출해 외부에서 재사용할 수 있다고 가정한다. 요청의 출처를 확인하지 않고 실행할 경우 다른 모든 곳의 요청이 실행될 수 있다.
민감한 데이터 노출
알려진 취약성이 있는 종속성 사용
백엔드에 요청할 때마다 자격 증명을 다시 전송하고 자격 증명을 클라이언트에 저장하는 것은 좋지 않은 방법이다. OAuth 2 프레임워크는 권한 부여 서버와 리소스 서버라는 별도의 엔티티를 정의하여 사용자에게 권한을 부여하고 토큰을 제공한다.
백엔드 부분을 리소스 서버라고 할 수 있고 호출할 수 있는 엔드포인트를 보호된 리소스라고 할 수 있다.
1. 사용자가 요청을 한다.
2. 접근을 위해 토큰이 있어야 한다. 토큰을 위해 인증한다.
3. 액세스 토큰을 얻는다.
4. 액세스 토큰을 이용해 리소스에 접근한다.