{"id":29957,"date":"2019-10-31T21:32:53","date_gmt":"2019-10-31T18:32:53","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1\/"},"modified":"2019-10-31T21:32:53","modified_gmt":"2019-10-31T18:32:53","slug":"skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","title":{"rendered":"Scannerizzazione delle vulnerabilit\u00e0 e sviluppo sicuro. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Scannerizzazione
\n
\nNell'ambito della professione, sviluppatori, pentester e esperti di sicurezza si trovano a dover affrontare processi come il Vulnerability Management (VM) e il (Secure) SDLC.
\nQuesti termini nascondono diversi set di pratiche e strumenti utilizzati, che si intrecciano tra loro, anche se i loro utilizzatori variano.<\/p>\n

Il progresso tecnico non \u00e8 ancora arrivato al punto da poter sostituire un'analisi umana della sicurezza delle infrastrutture e del software con un unico strumento.
\n\u00c8 interessante capire perch\u00e9 ci\u00f2 accada e quali problemi si devono affrontare.
\n<\/a><\/noindex><\/p>\n

Processi<\/h2>\n

\nIl processo di Vulnerability Management \u00e8 pensato per il monitoraggio continuo della sicurezza delle infrastrutture e della gestione delle patch.
\nIl processo di Secure SDLC \u00e8 progettato per garantire la sicurezza delle applicazioni durante lo sviluppo e l'operativit\u00e0.<\/p>\n

Una parte simile di questi processi \u00e8 il Vulnerability Assessment, ovvero la valutazione e lo scanning delle vulnerabilit\u00e0.
\nLa principale differenza nello scanning all'interno di VM e SDLC \u00e8 che nel primo caso l'obiettivo \u00e8 scoprire vulnerabilit\u00e0 conosciute nel software di terze parti o nella configurazione. Ad esempio, una versione obsoleta di Windows o una stringa community predefinita per SNMP.
\nNel secondo caso, invece, l'obiettivo \u00e8 scoprire vulnerabilit\u00e0 non solo nei componenti di terze parti (dipendenze), ma in primo luogo nel codice del nuovo prodotto.<\/p>\n

Questo genera differenze negli strumenti e negli approcci. A mio parere, la ricerca di nuove vulnerabilit\u00e0 nell'applicazione \u00e8 significativamente pi\u00f9 interessante, poich\u00e9 non si riduce a identificare le versioni, raccogliere banner, tentare password, ecc.
\nPer una scansione automatizzata di alta qualit\u00e0 delle vulnerabilit\u00e0 delle applicazioni, sono necessari algoritmi che considerano la semantica dell'applicazione, il suo scopo e le minacce specifiche.<\/p>\n

Un scanner infrastrutturale pu\u00f2 spesso essere sostituito da un timer, come ha detto avleonov<\/a><\/noindex>. Il punto \u00e8 che, puramente statisticamente, puoi considerare la tua infrastruttura vulnerabile se non l'hai aggiornata, ad esempio, per un mese.<\/p>\n

Strumenti<\/h2>\n

\nLa scansione, cos\u00ec come l'analisi della sicurezza, pu\u00f2 essere eseguita sia come black box che come white box.<\/p>\n

Black Box<\/h4>\n

\nDurante la scansione blackbox, lo strumento deve essere in grado di interagire con il servizio attraverso gli stessi interfacce usate dagli utenti.<\/p>\n

I scanner di infrastruttura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ecc.) cercano porte di rete aperte, raccolgono \"banner\", determinano le versioni del software installato e cercano nella loro base di conoscenza informazioni sulle vulnerabilit\u00e0 in queste versioni. Tentano anche di identificare errori di configurazione, come password di default o accesso aperto ai dati, cifrature SSL deboli, ecc.<\/p>\n

I scanner di applicazioni web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ecc.) possono anch'essi identificare componenti e versioni conosciute (ad esempio, CMS, framework, librerie JS). I principali passaggi di un scanner sono il crawling e il fuzzing.
\nDurante il crawling, lo scanner raccoglie informazioni sulle interfacce esistenti dell'applicazione e sui parametri HTTP. Nel fuzzing, vengono inseriti dati mutati o generati in tutti i parametri rilevati per provocare un errore e scoprire vulnerabilit\u00e0.<\/p>\n

Questi scanner di applicazioni appartengono alle categorie DAST e IAST \u2014 rispettivamente Dynamic e Interactive Application Security Testing.<\/p>\n

White Box<\/h4>\n

\nDurante la scansione whitebox ci sono maggiori differenze.
\nNel processo di scansione delle VM, scanner come Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ecc., spesso ottengono accesso ai sistemi eseguendo una scansione autenticata. In questo modo, lo scanner pu\u00f2 estrarre le versioni dei pacchetti installati e le impostazioni di configurazione direttamente dal sistema, senza dover indovinare tramite banner di servizi di rete.
\nLa scansione risulta cos\u00ec pi\u00f9 precisa e completa.<\/p>\n

Quando parliamo di scansione whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ecc.) delle applicazioni, ci riferiamo generalmente all'analisi statica del codice e all'uso di strumenti appropriati di classe SAST \u2014 Static Application Security Testing.<\/p>\n

Problemi<\/h2>\n

\nCi sono molteplici problemi legati alla scansione! La maggior parte di essi la affronto personalmente nel contesto della fornitura di servizi per la creazione di processi di scansione e sviluppo sicuro, cos\u00ec come durante le analisi di sicurezza.<\/p>\n

Metter\u00f2 in evidenza 3 principali gruppi di problemi, confermati anche da conversazioni con ingegneri e responsabili dei servizi di sicurezza informatica in diverse aziende.<\/p>\n

Problemi di scansione delle applicazioni web<\/h4>\n

<\/p>\n

    \n
  1. Difficolt\u00e0 nell'implementazione.<\/b> I scanner devono essere configurati, personalizzati per ogni applicazione, dedicare un ambiente di test per le scansioni e integrarsi nel processo CI\/CD per essere efficaci. Altrimenti, rischiano di diventare una procedura formale inutile che produce solo falsi allarmi.<\/li>\n
  2. Durata della scansione.<\/b> Anche nel 2019, i scanner hanno difficolt\u00e0 nella deduplicazione delle interfacce e possono impiegare giorni per scansionare mille pagine con 10 parametri ciascuna, considerandole diverse, anche se sono gestite dallo stesso codice. Tuttavia, \u00e8 necessario prendere decisioni rapide sui deployment in produzione durante il ciclo di sviluppo.<\/li>\n
  3. Raccomandazioni limitate.<\/b> I scanner forniscono raccomandazioni piuttosto generiche, e non sempre gli sviluppatori possono capire rapidamente come ridurre il livello di rischio, e soprattutto, se \u00e8 necessario farlo immediatamente o se si pu\u00f2 aspettare.<\/li>\n
  4. Impatto distruttivo sull'applicazione.<\/b> I scanner possono effettivamente realizzare un attacco DoS sull'applicazione e possono generare un numero elevato di entit\u00e0 o modificare quelle esistenti (ad esempio, creando decine di migliaia di commenti in un blog), quindi non \u00e8 consigliabile avviare scansioni in produzione senza giudizio.<\/li>\n
  5. Bassa qualit\u00e0 nella rilevazione delle vulnerabilit\u00e0.<\/b> I scanner solitamente utilizzano un insieme fisso di payload e possono facilmente trascurare una vulnerabilit\u00e0 che non rientra nello scenario di comportamento noto dell'applicazione.<\/li>\n
  6. Incomprensione delle funzionalit\u00e0 dell'applicazione da parte dello scanner.<\/b> Gli scanner non sanno cosa siano un \"internet banking\", un \"pagamento\", o un \"commento\". Per loro esistono solo link e parametri, quindi una vasta gamma di potenziali vulnerabilit\u00e0 logiche di business rimane completamente scoperta: non si accorgono di effettuare una doppia transazione, non riescono a visualizzare dati di altri utenti tramite ID o a gonfiare il saldo tramite arrotondamenti.<\/li>\n
  7. Incomprensione della semantica delle pagine da parte dello scanner.<\/b> Gli scanner non possono leggere FAQ, non riescono a riconoscere i captcha, non capiscono come registrarsi e che \u00e8 necessario effettuare il login di nuovo, non sanno che non si pu\u00f2 cliccare su \"logout\" e come si devono firmare le richieste quando si modificano i valori dei parametri. Di conseguenza, gran parte dell'applicazione potrebbe rimanere completamente non scansionata.<\/li>\n<\/ol>\n

    Problemi nella scansione del codice sorgente.<\/h4>\n

    <\/p>\n

      \n
    1. Falsi positivi.<\/b> L'analisi statica \u00e8 un compito complesso, che richiede spesso numerosi compromessi. Spesso si deve sacrificare la precisione, e anche i costosi scanner enterprise generano un'enorme quantit\u00e0 di falsi positivi.<\/li>\n
    2. Difficolt\u00e0 nell'implementazione.<\/b> Per aumentare la precisione e la completezza dell'analisi statica, \u00e8 necessario migliorare le regole di scansione, e la scrittura di queste regole pu\u00f2 rivelarsi troppo laboriosa. Talvolta \u00e8 pi\u00f9 semplice trovare tutte le aree nel codice con qualche bug e correggerle piuttosto che scrivere una regola per rilevare tali casi.<\/li>\n
    3. Mancanza di supporto per le dipendenze.<\/b> Progetti grandi dipendono da un numero significativo di librerie e framework che ampliano le capacit\u00e0 del linguaggio di programmazione. Se nella base di conoscenza dello scanner non ci sono informazioni sui punti pericolosi (\u00absinks\u00bb) in questi framework, questo diventa un punto cieco, e lo scanner non riuscir\u00e0 nemmeno a comprendere il codice.<\/li>\n
    4. Durata della scansione.<\/b> La ricerca di vulnerabilit\u00e0 nel codice \u00e8 un compito difficile anche in termini di algoritmi. Pertanto, il processo pu\u00f2 richiedere del tempo e richiedere sostanziali risorse computazionali.<\/li>\n
    5. Basso tasso di copertura.<\/b> Nonostante il consumo di risorse e la durata della scansione, gli sviluppatori di strumenti SAST devono comunque scendere a compromessi e analizzare non tutti gli stati in cui pu\u00f2 trovarsi un programma.<\/li>\n
    6. Riproducibilit\u00e0 dei risultati.<\/b> Indicare una riga specifica e uno stack di chiamate che portano a una vulnerabilit\u00e0 \u00e8 fantastico, ma in realt\u00e0 spesso lo scanner non fornisce informazioni sufficienti per verificare la presenza della vulnerabilit\u00e0 dall'esterno. Infatti, il difetto pu\u00f2 trovarsi anche nel codice morto, inaccessibile a un attaccante.<\/li>\n<\/ol>\n

      Problemi di scansione dell'infrastruttura.<\/h4>\n

      <\/p>\n

        \n
      1. Inventario insufficiente.<\/b> Nelle grandi infrastrutture, specialmente quelle distribuite geograficamente, \u00e8 spesso pi\u00f9 difficile capire quali host devono essere scansionati. In altre parole, il compito di scansione \u00e8 strettamente legato alla gestione delle risorse.<\/li>\n
      2. Scarsa priorizzazione.<\/b> I scanner di rete spesso generano molti risultati con vulnerabilit\u00e0 che in pratica non sono sfruttabili, ma formalmente il loro livello di rischio \u00e8 elevato. Il consumatore riceve un rapporto difficile da interpretare e non \u00e8 chiaro cosa sia necessario correggere per primo.<\/li>\n
      3. Raccomandazioni limitate.<\/b> Nel database delle conoscenze dello scanner ci sono spesso solo informazioni molto generali sulle vulnerabilit\u00e0 e su come risolverle, quindi gli amministratori dovranno attrezzarsi con Google. La situazione \u00e8 leggermente migliore con gli scanner whitebox, che possono fornire comandi specifici per la correzione.<\/li>\n
      4. Lavoro manuale.<\/b> Nelle infrastrutture possono essere presenti molti nodi, il che significa potenzialmente molte vulnerabilit\u00e0, i cui report devono essere esaminati e analizzati manualmente ad ogni iterazione.<\/li>\n
      5. Scarsa copertura.<\/b> La qualit\u00e0 della scansione dell'infrastruttura dipende direttamente dalla quantit\u00e0 di informazioni nel database delle vulnerabilit\u00e0 e delle versioni software. Tuttavia, si scopre<\/a><\/noindex>, anche i leader di mercato non dispongono di un database esaustivo, e nei database delle soluzioni gratuite ci sono molte informazioni che mancano ai leader.<\/li>\n
      6. Problemi di patching.<\/b> Nella maggior parte dei casi, il patching delle vulnerabilit\u00e0 nell'infrastruttura consiste nell'aggiornamento di un pacchetto o nella modifica di un file di configurazione. Un grande problema qui \u00e8 che il sistema, specialmente se legacy, potrebbe comportarsi in modo imprevedibile a seguito dell'aggiornamento. Fondamentalmente sar\u00e0 necessario eseguire test di integrazione su infrastrutture attive in produzione.<\/li>\n<\/ol>\n

        Approcci<\/h2>\n

        \nE quindi, cosa si pu\u00f2 fare?
        \nIn seguito, parler\u00f2 di esempi e di come affrontare molti dei problemi elencati, ma per ora indicher\u00f2 le principali direzioni in cui \u00e8 possibile lavorare:<\/p>\n

          \n
        1. Aggregazione di diversi strumenti di scansione.<\/b> Se utilizzati correttamente, diversi scanner possono portare a un significativo aumento della base di conoscenza e della qualit\u00e0 dei rilevamenti. Si possono scoprire anche pi\u00f9 vulnerabilit\u00e0 di quelle rilevate singolarmente da ciascun scanner, permettendo di valutare meglio il livello di rischio e di fornire pi\u00f9 raccomandazioni.<\/li>\n
        2. Integrazione di SAST e DAST.<\/b> Si pu\u00f2 aumentare la copertura di DAST e l'accuratezza di SAST attraverso lo scambio di informazioni tra di loro. Dalle sorgenti si possono ottenere informazioni sui percorsi esistenti, mentre con DAST si pu\u00f2 verificare se una vulnerabilit\u00e0 \u00e8 visibile dall'esterno.<\/li>\n
        3. Machine Learning\u2122.<\/b> Nel 2015, io parlato<\/a><\/noindex> (e ancora<\/a><\/noindex>) ho parlato dell'applicazione della statistica per dare agli scanner l'intuizione di un hacker, e per velocizzarli. Questo \u00e8 sicuramente un tema di sviluppo per l'analisi automatica della sicurezza in futuro.<\/li>\n
        4. Integrazione di IAST con test automatici e OpenAPI.<\/b> Nel contesto del CI\/CD-pipeline, \u00e8 possibile creare un processo di scansione basato su strumenti che operano come proxy HTTP e test funzionali che funzionano su HTTP. I test e i contratti OpenAPI\/Swagger forniranno allo scanner le informazioni mancanti sui flussi di dati, consentendo di eseguire la scansione dell'applicazione in vari stati.<\/li>\n
        5. Configurazione corretta.<\/b> Per ogni applicazione e infrastruttura \u00e8 necessario creare un profilo di scansione adeguato, che tengano conto del numero e della natura delle interfacce e delle tecnologie utilizzate.<\/li>\n
        6. Personalizzazione degli scanner.<\/b> Spesso un'applicazione non pu\u00f2 essere scansionata senza modifiche allo scanner. Un esempio \u00e8 una gateway di pagamento, in cui ogni richiesta deve essere firmata. Senza scrivere un connettore per il protocollo del gateway, gli scanner continueranno a inviare richieste con firme errate. \u00c8 anche necessario scrivere scanner specializzati per specifici tipi di vulnerabilit\u00e0, come Riferimento Diretto Insecure a Oggetti<\/a><\/noindex><\/li>\n
        7. Gestione del rischio.<\/b> L'uso di diversi scanner e l'integrazione con sistemi esterni, come Asset Management e Threat Management, consentiranno di utilizzare numerosi parametri per valutare il livello di rischio, cos\u00ec da fornire alla direzione un quadro adeguato sullo stato attuale della sicurezza nello sviluppo o nell'infrastruttura.<\/li>\n<\/ol>\n

          Rimanete sintonizzati e diamo una scossa alla scansione delle vulnerabilit\u00e0!
          \n
          Fonte:           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412 \u0440\u0430\u043c\u043a\u0430\u0445 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0439 \u0434\u0435\u044f\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c, \u043f\u0435\u043d\u0442\u0435\u0441\u0442\u0435\u0440\u0430\u043c, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u0438\u043a\u0430\u043c \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0442\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u043a\u0430\u043a Vulnerability Management (VM), (Secure) SDLC. \u041f\u043e\u0434 \u044d\u0442\u0438\u043c\u0438 \u0441\u043b\u043e\u0432\u043e\u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f\u043c\u0438 \u0441\u043a\u0440\u044b\u0432\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u043d\u0430\u0431\u043e\u0440\u044b \u043f\u0440\u0430\u043a\u0442\u0438\u043a \u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u044b\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0435\u0440\u0435\u043f\u043b\u0435\u0442\u0435\u043d\u044b \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439, \u0445\u043e\u0442\u044f \u0438\u0445 \u043f\u043e\u0442\u0440\u0435\u0431\u0438\u0442\u0435\u043b\u0438 \u0440\u0430\u0437\u043b\u0438\u0447\u0430\u044e\u0442\u0441\u044f. \u0422\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0433\u0440\u0435\u0441\u0441 \u043f\u043e\u043a\u0430 \u043d\u0435 \u0434\u043e\u0448\u0451\u043b \u0434\u043e \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0434\u043d\u0438\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0437\u0430\u043c\u0435\u043d\u0438\u0442\u044c \u0447\u0435\u043b\u043e\u0432\u0435\u043a\u0430 \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0437\u0430\u0449\u0438\u0449\u0451\u043d\u043d\u043e\u0441\u0442\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0438 \u041f\u041e. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-29957","post","type-post","status-publish","format-standard","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\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\n","aioseo_head_json":{"title":"\ud83e\udd47Scansione delle vulnerabilit\u00e0 e sviluppo sicuro. Parte 1 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","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\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","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":"2019-10-31T18:32:53+00:00","article:modified_time":"2019-10-31T18:32:53+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"29957","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":"Article","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":"2026-01-20 23:11:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:45:24","updated":"2026-01-20 23:11:19","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\/29957","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=29957"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/29957\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=29957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=29957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=29957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}