2장. 웹 애플리케이션 보안

모든 애플리케이션은 이론적으로 유사한 보안 메커니즘을 사용함

 

핵심요소

1)사용자 접근처리: 민감한 정보에 대한 권한 없는 사용자의 접근 차단

2)사용자 입력 값 처리: 의도치 않은 행동을 유발

3)공격자에 대한 처리: 방어와 보안수준

4)애플리케이션 관리: 실시간 모니터링

 

 

1. 사용자 접근처리

애플리케이션 상 데이터나 기능에 대한 불법적 접근 통제

애플리케이션에는 다양한 사용자 범주가 존재 (ex. 익명사용자,관리적 사용자,인가된 사용자…)

--> 각 사용자 그룹이 속한 권한에 관해서만 접근을 허용해야 함

웹 애플리케이션 통제 메커니즘: 인증,세션관리,통제

 

A. 인증

• 사용자가 “나는 이런 사용자이다!” 라고 주장하는 사실을 확인

• 논리적으로 가장 독자적인 메커니즘

• 오늘날 대부분의 웹 애플리케이션은 ‘로그인 방식’을 사용
--> 더 높은 수준 (ex.은행 뱅킹): 기밀정보를 통한 인증절차, 다단계 로그인 프로세스, 클라이언트 인증, 스마트 카드, 시도 응답 토큰에 기반을 둔 인증모델

• 한계: 설계, 구현 측면에서의 문제점 존재, 공격자가 ID/PW 추측, 로직의 결함을 악용하여 인증 우회 가능

 

B. 세션관리

• 인가된 사용자의 세션을 효과적으로 관리
*세션: 서버에 할당 되어 있는 데이터 집합의 구조. 애플리케이션과 사용자 간 상호작용을 도움

 

• 애플리케이션은 인가된 or 익명의 사용자가 요청한 내용을 효과적으로 응답
--> 각 사용자를 위한 세션 생성 or 사용자에게 세션을 확인하게 하는 토큰 발행

*토큰: 애플리케이션이 세션에 나타내는 독특한 문자열

 

• 사용자를 식별하여 그 사람에게 맞는 응답을 제공해야 함
1) 각 사용자를 위한 세션 생성
2) 사용자에게 세션을 확인하게 하는 토큰 발행

 

• 사용자가 서버로부터 자신의 고유 토큰을 받음
--> 브라우저가 그 토큰을 다시 서버로 보

--> 토큰을 받은 사용자가 보내는 http요청에서 사용자 식별 서비스 제공

 

• http 요청을 처리하기 위한 방법: http쿠키, 히든필드, url쿼리

• 주어진 시간동안 사용자가 응답이 없을 시, 세션 만료

• 세션관리 메커니즘은 토큰에 대한 의존도가 매우 높으므로 공격자는 이 토큰을 집중 공격함
1) 토큰 생성단계 결함 à 다른 사용자에게 발행된 토큰 추측 가능
2) 토큰 처리단계 결함 à 다른 사용자에게 발행된 토큰 수집 가능

 

--> 이렇게 토큰을 공격하여 공격자가 피해자로 위장하거나 인증 받은 사용자인 것 처럼 앱을 사용

• 세션 토큰을 사용하지 않고 사용자 재확인을 하기도 함

--> http 인증 메커니즘: 브라우저가 각 요청에 사용자 자격 증명을 앱에게 재 전달, 애플리케이션은 전달된 요청에 따라 사용자를 식별

 

• 앱은 클라이언트 측에 상태정보를 저장, 암호화
*상태정보: cpu가 기계어 각 단계마다 현재 무엇을 하고 있는가를 외부로 알려주는 신호

 

C. 접근통제

애플리케이션에서 사용자의 요청이 허가되는지 결정을 내리고 실행

강력한 설계와 다양한 요소 고려가 필요
--> 사용자에 대한 식별을 통해 적절하게 수행되어야 함

 

 

 

2. 사용자 입력 값 처리

‘입력 값 검증’이 필수적으로 필요함. 사용자가 임의로 값을 입력하는 것은 위험하니까!

--> 사용자가 입력한 값이 안전한 상태로 처리되어야 함

 

A. 다양한 입력 값

• 사용자의 입력 값 형태는 매우 다양함 à 다양한 값에 대해서 올바르게 작동해야 함

• 사용자가 입력한 값이 안전한 상태로 처리되어야 함
--> 입력 값에 대한 규칙 필요! (ex. 길이제한, HTML태그 미포함 등)

• 어떤 경우에는 사용자의 입력 값을 그대로 받아들여 안전한 형태로 표시해주기도 함
--> 즉, 입력 값이 잠재적으로 위험해 보인다고 해서 입력을 거부 하는건 X (ex. 블로그에 해킹코드를 입력한다던지…)

 

• 이 때, 서버가 클라이언트에게 쿠키나 히든필드를 생성하여 전달
why? 외부에 노출시키기 않기 위해
BUT 공격자가 이를 수정해버릴 수 있음. à 따라서, 클라이언트에서 앱으로 전달될 때 데이터 검증이 필요함
(매개변수: 사용자 언어를 나타내고 있는 쿠키, 사용자 고유값-ex.ID)

 

• 서버 생성 데이터가 비정상적으로 변경되었다면 공격자가 앱의 취약점을 찾고 있다는 것.
따라서, 사용자 요청에 응답하지 말고 사후조사를 위해 요청을 기록해야 함

 

 

B. 입력 갑 조작에 대한 처리방법

• 입력 값 유형에 따라 or 여러 접근방법 조합

 

1) 위험하다고 알려진 것들 모두 차단
블랙리스트 활용
*블랙리스트: 공격에 사용된 잘 알려진 문자열 혹은 패턴
블랙리스트에 포함된다? à 차단!
하지만, 이 방법은 가장 1)우회가 가능하고 2) 새로운 취약점을 빠르게 갱신할 수 있으며 3) NULL 바이트 공격에 취약 하므로 비효율적인 방법임

* NULL 바이트 공격 *
NULL 바이트를 차단된 표현식 이전에 입력하면 해당 문장을 인식하지 X
NULL 바이트를 문자열 통제환경 차이에 따라 다르게 다루기 때문. 블랙리스트 기반의 필터를 무산시킴

 

 

2) 안전하다고 알려진 것들은 모두 수용
화이트리스트 활용
*화이트리스트: 올바른 입력 값의 전형
화이트리스트와 일치한다? à 허용! 
불일치한다? à 차단!
잠재적 악성 입력값을 제어하기에 가장 효과적, 효율적
BUT 적당한 기준이 없는 처리를 위해 데이터를 받아들여야 하는 상황도 있음 (ex. 사람 이름에 공격문자가 들어간 경우)

 

 

3) 불순물 제거
불안전한 문자를 안전한 상태로 바꿈 (제거하거나 인전문자만 남기는 등…)
불안전한 문자를 받아들여야만 하는 상황에서 사용
일반적 해결 방안으로 꼽히며 효율성이 매우 높음
BUT 입력 값의 한 부분이 위험성 있는 데이터가 포함되어야 하는 경우에선 효과적으로 이루어지기 힘듦 à 경계 값 검증

 

4)안전한 데이터 처리
데이터 자체를 안전하게 유지하는 것
일반적으로 알려진 문제를 피하면서 사용이 가능한 안전한 프로그래밍 메소드 존재
--> 그니까 위험한거 찾아서 차단하려 하지말고 애초에 안전하게 처리하자

 

5) 의미론적 검증
공격자가 입력한 악성값은 평버한 사용자도 충분히 악의 없이 입력 가능
따라서, 정상적인 사용자의 데이터인지 공격자의 데이터인지 의미적 유효성 검증 작업 (의미론적 검증)이 이루어져야 함

 

 

C. 경계 검증 (Boundary Validation)

• 입력값 인증은 악의적 데이터를 도착시점에서 걸러내고 그걸 신뢰 되는 앱에 넘기는 역할을 함
BUT, 데이터가 서버로 접근하는 동안의 안전을 보장하지는 못함 (걸러 내기만 한다는 거지)

• 입력값 검증은 매우 복잡한 메커니즘을 가질 수 밖에 없음

 

WHY?
1) 애플리케이션은 다양한 기능을 가짐 à 따라서, 조작의 범위도 매우 넓음
2) 입력 값은 여러 컴포넌트를 거치면서 변형되는데, 이 변동된 결과 값이 입력값과 유사하지 않기에 사용자의 입력값에 대한 모든 결과를 예측하기는 어려움
3) 입력값에 기반한 공격을 방어하는 것은 입력값에 여러 검증을 한다는 것인데, 이 검증의 방법이 각각 다르기에 동시에 모든 공격을 막는 것이 불가능함

 

* 경계 검증 *

•신뢰되는 경계의 각 부분, 사용자와 서버 간 외부경계에서 데이터 검증을 수행

•각 컴포넌트는 입력값을 잠재적 악성 소스로 가정

 

* 효용 *
1) 조작된 입력 값으로부터 자기 방어 (자기한테 위험한 건 자기가 막는다!)
2) 데이터가 어떤 값을 갖더라도 검증 수행 가능

3) 다양한 검증이 여러 단계에서 수행되기에 검증은 서로 충돌하지 않음

검증이 다음 앱 컴포넌트로 넘어가는 데이터를 포함하고 있다면, 관련 신뢰경계에서 비슷한 방어가 수행되어야 함

 

경계 검증

 

D. 다단계 검증과 정규화

• 입력값 핸들링 메커니즘에 문제가 있으면 검증 단계를 거치는 과정에서 데이터 조작 가능

• 애플리케이션이 검증 과정에서 사용자 입력 값을 일부 제거하고 암호화하려 할 때 발생
(ex. 앱: <script> 제거 / 공격자: <scr<script>ipt>로 우회) à 필터를 우회하기 위해 검증단계 악용!

 

• 데이터 정규화에서도 입력값이 인코딩 될 때 공격자가 검증 메커니즘을 우회하기 위한 인코딩을 할 수 있음
(ex. 앱: 입력값에서 작은 따옴표(“”)삭제 (SQL인젝션 방지) / 공격자: 이중 URL인코딩으로 필터 우회(?))

*데이터 정규화: 데이터를 일반적인 문자조합으로 변환하거나 디코딩하는 과정

 

•애플리케이션이 사용하는 구성요소가 한 문자 세트를 다른 문자로 변환할 때도 발생

 

--> 다단계 검증과 정규화가 지닌 문제에 대한 명확한 해결책은 X
불순물 제거법을 사용하여 입력값의 한 부분이라도 수정되지 않을 때 까지 재귀적으로 불안전한 문자를 안전하게 만들수는 있음
BUT, 이 과정이 문제의 소지가 있는 문자를 피하는 작업을 포함한다면 무한루프 초래

 

 

3. 공격자 핸들링

공격자가 공격을 실패하게 하기 위해 구현된 방법들:

1) 에러 핸들링 (error handling)

2) 감사로그 관리 (maintaining audit logs)

3) 관리자에게 경고 (alerting administrator)

4) 공격에의 대응 (reacting to attack)

 

A. 에러 핸들링

애플리케이션은 에러를 적절한 상태에서 제어,복구 하고 사용자에게 에러 메시지를 보여주는 주요 방어 메커니즘이 필요
여기서, 에러 메시지는 시스템 기반 메시지나 디버깅 정보를 노출시키는 것은 X
공격자는 에러메시지를 통해 정보를 얻기 위해 다양한 에러를 발생시킴. 특별한 정보가 없는 임의의 에러메시지 설정
효과적 에러 핸들링은 예상치 못한 에러에 대한 많은 디버깅 정보를 기록하는 앱 로깅 메커니즘처럼 사용되기도 함

 

B. 감사 로그 관리

앱 침해 시도 조사를 할 때 우선시 되어야 함

 

* 기록되어야 하는 주요 이벤트 *

1)인증 기능 관련 이벤트 (ex. 로그인-성공,실패/비밀번호 변경)

2)주요 거래 (ex. 신용카드 결제, 자금 이체)

3)막혀진 접근 시도

4)공격 문자열을 포함하는 악의적 의도가 명확한 요청

 

* 효과적인 감사로그는? *

1)무슨 일이 일어났는지?

2)어떤 취약점이 악용됐는지?

3)공격자가 비인가적 접근,행위를 수행했는지?

4)침투자 신분 증거 제공

 

• 각 이벤트의 발생시간,IP주소,세션 토큰,사용자 계정을 기록

• 효과적인 저장방법: 핵심 앱으로부터 업데이트 된 메시지만 받는 자율 시스템에 감사기록 저장

• 허술하게 보호된 감사로그는 공격자에게 정보를 제공하게 됨

 

C. 관리자에게 경고

• 공격에 대한 실시간 조치를 취하는 것이 바람직함. 추가공격 방지

* 경고 메커니즘 *
공격이 눈에 보이지 않는 하부단에서 진행되고 있는지 검사
관련된 이벤트들은 가능한 한번만 경고
서명과 비정상적 행위에 기반을 둔 규칙 사용

-감시되는 이벤트-

1)하나의 IP주소,사용자로부터의 비정상적으로 많은 요청

2)하나의 계좌에서 평소와 달리 많은 돈 인출

3)잘 알려진 공격 문자열 포함

4)일반 사용자들에게 숨겨진 데이터가 수정된 경우

 

• 앱 방화벽, 침입 탐지 제품에 기능 제공
BUT,  각 웹 애플리케이션이 다르므로 효율성은 제한적이고 사용되는 규칙은 일반적

• 방화벽은 뛰어난 성능을 가지지만 미묘한 공격에서 공격자의 요청은 정상 사용자의 입력과 동일한 것으로 간주됨

• 실시간으로 경고를 알리는 가장 효과적인 방법: 입력값 검증 메커니즘, 다른 제어들 수준 강화 è 보호 메커니즘
--> 사전에 공격을 검사해서 공격자들을 쉽게 공격 메커니즘에 걸리게 함

 

D. 공격에의 대응

• 공격자로부터 방어를 위한 내부 메커니즘

• 추가적 장애요인을 배치하여 공격자의 행동을 무력화 시킴
(ex. 공격자의 요청에 점차적으로 늦게 대응, 공격자의 세션 종료 후 다음 공격 공격으로 이어지기 전 로그인 수행을 거치게 함)

• 결함 요소 제거를 위한 노력은 악용 가능한 결점을 남길수도 있으므로 절대 유일한 해결 방법이 아님

 

 

4. 애플리케이션 관리

* 관리 매커니즘 *

• 말 그대로 앱 관리 하는거임

 

• 공격자가 다양한 권한을 얻을 수 있음

1) 관리자 권한 획득 가능

2) 높은 권한을 가진 새로운 사용자 계정 생성 가능

3) 사용자로부터 발생되는 데이터 표현 사항 기능
높은 권한을 가진 사용자 세션을 위협
(관리자 인터페이스 내 크로스사이트 스크립팅 취약점 존재)

4) 관리자 기능은 보안검사가 덜 엄격
전체 서버를 장악하기 위한 위험한 조작이 가능