보안 DBMS 조회 및 결과 검증 20220811

보안설계 기준 정의 및 설계시 고려사항

 

입력데이터 검증 및 표현

DBMS 조회 및 결과 검증

   보안 대책

-      애플리케이션에서 DB연결을 수행할 때 최소권한의 계정을 사용해랴 한다

-      외부 입력값이 삽입되는 SQL질의문을 동적으로 생성해서 실행하지 않도록 해야한다

-      외부 입력값을 이용해 동적으로 SQL질의문을 생성해야 하는 경우 입력값에 대한 검증을 수행한 뒤 사용해야 한다

 

    취약점 개요

      데이터 베이스(DB)와 연동된 웹 응용프로그램에서 입력된 데이터에 대한 유효성 검증을 하지 않을 경우 공격자가 입력 폼 및 URL

      입력란에 sQL 질의문을 삽입하여 DB로부터 정보를 열람하거나 조작할 수 있는 보안 취약점을 말한다

 

   설계 시 고려사항

-      애플리케이션에서 DB연결로 데이터를 처리하는 경우 최소 권한이 설정된 계정을 사용해야 한다

취약한 애플리케이션으로 인해 침해사고가 발생하더라도 나머지 부분에 대해 공격자가 접근 권한을 가지지 않도록 애플리케이션에서

DB연결을 위해 사용되는 계정은 해당 애플리케이녓이 사용하는 데이터에 대한 읽기 쓰기 삭제 업데이트 권한남 설정한다

 

-      외부 입력값이 삽임되는 SQL질의문을 동적으로 생성해서 실행하지 않도록 해야 한다

SQL 질의문의 구조가 외부 입력값에 의해 변경되지 않는 API를 사용하도록 시큐어코딩 규칙을 지정한다

ORM프레임워크를 사용하여 안전한 정적 쿼리 구조로 SQL문을 수행할 수 있도록 개발 환경을 설정하고 ORM프레임워크에서 제공하는 함수를

활용하여 외부입력값에 의해 SQL질의문의 구조가 변경되지 않도록 한다

 

-      외부 입력값을 이용해 동적으로 SQL질의문을 생성해야 하는 경우, 입력값에 대한 검증을 수행한 뒤 사용해야 한다

클라이언트와 서버 양측에서 입력값에 대해 안전한 값만 사용할 수 있도록 검증작업을 수행한다

 

(ㄱ) 필터를 이용한 입력 값 검증

외부입력값에서 SQL삽입이 가능한 문자열들을 필터링하여 안전한 값으로 치환하도록 하는 Filter컴포넌트를 생성하고 DB에서 관리하는

데이터를 처리하는 모든 애플리케션에 일괄 적용한다

(ㄴ) 인터셉터를 이용한 입력 값 검증

MVC프레임웨크를 사용하는 경우 Interceptor 컴포넌트를 사용하여 입력값에 대한 검증 작업을 수행한 뒤 차단하거나 허용하는 정책을

애플리케이션에 일괄 적용한다

(ㄷ) 라이브러리 또는 Validator컴포넌트를 이용한 입력값 검증

입력값을 검증하는 Validator 컴포넌트를 공통코드로 생성하고 모든 개발자가 SQL 질의문에 삽입되는 입력값에 대해 검증작업을 해당

컴포넌트에서 수행하도록 시큐어코딩 규칙을 정의

 

    XML 조회 및 결과 검증

     보안 대책

-      XML 문서를 조회하는 기능을 구현해야 하는 경우 XML질의문에 사용되는 파라미터는 반드시 XML 질의문을 조작할 수 없도록

필터링해서 사용하거나 미리 작성된 질의문에 입력 값을 자료형에 따라 바인딩해서 사용해야 한다

 

    취약점 개요

     XML 문서를 조회할 경우 입력값 조작으로 XQuery나 톔소와 같은 XML 질의문의 구조를 임의로 변경하여 허가되지 않은 데이터를 조회하거나 인증절차를 우회할 수 있다

 

    설계시 고려 사항

-      XML 문서를 조회하는 기능을 구현해야 하는 경우 XML질의문에 사용하는 파라미터는 반드시 XML질의문을 조작할 수 없도록 필터링해서 사용하거나

미리 작성된 질의문에 입력값을 자료형에 따라 바인팅해서 사용해야 한다

 

(ㄱ)  공통 검증 컴포넌트를 이용한 입력값 필터링

외부 입력값에서 XML삽입 공격이 가능한 문자열들을 필터링하는 Validator 컴포넌트르 개발하여 XML조회를 수행하는 애플르케이션 작성 시

입력값에 대한 검증 작업이 일괄 적용되도록 설계한다

(ㄴ)  필터 컴포넌트를 이용한 입력값 필터링

Filter컴포넌트에서 XML삽입 공격에 활용될 수 있느 입력값(“,[,],/,=,@)을 필터링하도록 작성하여 전체 요청 또는 XML 필터링이 요구되는 요청에 대해

프레임워크에서 일괄 적용하도록 설계한다

(ㄷ)  개별 코드에서 입력값 필터링 하도록 시큐어코딩 규칙 정의

각각의 컴포넌트에서 입력값에 대해 XML삽입을 발생시킬 수 있는 문자열(“,[,],/,=,@)을 제거 또는 안전하게 치환하여 사용할 수 있도록 시큐어코딩 규칙을 정의한다

(ㄹ)  안전한 API를 사용하도록 시큐어코딩 규칙 정의

XML 조회를 수행하는 질의문 작성 시 외부 입력값이 질의문의 구조를 바꿀 수 없는 API( java API – XQuery)를 사용하도록 시큐어코딩 규칙을 정의한다

 

   디렉토리 서비스 조회 및 결과 검증

      보안 대책

-      LDAP 인증서버로 인증을 구현하는 경우 인증요청을 위해 사용되는 외부입력값은 LDAP삽입 취약점을 가지지 않도록 필터일해서 사용해야 한다

 

취약점 개요

외부입력값이 LDAP 조회를 수행하기 위한 필터 생성에 사용되는 경우 필터 규칙을 변경할 수 있는 입력값에 대한 검증 작업을 수행하지 않게 되면 공격자가 의도하는 LDAP조회가 수행 될 수 있는 취약점

 

설계시 고려 사항

-      LDAP인증서버로 인증을 구현하는 경우 인증요청을 위해 사용되는 외부입력값은 LDAP삽입 취약점을 가지지 않도록 필터링해서 사용해야 한다

LDAP 인증이 포함되는 기능 설계시 외부 입력값이 LDAP 조회를 위한 검색 필터생성에 삽입되어 사용되는 경우, 필터 규칙으로 인식 가능한 특수문자

(=,+,<,>,$,;,\ 등)들을 제거하고 사용할 수 있도록 시큐어 코딩 규칙을 정의해야 한다

 

   시스템 자원 접근 및 명령어 수행 입력값 검증

      보안 대책

-      외부 입력값을 이용하여 시스템 자원(IP,PORT,프로세스,메모리 , 파일 등)을 식별하는 경우 허가되지 않은 자원이 사용되지 않도록 해야한다

-      서버 프로그램 안에서 쉘을 생성하여 명령어를 실행해야 하는 경우 외부 입력값에 의해 악의적인 명령어가 실행되지 않도록 해야한다

 

     취약점 개요

       경로조작 및 자원 삽입 : 공격자가 입력값 조작으로 시스템이 자원에 임의로 접근하여 자원의 수정,삭제, 시스템 정보누출, 시스템 자원 간 충돌로 인한

       서비스 장애 등을 유발시킬 수 있는 취약점이다 즉경로 조작 및 자원 삽입으로 공격자가 허용되지 않은 권한을 획득하여 설정에 관계된 파일을 변경하거나 실행 시킬수 있다

       입력값으 조작하여 허가되지 않은 명령 실행 : 적절한 검증절차를 거치지 않은 사용자 입력값에 의해 의도하지 않은 시스템 명령어가 실행되어 부적저하게 사용자권한이 변경

       되거나 시스템 동작 및 운영에 악영향을 미칠 수 있다

 

    설계 시 고려사항

-      외부입력값을 이용하여 시스템자원(IP,PORT,프로세스,메모리,파일 등)을 식별하는 경우 허가되지 않은 자원이 사용되지 않도록 해야 한다

외부입력값이 프로그램 내부에서 사용하는 리소스를 결정하는데 직접적으로 사용되지 않도록 설계한다

기능 설계 시 사용해야 하는 리소스 목록을 정의하여 지정된 범위 안에서 리소스를 선택하여 사용하도록 해야 하며 리소스 목록은 프로퍼티파일이나 XML 파일로

정의하여 리소스 정보를 변경하는 경우 프로그램 수정을 최소할 수 있도록 관리한다

사용자의 요청 리소스가 특정 디렉토리 내의 모든 파일인 경우 모든 파일명을 목록화하는 것은 어렵다 이런 경우는 입력값 중 경로조작을 일으킬 수 있는 문자(.. / \)를

제거하고 사용하여 지정된 경로 내의 파일만 접근 가능하도록 시큐어 코딩 규칙을 정의한다

-      서버 프로그램안에서 쉘을 생성하여 명령어를 실행해야 하는 경우 외부 입력값에 의해 악의적인 명령어가 실행되지 않도록 해야한다

먼저 서버프로그램 안에서 쉘을 생성해서 명령어가 실행되는 구조를 가지지 않도록 설계하는 것이 우선이다 하지만 경우에 따라 이러한 기능이 꼭 필요한 경우에는 외부

입력값이 직접적으로 명령어의 일부로 사용하지 않도록 해야한다

명령어의 일부로 사용되어야 하는 값들을 목록화하여 목록 내에 있는 값들로만 명령어가 조립되어 실행될 수 있도록 해야 하며 목록화되어 있는 값들이 경우에 따라 변경되어야 한다면 이로 인해 프로그램이 수행되지 않도록 프로퍼티파일이나 XML 파일을 사용하여 허용목록을 작성한다

이때 외부 입력값은 목록화된 정보를 검색하는 인덱스값으로 사용하여 시스템 명령어 사용을 최소화 한다

 

    웹 서비스 요청 및 결과 검증

      보안 대책

-      사용자로부터 입력 받은 값을 동적으로 생성되는 응답페이지에 사용하는 경우 크로스사이트스크립트(XSS)필터링을 수행한 뒤 사용해야 한다

-      DB조회결과를 동적으로 생성되는 응답페이지에 사용하는 경우 HTML인코딩 또는 크로스사이트스크립트(XSS)필터링을 수행한 뒤 사용해야 한다

 

      취약점 개요

         외부 입력값을 검증 없이 응답페이지생성에 사용하는 경우

          웹 페이지에 악의적인 스크립트가 포함될 수 있으며 해당 웹페이지를 열람하는 접속자의 권한으로 부적절한 스크립트가 실행되어 정보 유출등의 공격을 유발 할 수 있다

             Reflective XSS

            

 

            DB에 저장된 값을 검증 없이 응답페이지 생성에 사용하는 경우

              공격자가 미리 취약한 서버에 악의적인 스크립트가 포함된 정보를 저장해서 일반 사용자들이 해당 정보를 조회하는 경우

              접속자의 권한으로 부적절한 스크립트가 수행되어 정보 유출 등의 공격을 유발 할 수 있다

                 

 

     설계 시 고려 사항

-      사용자로부터 입력 받은 값을 동적으로 생성되는 응답페이지에 사용하는 경우 크로스사이트 스크립트(XSS)필터링을 수행한 뒤 사용해야 한다

입력값에 대해 필터링 또는 인코딩 정책을 적용하는 공통코드를 작성하여 웹 컨테이너 또는 MVC 프레임워크에 적용한다.

 

(ㄱ) 필터를 이용한 입력값 검증

웹 컴포넌트인 Filter를 사용하여 사용자의 입력값에 대해 XSS 필터나 HTML 인코딩을 적용하여 안전한 값으로 치환한 뒤 사용할 수 있도록 모든 애플리케이션에 일괄 적용한다

(ㄴ) 인터셉트를 이용한 입력값 검증

MVC 프레임워크를 사용하는 경우 Interceptor컴포넌트를 사용하여 사용자의 입력값에 대해 XSS 공격패턴의 문자열이 포함되었는지를 검사하여 요청을 차단 또는 허용하는 정책을 모든 애플리케이션에 일괄 적용한다

(ㄷ) 라이브러리 또는 Validator 컴포넌트를 작성하여 XSS 공격패턴의 사용자 입력값을 필터링할 수 있도록 설계한다

공통코드로 입력값을 검증하는 Validator 컴포넌트를 작성하여 XSS공격패턴의 사용자 입력값을 필터링 할 수 있도록 설계한다

 

-      DB조회결과를 동적으로 생성되는 응답페이지에 사용하는 경우 HTML 인코딩 또는 크로스 사이트스크립트(XSS)필터링을 수행한 뒤 사용해야 한다

각각의 컴포넌트에서 출력값에 대해 XSS필터 또는 HTML인코딩을 적용하여 안전한 값만 응답에 사용한다

 

(ㄱ) View 컴포넌트에서 출력값에 대해 HTML 인코딩 적용

View 컴포넌트에서 사용자 입력값을 동적으로 생성되는 응답페이지에 사용하는 경우 XSS필터 또는 HTML 인코딩을 적용하여 코드를 작성하도록 시큐어코딩

규칙을 정의한다

(ㄴ) DB조회 결과값에 대한 XSS필터 적용

DB조회 결과값으로 응답페이지를 생성하는 경우 XSS필터를 적용하여 사용해야 한다

DB에서 읽어오는 데이터도 외부 입력값의 범위에 포함시켜, 응답페이지에 출력하기 전에 받드시 검증 작업을 수행해야 한다

DB에서 읽어온 값에 대한 검증작업을 프레임워크의 컴포넌트로 일괄 필터링하는 것이 쉽지 않다 이 경우 각 개발자들은 출력값에 대해 검증 작업을 수행해야 하는데

이러한 설정은 개발가이드 구현단계에 항목을 작성하여 적용할 수 있도록 해야 한다

HTML URL 등의 문자를 인코딩 및 필터링하여 XSS 취약점을 최소화할 수 있도록 다음과 같은 라이브러리의 사용을 고려할 수 있다.

 

웹 기반 중요 기능 수행 요청 유효성 검증

     보안 대책

-      시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지 아닌지 여부를 판별할 수 있도록 해야 한다

 

설계 시 고려 사항

-      시스템으로 전송되는 모든 요청에 대해 정상적은 사용자의 유효한 요청인지, 아닌지 여부를 판별할 수 있도록 해야 한다

(ㄱ) CSRF 토큰 사용

웹은 URL 기반으로 요청을 처리하는 구조이다. 해당 요청이 특정사용자의 정상적인 요청인지를 구분하기 위한 정책이 적용되지 않는

경우 스크립트나 자동화된 도구에 의해 보내지는 요청이 검증 절차 없이 처리 될 수 있다.

그래서 해당 요청이 정상적인 사용자의 정상적인 절차에 의한 요청인지를 구분하기 위해 세션별로 CSRF 토큰을 생성하여 세션에 저장하고

사용자가 작업페이지를 요청할 때마다 hidden값으로 클라이어트에게 토큰을 전달한 뒤 해당 클라이언트의 데이터처리 요청 시 전달되는

CSRF 토큰값과 세션에 저장된 토큰값을 비교하여 유효성을 검사하도록 설계한다.

CSRF 토큰값에 대한 검사 방법은 MVC프레임워크의 컴포넌트를 이용하여 데이터 처리 요청 수신 시 자동으로 검사 될 수 있도록 설계하는 것이다

Spring이나 Structs와 같은 MVC 프레임워크의 경우 사용자의 요청을 중간에 가로채서 값의 유효성을 검사할 수 있는 Imterceptor 컴포넌트를 이용하여

파라미터로 전달된 CSRF 토큰값이 세션에 저장된 토큰값과 동일한지를 검사하여 동일한 경우에만 요청이 처리될 수 있도록 설계한다

(ㄴ) 사용자와 사오퍼리 기능 적용

CSRF토큰 방식도 XSS 취약점이 있는 사이트를 공격하게 되면 무력화될 수 있으므로 CAPTCHA(캠차)와 같은 사용자 상호처리 가능한 기법을 척용하여 위조된 요청이 차단될 수 있도록 설계

(ㄷ) 재인증 요구

중요기능의 경우 재인증으로 안전하게 실제 요청여부를 확인하도록 설계한다