it-swarm-korea.com

AJAX 근본적으로 안전하지 않습니까?

가능한 중복 :
Ajax를 안전하게하는 방법?

내 직장에서 많은 사람들은 AJAX가 근본적으로 안전하지 않다고 생각합니다. AJAX이 (가) 다른 페이지로드와 똑같이 안전하다는 인상을 받았습니다. 이는 호출/페이지를 코딩하는 방법에 따라 다릅니다.

AJAX에 근본적인 보안 결함이 있습니까? XML 또는 JSON에 관계없이 AJAX 클래스의 공격 영역은 표준 동기 웹 응용 프로그램과 어떻게 다릅니 까?

16
C. Ross

짧은 대답 : 맞습니다. 페이지를 코딩하는 방법에 따라 다릅니다.

조금 더 긴 답변 :
AJAX에 대해 본질적으로 안전하지 않은 것은 없습니다. 대부분의 경우 AJAX는 일반 웹 페이지와 동일한 위협 및 공격에 취약합니다.
그러나 AJAX 전용 공격도 몇 가지 있지만 코드 작성 방법에 따라 다릅니다. 하지만 그렇다고 "fundamentally insecure".

그러나 종종 다른 미묘한 문제가 발생합니다. (대부분의) 프로그래머는 결국 웹 페이지 또는 브라우저와 서버 간의 통신에서 "숨겨진"항목이 사용자로부터 보호되지 않는다는 사실을 알게되었습니다. grokking이 주류로 가기에는 너무 길다)) AJAX 호출은 어떻게 든 "특별한"것입니다. 따라서 종종 오용 될 것입니다 ... 예를 들어, 여전히 모든 일반 페이지에서 SSL을 사용하는 많은 사이트를 볼 수 있지만 실제 민감한 데이터는 암호화되지 않은 HTTP를 통해 AJAX)를 통해 자유롭게 흐릅니다.

요컨대, cowirkers의 의견도 어느 정도 잘못되었습니다-AJAX 어떻게 든 "특별"할 것으로 기대합니다.

8
AviD

대답은 보호하려는 자산과 위협 모델에 따라 다릅니다.

사용자가 웹 페이지 내용 을 공격하고 AJAX 코드를 발견하고 무언가를 발견하는 것에 대해 걱정하는 경우 사용자가 알고 싶지 않은 페이지 인 경우, 사용자가 웹 페이지가 실행되는 환경에 물리적으로 액세스 할 수 있기 때문에 AJAX은 안전하지 않은 것이 사실입니다.이 예는 페이지가 게임 인터페이스를 구현하고 다른 플레이어의 위치에 대한 정보를 포함하는 경우, 사용자는 모든 것을 알아 내고 "벽을 통해 본다"는 속임수를 쓸 수 있습니다.

반면에 사용자가 서버를 공격하는 것에 대해 걱정하는 경우 사용자가 웹 페이지 및 관련 코드에서 모든 것을 수정할 수 있다고 가정하면, 사용자는 이러한 상황에서 사용자가 할 수있는 일로부터 서버를 보호하기 위해 적절한 예방 조치를 취합니다. 다른 사람들이 언급 한 것처럼 AJAX 다른 우수한 프로그래밍 기술과 마찬가지로 안전하며 주로 서버 측 코드, 항상 그렇듯이 Update : 그러나 그렇게하는 것은 까다로울 수 있으며, @iivel이 지적했듯이 OWASP 페이지는 다양한 것을 설명합니다. 주의해야 할 것은 : AJAX 취약점 (OWASP-AJ-001)

이것은 모두 Flash 또는 Java 애플릿 또는 Silverlight 등)과 같은 다른 클라이언트 측 기술에 적용됩니다. 대체로 Word 또는 PDF- 사람들의 눈에 띄지 않거나 기억하지 못하는 내용 (예 : 소프트웨어의 작성자 또는 소유자에 대한 메타 정보 또는 디지털 화이트 아웃으로 오버레이하여 "삭제 된"내용) 자동으로 포함되면 정통한 사용자가 비트를 볼 때 슬프게도 실망 할 것입니다.

위협 모델과 도구가 문제를 해결하는지 여부를 신중하게 생각하는 것이 매우 중요합니다.

10
nealmcb

AJAX는 "코드가 포함 된 웹 페이지"를 의미합니다. 일반 페이지에도 스크립팅 요소가있을 수 있으므로 AJAX와 "정상"페이지 사이에는 명확한 구분이 없습니다. AJAX 응용 프로그램의 일부를 클라이언트 브라우저에 푸시하려고합니다.

웹 기반 응용 프로그램은 서버와 클라이언트의 통합을 통해 실행됩니다. 클라이언트가 서버가 보낸 페이지를 표시하는 것보다 조금 더 많은 일을하도록 유혹하고 있습니다.

  • 인터페이스 반응성이 향상됩니다 (사용자 경험이 향상됨).
  • 네트워크로드를 줄일 수 있습니다 (서버와 통신하지 않고도 클라이언트에서 GUI 기반 작업을 수행 할 수 있음).
  • 컴퓨팅로드를 줄일 수 있습니다 (클라이언트 시스템의 경우 더 많은 작업, 서버의 경우 더 적은 작업).

온라인 게임과 유사하게 만들 수 있습니다. FPS 게임. 여러 사용자가 서로를 촬영합니다. 서버는 모든 사람의 위치와 누가 사람을 죽이는 지 추적합니다. 이러한 게임의 경우 인터페이스 반응성이 가장 중요합니다. 따라서 서버가 모든 것을 계산하고 클라이언트에게 표시 할 프레임을 보내는 것은 완전히 상상할 수없는 일입니다. 대신 클라이언트는 무거운 3D 렌더링 작업을 수행해야하며 서버는 단순히 레벨 맵과 플레이어 위치 업데이트를 보냅니다.

그 시점에서 기본 규칙으로 인해 보안이 작동합니다.

  • 서버 관점에서 볼 때 클라이언트는 악당입니다.

게임 비유에서 이것은 서버가 클라이언트 코드를 신뢰해야한다는 것을 의미합니다. 3D 렌더링의 경우 클라이언트는 레벨 맵과 다른 모든 플레이어의 위치를 ​​알아야합니다. 수정 된 클라이언트는 맵을 플레이어에게 표시하고 다른 플레이어를 정확하게 찾아내는 것이 쉬울 것입니다. 실제로, 많은 사기꾼이 있으며, 게임 엔진은 정교한 코드 난독 화 기술을 사용하여 사기꾼의 대다수를 저지하려고합니다 (사기꾼이 재미를 죽이고 플레이어가 떠나는 재미없이).

이것은 AJAX 보안 : 클라이언트 측에서 실행되는 코드이므로, 사용자가 정식으로 인증 된 경우에도 서버가 신뢰할 수없는 것은 무엇이든간에who 자동으로 합법적이지는 않습니다.) 이것은 게임 관련 비유의 "레벨 맵 디스플레이"기능과 같은 GUI에 대한 보안 문제가없는 한 GUI 관련 상호 작용에는 문제가되지 않습니다. 웹 기반 응용 프로그램의 보안을 분석하는 올바른 방법은 서버가 방출하는 모든 단일 바이트를 클라이언트라고하며 클라이언트의 모든 바이트가 잠재적으로 악의적이라고 가정하는 것입니다.

대략적인 예로서 SQL 삽입을 고려하십시오. SQL 삽입 공격을 피하는 한 가지 방법은 요청에 연결하는 데이터 요소에 이스케이프되지 않은 특수 문자가 없는지 확인하는 것입니다. 이 유효성 검사 단계 필수 는 서버에서 수행해야합니다. 클라이언트가 AJAX을 우회 할 수 있기 때문에) AJAX에서는이를 안전하게 수행 할 수 없습니다.

9
Thomas Pornin

OWASP는이 주제에 관한 좋은 기사를 가지고 있습니다. AJAX 더 넓은 공격 영역이되고 AJAX 응용 프로그램 (JSON 해킹 또는 클라이언트 이벤트 해킹))에서만 현실적으로 가능한 일부 공격과 관련된 주요 문제 .

AJAX 취약점 (OWASP-AJ-001) )에 대한 테스트
http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html

응용 프로그램의 비동기 특성과 필요한 서비스로 인해 더 많은 영역이 공격을 받기 쉽습니다. 데이터 구조 및 이벤트 방법 자체는 일반적으로 포스트에서 왕복하는 것보다 공격에 더 취약합니다.

4
iivel