{"id":84184,"date":"2020-06-05T19:42:31","date_gmt":"2020-06-05T17:42:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god"},"modified":"2020-06-05T19:42:31","modified_gmt":"2020-06-05T17:42:31","slug":"smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","title":{"rendered":"Peccati mortali di sicurezza del sito: cosa abbiamo appreso dalle statistiche dello scanner di vulnerabilit\u00e0 nell'ultimo anno","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Circa un anno fa, noi di DataLine abbiamo lanciato servizio<\/a><\/noindex> per la ricerca e l'analisi delle vulnerabilit\u00e0 nelle applicazioni IT. Alla base del servizio c'\u00e8 la soluzione cloud di Qualys, di cui abbiamo gi\u00e0 parlato<\/a><\/noindex>. In un anno di utilizzo della soluzione abbiamo effettuato 291 scansioni per diversi siti e accumulato statistiche sulle vulnerabilit\u00e0 comuni nelle applicazioni web.\u00a0<\/p>\n

Nell'articolo qui sotto mostrer\u00f2 quali falle nella sicurezza dei siti si nascondono dietro i diversi livelli di criticit\u00e0. Vediamo quali vulnerabilit\u00e0 lo scanner ha trovato con maggiore frequenza, perch\u00e9 possono sorgere e come proteggersi.\u00a0<\/p>\n

\"Peccati
\n<\/a><\/noindex>
\nQualys suddivide tutte le vulnerabilit\u00e0 delle applicazioni web in tre livelli di criticit\u00e0: basso, medio e alto. Se guardiamo alla distribuzione in base alla \"gravit\u00e0\", sembra che non sia cos\u00ec male. Ci sono poche vulnerabilit\u00e0 ad alto livello di criticit\u00e0, la maggior parte sono non critiche:\u00a0<\/p>\n

\"Peccati
\n
\nMa non critiche non significa innocue. Possono comunque causare danni seri.\u00a0<\/p>\n

Le principali vulnerabilit\u00e0 \"non critiche\"<\/h2>\n

<\/p>\n

    \n
  1. Vulnerabilit\u00e0 legate a contenuti misti.<\/b>\n

    Lo standard di sicurezza dei siti prevede la trasmissione dei dati tra client e server tramite il protocollo HTTPS, che supporta la crittografia e protegge le informazioni da intercettazioni.\u00a0<\/p>\n

    Alcuni siti utilizzano contenuti misti<\/i>: trasmettono parte dei dati tramite il protocollo non sicuro HTTP. Pi\u00f9 frequentemente si trasmettono contenuti passivi<\/i> \u2013 informazioni che influenzano solo la visualizzazione del sito: immagini, stili css. Ma a volte si trasmettono anche contenuti attivi<\/i>: script che controllano il comportamento del sito. In questo caso, attraverso software specifico, \u00e8 possibile analizzare le informazioni in arrivo dal server con contenuti attivi, modificare le proprie risposte al volo e far funzionare il computer in modo diverso da quanto previsto dai suoi creatori.\u00a0<\/p>\n

    I browser delle versioni pi\u00f9 recenti avvertono gli utenti che i siti con contenuti misti non sono sicuri e bloccano il contenuto. Anche i sviluppatori di siti ricevono avvisi dal browser nella console. Ad esempio, cos\u00ec appare in Firefox<\/a><\/noindex>:\u00a0<\/p>\n

    \"Peccati
    \n
    \nQuali sono i rischi<\/b>: Gli attaccanti utilizzano il protocollo non sicuro per intercettare informazioni sull'utente, sostituire script e inviare richieste al sito a suo nome. Anche se il visitatore del sito non ha inserito dati, non lo protegge da phishing <\/i>\u2013 estrazione di informazioni riservate con metodi fraudolenti. Ad esempio, tramite uno script si pu\u00f2 reindirizzare l'utente a un sito non sicuro, mascherato da uno a lui familiare. In alcuni casi, il sito malevolo appare anche migliore dell'originale, e l'utente pu\u00f2 autonomamente compilare un modulo e trasmettere dati riservati.\u00a0<\/p>\n

    Cosa ricordare per uno sviluppatore web<\/b>: Anche se l'amministratore del sito ha installato e configurato un certificato SSL\/TLS, la vulnerabilit\u00e0 pu\u00f2 sorgere a causa del fattore umano. Ad esempio, se su una pagina \u00e8 stato inserito un link assoluto con http invece di uno relativo e, inoltre, non sono stati configurati i redirect da http a https.\u00a0<\/p>\n

    Per rilevare contenuti misti su un sito, \u00e8 possibile utilizzare il browser: cercare nel codice sorgente della pagina, leggere le notifiche nella console dello sviluppatore. Tuttavia, lo sviluppatore dovr\u00e0 scavare a lungo e con difficolt\u00e0 nel codice. \u00c8 possibile accelerare il processo utilizzando strumenti di analisi automatizzati, per esempio: SSL Check<\/a><\/noindex>, software open source Lighthouse o software a pagamento Screaming Frog SEO Spider.<\/p>\n

    Inoltre, le vulnerabilit\u00e0 possono sorgere a causa di problemi con il legacy code \u2013 il codice ereditato. Ad esempio, se una parte delle pagine \u00e8 generata da un vecchio modello che non tiene conto della transizione dei siti a https.\u00a0\u00a0\u00a0\u00a0\n<\/li>\n

  2. Cookie senza i flag \"HTTPOnly\" e \"secure\".<\/b>\n

    L'attributo \"HTTPOnly\" protegge i file cookie dall'essere elaborati da script che i malintenzionati utilizzano per rubare i dati degli utenti. Il flag \"secure\" non consente la trasmissione dei cookie in chiaro. Lo scambio di dati sar\u00e0 consentito solo se i cookie vengono inviati tramite il protocollo sicuro HTTPS.\u00a0<\/p>\n

    Entrambi gli attributi devono essere specificati nelle propriet\u00e0 dei cookie:<\/p>\n

    Set-Cookie: Secure; HttpOnly<\/code><\/pre>\n
    \nQuali sono i rischi<\/b>: Se lo sviluppatore del sito non ha indicato questi attributi, un malintenzionato pu\u00f2 intercettare le informazioni dell'utente dai cookie e abusarne. Se i cookie vengono utilizzati per l'autenticazione e l'autorizzazione, sar\u00e0 in grado di rubare la sessione dell'utente e compiere azioni sul sito a suo nome.\u00a0<\/p>\n
    Cosa ricordare per uno sviluppatore web<\/b>: In genere, nei framework popolari, questi attributi vengono impostati automaticamente. Ma controlla comunque la configurazione del server web e imposta il flag: Set-Cookie HttpOnly; Secure. <\/p>\n
    In questo modo, l'attributo \"HTTPOnly\" render\u00e0 i cookie invisibili anche al tuo stesso JavaScript.\u00a0\u00a0\n<\/li>\n
  3. Vulnerabilit\u00e0 basate sui percorsi.<\/b>\n
    Lo scanner segnala tale vulnerabilit\u00e0 se trova file o directory del sito accessibili al pubblico con informazioni potenzialmente riservate. Ad esempio, rileva singoli file di configurazione del sistema o accesso all'intero file system. Questa situazione \u00e8 possibile se i diritti di accesso sul sito sono stati configurati in modo errato.<\/p>\n
    Quali sono i rischi<\/b>: Se il file system \u00e8 \"esposto\", un malintenzionato pu\u00f2 accedere all'interfaccia del sistema operativo e provare a cercare cartelle con password, se vengono conservate in chiaro (non fatelo!). Oppure pu\u00f2 rubare gli hash delle password e tentare di indovinare la password attraverso un attacco di forza bruta, oltre a cercare di ottenere privilegi nel sistema e avanzare nella rete.\u00a0\u00a0<\/p>\n
    Cosa ricordare per uno sviluppatore web<\/b>: Non dimenticate i diritti di accesso e configurate la piattaforma, il server web e l'applicazione web in modo che non sia possibile \"fuggire\" dalla directory web.\n<\/li>\n
  4. Forme per l'inserimento di dati sensibili con la funzione di completamento automatico attivata.<\/b>\n
    Se un utente compila frequentemente moduli sui siti, il suo browser conserva queste informazioni tramite la funzione di completamento automatico.\u00a0<\/p>\n
    I moduli sui siti possono includere campi con informazioni riservate, come password o numeri di carte di credito. Per tali campi, \u00e8 opportuno disattivare la funzione di completamento automatico sul sito stesso.\u00a0<\/p>\n
    Quali sono i rischi<\/b>: Se il browser dell'utente salva informazioni riservate, un malintenzionato potrebbe intercettarle in seguito, ad esempio tramite phishing. In sostanza, il web developer che dimentica questo aspetto mette a rischio i propri utenti.\u00a0<\/p>\n
    Cosa ricordare per uno sviluppatore web<\/b>: In questo caso abbiamo un conflitto classico: comodit\u00e0 vs sicurezza. Se il web developer si preoccupa del comfort dell'utente, potrebbe scegliere consapevolmente il completamento automatico. Ad esempio, se \u00e8 importante seguire Web Content Accessibility Guidelines<\/a><\/noindex> \u2013 raccomandazioni per l'accessibilit\u00e0 dei contenuti per utenti con disabilit\u00e0.\u00a0<\/p>\n
    Per la maggior parte dei browser, si pu\u00f2 disattivare il completamento automatico utilizzando l'attributo autocompete=\"off\", ad esempio:<\/p>\n
    \u00a0<body>\n    <form action="\/it\/form\/submit\/" method="get" autocomplete="off" data-trp-original-action="\/form\/submit">\n      <div>\n        <input type="text" placeholder="Nome">\n      <\/div>\n      <div>\n        <input type="text" id="lname" placeholder="Cognome" autocomplete="on">\n      <\/div>\n      <div>\n        <input type="number" placeholder="Numero di carta di credito">\n      <\/div>\n      <input type="submit">\n    <input type="hidden" name="trp-form-language" value="it"\/><\/form>\n  <\/body><\/code><\/pre>\n
    \nMa per Chrome non funziona. Questo pu\u00f2 essere aggirato utilizzando JavaScript, una variante della soluzione pu\u00f2 essere trovata qui<\/a><\/noindex>.\u00a0\n<\/li>\n
  5. Nella codifica del sito non \u00e8 stato impostato l'intestazione X-Frame-Options.\u00a0<\/b>\n
    Questo titolo influisce sui tag frame, iframe, embed o object. Con esso, puoi vietare completamente l'incorporamento del tuo sito all'interno di un frame. Per fare ci\u00f2, \u00e8 necessario specificare il valore X-Frame-Options: deny. In alternativa, puoi specificare X-Frame-Options: sameorigin, rendendo cos\u00ec l'incorporamento in iframe disponibile solo sul tuo dominio.<\/p>\n
    Quali sono i rischi<\/b>: L'assenza di questo header pu\u00f2 essere sfruttata su siti malevoli per clickjacking<\/i>. In questo tipo di attacco, l'attaccante crea un frame trasparente sopra i pulsanti e inganna l'utente. Per esempio: i truffatori inseriscono nel frame pagine dei social media. L'utente pensa di cliccare su un pulsante su quel sito. Invece, il clic viene intercettato e invia la richiesta dell'utente al social network, dove esiste una sessione attiva. Cos\u00ec gli attaccanti inviano spam a nome dell'utente o aumentano followers e like.\u00a0<\/p>\n
    Se non si vieta tale possibilit\u00e0, un attaccante potrebbe posizionare il pulsante della tua applicazione su un sito malevolo. Potrebbe essere interessato al tuo programma di affiliazione o ai tuoi utenti.\u00a0\u00a0<\/p>\n
    Cosa ricordare per uno sviluppatore web<\/b>: Una vulnerabilit\u00e0 pu\u00f2 sorgere se X-Frame-Options con un valore conflittuale \u00e8 impostato sul server web o sul bilanciatore di carico. In questo caso, il server e il bilanciatore sovrascriveranno semplicemente l'header, in quanto hanno una priorit\u00e0 pi\u00f9 alta rispetto al codice della parte backend.\u00a0\u00a0<\/p>\n
    I valori deny e sameorigin dell'header X-Frame-Options ostacoleranno il funzionamento di webvisor di Yandex. Per consentire l'uso di iframe per webvisor, \u00e8 necessario inserire una regola separata nelle impostazioni. Ad esempio, per nginx, puoi configurarlo in questo modo:<\/p>\n
    http{\n...\n\u00a0map $http_referer $frame_options {\n\u00a0\"~webvisor.com\" \"ALLOW-FROM http:\/\/webvisor.com\";\n\u00a0default \"SAMEORIGIN\";\n\u00a0}\n\u00a0add_header X-Frame-Options $frame_options;\n...\n}\n\n<\/code><\/pre>\n
    \n<\/li>\n
  6. Vulnerabilit\u00e0 PRSSI (Path-relative stylesheet import).\u00a0\u00a0<\/b>\n
    Questa \u00e8 una vulnerabilit\u00e0 nei fogli di stile del sito. Si verifica quando vengono utilizzati collegamenti relativi come href=\"\/somefolder\/styles.css\/\" per accedere ai file di stile. Un malintenzionato ne approfitter\u00e0 se trover\u00e0 un modo per reindirizzare l'utente a una pagina dannosa. La pagina sostituir\u00e0 il collegamento relativo nel proprio url e simuler\u00e0 una richiesta ai fogli di stile. Risulter\u00e0 in una richiesta simile a badsite.ru\/...\/somefolder\/styles.css\/, che sotto mentite spoglie pu\u00f2 eseguire azioni dannose.\u00a0<\/p>\n
    Quali sono i rischi<\/b>: Un truffatore potrebbe sfruttare questa vulnerabilit\u00e0 se trova un'altra falla nella sicurezza. Di conseguenza, \u00e8 possibile rubare dati utente dai cookie o dai token.<\/p>\n
    Cosa ricordare per uno sviluppatore web<\/b>: Imposta l'intestazione X-Content-Type-Options: nosniff. In questo caso, il browser verificher\u00e0 il tipo di contenuto per i fogli di stile. Se il tipo \u00e8 diverso da text\/css, il browser bloccher\u00e0 la richiesta.\n<\/li>\n<\/ol>\n
    <\/p>\n
    Vulnerabilit\u00e0 critiche<\/h2>\n
    <\/p>\n
      \n
    1. La pagina con il campo per la password viene trasmessa dal server su un canale non protetto (HTML form containing password field(s) is served over HTTP).<\/b>\n
      La risposta del server su un canale non crittografato \u00e8 vulnerabile ad attacchi di tipo \u00abMan in the middle\u00bb. Un malintenzionato pu\u00f2 intercettare il traffico e inserirsi tra il client e il server mentre la pagina viene dal server al client.\u00a0<\/p>\n
      Quali sono i rischi<\/b>: Un truffatore potrebbe sostituire la pagina e inviare all'utente un modulo per dati riservati, che verranno inviati al server del malintenzionato.\u00a0<\/p>\n
      Cosa ricordare per uno sviluppatore web<\/b>: Alcuni siti inviano agli utenti un codice usa e getta via email\/telefono invece della password. In questo caso, la vulnerabilit\u00e0 non \u00e8 cos\u00ec critica, ma il meccanismo complica la vita agli utenti.\n<\/li>\n
    2. Invio del modulo con login e password su un canale non protetto (Login Form Is Not Submitted Via HTTPS).<\/b>\n
      In questo caso, l'utente invia al server un modulo con login e password su un canale non crittografato.<\/p>\n
      Quali sono i rischi<\/b>: A differenza del caso precedente, questa \u00e8 una vulnerabilit\u00e0 critica. \u00c8 pi\u00f9 semplice intercettare dati riservati, poich\u00e9 non \u00e8 necessario scrivere codice per farlo.\u00a0\n<\/li>\n
    3. Utilizzo di librerie JavaScript con vulnerabilit\u00e0 note.<\/b>\n
      Durante il periodo di scansione, la libreria pi\u00f9 utilizzata \u00e8 diventata jQuery, con un ampio numero di versioni. In ciascuna di queste versioni c'\u00e8 almeno una, se non di pi\u00f9, vulnerabilit\u00e0 nota. L'impatto pu\u00f2 variare notevolmente \u2013 dipende dalla natura della vulnerabilit\u00e0.<\/p>\n
      Quali sono i rischi<\/b>: Esistono exploit per vulnerabilit\u00e0 note, come ad esempio:<\/p>\n
      \"Peccati
      \n
      \nCosa ricordare per uno sviluppatore web<\/b>: Torna regolarmente al ciclo: ricerca di vulnerabilit\u00e0 note \u2013 correzione \u2013 verifica. Se utilizzi librerie obsolete consapevolmente, ad esempio per supportare browser obsoleti o per risparmiare sul budget, cerca di eliminare le vulnerabilit\u00e0 note.\u00a0\n<\/li>\n
    4. Cross-Site Scripting (XSS).\u00a0<\/b>
      \nCross-Site Scripting (XSS), o script intersito, \u00e8 un attacco a un'applicazione web che si traduce nell'inserimento di codice dannoso nel database. Se Qualys riconosce una vulnerabilit\u00e0 di questo tipo, significa che un potenziale aggressore pu\u00f2 inserire o ha gi\u00e0 inserito nel codice del sito il proprio script js per eseguire azioni malevole.<\/p>\n
      XSS memorizzati (Stored XSS)<\/b> sono pi\u00f9 pericolosi, poich\u00e9 lo script viene inserito sul server e viene eseguito ogni volta che la pagina compromessa viene aperta nel browser.<\/p>\n
      XSS riflessi (Reflected XSS)<\/b> sono pi\u00f9 facili da realizzare, poich\u00e9 uno script malevolo pu\u00f2 essere inserito in una richiesta HTTP. L'applicazione riceve la richiesta HTTP, non verifica i dati, li confeziona e li invia immediatamente. Se l'aggressore intercetta il traffico e inserisce uno script come <\/p>\n
      <script>\/*+\u0447\u0442\u043e+\u0442\u043e+\u043f\u043b\u043e\u0445\u043e\u0435+*\/<\/script> <\/code><\/pre>\n
      \nverr\u00e0 inviato un richiesto malevolo a nome del cliente.<\/p>\n
      Un chiaro esempio di XSS: js-sniffer che simulano pagine per l'inserimento di CVC, data di scadenza della carta, e cos\u00ec via.\u00a0<\/p>\n
      Cosa ricordare per uno sviluppatore web<\/b>: Nella intestazione Content-Security-Policy, utilizza l'attributo script-src affinch\u00e9 il browser del cliente carichi ed esegua solo codice da una fonte fidata. Ad esempio, script-src 'self' consente solo gli script dal nostro sito nella whitelist.\u00a0
      \nLa miglior pratica \u00e8 il codice Inline: consenti solo javascript inline utilizzando il valore unsafe-inline. Questo valore consente di usare js\/css inline, ma non vieta l'inclusione di file js. In combinazione con script-src 'self', vietiamo l'esecuzione di script esterni.<\/p>\n
      Assicurati di registrare tutto utilizzando report-uri e osserva i tentativi di inserimento nel sito.\n<\/li>\n
    5. SQL injection.<\/b>
      \nLa vulnerabilit\u00e0 indica la possibilit\u00e0 di inserire nel sito codice SQL che accede direttamente al database. L'iniezione SQL \u00e8 possibile se i dati dell'utente non vengono estratti: non vengono verificati e vengono utilizzati direttamente nella richiesta. Ad esempio, ci\u00f2 accade se un modulo sul sito non verifica la coerenza dell'input con il tipo di dato.\u00a0<\/p>\n
      Quali sono i rischi<\/b>: Se un aggressore inserisce una richiesta SQL in tale modulo, pu\u00f2 compromettere il database o rivelare informazioni riservate.\u00a0<\/p>\n
      Cosa ricordare per uno sviluppatore web<\/b>: Non fidarti di ci\u00f2 che arriva dal browser. \u00c8 necessario proteggersi sia dal lato client che dal lato server.\u00a0<\/p>\n
      Sul lato client, scrivi controlli dei campi utilizzando JavaScript.\u00a0<\/p>\n
      Le funzioni incorporate nei framework popolari aiutano anche a eseguire l'escamotage dei caratteri sospetti sul server. \u00c8 anche consigliato utilizzare query parametrizzate per i database sul server.<\/p>\n
      Definisci dove si svolge l'interazione con il database nell'app web.\u00a0<\/p>\n
      L'interazione si verifica quando otteniamo qualche informazione: una richiesta con id (cambiamento id), creazione di un nuovo utente, nuovo commento, - nuove registrazioni nel database. Qui possono verificarsi sql injection. Anche se eliminiamo una registrazione dal database, potrebbe verificarsi un sql injection.\n<\/li>\n<\/ol>\n
      <\/p>\n
      Raccomandazioni generali<\/h2>\n
      \nNon reinventare la ruota - utilizza framework collaudati<\/b>. In generale, i framework popolari sono pi\u00f9 sicuri. Per .NET si tratta di ASP.NET MVC e 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 - Spring MVC.<\/p>\n
      Tieni d'occhio gli aggiornamenti del fornitore e aggiorna regolarmente<\/b>. Le vulnerabilit\u00e0 verranno scoperte, scriveranno un exploit, lo pubblicheranno e tutto ricomincer\u00e0 da capo. Iscriviti agli aggiornamenti per le versioni stabili dal fornitore del software.<\/p>\n
      Controlla i diritti di accesso<\/b>. Dal lato del server, tratta sempre il tuo codice come se fosse stato scritto dal tuo nemico pi\u00f9 odiato, desideroso di rompere il tuo sito, di compromettere l'integrit\u00e0 dei tuoi dati. In effetti, a volte \u00e8 proprio cos\u00ec.<\/p>\n
      Utilizza cloni, ambienti di test, e poi rilasciali in produzione<\/b>. Questo aiuter\u00e0, innanzitutto, a evitare errori e problemi nell'ambiente produttivo: l'ambiente produttivo genera denaro, e un'interruzione nell'ambiente produttivo \u00e8 critica. Quando aggiungi, correggi o chiudi qualche problema, \u00e8 importante lavorare prima in un ambiente di test, poi verificare la funzionalit\u00e0 e le vulnerabilit\u00e0 trovate, e solo dopo pianificare il lavoro con l'ambiente produttivo.\u00a0<\/p>\n
      Proteggi l'app web con Web Application Firewall<\/a><\/noindex> e integra con esso i rapporti dallo scanner delle vulnerabilit\u00e0<\/b>. Ad esempio, in DataLine viene utilizzato Qualys e FortiWeb come collegamento dei servizi.
      \n
      Fonte:       habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
      \u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434 \u043c\u044b \u0432 DataLine \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u043f\u043e\u0438\u0441\u043a\u0430 \u0438 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 \u0418\u0422-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445. \u0412 \u043e\u0441\u043d\u043e\u0432\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u2013 \u043e\u0431\u043b\u0430\u0447\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 Qualys, \u043f\u0440\u043e \u0440\u0430\u0431\u043e\u0442\u0443 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0443\u0436\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u043b\u0438. \u0417\u0430 \u0433\u043e\u0434 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u0440\u0435\u0448\u0435\u043d\u0438\u0435\u043c \u043c\u044b \u043f\u0440\u043e\u0432\u0435\u043b\u0438 291 \u0441\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0430\u0439\u0442\u043e\u0432 \u0438 \u043d\u0430\u043a\u043e\u043f\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0443 \u043f\u043e \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u043d\u044b\u043c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044f\u043c \u0432 \u0432\u0435\u0431-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.\u00a0 \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u043d\u0438\u0436\u0435 \u044f \u043f\u043e\u043a\u0430\u0436\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043c\u0435\u043d\u043d\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84185,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84184","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47I peccati mortali della sicurezza del sito: cosa abbiamo appreso dalle statistiche dello scanner delle vulnerabilit\u00e0 nell'ultimo anno | ProHoster","description":"Circa un anno fa abbiamo lanciato in DataLine un servizio per la ricerca e l'analisi delle vulnerabilit\u00e0 nelle applicazioni IT.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043c\u0435\u0440\u0442\u043d\u044b\u0435 \u0433\u0440\u0435\u0445\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0441\u0430\u0439\u0442\u0430: \u0447\u0442\u043e \u043c\u044b \u0443\u0437\u043d\u0430\u043b\u0438 \u0438\u0437 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0438 \u0441\u043a\u0430\u043d\u0435\u0440\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0437\u0430 \u0433\u043e\u0434 | ProHoster","og:description":"\u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434 \u043c\u044b \u0432 DataLine \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u043f\u043e\u0438\u0441\u043a\u0430 \u0438 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 \u0418\u0422-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-05T17:42:31+00:00","article:modified_time":"2020-06-05T17:42:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84184","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:03:50","updated":"2022-09-30 12:56:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=84184"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84184\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/84185"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=84184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=84184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=84184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}