| Контроль и проверка команд программирования |
|
Отличия между двумя рассматриваемыми здесь видами программирования имеют большое значение и с точки зрения безопасности. В автономной настольной прикладной программе все возможные команды, как правило, определены заранее. Они чаще всего выбираются щелчком кнопкой мыши из списка или меню. Даже если команды набираются вручную, они обычно проверяются на достоверность по заранее составленному списку возможных команд, и если команда окажется недостоверной, появится сообщение об ошибке.
В отличие от настольных прикладных программ, при написании таких веб-программ, как Joomla, приходится решать две непростые задачи. Прежде всего, веб-сайт открывается для всего сообщества пользователей Интернета, а среди них, к сожалению, имеются отдельные злонамеренные личности, пытающиеся раскрыть пароль администратора, испортить содержимое веб-сайта, заменив, например, некоторые его файлы своими собственными, или вообще вывести сайт из строя, разрушив информацию в его базе данных. Все это требует принятия практических мер защиты от подобных несанкционированных вмешательств в нормальную работу веб-сайта.
Еще одна трудная задача состоит в том, что количество команд, входящих в запрос, нельзя ни контролировать, ни ограничить. Как правило, команда представляет собой сочетание URL с рядом возможных значений полей из HTML-формы. Пользователи зачастую вводят команды, просто щелкая кнопкой мыши на ссылке или кнопке отправки формы, а следовательно, они всегда выдают действительные команды.
Но вполне возможно, что пользователь совершенно осознанно попытается ввести команду, чтобы сделать что-нибудь необычное или недозволенное, например, набрать URL вручную или изменить HTML-форму в окне браузера. К сожалению, веб-сервер не может ничего сообщить, выбрал ли пользователь ссылку или набрал URL вручную. И поэтому нельзя каким-то универсальным способом определить, заполнил ли пользователь форму и нажал кнопку ее предъявления или же видоизменил форму, чтобы передать какие-то данные со злым умыслом.
Ради перестраховки приходится всегда допускать, что команды, поступающие в запросе, могут быть специально предназначены для совершения атаки на веб-сайт, а следовательно, их нужно непременно проверить на достоверность, прежде чем выполнить.
Допустим, имеется простая система, в которой любой посетитель веб-сайта может вводить комментарии к статьям, хотя утверждать их разрешается только зарегистрированным пользователям сайта. Комментарии не появятся на веб-сайте до тех пор, пока не будут утверждены. Следовательно, требуется организовать какую-то элементарную защиту против появления на веб-сайте неуместных комментариев.
Для целей данного примера выберем два поля: одно — для отображения комментариев, а другое — для сообщения об их утверждении или неутверждении. Реализовать это можно двумя способами. Когда отображается форма, мы должны проверить, зарегистрирован ли пользователь.
Итак, перед отображением формы мы должны проверить, зарегистрирован ли текущий пользователь, т.е. имеет ли он полномочия на утверждение комментариев к статьям. Если он не зарегистрирован, поле Approved (Утверждено) пропускается, а в форме отображается только поле Comment (Комментарий). Таким образом, незарегистрированные пользователи вообще не увидят поле Approved, а следовательно, не смогут установить одноименный флажок в форме.
На первый взгляд, такое проектное решение устраняет всякую возможность утверждения комментариев незарегистрированными пользователями, но на самом деле это не совсем так. Любой, разбирающийся в веб-программировании, может очень легко отредактировать HTML-разметку страницы в такой программе, как Firebug или Web Developer, чтобы отобразить на ней поле Approved, установив в нем флажок в состояние "утверждено". Предъявленная таким образом форма окажется утвержденной якобы зарегистрированным пользователем. Веб-серверу ничего не известно, была ли форма изменена до нажатия кнопки ее предъявления. Он просто обнаруживает данные этой формы, полученные среди прочих сведений в запросе.
Таким образом, данное проектное решение имеет серьезную брешь в защите. Как же ее устранить? Для этого можно, в частности, организовать дополнительную проверку перед обновлением базы данных. Несмотря на то что незарегистрированный пользователь не может предъявить форму с флажком, установленным в поле Approved, мы, тем не менее, должны проверить этот факт еще раз, прежде чем записывать комментарии в базе данных. С этой целью мы должны убедиться в том, что пользователь зарегистрирован. И если он не зарегистрирован, мы можем всегда сбросить флажок в поле Approved и только после этого сохранить данные формы в базе данных.
Благодаря этому недействительные данные не будут сохранены в базе данных, даже если незарегистрированный пользователь незаконно добавит поле Approved в предъявленную им форму, а следовательно, он не сможет нанести никакого вреда ни веб-сайту, ни тем, кто будет читать публикуемые на нем статьи.
Понравился материал? Пригодилась информация? Плюсани в социалки!
Теги:
|
| Похожие новости | |
|
|