Názory k článku PHPMailer má kritickou chybu, ohrožuje miliony webů
-
Díval jsem se na diff opravy a nevypadá to, že by se zranitelnost provevila při volání funkce mail. Spíše se projeví, pokud se volání mail obejde a volá se rovnou sendmail přes shell. Navíc se musí vyplnit pole from daty od útočníka.
Ale procházel jsem jen zběžně jeden diff, který někdo odkázal na Twitteru. Ten obsahoval různé vzájemně nesouvisející změny, mohl jsem něco přehlédnout, něco může být mimo tento diff nebo někdo mohl dát link na falešnou stopu.
-
Vycházel jsem z popisu chyby od původního objevitele. Ten to záměrně popisuje trochu mlhavě, protože nechce prozrazovat úplné detaily. Ale budu samozřejmě rád za konkrétní upřesnění, pokud je ten popis chybný.
-
Já vycházím z commitu https://github.com/PHPMailer/PHPMailer/commit/4835657cd639fbd09afd33307cef164edf807cdc via https://mobile.twitter.com/kyhwana/status/813310093903077380 via https://mobile.twitter.com/spazef0rze/status/813479961340342273 . Jak jsem psal, nedělal jsem detailní průzkum, jen jsem byl zvědavý.
Chápu, že se držíte oficiálního oznámení. Já bych ostatně z této rychlé analýzy taky nedělal definitivní závěry.
Pokud je toto všechno, tak mi přijde, že by objevitel/autoři byli udělali možná i lépe, kdyby to zveřejnili s podrobnostmi.
-
Hmm, takže fix je prý nekompletní. Hledat diiff se mi nechce.
Z https://mobile.twitter.com/spazef0rze/status/814147558008360960 .
-
TanyStříbrný podporovatelOn se ten problém vyřeší sám, až bude crawler (pokud už není) na hledání slepenin s tou chybou, tak se ta chyba začne zneužívat a ty poslepovaný weby se objeví ve spamhausu apod.
Pak už to provozovatelé/majitelé/poskytovatelé začnou řešit, protože budou končit ve spamu.
-
František Havel (neregistrovaný)
Problém je v tom "snad" protože neumíme odhadnout kolik je "snad" :-).
Žertuji, chápu tě, to jestli mail dojde nebo ne není podstatné, podstatné je jestli dokážeme vložit argument k tomu volání binárky sendmailu co dělá phpmailer přes "exec" a ten se pak vykoná jako samostatný příkaz ne ?
Tedy nezkoumal jsem to do detailu, aktualizoval na wpcore (viz patche) a i samotný phpmailer na 5.2.19. -
Záleží na kontraktu API – jestli je vyžadována validní emailová adresa, nebo jestli to API slibuje zvalidovat.
Dále si nejsem jist všemi edge cases – jestli existuje validní vstup, kterým by šlo provést útok. Nevím, kterým shellem je to interpretováno (hádám /bin/sh), ani do detailu které přesně znaky jsou povolené v e-mailové adrese.
-
Objevitel zranitelnosti právě upozorňuje, že v případě použití validace podle RFC tam jde parametry dostat, protože RFC umožňuje používat mezery v uvozovkách - viz PoC https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html
Osobně tedy mezery v mailu ve validaci zakazuji, ale před pár lety jsem zakazoval i +, které se nyní používá stále více...
-
LT (neregistrovaný)
Týka sa táto chyba len základného použitia cez mail(), alebo aj použitia s vlastným smtp serverom? Na desiatkach webov používam staršiu verziu a z rôznych dôvodov ich už nebude možné aktualizovať. Úplne všetky ale používajú vlastné smtp servery + všetky majú pevne nastaveného odosielateľa.
Díky
-
LT (neregistrovaný)
Pozrel som to rovno v zdrojáku a chyba bude len pri nenastavených smtp údajoch. Ak sú nastavené PHPMailer sa pripája rovno na smtp server.
https://github.com/PHPMailer/PHPMailer/blob/master/class.phpmailer.php#L1331
-
. . (neregistrovaný)
servery nemá spravovat člověk, který tomu nerozumí!
Jedná se o php knihovnu, která není v debiáních balíčcích. Aktualizovat server podle toho, kde výjde jaká zprávička je dost špatné, primárně máš aktualizovat z daného security kanál ve své distribuci, tam zpravidla je k dispozici jíž aktualizace v momentě, kdy se o tom začalo psát.
-
uroboros (neregistrovaný)
vzdyt ma pravdu. Ja se tem chybam v PHP taky uz leta smeju, protoze to leta nepouzivam. Jsou lepsi veci na psani webitek. Ale kdo chce kam .... Jedinej duvod, proc se to pouziva je ten, ze v tom "umi" psat hodne lidi a ze to je "zautomatizovany". Takze kazdej "admin" si napise na svym bubuntu apt-get install apache2 mysql php wordpress a ma to hotovy, ze yo. Vzdyt to jede. Ja jsem za takovy lidi rad, bez nich by na internetu nebyla svanda.
-
NULL (neregistrovaný)
Jestli to není spíš tím, že s PHP začíná kdejaká lama a až si na tom pak vyláme zuby, tak trousí takové bobky . . .
Ano, instalace přes konzoli je jednoduchá, ale konfigurace a užití už ne. Jenomže tam jsi evidentně nedošel, to už není pro lamy.
Každopádně až budeš opravdu mít zkušenosti z více typů jazyků a více platforem, ne tak že si uděláš jenom hello world, tak se takových komentářů budeš zdržovat a kroutit očima nad podobnými moudry. Ale tam jsi evidentně taky ještě nedošel. Nevadí, děti je potřeba postrčit a pomoci jim, ne je přemlouvat. Tak si to užij.
-
TanyStříbrný podporovatel
Většina nástrojů, které existují dostatečně dlouho a udržují legacy, aby běželi obstarožní věci, se dají považovat za totální humus.
To je čistě na tom, kdo to píše, protože prasokód se dá napsat ve všem, neb jak se říká: miluju Fortran, protože ho můžu psát v jakémkoli jazyce.
-
Za mě drobné shrnutí:
- jedná se především o nevhodné použití funkce mail a to se netýká jen phpmaileru, ale i dalších nástrojů - roundcube, swiftmailer, email v codeigniter a bude jich spousty dalších
- problém je jen pokud je možné uživatelsky ovlivnit adresu odesílatele (jak už bylo zmíněno)
- pokud maily posílá postfix, tak ten k vytvoření "logu" se spustitelným kódem nelze použít
- pokud phpmailer posílá přes smtp, tak je to také ok
- oprava v phpmaileru 5.2.20 není chyba v phpmaileru, ale přímo v escapování php
- WordPress také phpmailer používá ale má kolem něj wrapper a zranitelný není (což nemusí být pravda u pluginů) -
To jistě, ale já to myslím tak, že jayzk PHP sám o sobě je kritická chyba. Nevím o žádném jiném jazyce, snad možná kromě Javascriptu (a ani to není jisté), kde by samotná struktura jazyka a jeho standardní knihovny obsahovaly katastrofální bezpečnostní chyby. V žádném jiném jazyce není i ten nejtriviálnější program tak náchylný k dírám, a zároveň žádný jiný jazyk není tak neschůdný pro automatické analyzátory. Starý dobrý Microsoft BASIC z osmibiťáků je proti tomu ADA ;-)
-
Ne že by PHP bylo výkladní skříní dobrého návrhu, ale tvrdit, že „by samotná struktura jazyka a jeho standardní knihovny obsahovaly katastrofální bezpečnostní chyby“ mi přijde dost nadsazené. Standardní knihovna jeste může (teda spíše její implementace), ale struktura jazyka? To je spíš na programátorovi, jak se s tím vyrovná. Že je PHP zbytečně error-prone? Někde ano, ale rozhodně v tom není samo: Podívejte se třeba na C a jeho standardní knihovnu (scanf, strcat etc.). Nebo na Perl.
Navíc to moc nesouvisí se samotnou zprávičkou. Zapomenuté escapování lze udělat v libovolném jazyce.
-
NULL (neregistrovaný)
Ze skušenosti vím, že jazyky jako PHP a JS dělají nejvíce problémů především těm, kteří o té bezpečnosti, escapování či ošetřování vstupů a toku ví prd, protože se jako první naučili dělat v nějakém tom velmi striktním jazyku a tak si naivně myslí, že tím je všechno vyřešeno. JInými slovy: v momentě, kdy dostanou do rukou benevolentní jazyk, tak jsou bezradní a nezbude jim nic než začít prskat. Vždycky se někdo takový najde. Co je ale nutí to vždycky někam vysypat, to netuším . . .
-
Připomínáte mi známý fór, že komunismus se dokáže směle potýkat s problémy, jaké se v jiném systému ani nevyskytují ;-) Jsem možná ze staré školy, ale mám za to, že jazyk je nástroj a tudíž má programátorovi usnadnit práci a umožnit mu se soustředit na řešení zadaného problému, ne se potýkat s kiksy v návrhu jazyka samotného. Psát kód, který obchází a řeší nesmysly, kterých jsou PHP a JS plné, není důkaz vyššího programátorského umění, ale právě naopak to svědčí o programátorově nekompetentnosti, že si nedokázal zvolit lepší nástroj vzhledem k požadavkům daného projektu.
Z hlediska bezpečnosti sám za sebe tvrdím, že jazyk má mít buď silný a prokazatelný typový model (Rust, Haskell apod.), nebo spolehlivou podporu kontroly dat za běhu (python atd.). C sice nemá doopravdy jedno ani druhé, ale aspoň jsou klasické chyby dostatečně známé a kód je natolik průhledný, že ve většině případů je relativně snadné se jim vyhnout. PHP nemá ani tuto polehčující okolnost, dynamická typovací pravidla jsou neuvěřitelná, runtime kontrola neexistuje, celé je to velmi složité a co se doopravdy děje se programátor stejně nikdy nedozví, protože to závisí mimo jiné i a konkrétní konfiguraci interpretru...
-
Ano, PHP není výkladní skříň dobrého návrhu. Pokud mám tu možnost, rád zvolím jiný jazyk. Někdy ale – navzdory všem nedostatkům – může PHP vycházet lépe. Třeba na hodně jednoduché stránky nebo pokud chci navázat na existující ekosystém. Například se mi může hodit WordPress (který ideálně schovám za SandStorm ☺). A když budu mít hodně práce na jiných věcech, přenechám to někomu jinému, protože takového člověka seženu.
-
Na druhou stranu, striktní jazyky vedou k tomu, že člověk musí aspoň trochu přemýšlet, kde má číslo, kde má řetězec atd.
Mám spíše pocit, že problém je v tom, že PHP a JS jsou často prvním jazykem. Kdyby tím bylo typicky C, nedopadlo by to lépe.
Ale uznávám, že třeba ostřílený Cčkový programátor, který nikdy neviděl dynamické typování, by s přechodem na PHP taky mohl mít problém, protože je najednou potřeba ošetřovat jiné věci.
-
uroboros (neregistrovaný)
Napsal jsem to vys a tys to jenom potvrdil. PHP je jednoznacne nejrozsirenejsi na webitka a pise v tom "kazdej", jenze jak si tady napsal, tak ty lidi nepremyslej. Jasne ze nepremyslej, vzdyt to prece funguje tak co je na tom spatne. Viz. vykladni skrin hruzy znama jako Wordpress. Ja chapu, ze pro obycejny smrtelniky je to prece super, ze si kliknou na tri tlacitka a maj web. Myslim, ze Io(s)T ukazalo a jeste ukaze jakej je to "provar" a u toho PHP to je stejny (coz se ukazuje relativne casto). Takze jasny, chces neco rychle zbastlit a vydelat si za minimum prace $$$, no a co ze z toho bude za par hodin, dni nebo tydnu botnet.... ze yo. A JS ani nepovazuju za jazyk .... proboha to snad nemuzes ani myslet vazne, vzdyt to nepozna ani rozdil mezi polem a objektem a vsechno je to pro nej string.
Abych tady nekopal jenom do PHP, tak z logickejch duvodu ma kazdej vetsi projekt problem s konzistenci, resp. QA. Jenze je rozdil v tom, ze nektery projekty delaj/pisou fundovany lidi, co premejslej nad tim co pisou a proc to tam pisou, no a nektery ty projekty proste pisou nejaky "samozvany odbornici", ktery nemaj tucha o tom, ze to bezi na nejakym systemu a ze ten system muze i neco delat a dokonce i neco o cem nemaj ani potuchy. Dalsi uskalim je ono QA a manazersky rozhodnuti (ahoj Volkswagen a klice napr.). Proste ne, kod sice mozna napises za 3 minuty, ale 3 hodiny ho musis testovat a premejslet jestlis ho napsal spravne (tuhle vetu neberte doslova). Jenze to je nakladny a zdlouhavy a neni to ekonomicky a je menzi profit ..... Jak jsem napsal vejs, jsem rad, ze je takovejch matlaku hodne a bude jich jeste vic, aspon je svanda.
-
NULL (neregistrovaný)
Nejsem si jistý, jestli je to, jak JS nakládá s objekty, poly a stringy problém JS, nebo toho, že nejsi schopný se na ten jazyk podívat mimo tvůj mentální blok jakéhosi asi jediného schématu kterému musí cokoliv odpovídat, jinak je to zmetek. Tobě evidentně dělají pružné a benevolentí jazyky problém. Jestli to nebude tím, že pokud to někdo přesně neřekne co máš dělat a jak, tak jsi bezradný . . . Tyto příspěvky ti taky někdo poradil a nebo je to tvé vlastní dílo?
Každopádně shodit si 2. odstavcem ten 1., to už chce zápal a umění.
-
Lael Ophir (neregistrovaný)
To jak "benevolentně" nakládá JS s objekty, pol[i] a stringy je příčinou dlouhé spousty problémů. Přitom jediným důvodem takového designu jazyka je to, že by v něm měli být schopní uplácat nějaký kus polofunkčního a chybami (způsobenými právě tím designem jazyka) prolezlého kódu i naprostí amatéři. Proč myslíte že přišly projekty jako TypeScript a Dart? Protože v MS a Googlu nejsou schopní pochopit "benevolentní" jazyk, nebo protože je ta benevolence kontraproduktivní?
-
NULL (neregistrovaný)
Já nemůžu za to, že M$ zaměstnává lamy a google indické lamy a nemůžou je nechat programovat v jazyku, který je neustále nevede za ručičku. A že se o M$ lamách může člověk přesvědčit každodenně
A teď vážně. Těžko říct, jaké přesně měl třeba google požadavky na jazyk a určitě si nemyslím, že prostě vezmeš jazyk a najednou ti sedne ve všem. To jsou naivné lamí sny. Projekty jako TypeScript a Dart vyšly hlavně proto, že jsou v podstatě API na generování kusů kódu JS a usnadňují psaní správné syntaxe - to vodění za ručičku - ale ano, zrychluje to, alel taky to má své mouchy a omezení - on to totiž není žádný boží zázrak, ale zase jenom výtvor člověka. V případě M$ to byl ještě zase naivní pokus o jakýsi nový proprietární zázrak, tedy to z jejich omezeného pohledu mohlo vypadat, že to má šanci.Možná by jsi se pro osvětu i z té druhé strany mohl podívat, co třeba takový mladý Steigervald píše o googlu a JS.
Víš, mušíš hlavně pochopit, že pro mě není utomaticky rovnítko mezi "je to velká firma" a "všechno dělají nejlépe", protože pár větších firem jsem zažil a s několika jsem dělal . . .
Ale pozor, nikdy jsem netvrdil že je JS nějaký zázrak bez chyb, to je zase jenom tvoje omezené M$ vidění světa jako černá a bíla - buď jedno a nebo druhé, nic mezi tím.Pak je taky otázka, jak vlatně jazyk hodnotit, jestli podle toho, zda sedne vývojářům v jedné firmě a zapadne do jejich schématu a nebo jestli to, že ten jazyk používá každý a může ho jednoduše použít každý a jednoduše dodá funkcionality které jinde neseženeš - a to JS dělá.
Jak ale tohle vlákno pokračuje, tak je evidnetní, že prostě nějaké skupině lidí prostě dělá problém jiný přístup než *xyz char[ ? ]; "==" vs "===" a implicitní přetypování. No a pak je hned plamen na střeše. Ok. Co ale nechápu je, že místo aby se tedy pohnuli k jinému jazyku musí kolem sebe plivat hovadiny - snad to není flame, případně se dotčeným omlouvám.
Jedna več je ale jistá. Tebe už znám a nemám zájem marnit čas vypisováním věcí které ani nečtěš, jen si vybereš co se ti hodí, začneš dělat Ad Ad Ad. Nemusíš se ani obtěžovat odpovídat.
Adieu
-
Lael Ophir (neregistrovaný)
Ad nemůžou je nechat programovat v jazyku, který je neustále nevede za ručičku - předpokládám že za vás by tedy bylo velmi praktické používat hypotetický jazyk, který neupozorní na žádnou chybu a vždy zdroják zpracuje, v případě nedodržení pravidel pak s nedefinovanými side effecty. Byl by to jazyk pro kovboje, které nikdo nemusí vodit za ručičku, a ideál pro každý projekt :D
Ad jak [vlastně] jazyk hodnotit - to je otázka do pranice. Na prvním místě bych se soustředil na problémy daného jazyka, na špatný návrh, protože to nutně znamená, že jazyk není dobrý. Mimochodem Jeff Atwood, zakladatel Stack Overflow, hodnotil PHP těmito slovy: PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Není to zdaleka jenom o opravdu úchylném ==, kde "foo" == TRUE, "foo" == 0, ale TRUE != 0 (WTF?). Je to o absenci jakékoliv konzistence jazyka, o spoustě nepříjemných překvapení a nečekaných vlastností. Konkrétní příšernosti návrhu PHP nemá smysl rozebírat tady, stačí se podívat na nějaký existující popis, vizte link.
Je pravda že novější verze PHP něco málo vyřešily, ale mnohdy za cenu breaking changes. Sorry, PHP je prostě od začátku zprasený jazyk navržený amatérem, a jestli jste se v tom minovém poli naučil chodit, tak dobře pro vás, ale dobrý jazyk to z PHP neudělá. Proti PHP je i VBScript, o kterém málokdo řekne cokoliv pozitivního, naprosto nádherný jazyk.
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/Ad Tebe už znám a nemám zájem marnit čas vypisováním věcí které ani [nečteš], jen si vybereš co se ti hodí, začneš dělat Ad Ad Ad - ano, známe se už nějakou dobu. Vaše příspěvky, stejně jako všechny ostatní na které odpovídám, samozřejmě čtu. Vzhledem k počtu překlepů a chyb nevím jestli je po sobě čtete vy :), ale to nechme stranou. "Ad" je praktický způsob jak citovat konkrétní část předchozího příspěvku a odpovědět na ni.
-
NULL (neregistrovaný)
@bez přezdívky
"Neni, cirou nahodou, JS made by MS?"
Ne, vznikl pro Netscape
https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript
-
uroboros (neregistrovaný)
[]+{}
{}+[]
...
muzes pokracovat, kreativite se meze nekladou, doporucuju si vzit kapesnicek na par slzicek, urcite ti smichy ukapnou.Pak mi rekni jak s necim takovym chces rozume pracovat?
A to nemluvim o tom, ze si odkudkoliv muzes pretizit/prepsat/pretypovat cokoliv, to je dalsi featurka toho jazyka .... ne je to proste wrong by design.
-
L. (neregistrovaný)
Když on je NULL nejspíš polobožský génius který i ty nejsložitější programy nabouchá na první dobrou bez jediné chyby. To je pak jasné, že nechápe, co nám na těch jazycích vadí.
Normální lidi ale v programech chyby dělají, ty chyby je třeba najít a opravit a čím dřív v procesu tvorby SW se najdou a opraví, tím lépe. A různé záludnosti v programovacích jazycích tomu rozhodně nepomáhají. Naopak, přísný jazyk umožní mnoho chyb odhalit už ve fázi psaní.
Mimochodem, dělám hodně v Javě, něco v Javascriptu a teď jsem psal menší projekt v Typescriptu. A jak Microsoft nesnáším tak musím říct, že tohle je druhá věc, která se mu povedla (ta první byly Age of Empires, mimochodem). Typesrcipt pomahá a přitom nepřekáží, tak to má být. Oproti psaní v čistém JS je to nebe a dudy.
-
uroboros (neregistrovaný)
Souhlas, cim je jazyk striktnejsi tim lip. Jako je fajn, kdyz se da obcas neco priohnout misto, aby se to obchazelo o tom zadna. Ja mam treba proto hrozne rad python, protoze to nemuze kazdej psat jak dobytek. Dalsi vec je taky takova "banalita" jako je deklarace promenych. Jako jasne, je super dynamicky typovani a deklarace atd. jenze jenom na to domaci bastleni. Ve velkym projektu to je spis zlo a hlavne kdyz pise ten kod hromada lidi co ma kazdej jiny navyky a 90% z nich nevi co je coding standard. Pak jsou z toho takovy krasny veci jako Wordpress, ten projekt neni spatnej jako takovej, jenom ten kod je hroznej bordel.
K tomu M$ s tema AoE souhlasim, Typescript jsem nevidel ani z vlaku, ale nasesti JS zacne pristi rok uz realne umirat, takze se toho snad uz nebudu muset ani dotknout (hura).
-
Lael Ophir (neregistrovaný)
Ad nasesti JS zacne pristi rok uz realne umirat, takze se toho snad uz nebudu muset ani dotknout - nevím jak se to projeví konkrétně u vás, ale v JS a PHP je namaštěno tolik kódu, že i kdyby zanikly zítra, bude ten kód používán ještě minimálně dekádu. Dobře je to vidět na COBOLu, který je sice dávno mrtvý, ale už dekády spokojeně žije svůj "posmrtný život" zalezlý prakticky ve všech větších organizacích v západním světě. Č(SS)R toho byla pravda ušetřena, ale jen protože jsme byli Východ.
-
NULL (neregistrovaný)
Jako v tomto máš asi pravdu. Jedna věc je, že pokud v PHP neděláš skopičiny jako třeba to nešťastné implicitní přetypování, kde ti to prostě zaokrouhlí na 16 des. míst a vyhneš se obloukem "==", ale poctivě ověřuješ, tak se v tom dá jednoduše tvořit. U PHP je ale spíše, a si i díky tomu, hodně široká základna frameworků, pluginů a knihoven a tím to celé žije. To samé je to s JS. I tem Typescript na něm stojí, je to prostě jenom compiler. Ale to se dá hlídat a dělat i Gruntem, LiveScriptem, Cofee scriptem . . . .atd . A to je to, co hýbe světem a drží tak dlouho a tolik lidíl. Nikdy jsem netvrdil že PHP a JS je něco světoborného, ale ukaž mi web nez JS, bez jQuery? Kolik jich je? (Nemyslím 1 stránkové prezentace, ale i tam často je). A tak jednoduše? Není ani v podstatě alternativa. Java žere kotel prostředků a taky má své mouchy, C# jsem měl ti čest a je to v podstatě to samo. Ale to je jedno, jde o to, že jenom WP weby, i kdyby zítra skončil tady budou ty dekády i dvě. Každopádně by jsi se divil, a to je vlastně celé proč jsem se tu teď do toho zamotal, že spousta webových firem ještě má weby php 5.3 (aktuální 5.7) a věřím že i tu dekádu mít budou - prostě weby jedou a složité migrace jim nikdo nezaplatí - pamatuješ ne, před 7-10 lety CI/CD dělaly jenom americké giganty (nadsázka) a dnes už je to v podstatě standart . . . . Navíc PHP, JS, MySql/ MAriaDB je pořád zdarma, na rozdíl od MSSQL, ISS atd. OpenJDK si nejsem tak moc jistý, ale před pár lety ještě nebyla nic moc (jestli se pletu tak pardon - však on mi za to někdo nadá :-) ) a co velice zbývalo?
-
Lael Ophir (neregistrovaný)
Ano, v PHP se dá jednoduše tvořit. Bohužel ta prvotní jednoduchost je výrazně převážená tím, že díky vlastnostem jazyka dochází k dlouhé řadě problémů, které se objevují i v kódu lidí, kteří se tvorbou aplikací v PHP zabývají dlouhé roky. Jak jsem uváděl a linkoval v samostatném threadu, je naprosto nemyslitelné, aby se string se čtyřmi vhodně zvolenými písmeny ("Null") rovnal null, což se rychle projeví když má někdo příjmení "Null".
Ano, weby v PHP tu ještě minimálně dekádu budou, a dost možná ještě déle. Je to podobně nešťastný problém jako s COBOLem, akorát výrazně horší. Ty projekty jsou od často začátku psané "kovbojským" způsobem (vizte link), jsou plné chyb a obtížně se udržují, jsou závislé na spoustě frameworků které časem přestanou být udržované, a jak správně píšete, ani migrace na novou verzi PHP není díky té spoustě breaking changes moc realistická. Ano, weby v PHP může psát každý amatér, ale díky návrhu jazyka (resp. absenci jakéhokoliv konzistentního návrhu) je kvalita projektů tristní jak u amatérů, tak u dlouholetých profesionálů. Projekty v PHP budou pro jejich zadavatele do budoucna velikým problémem.
http://www.zive.cz/clanky/rozhovor-nezkroceni-vyvojari-a-kovbojove/sc-3-a-162156/default.aspx -
NULL (neregistrovaný)
Promiň, ale jsou projekty a fw v PHP, které zprasené nejsou. To že všichni znají jen wordpress je prostě jen smutná realita. On ani ten wordpress zase není taková katastrofa, většina problémů je spíš spojena se zmatlanými pluginy 3tích stran a můžu tě ujistit, že se ty chyby většinou ani netýkají PHP, jako spíš neošetřených výpisů do šablon, zápisů do DB a lajdáckých užití JS. To je ale IMHO asi tím moderním přístupem, že nejprve se to napíše tak, aby to fungovalo a pak se s tím něco udělá, no a až to funguje, tak s tím už nikdo nechce marnit čas (tedy peníze) a při "refactoringu" se na půlku buď nedostane a nebo zapomene. Ale neboj se, největší prasárnu kterou jsem tento půlrok viděl by vyhrál hash hesla jak je v DB uložený cookie. A víš v čem to bylo? Byl to C#. Takže ten celý problém asi bude někde jinde než v návrhu jazyka. Já totiž PHP nijak extra nemiluji, ale za ty roky jsem se naučil a pochopil (už dávno) jak PHP s věcmi operuje a nemám s tím problém, protože jsem nezamrzl na Cčku a rozhodně nemám tolik drzosti ťápat kvůli systému implicitního přetypování něco o amatéreh a jejich jazyku. Každopádně odborníků a super jazyků už tu máme hodně, jenže v těch hrůzách nikdo nechce dělat, vývoj je drahý a výsledek není o nic lepší než v tom hrozném, zlém a strašném PHP. Vidím to každý druhý den. 100 lidí naťápe 100 věcí, ale nakonec když se mají pochlubit v čem dělají a co je ten jejich vybraný zázrak, tak je to jeden za 18 a za 20 bez 2. Co si ale budeme vykládat, v PHP, wordpresu, nette a dalších dělám protože si to lidi žádají a ne proto, jestli je to nejgeniálnější výkřik moderní doby. Samozřejmě se ale výběr jazyka řídí typem projektu . . .
Schválně, ty jsi takový Windowsák, ukaž mi zdarma IS na neomezenou velikost a počty jader a FW třeba v tom supr čupr cool C# který si nakopíruješ do webu a tvoje mamka může hned blogovat - no a tady to vidíš. Sice to máš všecko kůl a boží ale jaksi k hovnu . . .A ten link? To je teda dílo . . . Už jsem na to narazil, ale z podobných (ani nevím jak to nazvat) se mi chce zvracet. Ale buď klidný, za 2 roky zase bude ten zlý někdo jiný, přesně podle nejnovějších trendů . . . I když, je to pořád jednodušší než namáhat vlastní hlavu . . .
-
Lael Ophir (neregistrovaný)
Ad ale jsou projekty a fw v PHP, které zprasené nejsou - o tom nepochybuji
Ad tím moderním přístupem, že nejprve se to napíše tak, aby to fungovalo a pak se s tím něco udělá, no a až to funguje, tak s tím už nikdo nechce marnit čas - to je přesně ten kovbojský vývoj, který jsem vám linkoval. Bohužel to zatraceně často funguje přesně tak, jak ten článek popisuje. Webový vývoj má svoje "špecifiká". To je nakonec důvod, proč se na webové vývojáře ostatní vývojáři tak často koukají s despektem (ať už zaslouženým nebo nezaslouženým).
Ad největší prasárnu kterou jsem tento půlrok viděl by vyhrál hash hesla jak je v DB uložený cookie. A víš v čem to bylo? Byl to C# - jazyk sám o sobě od prasáren neuchrání. Ale je trochu nevhodné, když sám jazyk plný prasáren, nekonzistencí a nedomyšleností, protože to situaci jen komplikuje. O tom jsem už psal, a součástí postu byl link. Bohužel jste to nechal bez odpovědi. Zvlášť váš komentář těch vlastností PHP, které jsou zmíněné na tom blogu, by mě fakt zajímal. To není o nevodění za ručičku; je to prostě o špatném návrhu jazyka.
https://www.root.cz/clanky/phpmailer-ma-kritickou-chybu-ohrozuje-miliony-webu/nazory/901740/
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/Ad ukaž mi zdarma IS na neomezenou velikost a počty jader a FW třeba v tom supr čupr cool C# který si nakopíruješ do webu a tvoje mamka může hned blogovat - co je v daném kontextu IS a FW? Jinak na asp.net se pro blogování používá BlogEngine.NET, dasBlog, Subtext, AtomSite, Orchard (CMS) a další.
-
NULL (neregistrovaný)
Nikdy jsem nenapsal že vím všechno a všechno mi jde. Jestli jsem si z VŠ odnesl aspoň jednu věc kterou vím bezpečně, tak je to: Nikdo nikdy neví a neumí všechno. A taky jsem nahoře uznal, že jsem prostě nevěděl, že pro double je to 15-16 míst. Proš ne, já si na totálního vševěda a soudce, co je ten správný jazyk hrát nepotřebuju. Na rozdíl od někoho. Ale nevadí mi to. Díky flame na PHP a hlouposti příspěvku už jsem zase zjistil několik nových věcí. Takže + pro mě.
Ale opravdu nechápu, proč bych měl kňourat po diskuzích, protože PHP pracuje se stringy specifickým způsobem a to ještě nakonec podle IEEE, jestli se Vaše géinum obtěžovalo projít vlákno celé a už vůbec nehodlám někde naplákat proto, že v JS je všechno objekt.
Ještě jednu poznámku: PHP můžeš psát i bez záludností, prostě normálně ale nenech se mýlit, záludnosti z implicitního přetypování si můžeš natahat i v C, ale proti tomu si nedovolíš říct ani popel. A pokud to bourák tvého formátu neví, tak C používá pro typ double a počet desetiných míst stejnou mormu.
-
. . (neregistrovaný)
tam kde je masa nových programátorů, nedokážeš udržet vysokou úroveň. Pro ty lidi je php entry point a bohužel se někde musí naučit programovat, řada z nich poté skončí v pro ně lepších jazycích.
Mrkni co se děje v GO na githubu, občas se jedná také o hooodně odporný a nebezpečný kód, který lidi jsou schopni vyplodit a přitom GO nemůžeš považovat za špatně navržený jazyk.
To stejné platí o android aplikacích, mít možnost vidět jejich kód, zhrozíš se a utečeš hodně daleko, přitom java není zrovna ten špatně navržený jazyk.
Problém webu je, že je příliš exponovaný a moc na očích, stejné problémy jsou ale napříč celým IT světem přesně v místech, kam se dostávají lidé, kteří tomu nerozumí a zároveň v tom oboru jsou peníze. Stačí se podívat jak s tím zápasí tradiční výrobci domácí elektroniky, velice špatně, programování opět moc dobře nerozumí.
-
uroboros (neregistrovaný)
Ja to chapu a defakto s tebou souhlasim, jenze pak je "celej internet" jenom "sandbox" a muzes ho povazovat za cokoliv jenom ne za bezpecnej a duveryhodnej. Coz nerikam, ze je blbe, ale at pak neotravujou s nejakyma cenzurama a tim, ze se nekde neco sdili.
Problem nevidim v tom, ze se nekdo potrebuje neco naucit a nikdo ucenej z nebe nespadnul (co je mi znamo). Taky chapu, ze nektery projekty vznikaj na kolene na zacatku bez vetsiho zazemi. Tomu rozumim, nikdo neni dokonaly ani neomylny. Jenze kdyz se podivas na IT jako na celek tak vidis docela hodne problemu (asi, ja jich teda vidim opravdu hodne) a je problem s nedostatkem kvalitnich lidi. Jasny, takze casto to probiha tak, ze firma neco chce, chce to za nejlevnejc a chce to nejrychlejc, prej to prece udela nejakej student ne. No, a z toho tak nejako vznika hodne problemu at uz to jsou neudrzovany servery, switche, fw nebo vyprasenej kod. Je problem v programatorech/adminech? No castecne asi yo, jelikoz z ruznejch duvodu na to casto taky kaslou at uz vedome nebo nevedome.
Reseni? Hmm rict sefovi, ze chci jit na skoleni o tom a o tom a ze chci pul dne v tydnu mit cas na to se ucit. Jasne, at treba dostane mladej tri mesice trochu sodu, nebo at se z toho 1.5 mesice uci, testuje a skoli. Aha, na to nejsou penize? Hmm. No tak az ten skvelej sef bude potrebovat bypass, at leti do Afriky tak mu to nejakej student za par korun zbastli. Problem bilejch limecku je, ze nevedej a nechapou a nerozumej, pro ne jsou "pocitace" ty "ikonky" a ajtak to prece opravi. Vedi kulovy o tom co je system, programovani a ze to neni jenom klik a klik. Verim, ze si nejakej z nich mysli, ze gugl je prece jenom prazdna stranka z par tlacitkama a ze by to teda mel umet udelat kazdej za par hodin. Takovy lidi by se mely 10x servat do krupice, ze by si musely vymenit spodary i 3x denne. Ja se tesim, az budou roboti bezni a zacnou takovyhle blbce zabijet, protoze programator nemel cas to napsat spravne .... tam to povede a ja jsem za to rad. Ano je to kruty, ale vsechno si casem vybere svou dan, je treba se hluboce zamyslet a prehodnotit stavajici strategii vyvoje, testovani a udrzby.
At si kdo chce co chce rika, tak stav je vaznej rekl bych a rozhodne se to samo nezlepsi bez zmeny pristupu.
-
Konkrétní chybu v escapování lze samozřejmě udělat i v jiném jazyce. Prostě mi to nedalo, abych si nekopnul do PHP ;-) Ad struktura jazyka: například jedinečná (tedy jedinečně stupidní a především nekoherentní) typovací pravidla v PHP znamenají, že si člověk nikdy není jistý tím, co nějaká proměnná vlastně obsahuje. Můžete předpokládat integer, ale - aniž by se co řeklo - on to klidně může být například řetězec v důsledku typové chyby někde úplně jinde v programu (nebo třeba ve vstupních datech). A v takovém případě kód vesele poběží dál a bude produkovat naprosto nepředvídatelné výsledky. Nejen, že takové chyby nevyvolají automaticky vyjímku, ono to kolikrát v PHP spolehlivě ošetřit ani nejde. Když si k tomu přidáte takové horory, jako např. preg_replace(), k jehož používání PHP přímo vybízí, dáte mi snad za pravdu, že napsat program v PHP který by nebyl napadnutelný nějakou injekcí je přetěžký úkol.
Ad C, taky ho zrovna nemiluju ani ho nepovažuji za kdovíjak vynikající návrh, ale na jeho obhajobu lze říct to, že problémy, jako je špatné kódování řetězců a s tím související problémy se strcpy(), scanf() a jiné lahůdky vznikly přece jenom v jiné době, kdy bezpečnost byla jednak více méně v plenkách a jednak zdaleka nebyla takovým problémem, jako dneska a s tím, že K&R vlastně nikdy nepředpokládali, že by se C mělo stát obecně používaným jazykem. Naproti tomu PHP vzniko v době, kdy už bylo mnoho problémů známých a velmi akutních, a je určeno k programování webových aplikací, a tedy už z podstaty věci silně exponovaných.
-
> typovací pravidla v PHP znamenají, že si člověk nikdy není jistý tím, co nějaká proměnná vlastně obsahuje
Ano, toto je error-prone. Na druhou stranu, o Perlu jsem slyšel historku, jak vypsání hodnoty proměnné ovlivnilo další chod, protože se pak proměnná chápala jako jiný typ. Na to nemá ani PHP.
> ono to kolikrát v PHP spolehlivě ošetřit ani nejde
Ale jde. Namátkou === nebo typy parametrů nebo intval.
> dáte mi snad za pravdu, že napsat program v PHP který by nebyl napadnutelný nějakou injekcí je přetěžký úkol
Stačí použít vhodný framework ☺
> problémy se strcpy(), scanf() a jiné lahůdky vznikly přece jenom v jiné době, kdy bezpečnost byla jednak více méně v plenkách a jednak zdaleka nebyla takovým problémem, jako dneska a s tím, že K&R vlastně nikdy nepředpokládali, že by se C mělo stát obecně používaným jazykem
PHP z roku 1994 taky není čerstvá novinka. Když vzniklo, jmenovalo se to Personal Home Page a asi taky nikdo nepředpokládal, že někoho na tom napadne postavit třeba Facebook…
-
NULL (neregistrovaný)
" typovací pravidla v PHP znamenají, že si člověk nikdy není jistý tím, co nějaká proměnná vlastně obsahuje"
A to je přesně to o čem jsem psal. Ve striktně typových jazycích ti sice kompiler zařve pokud někam rveš co nemáš, ale pokud nechceš aby ti to při vykonávání padlo, stejně to musíš ověřit a případně přetypovat - klasika - parametry z url nebo nějaký uživatelský, které se ti předávají po celé aplikaci . . . . takže jsi tam kde s php . . . Ano, je pravdou že to můžeš udělat na 1 místě a pak ti to typová kontrola pohlídá, to ale neplatí při předávání mezi různými částmi aplikace jako třeba pluginy 3. stran . . . V PHP a jeho typové benevolenci zase můžeš vidět výhodu v tom, že se o to, co je v proměné staráš až tě to zajímá . . . třeba až v 10 volání funkce v řadě a nemusíš to ošetřovat hned na startu kam nemusíš mít ani logický neprasečí přístup a nebo pro předané netypované parametry - pokud se nesplní třeba 1. podmínka ani dalších 1000 hodnot v poli kontrolovat . . . To je jenom o tom, jak jsi zvyklý pracovat a případně jak rozmanitě jsi schopný nad kódem přemýšlet . . .
-
V tom nevidím žádnou výhodu. Pokud má striktní jazyk koherentní typový model (např. Hindley-Milner nebo něco odvozeného), pak mi buď zařve při kompilaci, nebo mám matematickou jistotu, že mi (kvůli typové chybě ve vstupu) program nespadne ani neprovede nic nepředvídaného. Neboli - jsem schopen poskytnout určitou garanci ohledně toho, jak bude program fungovat. Jistě to něco stojí, konkrétně delší vývoj, ale dle mého názoru se to bohatě vyplatí. Problém s pluginy není tak zlý, můžu například definovat typ "Sanitized String", který budou všechny pluginy používat, s tím, že takovou hodnotu lze získat výhradně jako výstup z nějaké sanitační fuknce.
Samozřejmě, že to v praxi má své meze, např. v Rustu všude tam, kde je nutné volat externí céčkovou knihovnu. Taková místa jsou aspoň izolovaná a pokud se má za to, že jsou jednotlivě implementována správně, pak program jako celek je prokazatelně správný. Ve srovnání s PHP, kde je potenciálně napadnutelný i řádek "$a = $b + $c;", je to nebe a dudy.
-
Silné/statické typování ma výhodu spíše v podpoře IDE, statické analýzy apod. Pokud jde o matematickou jistotu, ta je typicky hodně drahá (formální verifikace, typicky řadově mimo rozpočet) nebo hodně slabá (statické typování, velkou část těchto chyb by odhalily i testy).
Tím neříkám, že silný nebo statický typový systém (nejlépe obojí) nemá svůj význam. Má, jen od něj nečekám něco, co nesplní.
BTW, v PHP taky mohu mít (třídu) SanitizedString. Mohu jí i vynutit v typu parametru.
-
NULL (neregistrovaný)
Potenciální nebezpečí je každý neošetřený vstup, u webovek speciálně string nebo sekvence znaků - záleží na jazyku. Co se ti snažím vysvětlit je, že každý vstup stejně musíš ošetřit - typ, znaky třeba atd . . . - a nezáleží na jazyku . . . protože pokud do něčeho přiřadíš něco co tam nemá být, tak ti to bordel udělá nakonec vždy - amatérům 500stovku, schopným se jenom něco nevypíše nebo neprovede a je jedno v jakém jazyku děláš (mluvíme o webu předpokládám), prostě nechceš na výstupu do browseru vidět něco jako alert("It works") (samozřejmě celé :-) ) ani na vstupu něco jako "... UNION 1, 2, 3 . . . .atd" a je jedno jakou typovou kontrolu tam máš . . . . A když se do integeru pokusíš přířadit string a pak s tím sčítat, tak máš problém v každém jazyku, akorát se v každém projeví jinak a na jiném místě . . .
K tomu příkladu: "$a = $b + $c"Ano, ale když děláš v php a myslíš to vážně, tak je ošetřit "$a = $b + $c" úplně ta samá banalita, jako třeba v Javě "1" nejprve přetypovat když to rveš do int mojeCislo případně do parametru nějaké funkce . . .
PHP je na práci se stringy dost benevolentní - průser nastává ve chvíli, kdy to nevíš nebo nerespektuješ, případně v tom chceš psát jako v nějakém jiném jazyku - ale to je problém vždycky
-
Jenda (neregistrovaný)
> Co se ti snažím vysvětlit je, že každý vstup stejně musíš ošetřit - typ, znaky třeba atd . . . - a nezáleží na jazyku . . . protože pokud do něčeho přiřadíš něco co tam nemá být, tak ti to bordel udělá nakonec vždy
Není lepší, aby se o to obecně staral systém sám? U databáze samozřejmě prepared statements, na výstupu šablonovací systém atd.
-
NULL (neregistrovaný)
Databázi jsem schválně nezmiňoval, záleží co použiješ, jestli nějaké nativní dotazy z užitého jazaka nebo nějaký fw nebo něco z fw . . . Když už se tak ptáš, tak ti dím ještě i tip: Nestačí jenom prepared statements, ale taky musíš mít správně nastavený character a collate
Ale kde si myslíš, že se vezme ten "na výstupu šablonovací systém atd."? To je právě ono. Jeden jazyk to kontroluje tak a tam, jiný zase tu a támhle a frameworky to mají zpracované v těch šablonovacích systémech nějakým jazykem a zase jsi u toho - jediná důležitá věc je, že to musíš vědět a tak k tomu i přistupovat. Pokud ale začneš k PHP třeba přistupovat jako k Javě třeba, no tak se pak nediv, že ti zbude akorát kňourat po diskuzích . . .
-
. . (neregistrovaný)
nejenže musíš ošetřovat vstupy, musíš ošetřovat i výstup podle použitím, univerzální SanitizedString neexistuje a v typovém systému nezabráním logickým chybám, kdy text ošetřím pro html, ale pošlu ho do shellu.
V čístém PHP se kvůli jeho neduhám nepíše a masivně se používají frameworky, které ale jeho neduhy řeší často velice efektivně a vývoj není drahý.
-
declare(strict_types=1) (neregistrovaný)
Klokane, nevím, jestli jste se zasekl u PHP4, ale tento svět se už trochu posunul. Kromě bláznů, kteří ještě lepí webíky ve Wordpressu už dnes všichni staví na robustních frameworcích a dobře otestovaných knihovnách. A že je z čeho vybírat!
Co se týče typů, v PHP7 se dají vynucovat i návratové typy funkcí, což docela pomáhá.
Kdo není lempl a nepoužívá zastaralé postupy, nemůže chybu udělat tak snadno. Spoustu frameworků si, světe div se, dokáže bezpečnost pohlídat, vstupy ošetřit, oescapovat. Navíc máme i testy, slyšel jste o nich?
Nic není dokonalé, a určitě nepoužiju PHP na finanční transakce v bance. Víme? O tom to je. Takže vy si napište web třeba v Adě, v Rustu, nebo jánevímvčem. Bude to fajn, i když asi jen pro Vás. A pak mi řekněte, kdo si web za ty náklady zaplatil, kdo ho bude udržovat, nasazovat. A popovídejte mi pak o tom, jak Vám při složitějších problémech pomohla komunita, open-source nástroje, balíčky, knihovny. A nebo mi napište, jak je vlastně celej world-wide-web naho*no a že chcete zpátky BBSky a telnety.Nechápu, proč se v diskuzích objevují lidi jako vy a zasírají ji úplným offtopicem. Koukal jste se na tu chybu? Přijde Vám, že to je problém v datovým typu? Proč pokaždé, když se objeví někde článek o PHP, v diskuzi se vyrojí experti na kvalitu návrhu jazyka a na všechno možný? Nebylo by lepší vylejt si srdíčko raději přímo autorům PHP? Nebo to udělat líp? Nebo se na tyhle žvásty vykašlat a místo hejtování dělat něco prospěšnějšího? Bude to dobře i pro ostatní, kteří v diskuzi nebudou muset filtrovat příspěvky jako jsou ty Vaše.
-
Lol Phirae (neregistrovaný)
Nebylo by lepší vylejt si srdíčko raději přímo autorům PHP
Ne, protože mají v hlavách nasráno již drahně let. Jeden z nesčetných dalších příkladů:
- https://bugs.php.net/bug.php?id=54547
- https://bugs.php.net/bug.php?id=62097 -
NULL (neregistrovaný)
Rozhodně nechci být drzý, ale RTFM:
http://php.net/manual/en/language.types.float.php
"Additionally, rational numbers that are exactly representable as floating point numbers in base 10, like 0.1 or 0.7, do not have an exact representation as floating point numbers in base 2, which is used internally, no matter the size of the mantissa. Hence, they cannot be converted into their internal binary counterparts without a small loss of precision. This can lead to confusing results: for example, floor((0.1+0.7)*10) will usually return 7 instead of the expected 8, since the internal representation will be something like 7.9999999999999991118....
So never trust floating number results to the last digit, and do not compare floating point numbers directly for equality. If higher precision is necessary, the arbitrary precision math functions and gmp functions are available.jinak je to podle IEEE tímto Double - 64 bit (15-16 digits) ale v tom co jsi linkoval dal chlapík 19 a tak se to zaokrouhlilo.na
float(9.2233720368548E+18)
float(9.2233720368548E+18)Pokud použiješ jen přetypování a nebudeš to rvát do double
$a = "9223372036854775807";
$b = "9223372036854775808";
var_dump($a, $b, $a == $b, $a === $b);výsledek bude
string '9223372036854775807' (length=19)
string '9223372036854775808' (length=19)
boolean false
boolean falsecož je správně. Asi jsem ti zkazil pointu.
na int
$a = (int)"5523372036854775807";
$b = (int)"5523372036854775808";
var_dump($a, $b, $a == $b, $a === $b);result
int 5523372036854775807
int 5523372036854775808
boolean false
boolean falsecož je taky správně.
Uznávám ale, že na toto chování jsem osobně ještě nenarazil, asi je to tím, že si i když něco typuju, tak si hlídám, co mi z toho leze a garantuji ti, že toto chování mě nepřekvapí - na rozdíl od jiných věcí ;-) jak se občas stává prostě :-) Chápu pisatelovo rozčarování, tohle nepatří k základům, ani k pokročilým znalostem, ale k seniorním . . .
-
Hele, pěkně jsi vysvětlil že floating-point čísla se zaokrouhlují, ale pořád sis ještě nepřečetl pořádně ten bugreport (a nebo se nás pokoušíš oblbnout). To přetypování se totiž provádělo automaticky *vždy* při použití operátoru == a vývojáři veřejně uvažovali nad tím, že '9223372036854775807'=='9223372036854775808' je korektní chování
To že ti to nyní již funguje dobře (resp. rozumně) není tím že bys "zkazil pointu", ale tím že nakonec vývojáři uznali že to bug JE a opravili ho. A z toho patche (tedy minimálně toho prvního) je vidět v čem t oprava spočívá: že se detekuje případ kdy se ani jeno parsované číslo nevejde do integer a double hodnoty jsou shodné. Pak totiž platí že došlo k zaokrouhlování, jelikož int má víc platných číslic než double (tedy, na většině platforem, ale tím si tento pěkný fix nebudeme kazit).
Chápu pisatelovo rozčarování, tohle nepatří k základům, ani k pokročilým znalostem, ale k seniorním . . .
Ano, seniorní PHP programátor ví velmi dobře, že existují dva porovnávací operátory (== a ===) a musí si dávat setsakra pozor na to, který se použije.Pointa je ve skutečnosti v tom, že prostě PHP je jazyk ve kterém jsou pro psaní programů spolehlivě pracujících s daty nutné seniorní znalosti. Ti neseniorní (že by ty slavné lopaty?) holt musí psát maximálně weby, i kterých se nějaké to škytnutí toleruje.
A ano, je pravdou že to prostě specifická věc s PHP se kterou se musí počítat. Není pravdou že by na tom podobně byly všechny jazyky, protože většina nejrozšířenějších jazyků byla navržena jako univerzální.
-
NULL (neregistrovaný)
! Hele neber to všechno osobně, tak to nemyslím . . .
"...To přetypování se totiž provádělo automaticky *vždy* při použití operátoru == a vývojáři veřejně uvažovali nad tím, že '9223372036854775807'=='9223372036854775808' je korektní chování"
No jasně že se provádí vždy (PHP) pokud string začíná číslem. Ale asi ti nedošlo, že pokud takto porovnáš přetypovaný string na typ double nebo fload a díky IEEE to dopadne jak dopadlo, tak by to stejně mělo fungovat i pro stringy, protože tam to akorát přetypovává implicitně ( při "==" ), jenomže by tím brutálně zasáhli do zpětné kompatibility i pro ostatní případy . . . . Co je na tom k nepochopení nevím . . . Prostě
možnosti + kompromis . . Něco vybrat musíš"To že ti to nyní již funguje dobře (resp. rozumně) není tím že bys "zkazil pointu","
1. Měli 2 možnosti a jednu vybrali - žaluj je u velitele vesmíru . . .
2. By konečně někdo mohl linknout jazyk na milionu webů bez bugů . . . Asi ne, co?"Pointa je ve skutečnosti v tom, že prostě PHP je jazyk ve kterém jsou pro psaní programů spolehlivě pracujících s daty nutné seniorní znalosti. Ti neseniorní (že by ty slavné lopaty?) holt musí psát maximálně weby,"
Ano, promiň mi za tu přímost ale jinak mi to z huby neleze - PHP prostě není pro lamy, kteří si o tom nic nezjistí, vesele implicitně přetypovávají aniž by se třeba na mezním případu ujistii, přistupují k tomu jako Javě nebo C a pak si kam píšou tam uplivnou a vylévají srdíčko . . . To je právě zdrádnost toho, když někdo nezkušený přileze k benevolentnímu jazyku - ale to už se opakuji.
Nevím ovšem, jestli je chyba PHP, že je jednoduché v tom začít matlat pro každého a pak je z toho tohle (ta diskuze, ne nahlášení bugu). Uznávám že je to bug, no a co? Nějak ho vyřešili - ještě jsi nikdy bug a nějaký kompromis k němu neviděl? Hurá - tady jeden máš . . . Nebo co? Mají zavřít krám a všechno smazat aby jsi byl spokojený? To by jsi chtěl? A který jazyk s bugem se bude mazat jako další až nebude PHP a nějaký jiný se stane tím nejzlejším?"Není pravdou že by na tom podobně byly všechny jazyky, protože většina nejrozšířenějších jazyků byla navržena jako univerzální."
Možná je PHP pro někeré mistry oboru univerzální až moc . . . ;-)
-
notojo (neregistrovaný)
clanek hned vedle : Tři kritické 0-day chyby v PHP 7 ... Jde opět o „unserialized mechanism“, který byl před lety zneužíván už v PHP 5. Jedna z chyb přitom stále zůstává nezáplatovaná.
https://www.root.cz/zpravicky/tri-kriticke-0-day-chyby-v-php-7/
-
Pajk (neregistrovaný)
Co říkáte na tento námět na omezení dopadu (mitigation): Když jde o problém injektáže "nepořádku" přes pátý parametr funkce mail, tak proč nepoužít php.ini direktivu mail.force_extra_parameters s hodnotou třeba -fapache@hostname (samořejmě dosadit apache runtime usera a server hostname). Tím pádem žádný pátý parametr z aplikace nepřijde a prakticky to stále bude fungovat (dostatečně dobře) ...
-
Pajk (neregistrovaný)
No podle mého názoru phpmailer a cokoliv jiného v režimu použití funkce mail pošle něco do pátého parametru a php to prostě bude ignorovat a dosadí si hodnotu (bezpečnou) z konfiguráku ... Ano, mail nemůže mít envelope adresu z aplikace, bude mít pouze From: v hlavičce dopisu, ale podle mého názoru je to minimálně "good enough".
-
Pajk (neregistrovaný)
Ale pokud mám nastaveno v class.phpmailer.php
public $Mailer = 'mail';
(což je zřejmě default) a navíc mám v php.ini zakázané funkce jako system/exec/proc_open/popen, tak (imho) posílám pomocí fce mail a třeba nedávné CVE-2016-9920 řeší podobný problém pro Roundcube a zmiňuje se, že problém je právě injektáž v tom zpracování pátého parametru funkce mail, kdy sendmail není volán z php aplikace, ale ze samotného vnitřku php - https://blog.ripstech.com/2016/roundcube-command-execution-via-email/ . A je jasné, že phpmailer dokáže odesílat maily bez nastaveného smtp a se zakázaným popen, tj. pomocí mail ... Takže si myslím, že můj návrh může pomoci při tom defaultním použití funkce mail.
-
Aha, teď jsem prozkoumal zdroják PHPMaileru lépe a vypadá to, že někdy se skutečně používá funkce mail a injekce by šla do jejího pátého parametru. Tzn. útok by nemusel jít výhradně přes PHPMailer používající sendmail (popř. qmail), ale i přes PHPMailer používající funkci mail. Sice podle oficiální dokumentace by to mělo skrze escapeshellcmd zabránit přímému shell injection, ale mělo by to jít oklikou.
Potom by mělo jít o použitelný způsob mitigace útoku této zranitelnosti, pokud se používá funkce mail. Pokud ne, pak to nepomůže.
Ale:
1. Jak jsem tu postoval, oprava byla nekompletní. Zatím nedovedu říct, jestli i tu druhá část opravy lze nahradit tímto workaroundem.
2. Způsob odesílání se rozhodně nenastavuje v class.phpmailer.php! Tam je uvedena pouze defaultní hodnota, kterou lze přepsat za běhu, například metodou isSendmail(). V souboru class.phpmailer.php by se ale nic měnit nemělo. -
Pajk (neregistrovaný)
Nejsem programátor web aplikací, jsem administrátor serverů. Takže z mého pohledu vynucené přebití zranitelného pátého parametru je "good enough" mitigace v situaci, kdy blokuju použití popen a spol. (tj. přímé volání sendmail a jiných execů není možné) a tedy zbývá mail (doufám, že opravený přebitím) nebo smtp (které by mělo být v pohodě samo od sebe). Že by se sendmail někdy nějak použil k přípravě materiálu pro fci mail, to jsem ve zdrojáku phpmaileru nevyčetl ...
-
Pajk (neregistrovaný)
Samozřejmě souhlasím s tím, že správné řešení je update. Ale podle dostupných informací to vypadá, že problém by mohly mít i jiné podobné mailovací nástroje založené na volání php funkce mail (viz. časově předcházející publikovaný problém Roundcube) a tedy mnou navržená mitigace je pro mne preventivním řešením, které jsem nasadil. Rád si přečtu kvalifikovanější rozbor nebo vyvrácení mého názoru ...
Ohledně rozbití - jsem v pozici, kdy vidím, že maily odcházejí, v mail klientech vypadají správně (From:), envelope from a received headers mé zákazníky snad "netankují", ip adresa pro spf v envelope je nedotčena, takže "u mne dobrý", aspoň teda zatím. -
> mnou navržená mitigace je pro mne preventivním řešením, které jsem nasadil.
Souhlas. Původně se mi to nezdálo (myslel jsem, že s funkcí mail to nijak nesouvisí, navíc nápad nastavit tam natvrdo from zněl jako snaha ovlivnit PHPMailer, což by nešlo), ale teď to beru jako dobrý napad.
Ad rozbití – OK, ale obecně vzato: to záleží.
-
Lael Ophir (neregistrovaný)
Čtu tady spoustu obhajoby "dynamických" a "benevolentních" jazyků typu PHP a JS. Těm kdo je obhajují bych doporučil jít vysvětlovat lidem jako Jenifer Null a Christopher Null, že je skvělý nápad, když se string se čtyřmi "správně" zvolenými znaky rovná Null, a že tohle diletantství rozhodně není příčinou toho že spousta webů (které člověk v US potřebuje ke komunikaci s úřady, bankami a pojišťovnami) má problém s jejich jmény. Tenhle "benevolentní" přístup PHP a JS má umožnit psaní kódu i amatérům, ale ve skutečnosti věci komplikuje natolik, že v nich chybují i lidé, kteří se tvorbou webových aplikací léta zabývají.
http://www.bbc.com/future/story/20160325-the-names-that-break-computer-systems
https://www.wired.com/2015/11/null/
ČLÁNKY DO MAILU