Pozwólmy myśleć

Z zainteresowaniem przeczytałem artykuł Zastrzyk prosto w serce (CW nr 13/2003), bliski mi tematyką ze względu na prowadzone w przeszłości projekty. Opisana metodyka przełamywania barier ochronnych, czyli SQL injection, jakże oczywista i jednocześnie prawdopodobnie nie doceniana przez wielu twórców internetowego dostępu do baz danych, posłużyła mi tym razem do wyrywkowego sprawdzenia, jak też wygląda rzeczywisty stan zabezpieczeń witryn, do których zazwyczaj zaglądam. Okazało się, że miejsca, które wizytuję najczęściej, są na tyle poprawnie skonstruowane, iż nie sposób przemycić kodu SQL z nadbudowaną składnią. Wobec braku wrażeń z dreszczykiem postanowiłem wreszcie przetestować swoje produkty.

Z zainteresowaniem przeczytałem artykuł Zastrzyk prosto w serce (CW nr 13/2003), bliski mi tematyką ze względu na prowadzone w przeszłości projekty. Opisana metodyka przełamywania barier ochronnych, czyli SQL injection, jakże oczywista i jednocześnie prawdopodobnie nie doceniana przez wielu twórców internetowego dostępu do baz danych, posłużyła mi tym razem do wyrywkowego sprawdzenia, jak też wygląda rzeczywisty stan zabezpieczeń witryn, do których zazwyczaj zaglądam. Okazało się, że miejsca, które wizytuję najczęściej, są na tyle poprawnie skonstruowane, iż nie sposób przemycić kodu SQL z nadbudowaną składnią. Wobec braku wrażeń z dreszczykiem postanowiłem wreszcie przetestować swoje produkty.

Sięgnąłem więc do witryn, mojego autorstwa, z którymi styczność przy okazji ich projektowania miałem jakieś pięć lat temu. Zajrzałem do dokumentacji, aby nie błądzić po omacku i by od razu sprawdzić, gdzie może być najczulsze miejsce na wpompowanie niechcianego i demaskującego wnętrzności kodu SQL - nie ma nic bardziej satyrycznego niż autor rozwiązania, które dla niego samego stanowi tajemnicę.

Przestudiowałem więc konstrukcję i nazwy tabel, sposób odwoływania się do nich i dalejże próbować się włamać. Okazało się, że nie jestem w stanie przełamać własnych zapór, a więc test wypadł poprawnie. Zastanawiając się dlaczego - bo przecież tworząc owe rozwiązania, przyznam szczerze, nawet nie myślałem o tego rodzaju atakach - doszedłem do wniosku, że wynika to bezpośrednio z mojego doświadczenia i pewnej, wpojonej przez lata praktyki, zapobiegliwości. Tworząc wszelkiego rodzaju interfejsy dostępu do danych, zapewniam zawsze szeroko pojętą walidację danych, eliminującą już na wstępie możliwość popełniania błędów przypadkowych czy destrukcyjnych działań zamierzonych.

Tym między innymi różnią się moje produkty od wielu innych, funkcjonalnie im podobnych. Stąd też wyższa moja cena aniżeli u konkurencji, co mnie samego nie dziwi, ale dla nabywców stanowi często koronny argument. "Kowalski, pan jesteś drogi" - usłyszałem niedawno od pewnego decydenta. Być może drogi, być może nie - jest to kwestia względna. Jeśli użytkownicy oprogramowania dzięki jego poziomowi automatyzacji eliminują dosyć wymierną liczbę działań pośrednich, to znaczy, że de facto koszty zakupu w miarę szybko się zamortyzują. Niestety, nie dla wszystkich jest to argument przemawiający bardziej niż pierwotna cena zakupu.

Z drugiej strony, zbytnia automatyzacja stanowisk budzi u pracowników pewne obawy dotyczące zachowania miejsc pracy. Spotkałem się niedawno z opinią kierowniczki działu, że w zasadzie lepiej już oprogramowania nie rozwijać pod kątem jego dalszej automatyzacji. System komputerowy nie musi we wszystkich kwestiach "myśleć" za użytkowników, którzy jako pracownicy merytoryczni powinni zdawać sobie sprawę z ich powinności i wiedzieć, w których momentach realizować określone procedury. "Oni i tak już tylko klikają" - padło podsumowanie ich dosyć bezmyślnego stylu pracy, do którego w dużej mierze ja się przyczyniłem.

Wobec powyższego postanowiłem solennie, że moje następne produkty będą tanie i wymagające nie lada wysiłku umysłowego od użytkowników.