HSTS su Amazon CloudFront di origine S3


11

È possibile impostare le intestazioni HSTS su una distribuzione Amazon CloudFront da un'origine S3?

Risposte:



10

Un aggiornamento su questo ...

Le intestazioni di risposta HTTP ora possono essere personalizzate tramite le funzioni Lambda @ edge. Per la documentazione, consultare http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html per la documentazione. Per provare questo, crea una nuova funzione lambda nella console AWS. Scegli 'Edge Nodge.js 4.3' per la lingua e cerca il modello di intestazione cloudfront-change-response-response. Se lo fai, Lambda ti chiederà a quale distribuzione ed evento CloudFront applicare la funzione. Nota che puoi modificarlo o cambiarlo in qualsiasi momento accedendo alla scheda Comportamento di Cloudfront.

Ecco un esempio della funzione lambda ...

'use strict';
exports.handler = (event, context, callback) => {

    const response = event.Records[0].cf.response;
    response.headers['Strict-Transport-Security'] = 'max-age=2592000; includeSubDomains';

    callback(null, response);
};

1
Fantastico, lo proverò!
chrisvdb,

Mi sono imbattuto nello stesso articolo ... ha funzionato per te? @chrisvdb
Steverino

@Sververino non è mai venuto a provarlo, ma dato che stiamo solo creando un secondo sito Web statico che potrebbe trarne vantaggio, potremmo provarlo su questa istanza. Riporterò una risposta in quel caso, per favore fallo anche tu. Sarebbe interessante anche capire l'impatto sulle prestazioni.
chrisvdb,

1
Aggiornamento: risulta che il limite di 100 TPS nell'attuale versione di anteprima di Lambda @ Edge non è sufficiente per servire in modo affidabile il nostro sito Web (semplice e a basso traffico). Alcuni asset generano casualmente un codice di risposta 50x.
chrisvdb,

1
Il formato di response.headers è cambiato. Quanto sopra non funziona più.
Hamish Moffatt il

4

Per aggiungere alla risposta di Andrew:

Ho appena provato questo e un paio di note: non esiste più un runtime nodejs Edge specifico, ma il lambda deve essere creato nella regione N Virginia e attivato dalla risposta dell'origine cloudfront o dalla risposta del visualizzatore .

Il codice non sembra funzionare più. Fornisce ERR_CONTENT_DECODING_FAILED.

La soluzione è utilizzare la sintassi json come segue:

response.headers['Strict-Transport-Security'] = [ { key: 'Strict-Transport-Security', value: "max-age=31536000; includeSubdomains; preload" } ];
response.headers['X-Content-Type-Options']    = [ { key: 'X-Content-Type-Options', value: "nosniff" } ];

Maggiori informazioni sulle intestazioni qui: infosec.mozilla.org/guidelines/web_security
Josh Habdas

1

Corretto, poiché Lambda @ Edge è generalmente disponibile, lo hanno limitato a N Virginia e si deve scegliere il nodo 6.10 anziché il nodo 4.3.

La parte pertinente del nostro codice di seguito (per i nostri scopi sarà sempre un reindirizzamento permanente 302):

'use strict';
exports.handler = (event, context, callback) => {

  var request = event.Records[0].cf.request;
  const response = {
    status: '302',
    statusDescription: '302 Found',
    httpVersion: request.httpVersion,
    headers: {
      Location: [
        {
            "key":"Location",
            "value":"someURL"
        }
      ],
      'Strict-Transport-Security': [
        {
          "key":"Strict-Transport-Security",
          "value":'max-age=63072000; includeSubDomains; preload'
        }
      ],
    },
  };
  callback(null, response);
};

Configurando comportamenti diversi su CloudFront è possibile limitare quali richieste chiameranno la funzione Lambda.


Ciò era inteso come risposta al post di Adam Maschek ...
chrisvdb,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.