text:
Sessione, in informatica e telecomunicazioni, è un termine che può essere utilizzato per indicare:
 il colloquio tra utente ed elaboratore su un determinato argomento, tipicamente un'applicazione software;
 l'attività svolta tra due entità per trasferire dati in entrambi i sensi per tutta la durata del collegamento ovvero compreso all'interno del tempo di connessione tra le entità stesse.
Con il suo significato di base il termine è entrato in questi ambiti intorno agli anni settanta. Si parla di livello di sessione nel caso si parli di modello OSI.

Sessione Web
In inglese, la parola "sessione" si riferisce a un periodo di tempo discreto durante il quale viene eseguita un'attività. Una sessione web è quindi il tempo che un utente trascorre navigando su un determinato sito web: dal momento in cui arriva sulla prima pagina, al momento in cui lascia il sito.

Una sessione web è costituita da dati o file che sono persistenti durante l'uso di un sito web o di un'applicazione web. Queste risorse sono identificate in modo univoco con un ID di sessione. Il browser dell'utente riceve questo ID all'inizio di una nuova sessione e questo ID viene scambiato durante ogni successiva comunicazione tra il browser e il server.

Una sessione web include tutte le informazioni che possono essere rilevanti durante la visita dell'utente. A seconda dello scopo del sito Web o dell'applicazione Web, ciò può includere dati come:

 Le pagine visualizzate dall'utente
 I dettagli di contatto che l'utente ha inserito in un modulo
 Gli articoli nel carrello degli acquisti dell'utente

Di solito esiste un limite di tempo massimo per le sessioni web, dopo il quale la sessione scadrà. Questo limite di tempo massimo dipende dall'attuazione. Ad esempio, le sessioni web in Google Analytics scadono dopo 30 minuti di inattività; l'ulteriore attività dell'utente verrà trattata come una nuova sessione.

I siti Web e le applicazioni Web con un numero molto elevato di utenti spesso memorizzano nella cache le sessioni Web, in modo che possano essere recuperate in modo più rapido ed efficiente.

I vantaggi dell'utilizzo delle sessioni web sono evidenti: le sessioni web consentono al sito web di avere una qualche forma di "memoria a breve termine" sull'attività di un utente.

Da un lato, non avere alcuna memoria degli utenti sarebbe estremamente scomodo. Se un sito Web di e-commerce non è in grado di ricordare le azioni di un utente, ad esempio, gli utenti dovrebbero effettuare ordini di e-commerce tutti in una volta all'interno di una singola azione, invece di memorizzare gli articoli in un carrello della spesa.

D'altra parte, anche avere una memoria troppo lunga può essere poco pratico. Ad esempio, se un utente torna su un sito di e-commerce dopo un mese, potrebbe non voler vedere gli stessi articoli nel carrello degli acquisti dell'ultima volta.

Le sessioni web rappresentano un equilibrio tra questi due estremi. Le sessioni Web a breve termine forniscono ai siti Web e alle applicazioni Web una "memoria" sufficiente per creare esperienze utente coinvolgenti e personalizzate nel corso della visita di un utente, senza memorizzare troppe informazioni irrilevanti a lungo termine.

Le sessioni Web vengono spesso confrontate (e confuse con) i cookie. Sebbene sia i cookie che le sessioni web memorizzino informazioni su un utente, le loro funzioni sono diverse nella pratica.

I cookie sono file di testo che vengono utilizzati per autenticare e tenere traccia dei visitatori di un sito Web e che vengono memorizzati solo sulla macchina dell'utente. La durata di un cookie è in genere molto più lunga di quella di una sessione web, nell'ordine di mesi o addirittura anni. I cookie sono il modo in cui i siti Web memorizzano le informazioni dell'utente a lungo termine che dovrebbero essere preservate: ad esempio, accedendo automaticamente all'utente quando arriva al sito Web o compilando automaticamente un modulo con i dettagli dell'utente.

Al contrario, le sessioni web hanno lo scopo di memorizzare informazioni solo sulle attività più recenti dell'utente. Le sessioni Web vengono archiviate sul server anziché sul client, il che consente di impedire agli utenti malintenzionati di modificarle. Sia le sessioni web che i cookie possono essere utilizzati in combinazione per tenere traccia del comportamento a lungo e breve termine degli utenti.

Funzionamento

Il ciclo di sessione comprende tre fasi:
 Avvio o apertura: Si avvia uno scambio di informazioni tra l'utente (od anche il client) che intende avvalersi di un servizio e il server che sovraintende tale servizio. La procedura più nota e comune è quella di login. Il server prepara e memorizza un pacchetto di informazioni permanenti che diventeranno i parametri di sessione e, per l'utente, i suoi dati di lavoro per tutta la sessione (solitamente i dati preparati dal server vengono inseriti nei cookie, che a loro volta vengono scaricati dai web Browser e sfruttati per mantenere la sessione del servizio attivo, senza dover ogni volta reinserire i dati manualmente.)

 Lavoro in sessione: Il colloquio prosegue, sempre con lo scambio delle informazioni di sessione. Le tipiche applicazioni per il web prevedono spesso che nell'arco della sessione parte di queste informazioni possano essere variate o aggiunte di nuove.

 Chiusura: Su richiesta dell'utente o del client il server cancella le informazioni di sessione. In assenza di una specifica richiesta, nella gran parte delle applicazioni è prevista la chiusura o fine automatica di sessione, dopo un certo tempo in cui l'utente/client non invia alcun messaggio.

Autenticazione Web, gestione delle sessioni e controllo degli accessi
Una sessione Web è una sequenza di richieste HTTP di rete e transazioni di risposta associate allo stesso utente. Le applicazioni Web moderne e complesse richiedono la conservazione delle informazioni o dello stato di ciascun utente per la durata di più richieste. Pertanto, le sessioni forniscono la possibilità di stabilire variabili, come diritti di accesso e impostazioni di localizzazione, che si applicheranno a ogni interazione che un utente ha con l'applicazione web per la durata della sessione.

Le applicazioni Web possono creare sessioni per tenere traccia degli utenti anonimi dopo la prima richiesta dell'utente. Un esempio potrebbe essere il mantenimento della preferenza della lingua dell'utente. Inoltre, le applicazioni Web utilizzeranno le sessioni una volta che l'utente si è autenticato. Ciò garantisce la capacità di identificare l'utente su eventuali richieste successive oltre a poter applicare controlli di sicurezza di accesso, accesso autorizzato ai dati privati dell'utente e aumentare l'usabilità dell'applicazione. Pertanto, le attuali applicazioni Web possono fornire funzionalità di sessione sia prima che dopo l'autenticazione.

Una volta stabilita una sessione autenticata, l'ID sessione (o token) è temporaneamente equivalente al metodo di autenticazione più forte utilizzato dall'applicazione, come nome utente e password, passphrase, password monouso (OTP), certificati digitali basati su client, smartcard o dati biometrici (come impronte digitali o retina oculare).

HTTP è un protocollo senza stato (RFC2616 sezione 5), in cui ogni coppia di richieste e risposte è indipendente da altre interazioni web. Pertanto, al fine di introdurre il concetto di sessione, è necessario implementare funzionalità di gestione della sessione che colleghino sia i moduli di autenticazione che di controllo di accesso (o autorizzazione) comunemente disponibili nelle applicazioni web:

 L'ID di sessione o il token associa le credenziali di autenticazione dell'utente (sotto forma di una sessione utente) al traffico HTTP dell'utente e ai controlli di accesso appropriati applicati dall'applicazione web. La complessità di questi tre componenti (autenticazione, gestione della sessione e controllo degli accessi) nelle moderne applicazioni web, oltre al fatto che la sua implementazione e associazione risiede nelle mani dello sviluppatore web (poiché i framework di sviluppo web non forniscono relazioni strette tra questi moduli), rende molto impegnativa l'implementazione di un modulo di gestione delle sessioni sicuro.
 La divulgazione, l'acquisizione, la previsione, la forza bruta o la fissazione dell'ID di sessione porteranno ad attacchi di dirottamento della sessione (o sidejacking), in cui un utente malintenzionato è in grado di impersonare completamente un utente vittima nell'applicazione web. Gli aggressori possono eseguire due tipi di attacchi di dirottamento della sessione, mirati o generici. In un attacco mirato, l'obiettivo dell'aggressore è impersonare un utente vittima dell'applicazione Web specifico (o privilegiato). Per gli attacchi generici, l'obiettivo dell'aggressore è impersonare (o ottenere l'accesso come) qualsiasi utente valido o legittimo nell'applicazione web.

ID di sessione
Per mantenere lo stato autenticato e tenere traccia dei progressi degli utenti all'interno dell'applicazione web, le applicazioni forniscono agli utenti un identificatore di sessione (ID sessione o token) che viene assegnato al momento della creazione della sessione e viene condiviso e scambiato dall'utente e dall'applicazione web per tutta la durata della sessione (viene inviato ad ogni richiesta HTTP). L'ID sessione è una coppia name=value.

Con l'obiettivo di implementare ID di sessione protetti, la generazione di identificatori (ID o token) deve soddisfare le seguenti proprietà.

Fingerprinting del nome dell'ID
Il nome utilizzato dall'ID di sessione non deve essere estremamente descrittivo né offrire dettagli non necessari sullo scopo e sul significato dell'ID.

I nomi degli ID di sessione utilizzati dai framework di sviluppo di applicazioni Web più comuni possono essere facilmente rilevati tramite fingerprint, come PHPSESSID(PHP), JSESSIONID(J2EE), CFID& CFTOKEN(ColdFusion), ASP.NET_SessionId(ASP.NET), ecc. Pertanto, il nome dell'ID di sessione può rivelare il tecnologie e linguaggi di programmazione utilizzati dall'applicazione web.

Si consiglia di modificare il nome dell'ID di sessione predefinito del framework di sviluppo Web con un nome generico, ad esempio id.

Lunghezza ID sessione
L'ID sessione deve essere sufficientemente lungo da impedire attacchi di forza bruta, in cui un utente malintenzionato può passare attraverso l'intero intervallo di valori ID e verificare l'esistenza di sessioni valide.

 La lunghezza dell'ID sessione deve essere almeno 128 bit (16 byte).

 La lunghezza dell'ID di sessione di 128 bit viene fornita come riferimento in base alle ipotesi fatte nella sezione successiva Entropia dell'ID di sessione. Tuttavia, questo numero non deve essere considerato un valore minimo assoluto, poiché altri fattori di implementazione potrebbero influenzarne la forza.
 Ad esempio, esistono implementazioni ben note, come ID di sessione Microsoft ASP.NET: "L'identificatore di sessione ASP.NET è un numero generato in modo casuale codificato in una stringa di 24 caratteri composta da caratteri minuscoli dalla A alla Z e da numeri da 0 a 5 ".
 Può fornire un'entropia efficace molto buona e, di conseguenza, può essere considerato abbastanza lungo da evitare supposizioni o attacchi di forza bruta.

Entropia (ID sessione)
L'ID di sessione deve essere imprevedibile (abbastanza casuale) per evitare attacchi di indovinazione, in cui un utente malintenzionato è in grado di indovinare o prevedere l'ID di una sessione valida attraverso tecniche di analisi statistica. A tal fine, è necessario utilizzare un buon CSPRNG (Cryptographically Secure Pseudorandom Number Generator).

Il valore dell'ID di sessione deve fornire almeno l'entropia 64 bit (se viene utilizzato un buon PRNG, questo valore è stimato essere la metà della lunghezza dell'ID di sessione).

Inoltre, un ID di sessione casuale non è sufficiente; deve anche essere univoco per evitare ID duplicati. Un ID di sessione casuale non deve già esistere nello spazio dell'ID di sessione corrente.

 L'entropia dell'ID di sessione è realmente influenzata da altri fattori esterni e difficili da misurare, come il numero di sessioni attive simultanee che l'applicazione web ha comunemente, il timeout assoluto di scadenza della sessione, la quantità di tentativi ID di sessione al secondo che l'attaccante può fare e il l'applicazione web di destinazione può supportare, ecc.
 Se viene utilizzato un ID di sessione con un'entropia di 64 bit, un utente malintenzionato impiegherà almeno 292 anni per indovinare con successo un ID di sessione valido, supponendo che l'attaccante possa provare 10.000 tentativi al secondo con 100.000 sessioni simultanee valide disponibili nell'applicazione web.

Contenuto ID sessione (o valore)
Il contenuto (o valore) dell'ID di sessione deve essere privo di significato per prevenire attacchi di divulgazione di informazioni, in cui un utente malintenzionato è in grado di decodificare il contenuto dell'ID ed estrarre i dettagli dell'utente, della sessione o del funzionamento interno dell'applicazione web.

L'ID sessione deve essere semplicemente un identificatore sul lato client e il suo valore non deve mai includere informazioni sensibili (o PII).

Il significato e la logica aziendale o dell'applicazione associata all'ID sessione devono essere archiviati sul lato server e, in particolare, negli oggetti sessione o in un database o repository di gestione delle sessioni.

Le informazioni memorizzate possono includere indirizzo IP del client, agente utente, e-mail, nome utente, ID utente, ruolo, livello di privilegio, diritti di accesso, preferenze di lingua, ID account, stato corrente, ultimo accesso, timeout di sessione e altre sessioni interne dettagli. Se gli oggetti e le proprietà della sessione contengono informazioni sensibili, come i numeri di carta di credito, è necessario crittografare e proteggere adeguatamente il repository di gestione della sessione.

Si consiglia di creare ID di sessione crittograficamente efficaci tramite l'uso di funzioni hash crittografiche come SHA256.

Implementazione della gestione della sessione
L'implementazione della gestione della sessione definisce il meccanismo di scambio che verrà utilizzato tra l'utente e l'applicazione Web per condividere e scambiare continuamente l'ID di sessione. Ci sono più meccanismi disponibili in HTTP per mantenere lo stato della sessione all'interno delle applicazioni web, come i cookie (intestazione HTTP standard), i parametri URL (riscrittura URL - RFC2396), argomenti URL su richieste GET, argomenti del corpo su richieste POST, come campi modulo nascosti (Moduli HTML) o intestazioni HTTP proprietarie.

Il meccanismo di scambio dell'ID di sessione preferito dovrebbe consentire la definizione di proprietà avanzate del token, come la data e l'ora di scadenza del token o vincoli di utilizzo granulari. Questo è uno dei motivi per cui i cookie (RFC 2109 e 2965 e 6265) sono uno dei meccanismi di scambio dell'ID di sessione più ampiamente utilizzati, offrendo funzionalità avanzate non disponibili in altri metodi.

L'utilizzo di specifici meccanismi di scambio dell'ID di sessione, come quelli in cui l'ID è incluso nell'URL, potrebbe rivelare l'ID di sessione (nei collegamenti e nei registri Web, nella cronologia e nei segnalibri del browser Web, nell'intestazione del referer o nei motori di ricerca), nonché facilitare altri attacchi, come la manipolazione dell'ID o attacchi di fissazione della sessione.

Implementazioni di gestione delle sessioni integrate
I framework di sviluppo Web, come J2EE, ASP.NET, PHP e altri, forniscono le proprie funzionalità di gestione delle sessioni e l'implementazione associata. Si consiglia di utilizzare questi framework incorporati anziché crearne uno fatto in casa da zero, poiché vengono utilizzati in tutto il mondo su più ambienti Web e sono stati testati dalle comunità di sviluppo e sicurezza delle applicazioni Web nel tempo.

Tuttavia, tieni presente che questi framework hanno anche presentato vulnerabilità e punti deboli in passato, quindi è sempre consigliabile utilizzare l'ultima versione disponibile, che potenzialmente risolve tutte le vulnerabilità note, nonché rivedere e modificare la configurazione predefinita per migliorare la sua sicurezza seguendo le raccomandazioni descritte in questo documento.

Le capacità di archiviazione o il repository utilizzato dal meccanismo di gestione delle sessioni per salvare temporaneamente gli ID di sessione devono essere protetti, proteggendo gli ID di sessione dalla divulgazione accidentale locale o remota o dall'accesso non autorizzato.

Meccanismi di scambio degli ID di sessione utilizzati e accettati
Un'applicazione web dovrebbe utilizzare i cookie per la gestione dello scambio di ID di sessione. Se un utente invia un ID di sessione tramite un meccanismo di scambio diverso, come un parametro URL, l'applicazione Web dovrebbe evitare di accettarlo come parte di una strategia difensiva per interrompere la fissazione della sessione.

 Anche se un'applicazione web utilizza i cookie come meccanismo di scambio dell'ID di sessione predefinito, potrebbe accettare anche altri meccanismi di scambio.
 È quindi necessario confermare tramite test approfonditi tutti i diversi meccanismi attualmente accettati dall'applicazione Web durante l'elaborazione e la gestione degli ID di sessione e limitare i meccanismi di tracciamento dell'ID di sessione accettati ai soli cookie.
 In passato, alcune applicazioni Web utilizzavano parametri URL, o addirittura passavano dai cookie ai parametri URL (tramite riscrittura URL automatica), se sono soddisfatte determinate condizioni (ad esempio, l'identificazione di client Web senza supporto per i cookie o la mancata accettazione dei cookie a causa di preoccupazioni relative alla privacy degli utenti).

Protezione a livello di trasporto
Al fine di proteggere lo scambio di ID di sessione da intercettazioni attive e divulgazioni passive nel traffico di rete, è essenziale utilizzare una connessione HTTPS (TLS) crittografata per l'intera sessione web, non solo per il processo di autenticazione in cui vengono scambiate le credenziali dell'utente.

Inoltre, l'attributo Secure  cookie deve essere utilizzato per garantire che l'ID di sessione venga scambiato solo tramite un canale crittografato. L'utilizzo di un canale di comunicazione crittografato protegge anche la sessione da alcuni attacchi di fissazione della sessione in cui l'attaccante è in grado di intercettare e manipolare il traffico web per iniettare (o correggere) l'ID di sessione sul browser web della vittima.

La seguente serie di best practice si concentra sulla protezione dell'ID di sessione (in particolare quando vengono utilizzati i cookie) e aiuta con l'integrazione di HTTPS all'interno dell'applicazione web:

 Non passare una determinata sessione da HTTP a HTTPS o viceversa, poiché ciò rivelerà l'ID di sessione in chiaro attraverso la rete.
 Quando si esegue il reindirizzamento a HTTPS, assicurarsi che il cookie sia impostato o rigenerato dopo che si è verificato il reindirizzamento.
 Non mischiare contenuti crittografati e non crittografati (pagine HTML, immagini, CSS, file JavaScript, ecc.) Nella stessa pagina o dallo stesso dominio.
 Ove possibile, evitare di offrire contenuti pubblici non crittografati e contenuti privati crittografati dallo stesso host. Laddove è richiesto contenuto non sicuro, considera di ospitarlo su un dominio non sicuro separato.
 Implementare HTTP Strict Transport Security (HSTS) per applicare le connessioni HTTPS.

Vedere il foglio illustrativo della protezione del livello di trasporto OWASP per una guida più generale sull'implementazione sicura di TLS.

È importante sottolineare che TLS non protegge dalla previsione dell'ID di sessione, dalla forza bruta, dalla manomissione o dalla correzione sul lato client; tuttavia, fornisce una protezione efficace contro un utente malintenzionato che intercetta o ruba ID di sessione tramite un attacco man in the middle.

Cookies

Il meccanismo di scambio dell'ID di sessione basato sui cookie fornisce più funzionalità di sicurezza sotto forma di attributi dei cookie che possono essere utilizzati per proteggere lo scambio dell'ID di sessione:

Attributo sicuro
L'attributo cookie Secure indica ai browser Web di inviare il cookie solo tramite una connessione HTTPS (SSL/TLS) crittografata. Questo meccanismo di protezione della sessione è obbligatorio per impedire la divulgazione dell'ID di sessione tramite attacchi MitM (Man-in-the-Middle). Assicura che un utente malintenzionato non possa semplicemente acquisire l'ID di sessione dal traffico del browser web.

Forzare l'applicazione Web a utilizzare solo HTTPS per la sua comunicazione (anche quando la porta TCP/80, HTTP, è chiusa nell'host dell'applicazione Web) non protegge dalla divulgazione dell'ID di sessione se il cookie Secure non è stato impostato: il browser Web può essere ingannato per rivelare l'ID di sessione su una connessione HTTP non crittografata. L'aggressore può intercettare e manipolare il traffico dell'utente vittima e iniettare un riferimento HTTP non crittografato all'applicazione Web che costringerà il browser Web a inviare l'ID di sessione in chiaro.

Attributo HttpOnly
L'attributo cookie HttpOnly indica ai browser Web di non consentire agli script (ad esempio JavaScript o VBscript) la possibilità di accedere ai cookie tramite l'oggetto document.cookie DOM. Questa protezione dell'ID di sessione è obbligatoria per impedire il furto dell'ID di sessione tramite attacchi XSS. Tuttavia, se un attacco XSS è combinato con un attacco CSRF, le richieste inviate all'applicazione web includeranno il cookie di sessione, poiché il browser include sempre i cookie quando invia le richieste. Il cookieHttpOnly protegge solo la riservatezza del cookie; l'attaccante non può utilizzarlo offline, al di fuori del contesto di un attacco XSS.

Attributo SameSite
SameSite consente a un server di definire un attributo di cookie rendendo impossibile al browser inviare questo cookie insieme a richieste cross-site. L'obiettivo principale è mitigare il rischio di fuga di informazioni tra le origini e fornire una certa protezione contro gli attacchi di falsificazione delle richieste tra siti.

Attributi di dominio e percorso
L'attributo cookie Domain indica ai browser Web di inviare il cookie solo al dominio specificato e a tutti i sottodomini. Se l'attributo non è impostato, per impostazione predefinita il cookie verrà inviato solo al server di origine. L'attributo cookiePath indica ai browser Web di inviare il cookie solo alla directory o alle sottodirectory specificate (o percorsi o risorse) all'interno dell'applicazione Web. Se l'attributo non è impostato, per impostazione predefinita il cookie verrà inviato solo per la directory (o percorso) della risorsa richiesta e l'impostazione del cookie.

Si consiglia di utilizzare un ambito ristretto o limitato per questi due attributi. In questo modo, l'attributo Domain non dovrebbe essere impostato (limitando il cookie solo al server di origine) e l'attributo Path dovrebbe essere impostato il più restrittivo possibile al percorso dell'applicazione web che utilizza l'ID di sessione.

L'impostazione dell'attributo Domain su un valore troppo permissivo, ad esempio example.comconsente a un utente malintenzionato di lanciare attacchi agli ID di sessione tra diversi host e applicazioni Web appartenenti allo stesso dominio, noti come cookie cross-sottodominio. Ad esempio, le vulnerabilità in www.example.compotrebbero consentire a un utente malintenzionato di ottenere l'accesso agli ID di sessione da secure.example.com.

Inoltre, si consiglia di non mischiare applicazioni web di diversi livelli di sicurezza sullo stesso dominio. Le vulnerabilità in una delle applicazioni Web consentirebbero a un utente malintenzionato di impostare l'ID di sessione per un'applicazione Web diversa sullo stesso dominio utilizzando un attributo Domain permissivo (come example.com) che è una tecnica che può essere utilizzata negli attacchi di correzione della sessione.

Sebbene l'attributo Path consenta l'isolamento degli ID di sessione tra diverse applicazioni Web utilizzando percorsi diversi sullo stesso host, si consiglia vivamente di non eseguire applicazioni Web diverse (soprattutto da diversi livelli di sicurezza o ambiti) sullo stesso host. Altri metodi possono essere utilizzati da queste applicazioni per accedere agli ID di sessione, come l'oggetto document.cookie. Inoltre, qualsiasi applicazione web può impostare cookie per qualsiasi percorso su quell'host.

I cookie sono vulnerabili agli attacchi di spoofing DNS, in cui un utente malintenzionato può manipolare la risoluzione DNS per forzare il browser Web a rivelare l'ID di sessione per un determinato host o dominio.

Attributi Expire e Max-Age
I meccanismi di gestione della sessione basati sui cookie possono utilizzare due tipi di cookie, cookie non persistenti (o di sessione) e cookie persistenti. Se un cookie presenta il Max-Age(che ha la preferenza su Expires) o gli attributi Expires, verrà considerato un cookie persistente e verrà memorizzato su disco dal browser Web in base alla data di scadenza.

In genere, le funzionalità di gestione della sessione per tenere traccia degli utenti dopo l'autenticazione fanno uso di cookie non persistenti. In questo modo la sessione scompare dal client se l'istanza del browser Web corrente viene chiusa. Pertanto, si consiglia vivamente di utilizzare cookie non persistenti per scopi di gestione della sessione, in modo che l'ID di sessione non rimanga nella cache del client Web per lunghi periodi di tempo, da cui un utente malintenzionato può ottenerlo.

 Garantire che le informazioni sensibili non siano comprese, assicurando che le informazioni sensibili non siano persistenti/crittografate/archiviate in base alle necessità per la durata della necessità
 Garantire che le attività non autorizzate non possano aver luogo tramite la manipolazione dei cookie
 Assicurarsi che il flag di sicurezza sia impostato per impedire la trasmissione accidentale "sul cavo" in modo non sicuro
 Determina se tutte le transizioni di stato nel codice dell'applicazione controllano correttamente i cookie e impongono il loro utilizzo
 Assicurati che l'intero cookie debba essere crittografato se i dati sensibili sono persistenti nel cookie
 Definisci tutti i cookie utilizzati dall'applicazione, il loro nome e il motivo per cui sono necessari

API di archiviazione Web HTML5
Il Web Hypertext Application Technology Working Group (WHATWG) descrive le API di archiviazione Web HTML5 localStoragee sessionStorage, come meccanismi per l'archiviazione di coppie nome-valore lato client. A differenza dei cookie HTTP, i contenuti localStoragee sessionStoragenon vengono condivisi automaticamente all'interno delle richieste o risposte dal browser e vengono utilizzati per l'archiviazione dei dati lato client.

L'API localStorage

Scopo
I dati memorizzati utilizzando l' localStorageAPI sono accessibili dalle pagine caricate dalla stessa origine, definita come scheme (https://), host (example.com), port (443) e domain/realm (example.com). Ciò fornisce un accesso simile a questi dati come si otterrebbe utilizzando il flagsecure su un cookie, il che significa che i dati memorizzati da httpsnon possono essere recuperati tramite http. A causa del potenziale accesso simultaneo da finestre/thread separati, i dati archiviati utilizzando localStoragepotrebbero essere soggetti a problemi di accesso condiviso (come le race condition) e dovrebbero essere considerati non bloccanti (Web Storage API Spec).

Durata
I dati archiviati utilizzando l'API localStoragevengono conservati durante le sessioni di navigazione, estendendo il periodo di tempo in cui possono essere accessibili ad altri utenti del sistema.

Accesso offline
Gli standard non richiedono che i dati localStoragesiano crittografati a riposo, il che significa che potrebbe essere possibile accedere direttamente a questi dati dal disco.

Caso d'uso
WHATWG suggerisce l'uso di localStorageper i dati a cui è necessario accedere attraverso finestre o schede, su più sessioni e dove potrebbe essere necessario archiviare grandi volumi di dati (multi-megabyte) per motivi di prestazioni.

L'API sessionStorage

Scopo
L'API sessionStoragememorizza i dati all'interno del contesto della finestra da cui è stata chiamata, il che significa che la scheda 1 non può accedere ai dati archiviati dalla scheda 2. Inoltre, come l'API localStorage, i dati archiviati utilizzando l'API sessionStorage sono accessibili dalle pagine caricate dalla stessa origine, che è definito come scheme (https://), host (example.com), port (443) e domain/realm (example.com). Ciò fornisce un accesso simile a questi dati come si otterrebbe utilizzando il flagsecure su un cookie, il che significa che i dati memorizzati da httpsnon possono essere recuperati tramite http.

Durata
L'API sessionStorage memorizza i dati solo per la durata della sessione di navigazione corrente. Una volta chiusa la scheda, i dati non sono più recuperabili. Ciò non impedisce necessariamente l'accesso, nel caso in cui una scheda del browser venga riutilizzata o lasciata aperta. I dati possono anche persistere in memoria fino a un evento di garbage collection.

Accesso offline
Gli standard non richiedono che i dati sessionStorage siano crittografati a riposo, il che significa che potrebbe essere possibile accedere direttamente a questi dati dal disco.

Caso d'uso
WHATWG suggerisce l'uso di sessionStorageper i dati rilevanti per un'istanza di un flusso di lavoro, come i dettagli per la prenotazione di un biglietto, ma in cui è possibile eseguire più flussi di lavoro contemporaneamente in altre schede. La natura del vincolo di finestra/scheda manterrà i dati dalla perdita tra i flussi di lavoro in schede separate.

Rischi per la sicurezza
In generale, i dati protetti o sensibili non devono essere archiviati in modo persistente negli archivi dati del browser poiché ciò potrebbe consentire la fuga di informazioni sui sistemi condivisi. Poiché i meccanismi di archiviazione Web sono API, ciò consente anche l'accesso da script iniettati, rendendolo meno sicuro dei cookie con il flaghttponly applicato. Sebbene sia possibile archiviare dati specifici del flusso di lavoro sessionStorageper utilizzarli in quella scheda/finestra specifica durante i ricaricamenti, le API di archiviazione Web dovrebbero essere trattate come archiviazione non sicura. Per questo motivo, se una soluzione aziendale richiede l'uso di localStorageosessionStorageper archiviare dati sensibili, una tale soluzione dovrebbe crittografare i dati e applicare protezioni di riproduzione. A causa della possibilità di accedere alle API di archiviazione Web tramite un attacco XSS, gli identificatori di sessione devono essere archiviati utilizzando cookie non persistenti, con i flag appropriati per proteggere da problemi di accesso non sicuro (Secure), XSS (HttpOnly) e CSRF (SameSite).

Web Workers
I Web Worker eseguono il codice JavaScript in un contesto globale separato da quello della finestra corrente. Esiste un canale di comunicazione con la finestra di esecuzione principale, che viene chiamato MessageChannel.

Caso d'uso
I web worker sono un'alternativa per l'archiviazione del browser dei segreti (di sessione) quando la persistenza dell'archiviazione durante l'aggiornamento della pagina non è un requisito. Affinché i Web Worker forniscano l'archiviazione sicura del browser, qualsiasi codice che richiede il segreto dovrebbe esistere all'interno del Web Worker e il segreto non dovrebbe mai essere trasmesso al contesto della finestra principale.

L'archiviazione dei segreti nella memoria di un Web Worker offre le stesse garanzie di sicurezza di un cookie HttpOnly: la riservatezza del segreto è protetta. Tuttavia, un attacco XSS può essere utilizzato per inviare messaggi al Web Worker per eseguire un'operazione che richiede il segreto. Il Web Worker restituirà il risultato dell'operazione al thread di esecuzione principale.

Il vantaggio di un'implementazione di Web Worker rispetto a un cookie HttpOnly è che un Web Worker consente ad un codice JavaScript isolato di accedere al segreto; un cookie HttpOnly non è accessibile a nessun JavaScript. Se il codice JavaScript frontend richiede l'accesso al segreto, l'implementazione del Web Worker è l'unica opzione di archiviazione del browser che preserva la riservatezza del segreto.

Ciclo di vita dell'ID sessione

Gestione dell'ID sessione come qualsiasi altro input utente
Gli ID sessione devono essere considerati non attendibili, come qualsiasi altro input utente elaborato dall'applicazione Web, e devono essere accuratamente convalidati e verificati. A seconda del meccanismo di gestione della sessione utilizzato, l'ID di sessione verrà ricevuto in un parametro GET o POST, nell'URL o in un'intestazione HTTP (ad esempio i cookie). Se le applicazioni Web non convalidano e filtrano i valori ID di sessione non validi prima di elaborarle, possono essere potenzialmente utilizzate per sfruttare altre vulnerabilità Web, come SQL injection se gli ID di sessione sono archiviati su un database relazionale o XSS persistente se gli ID di sessione vengono memorizzati e riflessi in seguito dall'applicazione web.

Rinnova l'ID sessione dopo qualsiasi modifica del livello di privilegio
L'ID sessione deve essere rinnovato o rigenerato dall'applicazione Web dopo qualsiasi modifica del livello di privilegio all'interno della sessione utente associata. Lo scenario più comune in cui la rigenerazione dell'ID di sessione è obbligatoria è durante il processo di autenticazione, poiché il livello di privilegio dell'utente passa dallo stato non autenticato (o anonimo) allo stato autenticato. È inoltre necessario considerare altri scenari comuni, come le modifiche alla password, le modifiche alle autorizzazioni o il passaggio da un ruolo utente normale a un ruolo di amministratore all'interno dell'applicazione Web. Per tutte queste pagine critiche dell'applicazione Web, gli ID di sessione precedenti devono essere ignorati, un nuovo ID di sessione deve essere assegnato a ogni nuova richiesta ricevuta per la risorsa critica e l'ID di sessione precedente o precedente deve essere distrutto.

I framework di sviluppo web più comuni forniscono funzioni e metodi di sessione per rinnovare l'ID di sessione, come request.getSession(true)& HttpSession.invalidate()(J2EE), Session.Abandon()& Response.Cookies.Add(new...)(ASP.NET) o session_start()& session_regenerate_id(true)(PHP).

La rigenerazione dell'ID di sessione è obbligatoria per prevenire attacchi di fissazione della sessione, in cui un utente malintenzionato imposta l'ID di sessione sul browser Web dell'utente della vittima invece di raccogliere l'ID di sessione della vittima, come nella maggior parte degli altri attacchi basati sulla sessione, e indipendentemente dall'utilizzo di HTTP o HTTPS. Questa protezione mitiga l'impatto di altre vulnerabilità basate sul Web che possono essere utilizzate anche per lanciare attacchi di correzione della sessione, come la suddivisione della risposta HTTP o XSS.

Una raccomandazione complementare è quella di utilizzare un ID di sessione o un nome token (o un set di ID di sessione) diversi prima e dopo l'autenticazione, in modo che l'applicazione Web possa tenere traccia degli utenti anonimi e degli utenti autenticati senza il rischio di esporre o legare la sessione dell'utente tra entrambi gli stati.

Considerazioni sull'utilizzo di più cookie
Se l'applicazione Web utilizza i cookie come meccanismo di scambio dell'ID di sessione e più cookie sono impostati per una determinata sessione, l'applicazione Web deve verificare tutti i cookie (e applicare le relazioni tra di essi) prima di consentire l'accesso alla sessione dell'utente.

È molto comune per le applicazioni Web impostare una pre-autenticazione del cookie utente su HTTP per tenere traccia degli utenti non autenticati (o anonimi). Una volta che l'utente si autentica nell'applicazione Web, un nuovo cookie sicuro post-autenticazione viene impostato su HTTPS e viene stabilita un'associazione tra entrambi i cookie e la sessione utente. Se l'applicazione web non verifica entrambi i cookie per le sessioni autenticate, un utente malintenzionato può utilizzare il cookie non protetto di pre-autenticazione per ottenere l'accesso alla sessione dell'utente autenticato.

Le applicazioni Web dovrebbero cercare di evitare lo stesso nome di cookie per diversi percorsi o ambiti di dominio all'interno della stessa applicazione Web, poiché ciò aumenta la complessità della soluzione e potenzialmente introduce problemi di scoping.

Scadenza della sessione
Per ridurre al minimo il periodo di tempo in cui un utente malintenzionato può lanciare attacchi su sessioni attive e dirottarle, è obbligatorio impostare i timeout di scadenza per ogni sessione, stabilendo per quanto tempo una sessione rimarrà attiva. Una scadenza insufficiente della sessione da parte dell'applicazione web aumenta l'esposizione di altri attacchi basati sulla sessione, poiché per poter riutilizzare un ID di sessione valido e dirottare la sessione associata, l'aggressore deve essere ancora attivo.

Minore è l'intervallo di sessione, minore è il tempo a disposizione di un utente malintenzionato per utilizzare l'ID di sessione valido. I valori di timeout di scadenza della sessione devono essere impostati in base allo scopo e alla natura dell'applicazione Web e bilanciare sicurezza e usabilità, in modo che l'utente possa completare comodamente le operazioni all'interno dell'applicazione Web senza che la sua sessione scada frequentemente.

Entrambi i valori di inattività e di timeout assoluto dipendono fortemente dalla criticità dell'applicazione Web e dei suoi dati. Gli intervalli di timeout di inattività comuni sono 2-5 minuti per applicazioni di alto valore e 15-30 minuti per applicazioni a basso rischio. I timeout assoluti dipendono da quanto tempo un utente utilizza normalmente l'applicazione. Se l'applicazione è destinata all'uso da parte di un impiegato per un'intera giornata, un intervallo di timeout assoluto appropriato potrebbe essere compreso tra 4 e 8 ore.

Quando una sessione scade, l'applicazione web deve intraprendere azioni attive per invalidare la sessione su entrambi i lati, client e server. Quest'ultimo è il più rilevante e obbligatorio dal punto di vista della sicurezza.

Per la maggior parte dei meccanismi di scambio di sessioni, le azioni lato client per invalidare l'ID di sessione si basano sulla cancellazione del valore del token. Ad esempio, per invalidare un cookie si consiglia di fornire un valore vuoto (o non valido) per l'ID di sessione e impostare l'attributo Expires(o Max-Age) su una data passata (nel caso in cui venga utilizzato un cookie persistente):Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT

Al fine di chiudere e invalidare la sessione lato server, è obbligatorio che l'applicazione web intraprenda azioni attive quando la sessione scade, o l'utente si disconnette attivamente, utilizzando le funzioni e le modalità offerte dai meccanismi di gestione della sessione, quali come HttpSession.invalidate()(J2EE), Session.Abandon()(ASP.NET) o session_destroy()/unset()(PHP).

Scadenza automatica della sessione

Timeout di inattività
Tutte le sessioni dovrebbero implementare un timeout di inattività o inattività. Questo timeout definisce la quantità di tempo in cui una sessione rimarrà attiva nel caso in cui non vi siano attività nella sessione, chiudendo e invalidando la sessione dopo il periodo di inattività definito dall'ultima richiesta HTTP ricevuta dall'applicazione Web per un determinato ID di sessione.

Il timeout di inattività limita le possibilità che un utente malintenzionato abbia di indovinare e utilizzare un ID di sessione valido di un altro utente. Tuttavia, se l'aggressore è in grado di dirottare una determinata sessione, il timeout di inattività non limita le azioni dell'aggressore, poiché può generare periodicamente attività sulla sessione per mantenerla attiva per periodi di tempo più lunghi.

La gestione e la scadenza del timeout della sessione devono essere applicate sul lato server. Se il client viene utilizzato per imporre il timeout della sessione, ad esempio utilizzando il token di sessione o altri parametri del client per tenere traccia dei riferimenti temporali (ad esempio il numero di minuti dall'ora di accesso), un utente malintenzionato potrebbe manipolarli per estendere la durata della sessione.

Timeout assoluto
Tutte le sessioni dovrebbero implementare un timeout assoluto, indipendentemente dall'attività della sessione. Questo timeout definisce la quantità massima di tempo in cui una sessione può essere attiva, chiudendo e invalidando la sessione dopo il periodo assoluto definito da quando la sessione data è stata inizialmente creata dall'applicazione web. Dopo aver invalidato la sessione, l'utente è costretto a (ri) autenticarsi nuovamente nell'applicazione web e stabilire una nuova sessione.

La sessione assoluta limita la quantità di tempo che un utente malintenzionato può utilizzare una sessione dirottata e impersonare l'utente vittima.

Timeout rinnovo
In alternativa, l'applicazione web può implementare un timeout di rinnovo aggiuntivo dopo il quale l'ID di sessione viene automaticamente rinnovato, a metà della sessione utente, e indipendentemente dall'attività della sessione e, quindi, dal timeout di inattività.

Dopo un determinato periodo di tempo dalla creazione iniziale della sessione, l'applicazione Web può rigenerare un nuovo ID per la sessione utente e provare a impostarlo o rinnovarlo sul client. Il valore dell'ID di sessione precedente sarebbe ancora valido per un po' 'di tempo, adattando un intervallo di sicurezza, prima che il client sia a conoscenza del nuovo ID e inizi a usarlo. A quel punto, quando il client passa al nuovo ID all'interno della sessione corrente, l'applicazione invalida l'ID precedente.

Questo scenario riduce al minimo la quantità di tempo in cui un determinato valore di ID sessione, potenzialmente ottenuto da un utente malintenzionato, può essere riutilizzato per dirottare la sessione dell'utente, anche quando la sessione dell'utente vittima è ancora attiva. La sessione utente rimane attiva e aperta sul client legittimo, sebbene il valore dell'ID di sessione associato venga rinnovato periodicamente in modo trasparente durante la durata della sessione, ogni volta che scade il timeout di rinnovo. Pertanto, il timeout di rinnovo integra i timeout di inattività e assoluti, specialmente quando il valore di timeout assoluto si estende in modo significativo nel tempo (ad esempio, è un requisito dell'applicazione mantenere aperte le sessioni utente per lunghi periodi di tempo).

A seconda dell'implementazione, potenzialmente potrebbe esserci una condizione di competizione in cui l'attaccante con un ID di sessione precedente ancora valido invia una richiesta prima dell'utente vittima, subito dopo che il timeout di rinnovo è appena scaduto, e ottiene prima il valore per l'ID di sessione rinnovato. Almeno in questo scenario, l'utente vittima potrebbe essere a conoscenza dell'attacco poiché la sua sessione verrà interrotta improvvisamente perché il suo ID di sessione associato non è più valido.

Scadenza manuale della sessione
Le applicazioni Web dovrebbero fornire meccanismi che consentano agli utenti sensibili alla sicurezza di chiudere attivamente la propria sessione una volta terminato di utilizzare l'applicazione Web.

Pulsante di disconnessione
Le applicazioni Web devono fornire un pulsante di disconnessione (disconnessione, uscita o chiusura sessione) visibile e facilmente accessibile, disponibile nell'intestazione o nel menu dell'applicazione Web e raggiungibile da ogni risorsa e pagina dell'applicazione Web, in modo che l'utente possa chiudere manualmente la sessione all'indirizzo in qualsiasi momento. Come descritto nella sezione Session_Expiration, l'applicazione web deve invalidare la sessione almeno sul lato server.

NOTA: Sfortunatamente, non tutte le applicazioni Web facilitano agli utenti la chiusura della sessione corrente. Pertanto, i miglioramenti sul lato client consentono agli utenti coscienziosi di proteggere le proprie sessioni aiutando a chiuderle diligentemente.

Caching dei contenuti web
Anche dopo la chiusura della sessione, potrebbe essere possibile accedere ai dati privati o sensibili scambiati all'interno della sessione tramite la cache del browser web. Pertanto, le applicazioni Web devono utilizzare direttive di cache restrittive per tutto il traffico Web scambiato tramite HTTP e HTTPS, come le intestazioni Cache-Controle PragmaHTTP e/o tag META equivalenti su tutte o (almeno) le pagine Web sensibili.

Indipendentemente dalla politica della cache definita dall'applicazione Web, se è consentito il caching dei contenuti dell'applicazione Web, gli ID di sessione non devono mai essere memorizzati nella cache, quindi si consiglia vivamente di utilizzare la direttiva Cache-Control: no-cache="Set-Cookie, Set-Cookie2", per consentire ai client Web di memorizzare nella cache tutto tranne l'ID di sessione.

Difese aggiuntive lato client per la gestione delle sessioni
Le applicazioni Web possono integrare le difese di gestione delle sessioni descritte in precedenza con contromisure aggiuntive sul lato client. Le protezioni lato client, in genere sotto forma di controlli e verifiche JavaScript, non sono a prova di proiettile e possono essere facilmente sconfitte da un aggressore esperto, ma possono introdurre un altro livello di difesa che deve essere aggirato dagli intrusi.

Timeout di accesso iniziale
Le applicazioni Web possono utilizzare il codice JavaScript nella pagina di accesso per valutare e misurare il tempo trascorso da quando la pagina è stata caricata e è stato concesso un ID di sessione. Se viene tentato un tentativo di accesso dopo un determinato periodo di tempo, il codice client può notificare all'utente che è trascorso il tempo massimo per l'accesso e ricaricare la pagina di accesso, recuperando così un nuovo ID di sessione.

Questo meccanismo di protezione aggiuntivo cerca di forzare il rinnovo della pre-autenticazione dell'ID di sessione, evitando scenari in cui un ID di sessione precedentemente utilizzato (o impostato manualmente) viene riutilizzato dalla vittima successiva utilizzando lo stesso computer, ad esempio, negli attacchi di correzione della sessione.

Forza la disconnessione dalla sessione sugli eventi di chiusura della finestra del browser web
Le applicazioni Web possono utilizzare il codice JavaScript per acquisire tutte le schede del browser Web o gli eventi di chiusura (o anche indietro) della finestra e intraprendere le azioni appropriate per chiudere la sessione corrente prima di chiudere il browser Web, emulando che l'utente ha chiuso manualmente la sessione tramite il logout pulsante.

Disattiva le sessioni a campi incrociati del browser Web
Le applicazioni Web possono utilizzare il codice JavaScript una volta che l'utente ha effettuato l'accesso e una sessione è stata stabilita per forzare l'utente a eseguire nuovamente l'autenticazione se una nuova scheda o finestra del browser Web viene aperta per la stessa applicazione Web. L'applicazione Web non desidera consentire a più schede o finestre del browser Web di condividere la stessa sessione. Pertanto, l'applicazione tenta di forzare il browser Web a non condividere lo stesso ID di sessione contemporaneamente tra di loro.

Disconnessione automatica del client
Il codice JavaScript può essere utilizzato dall'applicazione Web in tutte le pagine (o critiche) per disconnettersi automaticamente dalle sessioni client allo scadere del timeout di inattività, ad esempio reindirizzando l'utente alla pagina di logout (la stessa risorsa utilizzata dal pulsante di logout menzionato in precedenza).

Il vantaggio di migliorare la funzionalità di timeout di inattività lato server con codice lato client è che l'utente può vedere che la sessione è terminata per inattività, o può anche essere avvisato in anticipo che la sessione sta per scadere tramite un conto alla rovescia e messaggi di avviso. Questo approccio intuitivo aiuta a evitare la perdita di lavoro nelle pagine Web che richiedono dati di input estesi a causa di sessioni scadute lato server.

Rilevamento degli attacchi di sessione

Indovinare ID sessione e rilevamento della forza bruta
Se un utente malintenzionato tenta di indovinare o forzare un ID di sessione valido, deve avviare più richieste sequenziali contro l'applicazione Web di destinazione utilizzando ID di sessione diversi da un singolo (o set di) indirizzi IP. Inoltre, se un utente malintenzionato cerca di analizzare la prevedibilità dell'ID di sessione (ad esempio utilizzando l'analisi statistica), deve lanciare più richieste sequenziali da un singolo (o insieme di) indirizzi IP contro l'applicazione web di destinazione per raccogliere nuovi validi ID di sessione.

Le applicazioni Web devono essere in grado di rilevare entrambi gli scenari in base al numero di tentativi di raccogliere (o utilizzare) ID di sessione diversi e avvisare e/o bloccare gli indirizzi IP offensivi.

Rilevamento delle anomalie dell'ID di sessione
Le applicazioni Web dovrebbero concentrarsi sul rilevamento delle anomalie associate all'ID di sessione, come la sua manipolazione. Il progetto OWASP AppSensor fornisce un framework e una metodologia per implementare funzionalità di rilevamento delle intrusioni integrate all'interno di applicazioni Web incentrate sul rilevamento di anomalie e comportamenti imprevisti, sotto forma di punti di rilevamento e azioni di risposta. Invece di utilizzare livelli di protezione esterni, a volte i dettagli della logica di business e l'intelligence avanzata sono disponibili solo dall'interno dell'applicazione Web, dove è possibile stabilire più punti di rilevamento relativi alla sessione, ad esempio quando un cookie esistente viene modificato o eliminato, un nuovo cookie viene aggiunto, l'ID di sessione di un altro utente viene riutilizzato o quando la posizione dell'utente o l'agente utente cambia durante una sessione.

Associazione dell'ID sessione ad altre proprietà utente
Con l'obiettivo di rilevare (e, in alcuni scenari, proteggere da) comportamenti scorretti dell'utente e dirottamento della sessione, si consiglia vivamente di associare l'ID di sessione ad altre proprietà utente o client, come l'indirizzo IP del client, utente-agente o client certificato digitale basato su. Se l'applicazione Web rileva qualsiasi cambiamento o anomalia tra queste diverse proprietà nel mezzo di una sessione stabilita, questo è un ottimo indicatore della manipolazione della sessione e dei tentativi di dirottamento e questo semplice fatto può essere utilizzato per avvisare e/o terminare la sessione sospetta.

Sebbene queste proprietà non possano essere utilizzate dalle applicazioni Web per difendersi in modo affidabile dagli attacchi di sessione, aumentano notevolmente le capacità di rilevamento (e protezione) delle applicazioni Web. Tuttavia, un utente malintenzionato esperto può aggirare questi controlli riutilizzando lo stesso indirizzo IP assegnato all'utente vittima condividendo la stessa rete (molto comune negli ambienti NAT, come gli hotspot Wi-Fi) o utilizzando lo stesso proxy Web in uscita (molto comune in ambienti aziendali) o modificando manualmente il suo agente utente in modo che appaia esattamente come fanno gli utenti vittima.

Ciclo di vita delle sessioni di registrazione: monitoraggio della creazione, dell'utilizzo e della distruzione degli ID di sessione
Le applicazioni Web dovrebbero aumentare le loro capacità di registrazione includendo informazioni riguardanti l'intero ciclo di vita delle sessioni. In particolare, si consiglia di registrare gli eventi relativi alla sessione, come la creazione, il rinnovo e la distruzione degli ID di sessione, nonché i dettagli sul suo utilizzo durante le operazioni di login e logout, le modifiche del livello di privilegio all'interno della sessione, la scadenza del timeout, la sessione non valida attività (se rilevate) e operazioni aziendali critiche durante la sessione.

I dettagli del registro potrebbero includere un timestamp, indirizzo IP di origine, risorsa di destinazione Web richiesta (e coinvolta in un'operazione di sessione), intestazioni HTTP (inclusi User-Agent e Referer), parametri GET e POST, codici e messaggi di errore, nome utente (o ID utente), più l'ID di sessione (cookie, URL, GET, POST...).

I dati sensibili come l'ID di sessione non devono essere inclusi nei registri al fine di proteggere i registri di sessione dalla divulgazione locale o remota dell'ID di sessione o da accessi non autorizzati. Tuttavia, è necessario registrare un certo tipo di informazioni specifiche della sessione per correlare le voci di registro a sessioni specifiche. Si consiglia di registrare un hash salato dell'ID di sessione invece dell'ID di sessione stesso per consentire la correlazione del registro specifica della sessione senza esporre l'ID di sessione.

In particolare, le applicazioni web devono proteggere a fondo le interfacce amministrative che permettano di gestire tutte le sessioni attive correnti. Spesso vengono utilizzati dal personale di supporto per risolvere problemi relativi alla sessione, o anche problemi generali, impersonando l'utente e osservando l'applicazione Web come fa l'utente.

I registri di sessione diventano una delle principali fonti di dati di rilevamento delle intrusioni nelle applicazioni Web e possono anche essere utilizzati dai sistemi di protezione dalle intrusioni per terminare automaticamente le sessioni e/o disabilitare gli account utente quando vengono rilevati (uno o più) attacchi. Se vengono implementate protezioni attive, anche queste azioni difensive devono essere registrate.

Accesso a sessioni simultanee
È la decisione di progettazione dell'applicazione Web determinare se sono consentiti più accessi simultanei dallo stesso utente dallo stesso o da indirizzi IP client diversi. Se l'applicazione Web non desidera consentire l'accesso simultaneo alla sessione, deve intraprendere azioni efficaci dopo ogni nuovo evento di autenticazione, terminando implicitamente la sessione precedentemente disponibile o chiedendo all'utente (tramite la vecchia, la nuova o entrambe le sessioni) la sessione che deve rimanere attivi.

Si consiglia alle applicazioni Web di aggiungere funzionalità utente che consentono di controllare i dettagli delle sessioni attive in qualsiasi momento, monitorare e avvisare l'utente degli accessi simultanei, fornire funzionalità utente per terminare manualmente le sessioni in remoto e tenere traccia della cronologia delle attività dell'account (registro) mediante registrazione più dettagli del client come indirizzo IP, agente utente, data e ora di accesso, tempo di inattività, ecc.

Protezioni WAF per la gestione delle sessioni
Ci sono situazioni in cui il codice sorgente dell'applicazione web non è disponibile o non può essere modificato, o quando le modifiche richieste per implementare le molteplici raccomandazioni sulla sicurezza e le migliori pratiche descritte sopra implicano una riprogettazione completa dell'architettura dell'applicazione web e, pertanto, non possono essere facilmente implementate a breve termine.

In questi scenari, o per completare le difese dell'applicazione web, e con l'obiettivo di mantenere l'applicazione web il più sicura possibile, si consiglia di utilizzare protezioni esterne come Web Application Firewall (WAF) in grado di mitigare le minacce di gestione delle sessioni già descritte.

I Web Application Firewall offrono funzionalità di rilevamento e protezione dagli attacchi basati sulla sessione. Da un lato, è banale per i WAF imporre l'utilizzo di attributi di sicurezza sui cookie, come i flag Securee HttpOnly, applicando regole di riscrittura di base sull'intestazione Set-Cookieper tutte le risposte dell'applicazione web che impostano un nuovo cookie.

D'altra parte, è possibile implementare funzionalità più avanzate per consentire al WAF di tenere traccia delle sessioni e degli ID di sessione corrispondenti e di applicare tutti i tipi di protezione contro la correzione della sessione (rinnovando l'ID di sessione sul lato client quando i privilegi cambiano vengono rilevati), imponendo sessioni permanenti (verificando la relazione tra l'ID di sessione e altre proprietà del client, come l'indirizzo IP o User-Agent), o gestendo la scadenza della sessione (costringendo sia il client che l'applicazione web a finalizzare la sessione).

Il ModSecurity WAF open source, oltre al set di regole OWASP Core, fornisce funzionalità per rilevare e applicare gli attributi dei cookie di sicurezza, contromisure contro gli attacchi di fissazione della sessione e funzionalità di tracciamento della sessione per applicare sessioni permanenti.

Esempio
session_start(
	'mySessionName',
	-expires = 1440,
	-usecookie=true
)
if(session_result('mySessionName') != 'load') => {
	session_addVar('mySessionName', 'sv_userId')
	session_addVar('mySessionName', 'sv_userName')
	session_addVar('mySessionName', 'sv_userEmail')
	session_addVar('mySessionName', 'sv_favouriteColour')
}

!var_defined('sv_userId') ? 	var('sv_userId' = integer)
!var_defined('sv_userName') ? 	var('sv_userName' = string)
!var_defined('sv_userEmail') ? 	var('sv_userEmail' = string)
!var_defined('sv_favouriteColour') ? 	var('sv_favouriteColour' = 'red')

Note

Voci correlate
 Cookie
 Informatica
 Login
 Logout
 Utente

Interfaccia utente
Terminologia informatica


text:
Sony withdraws the Cyberpunk 2077 from the PlayStation Store, and offers refunds • Eurogamer.net
Update 11 am GMT: CD Projekt Red appears Not In talks with Microsoft to remove Cyberpunk 2077 from sale on Xbox / Microsoft Store.
Joint CEO Adam Kisinski told ReutersWe are not in such discussions with Microsoft at the moment.
"There is no further communication or comment to provide at the moment," CD Projekt Red told Eurogamer this morning. Microsoft has also been contacted for comment.
Original story 9 a.m. GMT: Sony Cyberpunk 2077 has withdrawn from sale in the PlayStation Store until "further notice", and is offering a full refund to anyone who purchased it there.
"[Sony Interactive Entertainment] We strive to ensure a high level of customer satisfaction, "the company wrote at Online statementTherefore, we will begin offering a full refund to all players who have purchased Cyberpunk 2077 via the PlayStation Store. SIE will also remove Cyberpunk 2077 from the PlayStation Store until further notice.
Once we confirm that you purchased Cyberpunk 2077 via the PlayStation Store, we will begin processing your refunds. Please note that completing a refund may vary depending on the payment method and financial institution.
I took a look at the PlayStation Store this morning, and as it is written, Cyberpunk 2077 is no longer listed. This also means that the game is no longer available for PlayStation 5 On the PlayStation Store, as it's currently the PS4 version that you buy and play.
PlayStation Store this morning, after searching for Cyberpunk.
CD Projekt Red said she spoke to PlayStation before moving on.
"After our discussion with PlayStation, a decision was made to temporarily suspend distribution of Cyberpunk 2077 on the PlayStation Store," The center said in a statement. "You can still purchase physical versions of the game in physical stores and online. All digital and physical copies of the game purchased will continue to receive support and updates as we continue to improve your experience.
READ Abu Dhabi Grand Prix: Lewis Hamilton's health is "improving" but no decision has yet been made on a return
According to our knowledge, starting today, anyone who does not wish to wait for updates and wants to retrieve their digital copy of the game, can do so by submitting a request on https://www.playstation.com/cyberpunk-2077-refunds/.
"We are working hard to bring Cyberpunk 2077 back into the PlayStation Store as soon as possible."
Sony's unprecedented decision – I've never seen anything like this – comes after the horrific launch of Cyberpunk 2077 on last-generation devices. It was a game experience plagued with poor performance and a flurry of bugs – something the robustness of the new hardware adapts best to, although no issue without problems.
Digital Foundry is investigating issues And consider what it takes to fix it, and the result is: Lots of horrific work. Major corrections are not expected until January and February. This is not something that will be fixed overnight.
There was confusion And the There were apologies, But the question remains as to why the game would be put in such a state – and it would take more work to clean up the perceived stain of the answer.
It's a shame, at least because on hardware capable of playing it, Cyberpunk 2077 is an exceptional game. However, this wouldn't be a big consolation for those who bought the game, but couldn't enjoy it.
appendCarbon(); }
China News: Terror plague as new embassy could harass thousands of Black Death corpses | United Kingdom | News
Random: Miyamoto confirms that he is, in fact, the father of Mario and Luigi

redpajama_set_name: RedPajamaCommonCrawl


As I mentioned in the previous post (#81), we can use [A](http://en.wikipedia.org/wiki/A) to easily solve problem 82 as well.
One way to solve this problem is to perform the A* search from each element on the leftmost column, and then take the minimum length path amongst all these results.
(time (euler-82)) ;; "Elapsed time: 8053.744512 msecs"
Note how we can memoize the functions passed to A* to improve the speed of A* searches slightly. We possibly could probably have come up with a faster solution by memoizing the collections internal to A, but that would have meant exposing the details of the A to the outside world, which I don't think is advisable in this case.
A better approach towards improving performance is to start thinking outside the box – or in this case, outside the grid. If we redefine the cost and neighbor functions to have a special 'leftmost' starting point that has all the elements in the first column as children, we can solve the problem in a single A* search. Let's mark this new starting point with the coordinate [0 0], to mark that it is 'off the grid'.
(time (euler-82-better)) ;; "Elapsed time: 244.770152 msecs"
This really shows the versatility of the A* search method.


text:
package bt;

import bt.processor.ProcessingContext;
import bt.processor.Processor;
import bt.processor.ProcessorFactory;
import bt.processor.listener.ListenerSource;
import bt.runtime.BtClient;
import bt.runtime.BtRuntime;

import java.util.Objects;
import java.util.function.Supplier;

/**
 * Provides basic capabilities to build a Bt client.
 *
 * @since 1.1
 */
public abstract class BaseClientBuilder<B extends BaseClientBuilder> {

    private BtRuntime runtime;
    private boolean shouldInitEagerly;

    /**
     * @since 1.1
     */
    protected BaseClientBuilder() {
    }

    /**
     * Set the runtime that the newly built client will be attached to.
     *
     * @param runtime Bt runtime
     * @since 1.4
     */
    @SuppressWarnings("unchecked")
    protected B runtime(BtRuntime runtime) {
        this.runtime = Objects.requireNonNull(runtime, "Missing runtime");
        return (B) this;
    }

    /**
     * Initialize the client eagerly.
     *
     * By default the client is initialized lazily
     * upon calling {@link BtClient#startAsync()} method or one of its' overloaded version.
     *
     * Initialization is implementation-specific and may include fetching torrent metainfo,
     * creating torrent and data descriptors, reserving storage space,
     * instantiating client-specific services, triggering DI injection, etc.
     *
     * @since 1.1
     */
    @SuppressWarnings("unchecked")
    public B initEagerly() {
        this.shouldInitEagerly = true;
        return (B) this;
    }

    /**
     * @since 1.1
     */
    public BtClient build() {
        Objects.requireNonNull(runtime, "Missing runtime");
        Supplier<BtClient> clientSupplier = () -> buildClient(runtime, buildProcessingContext(runtime));
        return shouldInitEagerly ? clientSupplier.get() : new LazyClient(clientSupplier);
    }

    /**
     * @since 1.4
     */
    protected abstract ProcessingContext buildProcessingContext(BtRuntime runtime);

    private <C extends ProcessingContext> BtClient buildClient(BtRuntime runtime, C context) {
        @SuppressWarnings("unchecked")
        Class<C> contextType = (Class<C>) context.getClass();

        ListenerSource<C> listenerSource = new ListenerSource<>(contextType);
        collectStageListeners(listenerSource);

        return new DefaultClient<>(runtime, processor(runtime, contextType), context, listenerSource);
    }

    /**
     * @since 1.5
     */
    protected abstract <C extends ProcessingContext> void collectStageListeners(ListenerSource<C> listenerSource);

    private <C extends ProcessingContext> Processor<C> processor(BtRuntime runtime, Class<C> contextType) {
        Processor<C> processor = runtime.service(ProcessorFactory.class).processor(contextType);
        if (processor == null) {
            throw new IllegalStateException("No processors found for context type: " + contextType.getName());
        }
        return processor;
    }
}

redpajama_set_name: RedPajamaGithub


Jack in the Box's Garlic Herb Fries feature their regular French fries topped with garlic herb sauce.
I picked up an order for $2.49.
The fries seemed to have come fresh from the fryer as they were piping hot and crispy. If you've never had them, they're about the same size as McDonald's fries. but don't quite have that savory depth of flavor.
The "garlic herb sauce" appears to be the same as the garlic herb butter on the Buttery Jack as there's a buttery quality to it. Beyond that there's also a mild garlic flavor along with some sparse bits of parsley. It's pleasant enough but doesn't have the same bite as the more typical minced stuff you often get on garlic fries. Your best bet to get more than hints of garlic flavor is to sop up the liquid garlic butter that pools on the bottom of the paper tray.
Overall, Jack in the Box's Garlic Herb Fries were tasty but may be too mild for fans of garlic. Then again, they're relatively inoffensive so that even people that hate garlic might not mind eating them. Also, they cost about the same as a regular order of Jack's fries.


According to Girl's Day's agency, Dream Tea Entertainment – the 4-member girlgroup is going to take a trip to Thailand to do volunteer activities soon. The trip will take time from August 17 until August 21. According to the girlgroup's agency, to fulfill their role as the honorary ambassador of an international child development organization named Plan Korea, they will volunteers in the campaign related to human rights activity for girls – which is a campaign to register the birth of girls. Minah, Yura, Hyeri, and Sojin will participate in the campaign by getting closer to Thai girls' daily lives, and help them who have their births unregistered to be registered.
A representative from Plan Korea said that the girls had done volunteering activities in Thailand as well last year; and have witnessed the suffering of Thai girls whose births are unregistered because of violence, or premature marriages. After witnessing it, the members expressed to the organization that they're willing to work together again with the organization to help them with the birth registration campaign.
Girl's Day have been working together with Plan Korea as their ambassador since 2013. Besides their participation in the volunteer activities last year, Girl's Day also had donated the income from their first solo concert to Plan Korea; as a form of support for Thailand girls' birth registration campaign.


CEO, president of Colonial Danforth Consulting to speak at event hosted by Thomas College, Mid-Maine Chamber.
WATERVILLE — Motivating employees for success will e the focus of a business breakfast scheduled for 7:15-9 a.m. Thursday, June 8, in the Spann Student Commons Summit Room on Thomas College's campus at 180 West River Road, according to a college news release.
The event will be hosted by the college and Mid-Maine Chamber of Commerce. Jason Buchannan, CEO and president of Colonial Danforth Consulting, will discuss how employees are motivated differently and what it takes to maximize a workforce.
As the president and CEO of the company, Buchannan specializes in strategic planning, business growth and development, employee training programs, and process improvement and efficiency.
Buchannan's background includes 22 years in the Navy, along with multiple entrepreneurial adventures. He has extensive business consulting in industries including manufacturing, restaurants, social service agencies, media relations, nonprofit, and even religious institutions.
Buchannan holds a Master of Science degree in organizational leadership, an MBA with a project management certification, and is pursuing his PhD in industrial & organizational psychology.
The cost of the breakfast is $18 for members, $25 at the door and for nonmembers and the general public. Breakfast is included with the reservation. To register, or for more information, email [email protected] or call 873-3315.
The sponsors for the event are AT&T, People's United Bank, Higgins & Bolduc Insurance, Nicholson, Michaud & Company; O'Donnell, Lee, McCowan & Phillips LLC; the printer sponsor Morning Sentinel, a division of MaineToday Media Inc.; and radio sponsor MIX107.9.


text:
Home Cars News Honda's Acura CDX Could Be A Hit In India in Sub-15 Lakh...
Honda's Acura CDX Could Be A Hit In India in Sub-15 Lakh Segment – CMS 2018
Surendhar M
Acura CDX compact SUV is based on the India-bound Honda HR-V and has a solid build with the appealing exterior, showcased at 2018 Chengdu Motor Show
At the ongoing 2018 Chengdu Motor Show, Honda's subsidiary Acura has unveiled the latest avatar of its compact SUV called the CDX. Based on the highly popular and India-bound Honda HR-V, the CDX has been around for more than two years after making debut at the 2016 Beijing Auto Show.
The last edition of the same show in China's capital saw Acura introducing a hybrid version of the CDX. The standard 1.5-litre inline four-cylinder powertrain is paired with a single motor to produce a combined system output of around 160 horsepower.
Acura has not announced the CDX compact SUV in other potential markets like the United States but it could be a future product waiting in the wings for arrival, considering the craze over SUVs and crossovers across the globe. The Acura CDX takes design inspiration from the three-row MDX SUV despite being based on the HR-V and share components with it.
The successor of the Acura SUV-X Concept adorns a busy front portion, swooping roofline and a very unique diamond shaped front grille just as in the MDX, accompanied by an appealing overall stance with sporty styling cues. The Acura CDX is manufactured under the joint venture between Honda and Guangzhou Automobile.
Optimistically speaking, if the CDX could grace India under any form, it could slot right in the sub 15 lakh price bracket to rival Hyundai Creta, Jeep Compass, and Mahindra XUV500. But, as you might have guessed, the chances are highly unlikely.
For India, Honda will likely be launching the HR-V in the near future following the debuts of new CR-V and Civic in the coming months. The recently updated global HR-V boasts a slew of feature additions including Honda Sensing safety suite for the first time with Road Departure Mitigation, Lane Keeping Assist, Collision Mitigation and Adaptive Cruise Control.
Acura CDX Images (Swipe Left/Right)


As universities struggle to meet the growing post-9-11 demand for courses in security and intelligence, Canada's spy agency has revved up recruiting efforts to fill positions soon to be vacated by retiring baby boomers.
"We're looking for about 70% more intelligence officers," said Canadian Security Intelligence Service spokeswoman Barbara Campion, adding the agency currently employs about 2,400 people across Canada and around the world.
"It's a pretty significant increase and it's due mostly to the upcoming retirement of baby boomers."
Campion said CSIS stepped up recruitment efforts in the spring with an aggressive advertising campaign, but noted the service has been boosting its ranks since the terrorist attacks of Sept. 11, 2001, when it received additional funding from the federal government.
While the agency often looks to fill positions from within, it's "trying to increase personnel, not just move them around," Campion said.
According to the CSIS website, there are currently more than 20 positions up for grabs.
"We do get thousands of applications every year, but we really needed to increase the interest because that increases our potential pool of hires," she said.
Each individual hiring process can take up to a year since applicants must go through an extensive background check that includes a polygraph test and examination of financial records and personal acquaintances, Campion said.
While she wouldn't discuss numbers, Campion said there has been a significant increase in applications since the recruitment drive began, particularly after the arrests last June of 17 terrorism suspects in Ontario.
"Events like that tend to trigger increased interest in these types of jobs," she said. "Like after 9-11, apparently we were flooded with resumes."
Any Canadian citizen who has lived in the country for at least 10 years, has a university degree, has the potential to become bilingual (if not already), and can pass the background check required for "top secret" security clearance is eligible to become a CSIS intelligence officer.
If enrolment in security and intelligence university courses is any indication, CSIS should have no trouble finding qualified candidates.
University professors across the country say demand for such courses over the last few years has outstripped the ability of post-secondary institutions to provide them.
Gavin Cameron, a University of Calgary professor who specializes in international relations, terrorism and counterterrorism, said undergraduate courses fill up quickly, and there are usually requests to overload the courses.
The situation, he said, gets worse at the graduate level, with many students having difficulty finding faculty members who can supervise their studies.
"I think every year I probably had three times as many students inquire with overt security-related topics than I could supervise," he said.
Martin Rudner, founding director of the Canadian Centre of Intelligence and Security Studies at Carleton University, said the school last month approved a new master's program in intelligence and national security.
However, the problem is finding enough people to teach the course, since two professors, including Rudner, are retiring, and there is only enough money to hire one replacement.
"The province of Ontario has not only underfunded its universities, it has made it impossible for the universities to even replace retiring faculty," Rudner said.
"The problem is, in Canadian higher education there's no national strategy - nobody in Ottawa telling the provinces what to prioritize."
Because the provinces haven't made security and intelligence research and education a priority, Canada is losing its best and brightest to places like Britain and the United States, Rudner said.


In May of 2013 I started working at the Bike Shop on weekends.
I had been a customer there for a little bit, maybe a year. Getting my bike serviced, bending their ears asking a thousand questions a thousand times as I tried to learn enough about the new bikes for me to make an informed decision on the purchase of the bike I would need to replace my 20+ year old bike that no longer fit me well as my body no longer bent that way….
In 2012 I bought my bike from The Shop. In the early spring, on very cold Sunday mornings, I started joining the shop on the beginner rides.
In April of 2013 The Shop Manager mentioned that the shop was looking for sales help. I thought that sounded like fun, being paid to talk about bikes! I said I wish I could do that and well one thing led to another and in May of 2013….
On my first day I sold a bike, then another, and finally a third. My second day, I sold three more.
Since then I have sole a good number of bikes, shoes, helmets, shorts, jerseys, bike racks, lights, tires, tubes… And it never gets old.
Some of the sales are really memorable.
The time I sold a bike to a young lady who went to highschool with my cousin's son. In Chicago.
The family that came in for a bike for their 13-year old daughter and left with bikes for Mom, Dad, youngest son, oldest daughter….
I count as good friends several people I first met as my customers at the shop.
Today, on a cold and windy December day I sold an older gentleman his first new bike in 30 years. He had a smile that could light up the room. I sold a bike today to a woman who was buying the bike as a holiday gift for her 17-year-old daughter with learning delay. Helping her pick out the right bike, in the right color, with the right accessories and knowing how much joy this will bring to her daughter is something that gives me a wonderful and warm feeling.
All of this serves as inspiration to get me on the bike and riding. I see in the customers the same potential for joy that I feel whenever I get on my bike. They inspire me. As long as I work at the shop it will never get old seeing that look, the look of pleasure and joy and the magic of someone getting on a bike for the first time in years and discovering that the old saying is true, you really don't forget how to ride.
I started leading the beginner rides in the summer of 2013. The owners of The Shop had a family event or some other pressing demand on their time and asked if I would lead the ride for the coming Sunday. I can never really say no to them, they have been very good to me, and so I said yea with quite a bit of trepidation. I had never led a ride before. Was so afraid I would somehow screw it up.
It went great. A group of 10 riders went off and did a safe and enjoyable 35 miles. We all got back safely. And so the Sunday beginner ride became "Mark's Ride". I would lead the ride for the rest of 2013 and all of 2014. In 2015 my broken shoulder prevented me leading the ride. 2015 became my lost season.
This year I got back to leading the ride and we had a great deal of fun. Groups ranging from three or four all the way up to ten or twelve would ride off at a moderate pace and do anywhere from 25 to 40 miles. For me it is a chance to give back some of what I get from cycling. I can't wait until next spring!
Now I am at the time of the year when my riding switches to time on the trainer in my den and my outdoor activity becomes long walks on the track or hikes in the woods. All good. Maybe I can get in some cross-country skiing this winter. I have learned to wear a helmet when I cross-country. I learned this the hard way.
They are a couple whose company we truly enjoy. MT is a friend dating back to High School.
This allowed me to have a nice, hearty dinner and still come in under the calorie budget I have set. It isn't about denial. It is about control. Plan. Work the Plan. Achieve the Goal.
Great recap. Are you getting the snow that we are? Winter has finally arrived.


This Dezyne example is Richard Dennemans's submission for the Dezyne Challenge 2016.
Only when using single/unicast the receiver must acknowledge the message. If no acknowledge is received, the transmitter will retry a few times (mostly 3).
In the following paragraphs, the displayed system is build up step by step.
The ZWaveController can send messages to slave nodes (at request of a user application) and receives messages from slave nodes that will be send to the user application. Communication from controller to slave nodes is performed using an RF signal. And communication from an application to the controller with a RS232 serial port interface.
An interface for the RF communication to the slaves.
This is the main implementation of the ZWaveController.
IZWaveSendDataSerial: To send a message to a ZWave slave node from an application and to receive an acknowledge back from the slave.
IZWaveSendDataRf: to send data from a ZWave controller to a slave using RF.
IZWaveApplicationCommandHandlerRf: to receive data from a slave to a ZWave controller using RF.
IZWaveTxBuffer: interface to check if the transmit buffer is full. ZWaveTxBuffer is a helper component needed to simulate transmit buffer full/not full with the following interfaces.
IZWaveRxState: interface to check if the RF network is busy. ZWaveRxState is a helper component needed to simulate the RF network busy/not busy.
ITimer: timer interface to wait for a period of time. Timer is a helper component to simulate a timer. For example, the timer is used to send an ACK message, after a maximal time, from the controller/slave node (if an unicast transmit function is used).
The following is an example sequence of the ZWaveControllerSw component. It is sending a message to a slave and receiving an acknowledge back from a slave. Transmit buffer is not full, RF network not busy and timer does not timeout. Acknowledge received on time.
And another example of receiving an unsolicited message from a slave to the application, and sending an acknowledge back to the slave.
This component is an implementation of a ZWave slave node. The slave receives commands from a controller and sends commands to the controller. The slave uses the same RF interfaces as the ZWave controller but with inverted direction. See the following figure for the overview.
The slave node implemented in Dezyne contains a digital input and a digital output. The input can be connected to e.g. a switch and is used to send a message to the application if the switch is activated. The output can be connected to e.g. a LED and an application can send a message to toggle the LED.
IZWaveSendDataRf: to receive data from a ZWave controller using RF. See the ZWaveControllerSw component for the state diagram.
IZWaveApplicationCommandHandlerRf: to send data to a ZWave controller using RF. See the ZWaveControllerSw component for the state diagram.
IZWaveSendDataNodeUi: received action from a ZWave controller.
IZWaveApplicationCommandHandlerUi: send action to a ZWave controller.
The following sequence is an example of receiving a single cast data message by the ZWaveSlaveSw component from the RF signal and sending an acknowledge back. The ZWaveSlaveSw component is the main implementation of the ZWaveSlave component.
And a sequence example of sending a message from a slave over RF and receiving an acknowledge back.
The ZWaveSlave component and ZWaveController component can be connected to each other because they have the same RF interfaces with inverted direction. The ZWaveControllerSlaveSystem view after connecting both components is displayed in the following figure.
The Dezyne application doesn't like this setup, and it gives an error that there is a cyclic binding issue in the design when generating code. Because the send implementation should be completely isolated from the receive implementation this could not be a cyclic binding problem I thought. Otherwise I did something wrong with my implementation. To check if I did something wrong and that I made a mistake in my design by creating a cyclic binding, I did the following decomposition.
I extracted the ZWaveSlave component into 2 new components namely a ZWaveSlaveRx and a ZWaveSlaveTx component with same code, same implementation, same behavior, only separated in 2 components. In the following figure displaying the ZWaveControllerSlaveTxSlaveRxSystem is the new system with the separated ZWaveSlaveRx and ZWaveSlaveTx. You can clearly see that there's no cyclic binding in the design.
Now the Dezyne application is not complaining anymore about a cyclic-binding. Then I thought when using these 2 components in a new ZWaveSlaveTxRx component, it should be fine for Dezyne.
I created a new system with this component. The ZWaveControllerSlaveTxRxSystem.
But also in this situation, Dezyne complains about a cyclic-binding issue during code generation. So I had to use the ZWaveSlaveRx and ZWaveSlaveTx component as separate components otherwise I get the cyclic binding error. Dezyne gives this error because Dezyne only looks at the outside of a component, and not inside a component to check if there's a real cyclic-binding. Hope that Dezyne will cope with this in the future, because then you can combine separate features into one new component.
This component can act as an input for the slave component.
The ZWaveSlave will send an ApplicationCommandHandler message to the controller when the input is activated.
The following sequence is an example of activating the switch, and sending out a message. In this example the first message did not get an acknowledge, and a timeout occurs. After the second retry, an acknowledge is received.
This component can act as an output for the slave component.
The controller can send a SendData message to the slave to toggle the led.
In the following example, a message is received to toggle a LED.
In the following system overview displaying the ZWaveControllerSlaveWithIoSystem, a 'userinterface' in the form of a Led and Switch is added to the system.
Finally all slaves and the controller can be connected to a complete ZWave network. The system overview is already displayed in the first section at the beginning of this document. The system has 3 slave nodes and 1 controller node. In this system the ZWaveControllerNw component described in the following section is added to connect all nodes.
This is a helper component used to connect all nodes.
This component is also split into a ZWaveControllerNwRx and ZWaveControllerNwTx because of a cyclic-binding issue in Dezyne. So I had the same problem also with this component as I had with the ZWaveSlave component.
I use the INodeSelect interface in this example to select the destination node because I couldn't do that by a limitation of parameter check during an event in Dezyne. In the next section, I use another method without this interface but using an external variable.
The following is an example of selecting destination node2 and sending data from node 1 to node 2 with an acknowledgement.
And an example of selecting node 1 as destination and receiving data from node2, also with an acknowledgement at the end.
Using an external variable to select the destination node.
Instead of using the INodeSelect interface as mentioned in the previous section, also another method can be used to select the node namely using parameters.
Dezyne does not support internal variables as parameters at this moment, but you can use external variables for this purpose.
In the following overview the system using this method is displayed. The INodeSelect interface is removed, and a NodeIDChecker component with interface is added.
In all the ZWave functions, an external parameter naming nodeID is added. The external parameter is defined in the NodeIDChecker. All interfaces and components needing the nodeID are changed.


text:
Q: Bootstrap 3 navbar not fixed to bottom when scrolling in ios I'm using -viewport-overflow-scroll: touch; overflow: auto; to be able to use the momentum scroll in ios but I having problem with the bootstrap navbar. When I scroll in ios the navbar stays in the middle of the page until I stop scrolling, then a few seconds later it sticks to the bottom again. Any ideas? The navbar is inside the div with the scroll touch.
This is the navbar:

        All rights reserved

.footer{
min-height:1em;
bottom:0;
background-color: #35AEEE;
right: 0;
left: 0;
color: white;
}

A: Since you have bottom: 0;, you can add position: absolute; property to make it sticks to the bottom of the page.

.footer {
  min-height: 1em;
  bottom: 0;
  background-color: #35AEEE;
  right: 0;
  left: 0;
  color: white;
  position: absolute;
}

    All rights reserved

redpajama_set_name: RedPajamaStackExchange


The library has Windows-based computers equipped with Internet access, word processing, electronic reference resources and educational learning programs in the Adult and Youth Services departments. Computers are available on a walk-in basis. To ensure fair and equal access for everyone, we use a reservation system when all computers are in use.
Adult computers are unfiltered and for use by those 18 and older, unless accompanied by an adult.
Youth computers and Teen computers are filtered and for use by those younger than 18.
Teen computers are reserved for high school students. Individuals using a Teen computer may be asked provide a high school ID.
Children younger than 8 years old must have an adult assist them with the computer.
Adults who wish to use the youth computers must be accompanied by a child.
LAPTOPS: The library offers free laptops on the second floor. They are equipped with Windows 10 operating system, Microsoft Office 2016, Edge & Chrome Internet Browsers, Temporary Storage, Skype & Windows Media Player.
A wired mouse, SD card reader and headphones are available for checkout with the laptop.
Must be at least 18 years old and present a valid library card & photo ID to check out a laptop.
Laptops are available on a first-come, first-served basis and they are not reservable.
Checkout is for 3 hours, with a one-hour renewal if no one else is waiting.
Last checkout is at one hour before closing.
Laptops may not be removed from the second floor or taken into the restrooms.
Laptops may not be left unattended. If a laptop is found unattended, the borrower may be suspended from the laptop checkout program.
No food is allowed near the laptop, but you may use a covered drink.
Damage to laptops and/or any laptop accessories may incur fees up to the total replacement costs of those items.
Laptops must be returned to the librarian at the Reference Desk 30 minutes prior to closing.
PRINTING is available from library computers on both floors. The charge is 10 cents per page for black & white, and 50 cents per page for color.
The library also offers free WI FI service throughout the library. A password is required to access our network; you can get access at any of the service desks, and the password is posted throughout the library. For more help, please visit a service desk.


The first term of the academic year 2017-2018 is organised at Université Lille, Sciences et Technologies in Lille (FR).
Université Lille is one of the leading science universities in France. It learns students how to sharpen their critical thinking, a fundamental element in developing knowledge, and it makes them look at things from a different perspective, both academically and socially. Students at Université Lille 1 become part of a particularly cosmopolitan French population situated less than 300 kilometres from five European countries.


text:
By Jennifer Copley (Last Updated 8 January 2010)
Peppermint, Image Courtesy of Paytai, FreeDigitalPhotos.net
Rich in phenolic constituents and flavonoids, peppermint's benefits include antiviral, antioxidant, antifungal, and antibacterial activities (which means that it may help to protect against colds, flus, and other types of infections, as well as major illnesses such as heart disease and cancer). Peppermint may also ease stomach complaints such as indigestion due to its ability to relax smooth muscles. Additionally, a phytonutrient in peppermint oil has been found to protect against cancer of the skin, lungs, and colon in animal studies.
Peppermint has traditionally been used as a home remedy for many different conditions. Evidence suggests that it is an effective treatment for heartburn and may be beneficial for IBS sufferers. There has not yet been sufficient research conducted to evaluate its effectiveness for treating nausea, menstrual pain, cold and flu symptoms, and other health issues, though it remains a popular home remedy for many health complaints.
Like rosemary, peppermint contains rosmarinic acid, which may help those with asthma to breathe more easily. Peppermint is also a rich source of vitamins A and C, as well as other vitamins and minerals.
Peppermint is a staple in many Middle Eastern and East Asian dishes where it is more likely to be paired with meats and vegetables. In North America, it is more commonly consumed as a tea or in certain alcoholic beverages, added to salads and tomato-based soups, and used to flavour desserts, though it is also used in sauces, soups, and jellies.
For a full list of healthy herbs and spices and the reference list for this information series, see the main High-Antioxidant Herbs and Spices page.
For more food articles, see the main Food page. For a full list of health-related articles, see the Health page.


It may sound cliché but end of summer heading into fall in Chicago is one of my favorite times. The air is crisp the trees are changing construction is ending and the Chicago Independent Spirits Expo is held. This was in my mind the most successful one yet having attended every year since it came to Chicago. The brain child of David Schmier owner of Redemption rye and brought to Chicago by Marty Duffy co-producer of the CISE. This is the largest small production spirits show in America. This year's event was held at the Chicago Hilton downtown and was a marvelous spectacle of the comradery that drives the craft spirits world. The show is a place where craft producers of rum, tequila, gin, vodka and of course small batch whiskey.
Usually filled with industry professionals rubbing elbows with producers this years show had a decent amount more of the public who regularly consume these goods. "Leigh Mabry of BC merchants explains that she was impressed to see more of consumer and not just restaurant people" If you love tasting small batch whiskey, gins, vodka and tequilas this is the place to go.
Co-owner and founder of Koval distillery Sonat Hart, Dejorn Huffman the spirits director at Tenzing Wine and Spirits Jenny, Kelly Kniewell – CIO, Fresh Coast Distributor, Raquel Leduc – Brand Ambassador/Bartender, Herbsainte, Monique Huston – Spirit Specialist, Stoller/Glazer, Anne Marineau – Bartender, Randolph Tavern, Sarah Sheperd Macfarquhar – Brand Ambassador, North Shore Distillery, Jenny Solsberg – Owner, Rhine Hall Distillery, Inna Feldman-Gerber – Co-Founder & President, Premiere Distillery. Filled with the darlings of Chicago's craft industry the panel spoke about their unique experience dealing with the landmines of the spirits world.
Monique Huston of Stoller tells me that she "cannot wait for the day that these panels like this will not be necessary". It does bring up an interesting question as to why we distinguish between men and women in certain jobs when we all know women work just as hard.
Sadly, I was under the weather and attended to take pictures and meet with vendors, I was unable to taste anything so I went the whole day without a drop.


text:
A Ballet in the Sky on Board an Air France Flight
On July 6, 2019, Air France, in partnership with the Paris Opera, surprised its passengers on flight AF117 from Shanghai to Paris-Charles de Gaulle. During the flight, 10 dancers from the Paris Opera performed a ballet in the sky in all cabins, to the delight of all the passengers on board.
For the occasion, Yvon Demol, a dancer from the Paris Opera, created an original choreography, specially adapted to the space available in the aisles of the aircraft. The dancers were therefore able to offer a unique ballet performance, to the famous music of Antonio Vivaldi's Four Seasons and Tchaikovsky's Swan Lake.
Air France, official partner and carrier of the Paris Opera ballet's Asian tour.
From June 21 to July 5, 2019, Air France was the official partner and carrier of the Paris Opera ballet's Asian tour. The company carried 151 members of the Opera (dancers, coaches, technical teams, …) from Paris to Singapore and Shanghai, the two cities on their Asian tour.
The dancers' surprise performance on board an Air France flight from Shanghai to Paris celebrated the end of the Paris Opera ballet's tour of Asia.
Air France and the Paris Opera share many common values and contribute to France's influence throughout the world by promoting its culture and way of life. Throughout the year, on all its long-haul flights, Air France offers more than 1,400 hours of video on demand, including an "Arts and Culture" selection offering films from the Paris Opera's new online platform "3e Scène", highlighting dance and featuring a behind-the-scenes tour of the Paris Opera.
Air France ballet
British Airways Teamed Up with Tom Kerridge
Royal Caribbean Welcomes Spectrum of the Seas to the Fleet
Qatar Airways Launches New On-Board Safety Video
Qatar Airways has turned the pre-match team-talk into an entertaining safety video that will be shown on board flights before the end of the year. Featuring football legends past and present, the humorous video delivers...
FoodieVideos
As part of its centenary celebrations, British Airways has teamed up with Michelin-starred British chef, Tom Kerridge, to design gourmet menus for customers travelling with the airline throughout August – the airline's...
Spectrum of the Seas, the first in the Royal Caribbean Quantum Ultra Class, was designed and built for unforgettable vacation experiences. The ship features Royal Caribbean cruise line's first private enclave for suite...


Wireless video becomes more and more popular and is not only used by cinematopraphers and live boadcasters. Wireless video has found its way in the event industry. DwarfConnection addresses especially those who require highest stability in combination with an easy-to-use device. Because of its wide domain of application there are different DC-LINK video transmission systems based on WHDI technology. The transmission distance varies from 150m to 1200m. DC-LINK wireless transmitters are used for shooting, live video and signal distribution. Using the 5 GHz band, DC-LINK wireless SDI and HDMI transmission systems provide stable signal connectivity and uncompressed, real-time video transmission.
Please, choose the proper DC-LINK system below.
All DC-LINK wireless video transmission systems use WHDI technology. Learn more how to use them and how this technology works.


text:
Quick links... Bengals Reds FC Cincinnati College Sports High School Sports
SportsHigh School SportsHigh School Insider
High School Insider: Cincinnati Bengals award grant to Harrison High School's stadium project
Harrison Athletic Director Mark Meibers discusses the Wildcat Stadium renovation grant from the Cincinnati Bengals and the overall project around the school campus.
By: Mike Dyer
Posted at 4:55 PM, Mar 11, 2020
Harrison High School will soon have new synthetic turf at Wildcat Stadium thanks in part to the Cincinnati Bengals.
The Bengals and the National Football League Foundation Grassroots Program teamed up to contribute $250,000 to Harrison High School to install a new synthetic turf field.
RELATED: Join the Cincinnati area high school sports Facebook group
Harrison Athletic Director Mark Meibers discussed the grant and the overall stadium renovation project with the WCPO High School Insider. The school is hosting a groundbreaking ceremony with the Bengals at 10 a.m. Thursday.
Listen to this episode in the player above.
Subscribe to High School Insider with Mike Dyer podcast: