Как преодолеть страх перед пользовательским вводом (веб-разработка)

Одно слово: проверка на стороне сервера (хорошо, это может быть три слова).

В других ответах есть много полезных советов, но я добавлю менее «программный» ответ:

Разработайте план, как с этим справиться.

Будьте готовы к тому, что злоумышленникам удастся что-то украсть мимо вас. Имейте планы по уменьшению ущерба, восстановлению чистых и полных данных и общайтесь с пользователями (и потенциально другими заинтересованными сторонами, такими как эмитенты любых данных кредитной карты, которые у вас есть), чтобы сообщить им, что происходит. Знайте, как вы обнаружите брешь и закроете ее. Знайте, что ключевой операционный персонал и отдел разработки находятся на связи, так что плохой парень, забастовавший в 17:01 в пятницу перед государственным праздником, не получит более 72 рабочих часов, прежде чем вы сможете выйти из сети, не говоря уже о том, чтобы начать исправлять ситуацию.

Наличие планов не поможет вам остановить плохой пользовательский ввод, но должно немного помочь преодолеть ваши страхи.

Если его проблемы, связанные с «безопасностью», вам нужно просто протолкнуть его, безопасность и эксплойты — это факт жизни в программном обеспечении, и их нужно решать прямо как часть процесса разработки.

Вот несколько предложений:

• Держите это в поле зрения - безопасность, эксплойты и компрометация будут происходить с любым популярным или полезным приложением, будьте готовы к ним и ожидайте, что они произойдут
• Протестируйте его, а затем снова протестируйте — контроль качества, приемочное тестирование и приемка должны быть первоклассными частями вашего процесса проектирования и производства, даже если вы работаете в одиночку. Привлекайте пользователей для тестирования, так как преданный (и активный) пользователь будет вашим самым полезным инструментом в поиске проблем.
• Знайте свою платформу. Убедитесь, что вы знаете технологию и оборудование, на которых развертываете. Убедитесь, что установлены соответствующие исправления и обновления безопасности.
• исследования — просмотрите приложения, похожие на ваши, и узнайте, с какими проблемами они сталкиваются, просмотрите их форумы, прочитайте их журналы ошибок и т. д.
• Будьте реалистами — вы не сможете исправить все ошибки и закрыть все дыры. Выберите наиболее эффективные из них и решите те
• Много глаз — привлеките как можно больше людей для просмотра ваших проектов и кода. Это должно быть в дополнение к вашим ресурсам QA

• Вы не справитесь с этим.
• Проверьте все на стороне сервера — снова проверьте ввод, проверьте разрешения и т. д.
• Очистите все данные.

Это очень легко написать жирным шрифтом и немного сложнее сделать на практике.

Что-то, что я всегда делал, заключалось в том, чтобы оборачивать все пользовательские строки в объект, что-то вроде StringWrapper, который заставляет вас вызывать метод кодирования для получения строки. Другими словами, просто предоставьте доступ к s.htmlEncode() s.urlEncode().htmlEncode() и т. д. Конечно, вам нужно получить необработанную строку, чтобы вы могли иметь метод s.rawString(), но теперь у вас есть что-то, что вы можете найти, чтобы просмотреть все случаи использования необработанных строк.

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

Некоторые другие общие вещи:

• Предпочитайте белые списки черным спискам
• Не переусердствуйте с удалением плохих входных данных. Я хочу иметь возможность использовать символ ‹ в сообщениях/комментариях/и т. д.! Просто убедитесь, что вы правильно кодируете данные
• Используйте параметризованные SQL-запросы. Если вы сами SQL избегаете пользовательского ввода, вы делаете это неправильно.

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

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

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

На самом деле есть только одна вещь, от которой вы не можете защититься, если используете HTTP. Если вы используете файл cookie для идентификации чьей-либо личности, вы ничего не можете сделать, чтобы помешать кому-то другому в кофейне перехватить файл cookie другого человека в этой кофейне, если они оба используют одно и то же беспроводное соединение. Пока они не используют безопасное соединение, ничто не может спасти вас от этого. Даже Gmail не застрахован от этой атаки. Единственное, что вы можете сделать, это убедиться, что куки авторизации не могут храниться вечно, и подумайте о том, чтобы заставить их повторно войти в систему, прежде чем они сделают что-то важное, например, сменят пароль или что-то купят.

Но не парься. О многих деталях безопасности заботится любая система, на основе которой вы строите (вы строите поверх ЧЕГО-ТО, не так ли? Spring MVC? Rails? Struts?). Это действительно не так сложно. Если на кону большие деньги, вы можете заплатить компании, занимающейся аудитом безопасности, чтобы попытаться их взломать. Если нет, просто постарайтесь придумать все разумное и исправить дыры, когда они будут обнаружены.

Но не переставайте быть параноиком. Они всегда хотят тебя достать. Это просто часть популярности.

P.S. Еще один намек. Если у вас есть такой javascript:

if( document.forms["myForm"]["payment"].value < 0 ) {
  alert("You must enter a positive number!");
  return false;
}

Тогда у вас наверняка будет код в бэкэнде, который идет:

verify( input.payment >= 0 )

«Цитировать» все так, чтобы это не могло иметь никакого значения на «целевом» языке: SQL, HTML, JavaScript и т. д.

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

Существует несколько типов внедрения и межсайтовых сценариев (см. предыдущий ответ), но против всех них есть средства защиты. Для начала вам явно захочется взглянуть на хранимые процедуры, белые списки (например, для ввода HTML) и проверку.

Кроме того, сложно дать общий совет. Другие люди дали несколько хороших советов, например, всегда выполнять проверку на стороне сервера и исследовать прошлые атаки.

Будьте бдительны, но не бойтесь.

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

Вы можете использовать систему проверки для автоматизации проверки с помощью настраиваемых атрибутов проверки.

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=477

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

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

Наш клиент всегда говорит: «Имейте дело с моими пользователями, поскольку они не различают дату и текстовые поля!!»

Я кодирую на Java, и мой код полон asserts я предполагаю, что все не так с клиента, и я проверяю все это на сервере.

# 1 для меня - всегда создавать статические SQL-запросы и передавать ваши данные в качестве параметров. Это значительно ограничивает количество проблем с цитированием, с которыми вам приходится сталкиваться. См. также http://xkcd.com/327/.

Это также дает преимущества в производительности, поскольку вы можете повторно использовать подготовленные запросы.

На самом деле есть только 2 вещи, о которых вам нужно позаботиться:

1. Избегайте внедрения кода SQL. Используйте параметризованные запросы для сохранения пользовательского ввода в базе данных. В терминах Java: используйте PreparedStatement. В терминах PHP: используйте mysql_real_escape_string() или PDO.

2. Избегайте XSS. Избегайте пользовательского ввода во время отображения. В терминах Java/JSP: используйте JSTL <c:out>< /а>. В терминах PHP: используйте htmlspecialchars().

Это все. Вам не нужно беспокоиться о формате данных. Просто о том, как вы с этим справляетесь.