Рейтинг:
2
Eric Lynch
Вздох...забвение SQL-инъекции действительно кажется темой в этих постах. После ответа на предыдущий пост я поддержал ваши опасения...грустно видеть, что он продолжается :(
F-ES Sitecore
Откуда вы знаете, что код подвержен SQL-инъекции? Мы не можем видеть достаточно, чтобы знать наверняка.
Richard Deeming
Вы видели его(?) предыдущие вопросы?
Даже если вы этого не сделали, можно с уверенностью сказать, что кто-то, использующий конкатенацию строк вместо параметров, будет делать это не только с "безопасными" значениями.
F-ES Sitecore
Возможно, но мы все еще не можем сказать наверняка.
Richard Deeming
Как я уже сказал, Посмотрите на предыдущие вопросы ОП. Есть определенная закономерность!
F-ES Sitecore
Я действительно смотрел, но это не значит, что этот код подвержен SQL-инъекции. Сообщение, которое здесь дается, заключается в том, что конкатенация-это то, что делает ваш код подверженным SQL-инъекции, тогда как это не так и может дать людям неправильное представление о том, когда их код безопасен или нет.
Richard Deeming
Ожидать, что начинающие разработчики поймут тонкую разницу между "безопасной" и "небезопасной" конкатенацией в SQL-запросах, довольно оптимистично.
Да и зачем кому-то беспокоиться? Существует очень мало случаев, когда нетривиально использовать параметры, а параметры всегда "безопасны".
F-ES Sitecore
Вы (или, что более важно, человек, которому я на самом деле ответил :) ) все еще не знаете, был ли код подвержен SQL-инъекции, вот и все, что я говорю.
Richard Deeming
Всегда лучше предположить это является и скажите им, чтобы они использовали параметры, а не предполагали это не и скажите им, что можно объединить данные в команду. :)
F-ES Sitecore
Еще лучше сказать им, что это может быть ответственно, и всегда лучше использовать params, чем говорить им, что это ответственно и использовать params. Один фактически правильный и хороший совет, другой фактически неверный, даже если все еще хороший совет.
Eric Lynch
Мир-это неопределенное место. Тем не менее, выработка привычки не использовать параметры не дает никакой реальной выгоды и довольно большой недостаток.
Основываясь на сообщениях оперативников, я готов поспорить, что эта обратная сторона в конце концов укусит его. Обычно, с тех пор как он получил совет, это было бы хорошо для меня.
Однако в этом случае другие люди (его пользователи) потенциально также страдают от последствий. Поэтому я решительно поддерживаю попытку Ричарда предотвратить этот исход. Сначала он ответил на вопрос и только потом добавил предостережение.
Точно так же я не могу доказать, что вождение автомобиля с завязанными глазами приведет к аварии, но я бы определенно не советовал этого делать :)
F-ES Sitecore
Это к делу не относится, Вы сказали, что его код был открыт для SQL-инъекции, когда вы не знаете, было ли это на самом деле.
Ваш комментарий о том, что он, по крайней мере, ответил на этот вопрос, очень важен в данном случае, так как 9/10 я вижу, как людей ругают за то, что они не используют params, не обращаясь к фактическому вопросу, или люди публикуют использование params как фактическое решение, когда оно даже не устраняет исходную проблему. Можно добавить его как "и кстати...", но это не всегда делается.
Eric Lynch
Ummm...in справедливости ради, если вы перечитаете мой пост, я никогда на самом деле не говорил, что его код открыт для SQL-инъекций. Я уже говорил, что забвение об этом-это тема в постах. Основываясь исключительно на истории публикаций OPs, я придерживаюсь этого утверждения.
Что касается другой вашей точки зрения, меня также раздражают респонденты, которые проповедуют, не отвечая на вопрос. Я был получателем нескольких из этих ответов.
Однако здесь, в решении Ричарда, дело обстояло совсем не так. Он ответил на вопрос и дал отличный совет. Поэтому я придерживаюсь той поддержки, которую я предложил и там.
Это никогда не весело предлагать советы (или, по-видимому, поддержку :)). Ричард сделал это, на мой взгляд, совершенно правильно (сначала отвечай, а потом советуй).
Я бы также отметил, что ОП был свободен в своем ответе. Хотя у него нет никаких обязательств делать это.
Если бы это был я, то после того, как я получил ответы на ряд своих вопросов и увидел, что подобные проблемы возникают у людей с благими намерениями, я мог бы сказать что-то вроде: "Эй, спасибо, что ответили на вопрос. Я слышал вас о SQL-инъекции, но не волнуйтесь об этом в данном случае, потому что..."вставьте причину здесь".
Отсутствие такого ответа меня немного беспокоит. Опять же, он не обязан отвечать.
Но я все равно беспокоюсь. Что я могу сказать? Я очень беспокоюсь :)
Лично я надеюсь, что Ричард продолжит вести хорошую борьбу (пока он продолжает отвечать первым :)). Слишком многие компании в конечном итоге становятся мишенью этой так легко предотвращаемой атаки.
Во всяком случае, это самое лучшее, что я могу сделать, чтобы прояснить свой первоначальный ответ, поэтому я, вероятно, не буду отвечать дальше. Никто никогда не обвинял меня в том, что у меня отличные коммуникативные навыки :)
F-ES Sitecore
Классная история, братан, но, как я уже сказал, Никто не знает, Был ли его код открыт для SQL-инъекций или нет.
Рейтинг:
1
Goran Bibic
Решенный
SqlConnection con2 = new SqlConnection(cs);
string sqlquery = ("SELECT SUM(isnull(cast(REPLACE(TRY_CONVERT(int,TRY_CONVERT(float,iznos_bpdv),1), '#,0.00','')AS decimal(10,2)),0.00)) as UKUPNObpdv," +
" SUM(isnull(cast(REPLACE(TRY_CONVERT(float, TRY_CONVERT(float, pdv), 1), '#,0.00', '')AS decimal(10, 2)), 0.00)) as UKUPNOpdv," +
" SUM(isnull(cast(REPLACE(TRY_CONVERT(float, TRY_CONVERT(float, iznos_sa_pdv), 1), '#,0.00', '')AS decimal(10, 2)), 0.00)) as UKUPNOsapdv" +
" from mp_racun_roba" +
" where tip_robe = 'Roba (Generalno)' and id_fakture =" + id_fakture
);
SqlCommand command = new SqlCommand(sqlquery, con2);
con2.Open();
SqlDataReader sdr = command.ExecuteReader();
if (sdr.Read())
{
roba_bez_pdvTextBox.Text = sdr["UKUPNObpdv"].ToString();
roba_pdvTextBox.Text = sdr["UKUPNOpdv"].ToString();
roba_sa_pdvTextBox.Text = sdr["UKUPNOsapdv"].ToString();
}
con2.Close();