Technologiczne, Gadżety, Telefony Komórkowe, Pobieranie Aplikacji!

Wprowadzenie do łatania

Dobrze znanym problemem w branży hostingowej jest zarządzanie bezpieczeństwem stron internetowych należących do użytkowników końcowych i zarządzanych przez nich. Podczas gdy dostawca hostingu ma pełne prawo głosu w swoich systemach, musi ostatecznie przyznać zarządzanie przestrzenią hostingową tym, którzy jej używają. Niestety, znaczna część użytkowników końcowych nie ma czasu, zasobów ani ochoty, aby właściwie utrzymywać swój kod lub aplikacje. Jest to szczególnie zauważalne w przypadku aplikacji CMS, które nadal mają tendencję do pozostawania w tyle za najnowszymi wersjami.

Patchman oferuje rozwiązanie tego problemu automatyczne testowanie poprawek lub automatyzując proces wyszukiwania i korygowania luk w przestarzałych aplikacjach CMS w całej infrastrukturze hostingowej. Gdy przestarzała aplikacja zawiera lukę, Patchman wykryje ją i załata w kodzie, czyniąc przestarzałą aplikację, dla której udostępnia poprawki, tak bezpieczną jak najnowsza wersja.

Jednak osiągnięcie tego nie jest trywialne. Patchman skanuje tysiące plików dla swoich klientów, a Patches może mieć znaczący zasięg i wpływ; nawet pół miliona witryn na jedną lukę w zabezpieczeniach dla większych aplikacji, takich jak WordPress — a to nadal jest tylko ułamek całkowitej liczby witryn chronionych przez rozwiązanie Patchman.

Z tego wynika, że ​​właściwe testowanie i QA są absolutnie niezbędne i stanowią priorytet numer jeden dla naszego zespołu badawczego, gdy tworzona jest nowa poprawka. Ten artykuł da krótki przegląd praktyk QA Patchman, w szczególności procesu walidacji poprawki, i omówi kluczową poprawę, którą ostatnio wprowadziliśmy w tym obszarze, zautomatyzowane testowanie poprawek.

Tworzenie i sprawdzanie poprawności poprawek

Gdy nowa wersja aplikacji dociera do naszej uwagi, poprzez (zautomatyzowane monitorowanie) oficjalnych kanałów wydania, bezpośrednie zaangażowanie deweloperów aplikacji lub inną drogą, rozpoczynamy naszą pracę. Najpierw oceniamy taką nową wersję poprzez przegląd kodu i badanie rejestru zmian, aby ustalić, które zmiany, jeśli takie istnieją, rozwiązują problemy bezpieczeństwa w aplikacji. Po zidentyfikowaniu te istotne dla bezpieczeństwa zmiany są kandydatami do stania się poprawkami.

Tworząc nowe poprawki zawsze staramy się być jak najbliżej poprawek bezpieczeństwa wdrożonych przez oficjalnego dewelopera i przenosić je tak daleko, jak pozwala na to obecność luki i techniczna wykonalność, przy czym ostatecznym ograniczeniem jest to, że nie przenosimy poprawek do wersji aplikacji, które wymagają wersji PHP 5.3 lub wcześniejszych. Praktyki te pozwalają poprawkom, które tworzymy i rozpowszechniamy, na rozwiązywanie problemów bezpieczeństwa w dotkniętych wersjach, ale bez negatywnego wpływu na funkcjonalność aplikacji i witryny. Ta ostatnia — pewność, że poprawki niczego nie psują — jest weryfikowana poprzez automatyczne i ręczne testowanie, które zbiorczo nazywamy procesem walidacji poprawek.

Aby lepiej to wyjaśnić, warto przyjrzeć się przykładowej wersji WordPressa, powiedzmy WordPress 5.5.2 (z dnia 30 października 2020 r.). Dodano w niej ucieczkę do różnych elementów sekcji administracyjnej w dwóch plikach aplikacji, aby rozwiązać lukę w zabezpieczeniach związaną z atakami typu cross-site scripting:

  • wordpress/wp-admin/zawiera/media.php
  • wordpress/wp-admin/includes/template.php

Częścią procesu weryfikacji poprawek jest stosowanie nowo utworzonej poprawki do wszystkich wersji aplikacji, których dotyczy, we wszystkich wersjach PHP, na których działa dana wersja aplikacji, a następnie przeprowadzanie obszernych testów w celu upewnienia się, że załatana aplikacja pozostaje w pełni funkcjonalna, a luka w zabezpieczeniach nie występuje lub nie można jej wykorzystać.

Może to być rygorystyczne przedsięwzięcie, biorąc pod uwagę, że niektóre luki w zabezpieczeniach dotyczą dziesiątek różnych wersji aplikacji, a poprawki obejmują wiele plików, a każda unikalna poprawka musiałaby zostać skonfigurowana i przetestowana lokalnie. To sprawia, że ​​proces jest bardzo pracochłonny.

Wprowadź automatyczne testy poprawek

Na początku tego roku zbudowaliśmy nowy wewnętrzny system testowania, aby zastąpić poprzednie przepływy pracy procesu walidacji poprawek. Wewnętrznie nazywamy to automatycznym testowaniem poprawek i jest to platforma, na której możemy stosować i testować poprawki równolegle w centralnym środowisku.

Wbudowane w nasze własne wewnętrzne narzędzia, automatyczne testowanie poprawek pozwala nam na jednoczesne uruchamianie setek kontenerów, każdy z w pełni skonfigurowaną aplikacją CMS. W tych kontenerach stosujemy ramy testowania jednostkowego, aby testować jednostkowo każdą istotną kombinację wersji aplikacji, wersji PHP i poprawki. Pozwala nam to odejść od poprzedniego ręcznego testowania funkcjonalnego w środowisku lokalnym i nie tylko sprawia, że ​​samo testowanie jest bardziej kompleksowe, ale także sprawia, że ​​cały proces jest znacznie bardziej skalowalny.

Prowadzi to do szybszych cykli dzięki scentralizowanej automatyzacji testów i paralelizacji oraz lepszej jakości, ponieważ to pierwsze umożliwia nam bardziej rygorystyczne testowanie. Te ulepszenia przynoszą korzyści klientom Patchman, umożliwiając nam szybsze dostarczanie poprawek i z niezwykle dokładnym QA.

Aby uzyskać więcej informacji na temat Patchmana, napisz do nas na adres e-mail: [email protected] lub odwiedź Patchman.co i skorzystaj z bezpłatnego okresu próbnego.