Обнаружил, что при просмотре отчета на сервер посылается SQL-запрос, который выполняет handler.php
Проблема даже не в том, что этот запрос видно А в том, что злоумышленник может послать на сервер произвольный запрос, который серверная часть послушно выполнит. А там может быть все что угодно, начиная от получения данных, заканчивая банальным их уничтожением.
http://asupb.ru/stimulsoft_query.png
Теоретически, конечно, надо бы под каждый отчет создавать на сервере отдельный скрипт, который знает, какие данные нужно посылать. А из вьювера отчетов посылать какой-то идентификатор...
М.б. есть какие-то более простые решения?
Вопрос по безопасности
-
- Сообщения: 4
- Зарегистрирован: 02 янв 2012, 22:47
- Откуда: Moscow
Вопрос по безопасности
Здравствуйте,
Данная проблема недавно обсуждалась. В этом месяце мы добавим специальный алгоритм, который будет дополнительно присылать на сервер специальный хэш запроса и строки подключения, что позволит защитить запрос на начальном уровне. Так же, немного позже будет добавлено опциональное сжатие и шифрование передаваемых данных.
Спасибо.
Данная проблема недавно обсуждалась. В этом месяце мы добавим специальный алгоритм, который будет дополнительно присылать на сервер специальный хэш запроса и строки подключения, что позволит защитить запрос на начальном уровне. Так же, немного позже будет добавлено опциональное сжатие и шифрование передаваемых данных.
Спасибо.
-
- Сообщения: 4
- Зарегистрирован: 02 янв 2012, 22:47
- Откуда: Moscow
Вопрос по безопасности
Доброе время суток. Как дела с доработкой по данной проблеме? IMHO, запросы, конечно нужно хранить на сервере, а из отчета просто посылать какой-либо идентификатор (хеш)
Вопрос по безопасности
Здравствуйте,
Доработку запланировано реализовать к официальной версии 2012.1, которая будет доступна в марте.
Спасибо.
Доработку запланировано реализовать к официальной версии 2012.1, которая будет доступна в марте.
В данный момент, в качестве обходного пути это можно реализовать - в отчёте вместо запроса передавать какой-либо уникальный идентификатор запроса, а на сервере его заменить на реальный запрос (файл handler.php, команды RetrieveColumns и LoadData).IMHO, запросы, конечно нужно хранить на сервере, а из отчета просто посылать какой-либо идентификатор (хеш)
Спасибо.
Вопрос по безопасности
Здравствуйте,Vladimir писал(а): В данный момент, в качестве обходного пути это можно реализовать - в отчёте вместо запроса передавать какой-либо уникальный идентификатор запроса, а на сервере его заменить на реальный запрос (файл handler.php, команды RetrieveColumns и LoadData).
если отчет использует вот такого плана запрос:
select *
from table
where field_date between '{dStart.ToString("yyyy-MM-dd")}' and '{dEnd.ToString("yyyy-MM-dd")}'
dStart, dEnd - переменные в отчете ( которые, как я понял, меняются на значения на клиентской стороне )
речь об изменении переменных на панели самого вьювера...
( без передачи их в query_string-е )
т.е. если прописать ИД запроса в дизайнере, то значения переменных не будут заменены и на сервер придет запрос без изменений.
А после отработки sti_parse_query_parameters запрос превратится в :
select *
from table
where field_date between '' and ''
Собственно вопрос: так ли это ? и можно это как-нибудь победить ?
(чтобы работать через запросы, которые лежат в своей БД,
чтобы вьювер передавал только уникальный ИД запроса и чтобы при этом функционал с переменными работал по-прежнему )
Еще не готова ?Vladimir писал(а): Доработку запланировано реализовать к официальной версии 2012.1, которая будет доступна в марте.
Вопрос по безопасности
Здравствуйте,
Спасибо.
Доработка готова, обновление будет доступно в официальном релизе 2012.1, который запланирован на понедельник, 2 апреля.Еще не готова ?
Мы добавили новую опцию PassVariablesInUrl, при установке в True значения переменных, запрашиваемых у пользователя на панели переменных, будут дублироваться в URL запросе. Затем в PHP скрипте можно будет получить эти значения и подставить в SQL запрос.Собственно вопрос: так ли это ? и можно это как-нибудь победить ?
Спасибо.