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

Различные веб-приложения позволяют пользователям загружать файлы. Форумы позволяют пользователям загружать «аватары». Фотогалереи позволяют загружать фотографии. Социальные сети предоставляют возможности по загрузке изображений, видео, и т.д. Блоги позволяют загружать опять же аватарки и/или изображения.

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

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

В начале августа в нескольких десятках npm-пакетов был обнаружен вредоносный код. Администрация npmjs.com оперативно на это отреагировала и тут же подготовила отчёт о предпринятых мерах. Позже Доминик Кундел из twilio.com поделился советами о том, как найти проекты, «заражённые» подобными пакетами. Представляем вашему вниманию рассказ об этих событиях.

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

TL;DR: Работа с таймзонами — это боль и унижение. Никогда не работайте с таймзонами!

Итак, все кругом твердят вам, что при получении времени от пользователя нужно сразу же переводить его в UTC, работать со временем нужно только в UTC и хранить время тоже нужно строго в UTC. Совет, на первый взгляд, выглядит разумным, и следование ему делает вашу жизнь проще… Если только ваша программа не предполагает сложной работы с датами. Записать в базу данных дату и время регистрации пользователя на сайте? Сохранить время отправки сообщения или дату создания заказа в интернет-магазине? Вывести сообщение в лог с указанием даты-времени? Используйте UTC и всё будет в порядке, можете даже не читать эту статью дальше. Любое текущее время можно совершенно спокойно конвертировать в UTC и забыть о проблемах. Но что, если мы хотим работать с временем в будущем? Или в прошлом? Например, если мы пишем сервис календаря, или сервис для отложенной отправки сообщений?

В английском есть такая аббревиатура — TIFU. Привести здесь её точное значение мы не можем, но вы без труда найдёте его в Сети. А после «литературной обработки» TIFU можно перевести как «сегодня я всё испортил». В контексте этого поста данная фраза относится к использованию функции Math.random() в JavaScript-движке V8. Хотя случилось это не сегодня, а пару лет назад. Да и дров я наломал не по своей вине, корень зла таится в самой этой функции.

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

Дональд Кнут, «Искусство программирования», том 2.

Надеюсь, что к концу этого поста вы согласитесь с двумя утверждениями:

• Мы были идиотами, поскольку использовали генератор псевдослучайных чисел в V8, не понимая его ограничений. И если очень лень, то безопаснее использовать криптографически стойкие генераторы псевдослучайных чисел.
• В V8 необходима новая реализация Math.random(). Работу текущего алгоритма, кочующего от одного программиста к другому, нельзя считать удовлетворительной из-за слабой, неочевидной деградации, часто встречающейся в реальных проектах.

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

Правило №1. Делайте все авторизационные куки HttpOnly

Куки с флагом HttpOnly не видны браузерному коду, а отправляются только на сервер. На практике у вас почти никогда нет необходимости получать их содержимое со стороны клиента (если такая необходимость почему-то у вас возникла — пересмотрите архитектуру авторизации, скорее всего, там что-то не так). А вот злоумышленнику, нашедшему XSS — а XSS так или иначе когда-нибудь где-нибудь найдется — отсутствие HttpOnly на авторизационных куках доставит много радости.

Я думаю, что в процессе изучения той или иной СУБД каждый из вас не раз изобретал велосипеды для решения своих задач, не зная о существовании той или иной функции или приема, которые бы могли в разы ускорить выполнение запросов и уменьшить объем кода. В данной статье я хочу поделиться с вами своим опытом работы с очень «добрым» и «отзывчивым» MySQL, часто позволяющему программисту делать вещи, которые другие СУБД переварить бы не смогли. Материал будет полезен скорее тем, кто только решил углубиться в чудесный мир запросов, но возможно и опытные программисты найдут тут что-то интересное.

Материал предназначен в основном для начинающих веб-программистов.

Введение.

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

Здесь я постараюсь описать как можно подробнее частые ошибки при фильтрации данных в PHP скрипте и дать простые советы как правильно выполнить фильтрацию данных.

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

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

Очень краткая история контроля над использованием ядерного оружия

Лучше всего я знаком с попытками контроля использования ядерного оружия (ЯО) в США, начинавшимися в конце 1950-х и начале 1960-х. Распространение американского оружия по всему миру, включая поставки членам НАТО, сильно повлияло на озабоченность гражданского населения его подчинением законам США и предотвращением несанкционированного использования оружия союзниками. В популярном анекдоте Гарольд Агню [американский физик, известный как научный наблюдатель атомной бомбардировки Хиросимы и Нагасаки, а позднее третий директор Национальной лаборатории в Лос-Аламосе – прим. перев.], приезжает на аэродром и видит, как американские ядерные бомбы загружают на немецкие самолёты с немецкими пилотами, а рядом стоит одинокий часовой из США. Агню спрашивает часового, что тот сделает, если пилот попытается взлететь без авторизации. Часовой отвечает, что он подстрелит пилота, но Агню говорит, что вместо этого лучше подстрелить бомбу.

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

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

Несколько лет назад покупка или продажа BTC за фиат («настоящую» валюту вроде долларов, евро, рублей и т.д.) была вообще непростым делом, но сейчас времена изменились, всё стало гораздо проще.

Поэтому я решил жить только на биткоины, и вот как я пытаюсь реализовать этот план.

Старые методы по-прежнему работают

[Обновление] Теперь я в каком-то списке спецслужб, потому что написал статью про некий вид «бомбы», так?

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

Когда я в возрасте 13 лет впервые захостил свою маленькую Linux-коробочку с доступом по SSH, я смотрел логи и каждый день видел IP-адреса (в основном, из Китая и России), которые пытались подключиться к моей сладенькой маленькой коробочке (которая на самом деле была старым ноутом ThinkPad T21 со сломанным дисплеем, жужжавшим под кроватью). Я сообщал эти IP их провайдерам.

На самом деле если у вас Linux-сервер с открытым SSH, то можете сами посмотреть, сколько попыток подключений происходит ежедневно:

grep 'authentication failures' /var/log/auth.log

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

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

У всех это было: учишь какой-то язык, штудируешь один учебник за другим — и ничего. Тогда начинаешь сомневаться: «это слишком сложно», «программирование, наверное, не для меня». Уверен, это чувство вам знакомо.

Меня самого недавно настигла эта напасть: мне — уже неплохо освоившемуся младшему PHP-разработчику — вдруг захотелось слегка глубже изучить Python, особенно Django.

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

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

Однако осилив 80% руководства, я начал сомневаться. Я просмотрел видео и вручную переписал весь код. У меня был отличный проект, который можно показать другим. Так почему же мне казалось, что за все это время навыков у меня не прибавилось?

Переведено в Alconost

На работе в новом проекте используется СУБД PostgreSQL. Так как до сих пор я работал с MySQL, сейчас приходится изучать и открывать для себя Постгри. Первая проблема, которая меня заинтересовала — замена мускулевского SQL_CALC_FOUND_ROWS. При использовании этой константы в MySQL можно получить количество всех найденных по запросу записей, даже если запрос с limit'ом — это незаменимо при постраничном выводе поисковых результатов, когда используются «тяжелые» запросы.
Сходу готового решения найти не удалось. На форумах просто констатировали, что SQL_CALC_FOUND_ROWS в Постгри нет. Некоторые писали, что надо юзать count(*). И больше никакой информации. Но еще из MySQL мне было известно, что поиск с count()-запросом работает почти в 2 раза медленнее, чем с SQL_CALC_FOUND_ROWS. Я консультировался у тех, кто пользуется PostgreSQL, день мучал google и в результате получил 4 варианта замены SQL_CALC_FOUND_ROWS в PostgreSQL, один из которых вполне приемлимый по скорости.

Если вам это знакомо то прошу под кат.

[ Часть I. Доставка видеоконтента ] [ Часть II. CDN своими руками ]

Что такое «контент» для видеохостинга? Во-первых, контент видеохостинга – это просто видео, которое представляет собой набор файлов в различных форматах, в частности, в формате FLV для просмотра пользователем через Flash Player. Эти файлы статичны, видеохостинг при загрузке пользователем видеоролика осуществляет конвертацию во все требуемые форматы с необходимым битрейтом. Хранение такого контента — это хранение обычных файлов, только довольно большого размера. Отдача контента — это, по сути, организация скачивания файлов.
Во-вторых, контент видеохостинга — это «живые» потоки или вещания. Вещания не записываются на диск, не происходит их конвертация, потоки раздаются клиентам с учетом пропускной способности каналов (происходит пропуск пакетов, если канал клиента недостаточен для получения потока вещания в полном качестве). Отдача контента в данной ситуации — это раздача потока на большое количество подключенных пользователей (тысячи смотрящих).

Что такое онлайн-видео?

Под термином онлайн-видео я понимаю длительное вещание какого-то живого видеосигнала (к примеру, из телестудии). Традиционные средства отдачи видео (flv- и mp4-стриминг) в данном случае не работают, просто потому что файла, содержащего весь видеопоток, не существует.

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

[ Часть I. Доставка видеоконтента ] [ Часть II. CDN своими руками ]

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

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

Кроме того, имеет смысл «приблизить» контент к пользователю географически. Это связано с пропускной способностью каналов (отсутствием иногда хороших магистральных каналов), а также с разницей в стоимости локального и внешнего трафика для конечного пользователя (например, в регионах РФ).

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

Таким образом, осознав необходимость географической распределенности для контента, мы покупаем/арендуем сервера в непосредственной близости от потребителя: в Европе, США, Украине, Екатеринбурге и т.д.

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

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