오늘날의 보안

오늘날의 보안

SW 시스템 개발에 관여하는 사람들은 처음부터 보안을 고려해야 한다는 것을 명심하자.

• 성능, 확장성, 가용성, 보안과 같은 소프트웨어의 비기능적 특징은 시간이 지남에 따라 단기적 영향과 장기적 영향을 미칠 수 있음.
• 초기에 이러한 특징을 고려하지 않으면 애플리케이션 사용자의 수익성에도 중대한 영향이 발생할 수 있다.
• 또한 이러한 사항을 무시하면 DDos(분산 서비스 거부) 공격에 원치 않게 참여하는 등 다른 시스템 오류도 발생시킬 수 있다.

• 즉 소프트웨어 시스템을 다룰 때는 여러 비기능적인 측면을 고려해야 한다. 이러한 비기능척 측면도 모두 중요하며 소프트웨어 개발 프로세스에 책임감 있게 다뤄야함

1.1 스프링 시큐리티 : 개념과 장점

• 스프링 시큐리티는 애플리케이션 수준의 보안을 구현할 수 있게 해주는 프레임워크다. 그러나 스프링 시큐리티를 올바르게 이해하고 이용하는 것은 개발자의 몫이다. 스프링 시큐리티가 애플리케이션이나 저장 데이터나 전송중인 민감한 데이터를 자동으로 보호해주는 것은 아니다.

소프트웨어의 보안이란?

• 현재의 소프트웨어 시스템은 GDPR(General Data Protection Regulations) 요구사항을 고려할 때 상당 부분이 민감한 정보일 수 있는 대량의 데이터를 관리한다.

• 사용자가 개인적이라고 생각하는 모든 정보는 소프트웨어 애플리케이션에서 민감한 정보가 된다. 민감한 정보에는 전화번호, 이메일 주소 또는 식별 변호와 같은 무해한 정보도 있지만 유출됐을 때 위험성이 높은 신용카드 정보 등의 정보는 더욱 중요하게 다뤄야 한다.

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

• 보안은 계층별로 적용해야 하며 각 계층에 다른 접근 방식이 필요하다.
• 이러한 각 계층은 성을 보호하는 일과 비교할 수 있다.
• 해커는 앱이 보호하는 리소스를 획득하기 위해 여러 장애물을 통과해야함
• 각 계층을 잘 보호할수록 악의적인 대상이 데이터에 접근하거나 무단 작업을 수행할 가능성이 낮아진다.

보안은 아주 복잡한 주제다..

• 소프트웨어 시스템에서 보안은 애플리케이션 수준에서만 적용되는 것이 아니다.
• 예를 들어 네트워킹의 경우 여러 문제를 고려하고 특정한 관행을 적용해야 하며 스토리지에도 완전히 다른 사항이 적용된다.
• 비슷하게 배포 등에 관한 다른 철학도 있다.
• 스프링 시큐리티는 애플리케이션 수준 보안에 속하는 프레임워크다.

애플리케이션 수준의 보안이란?

• 애플리케이션 수준 보안은 애플리케이션이 실행되는 환경과 애플리케이션이 처리하고 저장하는 데이터를 보호하기 위해 해야 하는 모든 것을 나타냄

• 한 계층의 보안 문제를 해결할 때 되도록 위 계층이 없다고 가정하는 것이 바람직하다.

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

1. 세션고정
1. 세션고정(Session Fixation) 취약성은 웹 애플리케이션의 더 구체적이고 심각한 약점이다. 이 취약성이 존재하면 공격자는 이미 생성된 세션 ID를 재이용해 유효한 사용자를 가정할 수 있게된다.
2. 이 취약성은 웹 애플리케이션이 인증 프로세스 중에 교유한 세션 ID를 할당하지 않아 기존 세션 ID가 재사용될 가능성이 있을 때 발생한다.
3. 이 취약성을 악용하려면 먼저 유효한 세션 ID를 획득한 후 의도한 피해자의 브라우저가 이를 이용하게 해야한다.

2. XSS(교차 사이트 스크립팅)
1. XSS는 서버에 노출된 웹 서비스로 클라이언트 쪽 스크립트를 주입해 다른 사용자가 이를 실행하도록 하는 공격이다.
2. 따라서 원치 않는 외리 스크립트의 실행을 방지하기 위해 이용하기 전이나 심지어 저장하기 전에도 요청을 적절하게 “소독”하는 과정이 필요하다.
3. 이 취약성이 악용되면 계정 가장(세션 고정과 결합)이나 DDos와 같은 분산 공격 참여 등의 결과가 발생할 수 있음

3. CSRF(사이트 간 요청 위조)
1. CSRF도 엡 애플리케이션에 흔한 취약성이다. CSRF 공격은 특정 서버에서 작업을 호출하는 URL 을 추출해 애플리케이션 외부에서 재사용 할 수 있다고 가정한다.
2. 서버가 요청의 출처를 확인하지 않고 무턱대고 실행하면 다른 모든곳에서 요청이 실행 될 수 있다.
3. CSRF를 통해 동작을 숨겨서 사용자가 서버에서 원치 않는 동작을 실행할 수 있도록 할 수 있다.

4. 웹 애플리케이션의 주입 취약성 이해
1. 주입 공격은 광범위한 공격 방식임.
2. 주입 공격에서 공격자는 시스템에 특정 데이터를 유입하는 취약성을 이용한다.
3. 공격의 목표는 시스템에 피해를 주고, 원치 않는 방법으로 데이터를 변경하거나 원래는 접근할 수 없는 데이터를 검색하는 것이다.
4. 대표적인 예로 XSS, SQL Injection, XPath Injection, OS 명령 주입, LDAP 주입 등이 있다.

5. 민감한 데이터 노출 처리하기
1. 기밀 데이터 공개는 복잡성 측면에서 가장 기초적이고 단순한 취약성 같지만, 여전히 흔한 실수 중 하나로 남아있음
2. 그 이유는 많은 온라인 자습서와 여러 서적에서 설명의 편의를 위해 구성 파일에서 직접 자격 증명을 정의하기 때문일 수 있다. 주제의 초점이 다른 곳에 맞춰져 있는 가상의 사례라면 이렇게 하는게 적절할 것이다.
3. 민감한 정보를 로그에 남기지 말고 예외 스택도 응답에 내보내지 않는게 좋다.
 

1.5 다양한 아키텍처에 적용된 보안

• 시스템의 디자인에 맞는 보안 관행을 적용하는 방법을 알아야 한다. 그 이유는 소프트웨어 아키텍처가 서로 다르면 가능한 유출과 취약성도 서로 다르기 때문이다.

• 아키텍처는 애플리케이션의 스프링 시큐리티 구성을 선택할 때 큰 영향을 미치며 기능적 요구 사항과 비기능적 요구사항도 마찬가지다. 현실 세계에서 무언가를 보호하려면 보호할 대상에 맞게 금속문이나 방탄유리, 또는 장애물 등을 사용한다.
• 하지만 모든 상황에서 금속문을 사용할 순 없다. 박물관에서는 귀중한 그림을 보호하면서도 관람객들이 그림을 볼 수 있게 할 방법이 필요하다. 하지만 그러면서 그림을 만지거나, 손상하거나 훔칠 수 없게 해야한다.

일체형 웹 애플리케이션 설계

• 웹 애플리케이션 시스템의 구성 요소를 개발하는 예부터 시작해보자. 이 애플리케이션에는 백엔드와 프론트엔드 개발 간의 직접적인 분리가 없다.

• 일반적으로 이러한 종류의 애플리케이션을 보는 방식은 애플리케이션이 HTTP 요청을 수신하고 HTTP 응답을 클라이언트에 보내는 일반 서블릿 흐름을 통하는 것이다.
• 때에 따라 각 클라이언트에 대해 더 많은 HTTP 요청을 통해 특정 세부 정보를 저장하기 위한 서버 쪽 세션이 있을 수 있다.

1. 클라이언트가 서버에 요청을한다.

2. 디스패처 서블릿이 요청을 수신한다.

3. 디스패처가 핸들러 매핑을 통해 url 경로에 따라 연결된 컨트롤러를 찾는다.

4. 컨트롤러를 찾으면 비즈니스 로직 작업이 수행된다.

5. 모델엔 뷰를 통해 뷰를 리턴하고 뷰리졸버를 통해 뷰를 리턴한다.