Injection безопасного вызов IAxaptaRecord.ExecuteStmt()

Есть ли безопасный способ инъекции для вызова через axpata бизнес разъемInjection безопасного вызов IAxaptaRecord.ExecuteStmt()

string salesId = someObject.Text; 

IAxaptaRecord salesLine = ax.CreateRecord("SalesLine"); 
salesLine.ExecuteStmt("select * from %1 where %1.SalesId == '" + salesId + "'");

Если someObject.Text устанавливаются в следующем, я тогда уязвим для й ++ кода инъекция :

"SomeSalesOrder' || %1.SalesId == 'SomeOtherOrder"

есть ли способ параметризовать запрос, или было бы лучше, чтобы написать весь код доступа к данным непосредственно в X ++, а затем вызвать, что с COM?

источник

2009-05-18 holz

Там нет никакого способа, чтобы убедиться, что вы покрыли все случаи ...

Использование ExecuteStmt, скорее всего, неверный подход. Вы должны написать свой выбор или что-то другое в методе Axapta (с параметрами), затем вызовите этот метод.

источник

2009-05-18 07:13:32

Учитывая, что вы не используете литералы, поведение по умолчанию для простых запросов заключается в использовании заполнителей (параметризованных запросов), которые считаются безопасными. Для сложных запросов (объединений) единственным способом быть уверенным является использование подсказок ForcePlaceholders в соединениях. –

-2

вы должны заменить на 'to \' , например.

string salesId = someObject.Text.Replace("'", "\\'");

источник

2009-05-18 04:14:14

Я ищу способ параметризации обрабатываются фреймворком для обработки всех крайние случаи, а не только пример, который я дал – holz

Вы можете создать метод расширения для IAxaptaRecord что-то вроде «ExecuteParametizedStmt (string query, params object []) это будет принимать запрос в формате, ожидаемом от string.Format и построить его таким образом после выполнения требуемой работы над переменными (например, экранирование) –

Вся проблема заключается в обработке экранирования правильно. Если запрос был «select * from% 1.Id == {0}» (где {0} должен быть int), а затем «42 || 1 == 1» передается, инъекция все равно будет возникать после того, как я избежали его с помощью метода, который вы дали. Я не знаю всех случаев кросс-инъекций x ++ здесь, поэтому я не хочу писать свой собственный метод экранирования. Потому что, если я это сделаю, скорее всего, я что-то пропустил, и я только узнаю об этом, когда будет слишком поздно. Это для общедоступного веб-приложения с большим количеством конфиденциальной информации, поэтому мне нужно быть на 100%, чтобы не было риска инъекции. – holz

-2

Holz,

Вы можете использовать параметризованные ВЫБРАТЬ заявления с ключевым словом forcePlaceholder. Это поведение по умолчанию в X ++, но поскольку это поведение может быть переопределено для сложных объединений, рекомендуется неявно указывать подсказку forcePlaceholder.

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

С уважением, Velislav Маринов

источник

2009-05-18 20:36:33

'силодержатели' не решают проблему, указанную в вопросе. Использование литералов в X ++ как значения не представляет проблемы, поскольку значения цитируются ядром. –

Вы ошибаетесь. ForcePlaceholders создает параметризованный запрос, а ForceLiterals уязвим для SQL-инъекции. Проверьте технический документ безопасности MS. –

Техническая документация по безопасности: http://download.microsoft.com/download/b/6/e/b6e77418-cde2-4ed4-a920-60d7f2d17757/Microsoft%20Dynamics%20AX%20Writing%20Secure%20X++%20Code.doc Вопрос заключался в использовании прямого SQL через Business Connector, что плохо. Еще одна проблема связана с 'forceliterals' /' forceplaceholders'. Forceliteral - проблема, если котировки ядра можно обойти, что может быть трудно опровергнуть. –

Injection безопасного вызов IAxaptaRecord.ExecuteStmt()

ответ

Смежные вопросы