Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Logik

Stran: 1 ... 6 7 [8] 9 10 ... 68
106
Filip:V podstatě už jen slovíčkaříš a snažíš se z toho vykecat. (Např. ze všeho - dneska se skripty standardně bundlují, takže bazírovat na tom, že není stahován v samostatném souboru, takže to není skript - to dělá buďto člověk co neví o webovém vývoji zbla... anebo troll).

Na zbytek už v podstatě nemám co říci - vše, co píšeš už jsem několikrát okomentoval, a pokud jsi zmínil něco nového, tak jen argumentační fauly, jako např.
Citace
Pokud je pro vás základem webové bezpečnosti security through obscurity, pak vaší webové bezpečnosti opravdu nerozumím.
Nikde jsem netvrdil, že bezpečnost čehokoli stojí na obscurity. Tvrdil jsem, že zbytečné poskytování informací o zabezpečeném objektu
 usnadňuje útok, takže je neprofesionální je poskytovat zbytečně. To, že máš potřebu můj názor takto překrucovat je důkazem toho, že
  • nechceš diskutovat, ale dělat z druhých blby
  • korektní argumenty prostě nemáš
Takže další diskuse evidentně už fakt nemá smysl.


FKoudelka:
Citace
Je teda to Moneta bankovnictví na webu bezpečné, nebo ne ? Protože jestli ne, asi by se to mělo eskalovat
Z toho, co víme, se IMHO se nedá vyvodit, že je nebezpečné ve smyslu "víme jak ho zneužít". Ale je napsané neprofesionálně, což zavdává pochybnosti o jeho kvalitě a potažmo tedy i o kvalitě zabezpečení. To, že jsou k dispozici zdrojové kódy, je pak stav, který případný útok usnadňuje, to by snad někdo Monetě napsat měl. Ale nevěřím, že si té diskuse už nevšimli. 

107
Citace
Nejdřív napíšete něco, z čeho vůbec není patrné, na co reagujete
Víš, normální člověk, když si není jistý, na co druhý reagoval, tak se zeptá. A slušný člověk se také snaží pochopit, co druhý říká tak, aby to dávalo smysl - tedy že když mluvím o krádeži, tak asi reaguju na popisovanou krádež....

Já holt fakt nemůžu za to, že se tu v diskusi chováš jak arogantní vševěd, kterej si automaticky myslí, že všichni ostatní jsou blbci a místo, co by ses zamyslel nad tím, co tvrdí, tak se je snažíš co nejvíce setřít.

Citace
Prokazatelně znamená, že ve výčtu stahovaných skriptů vyší označíte ten skript, který je zbytečný.
Jasně, když už musíš uznat omyl, tak se snažíš aspoň něco vyhnidopišit. Je to teda dost trapný - a navíc jsi zas mimo: pokud je prokázáno, že ta stránka se zbytečně připojuje někam, tak prostě tam je prokazatelně zbytečný skript dělající to připojení. Pro toto tvrzení fakt není potřeba ukazovat na to, který to je. Spousta matematických důkazů pracuje s tím, že ukáže existenci tvrzeného, aniž by ukázala na konkrétní instanci. Viz např. Gödelova 1. věta o neúplnosti.

Citace
Nevím, jak přečtením zjistíte, že adresa je špatně. Abyste to zjistil, musíte ji s něčím porovnat – obvykle ale není s čím.
Klasika. Když ti dojdou rozumné argumenty, tak začneš tvrdit kraviny. Samozřejmě, že u nemalé části phisingu (např. zaměřené na elektronické bankovnictví) to je s čím porovnatelné, protože URL se snaží napodobovat orginální URL, které uživatel zná. Anebo není s čím, ale stejně jde z adresy snadno poznat, že je podvržená (absence HTTPS, obskurní doména apod.).
Navíc je to vlastně jedno, protože zadávat hesla na "mailem zaslaném odkazu" je stejné porušení pravidel bezpečnosti uživatelem, jako nezkontrolování čísla účtu v SMS. Takže i kdyby to co tvdíš byla pravda (jako že není), tak to nijak nevyvrací to, co jsem tvrdil: že pod otázky bezpečnosti patří i co největší prevence "uživatelských chyb" vedoucích k úspěšnému útoku.

Citace
Aha, takže ten zabezpečenej frontend mi brání v tom, abych si odchytil, jaký JSON s požadavkem prohlížeč posílá, a pak stejně strukturovaný požadavek poslal třeba přes curl. A pěkně prosím, jak přesně mi v tom ten frontend brání?
Víš, v Tvém omezeném světě, kde existují pouze útoky typu "(catch, modify and) replay", tak nijak. Ale jak jsem Ti v předchozích postech doložil, tak pod pojmem bezpečnost webové aplikace spadá podstatně více problematik a podstatně více druhů útoků, než jen ten "replay". V minulém postu Ti to už trochu došlo, teď už jsi na to zas zapomněl. A některým z těchto jiných útoků brání dobře napsaný frontend.

Tale Tvoje implikace, že některým nebrání, tedy že nebrání žádným, je jen učebnicovou ukázkou argumentačního faulu.
Nechceš toho už nechat? Jen dokolečka prokazuješ, že problematice webové bezpečnosti prostě nerozumíš. V podstatě dokolečka tady různými slovy opakuješ, že považuješ aplikaci zabezpečenou proti jednomu z mnoha druhů útoků za bezpečnou, což je prostě kravina.

Citace
Právě proto se používá druhý faktor. Protože aby byl útočník úspěšný, musel by napadnout uživatelův počítač a zároveň telefon.
Zamysli se, proč je to druhý faktor. Že by někde existoval první faktor?
Tady jen potvrzuješ, že uživatelův "počítač" - a mezi což patří i bezpečnost frontendové aplikace - mezi zabezpečení IB prostě patří.

108
Citace
Akorát že to byla reakce úplně na něco jiného.
To neokradl nebyla reakce na mé okradl? Nebo chceš tvrdit, že víš lépe, na co jsem reagoval svým že Tě okradl, než já? Teda, v originálnosti vejmluv mne furt překvapuješ....
Reagoval jsem na odstavec, jde jsi tvrdil, že zabezpečení backendu řeší to, že si někdo napíše PIN na kartu. Což prostě neřeší, protože v okamžiku, kdy zareaguje ochrana na backendu (limity), tak už jsi okradenej.

Citace
Blba ze sebe dělá sám ten, kdo tvrdí, že se stahují zbytečné skripty, sourcemaps apod.
Ano, děláš ze sebe blba, když tvrdíš, že stránka nic zbytečného nestahuje a nedokážeš uznat omyl.Ta stránka prokazatelně stahuje a spouští skript který umožňuje reload stránky při vývoji. A tendle skript tam prostě nemá co dělat, zpomaluje už tak nechutně nakynutý stránky.

Btw. ta stránka stahuje i plno dalších blbostí, včetně např. nějakého pdf-workeru, kterej je určitě na login-page potřeba, žejo.... Jako mít na jednoduchý login page skoro 9MB javascriptu????? Fakt profi práce....

Citace
Ano, protože jsem za bezpečnost považoval aktivní kroky, které brání nějakým útokům.
Jako že jsi si myslel že mít "neděravou aplikaci" do bezpečnosti nepatří???
Když porušíš pravidla vývoje na backendu, máš děravý backend. Když porušíš pravidla vývoje na frontendu, máš děravý frontend. Je to úplně to samé.

Nevím, za co jsi bezpečnost považoval. Ale prostě jsi evidentně netušil, co vše do bezpečnosti webové aplikace patří a ignoroval jsi problémy, které by měl v otázce bezpečnosti znát a řešit i slušný junior. Ale měl jsi tu drzost v diskusi ostatní označovat za laiky a arogantně poučovat.

Citace
Pokud někdo číslo účtu v SMS nekontroluje, je náchylný ke spoustě různých útoků.
Takže vlastně celej phishing a opatření proti němu se vlastně vůbec netýká zabezpečení prohlížeče, protože stačí dobře číst a není to problém.... Aha....
Samozřejmě, kdo nečte SMS, tak je náchylnej k různejm útokům. Třeba napadení frontendu. Jenže ono nemusí jít o nečtení, může jít např. o napadení telefonu. Nebo. Nebo. Právě proto je zabezpečenej i frontend, a není to tak, že by mohl poslat požadavek kdokoli a bezpečnost záležela jen na potvrzení SMS.
 Bezpečnost frontendu je jeden z faktorů bezpečnosti IB, úplně stejně, jako bezpečnost telefonu, kam Ti choděj SMS. Aby útočník IB zneužil, musí je překonat všechny. A právě proto, že ať už uživatel svým hloupým chováním, nebo hacker zneužitím chyby nebo kombinací může být nabourána bezpečnost jedné z vrstev bezpečnosti, je bezpečnost vícefaktorová.

Bezpečnost zahrnuje i řešení toho, že se uživatelé nechovají vždy 100% ideálně a tím oslabujou bezpečnost použitejch řešení (nečtou SMS, maj zavirovanej prohlížeč apod.). Bezpečnost spoléhající se na to, že se všichni chovájí "správně" není bezpečnost, ale iluze bezpečnosti. To je další ze školáckých pouček, kterou by měl znát každej, kdo se jen trochu ochomejtá kolem bezpečnosti - a kterou tu implicitně popíráš.
Citace
i vyvarování se triviálně nebezpečným konstrukcím typu eval(), pak
Víš, ono těch bezpečnostních problémů na frontendu je podstatně více, než jen ten triviální eval. Ale vzhledem k tomu, jak dlouho mi trvalo, než jsi aspoň částečně byl schopnej připustit, že vůbec nějakej bezpečnostní problém na frontendu může být, tak fakt nemám ani čas, ani náladu ti vysvětlovat podstatu dlaších, složitějších a v reálu k útokům použitelnejch nabourání bezpečnosti frontendu.
Smiř se s tím, že napsat frontend bezpečně není "automatické", že je k tomu třeba něco vědět a dodržovat určitá pravidla.A s dodržováním pravidel mají hoši z Monety evidentně problém, v diskusi už bylo poukázáno na X porušení pravidel dobrého webu (debugovací skripty na produkci, obecně velikost skriptů, s tím související nahrávání nepotřebného balastu potřebného až někde v hloubi webu, absence SCP....)

Btw., v tom útoku nemusí jít jen o podvržení plateb, kde Tě, když vše děláš správně, zachrání další vrstva zabezpečení. Může jít např. o krádeže výpisů z účtů, kde už další vrstva zabezpečení prostě není. Tam Ti stačí nabourat frontend a máš to, pro co sis přišel.

109
Citace
Neokradl.
Psal jsi "někdo s ní může vybrat až do výše limitu z bankomatu.". Tedy ten někdo Tě prostě okradl. Tak prosím takto primitivně nelži, je to trapné.

Citace
Pokud používáte na frontendu eval
A todle je trapná výmluva a snaha se vylhat osobním útokem. Ty jsi Tvrdil, že security je čistě otázka backendu. Teď jsem Tě přinutil připustit, že existuje pravidlo pro frontend (eval se nemá používat), které je třeba pro dodržení bezpečnosti dodržet. To, že se to trapně snažíš obrátit proti mně nic nemění na tom, že evidentně jsi celou dobu tvrdil nesmysly, že zabezpečení je čistě otázka backendu.Těch pravidel co je třeba dodržet na frontendu je samozřejmě více (ošetřování vkládaného HTML závislého na uživateli, správný parsing Jsonu, správné skládání url, atd.. atd....) - jen jsem Ti na tom úplně nejtriviálnějším příkladu ukázal nesmyslnost Tvého tvrzení, že security je jen otázka backendu a tedy že neprofesionalita frontendu nemá co dělat s bezpečností bankovní aplikace.

Citace
Vaše představa, že nechtěnému převodu na cizí účet brání JavaScriptový kód v prohlížeči, je opravdu zábavná.
Ne Filipe, zábavné je, že neznáš úplné základy web-security, a přitom tu vystupuješ jako člověk, co snědl moudrost světa a snažíš se ostatní poučovat a dělat z nich blby.

To, že je tam další rovina zabezpečení např. v telefonu pomocí SMS je pravda, ovšem protože nemálo lidí čístlo účtu v došlé SMS nekontroluje, je toto zabezpečení nedostatečné. Proto ano, úspěšné nabourání JS na frontendu (které umožní pozměnit číslo účtu příjemce) je podstatné narušení bezpečnosti IB. A pokud to furt popíráš, tak další debata nemá smysl, protože pak seš evidentně schopen popřít i nos mezi očima, abys nemusel uznat omyl.

110
Citace
Takže z té původní nečitelné hrůzy zbyde nečitelné už jenom to, že jsou možná přejmenované identifikátory.
Jenom? ??? ? Přejmenované identiikátory (v rozumně napsaném kódu) Ti proces ladění a porozumění kódu podstatně zpomalují. Řádově. Debugoval jsi vůbec někdy cizí kód? ???

Citace
Jenže prohlížeč má další kouzelná tlačítka, která umožňují vkládat breakpointy a krokovat kód.
Auuu. Jako takže jako budu každou funkci krokovat? A to jako si myslíš, že něco takovýho je třeba jen vzdáleně podobně efektivní, jako když si tu funkci prostě přečtu? ???
Citace
O, a tady se zase ukazuje, že jste laik, který o tom nic neví. Klient žádné neužitečné skripty nenahrává a neprovádí žádný kód, který není k funkčnosti stránky potřeba.
Je ten websocket pro uživatele k něčemu? Není. Otevírá ho nahraný kód do browseru? Otevírá.Nahrává a provádí se tedy "neužitečný kód"? Provádí.
Klasika - to, že se někdo do druhého začne navážet je vždy známka toho, že mu došli argumenty.
Citace
Mýlíte se. Ochrana proti XSS je samozřejmě záležitostí backendu. Kdyby byla na frontendu, útočník si ji prostě vypne a máte po ochraně.
Jednoznačná kravina. Některé XSS útoky jsou ošetřitelné pomocí hlaviček. Ovšem některé (např. nejtriviálnější je např. když je v kódu funkce eval na hash za URL) žádnejma hlavičkama prostě neošetříš, i kdyby ses na hlavu postavil. A i ty, které CSP zachytí: ještě jsou v provozu browsery, které CSP nepodporují, takže neřešit to, že to CSP zachytí je diletantština. CSP je ochrana proti chybám ve frontendovém kódu, ne že dáš CSP a o bezpečnost frontendu se nemusíš starat.

Sorry, ale todle jsou úplné základy. Bavit se o bezpečnosti a todle neznat - a prohlašovat ostatní za laiky? ??? ?

(A jako třešnička na dortu - to Moneta IB "samozřejmě" žádné CSP hlavičky neposílá, což je jen další známka neprofesionality té aplikace. )

Citace
Pochopte už konečně, že frontend má plně ve své moci uživatel. Takže na tom nemůže záviset bezpečnost,
A ty zkus pochopit, že existují dva způsoby narušení bezpečnosti, jeden je ochrana aplikace "před uživatelem" - tedy aby si např. uživatel nepřevedl něco z cizího účtu - a tam je Tvá námitka validní.

Ovšem bezpečnost aplikace zahrnuje i ochranu uživatele před tím, aby ho nějaká třetí strana vmanipulovala do něčeho, co nechce, i když je to z hlediska "serveru" naprosto validní požadavek (např. aby útočník nezměnil číslo účtu kam se prostředky převádějí)a pro tuto rovinu  je Tvoje námitka naprosto nesmyslná - a právě tato rovina bezpečnosti je záležitost přinejmenším stejnětak frontendu, jako backendu.
Citace
Když někdo ušetří pár vteřin nebo minut tím, že má kód rovnou v čitelné podobě, stejně narazí na zabezpečení na backendu.
???? Okradl Tě? Okradl. Tedy vyřešilo zabezpečení backendu všechny problémy? Nevyřešilo. Pro to, aby Tě neokradl, tak musí být jak zabezpečený backend, tak i frontend. Toto je z Tvé strany argumentační faul falešné generalizace, kdy z toho, že některé problémy se řeší na backendu vyvozuješ, že tam jdou vyřešit problémy všechny.

---

Ač bych mohl pokračovat ve vyvracení, tak na zbytek reagovat nebudu - sorry, ale diskuse s člověkem, co je přesvědčenej, že je jedinej profík v diskusi: a co věta to perla, to mne nějak přestalo bavit.

111
Server / Re:Router a Server v jednom
« kdy: 05. 05. 2021, 18:55:54 »
Citace
Proto se to obvykle nepovažuje za zabezpečení, pouze za mitigaci projevů.
V podstatě s tím souhlasím. Ale zas nepsal jsi?

Citace
Takže pokud někdo položí otázku "je to bezpečné?", je taková otázka nezodpověditelná bez doplnění očekávání.
Takže skrytí portů bezpečnost zvýší, jen ji nezvýší tolik, jako jiné, lepší řešení problému. Otázka tedy je: zvýší to (pro danou aplikaci) dostatečně?

112
Filip:
Citace
To, že to považují za „best practice“ lidi, kteří nemají s webovým vývojem nic společného
Sorry, Filipe, ale opět klasika - docházejí Ti arugmenty, tak začínáš agumentovat ad hominem. Mluv za sebe, jestli o dané věci nic moc nevíš Ty ještě neznamená, že s webovým vývojem nemají zkušenosti ostatní..... :-)
Tvrdit, že já to vidím správně, protože všichni ostatní jsou laici, to je jen varianta naprosto učebnicové arogance: "já vím všechno nejlíp".


Citace
Což uvidíte i v minifikovaném kódu, fakt to není nijak skryté.
Minifikovaný kód je řádově obtížnější na čtení, než původní. Sorry, ale tady pronášíš kategorické soudy o věci, se kterou evidentně nemáš reálné praktické zkušenosti.
Citace
ale v případě IB Monety prohlížeč používá minifikované soubory, takže to je v pořádku.
Není. Nahrávat "neužitečné" skripty a provádět na klientu nějaký kód, který není k funkčnosti stránky potřeba je z hlediska UX naprosto stejný problém, jako nahrávat neminifikované soubory. Zbytečné zpomalení.

Citace
Pro webové stránky provozovatele ultralightů a komerčního dopravce v letectví ale platí stejná pravidla.
Ano, protože webové stránky dopravce nepatří ke "klíčové letecké infrastruktuře". Ovšem frontend bankovnictví klíčová infrastruktura je, neboť nemálo bezpečnostních problému (jako např. ochrana proti XSS) jsou záležitosti frontendu (zdaleka ne vše je zajištěno explicitní autentifikací na serveru po prvotním přihlášení).Takže v tomto je Tvůj příměr úplně mimo. Pokud Ti někdo úspěšně napadne frontend, tak mu to např. podstatně usnadní provádění různých variant phisingových útoků atd. atd.....
Další mimoňství toho argumentu spočívá v tom, že autor webových stránek leteckého dopravce nemá např. s piloty společného vůbec nic. Ale vývoj frontendu jde zpravidla v úzké součinnosti s vývojem backendu, že jde opět o úplně jiný případ: zatímco piloti a webaři mohou mít úplně jinou "firemní kulturu", tak pokud jsou někde lajdáci frontendáři, tak zpravidla jsou i backendáři.

Citace
Ne, bezpečnost webových aplikací vážně nikdy nikdy nikdy nemůže být založena na tom, co dělá frontendový kó
Zaprve to co tvrdíš je blbina. Bezpečnost webových aplikací závisí I NA FRONTENDU. Viz předchozí odstavec.

Zadruhé je to z Tvé strany další argumentační faul: že když neumíš vyvrátit to, co tvrdím, tak můj argument překroutíš, abys měl co kritizovat.
Netvrdil jsem, že na tom bezpečnost stojí (byť vlastně i stojí, viz výš). Tvrdil jsem, že to zesložiťuje případný útok. Bezpečnost zámku také nestojí na tom, že útočník neví, kde vrtat, ale na tom, že je z "tvrdokovu" a tedy velmi obtížně odvrtatelný. Ale znalost, kde vrtat a kam se postavit, abych nebyl vidět na kameře, urychlí a usnadní provedení útoku.

Nedodržování best-practicies v jedné věci je důvodem k tomu se domnívat, že se nedodržují i v jiných věcech. Tedy i kdyby to nakrásně byla jen chyba UI (příliš dlouhé načítání stránky kvůli zbytečně dlouhému kódu), tak je to důvod k pochybnostem, jak jsou dodržována další pravidla ohledně bezpečnosti. A to nejen pro nás, ale i pro hackery - tedy je větší šance, že se někdo takovou stránku pokusí napadnout. A nějaká chyba je snad v každém SW.


JenTak:
Citace
na to ale nepotřebuju ten kod ani mimifikovaný ani původní .. stačí se podívat na requesty, co jdou na server.
Teoreticky ano. Prakticky znalost zdrojového kódu Ti podstatně urychlí analýzu API a vyhledání potenciálně slabých míst, a to z mnoha důvodů.
  • na server Ti nikdy nepůjdou všechny requesty na všechny api, co server nabízí. Při hackování potřebuješ odhalit ty, které jsou chybně implementované, a to jsou zpravidla právě ty, které se nepoužívají moc často. A právě takové requesty nemusíš nasimulovat, ale v zdrojovém kódu je můžeš vyhledat.
  • z console browseru sice vidíš requesty, ale nevidíš význam parametrů. Znalost zdrojového kódu Ti často hodně pomůže porozumět významu requestu a tedy můžeš snáz odhadnout, kde nechal autor toho api "díru".
  • ....

113
A k
Citace
minifikovnaý kód je nijak neskryje
To není ani náhodou pravda. Mohou být v minifikovaném kódu např. jako názvy samotných endpointů v rámci nějaké struktury API, parametry k nim pak se mohou doplňovat v jiných funkcích. Samozřejmě, za pomoci reverse engeneering to jde všechno dohledat, ale stojí to podstatný čas a úsilí. A to je nezřídka právě ten faktor, který rozhoduje o tom, zdali bude daný systém hacknut nebo ne.

Zámek, co máš do bytu, také není nepřekonatelný. Je jen tak obtížně překonatelný, že útočníkovi se nevyplatí na to plácat čas. Vystavit zdrojové kód je totéž, jako napsat na dveře: zloději, zámek odvrtávejte zde - a zde je místo nepokryté kamerovým systémem.

114
Citace
Strukturu API odhalí hlavně výpis volání,
To sice ano, ovšem znalost způsobu, jakým jsou požadavky sestavovány, může podstatně ulehčit porozumění těm voláním. Je to prostě naprosto zbytečné dávání informací útočníkovi.
Otázka nezní, jak se to dá zneužít. Otázka zní: proč dělat něco, co usnadní útočníkovi útok, byť jen třeba o malý fous - když jsou standardizované postupy, jak se tomu vyhnout?
On stačí už jen ten fakt, že to vypadá neprofesionálně - což (viz reakce v této diskusi) evidentně přinejmenším části odborné veřejnosti připadá. I to je bezpečnostní riziko, protože SW, co nevypadá profesionálně, "přitahuje" hackery. I jen tento "měkký" fakt snižuje bezpečnost takovéo řešení.
Citace
K leteckým nehodám nedochází po sérii neškodných chyb, ale po sérii reálných chyb.
Nezřídka je každá z těch chyb defakto benigní. Sama o sobě by nijak bezpečnost letu neovlivnila. Ale souběh více takových chyb ano.

Citace
Žádné pravidlo, že na serveru musí být jen mimifikovaný kód, neexistuje.
Jak vidíš, poměrně dost lidí tady v diskusi to za "best practicie" považuje.
Nejen z důvodu bezpečnosti: také z důvodu rychlejšího nahrávání stránek.

Citace
Většinu doby, co existuje web, se na server dával přesně ten samý kód, který napsal programátor.
Ano. S leteckými předpisy je to úplně stejně. Na začátku dokonce předpisy nebyly vůbec. Pravidla a "best practicies" jsou až reakcí na problémy.

Citace
U jednoduchých webů se to tak dělá dodnes, protože nestojí za to to řešit.
Ano, pro ultralighty také platí podstatně mírnější pravidla, než pro komerční dopravní letectví.

Btw. píšeš, že s jednoduchými weby se to tak dělá dodnes. Tedy implicitně tvrdíš, že se složitějšími se to tak už nedělá. Tak vidíš, že je "normální to dělat". Tedy že se to "zpravidla" dělá......

115
Citace
Bez ohledu na to, jestli je to nebo není bankovnictví - pokud v tom FE není žádná kritická logika, případně nějaké pokusy o  enkrypci dat, či nějaký obfuskovací kód, a de-fakto zveřejněné zdrojáky neusnadní nějaký útok na toto, je to, jestli tam jsou, nebo ne.. vcelku úplně jedno,
Kritická logika v tom asi nebude. To ovšem neznamená, že to nemůže nějak odkrýt např. strukturu API, což útočníkovi může usnadnit další útok. Ale to není to podstatné.
Koukni se někdy na nějaký seriál o leteckých nehodách. Letecké katastrofy se nestávají proto, že někdo udělá jednu obrovskou katastrofální chybu. Zpravila se stávají proto, že nebyla dodržována pravidla - a souhrn mnoha "neškodných" chyb dá dohromady průšvih. Proto je v letectví takový důraz na dodržování pravidel - i když se z vnějšku často zdají jako formalismus. A bankovnictví v oboru SW je podobně "precizní obor", jako letectví v průmyslu.

Samozřejmě, je možné, že to bylo "ojedinělé opomenutí" a jinak je jejich E-banking dobrá práce. Ale dá se o tom vcelku důvodně pochybovat. Právě proto, že nedodržují "standard practicies", nemají procesy nastaveny tak, aby se takováto věc nestala. Je tedy klidně možný, že ten jejich současný systém je neprůstřelný. Ale co až tam někdo vyrobí opravdovou díru? Všimne si ji někdo, než přijde do produkce? A každý programátor někdy díru udělá....




116
nealem:
Deminifikovat to jde. Ale názvy proměnných jsou nemalou součástí dokumentace, a ty neobnovíš. Takže jde o poskytnutí dokumentace potenciálnímu útočníkovi. Ale to v podstatě píšeš.

Od opensource se to přitom liší tím, že u opensource chyby hledají nejen útočníci, ale i uživatelé. Tady žádný "whitehackeři" nejsou, takže to z bezpečnostního hlediska spojuje nevýhody open a closed-source. Samozřejmě, security by obscurity je špatně, na druhou stranu, člověk také nedává do výlohy zlodějům plánek, kde má jaké bezpečnostní kamery, protože je přesvědčenej, že svůj objekt zabezpečil dobře. Každá věc, která útok ztěžuje, je dobře.

117
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 04. 05. 2021, 14:34:32 »
Citace
A na to já už jsem odpovídal, že mezi definicí služby a připojovacími podmínkami není žádný rozdíl.
Minulý post jsi začal diskutovat slušně, vydrželo Ti to jeden post, než jsi zas sklouznul k "nečtu co druzí píšou a jen dokolečka opakuju totéž". Rozdíl mezi těmi pojmy a čím se tyto pojmy liší jsem Ti vysvětlil v minulých postech. Nijak jsi na tento rozdíl nereagoval, ani jsi ho nevyvrátil.

Připojovací podmínky jsou smluvní závazky zákazníka (které podmiňují povinnost poskytovatele splnit smlouvu), "definice služby" je závazek poskytovatele. Evidentně jde tedy o ortogonální ustanovení uzavřené smlouvy a není to ani náhodou totéž.

Citace
Sláva, konečně jste pochopil, že jde o to, jak službu vnímá zákazník, tedy zejména zda je v souladu s jeho očekáváním.
Kolikrát mám napsat, že dle zákonů ČR je ISP povinen plnit smlouvu, nikoli nějaké očekávání. A že tvrdím, že ISP neplní smlouvu, takže jakékoli Tvé tvrzení o tom, že možná plní nějaké očekávání je prostě demagogie?Kvalita služby není žádné "očekávání zákazníka", ale věc, která je na jakémkoli očekávání zákazníka nezávislá. To, jestli má připojení takovou nebo makovou rychlost či latenci nijak s tím, co zákazník očekává, prostě nesouvisí. To je kvalita služby - její objektivní vlastnost, naprosto nezávislá na jakémkoli očekávání zákazníka, definovatelná obecně bez jakékoli závislosti na zákazníkovi.

Jsou dvě možnosti: buďto zákazník očekává to, co je ve smlouvě. Pak je nesmysl mluvit o očekávání, pak jde čistě o zamlžování pravé podstaty věci: že poskytovatel je povinnen dodržet smlouvu.Anebo zákazník očekává něco jiného. Pak, když očekává více, nebo něčco jiného, tak má prostě smolík. A když očekává méně, tak to nijak nemění fakt, že poskytovatel je povinnen dodržet smlouvu, nikoli očekávání.Tak prosím už těch nesmyslů ohledně očekávání nech - toto píšu asi po padesáté.

Citace
Pro některé zákazníky je služba „veřejná IP adresa“ použitelná,
Kolovrátek. Debata je o tom, zdali to, co nazýváš veřejnou IP adresou je skutečně veřejná IP. Tvoje odpovědi jsou stylem:"Já: Ale Jabloň není květina, vždyď je ze dřeva. Ty: Je to květina, koukni, jak kvete. Já: Ale všechno, co kvete, není květina. Jabloň kvete, a čichni si, jak hezky voní"Ano, to co píšeš je v tvojí definici IP konzistentní

Citace
Vždyť jste to v předchozí části sámnapsal, že podstatná je použitelnost.
Ne, napsal jsem, že je podstatné, aby ISP deklaroval vlastnosti, které podstatně ovlivňují použitelnost. Z toho, co jsem psal tedy plyne jediné: že i kdyby byla VIPA definovaná jak tvrdíš, tak by poskytovatel měl povinnost zveřejnit jakou technologií ji poskytuje. Zas jen potvrzuješ to, co tvrdím, jen Ti to nedochází.

Jenže já tvrdím, že Tvoje definice VIPA je špatně, protože a) zahrnuje i služby, které nikdo nepojmenuje VIPA, b) nelze její obsah určit bez zákazníka. Takže zas to je odpověď ve stylu: "jabloň není květina, je dřevnatá - ale je, podívej se jak kvete".Na první námitku jsi neodpověděl snad nikdy (od té doby, co ses dozvěděl, že STUN není portforward), na druhou sice částečně odpovídáš, ale naprosto mimo, zaprve viz další dva odstavce.
Citace
Takže i bez konkrétního zákazníka lze ověřit, zda ISP bude schopen poskytnout určitou službu
Opět fabuluješ. Nebude možné ověřit, zdali ISP je schopen poskytnout službu VIPA tak, jak jsi ji definoval Ty. Protože pokud např. ISP poskytuje NAT 1:1 označený veřejná IP, tak podle Tvé definice:Přijde zákazník 1 objedná veřejnou IP. ISP opravdu zpřístupní služby definované tímto zákazníkem, tedy závazek splní.
Přijde zákazník 2 objedná veřejnou IP. Protože bude chtít IPSEC, tak ISP naprosto stejnou službou smluvní závazek nesplní.
Tedy je z toho vidět, že tak, jak jsi definoval veřejno IP, jde ve skutečnosti nikoli o jednu službu, ale o několik různých služeb. Tedy není bez zákazníka dobře definovaná, a tedy nejde bez zákazníka ověřit, zdali ISP poskytuje službu VIPA.Co jde ověřit je, zdali poskytuje službu NAT 1:1. Nebo zdali poskytuje (skutečnou tedy routovanou) veřejnou IP. Protože to jsou dobře definované služby "nezávislé na zákazníkovi".
Citace
Už jsem vám asi milionkrát vysvětloval.... Ano, je – je to zákazník, který potřebuje jet do Brna, takže si vybere dopravce, přijde na Florenc a tam si vybere autobus jedoucí do Brna. Zákazník má nějaká očekávání, kam dojede – dopravce očekává jenom to, že dostane zaplaceno
Ano, dokolečka opakuješ s odpuštěním totální kravinu, i když jsem Ti ji už několikrát vyvrátil. Ano, zákazník něco potřebuje, ale to nijak nemění, že ten autobus vypravuje dopravce a ten autobus jede tam, kam určil dopravce, za podmínek, které určil dopravce, a to dřív, než do něj kterejkoli zákazník nastoupí. A jakékoli očekávání zákazníka nemá naprosto žádný vliv na to, kdy, kam a jak ten autobus pojede.
Čekají zákazníci, že autobus do Brna pojede do Plzně? Nepojede, i kdyby to čekali všichni, co v tom vlaku jsou. Čekají, že dostanou kafe? Smůla, nedostanou. Chtěli by vystoupit mimo zastávku? Houby. Autobusák prodává lístky do Brna, a ty si je můžeš koupit nebo nekoupit. Tečka.

Poruší dopravce smlouvu, pokud by (klidně všichni) zákazníci čekají, že autobus jede do Brna, ale on jasně a zřetelně deklaroval, že jede do Plzně a jel by do Plzně? Neporušil. A porušil smlouvu, pokud by zákazníci čekali, že jede do Brna, ale koupili si lístek do Plzně - a on je BEZ ZMĚNY SMLOUVY dovezl do Brna? Porušil. Protože uzavřená smlouva je na přepravu do Plzně, bez ohledu na očekávání cestujících.

 Očekávání zákazníků je zde naprosto irelevantní. Nabízená služba (hromadného) dopravce je "as is": ber nebo neber. Službu zde naprosto jasně definuje dopravce. Zákazník dělá jedinou věc: rozhoduje se, zdali danou službu definovanou dopravcem využije, nebo ne. Tedy zdali přijme nabídku smlouvy na přepravu, napsanou dopravcem.
Přečti si konečně občanský zákazník a přestaň s odpuštěním mlít kraviny. Vyvěšený jizdní řád a přepravní podmínky tvoří dohromady návrh smlouvy definovaný dopravcem, a to před jakoukoli interakcí se zákazníkem. Toť zákony ČR. A stejnětak funguje drtivá většina ISP v ČR.

118
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 01. 05. 2021, 22:17:16 »
Citace
Jednou v Praze a jednou v Brně
Na to jsem už odpovídal - to není věc definující službu, pouze "připojovací podmínky" (tedy kde Tě připojí).
Citace
telefonním vedení, jednou po ethernetu a jendou po optice?....
Ovlivňuje to nějak kvalitu dodané služby, především tu garantovanou, nebo ty sice negarnatované, ale podstatně ovlivňující použitelnost služby? Pokud ano, tak ano. Pokud ne, tak to není zákazníkova věc, jakým způsobem ISP službu dodá, když dodá "stejně kvalitní službu".

Citace
Služba „můj domácí NAS a IP kamera budou dostupné přes webový prohlížeč odkudkoli z internetu“
Jenže toto není služba veřejné IP tak, jak jsi ji definoval. Ty jsi nedefinoval veřejnou IP tak, že ISP musí zpřístupnit služby definované Tebou. Ty jsi tu službu definoval jako zpřístupnění služeb definovaných zákazníkem - ten je pokaždý jiný a proto není Tvá definice dobře definovaná. Když si objednám veřejnou IP adresu já, tak podle Té definice mi nemá ISP zpřístupnit Tvůj NAS a IP kameru. Má mi zpřístupnit služby, které definuji já, např. ten IPSec. A můj soused bude požadovat VOIP - tedy mu bude stačit STUN server.

119
/dev/null / Re:Vymazání metadat z mailu (offtopic)
« kdy: 01. 05. 2021, 13:19:47 »
FKoudelka:
Nepředpokládám, že myslíš mne, ale Filipa, ale i kdyby. Ono je to problém - s "politickým komentářem" jsme tady nepřišel první ani já, ani Filip. Proč to tedy házíš na Filipa? Že reagoval? S tím, jak Filip diskutuje se velmi často hrubě neztotožňuji. Ale tady to není primárně jeho chyba.

Samozřejmě, mohli jsme nereagovat. Ale takové nereagování vede k tomu, že je internet plný "polopravd" - které ať chceš nebo nechceš působí na lidské názory. Samozřejmě, zásah moderátora (a přinejmenším odsunutí do /dev/null) by byl asi na místě (než jsem to napsal, tak i zareagoval, děkuji). Ale v okamžiku, když nereagoval moderátor, tak je to prostě Sofiina volba.
Možná se přikláníš k Pajahově vidění problému - a tak Ti nevadí, když tu zazní "jeho politický komentář". Ok, na to máš právo. Pak ale neupírej ostatním právo to vidět jinak a na politický komentář odpovědět politickým komentářem.

====

Jinak - on je problém, že samotný Tvůj dotaz je vlastně reakcí na velmi vágní "novinářskou formulaci". Chtěl jsi odpověď na naprosto nejasné zadání - není divu, že se to tedy vyvinulo v debatu o tom, co vlastně tedy znamená to zadání.

Pokud to chceš řešit na technické rovině, tak ta otázka vlastně nemá smysl, protože naprosto není jasné, co to vůbec jsou "metadata emailu" - co do toho patří a co ne (všechny hlavičky? tedy i informace o odesílateli? i logy mailserverů?, ...?).  A ani nedává smysl spojení "odesílatel odstranil". Odesílatel nemůže nic odstranit, mail vzniká posláním dat na SMTP server, tam není žádný prostor na "odstraňování" (pokud se tím nemyslí nějaké ex-post odstraňování).
Jde evidentně o velmi vágní formulaci, z které není jasné, co přesně vlastně mail obsahuje a neobsahuje, proto technická debata nad tím vlastně nemá smysl.


Pajaha:
Citace
Když napíšu "asi" tak to znamená, že se domnívám, že tomu tak může být. Neznamená to, že tvrdím, že tomu tak je. 
Sorry, ale to je argumentace jak z Kosma ("A vážně pan ministr řekl, že vám mám upéci Husu? - Podle mých informací, ano."). Že když se jakákoli lež uvede "podle mého názoru" nebo "jak jsem byl informován", že se Tím člověk zbaví jakékoli zodpovědnosti za to, jaké šíří informace a názory.
Rozdíl je tu jediný: v Kosmu si z toho dělali legraci, zatímco Ty to tady myslíš vážně.
Do diskuse patří podložené argumenty. Tedy buďto jsi schopen svůj názor podložit validními argumenty, nebo ho nepiš. A nevymlouvej se poté, co Ti údajné argumenty rozložíme, že to je "jen názor", takže ho podložený mít nemusíš.

Citace
Celá věta znamená, podle mého názoru, že každý (kdo do toho mluvil) buď a) neříká celou pravdu, b)mlží, nebo za c) lže.
1) To, že nikdo neřekne veškeré utajované informace je fakt objev století. Tedy A je splněno triviálně. Pro B a C jsi nepřinesl jediný důkaz (tvrdíš všichni), přitom jde o dehonestující tvrzení. Je to jako bys říkal: buďto je 1+1=2 anebo lžeš. V podstatě jsi jen udělal logický kontrukt, který Ti umožnil obviňovat bez důkazu lidi ze lži.

Takže ano tato věta je logicky pravdivá, ale jde o klasický argumentační faul vzbuzování emocí. Slušný člověk neobviňuje někoho ze lži ani v potenciální rovině, pokud pro to nemá důkaz.

Citace
ale neopravňuje tě to mě tady dehonestovat jako šiřitele ruské propagandy. Nic takového nedělám.
Já Tě ovšem nehonestuji. Toto jsou fakta.
a) Hlásáš tady názor, který snižuje věrohodnost českého zahraničněpolitického zastoupení v této věci. Viz např. Tvůj výrok "Kulhánek mlží a Babiš, Zeman s Hamáčkem lžou." Aniž by jsipřinesljediný důkaz.
b) Hlásá, že se vlastně vůbec neví, jak to bylo. Viz např. "všichni mlží, anebo dokonce lžou."
Jak A tak B jsou přesně postoje, které šíří Ruská propaganda - A je jasné, B viz např.
https://ct24.ceskatelevize.cz/domaci/2807495-analytik-vrabel-rusko-rozklada-nasi-spolecnost-uz-roky-nove-siri-dezinformace-take"Ústředním narativem ruské propagandy je relativizace pravdy. Neexistuje nic jako pravda."Takže prostě prokazatelně Ruskou propagandu šíříš. Znovu: já netvrdím, že úmyslně. Naopak, jestli tedy tvrdíš, že to neděláš úmyslně a že evidentně pokládáš šíření Ruské propagandy za špatné (když to pokládáš za urážku), o to více je mé upozornění na místě (např. aby ses zamyslel, odkud čerpáš podklady pro své názory).
Citace
Což v případě, že by to tak čirou náhodou bylo, přináší spoustu dalších otázek........
Nevidím jediný důvod proč bych zrovna v tomhle případě v jejich vyjádření hledal nějakou pravdu.
Toto je jen variace na klasický argumentační faul: "dokažte mi, že neexistuje špagetové monstrum". Pokud tvrdíš, že někdo lže nebo podvádí, tak to dokaž. A nechtěj vyvracet od ostatních, že něco není lež či podvrh.
Nepřímých důkazů, že v tomto vláda nelže je X. Např. to, že se na tom shodne i většina opozice kromě stran tradičně tu hájících Ruské zájmy. Nebo to, že to udělala vláda, která jinak se snažila dělat vše proto, aby se Rosatom účastnil tendru na Dukovany - takže toto jde evidentně proti jejím zájmům.Navíc ten mail asi nepodvrhl Babiš, že? A o tom, že by kdy lhala BIS, si nedoložil jediný důkaz. Takže opět jde jen o variantu již vyvráceného argumentu falešnou generalizací: někdo někdy lžou => všichni v tomto konkrétním případě lžou.


PS: A ad Tvoje obvinění z vytrhávání z kontextu - to, co dokládám citacemi, tak to vyznívá z celého Tvého postu. Jestli jsi to nezamýšlel, tak to není můj problém, evidentně nejsem sám, kdo to tak chápe.


120
/dev/null / Re:Vymazání metadat z mailu (offtopic)
« kdy: 01. 05. 2021, 00:08:25 »
Pajaha:
Co Ty výčítám? Že manipuluješ informacemi a vyvozuješ z nich špatné závěry. A to závěry, které jsou přesně stejné, jako ty, které do ČR tlačí Ruská propaganda.
 Informace o metadatech vychází z informací respektu. Cituji: "Jak zjistila během vyšetřování česká policie....". V celých odstavcích není ani slovo o tom, že by jakákoli z těchto informací byla od BIS. Tedy Tvoje námitka, cituji:
Citace
Hmm takže BBC má asi víc informací než naše tajná služba.
Je prostě trojnásobná lež.
  • I kdyby se BIS jakkoli vyjadřovala o případu, to, co BIS komunikovala na venek a to, co všechno ví, spolu souvisí jen velmi volně.
  • Informace o metadatech evidentně nepocházejí od BIS, ale z nějakého úniku od policie ČR, tedy vyvozovat z toho cokoli o BIS je argumentační faul.
  • BBC píše o rozkrytí identity odesílatele, přičemž mail odesílatele nemusí být zahrnut mezi metadata, takže mezi "BBC" a "Respektem" ve skutečnosti není žádná kontradikce.
Tedy pro Tvůj výrok
Citace
všichni mlží, anebo dokonce lžou.
jsi nepřinesl jediný důkaz. BIS nijak nemlží, jen prostě neříká vše, co ví - což je jak u živého případu, tak v případě tajné služby naprosto normální. To není žádné mlžení - neboť mlžení znamená úmyslně nepřesné vyjádření s cílem zastřít pravou podstatu věci. A i kdybys nakrásně (a špatně) označoval "neříkání všeho" mlžením, tak ty z toho, že BIS neříká vše dovozuješ, že "všichni lžou": což je hrubý argumentační faul.

Všechny Tvé výše zmíněné argumentační fauly pak směřovaly právě k tomuto jedinému závěru: zpochybnění věrohodnosti českých tajných služeb. A to je právě to, o co se snaží ruská propaganda. Neříkám Tím, že jsi za to placený ani že jsi ruský troll, ale to, že - ať už vědomky či nevědomky - tu ruské propagandě pomáháš, je prostě fakt.

Stran: 1 ... 6 7 [8] 9 10 ... 68