strawberry-code / IFTTT-PoliTo

The portal of Polito IFTTT project by PRPC team. Visit our website at
https://cristiano-c.github.io
1 stars 1 forks source link

Problema di sicurezza generale #49

Closed sablaireau closed 8 years ago

sablaireau commented 8 years ago

1) Ho provato ad inviare un e.mail falsa dalla gmail action e me l'ha accettata. L'indirizzo era pippo. Quindi si dovrebbe usare più angular per la parte client quindi meno variabili globali e mettere più controlli sulla parte server. Ho usato un googleChrome con la console e ho cambiato il campo email del json ed è stata inviata.

2)Inoltre per ogni campo dalla parte client eseguiamo dei controlli di validità come ad esempio per la temperatura (-70/+70) si dovrebbero anche mettere sul server o ci sono già?

sablaireau commented 8 years ago

e farla al vecchio modo like C?

simonaPr commented 8 years ago

ovvero?

sablaireau commented 8 years ago

quello che importa è che abbia la @e che sia simile a x@y.s

dove x è una stringa che non deve finire per un non carattere a-z A-Z 0-9 e può avere solo punti in mezzo che non siano consecutivi e deve iniziare per un carattere a-z A-Z 0-9

Stessa cosa per `y'.

Mentre per sdeve essere solo una stringa con solo lettere.

Quindi in C diventa più macchinoso ma almeno è fattibile se non si possono usare le regex, al più ci posso provare e poi ti passo il codice.

simonaPr commented 8 years ago

forse ne ho trovata una che java mi accetta e provandola sul quel tool sembra funzionare..ma testate anche voi per sicurezza. ^[\w-_\.+]*[\w-_\.]\@([\w]+\.)+[\w]+[\w]$

sablaireau commented 8 years ago

o.k. va bene

simonaPr commented 8 years ago

ovviamente in java ho dovuto scriverla così: ^[\\w-_\\.+]*[\\w-_\\.]\\@([\\w]+\\.)+[\\w]+[\\w]$

strawberry-code commented 8 years ago

forse ne ho trovata una che java mi accetta e provandola sul quel tool sembra funzionare..ma testate anche voi per sicurezza. ^[\w-_\.+]*[\w-_\.]\@([\w]+\.)+[\w]+[\w]$

mi sembra giusta 👍

strawberry-code commented 8 years ago

Se in Java stai usando la classe Pattern qui c'è una spiegazione molto dettagliata.

simonaPr commented 8 years ago

ottimo, grazie!! Cmq per il momento l'ho messa solo nella registrazione, adesso vedo di aggiungere tutti i controlli per quanto riguarda la creazione delle ricette

simonaPr commented 8 years ago

ho aggiunto i controlli sull'email nel momento in cui riempiamo i db, sono da testare. Se funzionano..li aggiungo anche nella logica per un ulteriore sicurezza (man in the middle tra server e db)

simonaPr commented 8 years ago

provo a seguire le tue istruzione per testarlo..

simonaPr commented 8 years ago

ok..a me sembra funzionare. L'ho testato anche con il trigger gmail (incoming email) e funziona..però non compare la scritta lato client (che avvisa dell'errore) come invece compare per la action gmail

simonaPr commented 8 years ago

Ah sì..forse compare..come non detto.. in ogni caso, adesso aggiungo questi controlli (che mi sembrano funzionare) anche altrove

sablaireau commented 8 years ago

uhm allora noi spediamo tutto al server dopo che finisci la descrizione e a questo punto che riceviamo qualche cosa dal server.

Dentro a trigger gmail c'è una scritta che ti dice se è giusta o no l'email sotto il campo

simonaPr commented 8 years ago

sì sì niente..come non detto ;-)

simonaPr commented 8 years ago

sto tentando di mettere i controlli sulla temperatura, ma di quale temperatura stiamo parlando? thmax e thmin? Entrambe devono essere comprese tra -70 e +70 (inclusi)?

simonaPr commented 8 years ago

invece per quanto riguarda le date, lascerei la stringa nel db..perchè altrimenti bisogna cambiare tutto, sia db che logica..il chè è un po' rischioso; inoltre i controlli sarebbe sempre meglio farli sul server, per evitare un man-in-the-middle tra server e db..ciò significa gestire le eccezioni..come dicevo prima (discorso che io e Alex avevamo lasciato in sospeso)

sablaireau commented 8 years ago

Per thim e thmax le avevo prese dal quello che avevo letto dal quello che mi avevi passato molto probabilmente ho capito male, da quanto ho capito se la temperatura raggiunge X allora si manda un e.mail

simonaPr commented 8 years ago

sì esatto: se l'utente inserisce thmax ad esempio..allora si monitora la temperatura corrente e se supera thmax viene scatenata l'azione. Quindi i controlli che avete messo voi sono su queste due temperature giusto? entrambe devono essere impostate dall'utente con un numero compreso tra -70 e +70?

simonaPr commented 8 years ago

credo di sì..stavo facendo delle prove (e guardando il vostro codice) e mi sembra di capire così

sablaireau commented 8 years ago

si per la prima frase.

Si da [-70/+70] per entrambi

sablaireau commented 8 years ago

si si ho controllato adesso, da -70 a +70 compresi gli estremi solo interi [-70,-69 . . .+70]

simonaPr commented 8 years ago

ottimo grazie!! Li aggiungo sul server e poi posso chiudere questo issue. Perchè il discorso delle eccezioni è un'altra cosa..le ho già guardate un attimo, ma le rivedo poi bene anche con Alex, cmq l'importante è che vengano catturate in modo da non bloccare il thread..poi possono anche venire ignorate: se c'è un errore nei dati (ad esempio la data), la ricetta non verrà svolta..il discorso è più o meno questo

sablaireau commented 8 years ago

di nulla figurati :) Non lo so com'è fatto il server, ma a mio avviso si potrebbe dire che ogni volta che un dato è falso (esempio la temperatura non è un numero) allora si ipotizza un attacco ed il server non risponde poiché tutti i controlli sono fatti al lato client.

Mentre se è un problema sul server (esempio stupido: non c'è più memoria per nuovi utenti) allora si manda un errore da informare il client.

Quello che voglio dire è di cercare di non inviare segnalazioni di errori a valanghe per evitare varie tipologie di attacco.

Tuttavia le mie sono solo idee :) ^-^

simonaPr commented 8 years ago

no no certo...hai ragione..infatti io pensavo proprio di non fare nulla, cioè il thread deve continuare a girare all'infinito, quindi è importate catturare le eccezioni in modo che non lo blocchino, dopodichè se i dati sono sbagliati non si fa nulla..non si invia l'errore al client nè niente, semplicemente la ricetta viene ignorata (e il man-in-the-middle si fotte)..al prossimo giro (se il man-in-the-middle non c'è più) verrà eseguita normalmente. Errore più grave è quando i dati sono sbagliati già nel db (a quel punto la ricetta viene sempre ignorata), però abbiamo messo abbastanza controlli sia sul server che sul client per far sì che ciò non succeda ;-)

sablaireau commented 8 years ago

o.k. perfetto!!!! Povero man-in-the-middle :) quasi quasi mi dispiace per lui :)

simonaPr commented 8 years ago

Ahahahahahaha...a me no!!! :P

sablaireau commented 8 years ago

era ironica la mia affermazione :) XD Avete fatto un ottimo lavoro complimenti!!!!

simonaPr commented 8 years ago

hihihi..sì sì..l'avevo capito :) Grazie!! Anche voi!!!