여러 하위 도메인에서 이미지 데이터의 인라인 인코딩

Question

웹 페이지의 모든 img 태그를 이미지에 포함 된 base64 인코딩 된 데이터로 바꾸려고합니다.

로 표현되는 이미지 :

<img src="data:image/png;base64,iVBORw0KGg..." /> 

의 웹 페이지가 다수의 서브 도메인, 예를 들어, 이미지를 포함

<img src="http://a.example.com" /> 

로 변경 될 하나의 하위 도메인에

<img src="http://a.example.com" /> 
<img src="http://b.example.com" /> 

내가 사용할 수 있습니다 이미지가 HTML 페이지의 이외의 하위 도메인에있을 때

그러나

var images = document.getElementsByTagName('img'); 
for(var i=0; i<images.length; i++){ 
var img = new Image(); 
img.src = images[i].src; 
// Create canvas tag to represent img 
var canvas = document.createElement("canvas"); 
canvas.width = img.width; 
canvas.height = img.height; 
var context = canvas.getContext("2d"); 
context.drawImage(img,0,0); 

img.src = canvas.toDataURL("image/png"); 
$(images[i]).replaceWith(img); 
} 

가, 내가 얻을 :

Uncaught Error: SECURITY_ERR: DOM Exception 18 

콘솔에 있습니다. 페이지에서이 작업을 수행하여 모든 이미지 참조를 해당 인코딩 된 데이터로 변환하려면 어떻게합니까?

Answer 1

보안 샌드 박스는 다른 도메인의 이미지가있는 경우 캔버스에 toDataURL을 호출 할 수 없습니다. 정확한 논리가 나를 벗어나지 만, 당신이 정확히 이것을하지 못하게하기 위해서 존재합니다.

Answer 2

일반적으로 other domains에서 이미지 데이터를 읽을 수 없습니다. Cross-Origin Resource Sharing (CORS) 보안 모델을 위반합니다. 각 하위 도메인에 HTTP access control header (여기에는 example과 node.js)을 사용하고 각 이미지 태그에는 crossorigin 속성을 use-credentials으로 설정하여이 문제를 해결할 수 있다고 말했습니다. 모든 브라우저가 crossorigin 속성을 지원하는 것은 아닙니다.

궁극적으로 서버와 클라이언트는 모두 이미지에 CORS 보안을 사용하도록 선택해야합니다.

또 다른 해결 방법은 $.getImageData이라는 jquery 플러그인을 사용하는 것입니다. 커버 아래에서이 플러그인은 img-to-json 및 JSONP이라는 타사 서비스를 사용하여 보안 문제를 해결합니다. 여기 IMG - 투 - JSON 사용하는 방법에 대한 구체적인 예이다 : 기본적으로

"//img-to-json.appspot.com/?url=" + escape(img_url) + "&callback=" + callback 

이 서비스는 두 개의 매개 변수를 : 당신은 (URL 이스케이프 할 필요가있는) 다운로드하는 이미지의 URL과 이름을 이미지로드가 완료되면 실행하려는 콜백 콜백은 data url 버전의 이미지와 이미지의 높이 및 너비와 같은 일부 메타 데이터로 객체에 전달됩니다. 또한

은 위의 URL이 모두 http 또는 https 페이지에 일 것이다 의미한다 (즉,이 //로 시작)는 protocol relative URL의 예입니다 유의하십시오.

희망이 도움이됩니다.

Answer 3

당신은 사양의 법률을 위반하는 상태 당신은 다음 orgin는 청소 플래그가 false로 설정되어 캔버스의 문서와 같은 기원이 아닌 이미지와 drawImage를 사용하는 경우. 그 이후부터는 toDataURL을 사용할 수 없습니다.문제에 대한 사양의 전체 단어는 here.

입니다.이 보안의 이유는 정보 누출을 방지하기위한 것입니다. 이것이 나쁜 이유를 보려면 다음과 같은 가설적인 상황을 고려하십시오.

직장 네트워크를 사용 중이기 때문에 내부, 개인 회사 사이트 및 브라우저의 (개인용!) 하드 드라이브에 액세스 할 수 있다고 해봅시다. 개인 사이트는 www.internal.myCompany.com과 같을 수 있으며 하드 드라이브는 file:///C:/SomeOfMyPhotos/과 같은 URL에서 액세스 할 수 있습니다.

숨겨진 캔버스가있는 웹 사이트를 방문한 적이 있고 캔버스가 추측 할 수있는 URL이있는 캔버스에 계속해서 drawImage()을 호출하는 사이트를 탐색하는 동안,

www.internal.myCompany.com/secret/secret-plans.jpg

또는 하드 드라이브의 이미지 : 악성 사이트가 민간의 다양한 조합을 계속 시도 할

file:///C:/SomeOfMyPhotos/thatEmbarassingPhoto.png

이 URL은 개인 하위 도메인에 이미지 같은 것들을 것 실제로 파일 인 것을 발견 할 때까지 to-you urls. 그런 다음 그것을 캔버스에 그립니다. 그런 다음 캔버스에서 imageData을 가져 와서 서버로 보냅니다.

Voila! 그들은 당신의 동의없이 비밀 계획과 당신의 당황 사진을 도둑 맞았습니다.

이제 우리는 위의 시나리오가 그다지 가능성이 없다는 것을 알고 있습니다. 결국 기밀 사진은 거의 항상 PNG 형식이고 기밀 사진은 거의 항상 JPG 형식입니다. 그러나 위와 같은 상황이 발생할 수 있으므로 보안에 미치는 영향을 고려해야합니다.