CrossSiteContentHijacking - GitLite

KO | EN

gitlite — search

#python #hacktoberfest #react #golang #go #android #linux #docker #java #windows #awesome-list #ios #openai #open-source

CrossSiteContentHijacking

(★ 385)

Content hijacking proof-of-concept using Flash, PDF and Silverlight

파일 탐색기

최종 버전 다운로드 (.zip)

- - ContentHijacking.html
  - ContentHijacking.pdf
  - ContentHijacking.swf
  - ContentHijacking.xap
  - xfa-manual-ContentHijacking.pdf
- ContentHijackingLoader.html
- index.html
- NCC-logo.png
- - ContentHijacking.as
- - MyTestSilverlightApplication_v1.sln
LICENSE
README.md

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/nccgroup/CrossSiteContentHijacking

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd CrossSiteContentHijacking

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. .NET

보통 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
.NET SDK dotnet 명령어를 쓰기 위한 SDK입니다.

⚠️ 이 프로젝트는 규모가 큰 저장소라, 이 방법이 실제 핵심 제품이 아니라 내부 하위 패키지를 가리키는 것일 수 있습니다. README 전체를 함께 확인해보세요.

cd Source Code/Silverlight

이 프로젝트의 관련 파일이 하위 폴더 안에 있어서, 먼저 그 폴더로 이동합니다.

dotnet restore

프로젝트에 필요한 패키지를 내려받습니다.

dotnet run

프로젝트를 빌드하고 바로 실행합니다.

✅ dotnet run 실행 후 터미널에 나타나는 안내 메시지나 주소를 확인하세요.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

Cross-Site Content (Data) Hijacking (XSCH) PoC Project 
=======================================
License
-------
Released under AGPL (see LICENSE for more information).

Description
-----------
This project can be used to provide a proof of concept for:
- Exploiting websites with insecure policy files (crossdomain.xml or clientaccesspolicy.xml) by reading their contents.
- Exploiting insecure file upload functionalities which do not check the file contents properly or allow to upload SWF or PDF files without having Content-Disposition header during the download process. In this scenario, the created SWF, XAP, or PDF file should be uploaded with any extension such as .JPG to the target website. Then, the "Object File" value should be set to the URL of the uploaded file to read the target website's contents.
- Exploiting CVE-2011-2461 (see the references for more details)
- Exploiting websites with insecure HTML5 cross-origin resource sharing (CORS) headers

Note: .XAP files can be renamed to any other extension but they cannot be load cross-domain anymore. It seems Silverlight finds the file extension based on the provided URL and ignores it if it is not .XAP. This can still be exploited if a website allows users to use ";" or "/" after the actual file name to add a ".XAP" extension.

Usage
-----
- Exploiting an insecure policy file:
  1) Host the ContentHijacking directory with a web server.
  2) Browse to the index.html page (will be redirected to ContentHijackingLoader.html).
  3) Change the "Object File" field in the HTML page to a suitable object from the "objects" directory ("xfa-manual-ContentHijacking.pdf" cannot be used).
- Exploiting an insecure file upload/download: 
  1) Upload an object file from the "objects" directory to the victim server. These files can also be renamed with another extension when uploaded to another domain (for this purpose, first use Flash and then PDF as Silverlight XAP files will not normally work with another extension from another domain).
  2) The "Object File" field should be set to the location of the uploaded file.
- Exploiting CVE-2011-2461
  1) The "Object File" field should be set to the vulnerable file.
  2) Select the "Flash CVE-2011-2461 Only" option from the drop-down list of the "Type" field.
- Exploiting an insecure CORS policy:
  1) The "Object File" field can be set to the local "ContentHijacking.html" file. If you can upload a HTML file in your target domain, you can exploit XSS issues much more easier than using CORS.
  
Note: .XAP files can be renamed to any other extension but they cannot be load cross-domain anymore. It seems Silverlight finds the file extension based on the provided URL and ignores it if it is not .XAP. This can still be exploited if a website allows users to use ";" or "/" after the actual file name to add a ".XAP" extension.

Note: When Silverlight requests a .XAP file cross-domain, the content type must be: application/x-silverlight-app.

Note: PDF files can only be used in Adobe Reader viewer (they will not work with Chrome and Firefox built-in PDF viewers)

Note: Reading static contents or data that is publicly accessible cannot be considered as an issue. It is important to remove false-positive results from your advisories. Note that the use of an astresik ("*") character alone in the "Access-Control-Allow-Origin" header is not an issue.

Usage Example:
- in IE with Adobe Reader:
https://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=https://15.rs/ContentHijacking/objects/ContentHijacking.pdf&objtype=pdf&target=https://0me.me/&postdata=param1=foobar&logmode=all&regex=owasp.*&isauto=1
- in any browsers that supports SWF:
http://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=http://0me.me/ContentHijacking/objects/ContentHijacking.swf&objtype=flash&target=http://0me.me/&postdata=&logmode=result&regex=&isauto=1

Generic Recommendation to Solve the Security Issue
--------------------------------------------------
The file types allowed to be uploaded should be restricted to only those that are necessary for business functionality.

The application should perform filtering and content checking on any files which are uploaded to the server. Files should be thoroughly scanned and validated before being made available to other users. If in doubt, the file should be discarded.

Adding the "Content-Disposition: Attachment" and "X-Content-Type-Options: nosniff" headers to the response of static files will secure the website against Flash or PDF-based cross-site content-hijacking attacks. It is recommended that this practice be performed for all of the files that users need to download in all the modules that deal with a file download. Although this method does not fully secure the website against attacks using Silverlight or similar objects, it can mitigate the risk of using Adobe Flash and PDF objects, especially when uploading PDF files is permitted.

Flash/PDF (crossdomain.xml) or Silverlight (clientaccesspolicy.xml) cross-domain policy files should be removed if they are not in use and there is no business requirement for Flash or Silverlight applications to communicate with the website.

Cross-domain access should be restricted to a minimal set of domains that are trusted and will require access. An access policy is considered weak or insecure when a wildcard character is used especially in the value of the "uri" attribute.

Any "crossdomain.xml" file which is used for Silverlight applications should be considered weak as it can only accept a wildcard ("*") character in the domain attribute.

Browser caching should be disabled for the corssdomain.xml and clientaccesspolicy.xml files. This enables the website to easily update the file or restrict access to the Web services if necessary. Once the client access policy file is checked, it remains in effect for the browser session so the impact of non-caching to the end-user is minimal. This can be raised as a low or informational risk issue based on the content of the target website and security and complexity of the policy file(s).

CORS headers should be reviewed to only be enabled for static or publicly accessible data. Otherwise, the "Access-Control-Allow-Origin" header should only contain authorised addresses. Other CORS headers such as "Access-Control-Allow-Credentials" should only be used when they are required. Items within the CORS headers such as "Access-Control-Allow-Methods" or "Access-Control-Allow-Headers" should be reviewed and removed if they are not required.

Note: Using "Referer" header cannot be a solution as it is possible to set this header for example by sending a POST request using Adobe Reader and PDF (see the "xfa-manual-ContentHijacking.pdf" file in the "objects" directory). Update: Setting the "referer" header has been addressed by Adobe unless you also find a bypass for it ;)

Project Page
------------
See the project page for the latest update/help: https://github.com/nccgroup/CrossSiteContentHijacking

Author
------
Soroush Dalili (@irsdl) from NCC Group

References
----------
Even uploading a JPG file can lead to Cross Domain Data Hijacking (client-side attack)!
https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-can-lead-to-cross-domain-data-hijacking-client-side-attack/

Multiple PDF Vulnerabilities - Text and Pictures on Steroids
http://insert-script.blogspot.co.at/2014/12/multiple-pdf-vulnerabilites-text-and.html

HTTP Communication and Security with Silverlight
http://msdn.microsoft.com/en-gb/library/cc838250(v=vs.95).aspx

Explanation Of Cross Domain And Client Access Policy Files For Silverlight
http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight

Cross-domain policy file specification
http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html

Setting a crossdomain.xml file for HTTP streaming
http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html

Exploiting CVE-2011-2461 on google.com
http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html