Zwiększ skuteczność skanera aplikacji webowej poprzez zrozumienie powierzchni ataku

Understanding the attack surface of the web application is a very important step while conducting cybersecurity research or penetration testing. Even if you are running a web application scanner as part of DAST activities, knowing the attack surface will help you cover more functionality of the application with a scan. If you are using a source code web application scanner, understanding the attack surface will help you find true positives in the SAST tool’s report.

Czym jest powierzchnia ataku

Bez względu na to, czy używasz skanera aplikacji webowej w ramach testów DAST, czy prowadzisz testy penetracyjne lub badania nad cyberbezpieczeństwem, wszystkie funkcjonalności dostępne dla użytkowników oraz wszystkie możliwe wejścia danych stanowią powierzchnię ataku.

Wyobraź sobie dom z drzwiami frontowymi i oknami – każdy może je zobaczyć, dotknąć, a nawet spróbować otworzyć. Jeśli masz klucz, możesz włożyć go do zamka w drzwiach, otworzyć je i nagle uzyskać dostęp do całego wnętrza domu. Niektóre pomieszczenia są otwarte, inne zamknięte na klucz, a jeszcze inne wymagają przejścia na inne piętro. Możesz też zobaczyć pokój dziecięcy z tabliczką „Wymagane hasło do wejścia” – nie wpuszczą cię tam, dopóki nie zapukasz w odpowiedniej kolejności i nie wypowiesz sekretnej frazy.

W tej analogii drzwi i okna symbolizują funkcjonalności aplikacji webowej dostępne dla każdego. Klucze do drzwi, hasła i sekwencje pukania to dane wejściowe użytkownika. Nawet fakt, że możesz wspiąć się po schodach, jest formą wejścia użytkownika, która pozwala ci dostać się na inne piętro.

Łatwo zauważyć, że niektóre części domu są dostępne tylko po wykonaniu określonych działań.

Na przykład, jeżeli chcesz sprawdzić, czy pokój dziecięcy jest posprzątany, musisz:

1. Włożyć odpowiedni klucz do zamka (klucz to dane wejściowe użytkownika)
2. Przejść do drzwi pokoju dziecka
3. Zapukać trzy razy (sekwencja pukania to dane wejściowe użytkownika)
4. Wypowiedzieć hasło „Jestem gumą, a ty klejem” (hasło to dane wejściowe użytkownika)

Oznacza to, że jeśli chcesz użyć skanera aplikacji webowej do wykrycia podatności, może on widzieć tylko drzwi frontowe i okna, ale nie dotrze do reszty wnętrza, jeśli nie jest wystarczająco inteligentny.

Zauważ, że w trakcie sprawdzania, czy pokój dziecięcy jest czysty, zakładamy, że znasz dom, układ pomieszczeń i drogę do pokoju dzieci. Zakładamy też, że:

• Masz jedyny klucz, który pasuje do zamka
• Znasz sekretne hasło
• Potrafisz wejść po schodach

To oznacza, że znasz jedną konkretną ścieżkę w domu. Jeśli jednak znasz wszystkie możliwe ścieżki, oznacza to, że masz pełną świadomość powierzchni ataku i możesz sprawdzić wszystkie pokoje, a nie tylko fasadę domu czy pokój dziecięcy.

Znaczenie powierzchni ataku w SAST, DAST i testach penetracyjnych aplikacji webowych

W praktyce postrzeganie powierzchni ataku może się różnić w zależności od rodzaju przeprowadzanej analizy bezpieczeństwa.

W przypadku DAST (dynamiczna analiza bezpieczeństwa aplikacji) wykonywanej za pomocą skanera aplikacji webowej lub testów penetracyjnych, powierzchnię ataku stanowią wszystkie strony, panele, widoki, endpointy API, a także wszystkie pola, parametry, formularze i metadane, które można przesyłać do poszczególnych elementów aplikacji.

Nieco inaczej wygląda to w przypadku SAST (statyczna analiza kodu). Skanery kodu źródłowego zazwyczaj nie operują bezpośrednio na koncepcji powierzchni ataku, lecz śledzą przepływ danych w kodzie – od źródeł (wejście użytkownika) do ujść (funkcjonalności).

Powierzchnia ataku w aplikacjach CakePHP

Jeśli skupiasz się na identyfikowaniu podatności w aplikacjach opartych na CakePHP, framework ten może stanowić wyzwanie pod względem bezpieczeństwa. Jednak można wykorzystać jego własne mechanizmy do pozyskania przydatnych informacji dla testera penetracyjnego lub badacza.

Jeśli czytałeś poprzedni artykuł, wiesz, że CakePHP bazuje na wzorcu MVC (Model-View-Controller). Możemy to wykorzystać do zmapowania powierzchni ataku aplikacji CakePHP poprzez wydobycie tras, kontrolerów, akcji i innych informacji.

Pokażę Ci dwie metody osiągnięcia tego celu. Pierwsza to analiza statyczna kodu źródłowego, a druga to automatyczna ekstrakcja informacji za pomocą skryptu

Metoda analizy statycznej pozwala również na tworzenie podobnych skryptów dla innych frameworków aplikacji webowych.

Wszystkie skrypty, które tu przedstawię, są dostępne w repozytorium GitHub:
🔗 https://github.com/Zigrin-Security/CakePHPHackingScripts

Skaner aplikacji webowej oparty na trasach w CakePHP

Trasy to definicje adresów URL, do których użytkownicy mogą uzyskać dostęp. Jak już wiesz z poprzedniego artykułu, trasy w CakePHP są definiowane w pliku /config/routes.php.

Jako przykład weźmy Cerebrate i skupmy się na jednym zakresie (scope):

$routes->scope('/', function (RouteBuilder $builder) {
…
   $builder->registerMiddleware('csrf', new CsrfProtectionMiddleware([
       'httponly' => true,
   ]));
    if (empty($_SERVER['HTTP_AUTHORIZATION'])) {
        $builder->applyMiddleware('csrf');
    }
…
   $builder->connect('/', ['controller' => 'Instance', 'action' => 'home']);
   $builder->connect('/pages/*', ['controller' => 'Pages', 'action' => 'display']);
   $builder->fallbacks();
});

Zakresy to grupy tras, które dzielą tę samą konfigurację. W tym przypadku mamy tylko jeden zakres, a wszystkie trasy w nim zdefiniowane zaczynają się od /.

Pierwszą istotną rzeczą w trasach są instrukcje connect (linia 10–11).

Na ich podstawie mamy dwie trasy:

• / – wykonuje akcję home w kontrolerze Instance.
• /pages/* – wykonuje akcję display w kontrolerze Pages.

Symbol * oznacza, że do akcji kontrolera mogą być przekazywane argumenty. Może to odpowiadać następującemu adresowi URL:

https://cake_php_application/pages/argument1

Linia 12 definiuje domyślne trasy, które działają według następujących zasad:

• /<controller> – wykonuje akcję index dla określonego kontrolera.
• /<controller>/<action>/* – wykonuje określoną akcję w danym kontrolerze.

Te same akcje i kontrolery można wywołać za pomocą domyślnych tras, np.:

• https://cake_php_application/Pages/display/argument1
• https://cake_php_application/instance/home

Kolejną istotną kwestią jest middleware zdefiniowany dla wszystkich tras w danym zakresie (linie 3–8).

Cerebrate konfiguruje ochronę CSRF dla wszystkich tras w tym zakresie, z wyjątkiem sytuacji, gdy w żądaniu obecny jest nagłówek Authorization.

Dalsza część pliku routes.php definiuje prefiks Open:

$routes->prefix('Open', function (RouteBuilder $routes) {
   $routes->setExtensions(['json']);
   $routes->fallbacks(DashedRoute::class);
});

Prefiksy w CakePHP są bardzo podobne do zakresów (scopes). Główna różnica polega na tym, że wskazują one na kontrolery znajdujące się w innej ścieżce.

W linii 2 powyższego kodu widać, że zdefiniowano rozszerzenie. Oznacza to, że adresy URL zaczynające się od /open mogą kończyć się rozszerzeniem .json.

Na końcu definicji prefiksu znajduje się mechanizm rezerwowy (fallback) z domyślnymi trasami, jednak tym razem używana jest trasa w formacie myślnikowym. Oznacza to, że adresy URL zapisane z myślnikami zostaną przekonwertowane na ścieżki z wielkimi literami.
Przykładowo:
🔗 https://cake_php_application/my-messages/show-message
spowoduje wywołanie akcji ShowMessage w kontrolerze MyMessages.

W efekcie mamy:

• 2 trasy zdefiniowane w głównym zakresie,
• 2 domyślne trasy w tym samym zakresie,
• 2 trasy rezerwowe z prefiksem „Open”.

Czy to wszystkie trasy w Twojej aplikacji CakePHP?

Najprawdopodobniej nie.

Trasy mogą być również definiowane w innych częściach aplikacji, np. w wewnętrznych lub zewnętrznych wtyczkach. Możesz szybko wyszukać pliki routes.php, ale definicje tras mogą znajdować się także w innych miejscach.

Jak więc automatycznie znaleźć wszystkie trasy w aplikacji?

Automatyczne wydobycie tras w CakePHP

Otwieranie plików i szukanie definicji tras to już krok naprzód w zrozumieniu powierzchni ataku, ale możemy pójść o krok dalej i wydobyć te informacje z działającej aplikacji webowej. Wymaga to dwóch kroków.

Aplikację PHP można uruchomić z poziomu linii poleceń w ten sposób:

php /var/www/webapp/webroot/index.php

Dodatkowo, możemy napisać mały skrypt PHP, który zaimportuje plik index.php i wykona kod docelowej aplikacji webowej. To jest pierwszy krok:

<?php
ob_start();
include $argv[1];
$output = ob_get_clean();

Linie 2 i 4 odpowiadają za przechwycenie wyjścia aplikacji. Domyślnie, docelowa aplikacja webowa prawdopodobnie zwróci jakąś odpowiedź HTML, która nas nie interesuje. Używamy po prostu mechanizmu PHP, aby przechwycić to wyjście.

Linia 3 importuje plik PHP, który przekazaliśmy jako parametr do naszego przykładowego skryptu. Można go uruchomić poleceniem:

php cakephp_extractor.php /var/www/application/webroot/index.php

Po uruchomieniu skryptu powinieneś otrzymać albo brak wyników, albo ostrzeżenia/błędy PHP. Wynika to z faktu, że aplikacja może logować dużo na stderr. Na razie nie musimy się tym martwić.

Drugi krok wymaga pracy z samym CakePHP. Gdy wysyłasz żądanie HTTP do aplikacji CakePHP, wszystkie trasy są przechowywane w pamięci w obiekcie Cake\Routing\Router. Kiedy zaimportujemy index.php, możemy uzyskać dostęp do tego obiektu i przekształcić każdą trasę w regularny wyrażenie, które możemy wydrukować.

Oto skrypt, który to robi:

<?php
function get_routes() {
   $str_routes = array();
   $routes = Cake\Routing\Router::routes();
   foreach($routes as $route) {
       $str_routes[] = $route->compile();
   }
   $str_routes = array_unique($str_routes);
   return $str_routes;
}


if(count($argv) <= 1) {
   print("Usage: {$argv[0]} path/to/index.php\n");
   die;
}


ob_start();
include $argv[1];
$output = ob_get_clean();


$routes = get_routes();
foreach($routes as $route) print("$route\n");

Najpierw w linii 18 włączamy plik index.php z argumentu wiersza poleceń. To inicjuje wszystkie zmienne, których używa aplikacja docelowa, razem z obiektem Router. Następnie wywołujemy funkcję get_routes w linii 21.

Funkcja get_routes wyciąga wszystkie trasy w linii 4. Te trasy to również obiekty, więc musimy skompilować je do wyrażeń regularnych. Dzieje się to w linii 6 dla każdej trasy. W linii 8 upewniamy się, że nie ma duplikatów i zwracamy trasy.

Jeśli uruchomisz ten skrypt na działającej aplikacji Cerebrate z poprzednich przykładów, powinieneś otrzymać wynik podobny do poniższego:

You can see that there are more than six routes that we discovered through manual analysis.

Widać, że odkryliśmy więcej niż sześć tras, które wcześniej odkryliśmy podczas analizy ręcznej.

Wyrażenia regularne mogą początkowo być trudne do zrozumienia, ale z czasem dostrzegasz statyczne wartości oraz wspólne bloki, takie jak:

• <controller>
• <action>
• <_args_>

Przyjrzyjmy się ostatniej trasie ze zrzutu ekranu powyżej, aby wyjaśnić znaczenie wyrażenia regularnego:

#^/(?:(?P[^/]+))/(?:(?P[^/]+))(?:/(?P<_args_>.*))?[/]*$#

Oto główne bloki tej trasy:

• / – każda ścieżka URL zaczyna się od /
• (?:(?P<controller>[^/]+))
  • (?: Oznacza grupę nieprzechwytującą, czyli grupę składającą się z tylko jednego elementu (grupa), którą możemy pominąć
  • (?P – Określa grupę przechwytywania o nazwie controller, ta grupa wychwytuje wszystko oprócz znaku /
• / – Ukośnik po nazwie kontrolera
• (?:(?P<action>[^/]+)) – To samo co powyżej, ale nazwa grupy to action
• (?:/(?P<_args_>.*))? – Grupa nieprzechwytująca, opcjonalna, która ma dwa elementy
  • / – Znak ukośnika po grupie akcji
  • (?P – Określa grupę przechwytywania o nazwie _args_, która wychwytuje wszystko
  • ? – Oznacza, że grupa argumentów jest opcjonalna
• / – Opcjonalny jeden lub więcej ukośników

To po prostu tłumaczy się na ten schemat ścieżki URL:

/<controller>/<action>/<optional_arguments>

Aby analizować wyrażenia regularne, gorąco polecam używanie strony https://regex101.com/

Znajomość kontrolerów CakePHP w celu ich skanowania za pomocą skanera aplikacji webowej

Kontrolery są łatwiejsze do wydobycia, ponieważ są reprezentowane przez pliki w katalogu /src/Controller oraz wszystkich jego podkatalogach. Wszystkie pliki kończące się na Controller.php to kontrolery. Używając Cerebrate, jak w naszym poprzednim przykładzie, oto szybka komenda bash, która wydobywa kontrolery z aplikacji CakePHP:

W tym przypadku wyszukujemy wszystkie pliki kończące się na Controller.php i usuwamy zbędne elementy ścieżki. Pamiętaj, że otrzymasz tutaj także podkatalogi, takie jak Open/Individuals.

Używanie naszej sprytnej metody importowania index.php do skryptu PHP nie jest konieczne w tym przypadku, ale będzie przydatne do wydobywania akcji. Ma jedną główną zaletę: jeśli kontrolery znajdują się w katalogu innym niż /src/Controller, nadal zostaną wykryte.

<?php
function get_controllers() {
   $controllers = array();
   $c_const = 'Controller';
   $ext = '.php';


   $dirs = Cake\Core\App::classPath($c_const);
   foreach($dirs as $dir) {
       $paths = get_dir_content($dir);
       foreach($paths as $path) {
           if(strpos($path, $c_const.$ext) !== false) {
               $controllers[] = substr($path, strlen($dir), -strlen($c_const)-strlen($ext));
           }
       }
   }
   $controllers = array_unique($controllers);
   return $controllers;
}
function get_dir_content($dir, &$results = array()) {
   $files = scandir($dir);


   foreach ($files as $key => $value) {
       $path = realpath($dir . DIRECTORY_SEPARATOR . $value);
       if (!is_dir($path)) {
           $results[] = $path;
       } else if ($value != "." && $value != "..") {
           get_dir_content($path, $results);
           $results[] = $path;
       }
   }


   return $results;
}


if(count($argv) <= 1) {
   print("Usage: {$argv[0]} path/to/index.php\n");
   die;
}


ob_start();
include $argv[1];
$output = ob_get_clean();


$controllers = get_controllers();
foreach($controllers as $controller) print("$controller\n");

W wierszu 8 dynamicznie wydobywamy wszystkie katalogi, które zostały zarejestrowane jako katalogi kontrolerów. W wierszu 10 używamy funkcji pomocniczej rekurencyjnie wydobywającej wszystkie pliki i katalogi w każdym katalogu zarejestrowanym jako katalog kontrolera. W wierszach 12 i 13 po prostu sprawdzamy, czy plik kończy się na Controller.php, a jeśli tak, wydobywamy nazwę kontrolera i zapisujemy ją w tablicy. Na końcu, w wierszach 17 i 18, upewniamy się, że wszystkie nazwy kontrolerów są unikalne i zwracamy wynik.

W przypadku aplikacji Cerebrate nasz skrypt zwraca identyczny wynik jak poprzednia komenda bash:

Ekstrakcja akcji w aplikacji CakePHP

Akcje są reprezentowane przez metody w klasie kontrolera. Na przykład akcja „add” kontrolera „Users” w projekcie Cerebrate jest dostępna tutaj: https://github.com/cerebrate-project/cerebrate/blob/a7dca8284bdba862c8367f2afb479011d7460ca3/src/Controller/UsersController.php#L59

Zauważ, że metoda „add” jest publiczna.

Automatyzacja ekstrakcji akcji nie jest tak prosta jak ekstrakcja kontrolerów, ale nadal możemy to zrobić za pomocą podobnego skryptu PHP.

Krótka instrukcja poniżej, daj znać, jeśli chcesz, abym wyjaśnił kod szczegółowo.

Dla każdego kontrolera ekstraktujemy jego pełną nazwę klasy, włącznie z przestrzenią nazw. Osiągamy to za pomocą funkcji load_controller.

Funkcja get_controller_action ekstraktuje wszystkie metody kontrolera i usuwa metody prywatne z listy za pomocą funkcji is_controller_action.

Ostateczny skrypt, który ekstraktuje wszystkie kontrolery i ich akcje, ma ponad sto linii:

<?php
function get_controllers() {
   $controllers = array();
   $c_const = 'Controller';
   $ext = '.php';


   $dirs = Cake\Core\App::classPath($c_const);
   foreach($dirs as $dir) {
       $paths = get_dir_content($dir);
       foreach($paths as $path) {
           if(strpos($path, $c_const.$ext) !== false) {
               $controllers[] = substr($path, strlen($dir), -strlen($c_const)-strlen($ext));
           }
       }
   }
   $controllers = array_unique($controllers);
   return $controllers;
}
function get_dir_content($dir, &$results = array()) {
   $files = scandir($dir);


   foreach ($files as $key => $value) {
       $path = realpath($dir . DIRECTORY_SEPARATOR . $value);
       if (!is_dir($path)) {
           $results[] = $path;
       } else if ($value != "." && $value != "..") {
           get_dir_content($path, $results);
           $results[] = $path;
       }
   }


   return $results;
}
function get_actions() {
   $result = array();
   $controllers = get_controllers();
   foreach($controllers as $controller) {
       $class = load_controller($controller);
       if ($class!==false && class_exists($class)) {
           $result[$controller] = get_controller_action($class);
       }
   }
   return $result;
}
function load_controller($controller) {
   $pluginPath = "";
   $namespace = "Controller";
   $className = Cake\Core\App::className($pluginPath . $controller, $namespace, $namespace);


   $reflection = new ReflectionClass($className);
   if ($reflection->isAbstract()) {
       return false;
   }
   if (class_exists($className)) {
       return $className;
   }
   return false;
}
function get_controller_action($controller_class) {
   $controllerObject = new $controller_class();
   $actions = array();
   $methods = get_class_methods($controllerObject);
   foreach($methods as $method) {
       if(is_controller_action($controllerObject, $method)) {
           $actions[] = $method;
       }
   }
   return $actions;
}
function is_controller_action($controllerObject, $action) {
   $baseClass = new ReflectionClass(new Cake\Controller\Controller);
   if ($baseClass->hasMethod($action)) {
       return false;
   }
   try {
       $reflectionMethod = new ReflectionMethod($controllerObject, $action);
   } catch (ReflectionException $e) {
       return false;
   }
   $objectReflection = new ReflectionClass($controllerObject);
   if($reflectionMethod->class !== $objectReflection->getName()) {
       return false;
   }
   return $reflectionMethod->isPublic() && $reflectionMethod->getName() === $action;
  
}


if(count($argv) <= 1) {
   print("Usage: {$argv[0]} path/to/index.php\n");
   die;
}


ob_start();
include $argv[1];
$output = ob_get_clean();


print(json_encode(get_actions()));

Ostateczny wynik to słownik JSON kontrolerów i odpowiadających im akcji:

Poznaj, które wtyczki są używane w Twojej aplikacji CakePHP

Wtyczki mogą być trudne do zidentyfikowania. Najprostszym sposobem jest zajrzenie do katalogu /plugins. Wydaje się, że aplikacja Cerebrate używa tylko wtyczki Tags: https://github.com/cerebrate-project/cerebrate/tree/a7dca8284bdba862c8367f2afb479011d7460ca3/plugins

Jednak mogą istnieć inne wtyczki używane przez aplikację. Lepszym sposobem jest poszukanie w kodzie miejsc, w których rejestrowane są wtyczki. Szybkie użycie polecenia grep z frazą addPlugin powinno ujawnić inne wtyczki:

Automatyczne wydobywanie wtyczek z aplikacji nadal jest najpewniejszym sposobem, ponieważ pozwala na dokładne odzyskanie wszystkich wtyczek używanych w aplikacji.

Kod źródłowy:

<?php
function get_server_var() {
   global $app_vars;
   foreach($app_vars as $k=>$v) {
       if($v instanceof Cake\Http\Server) return $v;
   }
   return null;
}
function get_object_property($object, $property) {
   $object_reflection = new ReflectionClass($object);
   $property_reflection = $object_reflection->getProperty($property);
   $property_reflection->setAccessible(true);
   return $property_reflection->getValue($object);
}
function get_plugins() {
   $server = get_server_var();
   if(is_null($server)) return null;
   return get_object_property($server->getApp()->getPlugins(), 'names');
}


if(count($argv) <= 1) {
   print("Usage: {$argv[0]} path/to/index.php\n");
   die;
}


ob_start();
include $argv[1];
$output = ob_get_clean();
$app_vars = get_defined_vars();
unset($app_vars['output'], $app_vars['argv']);


print(json_encode(get_plugins()));

W rezultacie otrzymujemy listę wtyczek używanych przez aplikację:

Zrozumienie parametrów nazwanych w starszych wersjach CakePHP

Z tego, co wiem, ten element jest dostępny tylko w wersjach CakePHP 2 i 3. Należy pamiętać, że wersje CakePHP 2 i 3 nie są już wspierane. Niemniej jednak, ponieważ nadal istnieją aplikacje webowe opierające się na tej wersji frameworka, omówimy ten temat.

HTTP zostało zaprojektowane do przesyłania parametrów za pomocą ciągu zapytania. Z pewnością widziałeś to wcześniej:

https://example.com/posts/view?title=first&category=general

Parametry nazwane to po prostu inny sposób przekazywania parametrów do akcji kontrolera za pomocą URL. Oto przykład ścieżki URL z parametrami nazwanymi, która przekazuje te same parametry, co powyższy URL:

/posts/view/title:first/category:general

Małe wyjaśnienie:

• Kontroler: post
• Akcja: view
• Parametr 1:
  • Nazwa: title
  • Wartość: first
• Parametr 2:
• Nazwa: category
• Wartość: general

Możesz również przekazywać tablice w ten sposób:

/posts/view/filter[title][value]:first/filter[title][sort]:asc

Te parametry można znaleźć w plikach kontrolerów, szukając $this->params['named'] , $this->params["named"] lub $this->passedArgs.

Aplikacja może używać różnych parametrów nazwanych w różnych miejscach w kodzie. Może to również zależeć od różnych warunków. Dlatego nie ma uniwersalnego sposobu na automatyczne wyodrębnienie tych parametrów.

Podsumowanie – dynamiczne wyodrębnianie informacji gotowych do użycia przez skaner aplikacji webowej

Możemy połączyć wszystko w jeden skrypt, który zwróci żądane informacje w formacie JSON. Kod jest dostępny w repozytorium GitHub.

Oto kilka przykładów, jak go używać.

Wyodrębnianie tras:

Wyodrębnianie kontrolerów:

Wyodrębnianie akcji:

Wyodrębnianie wtyczek:

Uzyskanie wszystkich tych informacji w formacie JSON pozwala również przekazać je do innych skryptów i narzędzi, takich jak skanery aplikacji webowych.

Wykorzystanie wiedzy o powierzchni ataku CakePHP

Dzięki powierzchni ataku, którą opisałem powyżej, możesz wykorzystać te informacje do lepszej konfiguracji swoich skanerów aplikacji webowych, odkrywania ukrytej funkcjonalności aplikacji podczas testów penetracyjnych typu white-box oraz objęcia większych obszarów aplikacji swoją analizą.

W nadchodzących tygodniach opublikujemy narzędzie, które w dużej mierze opiera się na tych metodach do przeprowadzania Interactive Application Security Testing (IAST).

Usługa testów penetracyjnych typu white-box

Jeśli szukasz profesjonalnej usługi testów penetracyjnych typu white-box, pozostaw swój adres e-mail w poniższym polu, a skontaktujemy się z Tobą.

Bibliografia:

https://book.cakephp.org/2/en/development/routing.html#named-parameters