Łukasz Pilorz

Praca - bezpieczeństwo aplikacji PHP

Łukasz Pilorz — Fri, 27 Jun 2008 16:24:55 +0000

Jeżeli

doskonale znasz popularne metody ataków na serwisy internetowe
biegle programujesz w PHP
pasjonują Cię testy penetracyjne oraz analiza kodu aplikacji webowych

- skontaktuj się ze mną.

A tymczasem, na rozgrzewkę - pierwszej osobie, która poprawnie opisze, w jaki sposób poniższy skrypt broni się przed XSS, i zaprezentuje działające demo (IE7, FF3) w jaki sposób można to zabezpieczenie obejść, przesyłam książkę (do uzgodnienia - ostatnio “Silence on the Wire”):
http://lukasz.pilorz.net/testy/hackme2/

Aktualizacja: irk4z przesłał już rozwiązanie, a kod skryptu wrzuciłem na http://lukasz.pilorz.net/testy/hackme2/index.phps

JS Portscanning + DNS Rebinding

Łukasz Pilorz — Sat, 15 Dec 2007 01:00:06 +0000

DNS Rebinding polega na podmianie adresu IP domeny pomiędzy kolejnymi żądaniami skierowanymi do niej. W ten sposób można uzyskać dostęp na przykład do zasobów sieci lokalnej, w której znajduje się ofiara. W połączeniu z javascriptowym skanowaniem portów i fingerprintingiem aplikacji pozwala stworzyć ciekawe scenariusze ataku. Przykład:

użytkownik łączy się ze stroną http://lukasz.pilorz.net z sieci swojej firmy (w sieci lokalnej ma dostęp do aplikacji phpMyAdmin niedostępnej z zewnątrz, i w związku z tym niechronionej hasłem)
JavaScript sprawdza czy na którymś hoście w sieci lokalnej otwarty jest port 80 (może to być również localhost), a dla otwartych portów próbuje znaleźć popularne aplikacje (ze względu na same-origin JS nie ma dostępu read/write, ale może próbować np. wczytać obrazki ze znanych ścieżek)
po znalezieniu phpMyAdmina, JS w ukrytej ramce otwiera skrypt z domeny dnsrebinding.securityexploits.com
skrypt PHP na dnsrebinding.securityexploits.com zmienia wpis DNS dla tej domeny na adres przekazany mu w parametrze (np. 127.0.0.1)
JS na dnsrebinding.securityexploits.com wykorzystuje LiveConnect do otwarcia socketa do tej samej domeny, ale IP jest już zmienione na adres sieci lokalnej
JS ma teraz pełny dostęp read/write do portu 80 (np. na 127.0.0.1), może dowolnie kształtować żądania HTTP (metody, nagłówki, treść)
JS wczytuje token potrzebny do wykonania ataku CSRF na phpMyAdmina
JS ukryty na http://lukasz.pilorz.net może teraz wykonywać dowolne zapytania SQL na phpMyAdminie w sieci lokalnej ofiary

Oczywiście skrypt może posiadać sygnatury dla większej ilości aplikacji niż tylko phpMyAdmin, i w ten sposób zwiększać szanse powodzenia ataku. Poza CSRF, skaner mógłby też po prostu wczytywać zawartość niechronionych stron w sieci lokalnej i wysyłać na zewnętrzny serwer (we wcześniejszym wyszukaniu odpowiednich adresów może pomóc Fierce). Inne zastosowanie to ominięcie firewalli i lokalny dostęp na przykład do portu 139.

Powyższy scenariusz bazuje na ataku DNS rebinding z wykorzystaniem LiveConnect - ta metoda została już zablokowana, dlatego mogę opublikować praktyczny przykład:
http://lukasz.pilorz.net/testy/dnsrebinding/scanner.phps - skaner w JS
http://lukasz.pilorz.net/testy/dnsrebinding/phpmyadmin_exec.phps - atak DNS rebinding na phpMyAdmina

Więcej informacji można znaleźć w tekstach na których bazowałem tworząc powyższy skrypt:

Kolejna notka (czwarta część cyklu o testach, dotycząca ataków na mechanizmy logowania i zmiany hasła) pojawi się dopiero w Nowym Roku.

Testowanie bezpieczeństwa aplikacji internetowych - część 3: Słowniki wartości testowych

Łukasz Pilorz — Mon, 08 Oct 2007 17:33:03 +0000

Słowniki wartości testowych, zastosowanie Burp Intruder

Podstawowym i najciekawszym elementem testów bezpieczeństwa serwisów internetowych jest symulowanie praktycznych ataków na aplikację. Podobnie jak w przypadku analizy kodu źródłowego, nie istnieje narzędzie, które potrafiłoby całkowicie wyręczyć w tym zadaniu człowieka, jednak bez przynajmniej częściowej automatyzacji trudno byłoby rzetelnie przeprowadzić ten etap testów. W rzeczywistym ataku wystarcza często jedna luka, na znalezienie której nie obowiązują żadne limity czasowe, podczas gdy celem symulacji jest znalezienie wszystkich (w praktyce: większości) błędów w stosunkowo krótkim czasie.

Automatyzacja testów wymaga przygotowania zestawów wartości reprezentujących poszczególne próby ataków. Słowniki takich wartości są częścią wielu współczesnych skanerów aplikacji webowych, jednak ponieważ skanery nie są w stanie określić kontekstu i znaczenia poszczególnych parametrów oraz analizować rezultatów, często bywają niemal bezużyteczne. Proponuję zamiast tego wykorzystać wiedzę o aplikacji zdobytą w trakcie jej analizy i przygotować osobne słowniki dla poszczególnych typów parametrów. Wymaga to oczywiście znacznie więcej czasu niż uruchomienie skanera, ale myślę że warto.

Przykład słownika i jednocześnie zastosowania narzędzia Burp Intruder będzie oparty o parametr wyboru podstrony serwisu. Metoda określenia jego wartości może przybrać różne formy, między innymi:

http://example.com/index.php?id=123
http://example.com/index.php?strona=nazwa_podstrony
http://example.com/index.php?strona=nazwa_podstrony.html
http://example.com/index.php/nazwa_podstrony/
http://example.com/123/
http://example.com/nazwa_postrony/
http://example.com/nazwa_podstrony.html
http://example.com/nazwa_podstrony.php

W pierwszych czterech przypadkach jest w miarę oczywiste, że wybór podstrony bazuje na wartości pewnej zmiennej, w pozostałych jednak trudno powiedzieć, czy nie zostały wykorzystane reguły mod_rewrite. Typowy skaner “zauważy” i sprawdzi prawdopodobnie tylko trzy pierwsze opcje, często nie mamy też pewności jakiego typu podatności jest faktycznie w stanie wykryć.

Spróbujmy wykorzystać Burp Suite do przeprowadzenia własnego zestawu testów. Ustawiamy cel w zakładce intruder->target, a następnie w intruder->position wybieramy typ ataku “sniper” i wstawiamy żądanie HTTP z identyfikatorem podstrony zastąpionym przez §1§, na przykład:
GET /index.php?id=§1§ HTTP/1.1 Host: example.com
(można też wykorzystać odpowiednie żądanie zapisane w spiderze).

Teraz należy uzupełnić listę wartości, które będą wstrzykiwane w miejsce §1§. Proponuję w intruder->payloads wybrać “preset list” z następującym zestawem (najłatwiej jest zapisać go w pliku):
1 2 3 4 0 -1 1' 1" 1%BF 1%C5%BC 1 OR 1=1 1 OR 1=1/* 1||1=1 1||1=1/* 1test 1test.jpg
Listy testowych zawartości plików nie opublikuję w najbliższym czasie, ale w razie uzasadnionej potrzeby jej posiadania zapraszam do kontaktu mailowego (lukasz na pilorz.net).

Luki związane z uploadem są jedną z najprostszych dróg ataku. Można je napotkać w ogromnej ilości niewielkich, amatorskich serwisów, ale czasem także w poważnych projektach. Serwis Secunia zapytany o php upload zwraca ponad 250 wyników, z których znaczna część dotyczy właśnie tego typu błędów.

Prostym przykładem nieprawidłowego zabezpieczenia jest wykorzystanie następującego kodu, który pojawił się na jednym z portali poświęconych programowaniu:
$seg = explode(".", $nazwa_pliku); if($seg[1] == "jpg") {//OK //...

Pozwolę sobie przytoczyć również dwa nieco nietypowe przykłady takich luk (pozwalających na wykonanie własnego kodu PHP) pochodzące sprzed kilku tygodni z serwisów DobraOpcja.pl i Jogger.pl. W pierwszym przypadku walidacja typu/rozszerzenia pliku odbywała się wyłącznie we Flashu, po stronie przeglądarki. Zagrożenia wynikające z zastosowania technologii Flash są bardzo podobne (a w przypadku XSS nawet większe) do powszechnie znanych problemów związanych z JavaScriptem. Forma, w jakiej występują pliki SWF, może sprawiać wrażenie utrudnienia przy ataku, ale przechwycenie i modyfikacja żądań HTTP wysyłanych przez Flash jest równie prosta, jak dla XMLHttpRequest w skryptach JavaScript (jedyna różnica: w systemie Windows należy ustawić Burp Proxy dla Internet Explorera, a nie przeglądarki z której korzystamy).

Inna sytuacja miała miejsce w Joggerze, który znany jest z solidnych zabezpieczeń oraz dużej grupy użytkowników interesujących się bezpieczeństwem aplikacji internetowych. Mechanizm uploadu plików w tym serwisie posiadał ograniczenie na dopuszczalne rozszerzenia, a także przewidywał możliwość wstrzyknięcia bajtu zerowego w nazwie, jednak w wyniku prostego błędu programistycznego warunek ten nie był w pełni egzekwowany. W efekcie możliwa była zmiana nazwy pliku na zawierającą bajt zerowy i wstawienie dowolnego rozszerzenia pliku. Nawet najlepszym zdarzają się pomyłki, dlatego istotne jest by kluczowe funkcje były testowane z wykorzystaniem możliwie pełnego słownika.

Ciąg dalszy wkrótce.

Dziękuję Robertowi Wróblowi za uzupełnienie listy nazw plików oraz materiały do tej i kolejnych części tekstu.

Rails 2.0: wbudowana ochrona przed CSRF

Łukasz Pilorz — Sun, 07 Oct 2007 08:39:41 +0000

Niedawno narzekałem na RoR, a tymczasem w Rails 2.0 formularze są domyślnie chronione przed CSRF, zmienił się filtr zapobiegający XSS oraz dodano obsługę ciasteczek HTTPonly. Zwłaszcza pierwsza z tych zmian może znacznie zwiększyć bezpieczeństwo aplikacji. Polecam też Ruby on Rails Security Cheatsheet.

Jeśli ktoś czeka na trzecią część tekstu o testowaniu bezpieczeństwa aplikacji internetowych, to uspokajam: jest gotowa i czeka tylko na odpowiedź jednego ze wspomnianych w niej serwisów.

Czarny tydzień Google

Łukasz Pilorz — Sat, 29 Sep 2007 17:01:06 +0000

W tym tygodniu padło na Google. W ciągu kilku dni opublikowane zostały informacje o pięciu lukach w aplikacjach tej firmy. Z ciekawości wyszukałem informacje o podobnych zgłoszeniach w tym roku:

09/2007
http://sirdarckcat.blogspot.com/2007/09/google-mashups-vulnerability.html
http://xs-sniper.com/blog/2007/09/28/all-your-google-docs-are-belong-to-us/
http://www.thespanner.co.uk/2007/09/27/google-adsense-csrf-hole/
http://hackademix.net/2007/09/24/googhole-xss-pwning-gmail-picasa-and-almost-200k-customers/
http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/
http://blog.beford.org/?p=3
http://websecurity.com.ua/1368/
http://sla.ckers.org/forum/read.php?3,15534,15534

08/2007
http://ha.ckers.org/blog/20070817/xss-hole-in-google-apps-is-expected-behavior/
http://sla.ckers.org/forum/read.php?4,15136,15136

06/2007
http://websecurity.com.ua/1049/

05/2007
http://www.0×000000.com/index.php?i=319
http://www.earlofgrey.com/blog/major-google-security-flaw-to-remove-sites-from-the-index.html

04/2007
http://sla.ckers.org/forum/read.php?2,10960

03/2007
http://mybeni.rootzilla.de/mybeNi/2007/gmail_information_disclosure/

02/2007
http://www.watchfire.com/news/releases/02-21-07.aspx
http://ha.ckers.org/blog/20070222/google-desktop-the-saga-continues/
http://sla.ckers.org/forum/read.php?2,6505,6562
http://sla.ckers.org/forum/read.php?3,44,page=40#msg-7125
http://sla.ckers.org/forum/read.php?3,44,page=40#msg-7126

01/2007
http://googlified.com/2007follow-up-on-the-gmail-bug/
http://blogoscoped.com/archive/2007-01-14-n21.html

Czy jest to powód do unikania produktów Google? Jeżeli nawet tak, to nie ze względu na powyższe błędy (które były łatane w błyskawicznym tempie), ale raczej dlatego, że stają się one aplikacjami powszechnego użytku - a popularność często oznacza większe ryzyko ataku.

Testowanie bezpieczeństwa aplikacji internetowych - część 2: Analiza funkcjonalności aplikacji

Łukasz Pilorz — Mon, 24 Sep 2007 19:45:22 +0000

Tematem tej części można byłoby pewnie wypełnić książkę, tutaj ograniczę się do bardzo skrótowego ujęcia. Analiza funkcjonalności polegać będzie na skatalogowaniu akcji dostępnych w serwisie, a następnie określeniu zagrożeń, które z nich wynikają. Na tym etapie proponuję też wskazać fragmenty aplikacji, dla których należy sprawdzić istnienie typowych błędów.

Zarówno ten etap, jak i kolejne, najwygodniej będzie wykonywać przy pomocy przeglądarki internetowej (np. Firefox z rozszerzeniami: Firebug, Live HTTP Headers, Modify Headers i Edit Cookies) w połączeniu z Burp Suite lub podobnym narzędziem. Szczególnie polecam Burp Proxy, który pozwala modyfikować “w locie” dane przesyłane pomiędzy przeglądarką i serwerem. Po uruchomieniu Burp Suite należy ustawić w przeglądarce proxy localhost:8080, proponuję też przełączyć działanie Burp Proxy na “intercept off” i włączyć przechwytywanie dopiero przy następnych testach.

Podczas przeglądania przez nas testowanej aplikacji Burp Suite będzie na bieżąco aktualizował listę znalezionych podstron/linków, którą później można przejrzeć w zakładce spider->run->”show results”. W połączeniu z danymi uzyskanymi wcześniej z Wfuzz powinniśmy mieć w ten sposób w miarę dobry obraz struktury plików w aplikacji.

W trakcie tego etapu proponuję “przeklikać” aplikację kilkukrotnie, za każdym razem zmieniając nieco ustawienia przeglądarki:

ze standardowymi ustawieniami
z wyłączoną obsługą JavaScript
z wyłączonym nagłówkiem Referer (w rozszerzeniu Modify Headers do Firefoksa reguła “Filter”:”Referer”:”")

Powyższy krok może pomóc w szybkim wykryciu brakującej walidacji po stronie serwera (realizowanej tylko skryptami JavaScript) oraz zabezpieczeń bazujących na adresie strony odsyłającej.

Załóżmy, że testowany serwis zawiera następujący zestaw funkcji (do nich będę się odnosił również w następnych częściach):

wyświetlenie podstrony o zadanym identyfikatorze
wyszukiwanie
rejestracja użytkownika
logowanie/wylogowanie użytkownika
mechanizm odzyskiwania zapomnianego hasła
zmiana hasła, adresu e-mail i innych danych użytkownika, usuwanie konta
edycja tekstu/HTML (notka w serwisie blogowym, komentarz w sklepie internetowym, itp.)
upload plików (np. grafiki)
przesyłanie wiadomości pomiędzy użytkownikami/do obsługi serwisu/na adres e-mail

Za elementy z natury niebezpieczne uznałbym możliwość edycji HTML (persistent XSS, CSRF, phishing), możliwość przesyłania e-maili (spam, phishing), upload plików (kod wykonywalny, persistent XSS, phishing) oraz mechanizm odzyskiwania zapomnianego hasła. Analiza tych funkcji serwisu będzie zatem bardziej złożona - w trakcie testów powinniśmy sprawdzić, jakie zostały wprowadzone zabezpieczenia, ocenić ich skuteczność i ewentualnie zaproponować alternatywne rozwiązania. Pozostałe z dostępnych akcji nie powinny mieć wpływu na bezpieczeństwo, o ile nie zawierają błędu programistycznego - a więc ich testy sprowadzą się do sprawdzenia typowych problemów (reflected XSS, CSRF, SQLI, header injection, path traversal, session fixation, integer overflow, itd.).

Najtrudniejsze do wykrycia są zazwyczaj błędy w logice aplikacji. Ponieważ są one ściśle powiązane z zastosowaniem serwisu, nie można ich znaleźć przy pomocy skanerów i wymagają przygotowania osobnego zestawu testów praktycznie dla każdej funkcji. Do ataków wykorzystujących błędy logiczne zalicza się między innymi parameter tampering i forceful browsing, ale zakres tego typu problemów może być bardzo szeroki. Przykładem może być sytuacja, w której wieloetapowy mechanizm odzyskiwania hasła nie bierze pod uwagę zmian danych użytkowników jakie nastąpiły pomiędzy etapami, w wyniku czego na adres atakującego może być przesłany link do zmiany hasła innego użytkownika.

Przy okazji polowań na błędy w logice serwisu można też spróbować określić, jakie działania użytkownika nie powinny mieć miejsca w określonych sytuacjach, nawet jeśli nie mają wpływu na bezpieczeństwo. Przykład: wykorzystanie przypomnienia hasła w momencie, gdy użytkownik jest zalogowany. Zwykle nie ma powodu, by blokować takie zachowanie (wyjątek: ataki XSS/CSRF), jednak jest ono nieco podejrzane, i w związku z tym można do istniejących mechanizmów ostrzegania dodać alert dla tej sytuacji. Wprowadzenie większej ilości takich punktów kontrolnych może ułatwić odpowiednio wczesne wykrywanie nietypowych (a więc zwykle niechcianych) działań użytkowników - to już oczywiście zadanie dla programistów i administratorów serwisu, ale testerzy mogą mieć ciekawe pomysły, które warto zapisać.

Proponuję wrócić teraz do Burp Suite i zwrócić uwagę na możliwości narzędzi Repeater oraz Intruder. Jednym z elementów testu bezpieczeństwa powinno być sprawdzenie, czy zasoby dostępne wyłącznie dla zalogowanych użytkowników rzeczywiście są chronione. W tym celu wylogujemy się z aplikacji, a następnie w zakladce spider->run->”show results” wybierzemy interesujący nas plik. Po kliknięciu prawym klawiszem wybieramy “send request to repeater”, po czym przechodzimy do podświetlonej na czerwono zakładki. W polu tekstowym widoczne jest żądanie HTTP, które przeglądarka wykonała podczas legalnego dostępu do danej strony. Wybierając przycisk “go” powtórzymy to żądanie, a w dolnym okienku pojawi się odpowiedź serwera, która powinna wskazywać odmowę dostępu do strony (np. komunikat, przekierowanie do strony logowania, formularz logowania).

Burp Intruder przedstawię już w następnej części tego tekstu (na przykładzie próby ataku na parametr określający wybór podstrony serwisu). Trzecia część będzie też zawierać informacje o atakach wykorzystujących upload plików.

Testowanie bezpieczeństwa aplikacji internetowych - część 1: Identyfikacja dostępnych zasobów

Łukasz Pilorz — Sat, 15 Sep 2007 03:57:22 +0000

Przez ostatnie tygodnie w wolnych chwilach starałem się uporządkować swoje notatki o testach serwisów internetowych - jako efekt uboczny powstał ten wpis.

Tekst dotyczy przede wszystkim typowych aplikacji tworzonych w PHP: CMS-ów, serwisów społecznościowych i informacyjnych, BIP-ów, sklepów internetowych. Takie serwisy nie wymagają zabezpieczeń na poziomie bankowości elektronicznej. Najczęściej wystarczające są testy przeprowadzone przez programistów lub inżynierów QA, i mam nadzieję, że właśnie im przyda się poniższa lista. Zainteresowanych ogólniejszą i pełniejszą wiedzą odsyłam na strony OWASP

Identyfikacja dostępnych zasobów

Jako pierwszy etap proponuję przeprowadzenie rozpoznania, jakie informacje o aplikacji jest w stanie zebrać osoba z zewnątrz. Do tego celu najprościej jest wykorzystać typowe narzędzia, ale odrobina “twórczości własnej” też może się przydać. Przykładowy zestaw:

Fierce - to narzędzie jest przeznaczone do przeszukiwania zasobów sieci korporacyjnych, ale sprawdza się też przy małych serwisach. Metodą brute-force znajduje subdomeny, a następnie przeszukuje okoliczne IP w poszukiwaniu zasobów powiązanych z tą samą firmą:
perl fierce.pl -dns example.com -search nazwa,firmy,i,inne,slowa,kluczowe
Przykładowy wynik można obejrzeć tutaj. Podobna funkcja jest wbudowana w skaner Acunetix WVS (również w darmowej wersji).

Znajomość programu Nmap jest obowiązkowa dla administratorów, ale przy rekonesansie przydaje się również w testach aplikacji WWW. Do określenia celu można wykorzystać wyniki z Fierce, a skan wystarczy ograniczyć do portów typowych dla protokołu HTTP:
nmap -v -P0 -sV -p T:80,443,8080 example.com

Zadaniem Nessusa jest zweryfikowanie podatności systemu na podstawie bogatej listy sygnatur. Ten skaner nie wykryje błędów w napisanych przez nas aplikacjach, ale zastosowanie się do jego wskazówek pomoże między innymi w obronie przed robakami internetowymi oraz script kiddies. Dodatkowa funkcja, o której dokumentacja milczy, to wykrywanie nieodpowiednio zorganizowanych powiadomień o atakach na serwis - sygnaturą jest (dobiegający zwykle z pokoju obok) charakterystyczny krzyk osoby, której skrzynka pocztowa została zalana setkami alertów.
Przed użyciem Nessusa w środowisku produkcyjnym należy koniecznie analogiczny skan przeprowadzić przeciwko serwerowi testowemu, na którym uruchomione są te same aplikacje (możliwie wierna kopia) - w przeciwnym razie konsekwencje mogą być trudne do przewidzenia.

W kolejnym kroku proponuję powrócić do wyników uzyskanych przy pomocy Fierce oraz Nmapa, i tym razem wyszukać dostępne w znalezionych domenach katalogi/pliki. Do tego celu świetnie nadaje się Wfuzz - narzędzie do przeprowadzania ataków brute-force na aplikacje internetowe. Jego możliwości są znacznie większe niż wyszukiwanie, ale na tym etapie wystarczy ograniczyć się do poniższych poleceń:
./wfuzz.py -c -z file -f slownik.txt --hc 404 http://example.com/FUZZ/
./wfuzz.py -c -z file -f slownik.txt --hc 404 http://example.com/FUZZ.php
Do określenia rozszerzeń plików, których będziemy szukać, może się przydać metoda, którą opisałem tutaj.

Na koniec pozostaje metoda, w której można się wykazać własną inicjatywą, czyli Google Hacking. Poza wykorzystaniem Google Hacking Database, można podsumować informacje ze skanerów, i na tej podstawie próbować nowych sztuczek. Poniżej zamieszczam kilka googledorków, które kiedyś okazały się dla mnie przydatne:

site:example.com intitle:”Index of /” modified
site:example.com intitle:phpinfo
site:example.com filetype:php inurl:upload
site:example.com filetype:php inurl:file
site:example.com inurl:config
site:example.com filetype:inc config
site:example.com inurl:admin

Ciąg dalszy wkrótce (część 2: Analiza funkcjonalności aplikacji). Komentarze i propozycje poprawek mile widziane - tutaj lub mailowo.

Directory Traversal w Total Commanderze

Łukasz Pilorz — Wed, 12 Sep 2007 18:13:56 +0000

Kilka dni temu na secunia.com pojawiła się informacja o Total Commander FTP Download Directory Traversal Vulnerability. Jak widać, problemy ze wstrzykiwaniem ścieżki do pliku nie dotyczą tylko aplikacji internetowych. Przykład w wersji dla korzystających z klasycznego hostingu PHP + FTP, bez możliwości utworzenia pliku inną drogą:

touch("./..\\..\\..\\..\\..\\..\\Windows\\system32\\drivers\\etc\\hosts"); ?>

Plik wrzucamy (za pomocą FTP) do katalogu w którym PHP ma prawa do zapisu plików, odpalamy z przeglądarki, i odświeżamy widok katalogu FTP w Total Commanderze. Pojawi się niewinnie wyglądający plik hosts (cała reszta nazwy jest niewidoczna), który możemy spróbować skopiować do jakiegoś katalogu na dysku C:\.

Efekt:

Target already exists: C:\Windows\system32\drivers\etc\hosts Do you want to overwrite it?

Google Hacking: wyszukiwanie nietypowych plików

Łukasz Pilorz — Mon, 03 Sep 2007 18:25:29 +0000

Metoda na wyszukiwanie nietypowych zasobów w określonej domenie:
site:example.com filetype:* -filetype:htm -filetype:html

Na pierwszej stronie wyników pojawia się zazwyczaj sporo plików .php, więc te również można usunąć:
site:example.com filetype:* -filetype:htm -filetype:html -filetype:php

Jeśli teraz w wynikach przeważają pliki pdf, wówczas:
site:example.com filetype:* -filetype:htm -filetype:html -filetype:php -filetype:pdf
…i tak dalej.

Nic rewolucyjnego, ale efekty są czasem ciekawe.

Framework niekoniecznie bezpieczniejszy

Łukasz Pilorz — Sun, 19 Aug 2007 03:32:38 +0000

Wielokrotnie słyszałem opinię, że korzystanie z gotowych frameworków PHP rozwiązuje podstawowe problemy z bezpieczeństwem aplikacji. Jest w niej dużo racji, zwłaszcza jeśli chodzi o proste projekty tworzone przez niekoniecznie zaawansowanych programistów. Trzeba jednak pamiętać, że wykorzystanie obcego kodu wiąże się z jego jawnością dla potencjalnych atakujących, oraz że nie każdy framework jest tworzony z myślą o bezpieczeństwie.

Nie korzystam na co dzień z takich rozwiązań, zetknąłem się jedynie z Cake, Symfony i CodeIgniter - a okazję, by przyjrzeć się dokładniej, miałem tylko przy tym ostatnim. Z trzech wspomnianych CodeIgniter jest zresztą (moim zdaniem) najbardziej czytelny i najłatwiejszy do analizy. Efektem tego przeglądu było kilka poprawek, które trafiły do wersji 1.5.4.

W trakcie bardzo krótkiej korespondencji na temat zgłoszeń odniosłem wrażenie, że twórcy CodeIgnitera nie przypisują frameworkowi odpowiedzialności za bezpieczeństwo aplikacji. Ma on być ułatwieniem, ale programista nadal musi sam wprowadzić odpowiednie dla danej funkcjonalności zabezpieczenia. Ciekaw jestem, czy to podejście jest podobne w przypadku innych popularnych frameworków. Tak czy inaczej, warto przeanalizować taki kod przed zastosowaniem w poważniejszym projekcie.