Wampiryczny blog

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:

• Label,
• CustomLaylout,
• RichTextArea,

Dodatkowo uwagę trzeba zwrócić na:

• tooltipy,
• notyfikacje,

A najlepiej zacząć od tego: 11.8.1. Sanitizing User Input to Prevent Cross-Site Scripting.

Na początek dwa materiały poglądowe:

• Niebezpiecznik: Mogło być gorzej, czyli zastanów się do których skryptów się odwołujesz,
• pi3 blog: Niebezpiecznik.pl hacked,

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.

Wyobraźmy sobie taką sytuację:

• mamy urnę w której znajduje się 100 kul, 99 kul czarnych jedna kula biała,
• losujemy:
  1. bez zwracania kuli do urny do czasu wylosowania kuli białej,
  2. 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 :)