PHP hádanka: chýbajúce dáta v $_POST

5.4.2023 14:30 | Přečteno: 1012× | programovanie | poslední úprava: 6.4.2023 07:35

V dnešnej hádanke sa pozrieme na jednu vlastnosť spracovania POST v jazyku PHP.

Majme HTML formulár s niekoľkými inputmi:

<form action="/uloz.php" method="post" enctype="multipart/form-data">
  Správa: <textarea name="sprava"></textarea><br />
  Príloha: <input type="file" name="subor" /><br />
  <input type="hidden" name="vec_id" value="1234" />
  <input type="submit" value="Odoslať" />
</form>

Formulár sa metódou POST odosiela na server, kde ho PHP skript bez veľkých zmien uloží do databázy:

<?php
$zaznam_id=uloz_zaznam(array(
  "vec_id"=>(int)$_POST["vec_id"],
  "sprava"=>$_POST["sprava"],
));
uloz_prilohu($zaznam_id,$_FILES["subor"]);

Napriek tomu, že vec_id vo formulári je vždy predvyplnené správnym a validným číslom a používateľ ho nemá ako zmeniť, občas uloženie záznamu neprebehne:

INSERT INTO zaznamy (vec_id,sprava) VALUES (0,'Hotovo');
ERROR: insert or update on table "zaznamy" violates foreign key constraint "zaznamy_vec_id_fkey"
DETAIL: Key (vec_id)=(0) is not present in table "veci".

Udeje sa teda to, že hodnota poľa vec_id niekde po ceste zmizne a formulár sa neuloží.

Kto prvý príde na to, čo sa tam naozaj deje? Nám to trvalo len desať rokov...

 

 

 

Update 6.4.2023 - doplnené hinty a riešenie:

 

 

 

Hint č.1

Keď si na začiatku toho PHP skriptu nechám zalogovať $_POST, niekedy tam je len toto:

array(1) {
  ["sprava"]=>
  string(5) "blaaa"
}

(tzn. vec_id sa tam vôbec nenachádza)

 

 

 

Hint č.2

Ak nechám zalogovať aj $_FILES, v prípade chyby je tam vždy toto:

array(1) {
  ["subor"]=>
  array(6) {
    ["name"]=>
    string(11) "priloha.pdf"
    ["full_path"]=>
    string(11) "priloha.pdf"
    ["type"]=>
    string(0) ""
    ["tmp_name"]=>
    string(0) ""
    ["error"]=>
    int(3)
    ["size"]=>
    int(0)
  }
}

Dokumentácia k chybe uploadu číslo 3

 

 

 

Riešenie

Stane sa to, že sa upload preruší a PHP sa spustí nad nekompletnými dátami. Keďže parameter sprava ide ako prvý, ten prejde. Druhý parameter je upload súboru - ten je obvykle dlhší a dáva najviac priestoru na to, aby počas jeho prenosu došlo k ukončeniu spojenia. A skrytý parameter, ktorý má súbor zviazať s konkrétnym id v tabuľke (vec_id), sa pri prerušení spojenia už jednoducho neodošle.

Ako sa preruší spojenie?

Veľmi jednoducho - používateľ počas odosielania klikne niekam inam, prehliadač odosielanie zastaví a začne novú požiadavku. Alebo - a to je extra chrumkavé - nedočkavý používateľ znova klikne na tlačidlo "Odoslať". Tým sa prebiehajúci upload zastaví a začne odznova. To vysvetľuje, prečo sa pri skúmaní bugu zdalo, že uloženie prebehlo úspešne napriek chybe v logu. Uloženie naozaj prebehlo úspešne, ale na druhý pokus.

Čo proti tomu nepomáha?

• Volanie connection_aborted(), connection_status(), ani ignore_user_abort(): všetky tieto tri funkcie pracujú s prerušením požiadavky až potom, čo server začne odosielať odpoveď. Ak k prerušeniu dôjde ešte počas príjmu požiadavky, žiadna z týchto funkcií neindikuje žiadnu chybu.

Ako proti tomu bojovať?

• dať dôležité informácie týkajúce sa požiadavky na začiatok formulára - keby skryté pole vec_id bolo na začiatku, dáta by sa uložili, aj keď bez súboru
• dať ako poslednú položku formulára skryté pole a kontrolovať jeho prítomnosť v PHP:

  <form ...>
    ...
    <input type="hidden" name="naozaj_vsetko" value="1" />
  </form>

  <?php
  if (!array_key_exists("naozaj_vsetko",$_POST)) {
    http_response_code(400);
    // nema ani zmysel posielat chybovu stranku, klient sa uz zo spojenia odpojil
    die();
  }

• nepoužívať <input type="file" ... />, ale radšej nejakú javascriptovú knižnicu, ktorá upload spraví na pozadí metódou PUT

Víťaz

Nakoniec sa k riešeniu najbližšie dostal mirec (tu). Budem ho kontaktovať ohľadom vecnej ceny.

       

Komentáře

[Jdhdbf]

Race condition. Mate pouzivat autoincrement.

[AraxoN]

Nie, toto nesúvisí ani s autoincrementom, ani s race condition. Vec_id odkazuje na existujúci záznam v inej tabuľke. Vo formulári (v prehliadači) je v momente odoslania správna hodnota. Ale PHP na serveri túto hodnotu v malom percente prípadov neuvidí.

[Petr]

Pak nam asi nerikas vsechno. Mas spatny data v databazi? Protoze si nedokazu predstavit ze to jednou za cas nezafunguje pokud se to na server posila spravne a nejedna se o race condition.

[AraxoN]

Toto nie je poradňa, ale blog. Chyba už bola nájdená, ale je to taký pekný špek v PHP, že som o tom musel napísať blog. Budem tu postupne dávať viac hintov, ale s databázou to vonkoncom nesúvisí. Databáza je len tá časť systému, ktorá hlásila chybu, čo aj nás dlho vodilo za nos.

[Petr]

Posli db schema. Mozna int vs kdovijaky typ mas v db. Pak by to zlobilo pro cisla co se nevlezou do intu.

[AraxoN]

Tu to je, ale opakujem, že chyba nie je v SQL ani v databáze.

CREATE TABLE veci (
  id SERIAL NOT NULL,
  nazov VARCHAR NOT NULL,
  ...
  PRIMARY KEY (id)
);
INSERT INTO veci (id, nazov) VALUES (1234, 'Divná chyba');

CREATE TABLE zaznamy (
  id SERIAL NOT NULL,
  vec_id INT NOT NULL REFERENCES veci (id) ON UPDATE CASCADE ON DELETE CASCADE,
  sprava TEXT NOT NULL,
  ...
  PRIMARY KEY (id)
);
CREATE INDEX zaznamy_vec_id ON zaznamy (vec_id);

CREATE TABLE zaznam_prilohy (
  id SERIAL NOT NULL,
  zaznam_id INT NOT NULL REFERENCES zaznamy (id) ON UPDATE CASCADE ON DELETE RESTRICT,
  nazov VARCHAR NOT NULL,
  cesta VARCHAR NOT NULL,
  ...
  PRIMARY KEY (id)
);
CREATE INDEX zaznam_prilohy_zaznam_id ON zaznam_prilohy (zaznam_id);

[Ragzid]

Pokud je vec_id=0, tak to (predevsim u autoincrementu) ulozi realne jinou hodnotu.

Jinak je tu prilis malo informaci, priklad je tak genericky, ze muzeme pouze hadat.

[AraxoN]

vec_id=0 posiela do databázy ten PHP skript

mal by ale posielať vec_id=1234, tak ako to je vo formulári, z ktorého čerpá dáta

[Ragzid]

Aha, takze popis problemu by mel byt: Proc se v $_POST["vec_id"] vraci prazdno, coz se pretypuje diky (int) na nulu?

Nicmene netusim, podeziram spis skript, co generuje HTML, ze uz tam ulozi spatnou hodnotu. Pripadne se tam deji s _POST jeste jine operace, o kterych my ctenari nevime.

[Hsjdhd]

Dalsi moznost by byla ze to uzivatel zmeni (f12, proxy, ...) aby mel op nad cim premyslet. Ale jo, tech duvpdu muze byt celkem dost, od velikosti post requestu, nejaky obskurni nastaveni v php.ini atd.

[Petr]

Tak nejak. Tech moznosti muze byt hromada. Jen google vraci asi 5 zakladnich duvodu pro tohle chovani. Pockame az op sesedne z kone povysenosti "vim vic nez vy vsichni" a doda nejaky relevantni info.

[J]

+100

[mirec]

Škoda, že neviem čo obsahuje $_POST["vec_id"], takže neviem, či obsahuje garbage, je truncted, alebo nie je vôbec.

Možnosti, ktoré ma napadli:

• PHP má rozbite parsovanie boundary (skôr nepravdepodobné keď je to označené ako vlastnosť, nie bug)
• Nejaká exotická vlastnoť "Variables From External Sources"

[kvr]

Není tam nějaké přesměrování (třeba authentication), které pošle link znovu, ale už bez dat?

[AraxoN]

Nie, presmerovanie tam nie je. Ani žiadna proxy. Ani mod_rewrite.

[kralyk z abclinuxu]

Napriek tomu, že vec_id vo formulári je vždy predvyplnené správnym a validným číslom a používateľ ho nemá ako zmeniť

Jak nemá ako zmeniť? Tu hodnotu může v prohlížeči upravit (nebo poslat request jinak). Neposílá vám tam nějakej bot nějaký hovadiny?

[AraxoN]

Dobre, používateľ môže meniť <input type="hidden"> s pomocou developerských nástrojov v prehliadači, ale v tomto prípade ide o BFU a nerobí to. Tým to nie je.

[bigfood]

Nesouvisí to náhodou s tím souborem? Že je třeba větší, než dovoluje post_max_size?

[AraxoN]

Toto chovanie nemá na svedomí post_max_size, upload_max_filesize, ani max_input_time.

Takže prekročením týchto parametrov to nie je, ani prekročením iných konfiguračných hodnôt z php.ini. Ale si na dobrej ceste v tom, že to súvisí s tým uploadom súboru.

[R]

Niekto tam jebne velky subor a obmedzenie na post_max_size oreze data tak, ze vec_id zmizne.

[Gjhgg]

To je jedna z prvnich veci co vyhledavac vrati, to by nezabralo 10 let. Krom toho to vypada ze druha post value je neobrezana, coz by byla haluz se zrovna tak trefit.

[AraxoN]

Tak, ono to tomu istému človeku s tým istým súborom na tom istom hardvéri o chvíľu už ide.

V logu vidím, že niečo neprešlo, idem sa teda pozrieť do databázy a tam vidím, že sa mu to už podarilo uložiť. Keď nemám lepšiu prácu, tak sa v tom trochu vrtám, na nič neprídem, lebo mne to zakaždým ide, takže to zase nechám tak.

Takto ubehnú roky - nakoniec to vždy ide, príčina ostáva neznáma. Kód je priamočiary, chyba v ňom nie je. Zvíťazia aktuálnejšie problémy, ktoré musí developer riešiť.

[AraxoN]

Prihorieva. Naozaj vec_id je na konci odosielaných dát a z hodnôt proste zmizne. Ale nie je to prekročením post_max_size.

Keď si na začiatku toho PHP skriptu nechám zalogovať $_POST, niekedy tam je len toto:

array(1) {
  ["sprava"]=>
  string(5) "blaaa"
}

(tzn. vec_id sa tam vôbec nenachádza)

[mirec]

Sekne všetko za uploadom pri chunked encodingu?

[AraxoN]

Nie, tým to nie je.

[AraxoN]

K riešeniu nás nakoniec doviedlo zalogovanie premennej $_FILES, čo nikoho za 10 rokov nenapadlo.

V prípade chyby je obsah $_FILES zakaždým zhruba takýto:

array(1) {
  ["subor"]=>
  array(6) {
    ["name"]=>
    string(11) "priloha.pdf"
    ["full_path"]=>
    string(11) "priloha.pdf"
    ["type"]=>
    string(0) ""
    ["tmp_name"]=>
    string(0) ""
    ["error"]=>
    int(3)
    ["size"]=>
    int(0)
  }
}

Odtiaľ už len treba dohľadať, čo znamená chyba číslo 3 a začne sa rozvidnievať...

[m]

"Kód je priamočiary, chyba v ňom nie je". Tak ocividne jo, kdyz tam chybi kontrola jestli upload probehl vpohode.

[J]

Ale prosim te, bastlici a lepici v php na nejake kontroly zvysoka sekaslou…

[kralyk z abclinuxu]

Přeplněné /tmp?

Každopádně, ať už je ta chybá způsobená čímkoli, ten kód bych vyhodnotil jako nesprávný - neošetřuje chyby.

[kvr]

Já bych spíš jako nesprávný hodnotil ten server předtím. Neúplný request by vůbec neměl Php předat. Divné taky je, že zmizí jenom jedna hodnota - čekal bych, že půjdou všechny pohromadě v rámci jednoho www-form-urlencoded (nebo jak se to nazývá).

Přiznám se, že teď nevím, jak by reagovala Java - podezřívám, že pokud půjde o InputStream, tak se request možná začne zpracovávat hned a až čtení z InputStream nejspíš hodí IOException. Nebo jej možná korektně nepředá vůbec...

[mirec]

Tá hodnota chýba pretože je v requeste za súborom, takže pri postupnom čítaní sa už na ďalší argument nedostane. V tomto prípade by request nemal byť spracovaný vôbec.

[AraxoN]

Bingo! V jazyku PHP nie je kontrola, či prišiel celý POST request predtým, než sa začne vykonávať. Otázka je, či je to vôbec chyba a či to iné "webové" technológie majú inak.

[kralyk z abclinuxu]

Bingo! V jazyku PHP nie je kontrola, či prišiel celý POST request predtým, než sa začne vykonávať. Otázka je, či je to vôbec chyba a či to iné "webové" technológie majú inak.

V zásadě to chyba není, ale jak říkám, tam je úplně špatně to API nad tím, kde data requestu taháš z nějakého globálního pole a musíš se dívat do nějakého jiného globálního pole, jestli tam náhodou není chyba... To je úplně blbě, správně by měl existovat nějaký objekt/struktura/whatever representující request a ten by měl zpřístupňovat různé vlastnosti, jako např. jestli request doběhl celý / nebyl přerušen a form data by zpřístupnil pouze, pokud je všechno v pořádku.

IMO tvoje řešení v odstavci Ako proti tomu bojovať? je jenom takový hack, který neřeší podstatu problému, vůbec se mi to nelíbí, protože to zase spoléhá na nějaké řazení dat z HTML form. Je to pořadí vůbec garantované, nebo je to jenom nějaká konvence? Nehledě k tomu, že zas někdo může poslat request bez toho posledního políčka. Na to bych vůbec takhle nespoléhal. Měl bys IMO primárně především na začátku zkontrolovat proměnnou $_FILES jestli tam není ta chyba. Ideálně bys měl napsat nějakou funkci nebo request API, které tuhle křehkou práci zabalí na jednom místě a poskytne bezpečné, chybově ošetřené API, k tomu případně připsat pořádně velký a strašidelný komentář varující člověka, aby si dobře rozmyslel změny v té funkci/API, protože jsou z toho pak tyhle blbě debugovatelný problémy.

A ve zbytku kódu už bys používal jen tuhle funkci/API a na ty debilní globální proměnný vůbec nešahal.

[kralyk z abclinuxu]

Nehledě k tomu, že zas někdo může poslat request bez toho posledního políčka.

Oprava: Měl jsem na mysli, že může to pořadí přehodit.

[Václav HFechs Švirga]

Např. https://doc.nette.org/en/forms/standalone (samostatně se dá použít, je to jeden PHP soubor tuším, řeší toho spousty).

[mirec]

Jaj prerušený upload

[mirec]

Inak sranda bola aj debugovanie password_verify keď pri zlom vstupe vracia true.

The documentation for `password_verify()` clearly states that the `$hash` has to be valid:
> hash
> A hash created by password_hash().
I fail to see how this is a bug if you feed it garbage; also the documentation to crypt states:

Crypt je inak tiež krásny modul ;)

Returns the hashed string or a string that is shorter than 13 characters and is guaranteed to differ from the salt on failure.

[kvr]

Ta password_verify je teda masakr. A ta argumentace v tom ticketu ještě horší.

Ono Php je celkově slepá větev. Kdysi jsem řešil, že nějaká string funkce (substr?) při očekávaném výsledku prázdného stringu vracela false. Následně porovnání přes === samozřejmě selhalo. Ten jazyk a API jsou tak špatné, že není jiné cesty než zahodit.

[votruba]

+1^2560006545746544

[J]

Naprosty souhlas. Php mi pripomina rok 1998 kdy v Praze kazdy Slovak kodil v PHP pro nekoho stranky ktere delali uplne hovno ale potrebovali mysql databazi protoze to bylo cool. Dle blogu bych rekl ze autor udrzuje nejaky takovy vytvor. Se divim ze je zakaznici s timhle jiz neposlali do prdele.

[kvr]

Tak jenom pro úplnost, našel jsem ten kus kódu:

php var_dump(substr("a", 1)); bool(false)

Měli koule na to, aby i za cenu backward incompatibility to opravili už v Php 7 (poslední Php 5.6 ještě vrací false). Od Php 8 už vrací "" i index mimo rozsah, tedy třeba 2 na string délky 1. Což je s otazníkem - "normální" jazyky vyhodí exception, ale to je u Php nadstandard...

[Kde PHP, tam nebezpečno]

Ondřej Surý: "I fail to see how this is a bug if you feed it garbage"

Hackers everywhere: "Let's feed it garbage and see what happens..."

PHP: "Access granted."

Co jsem ti udělal, Ondřeji, že mě takhle trestáš? Pošlete ho někdo prosím na kurz základů počítačové bezpečnosti. Nebo radši na dva.

[podlesh]

Naštěstí máme rok 2023, takže to někdo napráskal a bud dostal CVE. Na to si dneska nikdo netroufne říct "opravovat to nebudeme, git gud losers".

[plostenka]

No fakt ze jo... rofl

[mirec]

Z vtipných vlastností PHP typu to hádam nemôže byť pravda ešte vyberám:

Prečo majú PHP funkcie tak divné názvy?

Pretože hashovacia funkcia pre funkcie bola strlen. Preto aby boli hashe funkcí rozdelené rovnomerne museli mať názvy funkcií rovnomerné rozdelenie dĺžky.

Alebo vo verzii 7 a menej:

php > if (undefined) { echo "tadaa"; }
tadaa

Bez varovania iba s poznámkou. A teraz si predstavme kód plný niečoho takého:

define(ma_prava, array_key_exist(...)); ... if (ma_prava)

Všetko funguje krásne kým sa kódu nechytí niekto ďalší a nezabudne na define na vrchu.

Vo verzii 8 (3x hurá) to skončí aspoň chybou (alebo varovaním, že došlo k chybe? :D)

php > if (undefined) { echo "a"; }
PHP Warning:  Uncaught Error: Undefined constant "undefined" in php shell code:1
Stack trace:
#0 {main}
  thrown in php shell code on line 1

[Jendа]

OMG, a to mi tvrdili, že PHP: a fractal of bad design je už v nových verzích PHP (7, 8) vyřešené.

Ale asi to nikoho nepálí, když furt nikdo neudělal náhradu pro nějaký normálnější jazyk (ne, rezidentní aplikace např. ve Flasku, nebo cold-start celého interpretu Pythonu při každém requestu, opravdu nejsou náhrada).

[AraxoN]

Riešenie som doplnil do článku!

Úspešným riešiteľom menujem mireca, aj keď viacerí boli odpovedi celkom blízko.

Pekné sviatky všetkým.

[phpsucks]

hehe jelita jeste si zkuste doma tohle

md5('240610708') == md5('QNKCDZO')

=> bool(true)

[mirec]

Ňuňuňu automatické pretypovanie na číslo.

[mirec]

Tu by som asi každému používateľovi PHP (programátorovi?) odporúčal všade používať ===. Problém je, že človek sa mýli a občas jeden znak zabudne.

Ako bývalého PHPčkára ma táto náchylnosť na chyby nesmierne unavovala. Skoro každá funkcia je nejakým spôsobom zle implementovaná z čoho vyplýva, že pri každom volaní si programátor musí prejsť corner casy a to neskutočne unavuje a je to náchylné na chyby.

[z_sk]

Zaleží asi aj od typu programovania. Tak:

$position=strpos($text, "something");
if($position=== false)
   return false;

je asi programátorsky ľahšie ošetrenie podmienky ako:

errno=0;
value=atoi(input);
if(errno != 0)
   return -1;

[mirec]

Keď už tak tie príklady by mali byť aspoň ekvivalentné. Takže v C by to bolo:

char *found = strstr(text, "vyraz");
if (!found)
    return ...

Alebo v druhom prípade ten prevod čísel:

if (!is_numeric($input)) {
    return -1;
}
$value = (int)$input;

Bez explicitnej kontroly pretypovanie vráti 0 čo môže mať za následok neočakávané správanie aplikácie.

[z_sk]

Prvý môj príklad bol zámerné v PHP, druhý v C. Ak čakáš od PHP ako lepšie C, tak PHP je okey.

P.S.: strstr/memmem vracia v C na chybu NULL.

[kvr]

strstr vrací NULL v případě, že hledaný string není nalezen. Chyba jako taková nenastává (respektive může nastat SIGSEGV pochopitelně).

Ten kód v C s errno nebude fungovat - atoi errno nemění. Dá se použít strtol neb std::stoi, druhá zmíněná vrací exception, pokud nelze zkonvertovat vůbec nic.

Java a jiné modernější jazyky jsou na tom ještě líp - vrací pouze validní výsledek, v opačném případě exception. Takže typický kód (který nezajímají chyby) je na jediný řádek. V C i novém C++ tyhle věci pořád ještě z velké části chybí.

[z_sk]

S atoi mas pravdu. Tak tam treba pouzit scanf. Skusil som strtol, ale ani to to nie je celkom ono (ak detekcia a ka regulerny vyraz). Tak zostava sscanf():

#include <stdio.h>
#include <stdlib.h>

int main()
{
	int number;
	int result;
	
	char buffer[100]={0};
	
	
	fgets(buffer, 100, stdin);
	
	result=sscanf(buffer, "%d", &number);
	if(result == 1)
		printf("Number %d.\n", number);
	
	return 0;
}

[Bystroushaak]

Tu by som asi každému používateľovi PHP (programátorovi?) odporúčal všade používať ===. Problém je, že človek sa mýli a občas jeden znak zabudne.

Já bych šel ještě dál a používal ====. Kdyby šlo do nejhoršího a bylo třeba porovnat extra těžké váhy, tak =====.