Non sicuro per consentire tutte le intestazioni? [chiuso]

2

Al momento sto sviluppando una webapp. Per testare e sviluppare ho permesso tutte le intestazioni. Non è sicuro per l'uso produttivo?

Header unset Connection
Header unset Time-Zone
Header unset Keep-Alive
Header unset Access-Control-Allow-Origin
Header unset Access-Control-Allow-Headers
Header unset Access-Control-Expose-Headers
Header unset Access-Control-Allow-Methods
Header unset Access-Control-Allow-Credentials

Header set   Connection                         keep-alive
Header set   Time-Zone                          "Asia/Jerusalem"
Header set   Keep-Alive                         timeout=100,max=500
Header set   Access-Control-Allow-Origin        "*"
Header set   Access-Control-Allow-Headers     "Accept, Accept-CH, Accept-Charset, Accept-Datetime, Accept-Encoding, Accept-Ext, Accept-Features, Accept-Language, Accept-Param$
Header set   Access-Control-Expose-Headers    "Accept, Accept-CH, Accept-Charset, Accept-Datetime, Accept-Encoding, Accept-Ext, Accept-Features, Accept-Language, Accept-Param$
Header set   Access-Control-Allow-Methods     "CONNECT, DEBUG, DELETE, DONE, GET, HEAD, HTTP, HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2, OPTIONS, ORIGIN, ORIGINS, PATCH, POST, PUT$
Header set   Access-Control-Allow-Credentials   "true"

Header set DNT "0"
Header set Accept-Ranges "bytes"
Header set Vary "Accept-Encoding"
Header set X-UA-Compatible "IE=edge,chrome=1"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set X-Xss-Protection "1; mode=block"
    
posta Yann1ck 10.06.2016 - 18:31
fonte

1 risposta

4

For testing and developing I allowed all Headers. ...

Non è molto chiaro cosa intendi qui (forse essere più specifico e non solo scaricare la configurazione) ma ...

 Header set   Access-Control-Allow-Origin        "*"
 Header set   Access-Control-Allow-Credentials   "true"

Non è sicuramente una buona idea consentire l'accesso all'origine incrociata da qualsiasi luogo. Ed è ancora peggio combinare questo con l'invio di cookie e altre credenziali.

Con queste restrizioni allentate, un utente malintenzionato potrebbe utilizzare le richieste XHR per accedere a un sito con le credenziali memorizzate dall'utente (ad es. cookie di sessione), modificare i dati con le autorizzazioni dell'utente (CSRF classico) e persino leggere la risposta (quale classico CSRF non può fare). Ad esempio, se si implementasse questo codice per un'applicazione interna all'azienda, un utente malintenzionato esterno potrebbe utilizzare il browser degli utenti interni come trampolino per accedere completamente all'applicazione e leggere il contenuto e il tutto con l'identità dell'utente attualmente connesso.

Tali attacchi basati su XHR potrebbero essere forniti quando l'utente visita il sito degli utenti malintenzionati e tale visita potrebbe essere attivata solo da un annuncio pubblicato da una qualsiasi delle reti pubblicitarie.

A parte questo:

Header set   Access-Control-Allow-Methods     "...HEAD, HTTP, HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2, OPTIONS, ORIGIN, ...

Non ho idea di cosa stai cercando di fare qui, ma i metodi sono GET, POST, HEAD ... e non HTTP / 0.9, HTTP / 1.0 ecc. Vi raccomando caldamente di dare un'occhiata più da vicino a come funziona CORS, cosa significano le intestazioni e quali sono le implicazioni sulla sicurezza.

    
risposta data 10.06.2016 - 19:08
fonte

Leggi altre domande sui tag