Как я могу кодировать / экранировать varchar, чтобы быть более безопасным без использования cfqueryparam? - PullRequest
Новая
       70

Как я могу кодировать / экранировать varchar, чтобы быть более безопасным без использования cfqueryparam?

3 голосов
/ 23 августа 2011

Как я могу кодировать / экранировать varchar, чтобы быть более безопасным без использования cfqueryparam?Я хочу реализовать то же поведение без использования <cfqueryparam>, чтобы обойти «Слишком много параметров было предоставлено в этом запросе RPC. Максимум - 2100».См .: http://www.bennadel.com/blog/1112-Incoming-Tabular-Data-Stream-Remote-Procedure-Call-Is-Incorrect.htm

Обновление:

  • Я хочу часть проверки / безопасности, без генерации подготовленного оператора.
  • Чтосамый сильный код / ​​побег, который я могу сделать с varchar внутри <cfquery>?
  • Что-то похожее на mysql_real_escape_string() может быть?

Ответы [ 6 ]

6 голосов
/ 24 августа 2011

Как уже говорили другие, эта ошибка, связанная с длиной, возникает на более глубоком уровне, а не в теге queryparam. И он предлагает некоторую ценную защиту и поэтому существует по причине.

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

SELECT name , 
       ..... , 
       createDate
FROM somewhere
WHERE (someColumn IN (a,b,c,d,e)
       OR someColumn IN (f,g,h,i,j)
       OR someColumn IN (.........));
2 голосов
/ 23 августа 2011

cfqueryparam выполняет несколько функций.

  1. Проверяет тип данных.Если вы говорите целое число, оно проверяет наличие целого числа, а если нет, то оно не позволяет ему передавать

  2. . Оно отделяет данные сценария SQL от исполняемого кода (этогде вы получаете защиту от внедрения SQL).Все, что передается в качестве параметра, не может быть выполнено.

  3. Он создает переменные связывания на уровне механизма БД для повышения производительности.

Вот какЯ понимаю cfqueryparam для работы.Вы рассматривали возможность сделать несколько маленьких звонков против одного большого?

1 голос
/ 24 августа 2011

Проблема не в cfqueryparam, а в самой MsSQL:

Каждый пакет SQL должен соответствовать предельному размеру пакета: 65 536 * Размер сетевого пакета.

Максимальный размер для запроса SQL Server? В пункте? Есть ли лучший подход

И

http://msdn.microsoft.com/en-us/library/ms143432.aspx

1 голос
/ 24 августа 2011

Первое, что я хотел бы задать себе: «Как, черт возьми, у меня получилось более 2100 параметров в одном запросе?».Потому что это само по себе должно быть очень очень большим красным флагом для вас.

Однако, если вы застряли с этим (либо из-за того, что он находится вне вашего контроля, либо из-за вашего уровня мотивации для решения ;-),тогда я бы рассмотрел:

  • идея временной таблицы, упомянутая ранее
  • для значений более определенной длины, просто нарезать их пополам и соединить обратно вместе с конкатенацией строк,Например:

*

SELECT *
FROM tbl
WHERE col IN ('a', ';DROP DATABAS'+'E all_my_data', 'good', 'etc' [...])

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

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

  • СЕРЬЕЗНО вернитесь к вашему требованию и посмотрите, есть ли способ не нуждаться в параметрах 2100+.Что вам на самом деле нужно сделать, что требует всего этого ???

1 голос
/ 23 августа 2011

Это проблема безопасности. Останавливает SQL-инъекции

Adobe рекомендует использовать тег cfqueryparam в каждом теге cfquery, чтобы защитить ваши базы данных от неавторизованных пользователей. Для получения дополнительной информации см. Бюллетень по безопасности ASB99-04, «Несколько операторов SQL в динамических запросах», по адресу www.adobe.com/devnet/security/security_zone/asb99-04.html и «Доступ и получение данных» в ColdFusion Developer. Руководство.

0 голосов
/ 10 сентября 2013

Несколько раз, когда я сталкивался с этой проблемой, мне удавалось переписать запрос, используя подвыборы и / или объединения таблиц. Я предлагаю попробовать переписать запрос таким образом, чтобы избежать параметра max.

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

<cfif ReFindNoCase("[^a-z0-9_\ \,\.]",arguments.InputText) IS NOT 0>
    <cfthrow type="Application" message="Invalid characters detected">
</cfif>

Код вызовет ошибку, если в текстовой строке будет обнаружен какой-либо специальный символ, кроме запятой, подчеркивания или точки. (Возможно, вы захотите разобраться с ситуацией, а не просто сгенерировать ошибку.) Я предлагаю вам изменить это по мере необходимости на основе ожидаемых или разрешенных значений в проверяемых вами полях. Если вы проверяете строку с целыми числами, разделенными запятыми, вы можете переключиться на использование более ограничивающего регулярного выражения, например "[^0-9\ \,]", которое будет разрешать только цифры, запятые и пробелы.

Этот ответ не ускользнет от персонажей, он не допустит их в первую очередь. Он должен использоваться для любых данных, которые вы не будете использовать с <cfqueryparam>. Лично я нашел в этом необходимость, только когда использовал поле динамической сортировки; не все базы данных позволят вам использовать переменные связывания с предложением ORDER BY.

...