Która przeglądarka jest bezpieczniejsza?

Pytanie to chyba zadaje sobie każdy w połączeniu z zestawem pytań o wydajność, wtyczki, wygląd itp. Cóż moim zdaniem nie ma jednoznacznej odpowiedzi dlatego, że nie ma przeglądarki która jest bezkompromisowa i idealna. Osobiście używam opery - to takie moje zboczenie (a może nie?). Większość stron i aplikacji tworzonych jest z myślą o internet explorer oraz firefox jednak ostatnio zdobywająca ogromną popularność chrome wkracza do trójki ustalających zasady, czy oby na pewno? Apple w końcu dostrzegł, że safari w krainie przeglądarek jest od dłuższego czasu na wakacjach i postanowił ją odświeżyć. Udało 1:0 dla safari, działa naprawdę szybciej ale w porównaniu do dzisiejszych przeglądarek zostaje daleko w tyle z wydajnością.
Nigdy nie używałem safari do innych celów niż test zgodności strony z przeglądarką, firefox jest pod tym względem lepszy jego główne zalety to wtyczki, narzędzia developerske (tudzież również wtyczki), oraz prędkość działania która jest co najmniej dobra oraz przez ostatnie wydania znacznie zmniejszono ilość potrzebnej pamięci RAM.  To będzie minusem opery, potrafi przy 30-40 zakładkach zjeść nawet 1,5 GB RAM, tak. Operę potraktuję bardziej jako środowisko, dragonfly oferowany przed tą przeglądarkę bardzo dobrze konkuruje a może i nawet wygrywa konkurencję z  z firebugiem - czołowym narzędziem developerskim DOM. Zaimplementowane działanie w chmurze, serwer, opera link, opera turbo, doskonały cache(również w chrome oraz chromium) uwydatnia się przy cofaniu w historii zakładek. Jednak to dlaczego używam akurat opery nie posiadają inne przeglądarki - obsługa gestów myszy i grupowanie zakładek.

Do meritum, do meritum!

IMHO ostatnio rosnąca popularność przeglądarki naraża ją na najwięcej uderzeń ze strony całego czarno-kapeluszowego towarzystwa.

Ostatnie wpadki chrome:

• DOS pod środowiskami NT,
• słaba obsługa PDF,
• memmory corruption (wraz z safari - jako webkit)

Ostatnie wpadki firefox:

• przepełnienie bufora(...),
• pre z rzędu wpadek w obsłudze javascrip

Ostatnie wpadki opery:

• obsługa SVG,
• obsługa javasript

Jestem raczej praktykiem niż teoretykiem, dlatego 'wyjdzie w praniu' jest dla mnie dość dobrym powiedzeniem. Przeglądając ostatnio katalog stron wordpressa łatwo wpadła mi strona kuborra.com, chciałem ją obejrzeć jednak na szczęście chciałem zrobić to operą, ku moim oczom pokazał się widok:

Jako, że bardzo mnie to zdziwiło postanowiłem przeprowadzić odpowiednie dochodzenie. W pierwszej linii poszły skanery online:

• http://www.phishtank.com,
• http://sitecheck.sucuri.net/scanner,
• http://company.yandex.com/technologies/antivirus_technology.xml,
• http://www.urlvoid.com

Jednak jedynie jeden z nich  stwierdził nieprawidłowości, yandex (którego możemy dostrzec na  screenie z opery). Stwierdziłem że warto podczas tak sprytnego ataku na czyjąś stronę sprawdzić resztę przeglądarek (w środowisku virtualnym) -> chrome, chromium, firefox, internet explorer, safari. każda z nich po kolei ładowała stronę i cieszyła się jej widokiem. Dlaczego akurat opera była w stanie zablokować tą stronę?  Odpowiedź jest dość banalna opera używa więcej niż jednej czy 2 black list dlatego jest w stanie dokładniej sprawdzić reputację strony. w chwili pisania artykułu kuborra.com dalej jest zarażona a administracja nie robi sobie z tego powodu problemów...

Która przeglądarka jest najbezpieczniejsza? Na te pytanie nie ma dobrej odpowiedzi, jednak przegladarka mniej popularna (chromium, opera) będą prawdopodobnie żadziej atakowane niż ff czy ie ale czy mamy się przeprowadzić do szwajcarii na czas wojny?

O testowaniu kilka słów...

Zawsze gdy piszemy aplikację przychodzi ten patologiczny moment gdy musimy ją pozbawić błędów które sami (lub wspólnie ze znajomymi) popełniliśmy. Jest to trudne gdyż teoretycznie testowanie własnego kodu jest w jakiś sposób pozbawione sensu. Testując kod wiele rzeczy pomijamy wiedząc odgórnie, że ten input czy to api działa bardzo dobrze - w końcu sam pisałem. Ostatecznie zamiast testować całą aplikację testujemy 20% własnego kodu który sprawił nam najwięcej problemu oraz kod innych programistów (skąd właściwie bierze się zaufanie do własnego kodu?). Dochodzimy do meritum sprawy, tester developerowi w testach nierówny - tester niczemu ani nikomu nie ufa i dobrze robi. Nawet jeżeli testujemy skrypt według określonego scenariusza prawdopodobnie nie zobaczymy wielu logicznych błędów - najlepszym przykładem będzie tu parametr typu int reprezentujący id newsa w tabeli, developer sprawdza i sprawdza czy nie przechodzą sztuczki typu:

• www.example.com?id=1'select...
• www.example.com?id=<script></script> 
• www.example.com?id=%3Cscript%3E%3C/script%3E    

 powinno działać, dopóki nie przyjdzie tester i nie wpisze:
  www.example.com?id=-1.
Jako że nie istnieją wartości mniejsze od zera prawdopodobnie ukaże nam się zapytanie do bazy danych, ale nie chodzi nam o zapytanie ale o metodologię testów. Jeżeli musimy sami testować aplikację musimy starannie przygotować scenariusz wraz z właściwymi parametrami które na aplikacji będziemy testować oraz założyć, że aplikacja napewno posiada błędy lecz narazie nie wiadomo gdzie. Przydadzą nam się również ciągi znaków francusko - japońsko - szwedzko - rosyjsko - tureckie które łatwo znajdziemy na translate.google.com.

Warto byłoby sprawdzić naszą aplikację jak radzi sobie z brakiem dostępu do bazy danych czy też samej bazy lub w sytuacji gdy brakuje nam niektórych plików - nie możemy pozwolić aby użytkownik zobaczył jakąkolwiek część kodu.

Kiedy zakończyć testy? Nigdy, wszystkie błędy które aplikacja generuje powinny być logowane, nigdy nie będziemy do końca pewni czy aplikacja jest pozbawiona błędów choćby na fakt, ze niektóre rzeczy nie zależą od sposobu ich zaprogramowania a samej platformy czy technologii - dlatego też polecam tworzenie kopii zapasowych;)

Jakiego masz phpMyAdmina?

Wielu administratorów oraz developerów nie pamięta o aktualizacjach a co ważniejsze nie śledzi bugtraqów. A szkoda bo od dzisiaj każdy może łatwo sprawdzić czy posiadasz starego phpMyAdmina.



W związku z ostatnimi poważnymi błędami w phpMyAdmin ukazał się bardzo prosty lecz bardzo ciekawy phpwy skrypt Administrative PHP Scanner. W prosty sposób sprawdzi ścieżkę oraz wersje phpmyadmina zainstalowaną na serwerze. Sam w sobie skrypt może się nikomu nie przydać jednak ostatnimi czasy powstaje bardzo dużo exploitów potrafiących wstrzykiwać kod, zmieniać hasło administratora czy poprostu wykorzystujące bardzo skutecznie ataki DOS.

Bezpieczeństwo a realia

Dlaczego wciąż można znaleźć niezabezpieczone strony - bardzo banalnie niezabezpieczone które przeciętny script kid złamie w parę minut? Większość instytucji prywatnych czy publicznych stara się jak najbardziej ciąć koszty, najczęściej widać to po stronie która poza ładnym wyglądem (ponieważ stronę narysował dobry webmaster podpinając ją szybko do jakiegoś znanego cms'a) nie była testowana w żaden sposób no bo przecież cms jest gotowy? Nie ma błędów wszystko się ładnie zapisuje, pokazuje , super! - Myśli sobie zleceniodawca. Za stronami/aplikacjami poważnych stron  stoją przynajmniej 4 osoby (projec menager, grafik, webmaster, developer) z czego osoba/zespół odpowiedzialny za implementację logiki oraz testy. niespełnienie tego warunku zagraża bezpośrednio  firmie - a tak, bezpośrednio.

Nawet najsłabszy atak typu xss może skutecznie osłabić pozycję firmy wobec konkurencji, nie wspominając o atakach na back-end aplikacji oraz kradzież wrażliwych danych. Firm audytujących bezpieczeństwo nie brakuje, czy ten 'proceder' jest spowodowany niewiedzom? Ostatnio zdarzyło mi się przeprowadzić audyt strony firmy znajomego. Firma planuje wejście na giełdę i działa w sektorze finansowym, jednak informacja o błędach wcale go nie przeraziła - choć umożliwiały między innymi upload plików...

CERT - polska komórka będąca elementem nask'u pełniąca służbę ku bezpieczeństwu informatycznemu kraju (właściwie nie tylko naszego ale z innymi nie miałem przyjemności). Informując cert o istnieniu pewnych niebezpieczeństw/incydentów czy luk w ważnych dla RP aplikacjach powinniśmy liczyć na szybką reakcję - niestety tak się nie stanie. CERT najczęściej odpowiada po 3-5 dniach i trudno nawiązać jakąkolwiek komunikację, choć mają to uwzględnione w swoim regulaminie, to często nawet po upłynięciu miesięcy nie da się dowiedzieć czemu luka została nie została usunięta i z czego to wynika. Oczywiście ze strony certu informującemu nie jest to potrzebne jednak co jeżeli aplikacja jest zbyt ważna by było miejsce na luki z zakresu bezpieczeństwa (nie wspominając o zasłudze poszukiwacza przygód)? Nic, od początku do końca nic. Biorąc pod uwagę słabość aplikacji oraz jej państwowość zgłoszenie zastrzeżeń administratorowi nic nie da (z resztą cert pewnie i tak to zrobił) a publikacja tej informacji (anonimowo czy nie) również. Więc drogi obywatelu jesteś skazany na milczenie - chyba, że ktoś naprawi tą lukę będziesz mógł sobie to przypisać na łamach bloga który na pewno pomoże ci w czymkolwiek...


Jedyną możliwością aby wilk był syty i owca cała należy bardzo dokładnie dokumentować znalezione luki, kulturalnie skomunikować się z administratorem - dzięki temu możemy ewentualnie odnieść jakieś korzyści...

Zatem wracając do meritum, co tak naprawdę obniża poprzeczkę?
To mógłby być najdłuższy akapit mojego życia ale skrócę go do jednego zdania. Od kultury wydawania pieniądza oraz kultury kodowania która najczęściej jest bo być musi.