Безопасность и дезинфекция пользовательского ввода с ограниченным контролем над целевыми показателями «выход»

Недавно я присоединился к команде, работающей над приложением со встроенной системой чата. Это стандартная система чата, которая позволяет клиентам общаться, а сообщения направляются через центральный сервер.

Обычно при работе с текстом пользователя рекомендуется «escape-on-output» вместо «escape-on-input». Существует множество примеров ( 1 , 2 , 3 ) относительно того, почему это лучше, но в основном это сводится к: вам нужно дезинфицировать текст в зависимости от контекста, в котором он используется. Если вы вставляете сообщение пользователя чата в базу данных, вам следует сбежать для SQL и использовать подготовленные операторы. Если вы отображаете сообщение чата в веб-браузере, вам следует скрыться для HTML. Etc.

К сожалению, ни одна из вышеперечисленных проблем безопасности не была обнаружена до недавнего времени. (Да, действительно).

Быстрое «взломать» решение состояло в том, чтобы фильтровать сообщения чата пользователя, когда они были получены сервером, и вычеркнуть любой, возможно, нечестивый символ (<,>, ", ', {, }, \ и т. д. Это привело к множеству жалоб пользователей, поскольку их пунктуация теперь волшебным образом исчезнет при отображении в канале чата.

Я хочу верить, что мы можем сделать лучше, чем этот текущий «взлом», и позволить пользователям вводить любой текст, который они хотят в безопасной среде.

Проблема в том, что я работаю с кажущимися невозможными ограничениями. У нас есть многочисленные версии клиента, распространяемые на многие устройства, тысячи пользователей и медленная скорость принятия новых версий. Существует много фрагментации, и мы не можем заставить клиентов обновляться.

Менеджмент не заботится о пользовательском опыте, и в основном сказал мне:

  

Внедрить решение для защиты от всех возможных типов   вредоносный пользовательский ввод без необходимости касаться клиентов. О, а также   защищать от любого будущего «неосторожного» разработчика, который не знает, что   они делают и могут случайно попробовать eval() пользовательский чат   сообщение.

(Да, на самом деле мне сказали, что последняя часть).

Есть ли лучшее решение этой проблемы, которое обеспечит немного лучший пользовательский интерфейс?

Спасибо за чтение.

1 голос | спросил smg 7 J000000Tuesday15 2015, 05:51:13

2 ответа


2

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

Итак, вы можете вырезать любой символ, а вместо этого сделать ввод безопасным для вставки в БД. Это должно быть простым и легко проверить.

Затем вам нужно изменить процедуры, которые вытаскивают данные из БД и дезинфицируют их для клиента. Если вы не можете обнаружить клиентское приложение (например, толстый клиент или веб-сайт), вам придется применять самый низкий общий знаменатель ко всем выводам, избегая всех возможностей.

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

ответил gbjbaanb 7 J000000Tuesday15 2015, 11:36:26
2

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

Вы не упомянули, в каком формате данные переносятся на клиентов, но если они находятся в форме HTML, вы считали, что заменяете на определенные символы своей формой сущности HTML? Вместо того, чтобы удалить их все вместе. То есть > становится &gt; и т. д. От клиента в перспективе они все равно смогут отправлять и получать символы без слов, но без риска XSS. Это была бы моя рекомендация.

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

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

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

ответил user4495048 7 J000000Tuesday15 2015, 16:42:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132