현재 위치: WiKi Security Spirit » 보안 하드닝 가이드 » Ajax 보안 개발 가이드

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판이전 판
다음 판		이전 판
다음 판양쪽 다음 판
guide:ajax_개발_보안_가이드 [2013/11/26 06:29] – 121.140.124.172guide:ajax_개발_보안_가이드 [2013/11/26 07:11] – 121.140.124.172
줄 115: 줄 115:
     - 기타 취약성 문자\\ <  >  \  ”   ‘  (   ) &  등의 문자를 사용하는 경우 해당 문자를 다른 문자로 변경하는 것이 보안상 안전하다.     - 기타 취약성 문자\\ <  >  \  ”   ‘  (   ) &  등의 문자를 사용하는 경우 해당 문자를 다른 문자로 변경하는 것이 보안상 안전하다.
 \\ \\
-     ^ From ^ To ^ +^ From ^ To ^ 
-     |  <  | &lt; | +|  <  | &lt; | 
-     |  >  | &gt; | +|  >  | &gt; | 
-     |  (  | &#40; | +|  (  | &#40; | 
-     |  )  | &#41; | +|  )  | &#41; | 
-     |  #  | &#35; | +|  #  | &#35; | 
-     |  &  | &#38; |+|  &  | &#38; |
 == Anti XSS Ajax == == Anti XSS Ajax ==
 +XSS는 대부분의 웹 개발자들이 현재까지 여전히 고통 받는 문제점이라고 이야기한다. 검증 없이 사용자 입력 값을 출력하는 코드의 한 라인 한 라인의 모든 사용자 입력 값을 검증하는 게 힘들기 때문에, 한번 취약한 몇 개의 공격 메소드들을 웹 어플리케이션 사용자에게 적용 된다면 이 공격들은 방어 할 수 없을 정도로 위험할 수 있다.
 +\\
 +우리가 이미 알다시피, 완전한 코드는 현실세계에 존재하지 않으며 몇몇 버그들은 방어 없이 검사 구문을 빠져나간다. 특히 코드 검사자가 보안 마인드 없이 검사를 수행한다면, 몇 번의 검사를 반복해서 수행 하더라도 웹 어플리케이션을 XSS 공격에 취약할 것이다. 실제 환경에서 제품에 XSS취약점이 나타난 경우,XSS 공격을 피하는 위험 완화 계획에 대한 해답을 얻기위해서는 다음에 대해 생각해 보아야 한다.
 +\\
 +  - XSS 공격은 기본적으로 사용자 단에서 발생된다.
 +  - XSS 공격은 보통 javaScript를 이용해서 발생된다.
 +\\
 +위의 두 관점을 살펴보면 우리는 서버 단에의 방어와 검증을 빠져 나오는 XSS공격을 멈추기 위해 클라이언트 단에서 이를 막아야 한다는 결론이 나온다. 이는 XSS공격이 <script>를 사용하는 javascript에 기본을 두고 있으므로, 지금 이런XSS공격을 막기 위해서 넘겨지는 HTML을 서버 단에서 필터 하는 JavaScript를 사용한다. 이는 공격자 Javascript를 확인하고 사용자와 관리자에게 공격을 알리는 기능을 한다.
 +\\
 +지금 당면한 진짜 과제는 어떻게 정상적인 javascript에서 공격자 javascript를 확인하는가 하는 것이다.  우리는 정상적인 javascript 어떤 시그니쳐 같은 것을 적용하여 웹 페이지에 삽입된 악의적인 javascript인지 확인할 수 있고, 다른 javascript를 사용해 공격자의 비정상적인 javascript인지를 확인해 페이지 내용을 필터 할 수 있을 것이다. 다음은 클라이언트 단에서 비정상적인 javascript가 발견되었을 때 비정상 적인 행동을 유발할 수 있는 javascript의 예이다.
 +\\

추적: