Se ho un certificato valido per xxxxx.target.com, non posso leggere i cookie di * .target.com?

Question

Se ho un certificato valido per xxxxx.target.com, non posso leggere i cookie di * .target.com?

#1 da (1 voti)

0

Follow up: Se ho un certificato valido per xxxxx.github.com, non posso leggere i cookie di * .github.com?

Mi è stato chiesto di chiederlo come una domanda a parte. Questa non è una domanda duplicata.

Okay, quindi ho posto la domanda di cui sopra perché sono preoccupato per la seguente situazione:

Un dominio imposta i cookie di autorizzazione a * .target.com in quanto più sottodomini che eseguono servizi diversi necessitano di cookie di autenticazione. Anche uno di questi servizi è xxxx.target.com. Qui, sono in grado di caricare file sotto il mio sottodominio che è possibile caricare file come myname.xxxx.target.com/myownfilename.extn. È vulnerabile?

Ad es., Lets Encrypt chiede di caricare un file in /.well-known/acme-challenge/. Per il mio caso questo non è possibile ma posso caricare un file come /somefile.extn.

La mia domanda è, è /.well-known/acme-challenge/ questo percorso è uno standard per la verifica del caricamento di file http? Il target.com è vulnerabile se riesco a caricare file su /myfile.extn?

Esistono altri modi per eseguire la verifica del dominio in questo caso per ottenere un certificato TLS valido?

In breve, se un server, ad esempio target.com ha i cookie di autenticazione impostati su * .target.com e consente inoltre agli utenti di caricare file nel sottodominio di destinazione ma non esattamente in /.well-known/acme-challenge/, è questa situazione è vulnerabile? Oppure, il server dovrebbe essere considerato sicuro? Sono più preoccupato che altre CA possano avere metodi di verifica del caricamento di file http diversi che potrebbero mettere a rischio tali server.

cookies tls certificates certificate-authority

posta Arul Anand M 26.11.2018 - 20:31

fonte

1 risposta

Leggi altre domande sui tag cookies tls certificates certificate-authority

Perché un sottodominio da un sito Web attendibile scarica un file? impossibile verificare il documento di identità dell'istanza di AWS EC2 con libressl

score 1 · Accepted Answer

Here, I am able to upload files under my sub-subdomain that is I can upload files as myname.xxxx.target.com/myownfilename.extn. Is this vulnerable?

Finché un caricamento nel sottodominio secondario non viene mappato a un URL nel dominio principale che può essere utilizzato per la convalida del dominio, non vedo alcun problema qui. E se questo è il caso dipende dalla specifica configurazione del server che è sconosciuta.

... is /.well-known/acme-challenge/ this path a standard for http file upload verification

Questo è il percorso standard definito nel protocollo ACME che è usato da Let's Encrypt e alcuni altri.

... Is there any other ways to get the domain verification done in this case to get valid TLS cert?

Lo scenario che descrivi non è così raro. Sarebbe molto brutto se questo potesse essere usato per ottenere un certificato TLS valido. Considerato quanto sia comune, non penso che sia possibile ottenere un certificato valido in questo modo.

In short, if a server, say target.com have auth cookies set to *.target.com and also allow users to upload files under target's subdomain but not exactly to /.well-known/acme-challenge/, is this situation vulnerable?

L'ambito dei cookie di autenticazione non ha nulla da fare in modo che un file caricato in qualche sottodominio si verifichi nel dominio principale (se non del tutto). Basandosi solo su queste informazioni non c'è vulnerabilità.