javascript - 왜 구글은(1) 동안 prepend합니까; JSON 응답에




ajax security (4)

왜 구글 while(1); prepend합니까 while(1); (비공개) JSON 응답에?

예를 들어, Google 캘린더 에서 캘린더를 켜거나 끄는 동안의 반응은 다음과 같습니다.

while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
  ['remindOnRespondedEventsOnly','true'],
  ['hideInvitations_remindOnRespondedEventsOnly','false_true'],
  ['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]

나는 이것이 사람들이 eval() 을 수행하는 것을 막을 것이라고 가정 할 것이지만, 정말로해야 할 일은 while 교체 한 다음에 설정하는 것이다. 평가판은 사람들이 안전한 JSON 구문 분석 코드를 작성하도록하는 것이라고 가정합니다.

이상한 점도 있지만, Google 문서 도구&&&START&&& 로 시작하고 Google 연락처는 시작되는 것처럼 보입니다. (메일, 캘린더, 주소록 등) while(1); &&&START&&& while(1); &&&START&&& .

무슨 일 이니?


JSON 하이재킹을 통해 응답이 공개되지 않도록합니다.

이론적으로 HTTP 응답의 내용은 동일한 출처 정책에 의해 보호됩니다. 한 도메인의 페이지는 명시 적으로 허용되지 않는 한 다른 도메인의 페이지에서 정보를 얻을 수 없습니다.

공격자는 사용자를 대신하여 <script src=...> 또는 <img> 태그를 사용하여 다른 도메인의 페이지를 요청할 수 있지만 결과 (헤더, 내용)에 대한 정보는 얻을 수 없습니다.

따라서 침입자의 페이지를 방문하면 gmail.com에서 귀하의 이메일을 읽을 수 없습니다.

JSON 콘텐츠를 요청하기 위해 스크립트 태그를 사용하는 경우를 제외하고 JSON은 공격자가 제어하는 ​​환경에서 Javascript로 실행됩니다. 공격자가 Array 또는 Object 생성자 또는 객체 생성 중에 사용 된 다른 메소드를 대체 할 수있는 경우 JSON의 모든 내용이 공격자의 코드를 통과하여 공개됩니다.

이것은 JSON이 파싱 될 때가 아니라 Javascript로 실행될 때 발생합니다.

여러 가지 대응책이 있습니다.

JSON이 실행되지 않도록하기

while(1); 놓음으로써 while(1); JSON 데이터 앞에 JSON 데이터가 없다면 Google은 JSON 데이터가 자바 스크립트로 실행되지 않도록합니다.

합법적 인 페이지 만 실제로 전체 내용을 가져올 수 있으며 while(1); 제거합니다 while(1); 나머지를 JSON으로 구문 분석합니다.

for(;;); 와 같은 것들 for(;;); 예를 들어 페이스 북에서도 동일한 결과가 나타났습니다.

JSON이 유효한 Javascript가 아닌지 확인하기

마찬가지로 &&&START&&& 와 같이 유효하지 않은 토큰을 JSON 앞에 추가하면 절대 실행되지 않습니다.

바깥쪽에 Object가있는 JSON을 항상 반환하십시오.

이것은 JSON 하이재킹으로부터 보호하기 위해 OWASP 권장 방법 이며 덜 관입적 인 방법입니다.

이전의 대응책과 마찬가지로 JSON이 자바 스크립트로 실행되지 않도록합니다.

유효한 JSON 객체가 Javascript에서는 유효하지 않습니다.

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

그러나 이것은 유효한 JSON입니다.

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

따라서 응답의 최상위 레벨에서 항상 Object를 반환하도록 설정하면 유효한 JSON 인 반면 JSON이 유효한 자바 스크립트가 아닌지 확인합니다.

주석에서 @hvd가 지적한 것처럼 빈 객체 {} 는 유효한 자바 스크립트이며 객체가 비어 있다는 것을 아는 것이 그 자체로 가치있는 정보가 될 수 있습니다.

위 방법의 비교

OWASP 방식은 클라이언트 라이브러리를 변경할 필요가 없으며 유효한 JSON을 전송하기 때문에 방해가 적습니다. 그러나 과거 또는 미래의 브라우저 버그가 이것을 물리 칠 수 있는지 여부는 확실하지 않습니다. @oriadam이 지적한 것처럼, 오류 처리를 통해 구문 분석 오류에서 데이터가 유출 될 수 있는지 여부는 명확하지 않습니다 (예 : window.onerror).

Google의 방식은 자동 직렬 제거를 지원하기 위해 클라이언트 라이브러리가 필요하며 브라우저 버그와 관련하여 더 안전하다고 간주 될 수 있습니다.

두 가지 방법 모두 개발자가 실수로 취약한 JSON을 보내는 것을 방지하기 위해 서버 측 변경이 필요합니다.


간단한 <script> 태그의 대상으로 사용되지 못하게합니다. (나쁜 것은 아닙니다.) 그런 식으로 악의적 인 사람들은 스크립트 태그를 자신의 사이트에 넣고 활성 세션에 의존하여 콘텐츠를 가져올 수 없습니다.

편집 - 주석 (및 기타 답변)을 기록하십시오. 이 문제는 전복 된 내장 시설, 특히 ObjectArray 생성자와 관련이 있습니다. JSON을 무의미하게 처리하면 구문 분석시 공격자 코드가 트리거 될 수 있습니다.


제 3자가 <script> 태그를 사용하여 JSON 응답을 HTML 문서에 삽입하는 것을 어렵게 만드는 것입니다. <script> 태그는 동일한 출처 정책 에서 면제됨을 기억하십시오.


2011 년부터 모든 주요 브라우저에서 EMCA5를 사용하여 정식으로 해결 된 JSON 하이재킹 을 막을 수 있습니다.

복잡한 예 : Google에 mail.google.com/json?action=inbox 와 같은 URL이 있습니다.이 URL은받은 편지함의 처음 50 개 메시지를 JSON 형식으로 반환합니다. 다른 도메인의 악의적 인 웹 사이트는 AJAX가 같은 출처 정책으로 인해이 데이터를 가져올 수 없지만 <script> 태그를 통해 URL을 포함 할 수 있습니다. 쿠키로 URL을 방문 하고 전역 배열 생성자 또는 접근 자 메서드재정 의하여 개체 (배열 또는 해시) 특성이 설정 될 때마다 호출되는 메서드를 통해 JSON 내용을 읽을 수 있습니다.

while(1); 또는 &&&BLAH&&& 는 이것을 방지합니다. mail.google.com 의 AJAX 요청은 텍스트 콘텐츠에 대한 완전한 액세스 권한을 가지며이를 제거 할 수 있습니다. 그러나 <script> 태그 삽입은 맹목적으로 처리없이 JavaScript를 실행하므로 무한 루프 또는 구문 오류가 발생합니다.

이것은 사이트 간 요청 위조 문제를 해결하지 못합니다.





security