Sergej Kurakin - personal website

Я, пока, опущу ту вкусную часть, как при помощи SQL-Injection можно получить пароли пользователей, но желающие могут самостоятельно прочесть IV раздел мануала о Безопастности - SQL Injection . И расскажу о самой неприятной (ок, не всем не приятной) привычке - открытых паролях и том как их хранят в других случаях.

Итак, первый и самый простой случай, когда пароли хранятся в таблице (название не имеет значения, но очень часто это бывает таблица users, admins или members, возможны разные префиксы), в поле password (обычно нужные поля очень легко узнать по форме регистрации или логина). Оно очень приятно, когда у сайта есть уязвимость ввиде SQL-Injection - вытянуть пароль и логин нужного вам пользователя не составит никакого труда. Время, нужно на поиск, занимает от 10 минут до нескольких часов - всё зависит от мастерства и фортуны (но не стоит исключать человеческий фактор). Кстати, если базу уводят (физический дамп с сервера), создателям скажут “спасибо”. Такие разработчики обычто оставляют незащищённый phpMyAdmin на сервере в легко доступном месте, а иногда оставляют SQL-Injection в скрипте логина в CMS. Вы конечно скажете - бред, не может быть, но всё-же такие случаи встречаются в моей практике и не раз.

Более сложный вариан для взломщиков - когда пароли хешируют. Обычно, встречаются варианты когда пароль просто хеширую при помощи md5 или других функций. Хотя тут, народ исхитрился иметь небольшие базы готовых хешей. Значит и тут пароли могут пострадать - вопрос размера базы хешей и то, какой это хеш. Конечно, все пароли не раскроют. Часто в базе - словари, фразы, а всякие “kld8jSkhYakKd772″ там наврятли будут - всё зависит от размера базы, вашей удачи и, иногда, от теории вероятности (про коллизию не забываем, да).

Итак, в резюме, получается, что с паролями излишняя параноидальность вам/нам не помешает. Если вы поманипулируете с паролями пользователей (да и администраторов) - вам это не повредит ни в коем случае. Сделать пару SALT, докинуть чего из “логина”, добавить битовую операцию, потом сделать base64 енкодинг и только потом хеш - это наверняка затруднит восстановление ворованного пароля.

А что вы посоветуете?

Bookmark:

Постоянно сталкиваюсь с серверами, где по умолчанию register_globals = On. Да, мне ничто не мешает взять .htaccess и отключить: php_value register_globals Off или написать письмо администратору сервера. Однако, иногда и сам забываешь о той угрозе, которую несёт в себе register_globals = On.

Для того, что-бы воспользоваться чем-то, что даёт вам register_globals = On, нужно либо иметь на руках исходники скрипта, либо быть очень счастливым с…м сыном (ну ещё есть шанс, что ошибки, выбрасываемые PHP вам помогут). Естественно, речь идёт о Global Scope.

На днях я перебирал один маленький сайтик, где PHP используется только для того, что бы можно было удобно и быстро подключить хедер и футер, меню и для страниц легко менять тайтл и мета данные. Такой классический сайт из учебника, плюс несколько наворотов, которые позволяют кешировать сайт на стороне клиента так, как будто это статически HTML. Теоретически, если отключить expose_php и сделать ServerSignature Off, а ServerTokens Prod мало кто догадается, что это PHP.
И нашёл я там одну переменную, которая отвечала за подключение отдельного CSS для страницы. Она была задекларированна не во всех файлах, а толxко там, где требовался дополнительный CSS файл. Именно в тех файлах, где эта переменная не была установлена, её можно было установить при помощи GET, POST или COOKIE (ведь мы помним о variables_order). Плюс никакой фильтрации. Идеальное место для XSS type1 атаки. Но для такой атаки имя переменной нужно знать.

Есть ещё такой стиль программирования, когда массивы никто не декларирует, а сразу к ним обращается. Я имею ввиду, что некоторые программисты не пользуются таким выражением: $arr = array ();, а сразу выполнят присваивание: $arr[] = ’some value’;. Опять же через GET, POST или COOKIE в таком случае можно передать первые ключи для массива $arr. И тогда сколько таких переменных есть у них, которые можно поменять, зная их имена?

Вроде и нет ничего страшного, действует только на Global Scope, надо знать название переменной, но вы не можете гарантировать, что копия сайта е попала в руки мальчишам-плохишам. Так, однажды, получив исходники одной CMS, можно досконально изучить её код, найти уязвимые места, а потом вскрыть этак сайтов 10-15 с одной и той-же ошибкой. Именно так однажды случилось с CMS моего знакомого: CMS решал, человек залоглен или нет, опираясь на онду переменную $admin_id. Стоило сделать запрос admin.php?admin_id=1 и коробочка раскрылась и даже не смотря на то, что этот $admin_id должен был придти из сессии - н там не был установлен (я взял новую сессию) и скрипт пощитал, что всё впорядке и можно пользоваться.

Короткое резюме: пишите свои проекты с учётом register_globals = Off; если вы уверены, что вами написанный проект отлично работает с register_globals = Off, а на сервере register_globals = On - отключите register_globals, так как в редких случаях это может вызвать неадекватное поведения вашего проекта; если вам приходиться работать со скриптами, которые требуют register_globals = On (только в том случае, если это необходимо), будьте предельно бдительны, не сделайте глупых ошибок, связанных со свойством register_globals = On, а также проведите аудит скрипта на возможные ошибки - вы последний, кто его редактировал и все бочки посыпятся на вас.

Bookmark:

Знаете, я не специалист по безопастности, но постоянно встречаюсь с элементарными проблемами любого WEB-программиста. А за последнюю неделю в жизни/работе призошло не мало изменений, связанных с безопасностью. Первое что очень сильно повлияло - это PHP Security conference, на котором показали на сколько бывают глупы создатели сайтов. Второе - это то, что я уже проверить и накопать на окружающих сайтах и своём коде.

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

Элементарная форма. Элементарный скрипт. Для того, что-бы нормально обработать картинку на “любом” сервере, её в начале нужно двигать в свой каталог на сервере. Чаще всего это где-то внутри DocumentRoot, и в редких случаях вне его. Почему? А никто не отменял случаев с включенным open_basedir. И вроде нет ничего опасного в том, что я написал, но, если файл попал в DocumentRoot - его можно соответственно вызвать броузером. А если вы не проверили что это за файл - могут быть проблемы. Ведь могли загрузить и PHP или Perl скрипт, в котором может быть бог знает что.

И я не буду скрывать, что я купился на этой форме. Да, тут я лажанулся. Я понадеялся на getimagesize. Оказалось - зря. В первую очередь нужно проверять расширение файла в массиве $_FILES['userfile']['name'] и ещё перед выполнением move_uploaded_file. И не забудьте провериться перед этим с is_uploaded_file.

Вот на расширении файла я и попался. Я этим (по непонятным мне причинам) очень сильно принебрёг и понадеялся на функцию getimagesize. А вот она то и подвела. Оказывается (установлено экспериментальным путём на локальном PHP версии 4.4) - при загрузке файла с расширением .php (помните, я этим принебрёг), если в этот файл всунуть первые 128 байт из PNG файла, getimagesize считает что это картинка. Соответственно PHP файл попал на сервер, а что дальше бывает, я вам рассказывать не буду.

Некоторые говорят, что нужно ещё проверять $_FILES['userfile']['type'], но доверять ему нельзя - это данные, которые нам посылает клиент и они могут быть легко потделаны на строне клиента.

Загружая файл, не рекомендуют полностью доверят и $_FILES['userfile']['name'] - только профильтровав, или только расширение. Если же его прямо вписать, возможна атака путём подделки имени файла (скажем впишут вам ../../../index.php, а если у вас suEXEC или su_php можно и пострадать). Причём, они (создатели PHP) даже не подумали это дело отфильтровать автоматически, хотя в примере Validating file uploads создатели мануала об этом подумали (сам пример на данный момент мне не понятен).

Если разобрать пример Validating file uploads, а мне он виден вот таким совсем не понятно, каким образом они установили что происходит “Possible file upload attack!”? Ведь файл будет сдвинут в каталог /var/www/uploads/, а если он не будет сдвинут - следовательно, либо нету прав на это, либо исходный файл пропал. По моему, там должна была функция is_uploaded_file, а move_uploaded_file уже потом.

Итак, короткое резюме: проверять файл по разрешению и разрешать загружать только те файлы, которые 100% не будут выполнены сервером как скрипты (я бы разрешал загружать только картинки); не доверять $_FILES['userfile']['name'], проверять и фильтровать её, если используете; если файл переноситься во временное место для обработки, постарайтесь это место либо держать вне DocumentRoot, либо закрыть его при помощи .htaccess; не доверять вообще $_FILES['userfile']['type']; пользуйтесь функциями is_uploaded_file и move_uploaded_file; проверяйте и перепроверяйте параметры.

Если у вас есть комментарии на эту тему, советы или замечания какие - пишите.

Bookmark:

Итак, прошёл PHP Security conference или PHP Security training в Каунасе.

XSS, SQL-Injections, Code Executions, Code Inclusions, Using google to find a Target, Shell Executions, Intranet Exploits, Output Encodings hacks и прочие вкусные вещи прошли огромным кол-вом через мои мозги. Часть осела, часть знал, о части даже не подозревал.

Johann-Peter Hartmann очень правильно подобрал материал, с немцам присущей пунктуальностью провёл не только лекции, но и hands-on курс с примерами взлома сайтов местных. 30 минут на взлом, несколько минут на поиск потенциальных мест для взлома, анализ кода (были даны примеры кода из зала, а он показал как надо это делать).

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

Были затронуты вопросы безопастности на уровне сервера (в смысле Apache, Linux/Unix конфигурации), но очень поверхностно, так как это от части не совсем забота программиста.

Вообще, очень полезная инвестиция, как денег фирмы, так и личных. Очень прочистило мозг. Очень! Чаще бы так.

Bookmark:

Начало весны (хотя уже середина) многообещающее.

14 марта прошла первая конференция блогеров Литвы, в которой я участвовал и описал ключевые моменты: Часть первая, Часть вторая, Фотографии, Награждения, Послесловие..

Как тут-же, 28 апреля пройдут “Круглые столы блогеров”. Итак, 28 апреля, Вильнюс, Факультет коммуникаций Вильнюсского университета, алея Саулетикио 9-I, 205 аудитория (VU komunikacijos fakultetas, Saulėtekio al. 9-I, 205 auditorija). Конечно, всё будет на Литовском языке. Официальное заявления организаторов альтернативной конференции.

К этому всему добавиться Kaunas PHP::Conf 2007, которая пройдёт 14 апреля в Каунасском технологическом университете.

А кроме всего: PHP Security training, который пройдёт 16-17 апреля в Каунас. Ведёт его Johann-Peter Hartmann, участвует в разработке PEAR и PECL, а также член документирующей команды PHP. Вот только вопрос, почему оно стоит таких смешных денег 60 Литов за 2 дня, правда ничего не включено - ни проживание в Каунасе, ни обеды, ни что либо ещё.

И везде я принимаю участие. Потратиться не малое количество денег на езду, еду и удовольствия. Но дело того стоит.

Bookmark:

Вчерашние новости, наверно так можно назвать то, что я сейчас опишу.

Итак, лучший HTML кодер, которого я познал за свою жизнь, Олег, ака nyvirus1, открыл свой сайт, http://coin-locker.com/. Нет, пока вы там не найдёте там супер-крутых советов, как сверстать сайт или чего либо связанного с кодингом. Нет, это очень личный блог, посвящённый его жизни и (кто бы сомневался), его девушке. Читайте, следите, никто не знает, куда повернёт этот гений.
Если вам интересно, почему он лучший HTML кодер, то я скажу, что я видел, как он за 3 месяца с ноля начал делать такое, что мне и не снилось, по моему достаточно, чтобы восхищаться человеком.

Коллега enc запустил свой проект на Ruby on Rails: ITopia - korespondencija pietų pertraukai. Комиксы на литовском языке о несуществующей фирме и людях, отображающий будни и реальности, которые происходили в разных местах, а иногда и просто вымышленные истории. Казалось-бы проекту нету месяца, но уже к 7 комиксу в сети появились шаржи и пародии - а ведь это успех старта. Мне лично все комиксы понравились, и я рад, что в Литовкой сети появился такой проект, а человек, который его создал, сидит за соседним столом. Хотя, нужно уделить внимание и человеку, который рисует каждый комикс: metalife (блог, тоже на литовском).

UAB “Dabarties Interneto projektų studija” начала обновлять свой сайт. Дада, мы обратили внимание на заметки в блогах, что мы как-бы замерли. Нет не, мы помним и знаем, что нас читают. Итак, в данный момент мы сменили первую страницу сайта. Причём, на ней самая важная информация об очень важном событие в истории фирмы. В то время, как вся Литва играет с Бизнес-планами (проект рекламируют, но основа конкурса - сделать лучший бизнес-план), UAB “Dabarties Interneto projektų studija” участвует в международном конкурсе Content 360°. И мало того, что участвует, она выходит в финал в категории “On-Demand participation”. Насколько известно мне, UAB “Dabarties Interneto projektų studija” единственная Литовская компания, которая вышла в финал, начиная с 1991 года. А вот вам и маленькая конфетка - клип, который представляет нашу идею.

А в переди 4 дня выходных, 2 из которых я просвещу семье, а два - наверняка работе. Спонсор блогпоста - пиво FAXE в литровой жестяной упаковке.

Bookmark:

Ой, господа, я честно говоря, не ожидал именно такого способа рекламы в Литве, в стране, котороя находиться в середине Европы (физически), входящей в Европейский союз.

Всё началось элементарно. Как-то утром я получил FlashSMS с рекламой нового портала для поиска работы: naujasDARBAS.lt. Вроде всё хорошо и я не совсем против - мой номер публично доступен в сети (правда есть пометка, что рекламу на внизу представленные контакты посылать нельзя). Несколькими часами позже, такое-же FlashSMS получила моя супруга. Её номер нигде не доступен публично, за исключением нескольких сайтов по поиску работы (где большинство из них прямых ссылок на публично-доступные CV не держат, а в других, вообще без регистрации не доберёшся). Реально это SMS - SPAM, прямо Viagra Marketing Style. Но такие SMS не падают каждый день, и на неё мы не обратили особого внимания, если бы не случай, который я опишу ниже.

Итак, вдруг утром я получаю письмо, такое стандартное, новостное, от EDOMUS. Да да, этот гигант, который совсем недавно объединился с aruodas.lt, сейчас балуется принципами рекламы согласно Viagra Marketing Style. Вы скажите почему? Очень элементарно. Мой ящик доступен, опять-же, всем публично, но вот такое-же письмо получила моя супруга, чей ящик, опять-же нигде публично не доступен, акромя нескольких сайтов по поиску работы. Вот тут-то я и насторожился. Этож, от куда у EDOMUS/Aruodas оба ящика эл. почты, мои и супруги? Ни она, ни я нигде их не регистырировали на сайтах о недвижимости.

И естественно, я позвонил в EDOMUS с вопросом: от куда у них мой ящик электронной почты, и почему я получил от них это письмо, хотя НИКОГДА не регистрировался у них на сайте. На что спокойным голосом мне ответили, что я есть у них в списке получателей на EDOMUS или Aruodas. Хм, простите, но я в жизни не подписывался на новости с этих сайтов (как и на тонный рекламы виагры и пенисоувеличителей). На это мне дали следующего “мальчика”, который сказал - пришлите ваш адрес и мы разберёмся и ответим. Я отослал. И что вы думаете? Мне ответили? Ага, ещё пишут… или оно где-то затерялось между хопами/серверами.

А потом меня осенило - этож получается, что кто-то из сайтов по поиску работы (CV-шные агентуры по нашему) либо продали нашу личную информацию, либо у них её украли. Я начал копать в прошлом, где есть мой CV, где есть CV моей супруги, в придачу свежий и с этими ящиками, на которые всё свалилось (ну и номерами телефонов). И что вы думаете? Есть только одна CV агентура в сети, где эти данные в этот момент есть: CV Market. Да да, это именно CV Market, единственная система с внятным интерфейсом, где есть CV моё (неактивированное, бо работу я сейчас не ищу, но с самой актуальной информацией) и моей супруги. Кроме того, огромный баннер CV Market висит на EDOMUS, EDOMUS на CV Market. Вот оно как - явно во всём виноваты они. Вопрос - украли или поделились?

Если посмотреть на письмо из нутри, путь его был короткий, и вновь указывал на CV Market:

Received: from [84.50.110.37] (helo=crater.cvmarket.net)
	by server1045.servers101.com with esmtp (Exim 4.63)
	(envelope-from )
	id 1HWfGc-0001Jv-On
	for monika@kurakin.info; Wed, 28 Mar 2007 17:01:15 -0400
Received: by crater.cvmarket.net (Postfix, from userid 81)
	id 9D2B32D0185; Thu, 29 Mar 2007 00:01:08 +0300 (EEST)

А подключившись к своему профайлу на CV Market, я видел (внимание) 2 соглашения на то, что я согласен получать информационные сообщения от CV Market (Ок, да я хочу) и информационные сообщения от их партнёров (эй, это что?). Если мне память не изменяет, я себе их снимал, супруге тоже. Ладненько, не буду спорить, снимал я их или нет, но вот прямо сейчас мы оба их убрали и не желаем получать никакой информации от партнёров CV Market. Посмотрим, что будет.

А теперь что касается EDOMUS: для меня они по прежнему остались любителями Viagra Marketing Style - в письме, если уж на то пошло, они обязаны были указать источник, от куда они получили мою контактную информацию, тем самым, уменьшив неприятности мне и себе, и тем более ответить на моё письмо относительно того, от куда они получили эти данные. Вот теперь, если EDOMUS получил мои личные данные от CV Market, а я убрал своё соглашение на получение информационных сообщений от партнёров - как себя поведут в EDOMUS? Будут ли ещё слать чего? А ещё другие любители рассылок?

А ведь отпиши мне, причину по которой я получил пиьмо, или укажи источник от куда контакты и что всё честно - этого поста бы небыло.

Почему ещё, письмо EDOMUS попадает под Viagra Marketing Style? Способ исполнения. Из принципа я провёл технический анализ. Письмо в формате HTML не имеет таких тэгов и разделов как: html, head, meta, title, body. Один большой дикий выдер из нормального письма (из того, какое я должен был-бы получить). Тем самым, письмо в части почтовых клиентов будет отображено не верно изза отсутствующей кодировки в теле письма (ведь у нас нет html, head и meta тага). И кто вам сказал, что кодировка iso-8859-13 будет нормально поддержана всеми клиентами? У части картинок не прописаны размеры, что при загрузке, колбасит вид письма - ваши специалисты вообще, знают как и что надо делать с HTML письмами? Что ещё характерно - картинки грузит с 2 разных серверов/доменов (простите не разбирался но один .ee, другой .lt), а ссылки ведут на третий - это мало того, что подозрительно, но оно напрашивается на “поход в сад”. Вы, это, знаете, что картинки с HTTP серверов по умолчанию не отображаются почтовыми клиентами? Вы думаете ваше письмо без картинок (ну не отображает их без взмаха волшебной палочкой) - очень эффективно (давайте подумаем ещё о тех, кто пользуется лаптопами и не всегда on-line)? Рассылка ведётся из какой-то системы, под названием “KV Mailer v0.91b” - знаете, а ведь нет такого клиента общеизвестного, следовательно, спам-фильтры, которые могут и на эту запись посмотреть, выбьют (потенциально) это письмо в спам (как это бывает с PHP мейлерами). А ведь мы тут делаем вид персональной рассылки, да?

Вот точно такие-же письма по качеству я получаю о виагре и разных увеличителях пениса, поэтому так и называю данную рекламную кампанию EDOMUS: Viagra Marketing Style. Это совсем не способ рекламы. Только не так, не в таком наглом стиле и не так убого и не качественно. Мало того, в ссылках нет никаких меток для слежения за её эффективностью (к примеру коды Google Analytics или любые другие аналитические системы) - так зачем её делать? Вот взять, разослать и забить? Разослали, отчитались перед директором (деньги на рекламу поделили), послали (мысленно) недовольных получателей и сидим дальше - самый настоящий Viagra Marketing Style.

Bookmark:

Не смотря на всё ранее сказанное, посмотрев на всё мероприятие, через 2 недели, когда прошла вся эйфория, я могу спокойно утверждать, что в Литве зародилась блогсфера. Да да, наконец, в 2007 году она зародилась. Ну и что, что опоздала этак лет на 5 от всего мира. Конечно, нам ещё далеко до того, что твориться в Западной Европе (так как центр Европы находиться в Литве), нам далеко до того, что твориться в Америке, и даже до того, что твориться в Российской Федерации.

Я пока не видел локальных проектов, похожих на Поиск по Блогам у Яндекса или blogsearch от Google, но возможно всё в переди. У нас уже несколько лет есть LietBlogs.lt, развитие которого я видел от начало до сих дней, и видел, как у этого проекта менялся движок, хозяева, дизайны и условия. Следовательно, Литовская блогсфера в очень скором времени воспрянет из пепла и ударит по местным СМИ, правилам, законам и жизни.

Следовательно, Первая конференция блогеров в Литве была именно в то время, когда она должна была быть. Она громко заявила о том, что блоги/блогеры и блогсфера в Литве есть и будет есть. После неё, и то, как её осветили старомодные СМИ, не один клиент у меня спросил при встречи, что такое блог, кто такой блогер и с чем их есть. Я думаю, в ближайшее время в стране появиться не один корпоративный блог и даже не один блог-сервис. Уже сейчас у нас есть: BLOGas.lt (кстати, болен болезнями, которыми переболел LiveJournal ещё в 2003-2004 годах), DELFI blog (всё ещё в бете и основан на Drupal, что мне немножко смешно, ведь есть другие, более для этого дела предназначенные системы и особенно классно выглядят favicon у них). Интересно, какой следующий шаг будет? Куда рванёт блогсфера?

Ещё одно интересное событие, которое последовало после (до или во время) первой конференции блогеров в Литве, это попытка признать блогера корреспондентом. Сейм это дело не пропустил и сказал, что блогеры не журналисты. В общем, полнее обо всё можно прочесть здесь Liutauro komentarai. Вобщем, у нас парадоксов много очень. Местами до смеха. И чуть пожже, всё-таки одного из блогеров, за опубликованную информацию, решили всё-таки рассматривать как корреспондента и ему всё-таки намерены применить меры по наказанию согласно закону.

Вобщем, следите, если что узнаю - обязательно напишу.

Bookmark: