Способы предотвращения атаки SQL-инъекций и XSS в веб-приложении Java

Question

Я пишу Java-класс, который будет вызываться фильтром сервлетов и который проверяет попытки атак с помощью инъекций и XSS для веб-приложения Java на основе Struts. Класс InjectionAttackChecker использует класс regex & java.util.regex.Pattern для проверки ввода по шаблонам, указанным в регулярном выражении.

С учетом сказанного у меня следующие вопросы:

1. Какие все специальные символы и шаблоны символов (например, <>, . , -, <=, ==,> =) должны быть заблокированы, чтобы можно было предотвратить атаку инъекцией.
2. Существует ли какой-либо существующий шаблон регулярных выражений, который я мог бы использовать как есть?
3. Я должен разрешить использование некоторых шаблонов специальных символов в некоторых конкретных случаях, некоторые примеры значений (которые должны быть разрешены) (используются 'pipe' | символ в качестве разделителя различных значений) * Atlanta | № 654, БЛДГ 8 # 501 | Простой герпес: хроническая язва (я) (> 1 месяц) или бронхит, пневмонит или эзофагит | FUNC & COMP (date_cmp), "NDI & MALKP & HARS_IN (icd10, да)". Какую стратегию я должен принять, чтобы можно было предотвратить атаку с помощью инъекций и XSS, но при этом разрешить эти комбинации символов.

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

Answer 1

Исходя из ваших вопросов, я предполагаю, что вы пытаетесь отфильтровать плохие значения. Я лично чувствую, что этот метод может очень быстро усложниться и рекомендовал бы кодирование значений в качестве альтернативного метода. Вот статья IBM на эту тему, в которой изложены преимущества и недостатки обоих методов: http://www.ibm.com/developerworks/tivoli/library/s-csscript/.

Чтобы избежать атак с использованием SQL-инъекций, просто используйте подготовленные операторы вместо создания строк SQL.

Answer 2

Если вы попытаетесь очистить все данные на входе, у вас будет очень трудное время. Существует множество хитростей, связанных с кодировкой символов, которые позволят людям обходить ваши фильтры. Этот впечатляющий список - это лишь некоторые из множества вещей, которые можно сделать в виде SQL-инъекций. Вы также должны предотвратить внедрение HTML, JS и, возможно, другие. Единственный надежный способ сделать это - закодировать данные, где они используются в вашем приложении. Кодируйте весь вывод, который вы пишете на свой веб-сайт, кодируйте все ваши параметры SQL. Будьте особенно осторожны с последним, поскольку нормальное кодирование не будет работать для нестроковых параметров SQL, как объяснено в этой ссылке. Используйте параметризованные запросы, чтобы быть полностью безопасными. Также обратите внимание, что теоретически вы можете кодировать свои данные в тот момент, когда пользователь вводит их, и хранить их в базе данных, но это работает только в том случае, если вы всегда собираетесь использовать данные способами, использующими этот тип кодирования (например, HTML). кодировка, если она когда-либо будет использоваться только с HTML; если она используется в SQL, вы не будете защищены). Это частично объясняет, почему практическое правило никогда не хранит закодированные данные в базе данных и всегда кодирует при использовании.

Answer 3

Проверка и привязка всех данных является обязательным. Выполните проверку как на стороне клиента, так и на стороне сервера, потому что 10% людей отключают JavaScript в своих браузерах.

У Джеффа Этвуда есть хороший блог на тему, которая дает вам представление о его сложности.

Answer 4

не фильтровать и не блокировать значения.

1. вы должны убедиться, что при объединении битов текста вы выполняете правильные преобразования типов :), т.е. их. в haskell вы можете легко реализовать это с помощью системы типов.

Хорошие языки шаблонов HTML по умолчанию исчезнут. если вы генерируете XML / HTML, то иногда лучше использовать инструменты DOM, чем язык шаблонов. если вы используете инструмент DOM, он удалит многие из этих проблем. к сожалению, инструмент DOM обычно дерьмо по сравнению с шаблонами:)

2. если вы берете строки типа HTML у пользователей, вы должны очистить их с помощью библиотеки, чтобы удалить все негодные теги / атрибуты. Есть много хороших HTML-фильтров белого списка.
3. вы всегда должны использовать параметризованные запросы. ВСЕГДА! если вам нужно динамически создавать запросы, то динамически создавать их с помощью параметров. никогда не объединяйте строки, не типизированные в SQL, со строками, типизированными в SQL.

Answer 5

Вот довольно обширная статья на эту тему.

Я не думаю, что у вас здесь будет Святой Грааль. Я также предложил бы попытаться закодировать / декодировать полученный текст некоторыми стандартными способами (uuencode, base64)

Answer 6

Взгляните на проект AntiSamy [www.owasp.org] . Я думаю, что это именно то, что вы хотите; Вы можете настроить фильтр для блокировки определенных тегов. Они также предоставляют шаблоны политик, политика slashdot будет хорошим началом, а затем добавьте нужные теги.

Кроме того, на веб-сайте www.osasp.org имеется множество знаний о защите вашей заявки.

То, что пользователь 'nemo' говорит об использовании подготовленных операторов и кодировке, также должно выполняться.