Какие векторы атаки в форме HTML существуют? - PullRequest
Новая
       14

Какие векторы атаки в форме HTML существуют?

3 голосов
/ 30 августа 2010

Я начинаю смотреть на безопасность формы HTML. На данный момент мое исследование выявило три основных направления атаки:

  1. Подделка межсайтовых запросов (CSRF)
  2. Межсайтовый скриптинг (XSS)
  3. SQL-инъекция

Мой вопрос: Есть ли больше векторов атаки для форм HTML, чем эти ? Меня интересует список возможных атак через формы HTML.

Ответы [ 4 ]

2 голосов
/ 30 августа 2010

Это всегда зависит от того, что делает форма.

Внедрение кода будет еще одной угрозой (к которой относится внедрение SQL).

1 голос
/ 30 августа 2010

Прочитайте овасп топ 10. Особенно А1-инъекция . Хотя следует отметить, что недостатки CSRF / XSS / Injection также могут возникать в других местах, таких как запросы GET и заголовки HTTP.

Существуют и другие проблемы с <form>, например, не используется URL-адрес HTTPS, если вы публикуете конфиденциальную информацию. Также не используется тип переменной «пароль» для форм входа в систему.

1 голос
/ 30 августа 2010

Форма идентична URI или заголовкам с точки зрения того, чтобы быть вектором ввода для предоставленных пользователем данных. Общие правила «не доверяйте клиенту» применяются, как показано возможностью внедрения SQL, XSS и т. Д. Таким образом, формы, которые полагаются только на проверку JavaScript без проверки на стороне сервера, являются плохими.

Проблемы, более специфичные для форм, включают:

  • Предполагается, что тип = скрытые поля не видны или не будут использоваться пользователем
  • Не отправлять конфиденциальные данные через HTTPS
  • Неправильная маскировка данных (например, отображение последних N цифр кредитной карты для пользователя, но в любом случае все цифры находятся где-то на странице)
  • Для таких языков, как PHP, где к данным GET и POST можно обращаться из разных массивов, применяя проверки безопасности к $ _POST, но принимая значения из $ _GET

Проблемы рабочего процесса или «бизнес-логики» не являются специфичными для форм, но они чаще применяются к функциям, часто обрабатываемым с ними:

  • Неадекватное принудительное выполнение рабочего процесса, такое как форма A, должно быть заполнено до формы B, но переход состояния отслеживается на стороне клиента, а не на стороне сервера. (Пользователь может пропустить шаг, который не должен быть пропущен.)
  • Отсутствие ограничения скорости. Это зависит от контекста, например при нажатии на форму, которая отправляет электронные письма пользователям спама или команде ops, при повторном нажатии на форму «применить скидку» для снижения цены, поиск, требующий полного сканирования таблицы, может привести к DoS.
0 голосов
/ 30 августа 2010

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

<img src="http://mysite.com/delete_post/4" style="display:none">

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

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

...