{"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":"Scansione delle vulnerabilit\u00e0 e sviluppo sicuro. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Scansione
\n
\nNel corso dell'attivit\u00e0 professionale, sviluppatori, pentester e esperti di sicurezza si trovano ad affrontare processi come Vulnerability Management (VM) e (Secure) SDLC.
\nQueste frasi nascondono diversi set di pratiche e strumenti utilizzati, che sono interconnessi, anche se i loro utilizzatori differiscono.<\/p>\n

Il progresso tecnico non \u00e8 ancora arrivato al punto da sostituire l'uomo con un unico strumento per condurre analisi di sicurezza su infrastrutture e software.
\n\u00c8 interessante capire perch\u00e9 sia cos\u00ec e quali problemi si devono affrontare.
\n<\/a><\/noindex><\/p>\n

Processi<\/h2>\n

\nIl processo di Vulnerability Management \u00e8 destinato al monitoraggio continuo della sicurezza dell'infrastruttura e alla gestione delle patch.
\nIl processo di Secure SDLC \u00e8 progettato per supportare la sicurezza dell'applicazione durante lo sviluppo e l'operativit\u00e0.<\/p>\n

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

Questo genera differenze negli strumenti e negli approcci. A mio avviso, il compito di identificare nuove vulnerabilit\u00e0 nell'applicazione \u00e8 significativamente pi\u00f9 interessante, poich\u00e9 non si riduce a fingerprinting delle versioni, raccolta di banner, attacchi brute force, ecc.
\nPer una scansione automatizzata di vulnerabilit\u00e0 delle applicazioni di alta qualit\u00e0, sono necessari algoritmi che tengano conto della semantica dell'applicazione, del suo scopo e delle minacce specifiche.<\/p>\n

Un analizzatore infrastrutturale pu\u00f2 spesso essere sostituito da un timer, come ha detto avleonov. . Il senso \u00e8 che statisticamente puoi considerare la tua infrastruttura vulnerabile se non l'hai aggiornata, ad esempio, da un mese.<\/a><\/noindex>La scansione, cos\u00ec come l'analisi della sicurezza, pu\u00f2 essere eseguita sia come black box che come white box.<\/p>\n

Strumenti<\/h2>\n

\nBlack Box<\/p>\n

Nel black box scanning, lo strumento deve essere in grado di interagire con il servizio attraverso le stesse interfacce utilizzate dagli utenti.<\/h4>\n

\n.<\/p>\n

Gli 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 conoscenze informazioni su vulnerabilit\u00e0 in quelle versioni. Tentano anche di scoprire errori di configurazione, come password di default o accesso aperto ai dati, crittografie SSL deboli, ecc.<\/p>\n

Gli scanner di applicazioni web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ecc.) sono in grado di identificare anche componenti noti e le loro versioni (ad esempio, CMS, framework, librerie JS). I principali passaggi dello scanner sono crawling e fuzzing.
\nDurante il crawling, lo scanner raccoglie informazioni sulle interfacce esistenti dell'applicazione e sui parametri HTTP. Durante il fuzzing, vengono inseriti nei parametri scoperti dati mutati o generati al fine di provocare un errore e scoprire una 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

\nCon la scansione whitebox ci sono pi\u00f9 differenze.
\nNel processo di VM, agli scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ecc.) viene spesso dato accesso ai sistemi, eseguendo una scansione autenticata. In questo modo, lo scanner pu\u00f2 estrarre le versioni dei pacchetti installati e i parametri di configurazione direttamente dal sistema, senza doverli indovinare dai banner dei servizi di rete.
\nLa scansione risulta pi\u00f9 precisa e completa.<\/p>\n

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

Problemi<\/h2>\n

\nCi sono molti problemi con la scansione! Con la maggior parte di essi mi trovo ad affrontare personalmente nel contesto della fornitura di servizi per costruire processi di scansione e sviluppo sicuro, cos\u00ec come durante l'analisi della sicurezza.<\/p>\n

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

Problemi con la scansione delle applicazioni web<\/h4>\n

<\/p>\n

    \n
  1. Difficolt\u00e0 nell'implementazione.<\/b> \u00c8 necessario configurare e personalizzare gli scanner per ogni applicazione, assegnare un ambiente di test per le scansioni e integrarli nel processo CI\/CD affinch\u00e9 funzioni in modo efficace. Altrimenti, diventer\u00e0 una procedura formale inutile, producendo solo falsi positivi.<\/li>\n
  2. Durata della scansione.<\/b> Nel 2019, gli scanner hanno ancora difficolt\u00e0 con la deduplicazione delle interfacce e possono impiegare giorni a scansionare mille pagine con 10 parametri ciascuna, considerandole diverse, sebbene siano gestite dallo stesso codice. \u00c8 fondamentale prendere rapidamente decisioni di deploy in produzione nel ciclo di sviluppo.<\/li>\n
  3. Raccomandazioni scarse.<\/b> Gli scanner forniscono raccomandazioni piuttosto generali e non sempre il programmatore pu\u00f2 comprendere rapidamente come ridurre il livello di rischio, e soprattutto, se \u00e8 necessario farlo subito o se pu\u00f2 attendere.<\/li>\n
  4. Impatto distruttivo sull'applicazione.<\/b> Gli scanner possono facilmente condurre attacchi DoS sull'applicazione e possono creare un numero elevato di entit\u00e0 o modificare quelle esistenti (ad esempio, generare decine di migliaia di commenti su un blog), quindi non \u00e8 consigliabile eseguire scansioni in produzione senza riflessione.<\/li>\n
  5. Bassa qualit\u00e0 nell'individuazione delle vulnerabilit\u00e0.<\/b> Gli scanner utilizzano solitamente un insieme fisso di payload e possono facilmente trascurare una vulnerabilit\u00e0 che non rientra negli schemi di comportamento che conoscono.<\/li>\n
  6. Incomprensione delle funzionalit\u00e0 dell'applicazione da parte dello scanner.<\/b> Gli scanner non sanno cosa siano internet banking, pagamenti o commenti. Per loro esistono solo link e parametri, quindi una vasta gamma di potenziali vulnerabilit\u00e0 nella logica aziendale rimane completamente scoperta; non capiranno come eseguire un addebito doppio, visualizzare dati altrui tramite ID o manipolare il saldo tramite arrotondamento.<\/li>\n
  7. Incomprensione della semantica delle pagine da parte dello scanner.<\/b> Gli scanner non sanno leggere le FAQ, non riconoscono i captcha, non capiranno come registrarsi e che \u00e8 necessario effettuare nuovamente il login, che non si deve cliccare su 'logout', e come 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 di fare molti compromessi. Spesso si deve sacrificare la precisione, e anche scanner enterprise costosi 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 scrivere queste regole pu\u00f2 risultare troppo impegnativo. A volte \u00e8 pi\u00f9 semplice trovare tutti i punti nel codice con un certo bug e correggerli, piuttosto che scrivere una regola per rilevare tali casi.<\/li>\n
    3. Mancanza di supporto per le dipendenze.<\/b> Progetti grandi dipendono da un gran numero di librerie e framework, che ampliano le possibilit\u00e0 del linguaggio di programmazione. Se nel database di conoscenza dello scanner non ci sono informazioni sui punti critici (\u201csinks\u201d) in questi framework, questo diventer\u00e0 un punto cieco e lo scanner non capir\u00e0 nemmeno il codice.<\/li>\n
    4. Durata della scansione.<\/b> La ricerca di vulnerabilit\u00e0 nel codice \u00e8 un compito complicato anche in termini di algoritmi. Pertanto, il processo pu\u00f2 richiedere molto tempo e considerabili risorse computazionali.<\/li>\n
    5. Bassa copertura.<\/b> Nonostante il consumo di risorse e la lunghezza della scansione, gli sviluppatori di strumenti SAST devono comunque affrontare compromessi e non analizzare tutti gli stati in cui pu\u00f2 trovarsi un programma.<\/li>\n
    6. Riproducibilit\u00e0 delle scoperte.<\/b> Indicare una linea 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 di una vulnerabilit\u00e0 dall'esterno. Infatti, il difetto pu\u00f2 trovarsi anche in codice morto, non raggiungibile da 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 geograficamente distribuite, \u00e8 spesso difficile capire quali host debbano essere scansionati. In altre parole, il compito di scansione \u00e8 strettamente correlato al compito di asset management.<\/li>\n
      2. Scarsa priorizzazione.<\/b> Gli scanner di rete spesso producono molti risultati con difetti che, nella pratica, non sono sfruttabili, ma formalmente il loro livello di rischio \u00e8 alto. Il consumatore riceve un rapporto che \u00e8 difficile da interpretare e non \u00e8 chiaro cosa debba essere corretto per primo.<\/li>\n
      3. Raccomandazioni scarse.<\/b> Nella base di conoscenza degli scanner, spesso c'\u00e8 solo una informazione molto generica sulle vulnerabilit\u00e0 e sui metodi per risolverle, quindi gli admin dovranno armarsi di Google. La situazione \u00e8 leggermente migliore con gli scanner whitebox, che possono fornire un comando specifico per la correzione.<\/li>\n
      4. Lavoro manuale.<\/b> Nelle infrastrutture possono esserci molti nodi, e quindi potenzialmente molti difetti, i report dei quali 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 dimensione della base di conoscenza sulle vulnerabilit\u00e0 e sulle versioni del software. Tuttavia, si rivela essere<\/a><\/noindex>, anche i leader di mercato non hanno una base di conoscenza esaustiva, e nelle basi delle soluzioni gratuite ci sono molte informazioni che non sono presenti nei leader.<\/li>\n
      6. Problemi con il 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, pu\u00f2 comportarsi in modo imprevedibile a seguito di un aggiornamento. In sostanza, sar\u00e0 necessario condurre test di integrazione su un'infrastruttura in produzione.<\/li>\n<\/ol>\n

        Approcci.<\/h2>\n

        \nCosa fare allora?
        \nParler\u00f2 pi\u00f9 in dettaglio di esempi e di come affrontare molti dei problemi elencati nelle prossime parti, mentre per ora indico le principali aree su cui \u00e8 possibile lavorare:<\/p>\n

          \n
        1. Aggregazione di diversi strumenti di scansione.<\/b> Con un uso corretto di pi\u00f9 scanner, \u00e8 possibile ottenere un notevole aumento della base di conoscenza e della qualit\u00e0 del rilevamento. \u00c8 possibile trovare anche pi\u00f9 vulnerabilit\u00e0 rispetto alla somma di tutti gli scanner eseguiti singolarmente, mentre si pu\u00f2 valutare con maggiore precisione il livello di rischio e fornire maggiori raccomandazioni.<\/li>\n
        2. Integrazione SAST e DAST.<\/b> \u00c8 possibile aumentare la copertura DAST e la precisione SAST grazie allo scambio di informazioni tra di essi. Dall'analisi del codice sorgente si possono ottenere informazioni sui percorsi esistenti, mentre con DAST si pu\u00f2 verificare se la vulnerabilit\u00e0 \u00e8 visibile dall'esterno.<\/li>\n
        3. Machine Learning\u2122.<\/b> Nel 2015, ho ha raccontato<\/a><\/noindex> (e ancora<\/a><\/noindex>) parlato dell'applicazione della statistica per fornire agli scanner l'intuizione di un hacker e velocizzarli. Questo rappresenta sicuramente un tema di sviluppo per l'analisi automatica della sicurezza in futuro.<\/li>\n
        4. Integrazione IAST con test automatici e OpenAPI.<\/b> Nel contesto di un pipeline CI\/CD \u00e8 possibile creare un processo di scansione basato su strumenti che operano come proxy HTTP e test funzionali che lavorano via HTTP. I test e i contratti OpenAPI\/Swagger forniranno allo scanner le informazioni necessarie sui flussi di dati, consentendo di scansionare l'applicazione in vari stati.<\/li>\n
        5. Configurazione corretta.<\/b> Per ogni applicazione e infrastruttura \u00e8 necessario creare un profilo di scansione adeguato, tenendo conto della quantit\u00e0 e della natura delle interfacce e delle tecnologie utilizzate.<\/li>\n
        6. Personalizzazione degli scanner.<\/b> Spesso, non \u00e8 possibile scansionare un'applicazione senza modifiche allo scanner. Ad esempio, un gateway di pagamento in cui ogni richiesta deve essere firmata. Senza scrivere un connettore per il protocollo del gateway, gli scanner tenteranno di inviare richieste con firme errate. \u00c8 anche necessario scrivere scanner specializzati per specifici tipi di vulnerabilit\u00e0, come Riferimento diretto a oggetti non sicuri<\/a><\/noindex><\/li>\n
        7. Gestione del rischio.<\/b> L'utilizzo di diversi scanner e l'integrazione con sistemi esterni, come Asset Management e Threat Management, consentiranno di utilizzare molteplici parametri per la valutazione del livello di rischio, in modo che la direzione possa ottenere una visione adeguata dello stato attuale della sicurezza dello sviluppo o dell'infrastruttura.<\/li>\n<\/ol>\n

          Rimanete sintonizzati e diamo 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}]}}