> Mám za to, že u programování na webu je rizikem vždycky to, co > dostávám od uživatele -- tedy data z formulářů a podobně. Pokud mi > chce web někdo heknout, snaží se podstrčit nějaká svá data nebo kód, > který vydává za data. Takže já jako programátor bych neměl dopustit, > aby to, co vypadá jako data, šlo za nějakých okolností spustit. A zde > jsou určité skupiny znaků, které jsou nebezpečné: závorky, zpětné > apostrofy atd. Ono je spustit a spustit. Tomu co popisuješ se říká code injection a je to možné aplikovat mnohem šířeji. Například: - pokud se uživatelský vstup dostává do eval() - pokud se uživatelský vstup dostává do sql dotazu (což je téměř vždy) (obligátní xkcd: http://xkcd.com/327/ ) - pokud se uživatelský vstup dostává do shellu (voláním system() nebo popen() To jsou jen nejčastější případy, podle toho si tam kdo dá mohou nastat i jiné (cronab, url, xslt, šablonovací systémy…) a každý má jiné escapování. Ošetřit všechno je prakticky nemožné už jen vzhledem k počtu možností, nemluvě o tom že jednotlivé syntaxe spolu kolidují.
> U Perlu je hezkou vychytávkou přepínač -T. Ten všechna data od > uživatele považuje za "nakažená" vyléčit je je možné jen kontrolou > přes regulární výraz. Dokud to programátor neudělá nemůže nakažená > data použít v rizikových situacích. Nevíte o nějaké podobné možnost > pro Python? To je s prominutím pitomost. V PHP taková vlastnost kdysi byla ale bylo z toho víc škody než užitku a nakonec byla zrušena. Kromě toho – k čemu by to bylo? Pokud se mají tvoji svěřenci něco naučit, tohle je jedna z lekcí bez kterých se neobejdou. Spoléhat se že to někdo udělá za ně je přesně to co by se naučit neměli :-) A protože učený z nebe nespadl, musíš prostě konzervativně předpokládat že díry budou. Šel bych proto spíše cestou izolace – apač v privátní síti, mod_user, chroot, jail, virtualizace… _______________________________________________ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python