Facebook iFrames 및 XFS 위험도

Question

Google 브랜드 페이지에 Facebook 앱을 사용하고 있으며 여기에는 Google이 소유 한 보안 도메인에서 양식을 가져옵니다. 그러나 iFrames에서 가능한 "프레임 간 스크립팅"공격으로 인해 재무 부서에서이를 허용하지 않습니다.

많은 대기업은 FB 내부에 앱을 보유하고 있으며 사용자 데이터를 수집하고 있습니다. FB가 이러한 방식으로 안전하지 않은 코드를 허용하지 않을지 의심 스럽습니다. FB가 이러한 위험을 관리하는 방법에 대해 이야기하는 사이트를 찾고 있습니다. 우리가이 위험을 관리하기 위해 할 수있는 일은 무엇입니까? 우리의 콘텐츠가 우리 자신의 보안 서버에서 오는 것이라면 FB는 우연히 장소 인 일 것입니다. 실제 보안은 우리와 함께 있습니까?

재무 부서의 예약이나이 주제에 관해 자세히 읽어 줄 포인터에 대한 의견을 환영합니다. FB의 도움은이 문제에 대해 드문 경우입니다.

감사합니다.

Answer 1

Cross-frame scripting은 XSS (Cross-Site Scripting) 취약점을 악용하는 방법입니다. 웹 응용 프로그램이 테스트되었고 XSS 취약성에서 벗어난 것으로 밝혀진 경우 크로스 프레임 스크립팅은 중요하지 않습니다.

Same Origin Policy and how it treats iframes에 대해 읽어보세요. 부수적으로, XSS는 공격자가 동일한 출처 정책을 우회 할 수 있기 때문에 공격자에게 유용합니다.

iframe'd 콘텐츠를 허용하는 사이트가 있다면 clickjacking에 대해 걱정할 필요가 있습니다. XSS와 같이 매우 일반적인 웹 애플리케이션 취약점에 익숙하지 않은 경우 OWASP 상위 10 개를 읽으십시오.

Answer 2

Google의 콘텐츠가 Google의 보안 서버에서 비롯된 것이라면 FB가 발생합니다. 우리가 물건을 다루는 장소가 되겠지만, 실제 보안이 우리와 엮여 있습니까?

예, 그렇습니다.

그런데 주로 입력 데이터가 없다는 우려가있는 경우 페이스 북의 사용자 인 것처럼 보이는 클라이언트의 진위를 확인하기위한 Facebook의 조치를 살펴보십시오. signed_request. 그리고 "교차 프레임 스크립팅 공격"과 같은 웹 위협에 대한 전문가의 지식을 습득하고 실제 상황이나 전문 용어가 사용자에게 던져 질 수 있습니다. 또는 귀하의 최종 결과를이 분야의 전문 기관이 확인/인증하도록하십시오.

해커가 앱/앱 서버를 제어하는 ​​것이 저장된 클라이언트 입력 데이터와 관련이있을 수 있다는 우려 사항이있는 경우 - 앱 이외의 다른 앱을 실행하는 전용 웹 서버의 경우입니다. 귀사의 DMZ 이 응용 프로그램 서버는 LAN 데이터 서버의 데이터에 대한 쓰기 액세스 만 가질 수 있습니다 (예 : INSERT 권한 만 부여 된 계정을 사용하여 데이터베이스 쿼리를 모두 작성).

---

Btw는., 회사의 어떤 종류의 금융 소속 (웹) 보안 문제에 대한 주권입니까? 우리가 고객이라면 걱정해야합니까 ...? ;-)