2017-02-10 9 views
0

Я могу найти так много информации в Интернете о правильном и безопасном способе динамического создания параметризованных запросов. Однако на таких сайтах говорят только о параметризации предложения where.Насколько уязвим этот динамически созданный sql?

Ну, а как насчет других предложений инструкции sql? Смотрите следующее:

 string sql = string.Format(@"     
      SELECT MIN(TableName) as TableName, {0} 
      FROM 
      (
       SELECT 'Table A' as TableName, {0} 
       FROM {1} 
       UNION ALL 
       SELECT 'Table B' as TableName, {0} 
       FROM {2} 
      ) tmp 
      GROUP BY {0} 
      HAVING COUNT(*) = 1", columnList, tableA, tableB); 

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

  1. Элементов в выбранном пункте
  2. имени таблицы в предложении из

Вопрос: Насколько уязвим это для SQL-инъекции, которая может нанести некоторый урон?

Я не могу думать, что вредоносный хакер может ввести sql, что приведет к правильно сформированному исполняемому sql. Но опять же, я не специалист по sql.

+1

Каждый раз, когда любая часть запроса поступает из ненадежного источника, он уязвим для атаки SQL-инъекции. Например, если у вас есть строка кода выше 'tableA = someBool? «foo»: «bar»; «тогда нет никакого риска, потому что это будет либо foo, либо bar. Но если вы получаете значение 'tableA' из какой-либо формы представления или какого-либо другого внешнего источника, с которым вы не контролируете, тогда вы рискуете. То же самое касается других переменных, используемых в запросе. – itsme86

+1

использовать параметризованный запрос, то есть рекомендуемый подход –

+3

Параметры @EhsanSajjad sql не могут использоваться для имен таблиц и столбцов. – Amy

ответ

2

Как @Andrew заявляет в своем ответе, если на параметры (-ы) не влияет какой-либо пользовательский ввод, или в противном случае его проверяют/очищают, оно должно быть прекрасным.

Чтобы ответить на ваш вопрос о возможном правильно сформированном SQL-заявлении ... Единственными областями, которые привлекают внимание, являются потенциальные экранированные символы (такие как точка с запятой, которые могут быть технически размещены в любом месте блока команд) и/или что-то хорошо сформированное в разделах {1} и {2}.

+0

Я думаю, что {0} так же уязвим. '* FROM TableA; Таблица DROP TableB; SELECT * ' – Andrew

+0

@Andrew Я рассматриваю эту форму атаки/эксплоит как escape-символ (с запятой); который технически может идти в любом месте в командном блоке. Я обновлю свой ответ, так как ваш комментарий также верен. – Svek

5

Это действительно зависит от того, где columnList, tableA и tableB. Если они исходят из вашего кода, без ввода пользователем, то это довольно безопасно. Если пользователь указывает имена таблиц, вы должны быть готовы к встрече Little Bobby Tables.

В основном приложении C# для моей компании мы используем нечто похожее для объявления столбцов, но столбцы в таблицах SQL определены в классе для этой таблицы, поэтому мы можем создавать выборки, добавлять, обновлять и создавать таблицы из этого класса , Никогда пользователь не может определить эти столбцы.