Sicurezza

Crediamo che la privacy sia un diritto, non un privilegio, ed è radicata nelle fondamenta della nostra azienda. Utilizzando la X Developer Platform e rispettando la nostra policy per sviluppatori, svolgi un ruolo critico nell’assicurare che la piattaforma serva la conversazione pubblica su X e tuteli il nostro impegno per la privacy.

Vogliamo ricordarti l’importanza di sviluppare in modo sicuro per proteggere sia i tuoi dati sia quelli degli utenti delle tue App. È tua responsabilità difenderti dal rischio di violazioni della sicurezza, e condividiamo la responsabilità di proteggere le persone che usano X. Questa pagina descrive le aspettative per la creazione di applicazioni sicure e per mantenere data e accessi quanto più possibile al sicuro.

Tieni presenti le tecnologie di sicurezza disponibili per la X Developer Platform, tra cui authentication, TLS e app permissions, nonché — dalla prospettiva degli utenti di X — le indicazioni su using third party applications and sessions.

​

Segnalazione di problemi di sicurezza

Gli utenti della X Developer Platform devono notificare a X, entro e non oltre 48 ore dal primo sospetto che si sia verificato un incidente di sicurezza, tramite il programma di segnalazione delle vulnerabilità di X.

​

Best practice di sicurezza

Tienile presenti mentre sviluppi sulla piattaforma per sviluppatori di X e, più in generale, su Internet.

​

Sicurezza by design

Valuta di ingaggiare professionisti della sicurezza per eseguire un audit di threat modeling e/o un penetration test. Una buona società di sicurezza approfondirà l’analisi per individuare i problemi. Scopri di più su come X ha adottato questa mentalità nel nostro post sul blog.

Inoltre, X ritiene tutti i partner responsabili di quanto segue:

• Mantenere il codice in un repository sicuro.
• Eseguire l’analisi dei rischi durante l’intero processo di Systems Development Life Cycle (SDLC).
• Garantire che i problemi di sicurezza siano identificati e mitigati lungo tutto l’SDLC.
• Garantire la segregazione degli ambienti durante il processo SDLC.
• Garantire che tutti i difetti rilevati nei test siano corretti, nuovamente testati e chiusi.

​

Monitora e ricevi avvisi

Se sospetti un problema con la tua web app, come puoi averne la certezza? Assicurati di mantenere log accurati e di ricevere notifiche per eccezioni ed errori critici. Potresti voler creare una dashboard con statistiche cruciali per capire a colpo d’occhio se qualcosa non va.

​

Crea un canale per le segnalazioni

Rendi facile per i tuoi utenti contattarti in merito a potenziali problemi di sicurezza riscontrati con la tua App. Se viene scoperto un problema che riguarda gli utenti di X e i relativi data, è tua responsabilità segnalare questo problema a X. Prepara inoltre un piano/processo d’azione per informare gli utenti interessati nel caso si verifichi un incidente di sicurezza.

​

Test adeguati

Assicurati che i test end-to-end siano approfonditi e aggiornati, includendo i fallimenti attesi per scenari di sicurezza come l’accesso non autorizzato. Adotta la prospettiva di un aggressore e configura test di sistema che siano progettati per bloccare tentativi di ottenere accesso non autorizzato ai data di X o di utilizzare funzionalità autorizzate in modo improprio.

​

Proteggere API Key e token

Come sviluppatore sulla piattaforma X, hai accesso programmatico sia ai tuoi dati sia a quelli dei tuoi utenti archiviati da X, a condizione che abbiano autorizzato la tua App sviluppatore. Tutte le richieste all’API devono essere autenticate tramite OAuth con la key e la secret della tua App sviluppatore e, in alcuni casi, con gli Access Tokens dell’utente autorizzante. È tua responsabilità mantenere al sicuro le tue credenziali.

Alcune buone pratiche consigliate includono:

• Impostare una rotazione per il rinnovo di password/token.
• Cifrare sempre i dati sensibili quando necessario ed evitare di decifrarli troppo a monte.
• Archiviare gli Access Tokens dei tuoi utenti in un archivio cifrato.
• Rigenerare o invalidare chiavi e token se ritieni che siano stati compromessi.

Per ulteriori discussioni su debug e sviluppo con OAuth per X, visita la categoria sicurezza del forum della community.

​

Validazione dell’input

Non dare per scontato che gli utenti forniscano dati validi e affidabili. Pulisci e normalizza tutti i dati degli utenti che possono confluire nelle richieste alla X API. Definisci una allowlist dei tipi di input accettati dall’applicazione ed elimina tutto ciò che non è presente nella allowlist.

​

Comunicazione crittografata

X richiede che tutte le richieste API siano effettuate tramite TLS. Anche la comunicazione con i tuoi server dovrebbe essere crittografata ove possibile.

​

Informazioni di debug esposte

Assicurati di non esporre dati sensibili di X o credenziali tramite schermate o log di debug. Alcuni framework web consentono di accedere facilmente a informazioni di debug se l’applicazione non è configurata correttamente. Per gli sviluppatori desktop e mobile, è facile distribuire per errore una build con flag o simboli di debug abilitati. Includi controlli per queste configurazioni nel processo di build/distribuzione. Inoltre, se condividi stack trace o crash dump ai fini della segnalazione, assicurati che i dati degli utenti X privati siano oscurati.

​

Input non filtrato, output non eseguito con escape

Un approccio facile da ricordare per la convalida dell’input è FIEO: Filtra l’input, esegui l’escape dell’output.

Filtra qualsiasi dato proveniente dall’esterno della tua applicazione, inclusi i dati della X API, i cookie, i dati immessi dagli utenti nei moduli, i parametri dell’URL, i dati provenienti dai database, ecc. Esegui l’escape di tutto l’output generato dalla tua applicazione, inclusi le istruzioni SQL inviate al server database, l’HTML che invii ai browser degli utenti, l’output JSON inviato ad altri sistemi e i comandi inviati ai programmi della shell.

​

Cross-site scripting (XSS)

Gli attacchi XSS sono, secondo la maggior parte degli indicatori, la forma più comune di problema di sicurezza sul web. Se un aggressore riesce a inserire il proprio codice JavaScript nella tua applicazione, può fare cose dannose. Ovunque tu memorizzi e visualizzi dati non attendibili forniti dagli utenti, è necessario verificarli, sanificarli ed eseguire l’escape HTML. Farlo correttamente è difficile, perché gli hacker dispongono di molti modi diversi per portare a termine attacchi XSS. Il tuo linguaggio o framework di sviluppo web probabilmente offre un meccanismo diffuso e ben collaudato per difendersi dal cross-site scripting; assicurati di utilizzarlo.

​

SQL injection

Se la tua applicazione utilizza un database, devi conoscere la SQL injection. Qualsiasi punto in cui accetti input può essere un potenziale bersaglio per un attaccante che cerchi di evadere dal campo di input ed entrare nel tuo database. Usa librerie per database che proteggano in modo sistematico dalla SQL injection. Se esci da questo approccio e scrivi SQL personalizzato, crea test rigorosi per assicurarti di non esporti a questa forma di attacco. I due approcci principali per difendersi dalla SQL injection sono: eseguire l’escaping prima di costruire l’istruzione SQL e utilizzare input parametrizzati per creare le istruzioni. Si raccomanda il secondo, in quanto meno soggetto a errori da parte degli sviluppatori.

​

Cross-site request forgery (CSRF)

Sei sicuro che le richieste alla tua applicazione provengano davvero dalla tua applicazione? Gli attacchi CSRF sfruttano questa incertezza costringendo gli utenti autenticati del tuo sito ad aprire in modo silenzioso URL che eseguono azioni. Nel caso di un’App sviluppatore, ciò potrebbe significare che gli aggressori stanno usando la tua App per costringere gli utenti a pubblicare Tweet indesiderati o a seguire account di spam.

Il modo più efficace per gestire il CSRF è includere un token casuale in ogni form e conservarlo in un contesto affidabile; se un form non presenta il token corretto, genera un errore. I framework web moderni offrono metodi sistematici per gestire questo aspetto e, con un po’ di fortuna, potrebbero persino farlo per impostazione predefinita. Un semplice passaggio preventivo (ma non l’unico che dovresti adottare) è richiedere che qualsiasi azione che crea, modifica o elimina dati utilizzi una richiesta POST.

​

Assenza di limiti di velocità

Usa i CAPTCHA, quando opportuno, per rallentare potenziali spammer e attacker.

---

Se hai individuato un problema di sicurezza che riguarda direttamente X, disponiamo di un programma di bug bounty per le vulnerabilità.