Какие общие сетевые эксплоиты я должен знать?

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

Ответы

Ответ 1

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

Ответ 2

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

Скрипты между сайтами (XSS)

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

Неисправности впрыска

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

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

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

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

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

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

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

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

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

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

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

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

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

Небезопасные коммуникации

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

Отказ от ограничения доступа к URL

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

Проект защиты открытых веб-приложений

-Adam

Ответ 4

bool UserCredentialsOK(User user)
{

if (user.Name == "modesty")
  return false;
else
 // perform other checks
}

;)

Ответ 5

Каждый собирается сказать "SQL Injection", потому что это самая страшная уязвимость и самая легкая, чтобы окунуться. Cross-Site Scripting (XSS) займет второе место, потому что это также легко понять. "Плохая проверка ввода" не является уязвимостью, а скорее оценкой наилучшей практики безопасности.

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

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

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

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

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

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

  • Email

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

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

Ответ 6

НАПРАВЛЕНИЯ ИНЪЕКЦИЙ SQL. Их легко избежать, но все слишком распространено.

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

Вы не указываете, на какой платформе вы работаете, но если на ASP.NET начать с хорошего ol 'Scott Guthrie и его статьи Tip/Trick: Защита от атак SQL-инъекций.

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

Вот те, которые приходят мне на ум, но у нашего самого Джеффа Этвуда была хорошая статья в Кодирование ужаса с обзором книги " 19" Смертельные грехи безопасности программного обеспечения".

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

SQL Injection. Скрипты между сайтами.

Ответ 12

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

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

Ответ 13

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

  • SQL Injection Attack: Использовать подготовленные запросы
  • Скрипты с несколькими сайтами: не отправлять пользовательские данные в браузер без фильтрации и экранирования. Это также включает данные пользователя, хранящиеся в базе данных, которые изначально поступали от пользователей.