Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene e benvenuti in questo nuovo episodio di GITBAR.Oggi è una puntata un po' particolare, avevo preparato per voi un episodio dove parlavo di Doku e di Bref quindi del deploy delle nostre applicazioni o su una singola macchina utilizzando appunto Doku in modo da deployare direttamente da repository git oppure utilizzando appunto la tecnologia e il paradigma serverless per deployare direttamente le applicazioni PHP in questo caso su le lambda di amazon su amazon lambda infatti naturalmente avevo preparato la puntata era già programmata ma ho deciso di sospenderla perché questa notte è successo qualcosa di veramente interessante ma prima di introdurvi l'argomento e di raccontarvi un po' cos'è successo e perché cosa mi ha spinto a portarlo qua in un episodio del del podcast vi devo ricordare i nostri contatti potete scrivermi @brainrepo su twitter oppure a info@gitbar.it inoltre tutte le puntate con relative note dell'episodio e trascrizione automatica le trovate su www.gitbar.it bene ricordati i nostri contatti è il momento di partire proviamo a capire cosa è successo stanotte perché ho cambiato idea per non pubblicare l'episodio che avevo già preparato.Stanotte è successa una cosa molto molto particolare infatti è avvenuto il più catastrofico attacco su Twitter l'attacco consisteva in una semplice truffa con tutta una serie di tweet che venivano da profili di personaggi famosi e che dicevano in poche parole "versatemi un tot in bitcoin io vi verserò il doppio giusto in modo da ringraziare la mia community che mi segue e mi sta accanto.Più o meno era questo il messaggio.Naturalmente ho visto tanti tweet hilari e simpatici per esempio quello di Jeff Bezos che scriveva appunto "Bezos è un po' visto come il tirchio tra gli ultramilionari" dice "se Jeff Bezos dà qualcosa indietro è è sicuramente una truffa.Però tweet simpatici a parte, in realtà questo tipo di truffa mette le basi su una serie di attacchi che risalgono al 2018, quando dei gruppi di truffatori hanno creato tutta una serie di account fake di Elon Musk, vittima anche della truffa di ieri sera.E utilizzavano tutta una serie di tecniche per amplificare la reach, quindi il numero di persone che potevano vedere il tweet tecniche che poi non erano altro che l'utilizzo di botnet per amplificare la reach oppure di reply, quindi risposte fatte a tweet dell'account ufficiale che in qualche modo permetteva l'acquisizione di legittimità naturalmente da questa esperienza, da questi fatti del 2018 una cosa si è notata chiara che le persone ci cascavano perché comunque questo tipo di tweet bastava andare a vedere le transazioni su quell'indirizzo bitcoin per vedere che comunque c'era del flusso quindi che c'erano delle persone che versavano dei bitcoin è emersa anche la lentezza nell'intervento di twitter ed è emerso anche una certa grinta nel reagire perché alle misure più repressive messe in atto da Twitter succedevano diciamo delle azioni ancora più forti da parte degli hacker quindi era un po' come fare il gioco del gatto e del topo rincorrersi con un obiettivo da parte degli hacker che oltre a naturalmente racimolare più soldi possibili volevano generare il più caos possibile.Caos che dopo due anni sono riusciti a fare.Perché? Perché pare che in realtà siano stati presi tutta una serie di account verificati, si parla di 359.000 account verificati che sono quelli che poi Twitter ha bloccato, per creare un problema in scala mastodontica.tra questi account ci sono quelli di Obama, quelli di Biden, quelli di Bezos, Bill Gates, persino quelli di Apple e Uber e naturalmente Elon Musk era in mezzo a questi pensate che con la stessa tecnica che vi ho raccontato prima quindi una truffa per la quale si chiedeva di versare un certo ammontare di bitcoin in cambio appunto del doppio sono stati raccolti nella prima ora circa 118 mila dollari.Naturalmente stiamo parlando di una cifra grandissima.Qualcuno faceva la battuta e dice "in un'ora sono stati raccolti quasi più denari del profitto di Twitter".E' una cosa simpatica, no? Visto che comunque Twitter ha dei grossi problemi di profittabilità.però diciamo che là è il problema e la portata del problema è una portata di scala gigantesca perché comunque tutti questi account verificati che non sono due, sono 359.000 hanno inciso comunque in una percezione di sicurezza stando alle dichiarazioni di Joseph Cox, spero si lega così, è un reporter esperto di sicurezza informatica a Vice pare che per l'hack sia stato usato un tool interno di twitter che appunto permette di gestire gli account e che attraverso questo tool sia stata cambiata l'ownership di questi account verificabili quindi la proprietà di questi account verificabili naturalmente twitter ha rimosso gli screenshot che erano stati pubblicati sulla stessa piattaforma e ha bloccato gli account che condividevano questi screenshot quindi ad oggi non sono disponibili degli screenshot di questo fantomatico pannello d'amministrazione che risulta accato Sempre stando alle indiscrezioni di Joseph Cox, pare che non si sia trattato di un caso di ingegneria sociale o di password non sicure o password riutilizzate, ma dipenda da un dipendente interno a Twitter che abbia in qualche modo divulgato e permesso l'accesso per effettuare questo tipo di truffa.E se così fosse, diciamo che è la seconda volta quest'anno, quindi in realtà probabilmente due o tre domande Jack Dorsey, CEO di Twitter, dovrà pur farsela.una cosa interessante è stato il fatto che twitter ha, in qualche modo è stata abbastanza fredda nel seguire questo tipo di fenomeno con appunto dei tweet infatti ha fatto due tweet durante il lasso di tempo in cui stava succedendo questa truffa il primo dove annunciava che c'era stato questo breach di sicurezza insomma questo problema e il secondo due ore dopo dove ha bloccato 359.000 account verificati tra questi account verificati come vi dicevo c'era l'account di Obama, di Joe Biden e di Jeff Bezos account che non potevano né twittare e né resettare la password adesso qua ed è uno dei motivi per cui vi sto parlando di questo mi sorge una domanda abbastanza spontanea Buona parte dei messaggi e delle informative che passano specie nel mondo statunitense passano attraverso Twitter.Anche informazioni di tipo critico, no? Per esempio la National Weather Service a Lincoln dà le informazioni relativa ai tornado.Nel momento in cui vengono bloccati 359.000 account, questo tipo di servizi che possono essere inquadrati come servizi critici non possono twittare, basti pensare che appunto la National Weather Service stava twittando un avviso di tornado e poi è sparita quindi in realtà la domanda che io mi pongo è oggi come oggi questo tipo di servizi vengono utilizzati anche in condizioni critiche e possono essere un servizio che viene utilizzato in condizioni critiche può essere vulnerabile ad attacchi di questa scala? Oppure possiamo utilizzare, stiamo facendo bene ad utilizzare i servizi di comunicazione general purpose per informazioni tipo critiche? Basti pensare che il presidente americano Donald Trump passa, non passa più comunicati stampa quasi, perché buona parte delle informazioni passano attraverso Twitter.Ma in un momento in cui degli hacker possono entrare su Twitter e far uscire dei messaggi a nome di personaggi famosi tra cui può esserci anche quello del presidente americano insomma qualche domanda me la metto la sicurezza nazionale se è legata a una piattaforma come Twitter qualche dubbio me lo metto è lo stesso dubbio che mi sommesso quando l'attuale presidente del consiglio italiano durante il periodo di covid faceva i suoi comunicati attraverso facebook lo faceva sotto forma di video e va bene ma può essere quello il canale istituzionale per comunicare e questo canale istituzionale a parte che appartiene a una società ma non voglio addentrarmi in discorsi di questo tipo per questo vi suggerisco magari il podcast data nightmare di vannini che mettono le note dell'episodio che tratta l'argomento in modo molto più profondo di come posso farlo io.Però nel momento in cui questo tipo di persone, questo tipo di strumenti vengono utilizzati per passare delle comunicazioni istituzionali non è permesso che abbiano questo tipo di vulnerabilità.Ma allora il problema quindi non è più solo un problema di minaccia della privacy ma è qualcosa anche di più vasto e di più grande portata come appunto la sicurezza nazionale riflettendo sull'accaduto mi sono reso conto che comunque tutti i prodotti che noi andiamo a realizzare come sviluppatori devono comunque garantire un'unità minima di sicurezza dove per minima intendo essenziale anche perché come ben sappiamo la sicurezza assoluta non esiste e non possiamo delegare la responsabilità della sicurezza solo ai framework che usiamo ma dobbiamo esserne in qualche modo pienamente consapevoli allora facevo una riflessione sulla sicurezza dei pannelli di amministrazione solitamente le nostre applicazioni in buona parte dei casi sono dotate di pannelli di amministrazione questi pannelli d'amministrazione sono come la chiave magica che permette l'accesso ai dati della nostra applicazione quindi sono uno degli elementi più vulnerabili della nostra stessa applicazione allora cosa ho pensato riflettendo su come mettere in sicurezza i pannelli d'amministrazione? il primo ragionamento che ho fatto è quello di dividere la nostra applicazione in due parti la parte userland e la parte amministrazione e rendere isolate le due parti.Questa azione si contrappone a una cosa che vedo spesso che sono dei software dove non si riesce a percepire la differenza sostanziale tra pannello d'amministrazione e software stesso.Spesso appunto la gestione dei diritti è delegata ad aree specifiche di interfaccia o a funzionalità all'interno di una maschera generale.L'idea di dividere il pannello d'amministrazione dall'applicazione ci permette comunque di isolare completamente i due ambiti operativi.Isolando completamente quindi a livello di codice i due ambiti operativi abbiamo la certezza matematica che all'interno dell'applicazione in userland non ci sarà nessun caso in cui l'utente possa scavalcare, assumere il controllo di funzionalità d'amministrazione.Un'altra cosa molto interessante è quello di nascondere l'url per l'accesso ai pannelli di amministrazione cosa che con gli attuali framework è abbastanza facile basta semplicemente impostare o una configurazione un parametro in configurazione oppure una rotta e il consiglio che mi sento di dare o comunque la tecnica che io utilizzo è quello di non usare uno /admin per accedere all'area amministrativa ma magari mettere dei nomi che possono essere fuorvianti per esempio che ne so un url random di un titolo di un contenuto del vostro sito piuttosto che qualcosa di veramente random io per esempio metto aria beta o che ne so css quindi slash css le persone pensano a tutto tranne che a un pannello d'amministrazione facendo così in qualche modo si limitano tantissimo quelle azioni di scanning automatico che precedono l'utilizzo di un brute force per tentare l'accesso.Un'altra cosa molto interessante che secondo me possiamo fare per limitare anche nelle nostre per quanto piccole applicazioni i tentativi di hacking è per esempio limitare i tentativi di login.Infatti molti framework che ci sono in circolazione oggi permettono il login throttle, spero si dica così, quindi una funzione che non permette di provare un login più di un certo numero di volte in un lasso di tempo.Questo magari può essere legato all'indirizzo IP o può essere legato per esempio alla browser fingerprint che è un'impronta che in qualche modo possiamo generare dalla configurazione del browser che sta eseguendo perché si sa che le configurazioni del browser sono talmente particolari una volta che installiamo dei plug-in mettiamo degli elementi da essere quasi un'impronta digitale per il navigante facendo così riusciamo a limitare tantissimo le operazioni e i tentativi di brute forcing.Un'altra cosa interessante per limitare questo tipo di tentativi è per esempio non usare l'utente admin per l'accesso nel pannello d'amministrazione ma mettere randomi con non solo la password ma anche il nome utente.Questo limita ancora di gran lunga i tentativi d'accesso e aumenta naturalmente il numero di tentativi di accesso falliti.Certo può generare un po' di confusione nel primo periodo con il nostro cliente, il nostro utente, ma ci dà un grosso vantaggio.Ci dà il vantaggio che in realtà le operazioni di brute force debbano essere fatte non solo per la password ma anche per il nome utente.naturalmente non sto a dirvi che buona parte dei framework moderni utilizzano sistemi di two-factor authentication, basta di pensare ad outi, a google authenticator, a microsoft authenticator, tutte queste tecniche però sono inutili se poi andiamo a salvare le password in chiaro nel database quindi mi raccomando la parte importante è quello di andare a salvare le password criptate, alcune cose che vi sto dicendo vi potranno sembrare banali ma credetemi ad oggi in buona parte delle consulenze che faccio continuo a vedere password salvate in chiaro, sistemi nei quali è possibile entrare inserendo admin come nome utente oppure accedervi con uno /admin quindi anche se vi sembrano banali questo vuole essere un memo, non solo per chi sta sviluppando le applicazioni ma anche per me stesso perché comunque racimolare mettere insieme queste piccole buone pratiche sono degli accorgimenti e spesso si rivelano a livello pratico come qualche configurazione in più da fare e poco più ci permettono però di aumentare in modo significativo la sicurezza dell'applicazione che stiamo realizzando.un'altra cosa per esempio che molti trascurano o non ci pensano, main premise, è quello di per il pannello di amministrazione evitare per esempio di mettere la funzione di "forgot password" quindi di "restore della password dimenticata" per l'utente amministratore che solitamente non serve e soprattutto la cui funzionalità in cambio apre una breccia, una possibilità appunto di attacco perché il Forgot Password è una delle aree più sensibili nella sicurezza dei nostri pannelli d'amministrazione.Alcune cose che possiamo fare per esempio permettere l'accesso al pannello d'amministrazione, qua naturalmente emerge la necessità di dividere il pannello d'amministrazione dall'applicazione che stiamo facendo proprio a livello anche operativo spesso anche di macchina virtuale ha solo ad alcuni ip che possono essere o ip pubblici per esempio le ec2 di amazon quindi le macchine virtuali di amazon permettono appunto attraverso il loro firewall di abilitare alcuni ip oppure può essere un ip interno che sta dentro la vpn non vi sto a dire perché lo sapete benissimo che è indispensabile installare un certificato all'interno della macchina quindi per permettere la navigazione sotto forma di HTTPS in modo che tutto il traffico che noi facciamo verso questo pannello di amministrazione o che i nostri utenti fanno sia criptato così come un'altra cosa interessante che ho trovato utile negli anni è stata quella di bloccare l'accesso al database solo ad alcuni IP che sono le macchine in realtà che ci accedono quindi le macchine nelle quali gira la nostra applicazione.Ci sarebbero tantissime cose da dire per esempio il fatto di bloccare i MIME types negli upload oppure di aggiornare i framework o di verificare i permessi dei file però questo tipo di azioni sono indispensabili quando noi andiamo a sviluppare un'applicazione che non gira solo nel localhost ma che poi mettiamo in produzione.Come vi dicevo spesso sono accorgimenti anche marginali anche che ci rubano pochi pochi minuti ma che in realtà rendono la nostra applicazione sicura e quindi rendono i dati dei nostri utenti sicuri a loro volta che da una parte ci aiutano a essere un po' più compliant col GDPR.Dall'altra ci rendono consapevoli della responsabilità che abbiamo nel trattare i dati degli utenti perché noi non sappiamo o comunque possiamo solo immaginare la tipologia di dati che i nostri utenti andranno a salvare nella nostra applicazione.Ma l'importanza di questi dati in realtà nella vita di tutti i giorni del nostro utente questa la possiamo solo appunto immaginare per cui abbiamo la necessità periodicamente di farci questo tipo di domande e di darci delle risposte per cui sarebbe opportuno fermarsi magari ogni tanto ed è una cosa che io sto facendo da qualche tempo a questa parte per tanti anni non l'ho fatta e mi sono reso conto solo poi dell'importanza a chiedermi il valore che io sto dando al mio cliente attraverso l'applicazione che sto sviluppando è un valore che in qualche modo lo mette anche al riparo da certi rischi o per dare questo valore al mio cliente lo espongo a una quantità di rischi che spesso rischia di superare appunto il valore che io voglio fornire.Sono sicuro che questa puntata potrebbe entrare nella serie le seghe mentale dello sviluppatore.Abbiate pazienza ma avevo proprio l'esigenza di condividere con voi questo tipo di riflessione quindi questa questa serie appunto di passaggi che mi spingono quotidianamente a cercare di fare dei prodotti non solo migliori in termini di valore ma anche un pelino più sicuri.Vi anticipo che sto preparando una puntata con un esperto di sicurezza informatica di cui non vi dirò il nome fino all'uscita dell'episodio e un'altra dove andremo a parlare di Deploy con un altro ospite abbastanza importante.Detto questo e prima di lasciarvi vi ricordo i nostri contati potete iscrivervi a info@gitbar.it oppure su twitter @brainrepo.Tutte le informazioni degli episodi col file audio la trascrizione le note appunto della puntata le trovate su github.it vi ricordo che potete iscrivervi col vostro client di podcast per ricevere settimanalmente la nuova puntata solitamente usciamo il giovedì e solitamente usciamo attorno alle otto e mezza a parte questa settimana che come vi dicevo ho preferito uscire un pochino più tardi per registrare questa puntata all'ultimo minuto.Un saluto da Pontallier, spero si dica così nella France con te, ci sentiamo la prossima settimana con Gitbar.Ciao! Gitbar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta delle attrezzi dei Full Stack Dev.[Musica]
