10.960 messaggi dal 09 febbraio 2002
Contributi
Ciao Laura,


Per https adesso io li sto configuardo che in http non sono più raggiungibili e quindi faccio un redirect automatico su https.

Ok, sembra corretto. Verifica giusto che la ridirezione funzioni bene anche se si passano dei valori in querystring. Un passo in più che potresti fare è abilitare HSTS: è una banale intestazione che IIS restituisce al client per dirgli di non fare più richieste HTTP, neanche se il client dovesse scriverlo espressamente nella barra degli indirizzi. Qui trovi un esempio completo di Scott Hanselmann, che include sia la ridirezione che l'intestazione HSTS.
https://www.hanselman.com/blog/HowToEnableHTTPStrictTransportSecurityHSTSInIIS7.aspx
Testa per bene l'applicazione in locale o su un server di test prima di metterlo in produzione.


se hai fatto una web application 3 anni fa è normale che non utilizzi l'ultima versione di jquery e che io non mi metterò mai ad aggiornarla?

Certo, non possono pretendere che aggiorni tutto all'ultima versione major. Del resto, se ho iniziato con jquery 1.x e lo aggiornassi alla 3.x ci sarebbero delle breaking change che impedirebbero all'applicazione di funzionare. Quello che puoi fare è aggiornare alla ultima versione minor rilasciata per la 1.x, che non dovrebbe introdurre alcuna breaking change.
Ma, anche se decidessi di restare alla tua attuale 1.x, è un onere di chi contesta dimostrare che quella versione ha dei problemi di sicurezza.

Per quanto riguarda la versione del .NET Framework vale lo stesso discorso: se attualmente stai usando il runtime 4.5, dovresti almeno aggiornarlo alla 4.5.2 per beneficiare degli eventuali fix di sicurezza. Oltrettutto, la 4.5 non è più supportata da Microsoft, mentre la 4.5.2 sì. Lo puoi verificare in questa pagina, scrivendo ".NET Framework 4.5"
https://support.microsoft.com/en-us/lifecycle/search/548

Idem per il sistema operativo, che deve sempre essere aggiornato.
Questo non lo fai tanto per rispondere agli enti certificatori, ma in primo luogo per salvaguardare la sicurezza dei dati dei tuoi utenti.


è possibile che adesso tutti i nostri clienti che si affideranno ad enti certificatori che non hanno competenze tecniche noi dobbiamo stare a rispondere e spiegare

Speriamo che sia un caso isolato ma se comincia a succedere più volte, potreste produrre un documento in cui elencate tutte le misure di sicurezza che state adottando e poi lo inviate in risposta ogni volta che ricevete una contestazione.
Se un ente certificatore ti dice che "non state facendo X", ricorda che la loro affermazione deve essere supportata dai fatti, tipo una vulnerabilità nota.


contestano le versioni del framework, versione di iis

La versione di IIS proprio non te la possono contestare perché, come vedi qui, Windows Server 2012 R2 è supportato e aggiornato da Microsoft fino al 2023.


Comunque quello che volevo è essere sicura di quello che andrò a dire e l'unico punto era appunto quello della password.

Se sono duri da convincere, ti consiglio di allegare anche il log di Wireshark, a dimostrazione che il traffico della richiesta di login è cifrato.


Sono andata nelle chiavi di registro e ho solamente SSL 2.0. Quindi devo creare come da guida TLS 1.1 e TLS 1.2 vero?

Verifica innanzitutto col tool https://www.ssllabs.com/ssltest/ cosa è abilitato. Se SSL 3.0 e/o TSL 1.0 sono abilitati, disabilitali dal registro. Ti mando anche un'altra guida.
https://tecadmin.net/enable-tls-on-windows-server-and-iis/


Mi hanno mandato un pdf in tedesco (dove adesso io sto cercando di fare una traduzione iniziale prima che mi arriva da loro quella effettiva)

Ok, se lo puoi condividere sarebbe un aiuto anche per altri utenti che si trovano nella stessa situazione.

ciao,
Moreno

Enjoy learning and just keep making
675 messaggi dal 08 aprile 2009
Ciao Moreno.
Innanzi tutto grazie per le risposte così dettagliate e la condivisione delle tue conoscenze :)
Ti spiego dei punti fondamentali per farti capire che approccio sto seguendo: lavoro in un'azienda che si accupa di gestionale fondamentalmente e abbiamo una nostra app (la sviluppo io) nativa per raccolta ordini e tentata vendita; poi c'è un'area che si occupa di siti web ed e-commerce poco ma loro lavoro con i cms e server linux e soprattutto hanno un sistemista (consulente) specializzato che si occupa di tutto il server; per finire facciamo applicazioni web dedicate che vengono sviluppate in ambiente ASP.NET e pubblicate su server dedicati. Per i server non abbiamo un sistemista e anche se io non lo sono cerco di documentarmi. Queste applicazioni web non sono mai state pubblicate in https e non avendolo mai fatto ho deciso di approcciare il discorso in questo modo: abbiamo acquistato un nuovo server Windows Server 2016 Standard e abbiamo pubblicato in test la prima applicazione web che non essendo ancora in produzione non rischio di fare danni. Sulla base di quello che farò qui andrò a replicarlo per le altre app web anche se il server e iis è un'altra versione e immagino che potrei trovare delle differenze.
Ho scelto di bloccare in definitiva l'http e se mi dici che c'è un'altra configurazione di sicurezza adesso me lo leggo per bene e penso di applicarlo.


Certo, non possono pretendere che aggiorni tutto all'ultima versione major. Del resto, se ho iniziato con jquery 1.x e lo aggiornassi alla 3.x ci sarebbero delle breaking change che impedirebbero all'applicazione di funzionare. Quello che puoi fare è aggiornare alla ultima versione minor rilasciata per la 1.x, che non dovrebbe introdurre alcuna breaking change.
Ma, anche se decidessi di restare alla tua attuale 1.x, è un onere di chi contesta dimostrare che quella versione ha dei problemi di sicurezza.


Putroppo mi è capitato con jquery di aggiornare una minor ed avere problemi con plugin compresi nel template. Per questione di tempo non sono stata ad indagare ma in questo caso potrebbe essere uno sforzo che è il caso di fare.




Per quanto riguarda la versione del .NET Framework vale lo stesso discorso: se attualmente stai usando il runtime 4.5, dovresti almeno aggiornarlo alla 4.5.2 per beneficiare degli eventuali fix di sicurezza. Oltrettutto, la 4.5 non è più supportata da Microsoft, mentre la 4.5.2 sì. Lo puoi verificare in questa pagina, scrivendo ".NET Framework 4.5"
https://support.microsoft.com/en-us/lifecycle/search/548


Per questo progetto sto già utilizzando la 4.5.2




Idem per il sistema operativo, che deve sempre essere aggiornato.
Questo non lo fai tanto per rispondere agli enti certificatori, ma in primo luogo per salvaguardare la sicurezza dei dati dei tuoi utenti.


Gli aggiornamenti del so vengono sempre effettuati.


Ho eseguito https://www.ssllabs.com/ssltest/ sull'applicativo web che in questo moemnto è in test sul server nuovo e mi da questo risultato:
Protocols
TLS 1.3   No
TLS 1.2   Yes
TLS 1.1   Yes
TLS 1.0   Yes
SSL 3   No
SSL 2   No
For TLS 1.3 tests, we currently support draft version 18.


a un certo punto poi su protoc details mi da questa riga rossa:
RC4 Yes INSECURE (more info)


Questa sera avrò il pdf tradotto e avrò la certezza delle contestazioni...può essere che tramite traduttore ho frainteso in precedenza.
675 messaggi dal 08 aprile 2009
Il test su Qualys da B sono passata a A dopo aver disabilitatto RC4 aggiungendo le chiavi nel registro.
Sempre su Protocol Detail mi da questa riga
Downgrade attack prevention   No, TLS_FALLBACK_SCSV not supported

che confrontata con un sito che abbiamo su Server Linux invece da in verde.
Ho letto che Microsoft non supporta il TLS_FALLBACK_SCSV.

Altre differenze di risultato che ho trovato sono queste righe arancioni in Chiper Suites:
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK   256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK   128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK   256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK   128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK   256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK   128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK   112
10.960 messaggi dal 09 febbraio 2002
Contributi
Ciao, prego!


abbiamo acquistato un nuovo server Windows Server 2016 Standard e abbiamo pubblicato in test la prima applicazione web che non essendo ancora in produzione non rischio di fare danni.

Ok, giusto, così puoi fare esperienza liberamente.


test su Qualys da B sono passata a A dopo aver disabilitatto RC4 aggiungendo le chiavi nel registro.

Se possibile fallo con comandi powershell, in modo che poi sia facile eseguire le modifiche anche su altre macchine tramite script.


Downgrade attack prevention No, TLS_FALLBACK_SCSV not supported

Qui non ti so più indirizzare perché non conosco i dettagli dei protocolli TLS. Ho trovato una discussione in cui si parla del tuo caso. La vulnerabilità sembra interessare solo Windows Server 2008 e precedenti. Leggi fino in fondo, il tipo chiede anche come mai ha una segnalazione da SSLabs.
https://social.technet.microsoft.com/Forums/office/en-US/36617b9c-459a-43f5-b1d7-599e346f00b0/enable-tlsfallbackscsv?forum=winserversecurity


Altre differenze di risultato che ho trovato sono queste righe arancioni in Chiper Suites:

Anche qui non ti so dire che ripercussioni ci potrebbero essere disabilitando quelle cipher suites. Sicuramente, escludendone qualcuna rimuovi di fatto la compatibilità con qualche vecchio browser. Stessa cosa disabilitando TLS 1.0. Ad esempio, se lasci solo TLS 1.1 e TLS 1.2, tagli fuori quelli che usano IE 10 (ma è uno 0.11% come vedi qui).
https://caniuse.com/#feat=tls1-1

Direi che la sicurezza è la prima cosa, ma bisogna anche che gli utenti riescano ad usare l'applicazione quindi penso che bisognerà trovare un giusto punto d'incontro.
Del resto, se le cipher suites non te le hanno contestate, puoi anche lasciarle come sono.


Gli aggiornamenti del so vengono sempre effettuati.
Per questo progetto sto già utilizzando la 4.5.2

Ok, ottimo

Enjoy learning and just keep making
675 messaggi dal 08 aprile 2009
Vi aggiorno dopo l'incontro che ho avuto sull'adeguamento del nuovo GDPR per l'applicazione web in questione.
La maggior parte delle segnalazioni che hanno effettuato sono corrette e già lo sapevamo anche noi ma su alcune abbiamo eseguito in passato le richieste effettuate dal cliente:
- certificato SSL: giustissimo
- privacy policy : giustissimo
- cookie policy: giustissimo anche se l'unico cookie che memorizziamo è un guid interno di sessione per recuperare la configurazione che si stava effettuando se eventualemnte si chiude il browser
- pagina impressium dedicata con i dati del proprietario e i nostri aziendali
- informativa trattamento e-mail: la configurazione di un prodotto non richiede nessun tipo di registrazione ma al termine della configurazione del prodotto richiediamo un indirizzo e-mail per poter inviare in allegato il PDF con il preventivo. Attualmento questo indirizzo viene salvato in banca dati per fini statistici interni. La decisione è stata quella di non registrare più l'indirizzo ma utilizzarlo solo per l'invio della e-mail con il preventivo dando informativa all'utente sull'utilizzo. Nel caso non voglia fornire l'informazione può aprire in anteprima il PDF e scaricarlo senza invio e-mail.

Questi sono i punti che ci aspettavamo e sapevamo benissimo che dovevano essere implementati per l'adeguamento.

Invece così come avevo intuito hanno contestato anche la versione di ASP.NET utilizzata.
Partiamo dal presupposto che hanno trovato queste informazioni da questo strumento online:
https://www.wappalyzer.com/

Recupera le informazioni degli headers.
Da queste informazioni esce fuori che
x-aspnet-version4.0.30319

Da quì sono andati in questa pagina
https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-2002/version_id-97706/Microsoft-.net-Framework-4.0.html

Dove c'è la lista delle vulnerabilità del Framework 4.0

Allora, adesso potrei pensare io delle cavolate ma:
x-aspnet-version4.0.30319
è la versione del CLR non di aspnet nè del framework di destinazione dell'app web che è il 4.5.2 supportata da microsoft.
Di versioni del clr ce ne sono 2 la 2.0 e la 4.0.
Sbaglio?

In ogni caso il nostro cliente dopo spiegazione tecnica ci ha chiesto di inviare una dichiarazione sulle versioni utilizzate e sulla sicurezza degli strumenti tecnologici dell'app.

Questa la nota tradotta dal tedesco:

Per quanto è comprensibile, la versione più recente di ASP.NET non viene utilizzata. Per l'usato
Le vulnerabilità sono note nella versione 4.0 (https://www.cvedetails.com/vulnerability-list/vendor_id-
26 / product_id-2002 / version_id-97706 / Microsoft .NET Framework 4.0.html). Non è chiaro se le patch appropriate
- se disponibile - sono stati installati.
Assicurarsi che il software utilizzato sia aggiornato e / o adeguato alle patch. Applica, se applicabile
anche per jequery 1.11.0 e IIS 8.5.

10.960 messaggi dal 09 febbraio 2002
Contributi
Ciao Laura,

Vi aggiorno dopo l'incontro che ho avuto sull'adeguamento del nuovo GDP

Ok, grazie per la condivisione!


Di versioni del clr ce ne sono 2 la 2.0 e la 4.0.
Sbaglio?

Corretto. Dovresti togliere quell'intestazione dalla risposta così gli enti certificatori non potranno dire stupidaggini ai tuoi clienti. Anzi, dovresti togliere ogni altra intestazione che faccia capire che tecnologia stai usando lato server. Infatti, sono utili solo ai malintenzionati che così possono restringere il cerchio sul tipo di attacco da rivolgere alle tue macchine. Leggi qui:
https://blogs.msdn.microsoft.com/varunm/2013/04/23/remove-unwanted-http-response-headers/


Assicurarsi che il software utilizzato sia aggiornato e / o adeguato alle patch. Applica, se applicabile
anche per jequery 1.11.0 e IIS 8.5.

Ok, non si capisce molto bene cosa vogliano dire :) Se consigliano semplicemente di tenere i sistemi aggiornati, va bene.

Enjoy learning and just keep making
675 messaggi dal 08 aprile 2009
Tolto tutte le intestazioni così la prossima volta almeno questa non succede.
Grazie Moreno di tutti i suggerimenti :)

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.