Предисловие
В модели разработки разделения фронт-энда и бэк-энда наиболее очевидным изменением с точки зрения ролей и функций разработки: в прошлом студенты фронт-эндов, которые несут ответственность только за разработку в среде браузера, необходимые для изучения уровня сервера и записи кода сервера. И основной вопрос перед нами - как обеспечить веб -безопасность?
В этой статье предлагаются решения проблем безопасности, с которыми сталкиваются передний и контрольный режим разделения в веб-разработке фронт-конца, а также контрмеры и меры предосторожности.
Защита атаки сценариев поперечного сайта (XSS)
Проблемы и решения
Сценарии поперечного сайта (XSS, поперечные сценарии) является наиболее распространенным и основным методом атаки веб-сайтов. Злоумышленник может публиковать данные, содержащие атакующий код на веб -странице. Когда браузер видит эту веб -страницу, определенный сценарий будет выполняться в качестве идентификации и разрешений пользователя браузера. XSS может быть легче изменен, пользовательские данные крадут, пользовательская информация и вызывают другие типы атак, такие как атаки CSRF.
Основной способ предотвращения атак XSS состоит в том, чтобы гарантировать, что любой вывод данных на HTML -страницу избежается в HTML (HTML Escape). Например, следующий код шаблона:
Кода -копия выглядит следующим образом:
<textarea name = "description"> $ description </textarea>
Описание $ в этом коде является переменной шаблона (синтаксис переменных, определенных в разных шаблонах, отличается, вот просто диаграмма). Данные, представленные пользователем, могут ввести часть кода, содержащего «JavaScript», чтобы сделать результат приведенного выше оператора шаблона, станет следующим результатом:
Кода -копия выглядит следующим образом:
<textarea name = "description">
</textarea> <script> alert ('hello') '</script>
</textarea>
Приведенный выше код, отображаемый в браузере, выполнит код JavaScript и предупреждает Hello на экране. Конечно, этот код безобиден, но злоумышленник может создать JavaScript для изменения информации пользователя или кражи данных cookie.
Решение очень простое, то есть HTML избежать значения $ описания. Выходной код после побега выглядит следующим образом
Кода -копия выглядит следующим образом:
<textarea name = "description">
</textarea> <script> alert (привет!) </script>
</textarea>
Вышеуказанный сбежал HTML -код не вреден.
Решение на полпути
Убежать от всех пользовательских выходных данных на странице
Существует несколько ситуаций и методов спасения данных:
1. Escape с использованием механизма, предоставленного внутри шаблона
Midway использует Kissy xtemplate в качестве языка шаблона.
В реализации xtemplate данные шаблона представляют собой синтаксис анализации с использованием двух кронштейнов ({{val}}). По умолчанию данные сбежались HTML, поэтому разработчики могут писать шаблоны, как это:
Кода -копия выглядит следующим образом:
<textarea name = "description"> {{description}} </textarea>
В Xtemplate, если вы не хотите, чтобы выходные данные избегали, вам необходимо использовать три кронштейна ({{{val}}}).
2. однозначно вызовут функции побега на полпути
Разработчики могут напрямую вызвать метод побега HTML, предоставленный Midway в программе или шаблоне Node.js, чтобы избежать отображения отображаемых данных, следующим образом:
Метод 1: HTML Escape Data в программе node.js
Кода -копия выглядит следующим образом:
var security = require ('midway-security');
// Данные с сервера, например, {html: '</textarea>', другие: ""}
data.html = security.escapehtml (data.html);
xtpl = xtpl.render (data);
Метод 2: HTML Escape HTML -данные в шаблоне
Кода -копия выглядит следующим образом:
<textarea name = "description"> security.escapehtml ({{{description}}}) </textarea>
Примечание. Security.escapehtml используется для побега только тогда, когда данные не сбежаются внутри шаблона. В противном случае шаблон внутренней и программа будет дважды избегать наложения, что приведет к выводу, который не соответствует ожиданиям.
Рекомендуется: если вы используете xtemplate, рекомендуется использовать встроенный {{}} шаблон, чтобы сбежать напрямую; Если вы используете другие шаблоны, рекомендуется использовать Security.escapehtml для побега.
Отфильтруйте богатый текст вывод пользователей на странице
Вы можете подумать: «На самом деле, я просто хочу вывести богатый текст, например, некоторые доски объявлений и форумы, чтобы предоставить пользователям какой -то простой размер шрифта, цвет, фон и другие функции. Так как мне справиться с таким богатым текстом, чтобы предотвратить XSS?»
1. Используйте функцию Richtext, предоставленную безопасностью в Midway
Midway предоставляет метод Richtext, который специально используется для фильтрации богатого текста и предотвращения уязвимостей, таких как XSS, фишинга и кража cookie.
Есть доска объявлений, и код шаблона может быть следующим:
Кода -копия выглядит следующим образом:
<div>
{{{сообщение}}}
</div>
Поскольку сообщение - это входные данные пользователя, содержимое ее платы сообщений содержит богатую текстовую информацию, здесь три скобки используются в Xtemplate, а HTML -выбеги не выполняются по умолчанию; тогда данные, введенные пользователем, следующие:
Кода -копия выглядит следующим образом:
<script src = "http://eval.com/eval.js"> </script> <span style = "color: red; spect-size: 20px; положение: исправлено;"> Я оставляю сообщение </span>
Если вышеупомянутые богатые текстовые данные напрямую выводят на страницу, это неизбежно приведет к инъекции JS с сайта Eval.com на текущую страницу, вызывая атаку XSS. Чтобы предотвратить эту уязвимость, мы просто называем метод безопасности.
Призыв метод похож на escapehtml, и есть два способа
Метод 1: Вызов непосредственно в программе Node.js
Кода -копия выглядит следующим образом:
message = security.richtext (сообщение);
var html = xtpl.render (сообщение)
Метод 2: вызов в шаблоне
Кода -копия выглядит следующим образом:
<div>
Security.richtext ({{{message}}}))
</div>
После вызова метода безопасности Richtext, окончательный вывод выглядит следующим образом:
Кода -копия выглядит следующим образом:
<div>
<span style = "color: красный; размер шрифта: 20px;"> Я оставляю сообщение </span>
</div>
Сначала видно: тег сценария, который приведет к тому, что атаки XSS будут отфильтрованы напрямую; В то же время позиция атрибута CSS: исправлена; Стиль в теге в стиле также отфильтрован. Наконец, безвредный HTML -богатый текст выводится
Узнайте о других способах потенциально привести к атакам XSS
В дополнение к возможной атаке XSS в шаблоне страницы есть несколько других способов в веб -приложениях, которые также могут быть рискованными.
1. Уязвимость на странице ошибок
Если страница не может быть найдена, система может сообщить о ошибке 404, например: http: // localhost/page/not/не найден
404 НЕТФОВАТЬ
Page/page/not/не найдено.
Очевидно, что злоумышленник может использовать эту страницу для построения подобного соединения, http: // localhost/%3cscript%3ealert%28%27Hello%27%29%3c%2fscript%3e и заманит жертву, чтобы щелкнуть; Если страница ошибки не избегает выходной переменной, то будет выполнен <Script> alert ('hello') </script> в подключении.
В экспрессе метод отправки страницы 404 заключается в следующем
res.send (404, «Извините, мы не найдем это!»)
Здесь разработчики должны обратить внимание на обработку страницы ошибки (404 или другой статус ошибки). Если возвращаемое содержимое сообщения об ошибке содержит информацию о пути (на самом деле, чтобы быть более точной информацией пользователя), вы должны выполнить ascoverhtml.
Впоследствии механизм безопасности обработки ошибок будет завершен на уровне Midway Framework.
Дополнительные примечания для решений на полпути
Другие шаблонные двигатели
Midway поддерживает шаблоны xtemplate по умолчанию, но в будущем он может также поддерживать другие шаблоны: такие как нефрит, усы, EJS и т. Д. В настоящее время в основных шаблонах, по умолчанию и не весецированные методы написания переменных, и разработчики должны уделять особое внимание своей безопасности.
Другая поддержка побега
В дополнение к обычным и богатым выводу текстовых данных на странице некоторые сценарии также включают в себя другие ситуации, которые могут потребовать побега. Midway предоставляет следующие часто используемые методы побега для разработчиков:
Escapehtml фильтры символов в указанном HTML для предотвращения уязвимостей XSS
JSENCODE JavaScript Escape из строк ввода. Unicode Escape из китайца, отдельные цитаты и двойные цитаты побега
EscapeJson не разрушает функцию Escape структуры JSON и выполняет только обработку EscapeHTML на имя и дале в структуре JSON
Escapejsonforjsvar - это понятно
Примеры следующие
Кода -копия выглядит следующим образом:
var jsontext = "{/" <script>/":/" <script>/"}";
console.log (securityutil.escapejson (jsontext)); // {"<cript>": "<cript>"}
var JsonText = "{/" hello/":/" <script>/"}";
console.log (securityUtil.escapejsonforjsvar (jsontext)); // {/"/u4f60/u597d/":/"<script>/"}
var str = "alert (/" hello/")";
console.log (securityutil.jsencode (str)); // alert (/"/u4f60/u597d/")
Профилактика атаки подделки по перекрестным запросам (CSRF)
Проблемы и решения
Определение терминов: форма: в целом относится к форме, используемой браузером для отправки данных на клиенту; Включая тег, данные представления AJAX, данные подачи формы и т. Д., А не теги формы, равные HTML.
Подделка по перекрестному запросу (CSRF, подделка по перекрестному запросу) является еще одной общей атакой. Злоумышленник создал запрос различными методами и подражал поведению пользователя по подаче форм, тем самым достигнув цели изменения данных пользователя или выполнения конкретных задач.
Чтобы притворяться пользователем, атаки CSRF часто объединяются с атаками XSS, но можно использовать другие средства: например, чтобы побудить пользователей нажимать на ссылку, содержащую атаку.
Идея решения атак CSRF разделена на два шага.
1. Увеличьте сложность атаки. Получить запросы легко создать. Пользователи могут инициировать запросы типа GET, нажав на ссылку. Запросы на почту относительно сложны. Злоумышленники часто должны использовать JavaScript для их реализации. Следовательно, обеспечение того, чтобы формы или серверные интерфейсы приняли только запросы на отправку после типа, может повысить безопасность системы.
2. Проверка подлинности запроса, чтобы убедиться, что запрос действительно был заполнен форму или инициировал запрос и представлен пользователем, а не выдел третьей стороной.
Процесс нормальной информации, изменяющий пользователь, заключается в следующем
Пользовательские запросы на изменение информации (1) -> Веб -сайт отображает измененную информацию пользователя (2) -> Пользователь модифицирует информацию и представляет (3) -> Веб -сайт принимает измененные данные и сохранения пользователя (4)
Атака CSRF не пойдет на этот маршрут, но будет напрямую поддерживать информацию о представлении пользователя на шаге 2.
Пропустите непосредственно к шагу 2 (1) -> Получите информацию, которая будет изменена, и отправить (2) -> Веб -сайт принимает злоумышленника для изменения данных параметра и сохранения (3)
Пока эти две ситуации можно различить, атаки CSRF могут быть предотвращены. Так как это отличить? Это должно проверить информацию, представленную на шаге 2, чтобы убедиться, что данные поступают из формы на шаге 1. Конкретный процесс проверки заключается в следующем:
Пользовательские запросы на изменение информации (1) -> Веб -сайт отображает пустую форму, используемую для изменения информации. Форма содержит специальный токен и сохраняет токен в сеансе (2) -> Пользователь изменяет информацию и передает ее и отправляет обратную информацию о токене на сервер (3) -> Веб -сайт сравнивает токен, отправленный пользователем и токеном в сеансе. Это должно быть последовательным. Затем данные, измененные пользователем, принимаются и сохраняются.
Таким образом, если злоумышленник подделал информацию, которая будет изменена и представлена, он не сможет напрямую доступ к сеансу, поэтому он не сможет получить фактическое значение токена; Если запрос был отправлен на сервер, когда сервер выполнял проверку токенов, будет обнаружено, что он непоследователь, и запрос был непосредственно отклонен.
Midway Solutions
Отключить форму подачи
Если сервер не принимает данные формы, представленные GET, он вызовет большие трудности для злоумышленника; Поскольку очень легко построить атрибут href a-label или атрибут IMG-Label SRC на странице, чтобы построить запрос, но если вы хотите его отправить, вы должны использовать скрипт для его реализации.
Проверьте запросы с токеном CSRF
Поскольку Midway не включает в себя логику распределенного сеанса Taobao и проверки токенов, в средней структуре только токены пересылаются между сервером и клиентом и не выполняют фактическую проверку. Процесс заключается в следующем:
Впоследствии: в середине, после распределенного сеанса Node.js и Taobao подключено, вы можете рассмотреть возможность автоматического выполнения проверки токенов на промежуточном уровне; В конце концов, чем раньше выполняется проверка безопасности, тем ниже стоимость.
Предложение: В середине вы можете определить, есть ли значение токена в запросе. Если операция модификации не имеет токена, вы можете напрямую считать его на промежуточном слое небезопасным и отбросить запрос.
Другие проблемы безопасности
Есть несколько общих вопросов веб -безопасности. Вот только некоторые представления и будут по -прежнему унаследовать в посредничестве в будущем.
HTTP Headers Security
Атакующие инъекции CRLF находят способы ввести два специальных символа CRLF в заголовок ответа, что приводит к исключительному формату данных ответа, тем самым внедряя скрипт и т. Д.
Откаживается от атак доступа каждый запрос, потому что файлы cookie приносятся по умолчанию, а сервер обычно ограничивает размер файлов cookie, что приводит к тому, что если клиентские куки -клиента установлены для превышения определенного порога, пользователь больше не сможет получить доступ к веб -сайту.
Профилактика и контроль cookie, общая кража файлов cookie получается с помощью JavaScript (уязвимость XSS), поэтому попробуйте установить файлы cookie только на HTTP и добавить время истечения срока действия cookie
Что касается проблем безопасности файлов cookie, у Webx уже было хорошее решение раньше; На этот раз Midway не несет ответственности за настройку и проверку файлов cookie и отвечает только за пересылку на уровень Webx для проверки.
О NODE.JS
Уязвимости для инъективных действий, такие как XSS, являются самыми легкими, которые можно игнорировать среди всех уязвимостей, составляя более 70% от общего интернет -атак; При написании кода node.js разработчики всегда должны напоминать себе и никогда не доверять входным данным.
Например, следующие примеры.
var mod = fs.readfilesync ('path'); Если путь исходит от пользовательского ввода, то предполагая, что пользователь входит /и т. Д. /Пароль, контент, который не следует читать
var result = eval (jsonval); Обязательно убедитесь, что jsonval - это json, а не пользовательский ввод
... В других местах, которые могут содержать ввод пользователя, обязательно подтвердите, что ввод пользователя - это значение, которое мы ожидаем.
Суммировать
В режиме разделения фронтального и среднего, традиционные фронт-разработчики могут начать писать код на основе. Хотя архитектура несет ответственность только за слой шаблона, они также будут подвергаться большему количеству кодекса в среднем; Следовательно, безопасность является большой проблемой для фронта.