Как настроить «X-Content-Type-Options: nosniff» на Amazon S3?

Question

Я столкнулся с проблемой установки заголовка «X-Content-Type-Options: nosniff» на статических файлах (js, css, jpg, gif, ...) на моем ковше Amazon S3.

Когда я пытаюсь добавить его, он говорит мне: «Пользовательские ключи метаданных должны начинаться с x-amz-meta-.»

Как это сделать? Должен ли я делать "х-АМЗ-мета-X-Content-Type-Options"

Спасибо заранее!

Answer 1

определяемые пользователем метаданные действительно должны начинаться с x-amz-meta-*, но это не поможет - они также вернулись как x-amz-meta-* заголовки, когда объект извлекается, и x-amz-meta-X-Content-Type-Options не распознаются браузерами.

S3 имеет очень ограниченную поддержку для заголовков, которые начинаются с x-amz-meta-*. Content-Type и Content-Disposition и действительны, но большинство других нет.

В качестве this support forum post указано (и подтверждено тестирование), если такие заголовки добавлены к загрузке (при работе непосредственно с S3 API), они просто игнорируются. Они не сохраняются и не возвращаются с ответом.

Одно из известных, но недокументированных исключений - X-Robots-Tag, которое S3 принимает и будет возвращаться с ответом, хотя консоль AWS не позволит вам редактировать ее, если вы добавите ее с помощью API.

Возможное временное решение, которое должно быть доступно в ближайшее время, - Lambda@Edge, которое представляет собой интеграцию между Lambda и CloudFront, где функция Lambda работает в сети CloudFront и может изменять заголовки запросов и ответов в CloudFront и из них и Конечно, CloudFront хорошо интегрируется с S3, поэтому это может быть жизнеспособным вариантом, как только Lambda @ Edge будет доступен.

Я испытал это (я подписался на предварительном просмотре Lambda @ Edge. Я официально не слышал назад, что я был предоставлен доступ, но это, кажется, работает.)

С помощью этого лямбда-код функции :

'use strict'; 
exports.handler = (event, context, callback) => { 
    const response = event.Records[0].cf.response; 
    const headers = response.headers; 
    headers['X-Content-Type-Options'] = ['nosniff']; 
    callback(null, response); 
}; 

... дает этот ответ ...

$ curl -v http://dxxxexample.cloudfront.net/robots.txt 
* Hostname was NOT found in DNS cache 
* Trying x.x.x.x... 
* Connected to dxxxexample.cloudfront.net (x.x.x.x) port 80 (#0) 
> GET /robots.txt HTTP/1.1 
> User-Agent: curl/7.35.0 
> Host: dxxxexample.cloudfront.net 
> Accept: */* 
> 
< HTTP/1.1 200 OK 
< Content-Type: text/plain 
< Content-Length: 324 
< Connection: keep-alive 
< Date: Tue, 10 Jan 2017 20:38:33 GMT 
< Last-Modified: Tue, 10 Jan 2017 17:13:36 GMT 
< ETag: "dbe2f9a267e8ef192f0fdf0c888da01c" 
< Cache-Control: no-cache 
< Accept-Ranges: bytes 
* Server AmazonS3 is not blacklisted 
< Server: AmazonS3 
< Via: 1.1 xxxxxxxxxx.cloudfront.net (CloudFront) 
< X-Content-Type-Options: nosniff 
< X-Cache: Miss from cloudfront 
< X-Amz-Cf-Id: xxxxx 
< 
User-agent: * 
Disallow:/

... так что, как представляется, является жизнеспособным обходной.

Я сконфигурировал эту функцию для запуска на «Viewer Response» (срабатывает триггер, чтобы разрешить изменение ответа до того, как ответ будет возвращен из CloudFront в браузер), но на самом деле он мог бы вместо этого активировать «Origin Response», требуя (в предположении, что в отличие от приведенного выше примера вы не использовали также Cache-Control: no-cache, как и в моем тесте. Я использовал /robots.txt просто потому, что у меня уже было это настроено в ведре вместе с CloudFront и Lambda - очевидно, этот файл не является особо интересным приложением для X-Content-Type-Options, но, как вы можете видеть, это работает).

Я не знаю, когда Lambda @ Edge будет выпущен из предварительного просмотра.

Если вы хотите представить это как запрос на функцию для S3, обратитесь к своему представителю учетной записи AWS, если у вас есть, или разместите об этом на форумах поддержки AWS. (Я не аффилирован с AWS).