Параноидальное отношение: каков Ваш градус о проблемах безопасности в Интернете?
этот вопрос может быть связан с субъективным вопросом, но это не действительно одно.
При разработке веб-сайта существует несколько точек, которые необходимо знать: нападения на XSS, Внедрение SQL, и т.д. Это может быть очень очень трудно (и занять много времени для кодирования) защитить все потенциальные атаки.
Я всегда пытаюсь защитить свое приложение, но я не знаю, когда остановиться.
Давайте возьмем тот же пример: социальная сеть как Facebook. (Поскольку веб-сайт банка должен защитить все свои данные.)
Я вижу некоторые подходы:
Не защищайте XSS, Внедрение SQL... Это может быть действительно сделано при доверии пользователю: бэкэнд для частного предприятия. Но Вы защищаете этот тип приложения?
Безопасные нападения только, когда пользовательская попытка получить доступ не к принадлежавшим данным: Это - для меня лучший подход.
Защитите все, все, все: Вы защищаете все данные (владелец или не): пользователь не может повредить его собственные данные и другие пользовательские данные: это очень длинно, чтобы сделать, и действительно ли это очень полезно?
Защитите общие нападения, но не защищайте очень трудные нападения (потому что это слишком длинно для кодирования по сравнению с шансом того, чтобы быть взломанным).
Ну, я не знаю действительно, что сделать... Для меня я пытаюсь сделать 1, 2, 4, но я не знаю, является ли это большой выбор.
Существует ли приемлемый риск не защитить все Ваши данные? Я могу защитить все данные, но мне требуется ускоренный марш для кодирования вещи? Каков корпоративный подход между риском, и "время является деньгами"?
Спасибо для совместного использования этого, потому что я думаю много разработчиков, не знает, что проку предел.
Править: Я вижу много ответов, говорящих о XSS и Внедрении SQL, но это не единственные вещи заботиться о.
Давайте возьмем форум. Поток может быть записью на форуме, где мы - модератор. Таким образом, при отправке данных в клиентское представление Вы добавляете или удаляете "добавить" кнопку для этого форума. Но когда пользователь пытается сохранить поток в стороне сервера, необходимо проверить, что пользователь имеет право отметить точкой ее (Вы не можете доверять на клиентской безопасности представления).
Это - очень простой пример, но в некоторых моих приложениях, у меня есть иерархия прав, которые может быть очень очень трудно проверить (нуждайтесь в большом количестве SQL-запросов...), но в другой руке, действительно трудно найти взлом (даты псевдо зашифрованный в клиентском представлении, существует много данных для изменения для создания выполнений взлома, и хакеру нужно хорошее понимание моих правил приложения сделать взлом): в этом случае могу я проверять только поверхностные дыры в системе безопасности (действительно легкий взлом), или могу я проверять очень твердые дыры в системе безопасности (но он уменьшит мои действия для всех пользователей и берет меня долгое время для разработки).
Второй вопрос: мы можем "доверять" (для не разработки твердого и длинного кода, который уменьшает производительность) на клиентском представлении для очень трудного взлома?
Вот другое сообщение, говорящее об этом виде взлома: (будьте в спящем режиме и проверка набора), вопрос о безопасности: как защитить, в спящем режиме наборы, возвращающиеся от клиента к серверу?
5 ответов
Я думаю, что вы должны попытаться зафиксировать все, что вы можете, время, потраченное на это, ничто по сравнению со временем, необходимым для исправления беспорядка, выполненного кем-то, используя уязвимость, которую вы оставили где-то.
Большинство вещей в любом случае довольно легко исправить:
- Инъекции SQL не имеют ничего общего с SQL, это просто строковые манипуляции, поэтому, если вы не чувствуете себя комфортно, просто используйте подготовленные заявления с связанными параметрами и забыть О проблеме
- Крестное использование сайта легко отрицается с помощью выхода (с HTMLEntities или SO) каждые ненадежные данные, прежде чем отправлять его как вывод - конечно, это должно быть связано с обширными фильтрацией данных, но это хороший запуск
- Кража учетных данных: никогда не хранить данные, которые могут предоставить постоянный доступ к охраняемым участкам - вместо этого сохраняйте хэш-версию имени пользователя в файлах cookie и установить ограничение по времени на сеансы: так, как атакующий, который может произойти, чтобы украсть эти данные Ограниченный доступ вместо постоянного
- никогда не предполагают, что только потому, что пользователь вошел в систему, он может быть доверен - применить правила безопасности для всех
- . Обработаться во всем, что вы попадаете извне, как потенциально опасно: даже доверенный сайт, который вы GE T данные могут быть скомпрометированы, и вы тоже не хотите упасть - даже ваша собственная база данных может быть скомпрометирована (особенно если вы находитесь в общей среде), поэтому не доверяйте ее данным
, конечно, Подробнее, как и сессионные угоны, но это первые вещи, на которые вы должны смотреть.
Править в отношении вашего редактирования :
Я не уверен, что полностью понимаю ваши примеры, особенно то, что вы подразумеваете под «доверием о безопасности клиента». Конечно, все страницы с ограниченным доступом должны начинаться с проверки, если у пользователя есть права, чтобы увидеть контент и необязательно, если он (или она) имеет правильный уровень привилегии: могут быть некоторые действия, доступные для всех пользователей, и некоторые Другие доступны только для более ограниченной группы (например, модераторы на форуме). Все эти элементы управления должны быть сделаны на стороне сервера, потому что вы можете никогда не доверяют тому, что клиент отправляет вам, что это данные через Get, Post и даже файлы cookie. Ни один из них не является необязательным.
Лично я предпочитаю, чтобы все было всегда под контролем. Возможно, это параноидальный подход, но когда я вижу в интернете тонны сайтов, которые уязвимы для SQL инъекций или даже гораздо более простых атак, и они не утруждают себя исправлением, пока кто-то не "взломает" их и не украдет их драгоценные данные, это заставляет меня сильно бояться. На самом деле я не хочу быть тем, кто отвечает за утечку паролей или другой пользовательской информации.
Просто попросите кого-нибудь с опытом взлома проверить ваше приложение/сайт. Это должно дать вам ясное представление о том, что не так и что должно быть обновлено.
Вы хотите иметь сильный ACL со стороны API. Несколько дней назад я видел проблему, когда парень защищал каждый пользовательский интерфейс, но сайт был уязвим через AJAX, просто потому что его API (где он посылал запросы) просто доверял каждому запросу для проверки. Я мог в основном вытащить всю базу данных через эту ошибку.
«Разрушение данных» - это не то, что должно быть возможным, уполномоченным пользователем или кем-либо еще. Я бы подал это в рамках «Валидация и санитария пользовательского ввода», и это то, что вы всегда должны делать. Если есть только возможность «разбития ваших данных», это произойдет рано или поздно, поэтому вам нужно проверить любой ввод в ваше приложение. Удаление SQL-запросов идет в эту категорию, которая является обеспокоенностью безопасности, так и санитарной информацией.
Общая безопасность в вашем приложении должно быть звуком независимо от. Если у вас есть система управления пользователями, она должна выполнять свою работу должным образом. Я Пользователи, которые не должны иметь доступ к чему-то, не должны иметь возможность получить доступ к ней.
Другая проблема, прямая атака XSS, не имеет большого значения с «разбитом данных», но с несанкционированным доступом к данным. Это то, что зависит от приложения, но если вы осознаете, как XSS нападает на работу и как вы можете избежать их, есть ли причина не , чтобы?
в резюме:
- SQL Инъекция, входная проверка и санитарно-санитария идут рука об руку и в любом случае необходимы
- XSS-атаки могут избегать лучших практик и немного сознания, вам не нужно делать много дополнительную работу для него
- То, что, как «проактивные» фильтры атаки грубой силы или такие вещи, которые вызывают дополнительную работу, зависят от приложения
просто принять привычку придерживаться передовой практики, проходит долгий путь в создании безопасного приложения и Почему бы тебе не так ли? :)
Вам нужно увидеть веб-приложения в качестве архитектуры сервера. Клиент может задать вопрос, сервер дает ответы. Вопрос - это всего лишь URL, иногда с небольшим количеством прилагаемых данных.
Могу ли я иметь
/ Forum / View_thread / 12345 /Пожалуйста,?
Могу ли я опубликовать это$ data-/ FORUM / NEW_THREAD /Пожалуйста,?
Могу ли я иметь/ Forum / admin / delete_all_users /, пожалуйста,?
Ваша безопасность не может полагаться только на клиента, не спрашивая правильный вопрос. Никогда.
Сервер всегда должен оценивать вопрос и ответить NO при необходимости.
Все приложения должны иметь некоторую степень безопасности. Вы обычно не просите SSL на веб-сайтах интрасети, но вам нужно позаботиться о атаках SQL / XSS.
Все данные Ваш пользователь входит в ваше заявление, должно быть под вашей ответственностью. Вы должны убедиться, что никто не несанкционировал получить доступ к нему. Иногда «не критическая» информация может представлять очень проблему безопасности, потому что мы все ленивые люди.
Некоторое время назад, друг использовал для запуска веб-сайта игр. Пользователи создают свои профили, форум, все эти вещи. Затем, когда-нибудь, кто-то нашел впрыску SQL открыть дверь где-то. Этот злоумышленник получает всю информацию пользователя и пароль.
Не большая сделка, а? Я имею в виду, кто заботится о учетной записи игрока на сайт? Но большинство пользователей использовали один и тот же пользователь / пароль в MSN, Counter Strike и т. Д. Так очень быстро становятся большой проблемой.
Нижняя строка: все приложения должны иметь некоторую проблему безопасности. Вы должны взглянуть на шаг , чтобы понять свои векторы атаки и предпринять лучшие действия.
Все приложения должны иметь определенную степень безопасности. Обычно вы не запрашиваете SSL на веб-сайтах интрасети, но вам нужно позаботиться об атаках SQL/XSS.
Все данные, вводимые пользователем в приложение, должны находиться под вашей ответственностью. Вы должны убедиться, что никто не имеет к нему несанкционированного доступа. Иногда «не критичная» информация может представлять проблему безопасности, потому что мы все ленивые люди.
Некоторое время назад друг вел веб-сайт игр. Пользователи создают свои профили, форум, все такое. Потом, в какой-то день, кто-то нашел где-то открытую дверь для впрыска SQL. Этот злоумышленник получает всю информацию о пользователе и пароле.
Не большое дело, да? В смысле, кого волнует аккаунт игрока на веб-сайте? Но большинство пользователей использовали один и тот же пользователь/пароль для MSN, Counter Strike и т.д. Так что стать большой проблемой очень быстро.
Итог: все приложения должны иметь некоторую обеспокоенность по поводу безопасности. Вы должны взглянуть на STRIDE , чтобы понять векторы атак и предпринять наилучшие действия.
-121--2991121-Нельзя использовать косую черту в значении маршрута в ASP.NET MVC. Даже если это URL-код, он не работает.
Существует только при использовании ASP.NET 4,0
-121--4903996-Я думаю, что полезно различать предотвращение ввода кода и простую авторизацию данных.
На мой взгляд, все, что нужно, - это несколько хороших привычек кодирования, чтобы полностью исключить инжекцию SQL. Этому просто нет оправдания.
Инъекция XSS немного отличается - я думаю, что это всегда можно предотвратить, но это может быть не тривиально, если ваше приложение имеет пользовательский контент. Под этим я просто имею в виду, что может быть не так тривиально защитить ваше приложение от XSS, как это по сравнению с SQL injection. Поэтому я не имею в виду, что разрешить XSS нормально - я все еще думаю, что нет оправдания для разрешения этого, это просто труднее предотвратить, чем SQL инъекция, если ваше приложение вращается вокруг пользовательского контента.
Таким образом, SQL injection и XSS являются чисто техническими вопросами - следующим уровнем является авторизация: насколько тщательно должен быть защищен доступ к данным, которые не являются делом текущего пользователя. Здесь я думаю, что это действительно зависит от приложения, и я могу представить, что имеет смысл различать: «пользователь X может не видеть ничего пользователя Y» vs «Не беспокоя пользователя X с данными пользователя Y улучшит удобство использования и сделать приложение более удобным для использования».