{"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\/hr\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","title":{"rendered":"Skeniranje na ranjivosti i sigurna razvojna praksa. Dio 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Skeniranje
\n
\nU okviru profesionalnih aktivnosti, programeri, pentesteri i stru\u010dnjaci za sigurnost se suo\u010davaju s procesima poput upravljanja ranjivostima (VM) i (sigurnog) SDLC-a.
\nIza ovih pojmova kriju se razni setovi praksi i kori\u0161tenih alata, koji su isprepleteni, iako su njihovi korisnici razli\u010diti.<\/p>\n

Tehni\u010dki napredak jo\u0161 uvijek nije dostigao to\u010dku u kojoj bi jedan alat mogao zamijeniti \u010dovjeka u analizi sigurnosti infrastrukture i softvera.
\nZanimljivo je razumjeti za\u0161to je to tako i s kojim se problemima suo\u010davaju.
\n<\/a><\/noindex><\/p>\n

Procesi<\/h2>\n

\nProces upravljanja ranjivostima (\u201eVulnerability Management\u201c) namijenjen je kontinuiranom pra\u0107enju sigurnosti infrastrukture i upravljanju zakrpama.
\nProces sigurnog SDLC-a (\u201eSecure SDLC\u201c) namijenjen je podr\u0161ci sigurnosti aplikacije tijekom razvoja i eksploatacije.<\/p>\n

Sli\u010dan dio ovih procesa je proces procjene ranjivosti \u2014 skeniranja na ranjivosti.
\nGlavna razlika u skeniranju u okviru VM i SDLC-a je ta \u0161to je cilj u prvom slu\u010daju otkriti poznate ranjivosti u tre\u0107em softveru ili u konfiguraciji. Na primjer, zastarjela verzija Windowsa ili zadnja community-string za SNMP.
\nU drugom slu\u010daju, cilj je otkriti ranjivosti ne samo u vanjskim komponentama (ovisnostima), ve\u0107 prvenstveno u kodu novog proizvoda.<\/p>\n

To uzrokuje razlike u alatima i pristupima. Po mom mi\u0161ljenju, zadatak pronala\u017eenja novih ranjivosti u aplikaciji zna\u010dajno je zanimljiviji, jer se ne svodi samo na otisak verzija, prikupljanje bannera, poku\u0161avanje lozinki itd.
\nZa kvalitetno automatizirano skeniranje ranjivosti aplikacija potrebni su algoritmi koji uzimaju u obzir semantiku aplikacije, njenu svrhu i specifi\u010dne prijetnje.<\/p>\n

Infrastrukturni skener se \u010desto mo\u017ee zamijeniti tajmerom, kako je to izrazio avleonov<\/a><\/noindex>. Smisao je u tome da mo\u017eete statisti\u010dki smatrati svoju infrastrukturu ranjivom ako je niste a\u017eurirali, recimo, mjesec dana.<\/p>\n

Alati<\/h2>\n

\nSkeniranje, kao i analiza sigurnosti, mo\u017ee se provoditi kao crna kutija, tako i kao bijela kutija.<\/p>\n

Crna kutija<\/h4>\n

\nPri blackbox skeniranju alat treba biti sposoban raditi s uslugom putem istih su\u010delja koja koriste korisnici.<\/p>\n

Skenirnici infrastrukture (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose itd.) tra\u017ee otvorene mre\u017ene portove, prikupljaju \u201ebanere\u201c, odre\u0111uju verzije instaliranog softvera i tra\u017ee u svojoj bazi podataka informacije o ranjivostima tih verzija. Tako\u0111er poku\u0161avaju otkriti gre\u0161ke u konfiguraciji, kao \u0161to su zadani lozinke ili otvoreni pristup podacima, slabi SSL \u0161ifriranja itd.<\/p>\n

Skenirnici web-aplikacija (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP itd.) tako\u0111er mogu odrediti poznate komponente i njihove verzije (na primjer, CMS, okvire, JS biblioteke). Glavni koraci skenera su crawling i fuzzing.
\nTijekom crawlanja skener prikuplja informacije o postoje\u0107im su\u010deljima aplikacije, HTTP parametrima. Tijekom fuzzinga u sve otkrivene parametre unose se mutirani ili generirani podaci s ciljem izazivanja gre\u0161ke i otkrivanja ranjivosti.<\/p>\n

Takvi skeneri aplikacija pripadaju klasama DAST i IAST \u2014 odnosno Dinami\u010dko i Interaktivno testiranje sigurnosti aplikacija.<\/p>\n

White Box<\/h4>\n

\nPri whitebox skeniranju razlika je vi\u0161e.
\nU procesu VM skeniranja (Vulners, Incsecurity Couch, Vuls, Tenable Nessus itd.) skeneri \u010desto dobivaju pristup sustavima, provode\u0107i autentificirano skeniranje. Tako skener mo\u017ee preuzeti instalirane verzije paketa i konfiguracijske parametre izravno iz sustava, ne naga\u0111aju\u0107i ih na temelju banera mre\u017enih usluga.
\nSkeniranje postaje preciznije i potpunije.<\/p>\n

Ako govorimo o whitebox skeniranju (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs itd.) aplikacija, obi\u010dno se radi o stati\u010dkoj analizi koda i kori\u0161tenju odgovaraju\u0107ih alata klase SAST \u2014 Stat\u010dko testiranje sigurnosti aplikacija.<\/p>\n

Problemi<\/h2>\n

\nPostoji mnogo problema sa skeniranjem! Ve\u0107inu njih osobno susre\u0107em tijekom pru\u017eanja usluge izgradnje procesa skeniranja i sigurne razvojne, kao i prilikom rada na analizi sigurnosti.<\/p>\n

Izdvojit \u0107u 3 glavne grupe problema koje potvr\u0111uju razgovori s in\u017eenjerima i rukovoditeljima slu\u017ebi za IB u raznim kompanijama.<\/p>\n

Problemi sa skeniranjem web-aplikacija<\/h4>\n

<\/p>\n

    \n
  1. Te\u0161ko\u0107e u implementaciji.<\/b> Skeneri se moraju postaviti, konfigurirati i prilagoditi za svaku aplikaciju, odvojiti testno okru\u017eenje za skeniranje i implementirati u CI\/CD proces kako bi to bilo u\u010dinkovito. Ina\u010de \u0107e to biti beskoristan formalni postupak koji \u0107e davati samo la\u017ene signale.<\/li>\n
  2. Trajanje skeniranja.<\/b> Skeneri \u010dak ni 2019. nisu dobro upravljali deduplifikacijom su\u010delja i mogu satima skenirati tisu\u0107u stranica s 10 parametara na svakoj, smatraju\u0107i ih razli\u010ditim, iako za njih odgovara isti kod. Pri tome je potrebno brzo donijeti odluku o deployu u produkciju unutar razvojnog ciklusa.<\/li>\n
  3. Osnovne preporuke.<\/b> Skeneri daju dovoljno op\u0107enite preporuke, a ne mo\u017ee uvijek developer brzo razumjeti kako smanjiti razinu rizika, a najva\u017enije, treba li to u\u010diniti odmah ili mo\u017ee malo pri\u010dekati.<\/li>\n
  4. Destruktivni utjecaj na aplikaciju.<\/b> Skeneri mogu izvesti DoS napad na aplikaciju, kao i stvoriti veliki broj entiteta ili promijeniti postoje\u0107e (na primjer, kreirati desetke tisu\u0107a komentara na blogu), tako da ne treba bez razmi\u0161ljanja pokretati skeniranje u produkciji.<\/li>\n
  5. Niska kvaliteta otkrivanja ranjivosti.<\/b> Skeneri obi\u010dno koriste fiksni skup korisnih optere\u0107enja ('payloads') i mogu lako propustiti ranjivost koja ne odgovara poznatom scenariju pona\u0161anja aplikacije.<\/li>\n
  6. Nesporazum skenera o funkcijama aplikacije.<\/b> Skeneri sami po sebi ne znaju \u0161to je 'internet-bankarstvo', 'pla\u0107anje', 'komentar'. Za njih postoje samo linkovi i parametri, tako da ogroman spektar mogu\u0107ih ranjivosti poslovne logike ostaje potpuno neza\u0161ti\u0107en, ne shva\u0107aju kako izvr\u0161iti dvostruku naplatu, vidjeti tu\u0111e podatke po ID-u ili manipulisati saldom kroz zaokru\u017eivanje.<\/li>\n
  7. Nesporazum skenera o semantici stranica.<\/b> Skeneri ne znaju \u010ditati FAQ, ne prepoznaju captcha, sami po sebi ne mogu shvatiti kako se registrirati, i da se treba ponovno prijaviti, da se ne smije kliknuti 'odjava', i kako treba potpisivati zahtjeve prilikom promjene vrijednosti parametara. Kao rezultat, veliki dio aplikacije mo\u017ee potpuno ostati neistra\u017een.<\/li>\n<\/ol>\n

    Problemi skeniranja izvornog koda.<\/h4>\n

    <\/p>\n

      \n
    1. La\u017eni signali.<\/b> Stati\u010dka analiza je slo\u017een posao koji \u010desto zahtijeva mno\u0161tvo kompromisa. \u010cesto se mora \u017ertvovati to\u010dnost, a \u010dak i skupi enterprise skeneri generiraju ogromne koli\u010dine la\u017enih pozitivnih rezultata.<\/li>\n
    2. Te\u0161ko\u0107e u implementaciji.<\/b> Kako bi se pove\u0107ala to\u010dnost i cjelovitost stati\u010dke analize, potrebno je nadograditi pravila skeniranja, a pisanje tih pravila mo\u017ee biti previ\u0161e zahtjevno. Ponekad je lak\u0161e prona\u0107i sva mjesta u kodu s odre\u0111enim gre\u0161kama i ispraviti ih nego pisati pravilo za detekciju takvih slu\u010dajeva.<\/li>\n
    3. Nedostatak podr\u0161ke za ovisnosti.<\/b> Veliki projekti ovise o velikom broju biblioteka i frameworka koji pro\u0161iruju mogu\u0107nosti programskog jezika. Ako u bazi znanja skenera nema informacija o opasnim mjestima ('sinks') u tim frameworkima, to postaje slijepa to\u010dka, a skener jednostavno ne\u0107e mo\u0107i razumjeti kod.<\/li>\n
    4. Trajanje skeniranja.<\/b> Tra\u017eenje ranjivosti u kodu je slo\u017een zadatak, \u010dak i u terminima algoritama. Stoga proces mo\u017ee trajati du\u017ee i zahtijevati zna\u010dajne ra\u010dunalne resurse.<\/li>\n
    5. Low coverage.<\/b> Unato\u010d potro\u0161nji resursa i dugotrajnosti skeniranja, programeri SAST alata \u010desto se moraju odlu\u010diti za kompromis i ne analizirati sve stanje u kojem se program mo\u017ee nalaziti.<\/li>\n
    6. Reproducibility of findings.<\/b> Upu\u0107ivanje na odre\u0111enu liniju i stog poziva koji dovodi do ranjivosti je izvrsno, ali \u010desto skener ne daje dovoljno informacija kako bi se vanjski provjerila prisutnost ranjivosti. Naime, nedostatak mo\u017ee biti i u mrtvom kodu, koji napada\u010d ne mo\u017ee dose\u0107i.<\/li>\n<\/ol>\n

      Problemi skeniranja infrastrukture.<\/h4>\n

      <\/p>\n

        \n
      1. Nedovoljna inventarizacija.<\/b> U velikim infrastrukturnim postavkama, posebno geografskim podijeljenim, \u010desto je najte\u017ee shvatiti koji se hostovi trebaju skenirati. Drugim rije\u010dima, zadatak skeniranja usko je povezan s upravljanjem imovinom.<\/li>\n
      2. Lo\u0161a priorizacija.<\/b> Mre\u017eni skeneri \u010desto generiraju mnogo rezultata s nedostacima koji se u praksi ne koriste, ali formalno je razina njihovog rizika visoka. Potro\u0161a\u010d dobiva izvje\u0161taj koji je te\u0161ko interpretirati i nije jasno \u0161to treba prvo ispraviti.<\/li>\n
      3. Osnovne preporuke.<\/b> U bazi znanja skenera \u010desto se nalazi samo vrlo op\u0107enita informacija o ranjivosti i na\u010dinima njenog ispravljanja, pa \u0107e administratori morati zavrnuti rukave i potra\u017eiti informacije na Googleu. Situacija je malo bolja sa whitebox skenerima koji mogu dati konkretne naredbe za ispravke.<\/li>\n
      4. Ru\u010dni rad.<\/b> U infrastrukturi mo\u017ee biti mnogo \u010dvorova, a time i potencijalno mnogo nedostataka \u010dije izvje\u0161taje je potrebno ru\u010dno analizirati pri svakoj iteraciji.<\/li>\n
      5. Lo\u0161a pokrivenost.<\/b> Kvaliteta skeniranja infrastrukture izravno ovisi o opsegu baze znanja o ranjivostima i verzijama softvera. Ipak, testiranje.<\/a><\/noindex>, \u010dak i kod lidera tr\u017ei\u0161ta, baza znanja nije sveobuhvatna, a u bazama besplatnih rje\u0161enja ima mnogo informacija koje nedostaju liderima.<\/li>\n
      6. Problemi s patchevima.<\/b> Naj\u010de\u0161\u0107e, patchiranje ranjivosti u infrastrukturi podrazumijeva a\u017euriranje paketa ili promjenu konfiguracijske datoteke. Veliki problem ovdje je to \u0161to se sustav, posebno legacy, mo\u017ee pona\u0161ati nepredvidivo kao posljedica a\u017euriranja. U su\u0161tini, bit \u0107e potrebno provesti integracijska testiranja na aktivnoj infrastrukturi u produkciji.<\/li>\n<\/ol>\n

        Pristupi<\/h2>\n

        \n\u0160to u\u010diniti?
        \nDetaljnije o primjerima i o tome kako se boriti s mnogim od navedenih problema, govorit \u0107u u sljede\u0107im dijelovima, a za sada \u0107u navesti glavne pravce u kojima se mo\u017ee djelovati:<\/p>\n

          \n
        1. Agregacija razli\u010ditih alata za skeniranje.<\/b> Pravilnim kori\u0161tenjem vi\u0161e skenera mogu\u0107e je zna\u010dajno pove\u0107ati bazu znanja i kvalitetu detektiranja. Mo\u017eete prona\u0107i \u010dak i vi\u0161e ranjivosti nego \u0161to bi pojedina\u010dno svi skeneri mogli otkriti, dok je mogu\u0107e to\u010dnije ocijeniti razinu rizika i dati vi\u0161e preporuka.<\/li>\n
        2. Integracija SAST i DAST.<\/b> Mogu\u0107e je pove\u0107ati pokrivenost DAST-a i to\u010dnost SAST-a razmjenom informacija izme\u0111u njih. Iz izvora se mogu dobiti informacije o postoje\u0107im rutama, a uz pomo\u0107 DAST-a mo\u017ee se provjeriti je li ranjivost vidljiva izvan.<\/li>\n
        3. Strojno u\u010denje\u2122.<\/b> Godine 2015. ja sam govorio<\/a><\/noindex> (i jo\u0161<\/a><\/noindex>) o primjeni statistike kako bih skenerima dao intuiciju hakera i ubrzao ih. To je definitivno poticaj za razvoj automatske analize sigurnosti u budu\u0107nosti.<\/li>\n
        4. Integracija IAST s automatiziranim testovima i OpenAPI.<\/b> U okviru CI\/CD pipeline-a mogu\u0107e je kreirati proces skeniranja koriste\u0107i alate koji funkcioni\u0161u kao HTTP proxy i funkcionalne testove koji rade preko HTTP-a. Testovi i OpenAPI\/Swagger ugovori \u0107e pru\u017eiti skeneru nedostaju\u0107e informacije o tokovima podataka, omogu\u0107uju\u0107i skeniranje aplikacije u razli\u010ditim stanjima.<\/li>\n
        5. Ispravno konfiguriranje.<\/b> Za svaku aplikaciju i infrastrukturu potrebno je kreirati odgovaraju\u0107i profil skeniranja koji uzima u obzir broj i karakter korisni\u010dkih su\u010delja, kori\u0161tene tehnologije.<\/li>\n
        6. Prilagodba skenera.<\/b> \u010cesto je nemogu\u0107e skenirati aplikaciju bez prilagodbe skenera. Primer \u2014 platni prolaz, gde svaki zahtev mora biti potpisan. Bez pisanja konektora za protokol prolaza, skeneri \u0107e bezrazlo\u017eno slati zahteve sa pogre\u0161nim potpisom. Tako\u0111e je potrebno pisati specijalizovane skener\u0435 za odre\u0111ene vrste nedostataka, kao \u0161to su Insecure Direct Object Reference<\/a><\/noindex><\/li>\n
        7. Upravljanje rizikom.<\/b> Kori\u0161\u0107enje razli\u010ditih skenera i integracija sa spoljnim sistemima, kao \u0161to su Asset Management i Threat Management, omogu\u0107it \u0107e kori\u0161\u0107enje mnogo parametara za procenu nivoa rizika, tako da uprava mo\u017ee dobiti adekvatnu sliku o trenutnom stanju bezbednosti razvoja ili infrastrukture.<\/li>\n<\/ol>\n

          Stay tuned and let’s disrupt the vulnerability scanning!
          \n
          Izvor:           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\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\udd47Skeniranje na ranjivosti i sigurna izrada. Deo 1 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/29957","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=29957"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/29957\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=29957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=29957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=29957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}