교차 도메인 Ajax가 보안 문제가 되는 이유는 무엇입니까?
XML 콜의 실행에 XMLHTTPRequest를 사용하는 것이 도메인 경계를 넘어 콜을 실행해서는 안 된다고 결정한 이유는 무엇입니까?JavaScript, 이미지, CSS, iframe 및 다른 도메인에서 생각할 수 있는 거의 모든 콘텐츠를 검색할 수 있습니다.Ajax HTTP 요청이 도메인 경계를 넘을 수 없는 이유는 무엇입니까?다른 사람이 Javascript를 페이지에 삽입하는 것 이외에는 사용할 수 없는 것을 생각하면, 이상한 제한이라고 생각합니다.단, 이 경우 문서에 img, 스크립트 또는 iframe 요소를 추가하여 서드파티 URL을 요청하고 서버로 전송할 수 있습니다.
[편집]
일부 답변은 다음과 같은 이유를 제시합니다. 이를 허용하지 않는 주요 이유를 제시합니다.
XSRF(사이트 간 요구 위조, CSRF, XSRF라고도 함)
이를 전혀 사용하지 않고 XSRF 공격을 실행할 수 있습니다.일반적으로 XMLHTTPRequest는 모든 주요 브라우저와 호환되는 방식으로 XMLHTTPRequest를 만들기 어렵기 때문에 전혀 사용되지 않습니다.URL을 로드하려면 URL에 img 태그를 추가하는 것이 훨씬 쉽습니다.
서드파티 사이트로의 투고
<script type="text/javascript">
$.post("http://some-bank.com/transfer-money.php",
{ amount: "10000", to_account: "xxxx" })
</script>
로 달성할 수 있다.
<body onload="document.getElementById('InvisbleForm').submit()"
<div style="display:none">
<form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
<input type="hidden" name="amount" value="10000">
<input type="hidden" name="to_account" value="xxxxx">
</form>
</div>
</body>
JPunyon: 왜 새로운 기능에 취약성을 남겨두려고 합니까?
더 이상 불안감을 조성하지 않을 거야당신은 단지 그것을 좋은 방향으로 사용하려는 개발자들에게 폐를 끼치고 있을 뿐입니다.이 기능을 악에 사용하고 싶은 사람은 누구나 다른 방법으로 사용할 수 있습니다.
결론
그가 중요한 문제를 지적했기 때문에 나는 보빈스의 답을 맞췄습니다.XMLHTTPRequest를 사용하면 자격 증명(쿠키)을 사용하여 대상 사이트에 게시하고 사이트에서 반환된 데이터를 읽을 수 있으며 개인 자격 증명도 전송할 수 있으므로 확인 폼을 포함한 일련의 폼을 제출하는 Javascript를 조정할 수 있습니다.XSRF를 방지하기 위해 생성된 임의의 임의의 키를 사용하여 완료됩니다.이렇게 하면 은행처럼 타깃 사이트를 탐색할 수 있으며 은행의 웹 서버는 일반 사용자가 이 모든 양식을 제출한 것이 아님을 알 수 없습니다.
Ajax HTTP 요청이 도메인 경계를 넘을 수 없는 이유는 무엇입니까?
AJAX 요구는 (a) 사용자 credential과 함께 제출되며 (b) 발신자가 반환된 데이터를 읽을 수 있도록 허용되기 때문입니다.
이러한 요인의 조합에 의해 취약성이 발생할 수 있습니다.사용자 credential을 생략한 크로스 도메인 AJAX 형식을 추가하는 제안이 있습니다.
단순히 img, 스크립트 또는 iframe 요소를 문서에 추가할 수 있습니다.
이러한 방법 중 어느 것도 발신자가 반환된 데이터를 읽을 수 있도록 하지 않습니다.
(도메인 간 스크립팅이 허용되도록 의도적으로 설정된 스크립트 또는 누군가가 잘못된 오류를 범한 스크립트는 제외됩니다.)
이를 전혀 사용하지 않고 XSS 공격을 수행할 수 있습니다.서드파티 사이트로의 투고
그건 XSS 공격이 아니야사이트 간 요청 위조 공격(XSRF)입니다.XSRF 공격을 해결하는 방법에는 사용자가 의도적으로 송신한 것이며 공격자 코드에서 송신한 것이 아님을 확인하기 위한 일회성 토큰 또는 암호 토큰을 포함하는 방법이 있습니다.
교차 도메인 AJAX를 허용하면 이 보호 기능이 손실됩니다.공격 코드는 은행 사이트에서 페이지를 요청하고, 해당 사이트의 모든 인증 토큰을 읽고, 두 번째 AJAX 요청으로 전송될 수 있습니다.이는 사이트 간 스크립팅 공격입니다.
POST의 중요한 차이점은 다음과 같습니다.
<body onload="document.getElementById('InvisbleForm').submit()" ...
그리고 Ajax는 POST 실행 후 브라우저가 페이지를 대체하고 Ajax 호출 실행 후가 아닙니다.POST의 결과는 다음과 같습니다.
- 사용자가 명확하게 볼 수 있습니다.
- 은, 응답 이기 때문입니다.이는 응답 페이지가
my-bank.com통제권을 갖게 될 거야어떤 은행도 원클릭 이체를 실시하지 않습니다.
크로스 도메인 Ajax 가 허가되는 경우, XSRF 의 시나리오는 다음과 같습니다.
- 가 어떻게든 방문하다
www.bad-guy.com. - 있는 가 없는
my-bank.com브라우저의 다른 인스턴스에서는 공격이 실패합니다. - 그러나 이러한 페이지가 열려 있고 사용자가 이미 사용자 이름/비밀번호를 입력한 경우, 이는 브라우저의 캐시에 이 세션의 쿠키가 있음을 의미합니다.
- ('JavaScript' )
www.bad-guy.com을 "Ajax" 에my-bank.com. - 를 "HTTP" "my-bank cookie" 에 .
my-bank.com그걸 보내요 - 뱅크는 이 콜을 사용자의 통상적인 액티비티와 구별할 수 없기 때문에 이 요구를 처리합니다.
- 자바스크립트공격의 경우는, 이것이 필요 없는 경우가 있습니다.정말 중요한 것은 컴퓨터 앞에 있는 사용자가 이 상호작용이 일어나는 것을 전혀 알지 못한다는 것입니다.는 화보에서 을 볼 이다.
www.bad-guy.com - 는 JavaScript에 대해 몇 호출을 .
my-bank.com요하필
요점은 주입이나 페이지 조작이 필요하지 않다는 것입니다.
보다 좋은 해결책은 콜 자체는 허용하지만 쿠키를 전송하지 않는 것입니다.이 솔루션은 매우 간단한 솔루션으로 광범위한 개발이 필요하지 않습니다.대부분의 경우 Ajax 콜은 보호되지 않은 위치로 이동하며 쿠키를 전송하지 않는 것은 제한되지 않습니다.
현재 논의 중인 CORS(Cross Origin Resource Sharing)는 쿠키의 송신/송신에 대해 설명하고 있습니다.
음, 보아하니 너만 그렇게 느끼는 건 아닌 것 같은데...
http://www.google.com/search?q=xmlhttp+cross+site
편집: 위의 검색에서 링크된 흥미로운 토론이 있습니다.
http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
사이트 간 xmlhttp 요청(IE 8, FF3 등)을 허용하는 제안이 진행되고 있는 것 같습니다.다만, 사이트 코드를 작성할 때 거기에 있었으면 좋았을 텐데…) 그리고 호환성 문제가 있습니다.그것이 어디에나 보급되려면 시간이 좀 걸릴 것이다.
HTTP 요청을 서버로 전송하면 서버에 의해 설정된 쿠키도 브라우저에서 서버로 다시 전송됩니다.서버는 이러한 쿠키를 사용하여 사용자가 로그인하고 있다는 사실을 확인합니다.
악의적인 공격자가 일부 JavaScript를 사용하여 사용자가 알지 못하는 사이에 다른 웹 사이트에서 정보를 훔치거나 승인되지 않은 명령을 수행할 수 있습니다.
예를 들어 다음과 같은 JavaScript 코드를 가진 사이트를 방문하도록 사용자에게 요청할 수 있습니다(jQuery를 가정).
<script type="text/javascript">
$.post("http://some-bank.com/transfer-money.php",
{ amount: "10000", to_account: "xxxx" })
</script>
이제 위의 코드가 실행되었을 때 사용자가 실제로 은행에 로그인했다면 공격자는 $10K를 XXX 계좌로 송금했을 수 있습니다.
이러한 종류의 공격은 Cross Site Request Formature(XSRF; 사이트 간 요청 위조)라고 불립니다.Wikipedia에 이것에 대한 더 많은데요.
이는 주로 동일한 오리진정책이 존재하며 브라우저에서는 오리진과는 다른 도메인에서 XMLHttpRequests를 수행할 수 없기 때문입니다.
크로스 도메인 XHR을 실제로 허용하기 위해 몇 가지 논의가 진행 중이지만, 이것이 실제로 받아들여질지는 지켜봐야 합니다.
말씀하신 대로 나쁜 용도로 사용될 수 있기 때문에 걱정입니다.또, 좋은 의도로 사용할 수 있기 때문에, 크로스 도메인·프로토콜이 개발되고 있습니다.
가장 큰 우려 사항은 Cross-Site Scripting(XSS; 사이트 간 스크립팅)과 Cross-Site Request Wraphing(CSRF; 사이트 간 요청 위조)과 함께 사용되는 경우입니다.둘 다 심각한 위협입니다(그 때문에 OWASP Top 10과 SANS 25에 진입했습니다).
악용되는 걸 볼 수 있는 유일한 방법은 누군가 자바스크립트를 주입해서
이는 XSS Far too 많은 앱이 여전히 취약하며 브라우저 보안 모델이 X-domain AJAX를 막지 못한다면 상당한 공격 벡터를 사용자에게 제공하고 있습니다.
문서에 img, 스크립트 또는 iframe 요소를 추가하여 서드파티 URL을 요구하도록 할 수 있습니다.
네, 단, HTTP_REFERER를 전송하여 CSRF를 방지하기 위해 차단할 수 있습니다.AJAX 콜은 헤더를 보다 쉽게 스푸핑할 수 있으며 기존의 CSRF 보호를 회피하는 다른 수단을 사용할 수 있습니다.
일반적인 XSRF 공격과 다른 점은 javascript를 통해 얻은 데이터로 작업을 수행할 수 있다는 것입니다.
뭐가 큰 문제인지 모르겠어요.AJAX 콜을 다른 도메인으로 송신한 후 필터링된 데이터를 사용하여 다른 도메인으로 전송하고 필요한 경우 반환된 데이터를 해석하여 사용자에게 전달합니다.
중요한 AJAX 요청을 처리하고 있습니까?헤더를 확인하거나 세션 시간 데이터를 저장하거나 수신 IP 주소를 신뢰할 수 있는 소스 또는 애플리케이션으로 필터링하여 들어오는 어리버리들을 고정합니다.
향후 개인적으로 보고 싶은 것은 웹 서버, 프레임워크 및 CMS 상의 모든 수신 요구에 대해 견고한 보안을 확립하고 외부 소스로부터의 요구를 해석하는 리소스를 명시적으로 정의하는 것입니다.
와 함께<form>데이터는 올릴 수 있지만 읽을 수는 없습니다.와 함께XHR둘 다 할 수 있어요.
같은 페이지http://bank.example.com/display_my_password는, XSRF(비밀번호만 표시하고 패스워드는 설정하지 않는 것을 전제로 하고 있습니다) 및 프레임(두 프레임의 발신기지 정책이 같습니다)에 대해서 안전합니다.단, 크로스 도메인 XHR은 취약성이 됩니다.
예상치 못한 방문자를 서비스 거부 공격자로 만들 수 있습니다.
또, 페이스북의 모든 것을 훔치는 크로스 사이트 스크립트를 상상해 보세요.IFrame이 열리고 Facebook.com으로 이동합니다.
이미 Facebook(쿠키)에 로그인하여 데이터나 친구를 읽을 수 있습니다.그리고 더 끔찍해.
언급URL : https://stackoverflow.com/questions/466737/why-the-cross-domain-ajax-is-a-security-concern
'programing' 카테고리의 다른 글
| Wordpress에서 하위 디렉토리로 페이지 이동 (0) | 2023.03.23 |
|---|---|
| 케이스 1에서는 ng-click이 동작하지 않지만 케이스 3에서는 동작하는 이유는 무엇입니까? (0) | 2023.03.23 |
| Vim 및 Syntastic에서 발생하는 각 방향성 보풀 오류를 무시하려면 어떻게 해야 합니까? (0) | 2023.03.23 |
| TypeError: 정의되지 않은 생성자가 아닙니다. (0) | 2023.03.23 |
| angularJ의 숫자에 1000개의 구분 쉼표를 추가하는 방법은 무엇입니까? (0) | 2023.03.23 |