Ooprócz zewnętrznych serwisów, wpisów DNS, certyfikatów dla domen – istnieje jeszcze jeden zasób identyfikujący wspólne cechy: domen (firm) i webaplikacji – jest to ulubiona ikonka (ang. favicon.ico). Bardzo dużo firm posiada unikalne loga, które są pomniejszane do ikonek i wyświetlane przy pasku adresu / zakładkach przeglądarki. Zazwyczaj możemy znaleźć je pod adresem: http://domena/favicon.ico chyba, że odpowiednimi tagami HTML wskażemy przeglądarce inną lokalizację. Bardzo wiele z tych ikonek jest unikalnych dla wybranych domen (firm) oraz webaplikacji. Dzięki tej zależności możemy przeszukiwać internet w celu namierzania różnych zasobów powiązanych z daną ikonką.
[ czytaj całość… ]

Z

azwyczaj dla wewnętrznych aplikacji – do uzyskania stałego przypisania IP klienta do puli adresów obsługujących żądania wybieraliśmy profil source_addr z ustawionym czasem wygaśnięcia np. na 3600 sekund. Problem z tego typu rozwiązaniem jest taki, że po wygaśnięciu czasu utrzymania informacji o przypisaniu klienta do wybranego serwera backend’u traciliśmy gwarancję, że zostanie on ponownie przypisany do tego serwera.
[ czytaj całość… ]

I

dentyfikacja rodzaju szyfrowania użytego do ukrycia danej informacji może być czasami irytująca. Aby złamać dany ciąg musimy zorientować się, jaki algorytm szyfrujący został użyty, aby uruchomić odpowiednie narzędzia do jego złamania. Na szczęście jest trochę skryptów, które pomogą nam w identyfikacji: HashTag, Hash Identifier, Hash-Algorithm-Identifier, hashes (.py oraz .txt) oraz hashID.

T

wemproxy (wymawiane „two-em-proxy”) lub nutcracker jest szybkim i lekkim proxy dla protokołów memcached (ascii) oraz redis. Został zbudowany przez programistów z firmy Twitter w celu zredukowania ilości połączeń do serwerów cache znajdujących się w backendzie. Przy dużej ilości serwerów frontowych łączność z warstwą cache lub systemem sesji za pomocą normalnej komunikacji może być bardzo kosztowny.
[ czytaj całość… ]

Z

ałóżmy, że chcemy na naszą aplikację webową nałożyć warstwę cache w celu przyśpieszenia jej działania, zredukowania serwerów front-endowych i odciążenia back-endu. W zależności od skali ruchu sieciowego i wielkości naszej aplikacji – jeden serwer typu proxy cache czasami nie wystarczy. Przyjmijmy, że skala wymaga pięciu serwerów typu cache (wykorzystajmy Varnish’a). Bez sensu jest postawienie przed tymi serwerami urządzenia lub aplikacji do wykonywania load balancingu w trybie round robin, ponieważ spowoduje to powielanie obiektów w pamięci cache serwerów i nieoptymalne ich wykorzystanie.
[ czytaj całość… ]

S

koro już mowa o wielu hasłach na wielu stronach… oczywiście w aspekcie ich łamania oraz stracenia jednego z nich na rzecz, wielu – możemy posłużyć się narzędziem pod postacią rozszerzenia dla przeglądarki Firefox.
[ czytaj całość… ]