W Computerworld ukazał się artykuł Bezpiecznie jak w banku. Wspominam o nim tylko dlatego, że z wdrożeniem systemu zarządzania tożsamością miałem “trochę” wspólnego (choć uważam, że można było to zrobić lepiej). Pozdrowienia dla koleżanek i kolegów, którzy pomagali w tym całym zamieszaniu, a teraz muszą z tym systemem żyć :)
Niezwłocznie po ustaleniu przyczyny problemu (czyli po tym, jak się upomniałem) otrzymałem wyczerpujące wyjaśnienie podnoszonej przeze mnie kwestii. Przypomnę: chodziło o otrzymanie przeze mnie mailingu rozsyłanego przez Pracuj.pl na zlecenie Profeo.pl mimo wcześniejszego usunięcia przeze mnie konta. Cytuję: Wskutek czasowego błędu baza danych w tym okresie nie została zaktualizowana, dlatego otrzymał Pan mailing po skasowaniu konta. Błąd został już naprawiony a baza zaktualizowana i Pana dane zostały całkowicie usunięte z systemu. Czy potrzebny jest jakiś komentarz?
Podpis elektroniczny jest jednym ze sposobów autoryzacji transakcji w bankowości internetowej (lub ogólnie – metodą potwierdzania operacji), ale również mechanizm ten jest wykorzystywany przy niektórych schematach uwierzytelnienia. Niby prosta rzecz, ale bywa implementowana źle.
W ciągu ostatniego miesiąca wpis Nasza Klasa na celowniku został otwarty (bo nie będę twierdził, że przeczytany) ponad 9 tysięcy razy(!). To mi podsuwa pomysł na pewien eksperyment...
Bardzo ciekawe i dogłębne analizy:
...kiedy w końcu zrobi się wiosna? Już mnie nosi :)
Pisałem ostatnio o trust boundary i przy okazji pokazałem diagramy DFD, które są wykorzystywane przy modelowaniu zagrożeń. Dla uzupełnienia w takim razie coś o podejściu STRIDE per element.
Jest sobie zapytanie SQL typu: SELECT DISTINCT * FROM tabela ORDER BY kolumna. Atakujący kontroluje parametr kolumna , baza to MS SQL. “Klasyczny” atak nie zadziała właśnie z powodu owego DISTINCT, przy próbie pojawi się błąd: ORDER BY items must appear in the select list if SELECT DISTINCT is specified. Jest to przykład ewidentnego błędu CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection'), niezależnie od tego, czy w tym konkretnym przypadku pozwala to na atak metodą sql injection , czy nie.
Oryginał tego wpisu dostępny jest pod adresem DISTINCT i ORDER BY
Autor: Paweł Goleń
Dziś miała miejsce premiera Internet Explorer 8. Choć moją podstawową przeglądarką jest Firefox, to do pracy (testów) używam głównie IE. Po prostu część aplikacji, które testuję działają poprawnie tylko w tej przeglądarce. W nowej wersji podoba mi się nowy debugger JavaScript oraz wbudowane narzędzia developerskie. Bardzo przydatne przy testach.
Nie, nie moje. Swoją drogą od kiedy zmieniłem ISP, wyłączyłem również swojego honeypotta. Po prostu ISP domyślnie chroni klientów przed atakami (filtrowanie “ulubionych” portów malware). Wracając do zrzutów pamięci, na blogu Forensic Incident Response pojawiły się dwa wpisy:
W skrócie – udostępniane są obrazy pamięci systemu z aktywnym malware. W sam raz materiał testowy by zaprzyjaźnić się z Memoryze , Volatility (patrz: tools) czy próbować uruchomić RegRipper na obrazie pamięci.
Pojęcie Trust Boundary (czasem też Security Boundary) jest wykorzystywane w celu określenia różnych “poziomów zaufania” w aplikacji. Jeśli coś przekracza trust boundary (w szczególności “wchodzi do środka”) musi być traktowane jako niezaufane.