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 - Kit

Stran: 1 ... 31 32 [33] 34 35 ... 47
481
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 12. 10. 2019, 14:56:11 »
Při prezentaci je zase nutné předat data do HTML, proto se obvykle používá funkce htmlspecialchars(). Z mého pohledu je poněkud zastaralá - PHP nabízí lepší, objektové řešení, u kterého už nemusím přemýšlet nad typem eskejpování v daném kontextu.
Myslíš jako pomocí DOMDocument? nebo něco jiného?
Ideálně prosím dej nějaký příklad kde se to používá.
Ano, mám na mysli DOMDocument. Vyleze z toho hotové XML či HTML, kde jsou potenciálně nebezpečné znaky řádně transformovány do entit.
DOMDocument je možná bezpečnější, ale to "lepší" se mi moc nezdá (spotřeba paměi,výkon,nutnost kompletního DOMu před odesláním na clienta).
Navíc transformace DOMu se dost liší od běžného použití php jako preprocesoru. To už mi přijde "lepší" použít nějaký framework, než toto.Ale to už jsme mimo téma.

Příznivci funkcionálního programování zde mají příležitost, jak se vyřádit. Nutnost kompletního DOMu nevidím jako překážku, jen málo úloh při tom vyžaduje víc než 1 MB. Obvykle to jsou jen desítky až stovky KB, se kterými si hravě poradí v malých jednotkách ms. Odezva je tedy řádově rychlejší než u běžných frameworků. Pokud bys ten DOM nechtěl generovat naráz, tak nemusíš. Uděláš jednu větev, exportuješ, uděláš další, exportuješ,... Efektivnější je však vygenerovat vše naráz, nemusíš tak plýtvat drahým echem. Po odladění jen vypneš odsazování. Navíc se v XML, které dostaneš navíc jako bonus, hledají chyby mnohem snáze než v HTML.

482
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 12. 10. 2019, 11:19:32 »
Při prezentaci je zase nutné předat data do HTML, proto se obvykle používá funkce htmlspecialchars(). Z mého pohledu je poněkud zastaralá - PHP nabízí lepší, objektové řešení, u kterého už nemusím přemýšlet nad typem eskejpování v daném kontextu.
Myslíš jako pomocí DOMDocument? nebo něco jiného?
Ideálně prosím dej nějaký příklad kde se to používá.

Ano, mám na mysli DOMDocument. Vyleze z toho hotové XML či HTML, kde jsou potenciálně nebezpečné znaky řádně transformovány do entit.

483
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 12. 10. 2019, 11:11:40 »
mikto nehovorí o obchádzaní driverov, ale než sa zavolá funkce driveru, tak proč by framework nepripravil data do bezpečnej podoby? Teda zabránil SQL injection a pod? Podla mňa je mnoho kvalitných frameworkov ktoré robia aj toto, a považujem ich za kvalitné a správne riešené.

Protože tohle už ten DB driver dělá, sám se efektivně brání proti SQL injection.

484
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 11. 10. 2019, 22:11:10 »
Framework s tím nedělá vůbec nic, jen to předá dál.
Kecáš nezmysel, a ešte jak to môžeš takto všeobecne povedať, frameworkov je miliarda. Nezáleží náhodou ktorý použiješ?

Kvalitní framework to skutečně jen předá dál do databáze přes prepared statements. Nic víc s tím totiž není třeba dělat. Databázové ovladače není radno obcházet.

Při prezentaci je zase nutné předat data do HTML, proto se obvykle používá funkce htmlspecialchars(). Z mého pohledu je poněkud zastaralá - PHP nabízí lepší, objektové řešení, u kterého už nemusím přemýšlet nad typem eskejpování v daném kontextu.

485
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 10. 10. 2019, 19:15:32 »
No tak potom prostě před uložením zkontrolujete vstupní data a pokud v nich najdete něco ze skupiny [&<>] tak to uživateli vrátíte s chybovou hláškou o nepovolených znacích. Nebo ty znaky prostě z dat vyhoďte když vám zabírají místo.
V čem je vlastně problém ?

Stefan
Ale vlastně vůbec v ničem. Přesně toto jsem přece psal v otázce, že to tak udělám a zda to tak stačí. Jen jsem chtěl slyšet jestli to stačí nebo ne.

To je právě chybně. Co když uživatel potřebuje uložit znaky <&> a ty mu je z nějakých pochybných důvodů smažeš? Hezky mu je tam nechej.

486
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 10. 10. 2019, 19:11:35 »
To escapování se dá obejít - za určitých okolností. Ale je fakt, že podrobnosti si nepamatuju. Na toto téma je třeba prohledat internet:

https://security.stackexchange.com/questions/134208/how-to-bypass-backslash-escaping-xss

Proto se escapování nedělá a nechává se to na databázovém ovladači, který to udělá nejlépe.

487
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 10. 10. 2019, 19:08:01 »
K čemu má být escapování dobré? Vždyť to každá databáze má jinak. Smysl mají jedině prepared statements. Můžeš použít i metodu quote(), ale to je jen taková nesystémová  nouzovka.
no ja neviem, ja to nikdy neriešil, na holom nerobil... framework mi sanitizing vyriešil priamo.

Framework s tím nedělá vůbec nic, jen to předá dál.

488
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 10. 10. 2019, 15:37:49 »
Navyše hodnoty v databázy ani netreba sanitizovať tak jak sa tu popisuje, stačí escapovať 3 znaky... Uvodzovky, apostrofy, a spätnú lomku. Ale bežne teraz framework už obstará kompletný sanitizing.

K čemu má být escapování dobré? Vždyť to každá databáze má jinak. Smysl mají jedině prepared statements. Můžeš použít i metodu quote(), ale to je jen taková nesystémová  nouzovka.

489
Distribuce / Re:Shell - přihlášení
« kdy: 08. 10. 2019, 10:17:58 »
Přihlásit se z jiného účtu přes sudo

490
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 04. 10. 2019, 17:09:29 »
Kód: [Vybrat]
SELECT tbl1.* FROM tbl1
  INNER JOIN tbl2 ON tbl1.id_data = tbl2.id_data
  WHERE t2.allowed>0

491
Hardware / Re:Cvakání v novém notebooku
« kdy: 28. 09. 2019, 18:56:33 »
Reklamovat, případně odstoupit od smlouvy.

492
Server / Re:Předsunutý HTML kód
« kdy: 25. 09. 2019, 20:11:54 »
Ja pouzivam ten prepend/append pro zpracovani jednoho webu - puvodni data byli u predesleho poskytovatele v nejakem CMS, ktery se editoval jako wysiwyg - klient nebyl spokojen s cenou, takze chtel odejit - ale neexistovala moznost exportovat uzivatelska data, takze se udelal rekurzivni wget a mame staticky mirror. Nad tyhle data se prave priplacne muj PHP kod z obou stran, ktery pak algoritmicky edituje puvodni HTML mirror - zejmena odstranuje copyright na CMS, nejake jejich interni admin linky.. a celkove kultivuje ten generovany kod. Neni to web, kde by stalo za to resit stovku podstranek prepisovanim.. tak jsem to vyresil takto. Na blby problem, blba zaplata.

K tomuto účelu používám XSLT šablony. Je to snadné a rychlé, dají se měnit elementy, jejich atributy, přehazovat bloky apod.

493
Vývoj / Re:Java - jak vymazat z ArrayListu množinu položek
« kdy: 24. 09. 2019, 15:49:58 »
Proto je výhodné programovat proti rozhraním, protože pak i tu uzavřenost ArrayListu můžete snadno obejít tím, že si vytvoříte vlastní implementaci Listu, která uvnitř vymění celý ArrayList.
Podstatou problemu byla prace s ArrayListem a to neni rozhrani.

Správně. Když mám v ruce kladivo, všechno najednou vypadá jako hřebík

494
Vývoj / Re:C++ no default constructor exists for class
« kdy: 23. 09. 2019, 16:40:14 »
C) občas je k vidění varianta "maximálně úsporná" = jména symbolů jsou 2-4 znaky dlouhé zkratky :-) Viz třeba zdrojáky Perlu.
...
( C) je samozřejmě blbost s Perlem nesouvisející, je rozdíl mezi built-in/idiomatickými proměnnými a tím, jak se pojmenovávají "uživatelské" proměnné.)

O nic nejde - nejsem si jist jestli si správně rozumíme, pro jistotu upřesním: měl jsem na mysli Céčkové zdrojáky samotného Perl interpretru, viz např. datový typ SV znamená Scalar Value, třeba tady na řádku 321 atd. (deklarace 'SV* sv;' a návazná užití té proměnné). Celá perlová střeva jsou špikována takto pojmenovanými elementárními typy. Připomíná to písničku "Zkratky" od Ivana Mládka.

Tak to se omlouvám, opravdu jsem to pochopil špatně.
I když si stále nemyslím, že by to měl být nějaký "standalone" styl pojmenovávání proměnných, spíš prostě způsob jak si ulehčit psaní dlouhých jmen, když je to v tu chvíli jasné.

Ono by to bylo špatně i v případě, kdyby se ta proměnná jmenovala scalar_value.

495
V tom případě asi nepotřebuješ pracovní stanici, ale vystačíš si s běžným PC s i3 nebo i5, integrovanou grafikou a rozšířenou RAM.

Stran: 1 ... 31 32 [33] 34 35 ... 47