Программирование на C++ глазами хакера

         

Обработка принимаемых данных


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

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

Если есть возможность, то команды лучше проверять жестко. Например, команду get filename необходимо проверять так, чтобы первые три буквы составляли слово "get". Нельзя делать поиск символов "get" во всем полученном тексте, т. к. для хакера открывается множество возможностей передать неверные данные. Большинство взломов происходит из-за неправильного анализа полученных данных и передачи некорректных данных серверу.

Если вы разрабатываете протокол обмена командами между клиентом и сервером, то делайте так, чтобы команда передавалась в самом начале, а все параметры шли в конце. Допустим, что у вас есть команда get. Она может работать в двух режимах:

Забрать файл со стороннего сервера — GET имя файла FROM Адрес

Забрать файл с клиента, который подключился к серверу — GET Имя файла

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

GET FROM Имя файла, Адрес

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


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

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

Допустим, что у вас открыт доступ только к папке interpub на диске С:. Если проверять только начало пути, то хакер сможет без проблем написать вот такой путь:

c:\interpub\..\winnt\system32\cmd.eхе\

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

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


Содержание раздела