Problémy starých skriptů v novém PHP

heh cau vsichni ted vam asi budu pripadat jak big lama a nebo big looser  ale muzete mi vysvetlit par vecicek s PHP nejaky cas delam ale jeste se tim nezivim a porad se spis ucim

1) co je presne promena $_REQUEST nebo spis co vlastne obsahuje

2)mohli by jste mi trochu vic vysvetlit priklad Jiriho Kocmana

reset($_GET);
while(key($_GET))
{
 ${key($_GET)} = current($_GET);
 next($_GET);
}

reset($_POST);
while(key($_POST))
{
 ${key($_POST)} = current($_POST);
 next($_POST);

...
}

a co presne znamenaji fce: reset, next, key a current. Trochu sem je z manualu nepochopil

3)co to je za fci: import_request_variables() a co presne umi

dopredu diky za vysvetleni jinak ja osobne vyuzivam superglobalnich promenych protoze mi to prijde bezpecnejsi uz jenom z principu

Pro takové dotazy slouží manual, který si můžeš stáhnout na php.cz v sekci download, je to tam hezky popsané

pardon v sekci documentation

ted uz to nepotrebuju ted uz tomu rozumim :)

Zdravim,

nejdrive by si autor mel to co napise overit. Skript ktery uvadel nefunguje vubec kvuli ` misto ' nebo ", dokonce kdyby se nesnazil o zadnou uvozovku tak by to behalo. Kdyz si skritp opravim a spustim, tak se zobrazi IP adresa v obou pripadech !!!! A proc? Protoze nova pole $_neco jsou do budoucna doporucovana a stary zpusob bude casem zrusen, ale stale je mozne pouzivat stary zpusob zapisu !!!

Od tohoto clanku jsem cekal daleko vice... treba skvela vec jako identicnost promennych, predavani hondoty odkazem apod... je toho spousta, co se zasadne zmenilo v PHP4 ale o tom se tu vubec nepise...

"V PHP 4.2.x je však implicitně nastavena hodnota off, čímž se předávání proměnných tímto způsobem zakazuje" ... tohle je fakt super... co to ma spolecneho se zmenami v PHP4?... prece kazdy clovek si konfiguraci dela dle sebe a NIKDY nenecha implicitni nastaveni, krome lam ktere si to neumeji poradne zkompilovat a nastavit...

"A jakou tedy můžeme mít jistotu, že byla proměnná předána právě z předchozího formuláře? Odpověď je stručná: žádnou." - nesmysl... existuje HTTP referer... cely form muze byt odeslan pres HTTPS, tim (domnivam se) se snizi pravdepodobnost zmeny REFERERa.

"Bohužel většina skriptů příliš důvěřuje zadaným údajům." - to je blbost programatora, ne PHP.

"by bylo "hazardem" provozovat starší verzi PHP4 než je verze 4.0.6." - přitlačil bych 4.1.2+

"Při těchto faktech by možná bylo vhodnější využít $_neco. Pokud máte ale rozsáhlý projekt, který nějaký čas vytváříte a v kterém využíváte $HTTP_neco_VARS, pak by bylo nerozumné předělávat znovu všechny scripty. Přeci jen $HTTP_neco_VARS ještě dlouho zůstane pro zachování zpětné kompatibility. Zde je zbytečné přidělávat si práci." - pokud je projekt psan spravne, tak to veme 10 minut prace predelat ho tak aby pracoval s poli $_GET, atd... Staci kdyz bude v projektu jedna metoda objektu (1 objekt = cely projekt), ktera zpracovava vsechny promenne, a je ji v podstate jedno odkud tato pochazi... Pak jeste exustuje lamarsky postup a to: nastavit auto prepend file a do nej dat asi toto:

reset($_GET);
while(key($_GET))
{
 ${key($_GET)} = current($_GET);
 next($_GET);
}

reset($_POST);
while(key($_POST))
{
 ${key($_POST)} = current($_POST);
 next($_POST);

...
}

?>

a mame tady register globals...

Som daleko od toho, aby som clanok nazval "totalni propadak" - predsa len asi autor nema roky praxe v PHP a niektore drobne nuansy mu unikaju... Ale to iste sa da povedat aj o Vas: konkretne v tom priklade na konci pouzivate uplne uchylny sposob prace s polami, lepsie by to bolo takto:

foreach ($_GET as $key=>$val) {
    $$key=$val;
}
...
?>

este lepsie z pola $_REQUEST a uplne najlepsie je pouzit funkciu import_request_variables()

Uvadel jsem ze se jedna o lamersky postup

Co se tyce propadaku... myslim ze nadpis hovori o necem jinem nez clanek... respektive v tematu clanku nevidim problem kompatibility...

Dobry den,

rad bych uvedl na pravou miru nektere veci, ktere jste zde uvedl:

>Skript ktery uvadel nefunguje vubec kvuli ` misto ' nebo ", >dokonce kdyby se nesnazil o zadnou uvozovku tak by to behalo.

To, ze redakcni system www.zive.cz provedl konverzi do techto uvozovek, tak za to skutecne nemohu. Original byl v poradku, takze chyba neni na me strane.

> Kdyz si skritp opravim a spustim, tak se zobrazi IP adresa v obou >pripadech !!!!

Zkousel jsem tento script znovu a ip adesa se nezobrazi v obou pripadech. Nejspis zalezi na konfiguraci. Ja jsem to testoval na konfiguraci Apache 1.3.26 + PHP 4.2.x.

> je toho spousta, co se zasadne zmenilo v PHP4

Tento clanek byl skutecne o necem trochu jinem :)

>prece kazdy clovek si konfiguraci dela dle sebe a NIKDY nenecha >implicitni nastaveni, krome lam ktere si to neumeji poradne >zkompilovat a nastavit...

Neuzival bych tak silny slovnik. To, ze je global_register ve vice jak 80% pripadu nastaveno na on je obecne znama vec.

>cely form muze byt odeslan pres HTTPS

Jiste, muze, ale ne vsude je mozne HTTPS vyuzit. Proste neni k dispozici. Jiste, muzete namitnout, ze v tom pripade je spravce serveru "lama", ale jako  programator s tim nic nenadelam. Obecne programator by mel byt tak trochu paranoidni, ale uzit na vsechno hned HTTPS neni dobre. Zalezi pripad od pripadu.

>Bohuzel vetsina skriptu prilis duveruje zadanym udajum." - to je
> blbost programatora, ne PHP

Jiste, mate pravdu. Timto clankem jsem na to chtel taky trochu poukazat.

Autor clanku

P.S: Tento clanek byl o necem trochu jinem nez jste si nejspis predstavoval. Vasi silnou argumentaci o "propadaku" nechapu.

Obsah clanku dle meho nazoru neodpovida nadpisu "Problemy starych skriptu v novem PHP" - nevidim realny a predevsim zasadni problem s novym zpusobem pristupovani k promennym.

Problem s register globals take neni zcela oduvodneni, protoze jde stale nastavit na on mozna by mel jit zapnout jen pro konkretni adresar napriklad pomoci htaccesu... Problem by byl tehdy, kdyz by registrovani promennych neslo zapnout.... Je jen na spravci serveru zda to povoli nebo ne... tudiz je to zavisle na konfiguraci...

Lepsi by byl treba clanek jake vyhody a nevyhody prinasi safe mod... napriklad ze :

exec("dir '/data/test s mezerami'");

se bude chovat jinak se zapnutym a jinak s vypnutym safemodem...

Za ten nadpis se omlouvam. Skutecne nebyl prilis vhodny. Kdyz jsem premyslel nad tim, jak bych ten clanek vlastne pojmenoval, nic me proste nenapadalo. A kdyz uz jo, tak to bylo prilis dlouhe. Tuto vytku prijimam....

Autor clanku

PHP je krasne prave to, ze se promenne daji predavat nejen pres formulare, ale uvnitr skriptu. Takze jestlize mam stranku index.php?action=menu , tak pokud chci neco podobneho udelat v jinem scriptu napisu

$action="menu";
include "index.php";

Clovek se na script musi podivat programatorsky. Script ma urcite vstupni, a urcite vystupni promenne. Pokud se zamerime na vstupni promenne, je nam uplne jedno, odkud se vzaly, zabezpecit se musi stejne, protoze chybu muze udelat nejen uzivatel, ale i programator. Proto tezko budu prijimat vstupni promenne s nazvem $loggeduser nebo $userid protoze predpokladam, ze tyto promenne obsahuji cislo uctu uzivatele. Tyhle promene proste budu muset v nejakem include nastavovat podle toho, v jakem stavu session je, a tim prepisu podstrcene hodnoty nejakym hackerem. Proste zakladem je inicializovat kazdou promennou na zacatku skriptu.

Pokud jde o predavani promennych mezi scripty (treba tim include), na to mam dobry nastroj. V include session.php kde jsou zdrojaky zabezpecuji oddeleni jednotlivych session inicializouju vsechny potrebne promenne a nastavuju si jednu promennou na specialni hodnotu, kterou potvrzuju, ze tudy script prosel a tudiz je mozne vsechny promenne povazovat za platne. Pokud by z nejakych duvodu hacker spustil vkladany script s podstrcenim parametru, stejne nebude znat onu specialni hodnotu a script ho nejspis vyfuckuje. Je ovsem nutne tu hodnotu kontrolovat na zacatku kazdeho scriptu a pripade nesouhlasu die().

Jinak bych rekl, ze predavani promennych mezi scripty je bezpecne uz z toho duvodu, ze hacker vetsinou nema paru o tom, jak script vypada a jak se jmenuji promenne. Samozrejme, pokud to neni verejny script, nebo k nemu nema pristup (napriklad protoze je to programatoruv kamos :o)

Priznam se, ze problemu nerozumim.

Jak muze zneuzit hacker ty predavane promenne?

Pokud udela include "http://neco.cz/script.php" tak dostane jenom vysledek v HTML a ke zdrojovym datum se nedostane.

Pokud bude volat script s nejakymi vlastnimi parametry, tak je snad jedno, co tam napise, protoze to muze zmenit kazdy kdo ma browser (pokud se parametry predavaji pres GET), u POSTu je to slozitejsi, ale do toho pozadavku je spravnymi nastroji mozno vecpat i vlastni REFERER.

Muzete mi nekdo napsat priklad scriptu, ktery je mozne takhle zneuzit?

Tam neslo ani tak o include ako o registraciu globalnych premennych. Priklad
main.php, z formularu pridu (za beznych okolnosti) premenne user a pwd:

Co si myslis ze sa stane ak zavolam skript ako "main.php?logged=1" ?
Toto je to co je na register_globals nebezpecne. Samozrejme da sa to osetrit tym ze na zaciatku skriptu dam "$logged=0" ....

--
Megac

A co se stane, kdyz si udelam vlastni formular a do nej dam a spustim ho z lokalu?

Prece neni mozne takhle chranit aplikace!

sorry, neni videt:

{input type="hidden" name="logged" value="1"}

A vyvorit falseny referer je legrace -priklad v Perlu:

=======================================================================

use strict;
use LWP::UserAgent;
use HTTP::Request::Common;

my $ua     = new LWP::UserAgent;
my $result = $ua->request(
             POST       'http://www.site.com/count.cgi?ID=31',
             Referer => 'http://www.yahoo.com',
);

=======================================================================

Samozrejme tohle je nevhodny navrh aplikace a jako takove reseni register_globals je pouze obrzlicka.

Muj script vetsinou miva jednu security vstupni promennou a tou je SESSIONID. A je naprosto suma fuk, jestli prijde GETem, POSTEM.

Tady jde akorat o to, ze muzu uvnitr scriptu pouzit prevod SESSIONID na $userid. Pokud si nedam pozor a pri spatnem SESSIONID nevynuluju $userid, pak nekdo muze napsat:

index.php?userid=20

Tady to samozrejme vadi, a zakaze register_globals se toto resi. Hacker ale musi vedet, ze ID uzivatelu se jmenuje userid, a ze uzivatele jsou cislovany 1...n. Mohl by se to dozvedet znalostim scriptu a nebo tak, ze by se program nekde sam prozradil a v nejakem formulari nebo nedejboze v odkazu by se to userid objevilo. Proto zrovna tohle je promenna, ktera ma byt platna pri platnem SESSIONID, jinak inicalizovana na neplatnou hodnotu (null,0,-1,unset($userid)).

Chtel bych namitnout, ze vycet poli v tabulce uprostredo clanku neni kompletni a IMHO schazi tam jedno superblobalni pole, ktere s tematikou souvisi. jedna se o pole:
$_REQUEST (taktez od PHP 4.1.0) - do tohoto pole se davaji prvky ze vsech uzivatelovych vstupu - Cookies, GET, POST. Poradi v jakem se tam zapisuji urcuje nastaveni paramteru "variables_order" v php.ini. Pri pouziti toho pole odpada zjistovani odkud ze mi dany prvek prisel.
doporucuji "register_globals = off"

Super clanek pro vsechny zastance PHP, jsem jednim z nich .

Ale podle me to je cele trochu jinak... Pokud nekomu "stare" skripty v novem PHP nechodi, je to (vetsinou) tim, ze ma register_global nastaveno na Off. Jakmile tuto hodnotu zmeni na On, vse funguje tak jako predtim.

To je naprosta pravda, ale s tim, ze to "najednou" muze byt nebezpecne, s tim pravdu nemate. Je to spis takto:

1.
Pokud jste meli sve skripty bezpecne, jsou stejne bezpecne i s novou verzi PHP.

2.
Pokud jste sve skripty meli napsany nebezpecne, jsou stejne nebezpecne i s novym PHP.

Pokud mate problemy s predavanim parametru u sveho projektu, zamyslete se, na kolik je potreba projekt zabezpecit. Jedna se o maly web a je Vam jedno, jakou metodou vzniknul pozadavek (GET, POST, COOKIE)... pak se na to vykaslete a jednoduse si v php.ini prepnete register_global na On.

Mate projekt, kde pracujete s citlivymi daty a najednou to nefunguje? At Vas ani nenapadne prepnout v php.ini register_global na On. Proste si zrevidujte svoji aplikaci.

Jo, presne tak. Zjistit odkud prisel pozadavek nebyl problem ani ve starych verzich PHP, popisovany bezp. problem je znamy od zacatku vyvoje PHP a kazdy kdo dela trochu vetsi veci o nem vi a ma techniky jak toto zabezpecit.

Naopak me tato vlastnost prijde dost uzitecna, protoze muzu vyuzit situace, kdy mam pod $neco parametr ktery muze prijit jak z formulare na strance (POST) tak i z odkazu (GET). S vypnutym register_globals tohle znamena kod navic...

Rozhodne spolehat na to, ze na serveru bude nastavene register_globals=off je dost debilni metoda. Vzhledem k tomu, ze by to znamenalo pro 99% hostujicich upravovat skripty, na hostinzich bude jeste hoodne dlouho register_globals=on... Provideri se k tomu urcite nesnizi, meje jeste v dobre pameti pokusy zavest na svych serverech safe rezim

nezapomente na $_REQUEST['neco']

Predstavte si situáciu:

Mám dva skripty. Prvý je formulár, a druhý spracovávateľ formuláru. Mám nastavené globals na off. Z prvého pošlem premennú napr. ID=123456 metódou POST.

Všetko prebehne OK.

A teraz:

Vytvorím si na inom serveri skrypt, ktorý pošle na môj server premennú ID=123456 tiež metódou POST.

Čo sa stane ???

Prijme skrypt s číslom dva premennú ID s iného servera, alebo nie ???

Neskúšal som to, ale myslím si že áno, a tým pádom je to jedno či mám globals zapnuté na off, alebo on, trebalo by to ošetriť v skriptoch.

Ak sa mýlim, opravte ma.

Ak je to takto, potom aký má význam zavedenie superglobálnych premenných ???

Dá sa naviazať príjem premenných na meno servera ???

Toto je pravda, stejnym zpusobem se da dostat do vetsiny skriptu, ktery si hlidaji parametry (i napr. ASP). Chce se to jen trochu zamyslet....

Čo máte na mysli, nad čím sa treba zamýšľať ???

Treba to podľa mňa zabezpečiť kvalitnou autentifikáciou a pred každým SELECTom do DB skontrolavať práva.

Ešte raz by som sa spýtal:

Dá sa nejako jednoducho naviazať prijatie premennej iba z určitého servera ???

Ak by sa to dalo (určite sa dá, ale zatiaľ som na to neprišiel) tak by to bolo fajn.

To si taky looser. Vsak mas pole$_SERVER a elementy REMOTE_ADDR a REMOTE_PORT. Treba na zaciatku skriptu checknut, ci ide o "nasu" adresu pripadne aj "nas" port a podla vysledku sa zariadit.

Neviem prečo je taký hlúpy zvyk označovať každého kto sa opýta LOOSER.

Ja som sa opýtal a Vy ste mi poradily.

Ďakujem.

Nabudúce bez toho LOOSERa, prosím.

Looser je mc1100, radi uplne nesmyslne 

Kdyz budu mit formular na jinem serveru, staci to zkontrolovat podle promenne $HTTP_REFERER, ktera musi obsahovat cestu ke skriptu na nasem SPRAVNEM serveru, jinak se zpracovani dat muze odmitnout

a pokud jde o testovani, jestli jsou data zaslana metodou post, lze pouzit konstrukci

if (strtoupper($REQUEST_METHOD) != "POST") {

       // ok, zpracuj data zaslana formularem.

}

"ochcat" se vsak da jakykoliv skript... i s tim refererem, kdy se da udelat to, ze se bude posilat spatny referer :)) samozrejme na tohle uz je potreba mit nejaky program, co bude posilat data metodou POST vcetne vsech HTTP hlavicek (i refereru) na cilovy server...

Zrejme mate na mysli program telnet? )))
telnet server 80
POST /url/ke/strance.php HTTP/1.0
Host: adresa.serveru.cz
Referer: http://adresa.serveru.cz/url/ke/strance.php
Length: 10

id=1234567

Treba, taky

vsechno jde prolomit, tohle by ale u vic stranek s hodne parametrama dalo docela dost prace

S tim refererem opatrne, kazdej lepsi Firewall uz ho dneska dokaze bloknout, takze uzivatel by k tomu pak prisel nevine, odeslana data by se totiz zamitli

Divim se, ze tyhle diskuse jeste nekdo cte

Inu, dobra, firewally ho dokazou blokovat, ale... proc to delat? Jsme opravdu tak paranoidni, ze blokujeme vsechno, co muze jen trosku byt "vyuzito" k mapovani pohybu po serverech nebo k overeni, ze uzivatel opravdu prisel z te ktere stranky?

(To uz by ale bylo na psychologicky rozbor... PROC si to lide blokuji

a navíc se to píše loser chytráku

Superglobalne premenne zjednodusuju pristup vo funkciach. Netreba ich v tele funkcie registrovat cez global. Je to len drobnost, ktora pekne zjednodusuje programatorom zivot. Ako bolo uz vyssie spomenute, pokial sa skript programuje od pociatku s rozvahou ("portovatelne" a modularne), problem so zmenou default konfiguracie nie je az taky citelny.

K tvojmu prikladu. Vzdy sa najde sposob ako nieco obist, ale zvacsa to nema hlbsi zmysel. Pisat skript, ktory si predava data z jedneho serveru na druhy je podla mna zbytocne. Urcite by sa vsak nasla aplikacia kde by to malo opodstatnenie...

Je to pravda, ale potom nevidím dôvod na besnenie okolo premenných globals. Už som o tom čítal veľa a mám z toho divný pocit. Bezpečnosť aplikácie sa robí trošku inak ako vypnutím globals !!!

Ano, je to presne tak - zadny duvod k besneni neni.

Pokud mate sve skripty napsany spravne, tzn. vcetne osetreni metory vzniku pozadavku, je Vam uplne jedno, zda mate register_global nastaveno na On nebo na Off - proste to bude fungovat.

Dobry program (programator) si to osetruje sam a neveri vsemu, co je mu podstrceno. Pokud to dela dobre, pak to funguje i s jakoukoliv hodnotou register_globals.

Myslim, ze je dulezite to, co jsem psal v prvnim prispevku - premyslejme o tom, kdy je to potreba sledovat vznik promennych a kdy ne.

Vypnutie register_global ma podla mna skor vychovny charakter. Autori PHP tym chcu zrejme docielit, aby sa skripty pisali uz od pociatku bezpecnejsie. Utocnik tym straca jednu pomerne silnu zbran. Bolo podla mna dost zle, ze mohol hocikto vnutit vasmu skriptu z vonku lubovolnu globalnu premennu.

Súhlasím.

ono bohate staci promenou necim inicializovat a pak mi je srdecne jedno, co se mi kdo snazi podstrcit za globalni promenou. kdyz si date error_reporting(E_ALL), tak vam php-ko bude mimo jine hlasit i pokus o cteni z neinicializovane promene ...

Mno tak ruzove to zas neni ze prepnu register_globals na on.... ono to totiz prave u me vubec nefunguje (a mozna ani u autora clanku)... nejspis to bude tim ze mam Apache 2 a Php 4 a bylo dost obtizne to dat dohromady (PHP pri kompilaci psalo ze Apache 2 neni oficialne podporovan)

takze reseni vidim takto:
   1. psat nove skripty podle noveho PHP
   2. ve starych skriptech pridat na zacatek if (isset($_GET ['neco'])) $neco = $_GET ['neco']; (da se to resit i pres cyklus pres pole kde bude vycet prenesenych promennych) - toto teoreticky zabezpeci i spatne napsany skript

ja by som riesenie videl aj v use perl; use strict;

Ono to muze mit jeste jeden problem: dostane se Vase PHP vubec k souboru php.ini, v nemz mate nastavene register_globals=on? Vsiml jsem si totiz jeste jedne moc hezke (a moc nedokumentovane) zmeny v PHP: promena prostredi PHPRC, ktera drive umoznovala specifikovat cestu k tomuto souboru vcetne jmena souboru (tedy /blbla/php.ini) ted musi byt pouze jmeno adresare, v nemz je php.ini (jinak se mi snazil otverit /blbla/php.ini/php.ini - pochvalen budiz strace ).

Petr

Ono sa clovek musi zamysliet, ci vobec potrebuje Apache 2.0, ci radsej neda prednost osvedcenemu 1.3.x... Aspon do doby, kym nebude PHP4 napisane tak aby s Apache 2.0 vedelo normalne spolupracovat...

Mate naprostou pravdu.

Autor clanku