Фильтрация POST и REQUEST

Активно используя Joomla в своей практике и переходя от версий к версиям, а так же учитывая заново появляющееся после очередных патчей огромное количество эксплойтов для ядра и (в основном) для сторонних (не всех, а только кривых) расширений меня не покидает мысль... почему нельзя сделать и включить в базовый дистр хороший фильтр входных параметров... веть большинство (подавляющее) эксплойтов и методов взлома основаны на хитроумно составленных _REQUEST_URI ... и содержат всем известные слова и символы маскировки и ошиблк:
/* */ %00 select union update drop flush alter и т.п.
присекая напрочь использование подобных символов в _REQUEST_URI мы (я полагаю,... возможно наивно) на 90% повышаем безопасность наших сайтов и предупреждаем от ошибок и брешей в новых сторонних компонентах....
это может быть даже что-то вроде

Код (PHP):

1. <?php
2. //global $_POST;
3.  $abcdefgh = parse_url($_SERVER['REQUEST_URI']); // парсим юри
4.  $base_url = explode('/',$abcdefgh['path']);
5.  $i = count($base_url)-1;
6.  $base_url = $base_url[$i]; //выделяем что то типа index.php
7.  $url_search = $abcdefgh['query']; // берем строку запроса
8.  $denied_str = '(select|union|outfile|alter|insert|/e\%00|drop|flush|create|truncate)|/\*|\*/|\[|\])';
9.  if (eregi($denied_str,$url_search))
10.           {
11.              header("location:$base_url"); // если есть что то подозрительное
12.              die() or exit();
13.           }
14.  
15. ?>

естественно, остается добавить фильтр хак параметров закодированных например в base_64 и прочих ухищрений, но даже одно это (сверху) уже отсеивает процентов 80 готовых эксплойтов.....

ваши замечания.... может у кого уже есть фильры покруче ... буду рад если поделитесь....
у меня впринципе есть, но он скорее заточен под конкретный проект и жестоко ограничивает _REQUEST_URI и _POST ...
пытаюсь все начать работу над универсальным, но все руки не доходят

 

Ответ: Фильтрация POST и REQUEST

Честно говоря надеялся на активное развитие темы.... видимо не зацепило...
ладно... буду сам дальше придумывать...

 

Ответ: Фильтрация POST и REQUEST

paranoik, решение интересное, но я не настолько владею вопросами безопасности, на таком уровне А возможно ли при использовании этого хака проблемы с самой джумлой? расширениями, а то мало ли

 

Ответ: Фильтрация POST и REQUEST

Решение плохое, если у меня сайт про SQL, если про программирование, если у меня сайт про приставочные игры, если про английский язык, если про софт... и т.п., рано или поздно всплывет боком этот фильтр.

 

Ответ: Фильтрация POST и REQUEST

Что касается get-запросов, то по-моему, вполне достаточно той фильтрации, которая включена в .htaccess.
А уж проверять, так все переменные, а не только $_SERVER['REQUEST_URI']. И даже массива $_POST недостаточно: недавно, например, была обнаружена уязвимость в Datso Gallery через переменную $_SERVER['HTTP_USER_AGENT'].

 

Ответ: Фильтрация POST и REQUEST

То что я написал выше - лишь общий вектор, скелетик так сказать... Поэтому если вставлять этот хак as is то могут быть проблемы при передаче сам понимаеш чего через сам понимаеш что...
Естественно, если мы будем брать только эти две $_SERVER['REQUEST_URI'] и $_POST то останется много дыр. Так же конечно нехорошо, как сказал sectus : Решение плохое, если у меня сайт про SQL, если про программирование, если у меня сайт про приставочные игры, если про английский язык, если про софт... и т.п., рано или поздно всплывет боком этот фильтр, поэтому надо писать более интеллектуальные фильтры... ну например использующие совокупности похожих на нехорошие запросы последовательностей....
Проверять естественно надо всю $_SERVER
Вообщем как дойдут руки засяду, чонить выложу на обсуждение....
А что касается фильтрации, которая включена в .htaccess, то её конечно не достаточно... Было б достаточно дак и не ломали бы тогда....

 

Ответ: Фильтрация POST и REQUEST

Ну вот что то более развитое получилось...
За аляповатости в коде извиняйте... некогда долга размышлять было...

Код (PHP):

1. <?php
2. //echo $_SERVER['HTTP_USER_AGENT'];
3. $paranoya_level = 1;
4. $abcdefgh = parse_url($_SERVER['REQUEST_URI']);
5.     $base_url = explode('/',$abcdefgh['path']);
6.     $i = count($base_url)-1;
7.     $base_url = $base_url[$i];
8.     $url_search = $abcdefgh['query'];
9.     $get_search = implode('',$_GET);
10.     $get_variables = implode('',$_POST);
11.     $post_search = $get_search.$url_search; // на всякий случай :)
12.     $level100p = '(\+|\%20|/\*\*/| )from(\+|\%20|/\*\*/| )[a-zA-Z]+([0-9_]+)?';
13.     $level1_warning_token_regex = array('null( +)?,( +)?null','-\d+(\+|\%20|/\*\*/| )union(\+|\%20|/\*\*/| )',
14. 'concat( +)?\(char','\.\.\|\w+\.php','union(\+|\%20|/\*\*/| )select',
15. 'username,(\+|\%20|/\*\*/| )?0x3a,(\+|\%20|/\*\*/| )?password',
16. 'ascii\(','(/\*\*/|\%20| )select(/\*\*/|\%20| )','script');
17.     $level2_warning_token_regex = array('(\+|\%20|/\*\*/| )union','password(\+|\%20|/\*\*/| )?FROM','/\*');
18.     $level3_warning_token_regex = array('117,(\+|\%20|/\*\*/| )?115,
19. (\+|\%20|/\*\*/| )?101,
20. (\+|\%20|/\*\*/| )?114,
21. (\+|\%20|/\*\*/| )?110,
22. (\+|\%20|/\*\*/| )?97,
23. (\+|\%20|/\*\*/| )?109,
24. (\+|\%20|/\*\*/| )?101,
25. (\+|\%20|/\*\*/| )?58',
26. '(\+|\%20|/\*\*/| |\(|\))(user|union|select|password|create|truncate|alter|drop|flush|char)',
27. 'null','\*','\%20','-\d+\+','\+|\%20|/\*\*/ )');
28.     $counter_w_1 = 0;
29.     $counter_w_2 = 0;
30.     $counter_w_3 = 0;
31.     $warning_from = 0;
32.    
33.     foreach ($level1_warning_token_regex as $reg1)
34.             {
35.                 if (eregi($reg1,$post_search))
36.                     {
37.                         $counter_w_1++;
38.                     }
39.             }
40.     foreach ($level2_warning_token_regex as $reg2)
41.             {
42.                 if (eregi($reg2,$post_search))
43.                     {
44.                         $counter_w_2++;
45.                     }
46.             }
47.     foreach ($level3_warning_token_regex as $reg3)
48.             {
49.                 if (eregi($reg3,$post_search))
50.                     {
51.                         $counter_w_3++;
52.                     }
53.             }
54.     if (eregi($level100p,$post_search))
55.         {
56.             $warning_from=1;
57.         }
58.     if (($counter_w_3>1)&&($counter_w_1)&&($warning_from)&&($paranoya_level==1))
59.         {
60.             ?>     
61.         <script language="javascript">     
62.             document.location="<?php echo "$base_url"; ?>";
63.         </script>
64.         <?php
65.         die() or exit();
66.         } else if (($counter_w_3>1)&&($counter_w_2)&&(($counter_w_1)||($counter_w_3>2))&&($paranoya_level==2))
67.                     {
68.                         ?>     
69.         <script language="javascript">     
70.             document.location="<?php echo "$base_url"; ?>";
71.         </script>
72.         <?php
73.         die() or exit();
74.                     } else if (($counter_w_3>1)&&($paranoya_level==3))
75.                                 {
76.                                     ?>     
77.         <script language="javascript">     
78.             document.location="<?php echo "$base_url"; ?>";
79.         </script>
80.         <?php
81.         die() or exit();
82.                                 }
83.    
84. /*  $replacement_array = array("from"=>"frоm", "union"=>"uniоn", "select"=>"sеlесt","drop"=>"drоp");*/
85.    foreach($_POST as &$_value) {
86.    $_value = eregi_replace('(\+|\%20|/\*\*/)from',' frоm',$_value);
87.    $_value = eregi_replace('(\+|\%20|/\*\*/)drop',' drоp',$_value);
88.    $_value = eregi_replace('(\+|\%20|/\*\*/)alter',' altеr',$_value);
89.    $_value = eregi_replace('(\+|\%20|/\*\*/)union',' uniоn',$_value);
90.    $_value = eregi_replace('(\+|\%20|/\*\*/)?script',' sсript',$_value);
91.    }
92. ?>

 

Ответ: Фильтрация POST и REQUEST

тема нужная ибо когда пишешь чтото сам
потом приходиться кучку обезопасивших примочек приделывать
а это сильно тормозит работу

помоему проще всего это
добавить к жумле единый секурити бот
который будет присекать все попытки ввести подозрительные параметры

что касается сайтов которые по специфике своей вынужденны вести в контенте эти самые коды иньекции и прочие запросы то я думаю что нужно парсить запрос потом если он седержит спецсимволы (подозрительные) передавать этот запрос функции по его обезвреживанию которые будут заключать эти запросы в контейнеры безопасные для основного кода сайта

таким образом мы получим единый стандарт безопасности для жумла единый бот присекающий попытки взлома этот бот можно развивать как отдельное расширение...
при этом незнающий пользователь joomla небудет так трястись за свой сайт ставя неизвестное не опробованное расширение ибо он точно знает что секурити бот проверит все запросы....

 

Ответ: Фильтрация POST и REQUEST

дак вот етот кодом и положена попытка это сделать

Код (PHP):

1. foreach($_POST as &$_value) {
2.    $_value = eregi_replace('(\+|\%20|/\*\*/)from',' frоm',$_value);
3.    $_value = eregi_replace('(\+|\%20|/\*\*/)drop',' drоp',$_value);
4.    $_value = eregi_replace('(\+|\%20|/\*\*/)alter',' altеr',$_value);
5.    $_value = eregi_replace('(\+|\%20|/\*\*/)union',' uniоn',$_value);
6.    $_value = eregi_replace('(\+|\%20|/\*\*/)?script',' sсript',$_value);
7.    }

только вторым параметром в ереги (тут не видно, и это хорошо) в словах from и прочих (как раз для сайтов со спецификой) некоторые символы заменяются на их коды... что не позволяет выполнятся этим вероятностным запросам в MySQL...

заложена настройка уровня недоверия к данным paranoya_level. По умолчанию - 1 - нормальный уровень, когда можно передавать и через формы и через request нехорошие символы в более менее безопастных совокупностях... вроде понятно написал...

однако чую потребность некоторой оптимизации данного мной кода и призываю гуру этим попробовать заняться...

Испробовано на всех самых свежих эксплойтах. 100% эффект. на компонентах joomla форумов тоже испробовано. Писать инъекции в виде поста - пожалуйста, можно и вроде безопасно.

 

Ответ: Фильтрация POST и REQUEST

пиши мамбот, чтобы можно было тестить по-человечески.

 

Ответ: Фильтрация POST и REQUEST

ещё нужно сделать проверку файлов
тут нужно чтобы бот знал какой компонент какие файлы разрешает грузить
например галерея разрешает грузить картинки
бот должен знать что данный компонент может через пост принимать только такието расширения

тоесть нужно для бота соорудить сводную таблицу где option_com соответсвует компоненту и typefile соответствует типу файла а size размеру ну и with итп

далее графические файлы нужно проверять на наличие атрибутув (опасных)
это если нерадивый программер разрешит переименовку файла то хаккер сможет загнать картинку с атрибутом ввиде кода php а потом переименовать её в php и выполнить....


и самое сложное это обратная связь с компонентами и расширениями
в идиале разработчик должен делать таблицу параметров (какой для чего нужен) которые будет использовать при запросе к компоненту или расширению ,
указать возможные пределы данного параметра т.е. от и до
а пот обращаясь к данной таблице будет знать что данный параметр долженбыть таким каким должен быть
например параметр page должен быть только integer но не более 5000 (это к примеру)
эта таблица параметров может быть аналогична файлу configuration.php

это и для разработчика удобней
я например всегда когда чтонибудь начинаю с нуля
сначало делаю общюю схему (алгоритм) потом назначаю назначать имена параметрам которые будут передаваться на вход функциям компонента.
вот както так
у кого ещё какие предложения?

 

Ответ: Фильтрация POST и REQUEST

предлагаю начать рисовать схемы Например в UML...
кста, неплохо бы заиметь всю ЦМС Joomla в UML...

 

Ответ: Фильтрация POST и REQUEST

хы... два раза...