쏚쏚스포이드

애플리케이션 수준 보안을 지원하는 스프링 시큐리티

스프링 시큐리티는 인프라적으로 가장 최상층에 위치한 애플리케이션 수준 보안을 구현한다

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

• 인증 취약성
• 세션 고정
• XSS(교차 사이트 스크립팅)
• CSRF(사이트 간 요청 위조)
• 주입
• 기밀 데이터 노출
• 메서드 접근 제어 부족
• 알려진 취약성이 있는 종속성 이용

인증과 권한 부여의 취약성

• 인증(Authentication)
  • 애플리케이션을 이용하려는 사람을 식별하는 프로세스
  • 사용자의 ID를 확인하고 나면 권한을 부여하는 프로세스가 시작
• 권한 부여(Authorization)
  • 인증된 호출자가 특정 기능과 데이터에 대한 이용 권리가 있는지 확인하는 프로세스
  • ex) 대부분의 인증된 사용자는 본인의 계좌에서만 이체가 가능하다
• 세션 고정(Session fixation)
  • 웹 애플리케이션의 더 구체적이고 심각한 약점
  • 이미 생성된 세션 ID를 재이용해 유효한 사용자를 가장할 수 있다.
  • 취약성 발생이유 : 인증 프로세스 중 고유한 세션ID를 할장하지 않아 기존 세션ID가 재사용될 가능성이 있을 때 발생
  • 공격방식 : 세션ID가 URL에 들어있는 방식으로 세션이 구현되어있을 때 악성 링크를 클릭하도록 유인할 수 있다. 이 때 클릭했을 때 세션 ID가 탈취된다.
    세션 값을 쿠키에 저장하는 경우 피해자의 브라우저가 스크립트를 실행하도록 할 수도 있다.
• XSS(교차 사이트 스크립팅, Cross Site Scripting)
  • 클라이언트 쪽 스크립트를 주입해 다른 사용자가 이를 실행하도록 한다.
  • 소독 하는 과정을 통해 해결
  • 이 취약성으로 인해 발생되는 문제 : 계정 가장(세션 고정과 결합), DDOS

  • 

• CSRF(사이트 간 요청 위조, Cross-Site Request Forger)
  • 서버가 요청의 출처를 확인하지 않을 때 발생하는 문제(모든 곳에서 요청이 실행될 수 있음)
  • 일반적으로 공격자는 CSRF를 이용해 시스템의 데이터를 변경하는 동작을 실행
• 웹 애플리케이션의 주입(Injection) 취약성 이해
  • 주입 공격은 광범위한 공격 방식.
  • 공격자는 시스템에 특정 데이터를 주입하는 취약성을 이용
  • 공격의 목표 : 시스템의 데이터 변경, 삭제, 무단 이용을 유발
  • 주입 공격의 유형 : XSS Injection, SQL Injection, XPath Injection, OS Command Injection, LDAP Injection 등
• 민감한 데이터의 노출 처리하기
  • 공개정보가 아닌 것은 절대 로그에 기록하지 말아야 한다
  • 로그에 기록하지 말아야 하는 예시
    • [오류] 요청의 서명이 잘못되었습니다. 사용할 올바른 키는 X입니다.
    • [경고] 사용자 이름 X와 암호 Y를 이용하여 로그인하지 못했습니다.
    • [정보] 사용자 X가 올바른 암호 Y를 이용하여 로그인했습니다.
  • 애플리케이션에 예외가 발생했을 때 서버가 클라이언트에 반환하는 정보를 주의

  • 

  • 로그인의 예시
    • 사용자의 이름이 올바르지 않음, 사용자의 암호가 올바르지 않음
      보다 사용자 이름 또는 암호가 올바르지 않음을 통해 처리하는 것이 정보를 제공하지 않기에 더 바람직함
• 메서드 접근 제어 부족
  • 컨트롤러 단에서 구성했을 때 나중에 다른 컨트롤러에서 레포지토리 참조시 권한부여가 제대로 안될 수도 있다.

  • 

• 알려진 취약성이 있는 종속성 이용
  • 개발하는 애플리케이션이 아닌 기능을 만들기 위해 이용하는 라이브러리나 프레임워크 같은 종속성에 취약성이 있을 수 있다.
  • 메이븐 또는 그레이들 구성에 플러그인을 추가하면 정적 분석을 수행할 수 있음

OAuth 2 흐름 이해

인증 권한 부여 방식

• 사용자가 애플리케이션접근 시 백엔드 리소스 호출
• 권한 부여 서버를 호출해서 토큰을 획득, 자격증명, 갱신 토큰으로 토큰 획득
• 자격 증명, 갱신 토큰이 올바를 때 새로운 액세스 토큰을 클라이언트로 반환
• 리소스 호출 시 서버에 요청할 때 헤더에 액세스 토큰을 담아 서비스 이용

토큰 형태로 애플리케이션이 구현되었을 때 이점

• 클라이언트는 사용자 자격 증명을 저장할 필요 없이 액세스 토큰과 갱신 토큰만 저장하면 된다.
• 애플리케이션은 사용자 자격 증명을 노출하지 않는다.
• 토큰을 가로챘을 때 사용자 자격 토큰을 실격시킬 수 있다.
• 토큰을 사용했을 때는 제삼자가 사용자를 가장하지 않고도 사용자 대신 리소스에 접근할 수 있다. 토큰의 수명은 짧기에 취약성을 악용할 기한이 제한된다.

API 키, 암호화 서명, IP 검증을 이용해 요청 보안

교환되는 메시지를 아무도 변경하지 못하게 하기 위해 백엔드 구성요소간 보안을 거는 방식이 있다.

• 요청 및 응답 헤더에 정적 키 이용
• 암호화 서명으로 요청 및 응답 서명
• IP 주소에 검증 적용

통신의 신뢰성을 테스트하는 제일 좋은 방법은 암호화 서명을 이용하는 것

이 책에서 배울 내용

스프링 시큐리티를 배우는 실용적 접근법 소개

• 스프링 시큐리티의 아키텍처와 기본 구성 요소 및 이를 이용해 애플리케이션을 보호하는 방법
• OAuth 2 및 OpenID Connect 흐름과 시큐리티로 인증과 권한 부여를 구현하는 방법
• 애플리케이션의 다양한 계층에서 스프링 시큐리티로 보안을 구현하는 방법
• 다양한 구성 스타일과 프로젝트에 맞는 모범 사례
• 리액티브 애플리케이션에 스프링 시큐리티 이용
• 보안 구현 테스트

요약

• 스프링 시큐리티는 스프링 애플리케이션을 보호하기 위한 가장 인기 있는 선택이며 다양한 스타일과 아키텍처에 적용할 수 있는 갖가지 대안을 제공한다
• 시스템의 계층별로 보안을 적용해야 하며 계층별로 다른 관행을 이용해야 한다.
• 보안은 소프트웨어 프로젝트를 시작할 때부터 고려해야 하는 공통 관심사다
• 일반적으로 취약성을 예방하는 투자 비용보다 공격의 대가가 훨씬 크다.
• 오픈 웹 애플리케이션 보안 프로젝트(OWASP)는 취약성과 보안 관련 사항을 참고할 수 있는 훌륭한 장소다.
• 종종 아주 작은 실수 때문에 큰 피해가 발생한다.( 로그나 오류 메시지에 민감한 데이터 노출)