Что я должен делать, чтобы защитить свой веб-интерфейс?

Question

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

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

У меня есть пользовательский интерфейс для сбора информации от вошедшего в систему пользователя, и часть этой информации отображается на страницах HTML. Мой сайт реализован с помощью PHP / MySQL на задней части и некоторых javascript-компонентов на передней части. Меня интересуют любые предложения / советы о том, как мне следует решать любые из следующих вопросов:

• Межсайтовый скриптинг: я надеюсь, что это будет достаточно просто для меня, так как я не поддерживаю размеченный ввод, просто текст. Должен ли я просто искать [A-Za-z] * и выбрасывать все остальное? Я довольно не осведомлен о типах атак, которые можно использовать здесь, поэтому я хотел бы услышать ваш совет.

• Внедрение SQL: здесь я использую параметризованные запросы (mysqli), так что я надеюсь, что я в порядке в этом отделе. Нужно ли проводить дополнительную проверку данных, введенных пользователем, чтобы защитить себя?

• Поведение троллейбуса: я поддерживаю полилинии, нарисованные пользователем на карте Google, поэтому (опять же, если мне повезет получить трафик), я ожидаю увидеть несколько нарисованных от руки фаллиц по всей Западной Европе. Я планирую внедрить некоторую модерацию, управляемую пользователем (пометить недопустимый стиль SO), но меня заинтересуют любые другие предложения по предотвращению такого поведения.

• Логины: Моя текущая система входа в систему - довольно простая веб-форма, MySQL-запрос в PHP, проверка пароля в кодировке mp5 и сохраненный файл cookie сеанса. Я надеюсь, что система достаточно проста, чтобы быть безопасной, но мне интересно, есть ли здесь уязвимости, о которых я не знаю?

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

Answer 1

Ваша первая проблема заключается в том, что вы обеспокоены своим пользовательским интерфейсом. Простое правило, которое следует соблюдать, это то, что вы никогда не должны предполагать, что отправленные данные поступают из созданного вами пользовательского интерфейса. Не доверяйте входящим данным, и дезинфицируйте выходящие данные. Используйте PHP strip_tags и / или htmlentities.

Определенные символы (<,>, ", ') могут испортить ваш HTML и разрешить внедрение, но это должно быть разрешено. Особенно в паролях. Используйте htmlentities, чтобы разрешить использование этих символов. Подумайте, что произойдет, если определенные символы выводились без "экранирования".

Проверки и проверки на основе Javascript следует использовать только для улучшения взаимодействия с пользователем (т. Е. Предотвращения перезагрузки страницы). Не используйте eval, кроме как в крайнем случае.

Answer 2

Межсайтовый скриптинг может быть легко реализован с помощью htmlentities, есть также функция, называемая стрип-тегами, которая удаляет теги из сообщения, и вы заметите, что это позволяет вам вносить в белый список определенные теги. Если вы решите разрешить использование определенных тегов в будущем, имейте в виду, что атрибуты этих тегов не очищаются каким-либо образом, это можно использовать для вставки javascript на страницу (onClick и т. Д.) И на самом деле не рекомендуется. Если вы хотите использовать форматирование в будущем, я бы порекомендовал реализовать язык форматирования (например, [b] для жирного шрифта или чего-то подобного), чтобы пользователи не могли просто вводить HTML-код на страницу.

Внедрение SQL также легко выполняется, поскольку вы можете подготовить операторы и затем передать пользовательские данные в качестве аргументов подготовленного оператора. Это остановит любой пользовательский ввод от изменения оператора sql.

CSRF (Подделка межсайтовых запросов) - часто упускаемая из виду уязвимость, позволяющая злоумышленнику отправлять данные из учетной записи жертвы с помощью формы. Обычно это делается либо указанием строки get вашей формы для img src (изображение загружается для жертвы, get загружается и форма обрабатывается, но пользователь не знает). Кроме того, если вы используете post, злоумышленник может использовать javascript для автоматической отправки скрытой формы, чтобы сделать то же самое, что и выше. Чтобы решить эту проблему, вам нужно сгенерировать ключ для каждой формы, оставить один в сеансе и один в самой форме (как скрытый ввод). Когда форма отправлена, вы сравниваете ключ из ввода с ключом в сеансе и продолжаете работу, только если они совпадают.

Некоторые охранные компании также рекомендуют использовать атрибут autocomplete = "off" в формах входа, чтобы пароль не сохранялся.

Answer 3

Я хотел бы заняться чем-то еще, кроме того, чтобы разрешить [A-Za-z] * на вашу страницу. Тот факт, что вы не собираетесь разрешать какую-либо разметку форматирования, не означает, что она вам не понадобится. Лично я ненавижу переписывать вещи, которые я не проектировал, чтобы приспособиться к будущим потребностям.

Возможно, вы захотите собрать белый список принятых тегов и добавить / удалить из него, если необходимо, или изучить кодирование любой разметки, представленной в виде обычного текста.

Answer 4

Против XSS достаточно htmlspecialchars, используйте его, чтобы очистить вывод. SQL-инъекция: если mysql анализирует ваш запрос до того, как добавляет параметры, afaik невозможно внедрить что-либо вредоносное.