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

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

Межсайтовые Сценарии (XSS)

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

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

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

Выполнение Вредоносного Файла

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

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

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

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

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

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

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

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

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

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

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

Небезопасные Связи

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

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

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

Проект Безопасности Открытого Веб-Приложения

-Adam

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

Эти три самые важные вещи:

• Подделка Межсайтовых Запросов
• Межсайтовые Сценарии
• SQL инъекция

bool UserCredentialsOK(User user)
{

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQL ИНЪЕКЦИОННЫЕ АТАКИ. Их легко избежать, но все они слишком распространены.

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

Вы не упоминаете, на какой платформе вы находитесь, но если на ASP.NET начать с хорошего старого Скотта Гатри и его статьи "Tip/Trick: Guard Against SQL Injection Attacks".

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

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

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

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

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

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

1. SQL инъекционная атака: используйте подготовленные запросы
2. Межсайтовые сценарии: не отправлять пользовательские данные в браузер без предварительной фильтрации / экранирования. Сюда же относятся и пользовательские данные, хранящиеся в базе данных, которые изначально поступали от пользователей.

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

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

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

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

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