Hlavní navigace

Názor k článku Zranitelnosti typu injekce: SQL injekce od Logik - - Escapování není žádné léčení choroby. Escapování je...

  • Článek je starý, nové názory již nelze přidávat.
  • 15. 10. 2018 17:08

    Logik

    - Escapování není žádné léčení choroby. Escapování je v SQL standardu stanovený způsob, jak se píší do SQL příkazu hodnoty.

    - "Unicode bylo několikrát rozšiřováno"
    Ovšem UTF-8 je uděláno tak, aby toto umožňovalo bez bezpečnostních problémů pro 7bitový subset. Ale to je vlastně vedlejší - při správné práci s databází to není problém ani při escapování, při špatné to je problém i při použití PS (protože ty by v lepším případě měli také selhat při zápisu neznámého znaku, v horším zapíšou do db něco, čemu nebudou rozumět a co bude v případě použití db funkcí na práci s řetězci dělat problém).
    Nicméně hezké je, že se o několik řádek níž v podstatě touto vlastností UTF8 oháníš, ale tady ji nebereš v úvahu... :-)

    - "ale shodnou se obě strany na tom, co je neplatná sekvence?"
    Pokud máš správně nastavenou databázi, tak shodnou, protože knihovní funkce se s databází domluví. A pokud nemáš správně nastavenou databázi, tak kdoví, co Ti bude selhávat dalšího. Řešit blbě nastavenou db zavrhnutím escapování je rovnák na vohejbák.
    Navíc, toto je opět problém společnej s prepared statements. I tam, pokud se blbě domluví na kódování, tak dojde k nekorektnímu běhu aplikace: do db se zapíše blbina. Nic z toho, co jsi napsal, není problém specifický pro escapování.

    - "A verzi parseru SQL a nastavení systému a locale a bůhvíco ještě dalšího, co může parsování SQL příkazu ovlivnit."
    To neřešíš ty, to řeší databázový klient. Pokud používáš blbě napsanýho db klienta, změň knihovnu či databázi. Opět, kdoví co dalšího bude mršit.

    - "toho, co jsem napsal, už je snad jasné, že pohlídat si vše, co může selhat při escapování, není v lidských silách"
    Negeneralizuj. Že nevíš, co máš zkontrolovat, ještě neznamená, že to neumí jiní. Pokud používáš správné knihovní funkce, tak jediné, co bys měl zkontrolovat, je, že data vkládáš do db ve správném kódování. A to musíš zkontrolovat i u escapování, i u prepared statements. Vše ostatní dělají knihovní funkce, a to i u mysql, kde to bývalo kolem verze 4.1 problém, protože MySQL do té doby měla kódování implementované prapodivně.

    - "obvykle se nic nezmrší a na datech to nepoznáte."
    "Obvykle" - takoví jsou nejlepší, co píšou tak, že to "obvykle" projde a je "radost" po nich aplikace opravovat. Právě to je společné všem "syptomatickým přístupům", že se řeší jen zjevné problémy, ale hromada dalších jich v aplikaci zůstane. Např. až se někdo připojí do db jiným (a z hlediska kódování správným) přístupem a něco tam zapíše, tak budeš mít z databáze neopravitelný guláš - a při troše štěstí na to nepřijdeš hned, ale až když si někdo ten guláš nechá opravit.

    Když máš správně nastavenej "stack" aplikace - klient - databáze, tak tebou citovaná "nevýhoda" escapování zmizí. Pokud ten stack nastavenej nemáš, tak je nebezpečí SQL injekce jen jeden z mnoha průšvihů - stejně budeš do databáze psát nesmysly, i když použiješ PS.
    A to si navíc vůbec nereagoval na to, že polovina knihoven s "prepared statements" dělá ve skutečnosti escapování, takže jejich používání je jen iluze bezpečnosti, teda spíše iluze rádobybezpečnosti.

    Zdá se mi, že žiješ ve světě mysql 4.0, kde se kvůli blbému návrhu Mysql dokolečka problémy s kódováním opravdu vyskytovaly. MySQL je ovšem už dávno jinde a jiné databáze to měli zpravidla bezproblémově vyřešené od začátku.