Недавно на books.ru оставлял комментарий на какую-то книгу и случайно обратил внимание на каптчу (Captcha). В глаза бросилось то, что она нарисована в виде банального текста. Я сначала протер глаза и очки, в надежде, что мне это кажется. Кликаю дважды по каптче, а она выделяется как банальный текст. Я снова не верю глазам и лезу в исходник страницы. Не может быть!!! Captcha действительно лежит в открытом виде и передается от формы к сценарию банальным параметром.
Для чего это делали? Хакеры могут без проблем взломать каптчу и написать программу, которая будет программно загружать страницу, анализировать в поисках секретного кода и передавать его серверу. Так как это легко реализовать программно, то можно без проблем организовать флуд на сервер.
Единственное, от чего спасает такая каптча - от ручного флуда. Пользователь не сможет ручками флудить банальным обновлением страницы. Нужно каждый раз вводить код. Зато любой хакер, который может написать программу, сможет зафлудить сервер по самую крыжечку.
Шли, шли к свободе и пришли к великой русской стене ради нашей безопасности. В Интернете пошли разговоры о том, чтобы построить шлюз между рунетом и остальной сетью. И это предложил президент отечественной ассоциации разработчиков ПО. Для этого за 10 лет может быть написан сетевой экран, а разработка обойдется в несколько сотен миллионов долларов.
Первое, что меня смущает – срок возведения стены. Сколько человек будет заниматься этим? Если бы Agnitum писала свой сетевой экран с такой же скоростью, то она никогда бы не стала одним из заметных игроков на рынке безопасности. Это что же можно разрабатывать и внедрять столько времени? Это не просто уже шлюз, защита или безопасность, это великая Китайская стена в интернете получается.
Расходы тоже как всегда с размахом. Допустим, что потратят всего 200 миллионов на разработку и внедрение. Если один сотрудник (программист, администратор, внедренец и другие) будет получать 5 000 долларов в месяц, то один человек скушает за 10 лет 600 тысяч долларов. А что вы хотели, программирование очень дорогое удовольствие даже в нашей стране, поэтому компании любят использовать сообщества OpenSource программистов в своих целях для удешевления разработки.
Сегодня я расскажу о еще одной своей уязвимости в PHP сценарии. Если тебе интересно учится на чужих ошибках, то это тебе поможет. Вчера я зашел в админку сайта HackishCode и увидел там комментарий от пользователя, который был сохранен со статусом 1, при этом имя пользователя отсутствовало. Меня это очень сильно испугало, потому что со статусом 1 можно сохранить комментарий только если его подтвердил я лично или если его оставил зарегестрированный пользователь. Неужели кто-то зарегистрировался с пустым именем, и будет мусорить? Лезу в базу и выясняю, что нет такого человека. Явно где-то уязвимость, которой воспользовались нарочно или случайно и нужно пускаться в поиски!
Пробую оставить комментарий к первой попавшейся новости от не зарегистрированного пользователя, но он, как и положено, попадает в базу со статусом 0 и не отображается. Смотрю еще раз на базу и выясняю, что испорченный комментарий оказался в разделе исходников. Смотрю в код исходников а там защита идентична, как и в новостях. Логика сохранения проста и ошибиться сложно:
У меня на всех сайтах есть один и тот же файл, который рисует капчу и таким образом, гарантирует, что сообщения оставляются именно человеком, а не компьютером. Но я допустил одну маленькую ошибку, благодаря которой все мои усилия пошли прахом, а обойти защиту стало очень просто. Как все произошло? Банальная забывчивость сделать значение по умолчанию. Я прекрасно знаю о таких проблемах и тут сам попался на банальную ошибку. Ну ничего, это будет мне лишним уроком на будущее.
На сайте есть форма для ввода сообщения и при ее генерирования вызывается PHP файл, который рисует капчу и сохраняет в сессии нарисованный код. Казалось бы, из сессии код вычислить невозможно, но спамерам оказалось это и не нужным. Достаточно всего лишь создать форму у себя на компьютере и перенаправить ее так, чтобы он отправляла результат скрипту на сайте. При этом убирается ссылка на капчу, а значит, сценарий не сохранит в сессии ничего и секретный код будет пустим.
Security команда из Microsoft будет помогать сторонним разработчикам искать баги в их продуктах и исправлять их. Это станет возможным благодаря программе Microsoft Vulnerability Research.
На самом деле, компания уже давно занимается подобными вещами и уже давно помогает сторонним разработчикам, в том числе и прямым конкурентам. В мае и июне компания работала вплотную с Apple исправляя ошибки, которые были найдены в Internet Explorer и помогая компании Apple исправить подобные ошибки в конкурирующем браузере Safari.
Сейчас читаю книгу Ховарда и Лебланка - защищенный код и терерь понимаю, почему Виста провалилась. Конечно, это не главная причина, но одна из них. Как я понял, эти два человека являются главными по безопасности в Майкрософт и они очень сильно заблуждаются. Нет, не в безопасности, а в психологии.
В книге они рекомендуют по умолчанию запрещать все, что может нанести вред или содержит потенциальную угрозу. Если пользователь явно разрешит опасную возможность, значит, он отдает себе отчет в возможных проблемах. Это первая ошибка. Большинство пользователей сколько не предупреждай, они не осознают опасность, пока не грянет гром. А даже если и грянет, виноваты будут в люблю случае разработчики.
С того момента, как я ввел слева меню для выбора месяца, за который вы хотите просмотреть сообщения на блоге, сайт был уязвимым к SQL Injection. Дабы избежать проблем с безопасностью, все входные параметры проходят фильтрацию в централизованной функции, но именно дату и год я брал не из фильруемого массива $_GET, а из автоматом создаваемых переменных $y и $m. Без какой-либо фильтрации значения этих переменных вливалось в запрос со всеми вытекающими последствиями.
И вот тут возникает резонный вопрос - почему меня до сих пор не взломали? Если посмотреть по другим сайтам, то мой сайт с программамми сканируют и пытаются взломать по 10 человек в день минимум. Там у меня стоит система журналирования, по которой я всегда могу узнать, какие запросы отправлялись серверу и реистрируются все необычные попытки обращений. Один раз я так вычислил свою ошибку, которую почему-то не нашли хакеры, хотя были рядом. Там я тоже по случайности один параметр использовал в обход централизованного фильтра