Foreversoft.ru

IT Справочник
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ошибка входных данных

Развертывание IDS

Типы компьютерных уязвимостей

Многие IDS предоставляют описания атак, которые они определяют. Это описание часто включает типы уязвимостей, которые используют атаки. Данная информация является очень полезной после того, как атака произошла, потому что системный администратор может исследовать и скорректировать использованную уязвимость. NIST рекомендует использовать ICAT Metabase проект для исследования и фиксации уязвимостей в сетях организации. ICAT содержит тысячи примеров реальных компьютерных уязвимостей со ссылками на детальное описание. ICAT доступна по адресу http://icat.nist.gov.

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

Ошибка корректности входных данных

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

Переполнение буфера

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

Ошибка граничного условия

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

Ошибка управления доступом

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

Исключительное условие при обработке ошибки

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

Ошибка окружения

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

Ошибка конфигурирования

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

Race-условие

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

Будущие направления развития >Хотя функция аудита системы, которая являлась первоначальной задачей IDS , стала формальной дисциплиной за последние пятьдесят лет, поле для исследований IDS все еще остается обширным, большинство исследований датировано не позднее 1980-х годов. Более того, широкое коммерческое использование IDS не начиналось до середины 1990-х.

Intrusion Detection и Vulnerability Assessment является быстро развивающейся областью исследований.

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

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

Более того – очень вероятно, что основные возможности IDS скоро станут ключевыми в сетевой инфраструктуре (такой как роутеры, мосты и коммутаторы) и в операционных системах. При этом, скорее всего, разработчики IDS сфокусируют свое внимание на решении проблем, связанных с масштабируемостью и управляемостью IDS .

Имеются также и другие тенденции, которые, скорее всего, будут влиять на функциональности IDS следующего поколения. Существует заметное движение в сторону аппаратно-программных (appliance) решений для IDS . Также вероятно, что в будущем некоторые функции определения соответствия шаблону могут быть реализованы в аппаратуре, что увеличит скорость обработки.

Читать еще:  Ubuntu ошибка при установке

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

Жизнь — это движение! А тестирование — это жизнь 🙂

вторник, 29 декабря 2015 г.

Панбагон. Ошибка входных данных, если выбрано 0

В прошлом посте я поведала историю о том, как иногда бывает: все работает по ТЗ, но в прод выводить нельзя!

Если вкратце — в интернет-магазине сделали возможность видеть в профиле участника все его отзывы к товарам. Надеялись, что принесет добро, а участники пошли выискивать компромат на «неугодных». Функционал убрали, стали дорабатывать (видимо).

Добавили возможность указать видимость отзыва во время его написания:

А сегодня зашла на форум и увидела такую фразу: «Сейчас видимость своего профайла Пользователь может выбрать в Личном Кабинете самостоятельно».

Мне же любопытно, я пошла искать

Зашла в свои отзывы и увидела большую кнопку изменения видимости.

Поменяла на «всем» и попробовала сохранить

Вылезло чудное сообщение «а вы уверены. »

Раскина на них нет! Винда же научила — видишь такое ужасное сообщение, раздражайся и кликай «ДА!», даже если успел передумать. Подтверждаем свои действия и.

Увы и ах. Некая ошибка входных данных. И думай, что хочешь. Как пользователю понять из такого текста, в чем он ошибся?

Давайте заведем это как баг! Прежде чем скакать заводить, надо локализовать и выяснить точные шаги воспроизведения. Оказывается, это не такая кнопка, которая меняет сразу и все. Слева от отзывов стоят чек-боксы выбора. Нужно отметить нужные и изменять видимость им:

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

«Ошибка входных данных» при смене видимости у 0 отзывов


Шаги для воспроизведения

  1. Войти в личный кабинет, «Мои отзывы» — https://lk.wildberries.ru/discussion/feedback (тут были тестовые данные для входа)
  2. Нажать «Сохранить» у блока «Видимость в профайле», ничего не выбрав, см рис «1. Сохранение».
  3. Подтвердить действие.

Результат

См рис «2. Ошибка» — появляется сообщение «Ошибка входных данных».

Текст должен пояснять пользователю, что он должен сделать для исправления ситуации. Например: «Ни один отзыв не выбран. Сменить видимость для всех?» и при выборе «да» система меняет видимость у всех отзывов, не заставляя пользователя выполнять дополнительные действия.

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

Это сильно лучше, чем дополнительный pop-up с текстом об ошибке

Еще тут стоит поставить улучшение на то, чтобы убрать шаг 3 из описания бага, убрать это сообщение об ошибке. Будет вам в качестве домашнего задания, описать и обосновать

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

PS — добавила пост в общую копилку багов.

PPS — магазин я люблю и уважаю, эти посты не о том, «какие они плохие». Баги бывают повсюду, я показываю начинающим тестировщикам, что их много. И их можно и нужно искать повсюду, набивать руку.

Я показываю примеры, где такие баги встречаются. И, разумеется, чем больше функционала, тем выше вероятность появления багов. Поэтому у вайлдберрис я постоянно что-то такое нахожу после очередного релиза. Но магазин молодец, развивается, новые фичи делает! И часто выпускает фичи в тестовом режиме, так что это просто кладезь для начинающих тестировщиков =)

Качественный код: проверка данных обязательна

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

Между тем, пример с отрицательным количеством товара, также как и различные XSS, SQL-injections — все это частные случаи, требующие подхода, известного как «Защитное (безопасное) программирование» (Secure programming).

Данная тема довольно часто и подробно рассматривается в специализированной литературе, например, см. «Совершенный код» С. Макконнелла (Steve McConnell, Code Complete), Глава 8 «Защитное программирование».

Приведу небольшую цитату из этой книги (если кто не читал — рекомендую):

Защитное программирование не означает защиту своего кода словами: «Это так работает!» Его идея совпадает с идеей внимательного вождения, при котором вы готовы к любым выходкам других водителей: вы не пострадаете, даже если они совершат что-то опасное. Вы берете на себя ответственность за собственную защиту и в тех случаях, когда виноват другой водитель.
В защитном программировании главная идея в том, что если методу передаются некорректные данные, то его работа не нарушится, даже если эти данные испорчены по вине другой программы. Обобщая можно сказать, что в программах всегда будут проблемы, программы всегда будут модифицироваться и разумный программист всегда будет учитывать это при разработке кода.
Эта глава рассказывает, как защититься от беспощадного мира неверных данных, событий, которые «никогда» не могут случиться, и других программистских ошибок. Если вы опытный программист, то можете пропустить следующий раздел про обработку входных данных и перейти к разделу 8.2, который расскажет об утверждениях.

8.1. Защита программы от неправильных входных данных.

Вы, возможно, слышали в школе выражение: «Мусор на входе – мусор на выходе» («Garbage in, garbage out»). Это вариант предостережения потребителю от разработчиков ПО: пусть пользователь остерегается.

Читать еще:  Файлы отчета об ошибках

Для промышленного ПО принцип «мусор на входе – мусор на выходе» не слишком подходит. Хорошая программа никогда не выдаст мусор независимо от того, что было у нее на входе. Вместо этого она использует принципы: «мусор на входе – ничего на выходе», «мусор на входе – сообщение об ошибке на выходе» или «мусор на входе не допускается». По сегодняшним стандартам «мусор на входе – мусор на выходе» — признак небрежного, небезопасного кода.

Существует три основных способа обработки входных мусорных данных, перечисленных далее.

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

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

Решите, как обрабатывать неправильные входные данные
Что делать, если вы обнаружили неверный параметр? В зависимости от ситуации вы можете выбрать один из дюжины подходов, подробно описанных в разделе 8.3

Защитное программирование – это полезное дополнение к другим способам улучшения качества программ, описанным в этой книге. Лучший способ защитного кодирования – изначально не плодить ошибок. Итеративное проектирование, написание псевдокода и тестов до начала кодирования и низкоуровневая проверка соответствия проекту – это все, что помогает избежать добавления дефектов.…

Механизм проверки может быть различным и зависит от типа данных/языка/библиотек/фреймворка и т.д. Это могут быть утверждения (assertions), перечислимые типы данных (enum), свойства и так далее. Главное, чтобы в архитектуре приложения проверки были обязательным элементом, логически отделенным от процесса обработки данных.

Касательно реакции на некорректные данные, полученными через пользовательский интерфейс, то, на мой взгляд — нужно быть честным с юзером. Попытка предугадать, что хотел получить пользователь, указав несуществующий почтовый индекс, отрицательное количество товара или некорректный текст вместо свого e-mail — будет самообманом. Мы никогда не узнаем, о чем действительно думал посетитель во время заполнения формы. А значит, не сможем выяснить — какое значение подразумевалось на самом деле.
Вероятно, он опечатался, возможно, какой-то кулхацкер проверял — как тут все работает, а быть может это просто ошибка в интерфейсе.
В любом случае, если происходит ошибка при вводе данных — логично приостановить выполнение программы и сообщить пользователю о том, что введенные данные неверны. (Естественно, речь идет о понятных для пользователя сообщениях, например, «населенного пункта с таким индексом не существует», вместо «http/500, UE throw… incorrect zip… at class N»).

Бытует мнение, что это снизит «дружественность» интерфейса. Это не так. Напротив, ПО станет более понятным, предсказуемым и безопасным — как для пользователя, так и для разработчика. Это легко проверить на практике: достаточно писать такие ошибки в лог, и в последствии проанализировать его содержание.

Стремление добиться того, чтобы программа продолжала выполняться любой ценой, сбрасывая некорректные значения к дефолтным – опасно, и, скорее всего, говорит о том, разработчик не вполне понимает — какой в итоге может оказаться эта цена.

Качественный код: проверка данных обязательна

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

Между тем, пример с отрицательным количеством товара, также как и различные XSS, SQL-injections — все это частные случаи, требующие подхода, известного как «Защитное (безопасное) программирование» (Secure programming).

Данная тема довольно часто и подробно рассматривается в специализированной литературе, например, см. «Совершенный код» С. Макконнелла (Steve McConnell, Code Complete), Глава 8 «Защитное программирование».

Приведу небольшую цитату из этой книги (если кто не читал — рекомендую):

Защитное программирование не означает защиту своего кода словами: «Это так работает!» Его идея совпадает с идеей внимательного вождения, при котором вы готовы к любым выходкам других водителей: вы не пострадаете, даже если они совершат что-то опасное. Вы берете на себя ответственность за собственную защиту и в тех случаях, когда виноват другой водитель.
В защитном программировании главная идея в том, что если методу передаются некорректные данные, то его работа не нарушится, даже если эти данные испорчены по вине другой программы. Обобщая можно сказать, что в программах всегда будут проблемы, программы всегда будут модифицироваться и разумный программист всегда будет учитывать это при разработке кода.
Эта глава рассказывает, как защититься от беспощадного мира неверных данных, событий, которые «никогда» не могут случиться, и других программистских ошибок. Если вы опытный программист, то можете пропустить следующий раздел про обработку входных данных и перейти к разделу 8.2, который расскажет об утверждениях.

8.1. Защита программы от неправильных входных данных.

Вы, возможно, слышали в школе выражение: «Мусор на входе – мусор на выходе» («Garbage in, garbage out»). Это вариант предостережения потребителю от разработчиков ПО: пусть пользователь остерегается.

Читать еще:  Winhttprequest ошибка поддержки безопасных каналов

Для промышленного ПО принцип «мусор на входе – мусор на выходе» не слишком подходит. Хорошая программа никогда не выдаст мусор независимо от того, что было у нее на входе. Вместо этого она использует принципы: «мусор на входе – ничего на выходе», «мусор на входе – сообщение об ошибке на выходе» или «мусор на входе не допускается». По сегодняшним стандартам «мусор на входе – мусор на выходе» — признак небрежного, небезопасного кода.

Существует три основных способа обработки входных мусорных данных, перечисленных далее.

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

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

Решите, как обрабатывать неправильные входные данные
Что делать, если вы обнаружили неверный параметр? В зависимости от ситуации вы можете выбрать один из дюжины подходов, подробно описанных в разделе 8.3

Защитное программирование – это полезное дополнение к другим способам улучшения качества программ, описанным в этой книге. Лучший способ защитного кодирования – изначально не плодить ошибок. Итеративное проектирование, написание псевдокода и тестов до начала кодирования и низкоуровневая проверка соответствия проекту – это все, что помогает избежать добавления дефектов.…

Механизм проверки может быть различным и зависит от типа данных/языка/библиотек/фреймворка и т.д. Это могут быть утверждения (assertions), перечислимые типы данных (enum), свойства и так далее. Главное, чтобы в архитектуре приложения проверки были обязательным элементом, логически отделенным от процесса обработки данных.

Касательно реакции на некорректные данные, полученными через пользовательский интерфейс, то, на мой взгляд — нужно быть честным с юзером. Попытка предугадать, что хотел получить пользователь, указав несуществующий почтовый индекс, отрицательное количество товара или некорректный текст вместо свого e-mail — будет самообманом. Мы никогда не узнаем, о чем действительно думал посетитель во время заполнения формы. А значит, не сможем выяснить — какое значение подразумевалось на самом деле.
Вероятно, он опечатался, возможно, какой-то кулхацкер проверял — как тут все работает, а быть может это просто ошибка в интерфейсе.
В любом случае, если происходит ошибка при вводе данных — логично приостановить выполнение программы и сообщить пользователю о том, что введенные данные неверны. (Естественно, речь идет о понятных для пользователя сообщениях, например, «населенного пункта с таким индексом не существует», вместо «http/500, UE throw… incorrect zip… at class N»).

Бытует мнение, что это снизит «дружественность» интерфейса. Это не так. Напротив, ПО станет более понятным, предсказуемым и безопасным — как для пользователя, так и для разработчика. Это легко проверить на практике: достаточно писать такие ошибки в лог, и в последствии проанализировать его содержание.

Стремление добиться того, чтобы программа продолжала выполняться любой ценой, сбрасывая некорректные значения к дефолтным – опасно, и, скорее всего, говорит о том, разработчик не вполне понимает — какой в итоге может оказаться эта цена.

Ссылка на основную публикацию
Adblock
detector