Kolejny odcinek serii o tym czego NIE należy robić w trakcie tworzenia aplikacji internetowych. Tym razem o tym, dlaczego nie należy wstawiać zmiennych przekazywanych przez użytkownika bezpośrednio do skryptów JavaScript.
A w zasadzie to “nie wszystko żmija, co pełza”. Fakt, węży pojawia się czasami dość sporo, teraz podobno jest znowu ich “wysyp”, w tym wysyp żmij właśnie. Problem w tym, że żmija to nie jedyne pełzające stworzenie w naszym kraju... Sam kiedyś widziałem jak spokojnie płynący sobie zaskroniec (w Wetlinie) wywołał panikę ludzi stojących na moście i dzikie wrzaski “żmija, żmija”. Nawet jeśli byłaby to żmija, to co ona miała zrobić? Skoczyć 5 metrów do góry i rzucić się do gardła jak królik morderca?
Warto popatrzeć jak wygląda:
Jak stwierdził Tomek, temat SQL Injection jest tematem dyżurnym na moim blogu. To nie do końca tak, temat ten nie zajmowałby tyle miejsca, gdyby nie był dyżurnym błędem wielu developerów, których produkty następnie przychodzi mi testować. W każdym razie dla porządku jeszcze ja wymienię te narzędzia:
Jakiś czas temu pisałem o pojawieniu się nowego narzędzia – F-Response. Wówczas mogłem napisać o nim jedynie na podstawie opinii innych ludzi, tak się jednak stało, że dostałem do testów F-Response Enterprise Edition.
Jakiś czas temu pojawiły się informacje o ataku na klientów PKO BP, informacja dostępna jest na przykład tu: Klienci PKO BP – uwaga na cyberoszustów. Tradycyjnie przyczepię się do kwestii merytorycznych zawartych w tym artykule.
Jakby ktoś jeszcze nie wiedział, to w końcu jest dostępna finalna wersja BackTrack 3.
We wtorek swoją premierę miał Firefox 3. W jednej wypowiedzi Window Snyder powiedziała:
In setting out to elevate Firefox's basic security, Snyder is also compelling Microsoft and Apple, maker of the Safari browser, to follow her lead — or get out of the way.
Snyder's rising star is sure to ascend even more this week, with the release of Version 3.0 of Firefox on Tuesday. The release is packed with new features, most notably stiffer security, faster speed and improved ease of use.
Panią Snyder uważam za kompetentną osobę, choćby z uwagi na książkę Threat Modeling , ale ta wypowiedź wybitnie jej nie wyszła...
Ostatnimi czasy było głośno o nowej wersji GPCode. Było głośno po części z uwagi na inicjatywę firmy Kaspersky, która to inicjatywa miała (przynajmniej według masowych doniesień) na celu złamanie klucza RSA wykorzystywanego przy szyfrowaniu plików. O tym, że jest to, delikatnie mówiąc, naiwne podejście pisał Schneier, a i inne wątpliwości były zgłaszane w tym temacie. Ponieważ ostatnio trochę czasu spędziłem ze Sleuthkit (i podobnymi) w ręku, zastanawiałem się, czy GPCode czyści zawartość oryginalnego pliku po jego zaszyfrowaniu. Okazuje się, że nie. Swoją drogą Robert Hensing wskazał na ciekawą nową funkcję w Windows Vista i Windows 2008.
Jednym z elementów analizy systemu (po incydencie) jest analiza pamięci fizycznej. Problemem jest oczywiście zdobycie obrazu tej pamięci. Kiedyś można było zdobyć go bezpośrednio nawet za pomocą narzędzia dd przy czym a samą pamięć można było odczytywać z \Device\PhysicalMemory. To się jednak zmieniło. W ostatnich dniach pojawiło się jednak kilka narzędzi, które na uzyskanie obrazu pamięci pozwalają.
Tak jak pisałem z debuggerem nie czuję się jakoś specjalnie zaprzyjaźniony. Jest jednak narzędzie, które może być pomocne w odkryciu tego, w jaki sposób proces explorer.exe jest infekowany przez malware. Narzędzie to jest częścią pakietu Debugging Tools For Windows i nazywa się Logger.