http://lukasz.pilorz.net Sat, 28 Jun 2008 09:53:26 +0000 http://backend.userland.com/rss092 en 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 ... http://lukasz.pilorz.net/2008/06/27/praca-bezpieczenstwo-aplikacji-php/ 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/2007/12/15/js-portscanning-dns-rebinding/ 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 ... http://lukasz.pilorz.net/2007/10/08/testowanie-bezpieczenstwa-aplikacji-internetowych-czesc-3-slowniki-wartosci-testowych/ 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 ... http://lukasz.pilorz.net/2007/10/07/rails-20-wbudowana-ochrona-przed-csrf/ 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.0x000000.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 ... http://lukasz.pilorz.net/2007/09/29/czarny-tydzien-google/ 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, ... http://lukasz.pilorz.net/2007/09/24/testowanie-bezpieczenstwa-aplikacji-internetowych-czesc-2-analiza-funkcjonalnosci-aplikacji/ 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ą ... http://lukasz.pilorz.net/2007/09/15/testowanie-bezpieczenstwa-aplikacji-internetowych-czesc-1-identyfikacja-dostepnych-zasobow/ 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ą: <?php touch("./..\\..\\..\\..\\..\\..\\Windows\\system32\\drivers\\etc\\hosts"); ?> Plik wrzucamy (za pomocą FTP) ... http://lukasz.pilorz.net/2007/09/12/directory-traversal-w-total-commanderze/ 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. http://lukasz.pilorz.net/2007/09/03/google-hacking-wyszukiwanie-nietypowych-plikow/ 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 ... http://lukasz.pilorz.net/2007/08/19/framework-niekoniecznie-bezpieczniejszy/