Я бы убрал |sh; nc /dev/tcp/localhost, иначе «PoC» может сработать даже если на сервере жертвы не установлен nginx (причём сервер жертвы, явно не удалённая машина).
В итоге, мы решили сделать 2 вида чатов — секретные и облачные. Секретные чаты поддерживают E2E-шифрование и никогда не включаются в резервные копии. Облачные чаты точно так же зашифрованы, но копируются в облако. Облачные чаты рассчитаны на большинство пользователей — на тех, кто в другом приложении, например, WhatsApp, будет полагаться на менее безопасные резервные копии, хранящиеся у третьих лиц. В отличие от нишевых приложений, трафик между пользователями облачных и секретных чатов неотделим (используется одно и то же шифрование, но у сервера есть ключ шифрования от облачных чатов), поэтому никого нельзя «взять на карандаш», опираясь на то, что человек использует секретные чаты и потому ему есть, что скрывать.
В первое время управлять тазерами, конечно, будут операторы. Но можно представить, что в далёком будущем патрулирование района и обезвреживание преступников станет осуществляться алгоритмически.
Мне кажется, всё намного интереснее, поскольку взлом происходит примерно в 1999-2000 (симуляция), когда эксплойт был опубликован только в 2001 (наш мир). Получается, именно Тринити обнаружила эту уязвимость, а машины просто не могли предвидеть уязвимость нулевого дня.
К тому же, не вижу ничего странного в том, что «кто-то забыл» патчить систему или сделать бэкапы.
Позвольте не согласиться с Вами. Хоть я и не химик, но даже я бы огорчился, увидев, что она пытается убить монстра с помощью H2O или NaCl. Я более чем уверен, что для тех, кто «разбирается» в теме, эти «мелкие детали» очень важны, даже если они длятся считанные секунды. Например, для меня было настоящим подарком увидеть сценарий реального взлома в Матрице (сканирование с помощью nmap → обнаружение открытого порта → применение настоящего эксплойта → подключение по ssh). С другой стороны, есть фильмы, в которых «хакеры» взламывают системы с помощью HTML-кода или командой ping 127.0.0.1.
Конечно, я и раньше считал, что «Чужой» хороший фильм, но только благодаря «тому кто в теме» я понял, что фильм намного круче.
А я всегда думал, что по-настоящему «опытные программисты-фрилансеры» никогда не заняты ;)
Насчёт ТЗ, я уже сказал своё мнение — профессионал должен сделать всё правильно, даже если заказчик ничего в этом не понимает или указал в ТЗ «ЧТО» делать, но не указал «КАК» это делать. Например, если у Вас есть заказ на вёрстку сайта, Вы ведь не будете использовать иконки в формате BMP по 99МБ каждая, даже если заказчик ничего не указал об этом в ТЗ. Также, я уверен, что Вы не будете тестировать результат только в одном браузере.
При необходимости профессионал должен описывать несколько сценариев и позволить заказчику выбрать то, что ему подходит. Более того, если заказчик указал в ТЗ, что необходимо применить плохое решение, профессионал должен донести это до заказчика.
И это касается не только программистов, но и всех специалистов, включая механиков, врачей, сантехников, строителей и других.
Почему Вы думаете, что опытные программисты не хотят получить, скажем, €200 за пару часов работы и хороший проект для своего портфолио?
Дело в том, что опытному программисту не нужны несколько дней, чтобы имплементировать процесс регистрации в готовом проекте. Например, первый фрилансер сдал работу через 21 часов, но он хранил пароли как обычный текст. Когда его попросили защитить пароли, ему потребовалось 38 часов, чтобы сделать это (для сравнения, один из фрилансеров перешёл на BCrypt всего за 4 минуты). Разве это не говорит о том, что задача была довольно проста для опытного разработчика?
Проблема в том, что «низкооплачиваемые ноунеймы» охотно откликаются и на проекты с большим бюджетом. Если исследователи заплатили бы больше, это привело бы к увеличению числа исполнителей, но минимум 8 из них всё ещё использовали бы Base64. Думаю, стоимость работы не играет самой важной роли, иначе из 43 фрилансеров все бы использовали Base64, а не только 8 из них.
Поэтому, Вы должны задаваться следующим вопросом: почему большинство фрилансеров за те же условия (деньги и ТЗ) использовали правильные алгоритмы, а некоторые нет.
Лично я всегда думал, что есть вещи, которые не нуждаются в ТЗ. Например, затяжка колёсных болтов, хеширование паролей, использование метода POST для передачи конфиденциальных данных, и так далее.
Например, заменить base64_encode() на password_hash() ничего не стоит (наоборот, даже сократит время разработки). И поверьте, стоимость работы никак не влияет на профессионализм разработчика. Если человек говорит, что «очень сложно расшифровать Base64», можете заплатить ему хоть миллион, от этого он не перестанет «шифровать пароли с помощью Base64» или хранить их как обычный текст. Достаточно взглянуть на крупные корпорации, которые забывают, как правильно хранить пароли и сразу становиться ясно, что проблема скорее всего не в деньгах.
Нет, «пляшущие человечки», как и Base64 никогда не являлись шифрованием. Например, шифрование обязательно требует ключ и обеспечивает целостность данных, когда ни «пляшущие человечки», ни Base64 не умеют это (разве что ASCII armor может защитить целостность Base64 от случайного повреждения).
Я подумал, что цитата, смайлик и описанные мною «преимущества», должны намекать, что я явно не считаю Base64 алгоритмом шифрования. Но оказалось, что в конце недели люди воспринимают вещи «слишком буквально».
На самом деле этот образец был предоставлен не команде iFixit, а другому человеку, который (скорее всего, нарушая правила) передал его iFixit. В свою очередь, они написали, что не были обязаны удалить статью, но сделали это из уважения к человеку, предоставляющему смартфон.
Получается, в ТЗ заказчик должен написать всё подробно, в том числе, что пароль пользователя необходимо:
— Хранить как CHAR, а не как INT.
— Передать методом POST, а не GET.
— Хешировать, а не шифровать.
Скорее всего ещё придётся указать, что если пользователь будет ввести неверный пароль, то не нужно его авторизовать. И конечно, что необходимо обезопасить приложение от SQL-инъекций и CSRF-атак.
Почему сложно? Base64 — алгоритм шифрования, который не использует ключ для шифрования и дешифрования информации. Основными преимуществами алгоритма являются скорость, компактность и универсальность :)
|sh; nc /dev/tcp/localhost, иначе «PoC» может сработать даже если на сервере жертвы не установлен nginx (причём сервер жертвы, явно не удалённая машина).Это не ключ, а алфавит. У Base64 тоже есть свой алфавит.
Вы правы, я ляпнул необдуманное. Благодарю за поправку!
К тому же, не вижу ничего странного в том, что «кто-то забыл» патчить систему или сделать бэкапы.
ping 127.0.0.1.Конечно, я и раньше считал, что «Чужой» хороший фильм, но только благодаря «тому кто в теме» я понял, что фильм намного круче.
Насчёт ТЗ, я уже сказал своё мнение — профессионал должен сделать всё правильно, даже если заказчик ничего в этом не понимает или указал в ТЗ «ЧТО» делать, но не указал «КАК» это делать. Например, если у Вас есть заказ на вёрстку сайта, Вы ведь не будете использовать иконки в формате BMP по 99МБ каждая, даже если заказчик ничего не указал об этом в ТЗ. Также, я уверен, что Вы не будете тестировать результат только в одном браузере.
При необходимости профессионал должен описывать несколько сценариев и позволить заказчику выбрать то, что ему подходит. Более того, если заказчик указал в ТЗ, что необходимо применить плохое решение, профессионал должен донести это до заказчика.
И это касается не только программистов, но и всех специалистов, включая механиков, врачей, сантехников, строителей и других.
Дело в том, что опытному программисту не нужны несколько дней, чтобы имплементировать процесс регистрации в готовом проекте. Например, первый фрилансер сдал работу через 21 часов, но он хранил пароли как обычный текст. Когда его попросили защитить пароли, ему потребовалось 38 часов, чтобы сделать это (для сравнения, один из фрилансеров перешёл на BCrypt всего за 4 минуты). Разве это не говорит о том, что задача была довольно проста для опытного разработчика?
Поэтому, Вы должны задаваться следующим вопросом: почему большинство фрилансеров за те же условия (деньги и ТЗ) использовали правильные алгоритмы, а некоторые нет.
Например, заменить
base64_encode()наpassword_hash()ничего не стоит (наоборот, даже сократит время разработки). И поверьте, стоимость работы никак не влияет на профессионализм разработчика. Если человек говорит, что «очень сложно расшифровать Base64», можете заплатить ему хоть миллион, от этого он не перестанет «шифровать пароли с помощью Base64» или хранить их как обычный текст. Достаточно взглянуть на крупные корпорации, которые забывают, как правильно хранить пароли и сразу становиться ясно, что проблема скорее всего не в деньгах.Я подумал, что цитата, смайлик и описанные мною «преимущества», должны намекать, что я явно не считаю Base64 алгоритмом шифрования. Но оказалось, что в конце недели люди воспринимают вещи «слишком буквально».
— Хранить как CHAR, а не как INT.
— Передать методом POST, а не GET.
— Хешировать, а не шифровать.
Скорее всего ещё придётся указать, что если пользователь будет ввести неверный пароль, то не нужно его авторизовать. И конечно, что необходимо обезопасить приложение от SQL-инъекций и CSRF-атак.