Как проверить безопасность params?

Question

[asdasda11]

route такого характера:
match '*path', to:'public#index'
Прийти могут разные параметры. Они, скажем так, динамические. Но мне нужно проверить каждый из них на безопасность, если так можно выразиться. Например, приходит params[:command]. Как мне проверить, что внутри параметра нет ничего хитрого? Т.е. ни скриптов, ни чего-то ещё. У меня почти сразу этот params[:command] отправляется в консоль операционки, т.е. будет исполняться в системе. А потом он же - полезет в БД и ещё будет показываться на странице. Выходит, что мне его проверять на каждом отдельном направлении или можно как-то разом?

Пример. Допустим придёт запрос: localhost:3000/command="rm -rf /"

Если его сразу отправлю в исполнение, то будет всё плохо. Но и проверять каждую команду не могу. А если в нём будет ещё xss и sql injection?.....

Answer 1

[mletov]

По поводу sql:
используйте параметризированные sql запросы или какой-нибудь ORM или конструктор sql запросов (по-моему, сейчас каждый язык/фреймворк что-нибудь такое имеет).

По поводу xss:
Вырезать регуляркой тег script, или вообще не выполнять дальше действий, если такой есть в запросе. Экранируйте, заменяйте теги спецсимволами и т д.
Некоторые продвинутые фреймворки сами не дают сохранить такой код, пишут что-то вроде "Обнаружено потенциально опасное содержимое запроса"

По поводу запроса:
Вы отправляете входящие данные в консоль. Как я понимаю, в любом случае это будет команда Linux, может вредоносная, может разрешенная, но команда.

Значит легкого пути не будет. Какие варианты можно рассмотреть:
1) Если количество разрешенных команд конечно, то просто присвойте им порядковые номера типа localhost:3000/command=1, localhost:3000/command=2...
И в зависимости от переданного номера выполняйте команду.
2) Если количество команд не ограничено, то тут разве что завести пользователя с ограниченными правами, чтобы все команды, переданные запросом, выполнялись под ним.
3) Если количество команд ограничено, но у них есть опциональные параметры (типа там путь к аудитории, имя создаваемого файла и т д), то, как уже предложил dimonchik2013, забейте все допустимые шаблоны в regex.

Comments

[asdasda11]

Хорошо, а на уровне рельсов что есть для подобных проверок? Ну для view это вроде html_safe или raw. А что-то ещё схожее есть? param.permit поможет не передать лишнее, валидаторы модели и ActiveRecord - не запихать в БД что-то лишнее. А что ещё есть?

[mletov]

asdasda11,
Я ни разу не Ruby программист, но первое, что выдает google:

XSS:
https://www.netsparker.com/blog/web-security/preve...

SQL:
https://blog.sqreen.io/preventing-sql-injections-i...

[asdasda11]

mletov, буду видимо тоже гуглить :) в любом случае - спасибо за помощь

[mletov]

asdasda11, пожалуйста:)

Answer 2

[Евгений Козлов]

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

Comments

[asdasda11]

Это понятно, но беда в том, что круг команд очень большой. По сути, мне нужно работать с сервером, отправляя ему любые команды. Т.е. это не массовый проект, который раздавать всем и вся, это для себя. Но я понимаю, что есть куча разных систем, которые сканируют ресурсы и могут узнать о таких возможностях. Т.е. это явная дыра, пусть и защищенная парой логин-пароль, токенами и т.д. Не суть.

Вопрос в другом. params как-то проверяется рельсами или нет? Если нет, то кем проверяется на уровне контроллеров?

[vsuhachev]

asdasda11, в вашем случае никакие проверки не помогут. Просто понадежнее защитите вход. Да и вообще непонятно зачем что-то городить, если есть ssh?

[asdasda11]

vsuhachev, какая к черту разница зачем? Вечно какой-то умник лезет с советами "зачем". Заказчик так хочет, значит так и нужно.

[vsuhachev]

asdasda11, если прибегнуть к аналогиям вы спрашиваете "как мне прострелить себе ногу?", ну вам посоветовали как. Ну, ок, пусть вы будете стрелять в ногу заказчика по его просьбе. Но вопрос "зачем" он будет у адекватных людей возникать всегда при взгляде на очередного умника, стреляющего себе в ногу. Не сочтите за наезд :)

[asdasda11]

vsuhachev, на любое "зачем" и "почему" - "потому что".

Answer 3

[Dimonchik]

регекспом оставляешь только разрешенные символы

Comments

[asdasda11]

сомнительное решение

[Dimonchik]

сомнительно в консоль пихать что попало

[asdasda11]

Если нельзя изменить подход, то приходится работать с тем что есть, поэтому вопрос остаётся открытым.

Answer 4

[Pazzik]

Не знаю ответа на ваш вопрос. Но знаю кто знает :) На hexlet есть какая то консоль из браузера для выполнения заданий. Она вполне полноценно работает. Можно у авторов в слаке узнать как у них это работает. У них это крутится в докере. Так что подозреваю секрет именно в этом.