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

Как я могу кодировать / экранировать 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 ответов

Решение

Как уже говорили другие, эта ошибка, связанная с длиной, возникает на более глубоком уровне, а не в теге 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 (.........));
Источник

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

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

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

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

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

Источник

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

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

Источник

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

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

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

*

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

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

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

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

Источник

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

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

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

А также

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

Источник

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

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

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

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

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

Источник
Другие вопросы по тегам