Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Кевину Митнику, родоначальнику социальной инженерии, принадлежат золотые слова:

Социальный инженер задумал заполучить проект (исходники) Вашего нового продукта за 2 месяца до релиза.
Что остановит его?
Ваш файервол? Нет.
Мощная система идентификации? Нет.
Система обнаружения вторжений? Нет.
Шифрование данных? Нет.
Ограничение доступа к номерам дозвона модемов? Нет.
Кодовые имена серверов, которые затрудняют определение местонахождения проекта искомого продукта? Нет.
Смысл здесь в том, что никакая технология в мире не сможет противостоять атаке социального инженера.

Однако частично обезопасить себя всё же можно – изучив, чем движим социальный инженер, как он мыслит и действует, какими приёмами пользуется. Зная это, можно уберечь себя от атак социальных инженеров. Подробно об этом можно почитать в книге про Кевина Митника «Искусство обмана». Однако поскольку книги читать мало кто любит, можно посмотреть фильм «Взлом», где хорошо проиллюстрированы приёмы, которыми пользовался Кевин. Ниже представлены ключевые видеофрагменты из этого фильма. Их вполне можно использовать при проведении корпоративных тренингов по информационной безопасности.

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

Предыдущие части: первая, вторая.

To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.

«Лучший способ писать — это переписывать» Пол Грэм, «The Age of the Essay»

Преред курсом Сергея Абдульманова ( milfgard) я взял для себя квест — структурировать все статьи Грэма. Пол не только крутой программист и инвестор — он мастер лаконичного письма. Если milfgard назвал свой курс для контент-менеджеров "Буквы, которые стреляют в голову", то Пол Грэм стреляет из «по глазам» (кто играл в Fallout 2 тот поймет).

А еще мне захотелось освоить Lisp. Чисто так, чтобы мозг поразвивать, потому что крутые люди — Грэм, Кей и Рэймонд, Моррис — говорят хором: «Учите Lisp».

На данный момент Пол Грэм написал (по крайней мере, я нашел) 167 эссе. Из них на русский переведены 69.74(+10). Если читать по 1 статье в день (что очень хороший результат, потому что я после одной статьи хожу задумчивый неделю — голова кипит как после отличного мастер-класса, а иногда и как после двухдневного интенсива), то процесс займет полгода.

Под катом — список всех статей со ссылками на оригинал и с переводом (если он есть). Подборка живая (так что, как обычно, добавляйте в избранное, потом прочитаете) и будет дополняться по мере обнаружения свежака. Еще вы найдете переведенную на 8/15 книгу «Хакеры и художники» и 4/25 перевода книги «On Lisp». Так же я приведу свою подборку топ-5 статей Пола Грэма, с которых я бы рекомендовал начать знакомство с этим автором.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

В отличие от CTF-соревнований, лаборатории тестирования на проникновение «Test lab» имитируют ИТ структуру настоящих компаний и имеют полноценную легенду. Созданные для легальной проверки и закрепления навыков пентеста, лаборатории всегда уникальны и содержат самые актуальные уязвимости, а участие в лабораториях требует хорошей практической подготовки.

Разрабатывая лаборатории «Test lab» мы стараемся охватить практически все области ИБ: безопасность сетей, ОС и приложений. Участникам предлагается выполнить эксплуатацию различных уязвимостей, связанных с работой сетевых компонентов и криптографических механизмов, ошибками конфигурации и кода, а также с человеческим фактором. Участники, выступающие в роли пентестеров, пытаются эксплуатировать их, и, в случае удачи, получают доступ к серверам и рабочим станциям, каждый из которых содержит токен. Победителем считается участник, первым собравший все токены. Работа в лаборатории осуществляется на основе методики «серый ящик»: перед началом исследования предоставляется информация об инфраструктуре «Test lab» в виде схемы и описания деятельности виртуальной компании. Собирая пентестеров со всего мира, мы разрабатываем лаборатории «Test lab» для различных мероприятий, таких как всероссийский конкурс ПрофИТ-2013, ZeroNights'13, PHD IV.

Test lab v.7

В предыдущей лаборатории «Test lab v.7», запущенной 01 мая 2015 г, приняло участие более 2000 участников из 73 стран мира. Большинство активных участников были из России, Украины, США, Германии и Китая. По мнению пентестеров, наиболее интересные задания были связаны с эксплуатацией уязвимостей веб-приложений, в то время как брутфорс не представлял особого интереса и реализовывался в последнюю очередь, несмотря на то, что по мировой статистике уязвимости, связанные с использованием нестойких паролей, являются одной из основных причин компрометации корпоративных сетей.

На YouTube появились записи выступлений с Positive Hack Days V — несколько десятков докладов по практической безопасности на русском и английском языках. В 2015 году на форуме говорили не только о хардкорных методах взлома, но и о «нетехнических» атаках. Многим запомнился доклад Криса Хаднаги (Chris Hadnagy), который для получения информации использует особенности человеческой психики и не верит в технический прогресс: «Пока вы ищите уязвимости нулевого дня, мы просто поднимаем трубку телефона и узнаем ваши секреты». В этом материале мы расскажем несколько историй и наблюдений из практики 42-летнего американца.

Kore Nordmann

В первой части мы рассматривали высокоуровневые различия во внутреннем представлении значений между PHP 5 и PHP 7. Как вы помните, главное отличие заключается в том, что zval больше не выделяются отдельно и не хранят в себе refcount. Простые значения, вроде целочисленных или с плавающей точкой, могут храниться прямо в zval, в то время как сложные значения представляются с помощью указателя на отдельную структуру.

Привет, Хабр!

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

• С чего начать обучение программированию?
• У вас есть курс по Java для новичков, но я слышал, что нужно изучать Python, правда ли это?
• На других сайтах все просто и понятно, а у вас какие-то компиляции и тесты!
• Непонятно зачем нужен этот ваш курс по алгоритмам, в реальной жизни все алгоритмы уже реализованы в стандартных библиотеках

Но сложнее всего объяснить новичку, грубо говоря, во что он ввязывается. Благодаря очень простым, игровым образовательным проектам многие считают, что программирование это очень легко, а наши виртуальные машины, где нужно запускать тесты и компилировать код – это надуманная сложность. Давно хотелось найти такой материал, который бы подготовил новичка к длинному и сложному пути к карьере программиста. И недавно наши коллеги из Viking Code School такой материал написали! А мы его перевели для вас.



Квинси Ларсон был просто “офисным парнем в костюме”. Он решил научиться программировать. Начал спрашивать людей вокруг. Изучил немного Руби, потом быстренько посмотрел на другие языки вроде Scala, Clojure и Go. Он изучил Emacs, а потом Vim, а потом раскладку Dvorak. Он втыкал в Линукс, копался с Лиспом и кодил на Питоне, и жил при этом в командной строке больше полутора лет.

Его швыряло туда-сюда как листочек в торнадо. Каждый совет, который он слышал, тащил его то в одну, то в другую сторону, до тех пор пока он не прошел “каждый онлайн-курс по программированию во вселенной”. В конце концов, не смотря на то, что он получил работу разработчика ПО, Квинси:

… был уверен, что на первый взгляд нормальные программисты, с которыми я общался, были на самом деле социопатами, которые получили, а потом подавили в себе, травму при изучении программирования.

Ох. Звучит знакомо?

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

Долго и сложно выбирая темы, что же все-таки рассказать разработчикам фронтендов про безопасность, при этом минимум касаясь бекэнда (местами все-таки это неделимо), получился доклад, а здесь — его текстовый пересказ.

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.

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

Меня настолько заинтересовал вопрос о книгах, что я решил начать новую серию статей на своём сайте catonmat о моих топ-100 книгах о программировании, программном обеспечении, науке, физике, математике и компьютерах. В каждой статье я буду размещать по пять книг, ведь разбивать огромное задачи на маленькие подзадачи — это самый простой способ их решать (GTD — get things done).

Взгляните на мою книжную полку, чтобы убедиться, что я настоящий ботаник:

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

Для статьи я подобрал наиболее полезные дополнения «на все случаи жизни».

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

Итак, перейдём к резюме и ошибкам, которые вы совершаете.

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

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Крупнейший международный портал разработчиков StackOverflow провёл ежегодный опрос. Участвовали более 26 тысяч человек из 157 стран. Результаты получились очень интересные.

Общая картина

Самая большая концентрация разработчиков на 1000 человек в Люксембурге, Исландии и Швеции. Средний возраст разработчика — 28.5 лет и его дата рождения приходится на апрель 1986 года. Женщин менее 6% и почти половина из них начали программировать лишь в последние 2 года.

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



Далее много слов и картинок.

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

Приходится прибегать к кластеризации: несколько серверов объединяются в кластер; нагрузка между ними распределяется при помощи комплекса специальных методов, называемых балансировкой. Помимо решения проблемы высоких нагрузок кластеризация помогает также обеспечить резервирование серверов друг на друга.
Эффективность кластеризации напрямую зависит от того, как распределяется (балансируется) нагрузка между элементами кластера.

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

Студент в Big Data получает 70 тысяч рублей в месяц, а специалист с опытом 3-4 года — 250 тысяч рублей в месяц. Это те, например, кто умеет персонализировать предложения розницы, искать в соцсети человека по анкетным данным заявки на кредит или по списку посещённых сайтов вычислять новую симку старого абонента.

Мы решили сделать профессиональный курс по Big Data без «воды», маркетинга и всяких эджайлов, только хардкор. Позвали практиков из 7 крупных компаний (включая Сбербанк и Oracle) и устроили, фактически, хакатон длиной во весь курс. Недавно у нас прошел день открытых дверей по программе, где мы напрямую спросили практиков, что же есть Big Data в России, и как компании на деле используют большие данные. Ниже ответы.

Думали ли вы когда-нибудь о том, что однажды слишком быстро втянулись в веб-программирование на PHP? И вот уже прошло много лет, у вас хороший опыт, и вы не думаете ни о каких других способах „делать“ веб, кроме как на PHP. Может быть, у вас возникают сомнения в правильности выбора, однако непонятно, как найти способ быстро его проверить. А хочется примеров, хочется знать, как изменятся конкретные аспекты деятельности.

Сегодня я попробую ответить на вопрос: «А что если вместо PHP писать на Python?».

Сам я долгое время задавался этим вопросом. Я писал на PHP 11 лет и даже являюсь сертифицированным специалистом. Я научился его «готовить» так, чтобы он работал в точности, как мне надо. И когда я в очередной раз читал на Хабре перевод статьи о том, как всё в PHP плохо, я просто недоумевал. Однако подвернулся случай пересесть на Ruby, а потом и на Python. На последнем я и остановился, и теперь попробую рассказать вам PHP-шникам, как нам питонистам живётся.

Привет, Хабр!

В этой статье предлагаю читателю ознакомится с уязвимостями веб-приложений (и не только), по классификации OWASP Top-10, и их эксплуатацией на примере bWAPP.