Как я должен предотвратить злоупотребления при использовании web.database web.py? - PullRequest
2 голосов
/ 09 декабря 2011

Я пишу быстрое приложение web.py и беру данные из web.input ...

import web
urls = (
    '/', 'something',
)
app = web.application(urls, globals())
db = web.database(dbn='postgres', db='database', user='username', password='password', host='127.0.0.1')
class something:
    def GET(self):
        i = web.input()
        return db.select('foo.table', where="column=$variable", vars={'variable':i.input, })
if __name__ == "__main__": app.run()

Должен ли я беспокоиться о передаче i.input в db.select (или запросе и т. Д.), Как я делаю как часть vars? Возможности SQL-инъекций и т. Д.?


Edit: Я сам играл с этим, пытаясь добиться чего-то неприятного. Например, при игре с кавычками http://localhost:8080/?id=13' или 'x' = 'x приводит к тому, что sql с хорошим экранированием отображается в исключениях:

<sql: 'select * from foo.table where id = "13\' or \'x\'=\'x"'>

Я попробовал несколько других распространенных тестов, которые предлагает интернет, и я думаю, что я вполне доволен, что web.py занимается санитарией ... Кто-нибудь еще сможет прокомментировать?

Ответы [ 3 ]

6 голосов
/ 09 декабря 2011

http://webpy.org/cookbook/query говорит:

Чтобы предотвратить атаки с использованием SQL-инъекций, db.query также принимает "vars" синтаксис, как описано в db.select:

results = db.query("SELECT * FROM users WHERE id=$id", vars={'id':10})

Это ускользнет от пользовательского ввода, если вы доверяете им как "id" переменная.

Так что, я думаю, все так просто.

Конечно, я понимаю, что мне все еще нужно проверить ввод пользователя, если я собираюсь вставить его местами ...

4 голосов
/ 18 декабря 2011

«Приятно избежавший sql», который вы видите, не имеет значения, так как он никогда не отправляется ядру базы данных.

Во всех случаях, если вы вручную не вставите значения в строку запроса SQL, вы защищены от внедрения SQL. Это включает в себя методы выбора / вставки / обновления / удаления, а также стиль замены $variable_name. В обоих случаях запрос SQL не полностью собран как текст, но должным образом преобразован в подготовленный оператор SQL и скомпилирован механизмом БД как таковым. Только после этого параметры фактически подставляются для выполнения оператора. Поэтому, если вы не строите строку SQL-запроса и / или ее части вручную, используя ненадежные данные, вы в безопасности.

К сожалению, я не могу предоставить ссылку на какой-либо источник лучше, чем исходный код модуля , так как это был мой единственный источник информации.

0 голосов
/ 09 декабря 2011

Да, потому что кто-то может изменить переменную, особенно если это происходит из URL, чтобы сказать что-то вроде "selecte * из таблицы, где id = [variable + DELETE TABLE [. Это пример внедрения SQL. Это особенно важно, если пользователь имеет какое-либо представление о том, как называются ваши внутренние объекты данных.

Я не совсем уверен, как Python будет обрабатывать параметризацию переменных для оператора SQL, но мне пришлось выполнить аналогичные исправления безопасности для сайтов Cold Fusion и ASP.net.

...