Circa un annu fà, avemu lanciatu DataLine per circà è analizà e vulnerabilità in l'applicazioni IT. U serviziu hè basatu nantu à a suluzione Qualys nuvola, circa u funziunamentu di u quali . In u corsu di un annu di travagliu cù a suluzione, avemu realizatu 291 scans per diversi siti è statistiche accumulate nantu à e vulnerabilità cumuni in l'applicazioni web.
In l'articulu sottu, vi mustraraghju esattamente ciò chì i buchi in a sicurità di u situ web sò oculati daretu à diversi livelli di criticità. Videmu quali vulnerabilità u scanner hà trovu soprattuttu spessu, perchè puderanu esse, è cumu si prutegge.
Qualys divide tutte e vulnerabilità di l'applicazioni web in trè livelli di criticità: bassa, media è alta. Se fighjate à a distribuzione per "gravità", pare chì tuttu ùn hè micca cusì male. Ci sò pochi vulnerabili cù un altu livellu di criticità, per suprattuttu tutti ùn sò micca critichi:
Ma acriticu ùn significa micca innocu. Puderanu ancu causà danni seriu.
Top vulnerabilità "non-critica".
- Vulnerabilità di cuntenutu mistu.
U standard per a sicurità di u situ web hè u trasferimentu di dati trà u cliente è u servitore via u protocolu HTTPS, chì sustene a criptografia è prutegge l'infurmazioni da l'intercepzioni.
Certi siti usanu cuntenutu mistu: Certi dati sò trasferiti via u protocolu HTTP inseguru. Questu hè cumu si trasmette più spessu cuntenutu passivu - infurmazione chì afecta solu a visualizazione di u situ: ritratti, stili css. Ma qualchì volta questu hè cumu si trasmette cuntenutu attivu: scripts chì cuntrolanu u cumpurtamentu di u situ. In questu casu, utilizendu un software speciale, pudete analizà l'infurmazioni cù u cuntenutu attivu chì venenu da u servitore, mudificà e vostre risposti nantu à a mosca è fà chì a macchina travaglia in una manera chì ùn era micca pensata da i so creatori.
E versioni più recenti di i navigatori avvisanu l'utilizatori chì i siti cun cuntenutu mistu ùn sò micca sicuri è bluccà u cuntenutu. I sviluppatori di u situ web ricevenu ancu avvisi di navigatore in a cunsola. Per esempiu, questu hè cumu si vede :
Perchè hè periculosa?: L'attaccanti utilizanu un protokollu inseguru per intercepte l'infurmazioni di l'utilizatori, rimpiazzà scripts è mandà dumande à u situ in u so nome. Ancu s'ellu un visitatore di u situ ùn hà micca inseritu dati, questu ùn u pruteghja micca phishing - ottene infurmazione cunfidenziale cù metudi fraudulenti. Per esempiu, aduprendu un script, pudete reindirizzà l'utilizatore à un situ inseguru chì si maschera cum'è un familiar à l'utilizatore. In certi casi, u situ maliziusi pare ancu megliu cà l'uriginale, è l'utilizatore pò cumpiendu u furmulariu stessu è sottumette dati cunfidenziale.Ciò chì un sviluppatore web deve ricurdà: Ancu s'è l'amministratore di u situ hà stallatu è cunfiguratu un certificatu SSL / TLS, una vulnerabilità pò esce per errore umanu. Per esempiu, se in una di e pagine ùn mette micca un ligame relative, ma un ligame assolutu da http, è in più ùn avete micca stallatu redirects da http à https.
Pudete detectà u cuntenutu mistu in un situ cù un navigatore: cercate u codice fonte di a pagina, leghjite notificazioni in a cunsola di sviluppatore. In ogni casu, u sviluppatore duverà tinker cù u codice per un bellu pezzu è tediously. Pudete accelerà u prucessu cù strumenti d'analisi automatizati, per esempiu: , software Lighthouse gratuitu o software pagatu Screaming Frog SEO Spider.
Inoltre, a vulnerabilità pò esse per via di prublemi cù u codice legacy - codice chì era ereditatu. Per esempiu, se certi pagine sò generati cù un vechju mudellu, chì ùn piglia micca in contu a transizione di i siti à https.
- Cookies senza i bandieri "HTTPOnly" è "secure".
L'attributu "HTTPOnly" prutege i cookies da esse processati da scripts chì l'attaccanti utilizanu per arrubbari dati di l'utilizatori. A bandiera "sicura" ùn permette micca di mandà cookies in testu chjaru. A cumunicazione serà permessa solu se u protocolu HTTPS sicuru hè utilizatu per mandà cookies.
I dui attributi sò specificati in e proprietà di cookie:
Set-Cookie: Secure; HttpOnlyPerchè hè periculosa?: Se u sviluppatore di u situ ùn hà micca specificatu questi attributi, un attaccu puderia intercepte l'infurmazioni di l'utilizatore da a cookie è sfruttà. Se i cookies sò utilizati per l'autentificazione è l'autorizazione, ellu puderà chjappà a sessione di l'utilizatore è eseguisce azzione nantu à u situ in u so nome.
Ciò chì un sviluppatore web deve ricurdà: In regula, in i frameworki populari sti attributi sò stallati automaticamente. Ma ancu verificate a cunfigurazione di u servitore web è stabilisce a bandiera: Set-Cookie HttpOnly; Secure.
In questu casu, l'attributu "HTTPOnly" farà i cookies invisibili à u vostru propiu JavaScript.
- Vulnerabbilitati Path-Based.
U scanner informa una tale vulnerabilità se trova un schedariu accessibile publicamente o un repertoriu di u situ web cù infurmazione potenzialmente cunfidenziale. Per esempiu, detecta i schedarii di cunfigurazione di u sistema individuale o l'accessu à tuttu u sistema di schedari. Questa situazione hè pussibule se i diritti d'accessu sò stallati in modu incorrectu in u situ.
Perchè hè periculosa?: Se u sistema di fugliali "si ferma", un attaccu pò cascà in l'interfaccia di u sistema operatore è pruvate à truvà cartulare cù password si sò guardati in testu chjaru (ùn fate micca cusì!). O pudete arrubà l'hash di password è a forza bruta di a password, è ancu pruvà à elevà i privilegi in u sistema è si move più in l'infrastruttura.
Ciò chì un sviluppatore web deve ricurdà: Ùn vi scurdate di i diritti d'accessu è cunfigurà a piattaforma, u servitore web, l'applicazione web in modu chì hè impussibile di "scaparà" da u repertoriu web.
- Forme per inserisce dati sensibili cù u riempimentu automaticu attivatu.
Se un utilizatore compie spessu e forme nantu à i siti web, u so navigatore guarda sta informazione utilizendu a funzione di riempimentu automaticu.
Forme nantu à i siti web ponu include campi cù informazioni sensibili, cum'è password o numeri di carte di creditu. Per tali campi, vale a pena disattivà a funzione di autofill di forma in u situ stessu.
Perchè hè periculosa?: Se u navigatore di l'utilizatore guarda infurmazione sensitiva, un attaccu pò intercepte più tardi, per esempiu per via di phishing. In essenza, un sviluppatore web chì hà scurdatu di sta sfumatura hè stallatu i so utilizatori.
Ciò chì un sviluppatore web deve ricurdà: In questu casu, avemu un cunflittu classicu: comodità versus security. Se un sviluppatore web pensa à l'esperienza di l'utilizatori, pò sceglie cunscientemente l'autocomplete. Per esempiu, s'ellu hè impurtante di seguità - raccomandazioni per l'accessibilità di u cuntenutu per l'utilizatori cù disabilità.
Per a maiò parte di i navigatori, pudete disattivà l'autocomplete cù l'attributu autocompete="off", per esempiu:
<body> <form action="/co/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Ma ùn funziona micca per Chrome. Questu hè aggiratu cù JavaScript, una variante di a ricetta pò esse truvata .
- L'intestazione X-Frame-Options ùn hè micca stabilitu in u codice di u situ.
Questa intestazione affetta e tag di frame, iframe, incrustate o oggetti. Cù u so aiutu, pudete pruibisce completamente di incrustà u vostru situ in un quadru. Per fà questu, avete bisognu di specificà u valore X-Frame-Options: deny. O pudete specificà X-Frame-Options: sameorigin, allora l'incrustazione in un iframe serà dispunibule solu in u vostru duminiu.
Perchè hè periculosa?: L'absenza di un tali header pò ièssiri usatu in siti maliziusi à clickjacking. Per questu attaccu, l'attaccante crea un quadru trasparente nantu à i buttoni è inganna l'utilizatore. Per esempiu: scammers frame pages di rete suciale in un situ web. L'utilizatore pensa chì cliccà un buttone in stu situ. Invece, u clicu hè interceptatu è a dumanda di l'utilizatore hè mandata à a reta suciale induve ci hè una sessione attiva. Questu hè cumu l'attaccanti mandanu spam in nome di l'utilizatore o guadagnanu abbonati è piace.
Se ùn disattiveghjanu micca sta funzione, un attaccu pò mette u vostru buttone d'applicazione in un situ maliziusu. Pò esse interessatu in u vostru prugramma di riferimentu o i vostri utilizatori.
Ciò chì un sviluppatore web deve ricurdà: A vulnerabilità pò accade se X-Frame-Options cun un valore cunflittu hè stabilitu in u servitore web o l'equilibriu di carica. In questu casu, u servitore è l'equilibriu riscriveranu solu l'intestazione, postu chì anu una priorità più altu cumparatu cù u codice backend.
I valori di denegazione è listessa origine di l'intestazione X-Frame-Options interferiscenu cù u funziunamentu di u web viewer Yandex. Per permette l'usu di iframes per u web viewer, avete bisognu di scrive una regula separata in i paràmetri. Per esempiu, per nginx pudete cunfigurà cusì:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Vulnerabilità PRSSI (importazione di fogli di stile relative à Path).
Questa hè una vulnerabilità in u stilu di u situ. Succede se ligami relative cum'è href="/co/somefolder/styles.css/" sò usati per accede à i schedarii di stile. Un attaccu hà da prufittà di questu s'ellu trova un modu per reindirizzà l'utilizatore à una pagina maliciosa. A pagina inserirà un ligame relativo in u so url è simulerà una chjama di stile. Riceverete una dumanda cum'è badsite.ru/…/somefolder/styles.css/, chì pò fà azzione maliciosa sottu a forma di stile.
Perchè hè periculosa?: Un fraudeur puderia sfruttà sta vulnerabilità s'ellu trova un altru bughju di sicurità. In u risultatu, hè pussibule arrubbari dati di l'utilizatori da cookies o tokens.
Ciò chì un sviluppatore web deve ricurdà: Imposta l'intestazione X-Content-Type-Options à: nosniff. In questu casu, u navigatore verificarà u tipu di cuntenutu per i stili. Se u tipu hè altru da u testu / css, u navigatore bluccà a dumanda.
Vulnerabilità critica
- Una pagina cù un campu di password hè trasmessa da u servitore nantu à un canale inseguru (forma HTML chì cuntene campi di password hè servita nantu à HTTP).
A risposta da u servitore nantu à un canale micca criptatu hè vulnerabile à l'attacchi "Man in the middle". Un attaccu pò intercepte u trafficu è cuncessi trà u cliente è u servitore mentre a pagina viaghja da u servitore à u cliente.
Perchè hè periculosa?: U fraudster puderà rimpiazzà a pagina è mandà à l'utilizatore un furmulariu per dati cunfidenziale, chì andarà à u servitore di l'attaccante.
Ciò chì un sviluppatore web deve ricurdà: Certi siti mandanu à l'utilizatori un codice una volta per email / telefonu invece di una password. In questu casu, a vulnerabilità ùn hè micca cusì critica, ma u mecanismu complicà a vita di l'utilizatori.
- Invià un furmulariu cù login è password nantu à un canale inseguru (Formulu di login ùn hè micca sottumessu via HTTPS).
In questu casu, un furmulariu cù un login è una password hè mandatu da l'utilizatore à u servitore via un canale micca criptatu.
Perchè hè periculosa?: A cuntrariu di u casu precedente, questu hè digià una vulnerabilità critica. Hè più faciule per intercepte e dati sensittivi perchè ùn avete mancu bisognu di scrive codice per fà.
- Utilizà e librerie JavaScript cun vulnerabilità cunnisciute.
Durante a scansione, a biblioteca più utilizata era jQuery cù un vastu numeru di versioni. Ogni versione hà almenu una, o ancu più, vulnerabilità cunnisciute. L'impattu pò esse assai diffirenti sicondu a natura di a vulnerabilità.
Perchè hè periculosa?: Ci sò sfruttamenti per vulnerabili cunnisciuti, per esempiu:
Ciò chì un sviluppatore web deve ricurdà: Riturnà regularmente à u ciculu: cercate vulnerabili cunnisciute - correzione - verificate. Se utilizate librerie legacy deliberatamente, per esempiu per sustene i navigatori più vechji o per risparmià soldi, cercate l'uppurtunità di riparà una vulnerabilità cunnisciuta. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), o cross-site scripting, hè un attaccu à una applicazione web chì risultatu in malware chì hè introduttu in a basa di dati. Se Qualys trova una tale vulnerabilità, significa chì un attaccu potenziale pò o hà digià introduttu u so propiu script js in u codice di u situ per fà azzioni maliziusi.XSS archiviatu più periculosa, postu chì u script hè incrustatu in u servitore è eseguitu ogni volta chì a pagina attaccata hè aperta in u navigatore.
XSS riflessu più faciule da realizà postu chì un script maliziusu pò esse injected in una dumanda HTTP. L'applicazione riceverà una dumanda HTTP, ùn cunvalidarà micca e dati, l'imballerà è l'inviarà immediatamente. Se un attaccu intercepte u trafficu è inserisce un script like
<script>/*+что+то+плохое+*/</script>allora una dumanda maliciosa serà mandata in nome di u cliente.
Un esempiu impressiunanti di XSS: js sniffers chì simulanu e pagine per inserisce CVC, data di scadenza di a carta, etc.
Ciò chì un sviluppatore web deve ricurdà: In l'intestazione Content-Security-Policy, utilizate l'attributu script-src per furzà u navigatore di u cliente à scaricà è eseguisce solu codice da una fonte di fiducia. Per esempiu, script-src 'self' whitelists tutti i script da u nostru situ solu.
A megliu pratica hè u codice Inline: permette solu javascript inline usendu u valore unsafe-inline. Stu valore permette l'usu di inline js/css, ma ùn impedisce micca l'inclusione di i schedari js. In cumbinazione cù script-src 'self' disattivemu i script esterni da esse eseguiti.Assicuratevi di logà tuttu cù report-uri è fighjate i tentativi di implementà in u situ.
- Iniezioni SQL.
A vulnerabilità indica a pussibilità di injecting codice SQL in un situ web chì accede direttamente à a basa di dati di u situ web. L'iniezione SQL hè pussibule se e dati da l'utilizatore ùn sò micca screened: ùn hè micca verificatu per a correzione è hè immediatamente utilizatu in a dumanda. Per esempiu, questu succede se una forma in un situ web ùn verifica micca se l'input currisponde à u tipu di dati.Perchè hè periculosa?: Se un attaccante entra in una dumanda SQL in questa forma, pò crash a basa di dati o revelà infurmazione cunfidenziale.
Ciò chì un sviluppatore web deve ricurdà: Ùn fidate micca di ciò chì vene da u navigatore. Avete bisognu di prutezzione di u latu di u cliente è di u servitore.
Da u latu di u cliente, scrivite a validazione di u campu cù JavaScript.
E funzioni integrate in i frameworki populari aiutanu ancu à scappà di caratteri sospetti nantu à u servitore. Hè cunsigliatu ancu di utilizà e dumande di basa di dati parametrizzate nantu à u servitore.
Determina induve esattamente l'interazzione cù a basa di dati si faci nantu à l'applicazione web.
L'interazzione accade quandu avemu ricevutu ogni infurmazione: una dumanda cù un id (cambiamentu di id), a creazione di un novu utilizatore, un novu cumentu, o novi entrate in a basa di dati. Questu hè induve l'injections SQL ponu accade. Ancu s'è sguassate un record da a basa di dati, l'iniezione SQL hè pussibule.
Rispunsioni generale
Ùn reinventate micca a rota - utilizate frameworks pruvati. In regula, i quadri populari sò più sicuri. Per .NET - ASP.NET MVC è ASP.NET Core, per Python - Django o Flask, per Ruby - Ruby on Rails, per PHP - Symfony, Laravel, Yii, per JavaScript - Node.JS-Express.js, per Java - MVC di primavera.
Segui l'aghjurnamenti di u venditore è aghjurnà regularmente. Truvaranu una vulnerabilità, poi scriveranu un sfruttamentu, rendenu dispunibule publicamente, è tuttu succederà di novu. Abbonate à l'aghjurnamenti à e versioni stabili da u venditore di software.
Verificate i diritti d'accessu. In u latu di u servitore, sempre trattate u vostru còdice cum'è s'ellu, da a prima à l'ultima lettera, hè statu scrittu da u vostru nemicu più odiatu, chì vulete rompe u vostru situ, viola l'integrità di i vostri dati. Inoltre, qualchì volta questu hè veru.
Aduprate cloni, siti di teste, è dopu aduprate per a produzzione. Questu aiuterà, prima, per evità i sbagli è i sbagli in un ambiente produtivu: un ambiente produtivu porta soldi, un ambiente produtivu simplice hè criticu. Quandu aghjunghje, riparà o chjude ogni prublema, vale a pena di travaglià in un ambiente di prova, dopu cuntrollà e funziunalità è e vulnerabilità truvate, è dopu pianificà à travaglià cù l'ambiente di produzzione.
Prutegge a vostra applicazione web cù è integrate i rapporti da u scanner di vulnerabilità cun ellu. Per esempiu, DataLine usa Qualys è FortiWeb cum'è un bundle di servizii.
Source: www.habr.com