htmlspecialchars

[Ramzes]

Перед тем, как записать данные в БД, надо обработывать эти данные функцией htmlSpecialChars (или htmlentities). А как быть, если данные я передаю из клиентского скрипта backEnd скрипту, а только потом в БД.
Обрабатывать их в backEnd-e или есть какой-то аналог для JS?

[RayShade]

Замену по regexp в JS еще никто не отменял

[Хакер]

Вопрос непонятен. Можно ещё раз?

[RayShade]

Ну ему надо заэскейпить все < > & и прочие непечатные символы разметки HTML и получить на выходе &gt; &lt; &amp; и так далее htmlSpecialChars() делает именно это, как я понял. Но на клиенте нету РНР - на клиенте есть JS. Стало быть, придется юзать string.replace() с regexp

[Ramzes]

решил гуглить в поисках готовых решений
http://kevin.vanzonneveld.net/code/php_ ... nts/php.js

и еще вариант

Код: Выделить всё

   
1        function htmlspecialchars(string, quote_style) {
2        // http://kevin.vanzonneveld.net
3        // +   original by: Mirek Slugen
4        // +   improved by: Kevin van Zonneveld (http://kevin.vanzonneveld.net)
5        // *     example 1: htmlspecialchars("<a href='test'>Test</a>", 'ENT_QUOTES');
6        // *     returns 1: '&lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt'
7       
8        string = string.toString();
9       
10        // Always encode
11        string.replace('/&/g', '&amp;');
12        string.replace('/</g', '&lt;');
13        string.replace('/>/g', '&gt;');
14       
15        // Encode depending on quote_style
16        if (quote_style == 'ENT_QUOTES') {
17            string.replace('/"/g', '&quot;');
18            string.replace('/\'/g', '&#039;');
19        } else if (quote_style != 'ENT_NOQUOTES') {
20            // All other cases (ENT_COMPAT, default, but not ENT_NOQUOTES)
21            string.replace('/"/g', '&quot;');
22        }
23       
24        return string;
25    }

[Хакер]

RayShade, какая разница, есть на клиенте PHP или нет? Клиент ведь делает запрос веб-серверу, а не веб-сервере (где разумеется есть php) и производится работа с БД.

Или не так, а Ramzes?

[Ramzes]

все верно, есть только одно но

запрос из текстовго поля серверу отправляется в виде GET запроса

например:
backEnd.php?action=doOne&var=txtValue

где var берется из текстового поля, соответсвенно пользователь написал в поле "txtValue".

а если пользователь напишет в текстовом поле "A&action=doElse&var=fff"
получится, что серверу будет отправлен запрос вида

backEnd.php?action=doOne&var=&action=A&doElse&var=fff

[Хакер]

В этом случае, здесь неуместно использовать htmlspecialchars (пишется строчными). В этом случае надо использовать urlencode.

[RayShade]

Тут вообще-то имеет место быть здоровая дыра для injection Так что параметр лучше самостоятельно разбирать, выкидывать все лишнее, и потом передавать

[Ramzes]

Хакер, это, надо понимать тоже PHP функция?
RayShade, подробнее, пожалуйста

[Хакер]

Ramzes, ты расскажи вообще, как у тебя и что? Ты GET-запрос вручную делаешь, с помощью XmlHttpRequest, или он у тебя в веб-форме?

[RayShade]

Все просто. Если ты даешь серверу прямо запрос, который кто то вбивает в текстовое поле, то этот кто-то туда может вбить любой код (может и вредный) и ты теоретически можешь обвалить свой сервак таким образом.

[Ramzes]

Все просто. Если ты даешь серверу прямо запрос, который кто то вбивает в текстовое поле, то этот кто-то туда может вбить любой код (может и вредный) и ты теоретически можешь обвалить свой сервак таким образом.

Это я понимаю, как раз в связи с понимаем вышенаписаного, я и создал эту тему, ибо надо эти скрипты как-то обезопасить.

[Хакер]

(Рамзес сообщеает параллельно по аське, что он действительно использует XmlHttpRequest).

В этом случае надо энкодить вручную.

Тут есть две проблемы:
1) Необходимость encode-ить значения аргументов.
2) Опасность применения SQL-Injection.


Сначала надо разобраться с первым (несмотря на то, что второе опаснее). Если с первым не разберёшься, запрос может вообще не дойти до сервера в нужном виде.

Для примера того, как можно разрулить такую проблему, смотри сл. скрипты из одного недоделанного сделанного мною сайта:
http://shanrak.kz/aj_article.js (обратить внимание на код функции askbox_send_handler)
http://shanrak.kz/aj_base.js (обратить внимание на код функции safe_amps, использующуюся в askbox_send_handler)


Вторая проблема: проблема безопасности. Есть она у тебя или нет нельзя определить, не зная, какием трансформациям подвергаются данные, взятые из GET-запроса, прежде чем они станут частью SQL-запроса. Если никаким — всё очень плохо.

[Ramzes]

Вторая проблема: проблема безопасности. Есть она у тебя или нет нельзя определить, не зная, какием трансформациям подвергаются данные, взятые из GET-запроса, прежде чем они станут частью SQL-запроса. Если никаким — всё очень плохо.

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

[Хакер]

Разберись сначала с первым, потом перейдём ко второму.

Кстати, напоминаю, что XmlHttpRequest шлёт запрос в кодировке UTF-8. Если у тебя серверные скрипты работают с cp1251, то, по видимому, придётся юзать iconv-функции, чтобы перекодировать.

[Ramzes]

ну с первым все более-мение понятно, копируем код Хакера, и получаем что-то вроде:

Код: Выделить всё

function createDeliveryPoint()
{
   var dpName = document.getElementById("dpName").value;
   dpName = safe_amps(dpName);

   var dpAddress = document.getElementById("dpAddress").value;
   dpAddress = safe_amps(dpAddress );

   var dpcontactPerson = document.getElementById("dpContactPerson").value;
   dpcontactPerson = safe_amps(dpcontactPerson );

   var dpcontactPhones = document.getElementById("dpContactPhones").value;
   dpcontactPhones = safe_amps(dpcontactPhones );
   
   var url = "components/presonalData/backEnd.php?action=createDeliveryPoint&dpName="+dpName+"&dpAddress="+dpAddress+"&dpcontactPerson="+dpcontactPerson+"&dpcontactPhones="+dpcontactPhones;
   pInfo_SendUrl(url);
   document.getElementById("bottom_el").innerHTML = "<a href=\"#\" onclick=\"return getDeliveryPoints();\" >Точки доставки</a>";
}

function safe_amps(sData) { return encodeURI(sData).replace(/\&/g, "%26"); }


а на стороне сервера

Код: Выделить всё

$val = $_GET['val'];
$val = htmlspecialchars($val, ENT_QUOTES);

и после чего, со спокойно душой записываем val в БД.

так?

[Хакер]

Нет не так.

Во-первых, это не защищает от SQL-инъекции, но об этом позже.

1) Нет никаких причин вызывать для данных функцию htmlspecialchars() перед тем как записать эти данные в БД. Данные в БД стоит записывать в том виде, в котором они пришли. (Причина такой организации объяснять не буду)

Если то, сколько места занимает база — не важно, а вывод данных из базы на страницу (конечному пользователю) происходит очень часто, то рациональнее использовать твой вариант. Т.е. скажем если есть большой текст, и он показывается на каждой странице сайта и берётся из базы, то тут логичнее хранить в базе уже обработанный с помощью htmlspecialchars вариант.

Другим случаем, когда такой вариант надо применять является случай, когда текст может содержать некоторые html-теги, но наряду с этим, может содержать теги, которые не должны отображаться как теги
Для примера можно рассмотреть phpBB2: там html-теги в постингах отображались как просто текст, но тем не менее, можно было вставить (вручную, правкой базы) в постинг html-код, который не превратится в "просто текст" при отображении топика. Вобщем-то, в phpBB2 была возможность разрешать некоторые html-теги для использования внутри постингов. Собственно для этого и было выбрано хранение в базу уже обработанного варианта.

Теперь насчёт SQL-инъекции.

Хитрецы могут сформировать такой GET-запрос, значения аргументов которого, будучи вставленными в твой SQL-запрос, раздробят его на две или более частей, среди которых может оказаться и drop database.

Нехитрецы могут сформировать строчку, содержащий такой символ (например одинарную кавычку), что при вставке этой строчки в SQL-запрос последний станет иметь невалидный синтаксис.

(Пример: $username = "Janna D'Ark"; $where_clause = "where u_name = '$username' and ...";)

Чтобы этого не произошло, все символы, которую в SQL имеют особый смысл, но должны быть истолкованы парсером запросов как обычные символы, следует заэкранировать.

В вопросе об экранировании есть несколько аспектов:

• В обычном PHP стандартным способ заэкранировать строчку является вызов функции addslashes(). Чтобы разэкранировать строчку, надо, соотвественно, вызывать stripslashes().
• Эти функции экранирует то, что сами считают нужными. Не исключено, что окажется, что они заэкранируют что-то, что не нужно (для исопльзования внутри MySQL), и наборот, забудут заэкранировать что-то, что должно быть заэкранировано для использования в MySQL).
  Поэтому, MySQL имеет свою функцию для экранирования, которая гарантировано заэкранирует все те символы, что должны быть заэкранированны именно для MySQL. Речь идёт о функции mysql_real_escape_string().
• В PHP есть такая фишка, как MagicQuotes. Это security-технология, которая сама (без твоего веления) экранирует все входящие в скрипт (т.е. потенциально опасные) данные. Дело в том, что эта фишка может быть во-первых либо включена, либо выключена. Во-вторых, она может обрабатыватьт только $_GET-параметры, только $_POST или только $_COOKIE. Все эти параметры поведения MagicQuotes устанавливаются в php.ini (параметры начинаются на "magic_quotes", например "magic_quotes_gpc").
  
  Понятно, что если входящие данные уже были заэкранированы (не нами), нам повторно экранировать их не нужно (потому что тогда в базу попадёт одно лишнее ненужное экранирование, что очень нехорошо). И наоборот, нельзя полагаться, что MQ включено и нам ничего экранировать не надо — MQ могут с успехом выключить.
  
  Чтобы узнать, подверглись ли параметры $_GET, $_POST, $_COOKIE (далее GPC-параметры) подвергнуты (MQ-экранированию), есть функция get_magic_quotes_gpc(). Если она возвращает true, то всё уже заэкранировано, в противном случае, нам надо экранировать всё самим.
  
  Как её использовать — твоё дело, может каждый раз вызывать её и делать проверку, но я в своём движке (который многие тут отказались называть движком, и признали фреймворком) сделал на самом-самом нижнем уровне следующее:
  
  

  Код: Выделить всё

  if($config['ssp']!='auto')
{
        if($config['ssp']=='force' || (!get_magic_quotes_gpc()))
        {
                $_GET    = security_add_gpc_array_slashes($_GET);
                $_POST   = security_add_gpc_array_slashes($_POST);
                $_COOKIE = security_add_gpc_array_slashes($_COOKIE);
        }
}

if($config['gpc_processing']!='auto')
{
        if(($config['gpc_processing']=='force') || (ini_get('register_globals') ))
        if(is_array($_GET))   {while(list($kkey)=each($_GET))   {unset($GLOBALS[$kkey]); }}
        if(is_array($_POST))  {while(list($kkey)=each($_POST))  {unset($GLOBALS[$kkey]); }}
        if(is_array($_COOKIE)){while(list($kkey)=each($_COOKIE)){unset($GLOBALS[$kkey]); }}
}

  
  
  (где security_add_gpc_array_slashes() — функция, рекурсивно обходящая дерево-массив, и квотящее в нём всё строковое)
  Здесь второй блок не имеет никакого отношения к MQ, но это тоже security-трюк против register_globals.
  
  Таким образом, мой движок обезопасивает сайт от того, какие настройки имеет PHP (и главное от того, что они внезапно кем-нибудь будут изменены). Так что для кода моих сайтов всегда абсолютно точно можно сказать, что все GPC-данные гаратировано экранированы.
  
• Помимо addslashes() и stripslashes() есть addсslashes() и stripсslashes(), которые экранируют то, что подлежит экранированию в языке С.