차이
문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판이전 판다음 판 | 이전 판다음 판양쪽 다음 판 | ||
guide:ajax_개발_보안_가이드 [2013/11/26 06:14] – 121.140.124.172 | guide:ajax_개발_보안_가이드 [2013/11/26 06:33] – 121.140.124.172 | ||
---|---|---|---|
줄 101: | 줄 101: | ||
</ | </ | ||
</ | </ | ||
+ | == (2) 보안 대책 == | ||
+ | XSS는 공격자들이 웹 어플리케이션에 몰래 침투하기 위해 이용하는 가장 일반적인 공격 중에 하나이다. XSS는 JavaScript를 통해 이루어지는 공격이므로 JavaScript로 구성된 Ajax에게 치명적인 공격이 될 수 있다. Ajax가 비동기 방식으로 웹 페이지를 불러오는 과정에서 악성 스크립트가 삽입된다면 Ajax의 특성상 사용자는 공격 당하고 있다는 사실을 모른 채 공격 코드가 사용자의 시스템에서 실행된다. 또한 Ajax는 한번 신뢰된 사이트는 지속적으로 신뢰를 하게 되기 때문에 방화벽 등을 우회할 수 있다는 것이 가장 큰 문제점이라 할 수 있다. | ||
+ | \\ | ||
+ | 결국 악의적인 사용자는 Ajax의 XSS 취약점을 가지고 여러 가지 방법으로 악성 스크립트를 삽입하여 임의의 사용자의 세션 및 쿠키, 패스워드, | ||
+ | \\ | ||
+ | - Server-Side에서 입력값 검증이 이루어져야 한다. | ||
+ | - 사용자 입력처리 모듈을 사용하여 비정상적인 악성 스크립트 삽입이 되지 않도록 필터링을 해야 한다. | ||
+ | - 사용자 계정 및 패스워드 타입\\ 사용자 인증 부분에는 SQL Injection 유형을 차단하기 위해 숫자, 영문 대/ | ||
+ | - 게시판 타입\\ 입력문자의 타입(영문 대/ | ||
+ | - 주민등록번호 타입\\ 주민등록번호를 입력 받기 위해 숫자형태의 6~7자리를 정의한다. | ||
+ | - 날짜타입\\ 사전에 정의된 날짜 형식을 사용하거나 날짜형식에 맞는 표현식을 작성한다. | ||
+ | - 숫자타입\\ 계좌이체의 경우 이체금액을 음수(-)로 입력할 경우 잔액계좌에는 오히려 금액만큼 증가될 수 있기 대문에 금액을 입력 받는 부분은 양수(+)만을 입력 해야한다. | ||
+ | - 기타 취약성 문자\\ < > \ ” | ||
+ | \\ | ||
+ | ^ From ^ To ^ | ||
+ | | < | < | | ||
+ | | > | > | | ||
+ | | ( | ( | | ||
+ | | ) | ) | | ||
+ | | # | # | | ||
+ | | & | & | | ||
+ | == Anti XSS Ajax == | ||
+ | XSS는 대부분의 웹 개발자들이 현재까지 여전히 고통 받는 문제점이라고 이야기한다. 검증 없이 사용자 입력 값을 출력하는 코드의 한 라인 한 라인의 모든 사용자 입력 값을 검증하는 게 힘들기 때문에, 한번 취약한 몇 개의 공격 메소드들을 웹 어플리케이션 사용자에게 적용 된다면 이 공격들은 방어 할 수 없을 정도로 위험할 수 있다. | ||
+ | \\ | ||
+ | 우리가 이미 알다시피, | ||
+ | \\ | ||
+ | - XSS 공격은 기본적으로 사용자 단에서 발생된다. | ||
+ | - XSS 공격은 보통 javaScript를 이용해서 발생된다. | ||
+ | \\ | ||
+ | 위의 두 관점을 살펴보면 우리는 서버 단에의 방어와 검증을 빠져 나오는 XSS공격을 멈추기 위해 클라이언트 단에서 이를 막아야 한다는 결론이 나온다. 이는 XSS공격이 < | ||
+ | \\ | ||
+ | 지금 당면한 진짜 과제는 어떻게 정상적인 javascript에서 공격자 javascript를 확인하는가 하는 것이다. | ||
+ |