2010-03-16 7 views
9

기존 양식 중 하나가 다른 웹 사이트에 표시되기를 원하는 클라이언트로부터 요청을 받았습니다.iframe SSL 이외의 사이트에서 SSL 보안 양식

iframe에 결제 수단이 있어야합니다.

지불 처리와 관련하여 SSL 웹 사이트에서 비 SSL 웹 사이트로 iframe을 보내면 어떤 영향이 있습니까?

+1

@Kevin : StackOverflow에 오신 것을 환영합니다 :) 여기 몇 가지 사항을 고려해야 할 관련 질문이 있습니다. http://stackoverflow.com/questions/2356080/ssl-login-in-iframe –

답변

5

사용자의 브라우저는 기본적으로 이것이 안전하지 않은 시나리오라고 말하는 보안 경고를 제공합니다. 예를 들어, man-in-the-middle 공격은 비 SSL 페이지에 자바 스크립트를 삽입 할 수 있으며 잠재적으로 손상 될 수 있습니다.

이 시나리오에서는 팝업 또는 리디렉션 페이지 리디렉션이 적절한 방법입니다. 아마도 잘 알고 있기 때문에 브라우저의 콘텐츠를 100 % SSL을 통해 호스팅해야합니다. 그렇지 않으면 단순히 보호받을 수 있다고 보장 할 수 없습니다. 이것이 그 경고의 이유입니다.

+0

그게 내가 생각한 것입니다. 방금 두 번째 사이트도 SSL 보안을 사용할 수 있다고 들었습니다. 그것은 안전하지 않은 콘텐츠 경고에서 우리를 빠져 나올 것입니다. 감사. – Kevin

6

최신 웹 브라우저는 상위 창이 HTTP를 통해 안전하지 못하게 실행되므로 보안 경고를 표시하지 않습니다. 하지만 보안 콘텐츠가 하위 창 (iframe) 내부에 있기 때문에 웹 브라우저에 주소 표시 줄에 보안 잠금 아이콘이 표시되지 않으므로 사용자가 양식이 안전하지 않을 수 있음을 두려워하게됩니다.

modern & classic 인 모든 웹 브라우저는 iframe이 다른 프로토콜 및/또는 도메인 이름을 사용하고 있기 때문에 Javascript를 통해 iframe 콘텐츠에 대한 액세스를 거부하기 때문에 man-in-the-middle 공격은 거의 발생하지 않습니다. 이 시점에서 iframe과 통신하는 유일한 방법은 자바 스크립트를 통한 도메인 간 통신을 허용하는 최신 웹 브라우저에 구현 된 postMessage 함수를 사용하는 것입니다. postMessage를 사용하는 경우에도 iframe에는 부모 창에서 오는 postMessage 이벤트를 수신하는 코드가 포함되어야합니다. iframe에서 지불 양식을 개발하는 경우 상위 창만이 이후 이벤트를 수신해야합니다. 지불이 처리됩니다. 따라서 postmessage를 통해 통신을 유지하는 경우 man-in-the-middle 공격이 발생할 가능성은 거의 없습니다. iframe은 postMessage 만 실행하고 parent는 메시지를 수신합니다.

물론 누구나 이벤트 수신기를 무시하고 상위 창에서 코드를 실행하여 서버가 지불이 처리되었다고 생각하도록 속일 수 있습니다. 즉, 실제로 트랜잭션이 합법적인지 확인하기 위해 서버 측 코드에서 예방 조치를 취해야 할 때입니다. 필자의 지불 양식 (iframe)은 데이터베이스에 임시 키를 생성하고 해당 키를 postMessage를 통해 상위 창으로 보냅니다. 그런 다음 부모 창은 AJAX를 서버에 호출하고 키가 일치하는지 확인하기 위해 데이터베이스를 확인한 다음 트랜잭션이 실제로 수행 한 레코드를 만들기 전에 키를 빠르게 삭제합니다.