Come convalidare se una libreria JavaScript è sicura?

16

Sono lo sviluppatore principale di una libreria JavaScript Open Source. Quella libreria viene utilizzata nell'azienda per cui lavoro, per diversi clienti. Ogni tanto c'è un cliente che si sente paranoico nell'implementare una biblioteca di cui non ha mai sentito parlare e mi chiede perché dovrebbe fidarsi di questo codice.

Comprendo la preoccupazione e di solito li indirizza a un repository github in cui è ospitata la libreria e mostro altri progetti e client che utilizzano la stessa libreria. A volte riesaminano il codice su github e tutto procede liscio dopo.

Ma questa volta il cliente è un po 'più paranoico. Mi ha chiesto che tipo di controllo di sicurezza ha avuto la libreria e mi ha detto che i loro sistemi sono "validati con i primi 10 controlli OWASP / scansioni".

Dopo alcune ricerche la cosa più vicina che ho trovato è questo documento che elenca le 10 vulnerabilità principali nelle applicazioni web nel 2010, da OWASP.

Penso che non tutti questi si applicano, dal momento che non sto fornendo un'applicazione web ma solo una libreria javascript. E la mia comprensione è che queste vulnerabilità la maggior parte delle volte devono essere controllate manualmente da uno specialista della sicurezza piuttosto che da una scansione automatica.

Ora alle mie domande:

  • C'è un modo per affermare gli standard di sicurezza in una libreria JavaScript?
  • C'è qualche strumento in grado di scansionare JavaScript per minacce alla sicurezza?

UPDATE 1

Anche se non sono un esperto in sicurezza, sono uno sviluppatore web e comprendo i difetti comuni che possono causare vulnerabilità alle applicazioni Web. Ciò di cui ho bisogno è un modo per dimostrare in particolare a una persona non tecnica che questa libreria è stata controllata almeno per minacce minime e exploit ed è in effetti sicura per essere utilizzata sul loro sito web.

Ciò che mi viene in mente è forse una società neutrale o un consulente specializzato in sicurezza web in grado di revisionare il codice e attestarne la qualità. È una pratica comune?

UPDATE 2

Immagina che qualcuno ti dia un grande file javascript da includere nel tuo sito come parte di un'integrazione. Questo script verrà eseguito all'interno del tuo sito e. Probabilmente vuoi essere sicuro da dove viene quel file e chi è stato lo sviluppatore che lo ha creato. Immagina che qualche sviluppatore disonesto su Facebook abbia deciso di inserire del codice maligno all'interno dello script simile per rubare dati o cookie dai siti in cui viene eseguito.

Quando includi librerie di aziende ben conosciute o progetti Open Source che vengono esaminati da più persone (come jQuery) questo è un caso molto improbabile. Ma quando includi uno script da una piccola azienda o da uno sviluppatore solista, posso considerarlo un problema.

Non voglio cercare exploit nella mia biblioteca, perché so di averne incluso nessuno. Voglio solo dimostrare in qualche modo che il codice è sicuro, quindi gli utenti non hanno questo tipo di preoccupazione quando lo usano.

    
posta Eduardo Cereto 26.10.2012 - 03:02
fonte

6 risposte

18

Per evitare problemi di sicurezza sul lato client, è necessario conoscere i requisiti di sicurezza per il codice lato client e gli errori comuni. OWASP ha buone risorse. Assicurati di leggere su XSS basato su DOM, poiché questo è uno degli errori di sicurezza più comuni.

Per quanto riguarda le best practice sulla sicurezza, ho diversi suggerimenti:

  • Per evitare XSS, rispettare le regole trovate in Adam Barth su Tre semplici regole per costruire XSS- applicazioni web gratuite .

  • Evita setInnerHtml() e .innerHtml = . Invece, usa setInnerText() o operazioni basate su DOM (per assicurarti di non introdurre tag script, ad es. Per evitare XSS basato su DOM). Evita document.write() .

  • Evita eval() . Il suo uso tende ad essere correlato a difetti di sicurezza. Allo stesso modo, evita altre API che trasformano una stringa in codice e la eseguono, come setTimeout() con un argomento stringa, setInterval() con un argomento stringa o new Function() .

  • Attiva Javascript "modalità rigorosa" . Aiuta a evitare alcune aree sottili di Javascript che sono state prima responsabili di problemi di sicurezza.

  • Assicurati che il tuo codice sia compatibile con una rigorosa norme sulla sicurezza dei contenuti (ecco un tutorial ), come script-src 'self'; object-src 'self' .

Vedi anche Preoccupazioni per la sicurezza sul clientide (Javascript) , che si trova su un argomento correlato.

Non conosco alcuno strumento di analisi statica per scansionare Javascript e cercare problemi di sicurezza.

Se segui le raccomandazioni di Doug Crockford su come utilizzare Javascript (ad esempio, come per il suo libro, Javascript: The Good Parts), puoi usare JSLint . È uno strumento piuttosto delicato e aggressivo. Se il tuo codice è JSLint-clean, questo è un segno positivo. Ma JSLint non è focalizzato principalmente sulla sicurezza. E se prendi il codice legacy ed esegui JSLint su di esso, probabilmente verrai sommerso da una serie di avvertimenti.

    
risposta data 26.10.2012 - 03:17
fonte
5

La prassi standard prevede che il tuo cliente intraprenda un test di sicurezza, ma vedo che più sviluppatori assumono i tester della sicurezza per fornire una certa garanzia al cliente.

Ma non c'è modo di dire "questo codice è garantito sicuro" - c'è solo "questo codice sembra appropriatamente sicuro" o "adatto allo scopo"

    
risposta data 26.10.2012 - 09:12
fonte
1

Penso che ciò che vuoi sia fondamentalmente impossibile - affermare che un programma fa o non fa una cosa (non specificata) dannosa equivale al problema dell'arresto. Soprattutto, considera che javascript fa parte di un complesso ecosistema di software interattivo. Gli exploit non sono necessariamente così semplici come scrivere una funzione chiamata steal_cookies_and_send_to_bad_guys.

Quindi, dal momento che è impossibile, il meglio che puoi fare è far ispezionare il codice da qualcuno che dovrebbe essere in grado di individuare alcune "specie conosciute" di malware, e magari formarsi un'opinione che sia altrimenti sopra scritto e ben scritto.

    
risposta data 26.10.2012 - 09:20
fonte
1

Un'opzione è sandboxing o riscrittura del javascript. Ecco alcune cose in questa direzione.

link

Google JSand Sandboxing lato client di javascript

Isolamento basato su lingua di Google di javascript non attendibile di maffeis

    
risposta data 04.06.2013 - 04:36
fonte
1

La maggior parte degli scanner di codici commerciali (IBM, HP Fortify, Checkmarx, Veracode, ecc.) scansionano JavaScript. Io personalmente ho usato solo Checkmarx e funziona bene, ma non ho fatto alcun confronto.

    
risposta data 22.07.2013 - 09:49
fonte
-1

@ edwardo-cereto Ho usato un certo numero di applicazioni, tra cui Appscan Source, che fornisce una copertura del codice JavaScript molto profonda. Sfortunatamente, la maggior parte delle applicazioni per JavaScript sono commerciali. Il suggerimento di jslint è buono. Potrebbe non includere il filtraggio dell'input dell'utente e più casi d'uso specifici per le applicazioni web, ma è un buon inizio.

Ho guardato Ratproxy qualche tempo fa, ma era ancora un'applicazione matura e non era utile per quello che stavo cercando.

    
risposta data 20.03.2017 - 19:45
fonte

Leggi altre domande sui tag