Granice paranoi

Jestem ogromnym antyfanem polemizowania z kimkolwiek w sposób inny, niż otwarty. Nie lubię artykułów polemicznych, nie lubię dyskutować przy użyciu form, które powinny być zamknięte. Na polemikę jest miejsce pod tekstem. Jednak nie mogę się powstrzymać i spiszę kilka myśli na temat ostatniego wpisu na blogu webnulla, który można poczytać pod tym linkiem.

Nothing is secured...

Webnull często raczył nas artykułami związanymi z ogólnie pojętym bezpieczeństwem. Część z nich była parówkami, część była nawet interesująca, część jednak była beznadziejna. Artykuł, do którego się odnoszę zdaje się sięgnął szczytu. Rozłożę go powoli na części pierwsze, niestety - wraz z komentarzami.

Cachowanie zawartości strony w kontekście bezpieczeństwa

Co za wierutna bzdura. Coś jakby "kolor pomidorów w kontekście zużycia bieżnika opon". Cachowanie służyć może zmniejszeniu loadu serwera i skróceniu czasu ładowania się strony. Nie ma żadnego realnego wpływu na bezpieczeństwo aplikacji. Bo niby jak? webnull twierdzi, że

W odpowiedzi na post Ryana

No drogi panie! Co za stek bzdur! Jeśli tylko poprawnie używamy geta i posta (ten pierwszy do ustawiania parametrów wyświetlanej strony, drugi do przesyłania danych od użytkownika) to co ja tutaj mama cachować? Użytkownik chce wyświetlić 15 wyników na stronę, to mu tego nie dasz bo nie masz w cachu? A może wygenerujesz na żądanie cache, zapiszesz sobie i będziesz liczył, że w przeciągu 10 minut (czy ile tam live time się ustawi) ktoś znów zażąda takich samych danych? A może by tak po wysłaniu komentarza poprosić usera, żeby łaskawie wstrzymał się z zapoznaniem się z tym, co spłodził, bo cache trzeba oczyścić? A może inne rozwiązanie? Kolejka! O tak! Serwujemy stale te same dane, dochodzą komentarze słane postem, a potem raz na 862 sekundy insertujesz jednym zapytaniem? Litości.

Mam jeszcze jeden pomysł! Strona będzie wyświetlała stoper, który będzie odmierzał czas do otwartego okna komentowania. I tylko przez 5 sekund będzie można kliknąć wyślij! Genialne rozwiązanie. A o ile się wydłuży czas przebywania usera na stronie!

Elastyczne interfejsy do niczego, czyli z armatą na muchy

Wyobraźmy sobie prostego bloga. Co można zrobić na takiej stronie? Dodać wpis, dodać komentarz, zalogować się... i już. Widzę więc konieczność robienia 3 insertów (dla wpisu, komentarza oraz dodawanie użytkowników), 3 selectów (wyświetlanie wpisów, wyświetlanie komentarzy, autentykacja) i 3 updatów (zmiana treści wpisu, zmiana wpisu komentarza, dezaktywacja użytkowników). I czy dla tych 9 (słownie- dziewięciu) query warto zaprzęgać do pracy rozbudowane klasy, przerzucać między nimi obiekty? Trzeba znać umiar.

...paranoia is your firend

Z drugiej strony nie da się ukryć, że niebezpieczeństwo czai się wszędzie. SQLi albo inny google include to tylko jeden z banalnych do zabezpieczenia (głównie dlatego, ze powszechnie znany) sposób na zaatakowanie serwisu. Prawdziwe zagrożenie to jednak nie wstrzyknięty gdzieś kod, a głupota i lenistwo programistów i administratorów. Za wskazywanie potencjalnych niebezpieczeństw chwała i cześć webnullowi, za proponowane rozwiązania... a tu już każdy według własnego uznania.

Postaram się napisać parę słów jeszcze o SQLi, sql file injection, JSi i co to jest ten google include hack. To będzie parówka :)