Jak wiecie do testów aplikacji webowych używam głównie Fiddlera. Oczywiście korzystam też z innych narzędzi, choćby Burpa, ale jakoś Fiddler wciąż wydaje mi się najwygodniejszy przy analizie/porównywaniu/wyszukiwaniu w zapisanych sesjach. Nawet gdy korzystam z Burpa, to często puszczam go przez Fiddlera (lub przez FiddlerCap do późniejszej analizy), bo tak mi wygodniej.
Od pewnego czasu, czyli od kiedy korzystam z Windows 8, Fiddler przestał mi się prawidłowo zamykać. GUI znikało, ale proces wisiał sobie w najlepsze i oczywiście zajmował również port, w związku z czym ponowne uruchomienie kończyło się błędem (informacja o zajętości portu).
Przez długi czas ignorowałem ten problem i po prostu dobijałem proces, ale w końcu postanowiłem zobaczyć w czym rzecz. Podejrzewałem, że problemem jest jakieś rozszerzenie, typowałem na winnego swój plugin. Okazało się jednak, że winny jest ktoś inny, konkretnie plugin x5s. Problemem są takie dwie linie:
TextWriter w = new StreamWriter(myDoc + @”\My Documents\Fiddler2\Scripts\” + fileName);
TextReader r = new StreamReader(myDoc + @”\My Documents\Fiddler2\Scripts\” + fileName);
W Windows 8 nie ma katalogu My Documents, został zastąpiony przez Documents, więc zapisanie ustawień przy wyjściu kończy się niepowodzeniem i całość wisi. Zastosowałem szybką poprawkę polegającą na stworzeniu hardlinku z My Documents do Documents (narzędzie mklink) i irytujący problem ustąpił.
Vaadin to dość ciekawy framework. Nie miałem z nim zbyt wiele razy do czynienia w sensie projektów polegających na testowaniu aplikacji napisanych z jego wykorzystaniem. Przyznam, że pierwsze zetknięcie (z Vaadin 6.x) było pewnego rodzaju wyzwaniem, głównie z uwagi na jego wyraźnie inną filozofię i mocno ograniczoną powierzchnię ataku.
Jeśli ktoś chce się zapoznać z Vaadin, proponuję przyjrzeć się tej demonstracyjnej aplikacji: http://demo.vaadin.com/sampler/. Wspomniane XSS można poćwiczyć w następujących kontrolkach:
Ja tylko chciałem przypomnieć, że już dawno, dawno temu zwracałem uwagę, że wpuszczanie zewnętrznego kodu do swojego serwisu to potencjalny problem. W tym kontekście “zewnętrzny kod” to kod serwowany z zewnętrznych serwisów.
Czasami można doszukać się rozwiązań technicznych, które odseparują “naszą” treść od tej “obcej” i ograniczą skutki zdarzenia, w którym ten “obcy” kod nagle zacznie robić dziwne rzeczy. Tu warto wspominać o iframe z atrybutem sandbox, może w końcu ta możliwość zacznie być szerzej wykorzystywana. Oczywiście nie w każdym przypadku iframe nadaje się do wykorzystania.
Mam nadzieję, że to zdarzenie (wcale nie wyjątkowe, ale z uwagi na pozycję Niebezpiecznika – dość medialne) zaowocuje podniesieniem świadomości odnośnie tego, że bezpieczeństwo serwisu to nie tylko “jego” kod, ale również kod wszystkich przyległości, z których ten serwis korzysta. Wszelkie reklamy, gadżety społecznościowe, biblioteki programistyczne serwowane z CDN mają/mogą mieć taki sam wpływ na bezpieczeństwo, a atak na nie może okazać się łatwiejszy.
Oryginał tego wpisu dostępny jest pod adresem Się porobiło
mamy urnę w której znajduje się 100 kul, 99 kul czarnych jedna kula biała,
losujemy:
bez zwracania kuli do urny do czasu wylosowania kuli białej,
ze zwracaniem kuli do urny do czasu wylosowania kuli białej,
Jaka jest wartość oczekiwana losowań w pierwszym i w drugim przypadku? Jak zmieni się sytuacja, jeśli w przypadku losowania ze zwracaniem wyciągamy 5 kul, sprawdzamy czy jest wśród nich kula biała i jeśli takiej kuli nie ma – kule są zwracane do urny.
Całość można policzyć, albo wykonać szybką symulację.
P.S. Generator liczb pseudolosowych wykorzystany przy tej symulacji nie musi być kryptograficznie bezpieczny :)
Ostatnio miałem okazję uczestniczyć w Akademii Jakości. Kilka prezentacji podobało mi się bardziej, kilka ciut mniej (ale mimo wszystko oceniam pozytywnie), na dwie prezentacje nie zdążyłem, żałuję przede wszystkim prezentacji Moniki. Na koniec okazało się, że moja prezentacja została bardzo pozytywnie oceniona, za co dziękuję. A w prezentacji tej starałem się pokazać, że testy bezpieczeństwa są ważne, ale niewystarczające, jeśli chcemy w sposób powtarzalny tworzyć “bezpieczne” aplikacje. W sumie chyba nic nowego dla kogoś, kto mojego bloga czyta.
P.S. Była jedna prezentacja, która zainteresowała mnie bardzo (temat), ale trochę rozczarowało wykonanie. Wyglądało to trochę tak, jakby dużo większa prezentacja była “na żywo” przycinana do określonego slotu czasowego. W efekcie czułem spory niedosyt...
Zacząłem odpisywać na komentarz Papiego, ale ostatecznie zdecydowałem się na zrobienie z tego kolejnego wpisu.
Tak, powoli zaczynam się rozglądać za zastępnikiem dla Google Reader. Na razie przyglądam się The Old Reader, wygląda nieźle, aczkolwiek kilku rzeczy mi w nim brakuje. Kolejną alternatywą, nad którą się zastanawiam jest NewsBlur, przy czym oczywiście w wersji płatnej (24$ na rok nie przeraża). Ciekawy jest też ten sugerowany Tiny Tiny RSS, aczkolwiek nie uśmiecha mi się utrzymywanie tej usługi we własnym zakresie. Przyjrzę się temu funkcjonalnie i jeśli mi się spodoba, to byłbym skłonny kupić od kogoś usługę :)
Moje wymagania są dość proste:
muszę mieć możliwość czytania feedów z różnych miejsc i urządzeń (różne laptopy, telefon),
GUI ma być wygodne, a nie nowoczesne/cukierkowe,
powinna być możliwość tagowania wpisów i puszczenia feedu dla określonego tagu,
O rzeczach oczywistych, czyli na przykład o braku limitów na ilość kanałów RSS nawet nie wspominam.
Pamiętacie BEAST? i Lucky13? Te ataki celowały w szyfry blokowe w trybie CBC wykorzystywane w SSL/TLS. Zalecanym “rozwiązaniem” problemu było wykorzystanie szyfru strumieniowego, konkretnie RC4. Co prawda po drodze był jeszcze CRIME, który dobrze się nadawał do atakowania RC4, ale w tym wypadku wystarczyło wyłączyć kompresję.
Aż tu nagle pojawił się problem: Attack of the week: RC4 is kind of broken in TLS. To znaczy problem się nie pojawił nagle, bo o tym, że w wyjściu RC4 (generatora, a nie zaszyfrowanych danych) są pewne “zakłócenia” (niektóre wartości na określonych pozycjach są bardziej prawdopodobne, niż powinny być), wiadomo od dawna. Teraz pokazane zostało, że jeśli atakujący dysponuje wystarczającą ilością próbek, w których ta sama wiadomość jest szyfrowana przy pomocy RC4 z użyciem różnych kluczy, można ustalić jej treść.
Jakiś czas temu pisałem o sposobie na limitowanie liczby żądań generowanych przez klienta: Limitowanie klienta. Chcę na chwilę wrócić do tego tematu w kontekście ochrony przed DoS.
