Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

[Bezpieczeństwo] Metody zabezpieczania serwisów internetowych

Witam.

Przedstawię Wam jedno z najprostszych i najbardziej skutecznych zabezpieczeń.
Dla niektórych osób może się okazać równie absurdalne po przytoczeniu odpowiedniej analogii.

Otóż dzisiejsze firmy starają się jak najskuteczniej zabezpieczyć swoje strony internetowe, jednak tak czy inaczej padają one ofiarą ataków czego przykładem są ostatnie ataki Anonimowych oraz LulzSecurity.

Jednym z najczęstszych ataków na aplikacje webowe są SQL Injection oraz ataki typu "include". Obydwa równie niebezpieczne, z czego ten drugi jest nieco prostszy a jak się powiedzie to potrafi dać pełen dostęp do bazy danych aplikacji czy bazy danych całego serwera.

1. Interpreter, czy zawsze jest potrzebny?

Jednym z najprostszych sposobów na częściowe zabezpieczenie jest... przestań używać PHP/Javy/Pythona/Ruby/LUA/..., dosłownie.

Chodzi mi bardziej o to aby generować cache i wyświetlać więcej kodu HTML niż go generować na bieżąco.
Unikanie uruchamiania parsera PHP, Pythona, Javy, Ruby, LUA czy innego wiąże się z mniejszym ryzykiem.

Drobniejsze podstrony WWW czasami lepiej wygenerować okresowo np. co 10 minut automatycznie z powłoki serwera niż serwować użytkownikowi odpowiedzi generowane całkowicie w czasie realnym bądź też przy pomocy cache po stronie parsera kodu.

Oczywiście metoda nie sprawdza się wszędzie, jednak warto ją wziąć pod uwagę kiedy piszemy system blogowy, portal czy cokolwiek innego nie potrzebującego większej interakcji z użytkownikiem.

2. Uniwersalne interfejsy

Zabezpieczanie aplikacji webowych do łatwych nie należy, osobiście uważam, że aby zabezpieczyć aplikację należy użyć czegoś cięższego co odbije się większym zapotrzebowaniem na zasoby.

Przykładem czegoś większego jest uniwersalny interfejs do bazy danych, niemalże odporny na ataki typu SQL Injection.

Przykład uniwersalnego interfejsu z projektu "OpenWikiBlog": <?php $WhereClause = new tuxMyDB_WhereClause (); // poniższa linia wygląda na podatną na SQL Injection bądź inny atak, jednak tak nie jest bo klasa tworząca zapytanie potrafi na bieżąco filtrować argumenty i wartości przyjmowane z zewnątrz $WhereClause -> Add ('', 'name', '=', $_GET['seo_name'] ); // tworzenie zapytania $Query = $this->DB->Select( '*', 'libmypage', $WhereClause, '', '', 0,1); if ($Query -> num_rows == 1) { // hurra, zapytanie się powiodło, odnaleziono jeden rekord } ?>

Oprócz bezpieczeństwa przez swą uniwersalność interfejs zapewnia największą możliwą elastyczność przy tworzeniu aplikacji. Można dowolnie zmienić bazę danych przykładowo z MySQL na SQLite3 czy na jakąś tekstową bez żadnych zmian w kodzie aplikacji.

 

Komentarze

0 nowych
  #1 14.06.2011 17:32

Eeee... tyle? Przy samym SQL Injection wypadałoby wspomnieć o:
- zapytaniach preinterpretowanych (i przy okazji o PDO)
- magic_quotes
- register_globals
- sposobach czyszczenia: addslashes, mysql_real_escape_string itp.

Nie widzę numerku sugerującego, że to I część serii, a więc jestem mocno zawiedziony.

webnull   9 #2 14.06.2011 17:57

@lukasamd
To nie miał być z założenia długi i szczegółowy wpis, miał być bardzo ogólnie napisany i taki też jest :-)

kubut   17 #3 14.06.2011 21:49

@webnull - może warto byłoby dogłębniej opisać różne techniki? Osobiście byłbym zainteresowany wpisami o takiej tematyce.

GL1zdA   11 #4 15.06.2011 13:02

SQL Injection? Chyba dla tych, co zostali w epoce kamienia łupanego tworzenia serwisów WWW - ktoś jeszcze skleja ręcznie zapytania?

  #5 15.06.2011 13:51

"SQL Injection? Chyba dla tych, co zostali w epoce kamienia łupanego tworzenia serwisów WWW - ktoś jeszcze skleja ręcznie zapytania?"

Jeżeli dobrze pamiętam, to ataki na PSN były możliwe dzięki własnie SQL Injection.
Może i SQL Injection jest archaiczny, ale jeżeli ktoś zadałby sobie trochę trudu i zrobił audyt bezpieczeństwa ważniejszych stron, portali, serwisów to myślę, że wynik byłby taki że jeszcze trochę witryn jest podatnych na ten atak.

Ryan   15 #6 15.06.2011 15:27

O mamo, ale bzdura. :S I ten cache generuje się w jakiś magiczny sposób, że nie jest się narażonym na te same ataki, na które narażone są dynamiczne strony? Co za różnica, czy SQLi nastąpi w czasie wywoływania strony czy w czasie budowania cache?

Ardziej   5 #7 15.06.2011 15:58

Szczerze to spodziewałem się czegoś lepszego szczególnie po Tobie :)
Liczyłem na więcej szczegółów, ale i tak pozytywnie :)
Co do cache'wania to sprawa jest nie taka prosta.
@Ryan, zapewne chodzi webnull'owi oto aby generować stronkę po stronie serwera co jakiś czas, tylko w sumie co do bezpieczeństwa nie ma to się nijak. Ponieważ co nam po stronie z cache, jak tak czy siak jakaś interakcja z użytkownikiem musi być na stronie, pola do logowania nie da się "zkeszować" dla wszystkich, ba można dać stronkę samą w HTML'u beż żadnych pól tekstowych, PHP.
A wystarczy użyć solidnego frameworka czy po prostu mózgu w czasie tworzenia danej aplikacji, PDO i problemu nie ma.
Nie ma różnicy jakiego parsera używamy, te co wymieniłeś są po prostu popularniejsze przez co jest więcej "pomysłów" na hacking. Wystarczy mądrze programować, i nie ma problemów, bardzo wielu.

webnull   9 #8 15.06.2011 16:16

@Ryan (redakcja) | 15.06.2011 15:27
Oczywiście, że nie. Jednak szansa jest mniejsza, ponieważ jest na to tylko chwila aby wykonać atak przy użyciu GET, POST itp.

webnull   9 #9 15.06.2011 16:17

@Ardziej
"A wystarczy użyć solidnego frameworka czy po prostu mózgu w czasie tworzenia danej aplikacji, PDO i problemu nie ma. "

Powiedz to tym od Sony ;-)

webnull   9 #10 15.06.2011 16:19

@zorak | 15.06.2011 13:51
Obawiam się, że więcej niż trochę witryn będzie podatnych na atak tego typu.

Wystarczy przeanalizować użycie poszczególnych systemów zarządzania treścią w internecie a procent się znacznie zwiększy.
Przykładowo taki PHP-Fusion wcale od strony kodu nie jest za dobrze napisany.

Ardziej   5 #11 15.06.2011 16:24

@webnull, póki co moje miejsce pracy jest tu w Polsce, i nie w Sony, także póki co muszą sami poszukać wskazówek, chociażby tu ;-)
PHP-Fusion, niby taki znany i lubiany, a nawet kijem bym nie dotknął. Chcą nie chcą, świat się rozwija, szczególnie e-świat, i trza iść do przodu, głównie przez ten postój porzuciłem na jakiś czas Joomle, jednak oni przynajmniej aktualizują pod kontem bezpieczeństwa swój CMS, ale nie ma porównania z np. TYPO3 ;-)

  #12 15.06.2011 16:43

"SQL Injection? Chyba dla tych, co zostali w epoce kamienia łupanego tworzenia serwisów WWW - ktoś jeszcze skleja ręcznie zapytania? "

Tak, jeżeli masz na myśli użycie zamiast tego np. ORM to wiedz, że serwerów VPS i serwerów dedykowanych za darmo nie rozdają. Poza tym, ręcznie sklejane zawsze są konkretne i nietypowych projektach naprawdę przydatne.

tfl   8 #13 15.06.2011 17:37

@Webnull

Oczywiście, że nie. Jednak szansa jest mniejsza, ponieważ jest na to tylko chwila aby wykonać atak przy użyciu GET, POST itp.

Do czego Twoim zdaniem sluzy post i get ?

Ardziej   5 #14 15.06.2011 19:21

@tfl, sprawa oczywista, ale w sumie to nie rozumiem tego, co za różnica, czy ktoś będzie czekał aby w określonej chwili coś wstrzyknąć. to jest absurd, POST i GET służy do przesyłania danych po stronie serwera, z czego postów nie dokleimy tak łatwo jak GETów, poza tym jeszcze odbywa się to po stronie server-side więc nic tu użyszkodnik nie ma do powiedzenia.
Całkowicie nie kumam tego a cache'owaniem, może webnull wyraź się jaśniej :)
Bo jak dla mnie jest to całkowita bzdura, ale broń się, pokaż może nam coś nowego :)

Ryan   15 #15 15.06.2011 23:00

"Oczywiście, że nie. Jednak szansa jest mniejsza, ponieważ jest na to tylko chwila aby wykonać atak przy użyciu GET, POST itp."

Teraz już kompletnie nie rozumiem o czym mówisz. Aktualizacja cache musi się odbywać zawsze, kiedy pojawia się nowa treść. To, czy dzieje się to synchronicznie czy też nie nie ma najmniejszego znaczenia. Wciąż dodawana treść jest niebezpieczna. Twoje rozwiązanie niczego nie rozwiązuje. To nawet nie security by obscurity, bo absolutnie niczego nie zmienia.

DonM$   9 #16 16.06.2011 15:35

O masakra, wszedłem z ciekawości, notka , bo tak to można nazwać, nic nie wyjaśnia, sposób z cache jest groteskowy i nic nie rozwiązuje, tutaj w 100% zgadzam się z Rayn.
A to to już mnie zwaliło z nóg "osobiście uważam, że aby zabezpieczyć aplikację należy użyć czegoś cięższego co odbije się większym zapotrzebowaniem na zasoby".

webnull   9 #17 16.06.2011 16:20

@DonM$ | 16.06.2011 15:35
"A to to już mnie zwaliło z nóg "osobiście uważam, że aby zabezpieczyć aplikację należy użyć czegoś cięższego co odbije się większym zapotrzebowaniem na zasoby"."

Użycie frameworka, dodatkowych klas które będą budować zapytanie jest trochę bardziej zasobożerne niż stworzenie pytania odręcznie.

@Ryan (redakcja) | 15.06.2011 23:00
Przyznaję, że pomyliło mi się coś z tym cachowaniem, wytnę to ostatecznie z wpisu.

DonM$   9 #18 16.06.2011 17:13

No bez przesady, w ogólnym działaniu aplikacji to się rozejdzie po kościach, a napisałeś tak jakby tych zasobów nie wiadomo ile by było potrzeba, po za tym wyjście z założeniem, że jak coś zżera więcej zasobów to jest lepsze, jest bardzo mylne.

"wytnę to ostatecznie z wpisu" - lepiej nie bo nic z tego nie zostanie.

webnull   9 #19 16.06.2011 17:45

@DonM$ | 16.06.2011 17:13
Idź potrollować gdzie indziej.

DonM$   9 #20 16.06.2011 18:55

Oj argumentów zabrakło, jak mi przykro.

webnull   9 #21 16.06.2011 20:02

@DonM$ | 16.06.2011 17:13
Argumentów nie zabrakło, po prostu nie chcę aby rozpętała się tutaj kolejna do niczego nie prowadząca wojna ;-)

  #22 17.06.2011 10:41

Poziom artykułu jak i komentarzy niektórych tragiczny. Idźcie na demony lepiej