О каких распространенных веб-эксплойтах я должен знать? [закрыто]

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

22.08.2008 18:22:09
13 ОТВЕТОВ
РЕШЕНИЕ

OWASP хранит список 10 самых популярных веб-атак, а также массу другой полезной информации о безопасности для веб-разработки.

29
22.08.2008 19:03:40
28
11.09.2008 22:58:08

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

0
22.08.2008 18:24:17
bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}   
10
18.05.2018 09:13:55
+1 за смешно, но я не хочу знать, сколько раз я находил жестко закодированные аутентификации в системах ...
tekiegreg 19.01.2009 23:50:42
Кроме того, это может открыть дверь для временных атак, когда действительное имя пользователя с неверным паролем займет намного меньше времени, чем недопустимое имя пользователя. Затем хакер может составить список имен пользователей и работать оттуда.
Nicolas Bouliane 5.03.2014 19:19:49

Даже на этом сайте вы можете видеть, что самые разрушительные вещи, которые вы будете искать, связаны с внедрением кода в ваше приложение, поэтому XSS (межсайтовый скриптинг) и SQL-инъекция (предложения @ Patrick) - ваши самые большие проблемы. По сути, вы захотите убедиться, что, если ваше приложение позволяет пользователю вводить какой-либо код, оно регулируется и проверяется, чтобы быть уверенным, что только те вещи, которые вы уверены, что хотите разрешить (HTML-ссылка, изображение и т. Д.) ), и ничего больше не выполняется.

0
22.08.2008 18:26:10

Это также небольшая небольшая презентация по безопасности от одного из ключевых разработчиков WordPress.

Безопасность в WordPress

он охватывает все основные проблемы безопасности в веб-приложениях.

1
22.08.2008 18:27:52

SQL-инъекция. Межсайтовый скриптинг.

0
22.08.2008 18:28:50

SQL-инъекция Их легко избежать, но слишком часто.

НИКОГДА НИКОГДА (когда я упоминал «когда-либо»?) Доверяйте информации пользователя, передаваемой вам из элементов формы. Если ваши данные не проверяются перед передачей на другие логические уровни вашего приложения, вы также можете отдать ключи от своего сайта незнакомцу на улице.

Вы не упоминаете, на какой платформе вы находитесь, но если в ASP.NET начнете с хорошего старца Скотта Гатри и его статьи « Совет / хитрость: защита от атак SQL-инъекций ».

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

Это два, которые приходят мне на ум, но у нашего собственного Джеффа Этвуда была хорошая статья в Coding Horror с рецензией на книгу « 19 смертных грехов безопасности программного обеспечения ».

3
22.08.2008 18:31:50

Использование хранимых процедур и / или параметризованных запросов защитит вас от внедрения SQL. Также НЕ позволяйте вашему веб-приложению обращаться к базе данных как sa или dbo - настройте стандартную учетную запись пользователя и установите разрешения.

AS для XSS (межсайтовый скриптинг) ASP.NET имеет некоторые встроенные средства защиты. Лучше всего фильтровать ввод, используя элементы управления проверкой и Regex.

0
22.08.2008 18:33:56

Я не эксперт, но из того, что я узнал до сих пор, золотое правило - не доверять никаким пользовательским данным (GET, POST, COOKIE). Распространенные типы атак и как себя спасти:

  1. Атака SQL-инъекций : использование подготовленных запросов
  2. Межсайтовый скриптинг : не отправляйте данные пользователя в браузер без предварительной фильтрации или экранирования. Это также включает в себя пользовательские данные, хранящиеся в базе данных, которые первоначально пришли от пользователей.
0
23.08.2008 09:30:18

Большинство людей здесь упоминают SQL Injection и XSS, что является своего рода правильным, но не дайте себя одурачить - наиболее важные вещи, о которых вам нужно беспокоиться как веб-разработчику, - это INPUT VALIDATION, откуда происходят XSS и SQL Injection.

Например, если у вас есть поле формы, которое будет принимать только целые числа, убедитесь, что вы реализуете что-то как на стороне клиента, так и на стороне сервера для очистки данных.

Проверьте и перепроверьте все входные данные, особенно если они попадут в SQL-запрос. Я предлагаю создать функцию escaper и обернуть ее вокруг всего, что входит в запрос. Например:

$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";

Аналогично, если вы собираетесь отображать любую введенную пользователем информацию на веб-странице, убедитесь, что вы удалили все теги <script> или что-либо еще, что может привести к выполнению Javascript (например, атрибуты onLoad = onMouseOver = и т. Д. В тегах). ).

3
23.08.2008 11:03:30

Я публикую здесь сокращенный список OWASP Top 2007, чтобы людям не приходилось просматривать другую ссылку, а в случае отказа источника.

Межсайтовый скриптинг (XSS)

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

Недостатки инъекции

  • Недостатки внедрения, особенно SQL-инъекция, часто встречаются в веб-приложениях. Инъекция происходит, когда предоставленные пользователем данные отправляются интерпретатору как часть команды или запроса. Враждебные данные злоумышленника заставляют интерпретатора выполнять непреднамеренные команды или изменять данные.

Вредоносное выполнение файлов

  • Код, уязвимый для удаленного включения файлов (RFI), позволяет злоумышленникам включать враждебный код и данные, что приводит к разрушительным атакам, таким как полный взлом сервера. Вредоносные атаки на выполнение файлов затрагивают PHP, XML и любые фреймворки, которые принимают имена пользователей или файлы от пользователей.

Небезопасная прямая ссылка на объект

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

Подделка межсайтовых запросов (CSRF)

  • CSRF-атака заставляет вошедший в систему браузер жертвы отправлять предварительно проверенный запрос в уязвимое веб-приложение, которое затем вынуждает браузер жертвы выполнять враждебные действия в интересах злоумышленника. CSRF может быть таким же мощным, как и веб-приложение, которое он атакует.

Утечка информации и неправильная обработка ошибок

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

Сломанная аутентификация и управление сессиями

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

Небезопасное криптографическое хранилище

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

Небезопасная связь

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

Неспособность ограничить доступ к URL

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

Открытый проект безопасности веб-приложений

-Адам

34
7.09.2008 00:09:50
Список первой десятки 2013 года находится здесь: owasp.org/index.php/Top_10_2013-Top_10
Adam Davis 8.03.2016 15:57:19

Все будут говорить «SQL-инъекция», потому что это самая страшная уязвимость и самая легкая из них, чтобы разобраться. Межсайтовый скриптинг (XSS) займет второе место, потому что его также легко понять. «Плохая проверка ввода» - это не уязвимость, а оценка наилучшей практики безопасности.

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

  • Динамический SQL (например, построители запросов пользовательского интерфейса). К настоящему времени вы, вероятно, знаете, что единственный надежно безопасный способ использования SQL в веб-приложении - это использование параметризованных запросов, когда вы явно привязываете каждый параметр в запросе к переменной. Места, где я вижу веб-приложения, чаще всего нарушают это правило, когда злонамеренный ввод - это не очевидный параметр (например, имя), а атрибут запроса. Очевидным примером являются разработчики запросов в стиле iTunes «Smart Playlist», которые вы видите на поисковых сайтах, где такие вещи, как операторы where-clause, передаются непосредственно бэкэнду. Еще один замечательный камень для переворота - это сортировка столбцов таблицы, где вы увидите такие вещи, как DESC, представленные в параметрах HTTP.

  • Файл загружен. Загрузка файлов приводит в замешательство людей, потому что пути к файлам выглядят подозрительно, как пути к URL-адресам, и потому, что веб-серверы облегчают реализацию части «загрузки», просто направляя URL-адреса в каталоги файловой системы. 7 из 10 обработчиков загрузки, которые мы тестируем, позволяют злоумышленникам получать доступ к произвольным файлам на сервере, поскольку разработчики приложений полагали, что к вызову open () файловой системы были применены те же разрешения, что и к запросам.

  • Хранение пароля. Если ваше приложение может отправить мне мой пароль, когда я его потеряю, вы потерпите неудачу. Существует один надежный надежный ответ для хранения пароля, который bcrypt; если вы используете PHP, вы, вероятно, хотите PHPpass.

  • Генерация случайных чисел. Классическая атака на веб-приложения: сброс пароля другого пользователя и, поскольку приложение использует системную функцию "rand ()", которая не является криптостойкой, пароль предсказуем. Это также применимо везде, где вы делаете криптографию. Что, кстати, вам не следует делать: если вы где-нибудь полагаетесь на крипто, вы, скорее всего, уязвимы.

  • Динамический вывод. Люди слишком доверяют проверке входных данных. Ваши шансы удалить пользовательский ввод всех возможных метасимволов, особенно в реальном мире, где метасимволы являются необходимыми частями пользовательского ввода, невелики. Гораздо лучший подход - иметь согласованный режим фильтрации выходных данных базы данных и преобразования их в объекты HTML, такие как quot, gt и lt. Rails сделает это автоматически.

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

Помимо этих функций, ошибка № 1, которую вы, вероятно, допустите в своем приложении, заключается в том, чтобы где-то предоставить идентификатор строки базы данных, чтобы пользователь X мог видеть данные для пользователя Y, просто изменив число с «5» на «6».

10
10.09.2008 21:33:26