Security 기본 개념 - basic

2 minute read

SQL Injention

SQL 인젝션은 데이터베이스 명령어인 SQL 쿼리문에 기반하여 공격을 수행한다. 공격에 이용되는 쿼리문은 문법적으로는 지극히 정상적인 SQL 구문이다. 다만 실행되지 말아야 할 쿼리문이 실행되어 공격에 이용되는 것이다.

SQL 인젝션은 최소한 다음의 조건을 충족해야 공격이 가능하다.

조건 1) 웹 애플리케이션이 DB와 연동하고 있다.

조건 2) 외부 입력값이 DB 쿼리문으로 사용된다.

웹 애플리케이션이 위 두 조건 중, 하나라도 충족하지 않는다면 SQL 인젝션 공격은 무용지물이 될 것이다. 그러나 현재의 대부분 웹 애플리케이션은 위 두가지 조건을 대부분 충족한다. 그래서 대부분의 경우 SQL 인젝션은 유효한 공격 기법이 될 것이다.

입력값 유효성 검사
- 정규표현식을 사용한 방법 ⬇️ 에 있는 방법들
시큐어 코딩
- 블랙 리스트 : 사용하면 안되는 명령어를 다른 식으로 대치
- 화이트 리스트 : 가능한 명령어만을 리스트로 관리해서 사용
오류 메시지 출력 제한
- DB에서 에러가 나는 것을 보고 공격자는 DB의 상태를 확인할 수 있다.
- DB 오류를 제한적으로 출력하기 위해 커스텀된 오류 페이지를 제공한다.
- 추상화된 안내 메지시 → 로그인 실패시에 어떤 부분이 틀렸는지 알려주지 않는다.
DB 보안
- DB 계정 분리: 관리자 계정과 웹 어플리케이션 계정 분리하여 공격당하더라도 그나마 피해를 줄인다.
- 계정의 꼭 필요한 권한만을 제공해준다.
- 쿼리를 사용하는 계정마다 권한을 제한. → select 계정에서 update 못하게

JPA 같은 경우는 그 값을 그대로 사용하기 보다는 value로 단위로 생각을 해서 문제가 되지 않음.
- JAP native query에서도 내부적으로 preparedStatement처럼 동작하여 injection이 아니라 value로 값이 들어가게됨.
이유: PreparedStatement를 사용하는 경우 파라미터로 들어가는 값을 바인딩하여 사용한다. 바인딩데이터는 SQL문법이 아닌 컴파일언어로 처리하기 때문에 문법적 의미를 가질 수 없으므로, 바인딩 변수에 SQL injection query를 넣더라도 의미있는 쿼리로 동작하지 않는다.

외부 입력값이 충분한 검증 없이 동적으로 생성되는 응답 페이지에 사용 되는 경우 해당 페이지를 사용하는 다른 클라이언트들이 공격자로 부터 공격 받을 수 있다.

XSS 취약점은 공격 유형에 따라 Reflective XSS, Stored XSS, DOM XSS로 구분가능하다.

Reflective XSS : 공격자가 악성 스크립트가 포함된 URL을 클라이언트에 노출시키게 하여 클릭을 유도하여 정보탈취, 피싱사이트 리다이렉트 등의 공격을 함.
Stored XSS : 악성 스크립트를 DB에 저장해 해당 DB정보를 이용하는 애플리케이션을 통해 시스템을 사용하는 모든 사용자들이 해당 스크립트를 실행하게함.
DOM XSS : AJAX프로그램에서 사용되는 자바스크립트를 이용해 브라우저에 수신된 데이터를 다시 잘라내서 Document에 write하는 작업을 수행할 경우 XSS 공격이 가능하게 한다.

입/출력 값에 대해 필터링 적용
Black list 방식 : 간단함. 모든 방어에 대해 준비가 불가능함.
White list 방식 : 지속적으로 list를 추가해줘야함. 강력함.
오픈소스 라이브러리 사용 : 네이버 개발자 그룹에서 개발한 자바기반의 lucy-xss Filter(바로가기)을 사용하여 Spring boot MVC의 Controller 컴포넌트에 적용 가능. 화이트리스트 정책 사용

인터넷 서비스에서 인증(Authentication)과 권한(Authorization) 관리를 철저히 해야하는건 당연지사이다. 인증이나 세션 관리와 관련된 애플리케이션의 기능이 올바르게 구현되지 않은 경우 공격자는 쉽게 다른 사용자로 가장할 수 있다.