Mój niedawny eksperyment dotyczył pojemności pamięci krótkotrwałej. Pojemność tej pamięci jest znana i wynosi 7 elementów +/- 2. Chciałem zweryfikować, czy informacje, które można wyczytać w mądrych książkach, są zgodne z rzeczywistością. Ten sam eksperyment przeprowadzony 20 lat temu i dziś wcale nie musi dać takich samych rezultatów. Są badania, z których wynika, że wśród obecnych 11-12 latków pewne zdolności kognitywne rozwijają się o 2-3 lata później, niż miało to miejsce 15 lat temu (Children are less able than they used to be). Co prawda oczekiwano zmiany, ale raczej w drugim kierunku. Inny przykład: Psychologia biznesu: Jak reklamy wabią dzieci? (20.02) i fragmenty o "wymiataniu neuronów". Przez otaczającą nas rzeczywistość nasze mózgi kształtują się inaczej, niż kiedyś. No i w zasadzie po co nam pamięć krótkotrwała, skoro mamy cut, copy and paste?
Ciąg dalszy "Wyniki eksperymentu: ile cyfr jesteś w stanie..." »Monday, February 28. 2011
Friday, February 25. 2011
Bootcamp XXV - hint II
Kolejne wskazówki/zadanie związane z bootcamp XXV. W tej części wskazówek udostępniony jest plik z zapisem sesji HTTP. Zadanie polega na przeanalizowaniu odpowiedzi serwera na poszczególne zapytania i identyfikacji na tej podstawie miejsc, w których należy się spodziewać sql injection. Więcej informacji: Wyzwanie V - wskazówki, część druga.
Wednesday, February 23. 2011
Principles of Security Usability
Truizmem jest stwierdzenie, że człowiek jest najsłabszym ogniwem (bezpieczeństwa). Wydaje mi się, że za mało czasu poświęca się temu, by odpowiedzieć na pytanie dlaczego tak właśnie jest. Człowiek jest (tylko) człowiekiem, jest przez to "ograniczony". Ograniczony przez tysiące lat ewolucji, które w pewien sposób nas ukształtowały. Uważam, że z czasów, gdy nasi przodkowie musieli walczyć o przetrwanie, pożywienie i sukces reprodukcyjny, zostało w naszym zachowaniu dużo więcej, niż chcemy się do tego przyznać. Są też inne, prostsze(?), zagadnienia z psychologii, które mogą przydać się przy projektowaniu mechanizmów bezpieczeństwa. Używalnych mechanizmów bezpieczeństwa, cokolwiek to znaczy.
Ciąg dalszy "Principles of Security Usability" »Monday, February 21. 2011
Uczmy się na CUDZYCH błędach: HBGary hack
Ciekawa lektura: Anonymous speaks: the inside story of the HBGary hack. Warto przeczytać i zobaczyć jak wiele "małych" błędów prowadzi do całkiem sporej wtopy. A błędy były proste i typowe:
- wykorzystanie "autorskiego", podatnego na SQL injection CMS (a sql injection to nie jest wiedza tajemna),
- przechowywanie haseł w postaci łatwej do złamania (patrz też: O przechowywaniu haseł, Coś mocniejszego niż MD5, Are you sure SHA-1+salt is enough for passwords?),
- wykorzystywanie jednego hasła w wielu miejscach (patrz też: I dlatego warto mieć jedno hasło..., Jak korzystam z KeePass),
- podatność na social engineering (oczywista oczywistość: The Art of Deception: Controlling the Human Element of Security),
- używanie oprogramowania, które zawiera znane podatności,
W tej chwili zamiast się dowartościowywać wymyślając przemyślne epitety mające oddać brak profesjonalizmu ofiar ataku, lepiej zastanowić się, czy my sami się przed takim scenariuszem dobrze bronimy. To jak z tym jest?
Dla przypomnienia inna historia: Uczmy się na błędach: apache.org incident report. Znajdź części wspólne na tych obrazkach :)
UPDATE: W tym samym temacie HBGary hack: lessons learned.
Friday, February 18. 2011
Prośba o pomoc: zmarnuj trochę czasu
Jeśli ktoś z czytelników ma trochę czasu do zmarnowania(?), to może niech go marnuje produktywnie. No, produktywnie przynajmniej dla mnie :) Chcę przeprowadzić pewien eksperyment, Wasz udział bardzo mi w tym pomoże.
O co chodzi? Przygotowałem prostą aplikację, która wyświetla przez kilka sekund kilka cyfr. Następnie te cyfry znikają, natomiast pojawia się pole do ich wpisania. Zadanie jest proste - spróbować przepisać wyświetlone wcześniej cyfry, lub przynajmniej tyle, ile udało się zapamiętać. Ilość wyświetlanych cyfr waha się od 3 do 10, czas ich wyświetlania zależy natomiast od ich ilości (sekunda na każdą cyfrę).
Przykład ten znajduje się pod adresem http://bootcamp.threats.pl/e/test01.php (wymaga włączonej obsługi JavaScript) i nie jest elementem mojego przewodnika po bezpieczeństwie aplikacji internetowych, więc proszę go nie hakować. Przykłady z przewodnika hakować oczywiście można :)