[SK shieldus Rookies 19기][애플리케이션 보안] - 애플리케이션 보안 1

1. 애플리케이션 보안

 

웹 애플리케이션에서는 클라이언트, Web 서버, WAS 서버, DB 서버가 있다.

 

클라이언트가 웹에 요청할 때 static한 데이터는 웹에서 실행하고, dynamic한 데이터는 WAS 서버 관련된 데이터를 DB 서버에서 조회해서 그에 맞는 응답을 전달한다.  

이때, 클라이언트에서 오는 데이터가 안전한지 아닌지를 판단해야 하고, 그 판단이 안전하지 않다고 판단되는 것들은 더 이상 내부로 진입할 수 없도록 하는 기법들이 나온다. 

 

기법 중 가장 앞에 나오는 것은 방화벽인데 방화벽은 특정 IP나 특정 Port로의 진입과 진출을 제어하는 데 사용한다.

Web 서버에 접근할 때 80 포트를 사용할 때, 80 포트로만 접근해야 하는데, 80 포트가 아닌 허용하지 않는 포트로 접근한다는 것은 정상적이지 않은 작업을 한다는 것이라고 할 수 있다. IP 주소와 포트 번호가 들어오고 나가는 것을 제어하는 것을 방화벽이 한다.

 

방화벽만으로 모든 것을 막을 수 있을까?

만약 동적인 데이터가 들어와서 DB 서버에 쿼리를 전달해 데이터를 받아와야 할 때 방화벽은 동적인 데이터나 쿼리문에 대해 제어하지 않고 서버 주소가 맞고 서비스 포트가 맞으면 통과한다.

동적인 매개변수에 올 수 없는 값들이 포함되는 것을 방화벽은 모른다. 이를 확인할 수 있는 것이 WAF(웹 애플리케이션 방화벽)라고 한다.

 

WAF는 웹으로 넘어오는 매개변수들의 패턴을 추출해서 검증해 서버로 들어가지 못하도록 막아주는 역할을 한다.

기존 방화벽의 한계를 보완해 준다.

 

방화벽과 WAF는 네트워크 단에서 H/W 기반으로 방어하는 것이다. 

이 두 가지를 사용해서 100% 막을 수 있을까? 100%로 막기는 어렵다. 

 

방호벽, IDS/IPS, 웹 방화벽에서의 침해사고 발생빈도는 크게 높지 않다. 최근 침해사고는 서버 구간에서 제일 많이 나온다. 잘못 만들어진 애플리케이션의 취약점으로 인해 보안 사고가 발생하는데 최근 조사에 따르면 이곳에서 보안사고 92%가 생긴다고 한다.

이러한 보안 사고를 막기 위해서는 시큐어 코딩해야 한다. 가이드라인을 확인하고 그것에 맞게 시큐어 코딩해야 한다.

 

사전점검을 통해 SW 개발 보안이 이루어지면 취약점 조치 비용이 절약된다. 설계단계 대비 최대 30배의 취약점 수정 비용 절약할 수 있다.

 

 

1) 가이드라인

가이드라인 페이지

 

가이드라인은 종류별로 있으니 필요한 것을 찾아 확인 후 가이드라인에 맞게 개발해야 보안 사고가 줄어든다.

 

2) 안전한 SW 개발

소스코드 등에 존재할 수 있는 잠재적인 보안 약점을 제거하고, 보안을 고려하여 기능을 설계 구현하는 등
SW 개발 과정에서 실행되는 일련의 보안 활동을 수행해야 한다.

 

시큐어 코딩과 SW 개발 보안 활동을 해야 한다.

 

• 애플리케이션의 문제점 도출
  • 정적 분석과 동적 분석은 상호 보완적 관계로 항상 함께 적용해야 함
• 정적 분석
  • 애플리케이션을 실행하지 않고 소스 코드의 내용, 형태, 구문 등을 분석해서 문제가 있는지 확인
  • 코드 리뷰
• 동적 분석
  • 애플리케이션을 실행해서 원하는(계획한) 결과가 제공되는지를 확인
  • 디버깅, 부하 테스트, 모의해킹, 침투 테스트
  • 인증 및 인가와 같이 정적 분석으로 파악이 힘든 경우 수행

 

3) 소프트웨어 보안 약점

소프트웨어 보안 약점

 

 

2. HTTP

1) 특징

• HTTP는 단순
• HTTP는 확장 가능
• HTTP 이전 요청과 현재 요청 사이의 관계를 유지하지 않지만, 세션을 사용하여 클라이언트 상태를 유지
  • 성공적으로 완료된 두 개의 요청 사이에는 연결고리가 없음
  • 헤더 확장성을 사용하여, 동일한 컨텍스트, 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 쿠키를 추가
• HTTP 연결
  • HTTP/1.0 : 요청/응답 교환에 대한 각각의 TCP 연결을 생성, 비연결성만 지원
  • HTTP/1.1 : 파이프라이닝 개념과 지속적인 연결의 개념 도입, 멀티플렉싱 등 지원
  • HTTP/1.2 : 단일 연결을 통해 메시지 다중화, 더욱 효율적인 연결 관리, 헤더 압축 등 지원 

 

2) 흐름

연결, 요청, 응답, 연결 해제

 

HTTP 흐름

 

 

3) 요청

• 웹 브라우저가 웹 서버에게 자원을 요청
• 시작줄, 요청 헤더, 요청 본문으로 구성
• 시작줄은 "요청 방식(method) + URI(URL) + 프로토콜 버전"으로 구성
• 요청 헤더와 요청 본문 사이에는 1개의 빈 공백 라인이 존재
  • 이것을 통한 공격기법이 있기 때문에 중요한 특징이다.

 

HTTP 요청

 

 

4) 응답

• 웹 브라우저의 요청에 대한 처리 결과 전달
• 시작줄, 응답 헤더, 응답 본문으로 구성
• 시작줄은 "프로토콜 버전 + 상태 코드 + 상태 메시지"로 구성
• 응답 헤더, 응답 본문을 구분하는 기준은 1개의 공백 라인
• 응답 헤더는 브라우저에 서버가 전달해 주는 부가적인 정보
• 응답 본문은 내가 요청한 실질적인 데이터

 

HTTP 응답

 

 

5) 요청 메서드

(1) GET

• 웹 서버로 자원을 요청할 때 사용(default)
• 요청 파라미터를 URL에 포함해서 전달하는 방식
• 전송할 수 있는 데이터의 크기가 제한(지금은 거의 무한대)
• 북마크가 필요한 경우에 사용

 

GET  메서드

 

 

(2) POST 메서드

• 웹 서버로 자원을 요청할 때 사용
• 요청 파라미터를 요청 본문에 포함해서 전달하는 방식
• 전송할 수 있는 데이터의 크기 제한이 없음(시간제한 개념)

 

POST 메서드