Это не имеет никакого отношения к тому, где хранятся запросы. Это то, как запросы заполняются данными для изменения запроса. Допустим, у вас есть запрос, который принимает значение для предложения WHERE. Если вы не готовите запрос к выполнению должным образом, вы подвергаете код эксплуатации.
Я не думаю, что можно предотвратить манипулирование данными ресурса, и тогда даже код правильно реализован с помощью параметров, вы всегда можете манипулировать ресурсом и добавлять вредоносные SQL-операторы. Но это действительно очень теоретический сценарий. Может быть, я и ошибаюсь, но я так не думаю
Это можно сделать, но трудно.
Инъекция SQL становится возможной, когда ваши запросы подвергаются воздействию инъекции кода. Не имеет значения, как вы храните запросы, а как они выполняются. Это не принесет никакой пользы, если вы храните и загружаете SQL-запросы из файла или даже из сети, или храните их в файлах ресурсов или в памяти, если запрос подвергается инъекции, он будет введен с кодом.Цитата:Атаки с использованием SQL-инъекций возможно с помощью ресурсов(.файл resx).
var query = "SELECT * FROM table_name WHERE primary_column = '" + variable + "';Не имеет значения, исходит ли этот запрос от ресурса, сети или жестко закодирован внутри программы. Вам нужно изменить этот запрос, чтобы предотвратить инъекцию.
Вы должны писать запросы безопасным способом, например, рекомендуется использовать параметры. Вы также должны рассмотреть, может ли пользователь изменить любой из этих запросов или нет. Ваша программа должна заботиться о запросах, которые она выполняет.Цитата:Если sql-инъекция возможна, то как и где поддерживать все sql-запросы.
Я не думаю, что можно предотвратить манипулирование данными ресурса, и тогда даже код правильно реализован с помощью параметров, вы всегда можете манипулировать ресурсом и добавлять вредоносные SQL-операторы. Но это действительно очень теоретический сценарий. Может быть, я и ошибаюсь, но я так не думаю
Именно в этом и был смысл. Пользователь может легко изменять правильно реализованные и безопасные SQL-запросы, если они записаны в файлы ресурсов.
Они могут применить некоторые трюки, чтобы противостоять этому—помните, что эти глупые хаки требуются только в том случае, если SQL-запросы хранятся в файлах ресурсов, ни один здравомыслящий ум не будет этого делать.
Один из способов, который я могу придумать, - это проверить, соответствует ли запрос хэш-значению, сгенерированному защищенным запросом. Если вмешательство сделано, они могут прерваться. Но, конечно, был бы безопасный и лучший подход к этому.
Что касается хранения в файле ресурсов, то я просто следил за OP, в противном случае я не нахожу никаких причин для этого. :-)
Что, наконец, является аргументом для подписанных заявлений, даже я не очень доволен этим в данный момент. Во всяком случае сейчас 5 ;)
Спасибо, но ОП-это все-таки операция. ;-)