Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Буду откровенен - возможный заказчик просто скинул список того, что ему требуется от инструментария для разработки сайта, а я чёт и потерялся, поскольку знаю мало о том, что входит в безопасность Laravel. Уж не знаю, будут ли меня ждать, но на будущее хочется всё-таки собрать инфу по безопасности.
Итак:
Поиск уязвимостей в веб-окружении сервера;
...
Поиск уязвимостей серверных компонентов;
...
Проверка на удаленное выполнение произвольного кода;
...
Проверка на наличие инъекций (внедрение кода);
Знаю лишь, что sql инъекции невозможны, т.к работа с бд делается через eloquent или конструктор запросов. Но можно ли как-то ещё внедрить код, я не знаю
Попытки обхода системы аутентификации веб-ресурса;
...
Проверка веб-ресурса на наличие «XSS» / «CSRF» уязвимостей;
Знаю, что можно добавить CSRF в форму.
Попытки перехватить привилегированные аккаунты (или сессии таких аккаунтов);
...
Попытки произвести Remote File Inclusion / Local File Inclusion;
...
Поиск компонентов с известными уязвимостями;
...
Проверка на перенаправление на другие сайты и открытые редиректы;
...
Сканирование директорий и файлов, используя перебор и «google hack»;
...
Анализ поисковых форм, форм регистраций, форм авторизации и т.д.;
...
Проверки ресурса на возможность открытого получения конфиденциальной и секретной информации;
Ну, скрытые файлы можно хранить в storage и давать им доступ через ссылки и уж в роутах проверять права. Это, если я правильно понял, о чём идёт речь.
Атаки класса «race condition»;
...
Внедрение XML-сущностей;
...
Подбор паролей.
Разве от этого кто-то застрахован?
Изменено Kirir (28.11.2018 00:17:50)
Связь со мной:
Скайп(с аватаркой) - shyraks
Телеграм - @Mramoris или +7 999 260 13 20
Не в сети
Мастер 
Заказчик хочет получить веб-программиста и аудит безопасности в одном флаконе? При разницы з/п у обоих примерно в 20 раз...
но на будущее хочется всё-таки собрать инфу по безопасности.
Это не то, что можно просто "собрать" и вызубрить. Нужно понимать работу всех компонентов, в том числе нижележащих - PHP, веб-сервера, протоколов. Я на пару пунктов отвечу для интереса, но это только вершина айсберга.
Проверка на удаленное выполнение произвольного кода;
Если не использовать eval($_GET['x']); то RCE в PHP получить не получится, к счастью.
Проверка на наличие инъекций (внедрение кода);
Внедрение кода в SQL?..
В любом случае, если использовать ORM, то шанс получить инъекцию очень мал, но остается, ведь "сырые" выражения никуда не деваются. Правда, некоторые любят использовать целые сырые запросы в сложных случаях, когда ORM снижает читабельность - тогда риск больше.
Проверка веб-ресурса на наличие «XSS» / «CSRF» уязвимостей;
Странно, что две совершенно разные проблемы объединены в один пункт.
XSS - когда в шаблоне нет экранирования пользовательского ввода (который может прийти не только напрямую из GET/POST, но и косвенно через БД, к примеру). Тогда можно вставить свой код на страницу, утащить cookie с сессией и другие пользовательские данные, вроде кредиток.
XSS бывают отраженной и хранимой, об этом писать не буду.
CSRF - возможность выполнить действие "за" пользователя без его явного согласия. Например, есть маршрут вида "GET //my.site/delete/account". Кто-то авторизовался на вашем сайте, перешел на "вредоносный" ресурс, где стоит картинка с этим URL: <img src=".../delete/account">. Результат - браузер запросил картинку, это вызвало удаление аккаунта.
Решается добавлением скрытого token к подобным маршрутам: //my.site/delete/account?csrf=token. Вредоносный сайт token знать не будет, поэтому запрос на удаление будет отклонен.
Внедрение XML-сущностей;
Еще более странно, что этот класс отдельно от XSS. По сути то же самое, только вставка своего ввода не в HTML, а в XML. На большинстве сайтов XML нет, RSS, к сожалению, умер, поэтому про это можно не думать.
Попытки произвести Remote File Inclusion / Local File Inclusion;
Это, к счастью, вымерло окончательно благодаря автозагрузке классов.
require $_GET['lang'].'.php';
RFI - когда lang=http://my.site/inc.php
LFI - когда lang=/tmp/upload/f78a.tmp
То есть можно выполнить произвольный PHP-код на сервере. Очень опасная штука.
Проверка на перенаправление на другие сайты и открытые редиректы;
Имеем форму логина и переменную типа "page". По смыслу, когда человек вошел на сайт, его перекидывает обратно на данную "page". Однако без дополнительных проверок, если page - любой URL, то получаем "open redirect": /login?page=http://my.site/xxx
Это плохо для SEO. Также это может сбить с толку пользователя, если my.site внешне неотличим от исходного сайта - можно, к примеру, подсунуть пользователю "форму входа", он подумает, что ошибся в пароле и введет свои данные снова, только на этот раз - на подставном сайте.
Сканирование директорий и файлов, используя перебор и «google hack»;
Я просто оставлю это здесь: https://habr.com/post/70330/
Проверки ресурса на возможность открытого получения конфиденциальной и секретной информации;
Файлы во всяких форумах и CMS часто сохраняют в какую-то общую папку без защиты доступа. Если у тебя есть ссылка (имя файла) - то даже не имея прав просматривать форум/раздел CMS ты можешь получить файл. Это не обязательно плохо, т.к. к примеру может использоваться для расшаривания файлов другим людям, но многие сайты этим грешат. Чтобы этого не было, используют специальные ссылки с хэшем, см. к примеру nginx: http://nginx.org/ru/docs/http/ngx_http_ … odule.html
Отдавать статику через PHP плохая идея из-за производительности. На форуме уже была тема.
Другая проблема - перебор идентификаторов. Я сделал заказ 1234, и если нет проверок на права (а их очень часто забывают) - я могу открыть ту же страницу с заказом, но дописав в параметр не 1234, а 1235. И увижу заказ другого человека.
Решается тоже добавлением хэша/секретной строки.
Атаки класса «race condition»;
Про это можно целую книгу написать. Вкратце, есть маршрут заказа некоего товара. Если программист не озаботился защитой от гонки, то там будет что-то такое:
if ($user->balance >= $order_total) {
create_order();
$user->balance -= $order_total;
$user->save();
}
Итого, сделав 2 и более запросов одновременно (а это не так сложно, имея быструю сеть в дата-центре) я могу загнать пользователя в минус, не имея достаточно денег на балансе.
Данный конкретный пример решается оборачиванием всего маршрута в транзакцию, но этот пример мне просто пришел в голову с ходу, а на практике гонка встречается в самых разных формах и может вылиться в крупные суммы для ресурса, если постоянно не держать эту возможность в голове.
Подбор паролей.
Без деталей можно только гадать, что имелось в виду - повесить CAPTCHA, ограничить число попыток ввода с IP или что-то более умное вроде атак по времени на токены, может даже BREACH...
В целом, насчет возможности подбора паролей переживать не стоит, это самая малая проблема для сайта - пользователи, которые не парятся о своих паролях, найдут способ любые ваши ограничения ("один знак, заглавная буква и цифра" = "aA1!") и их все равно взломают, а те, которые парятся, сгенерируют такой пароль, что его даже без CAPTCHA можно брутфорсить до конца времени.
Меня больше волнуют банки, которые не позволяют использовать больше 16 знаков в пароле, или которые ограничивают набор символов только цифрами (привет, ВТБ).
Не в сети
Вери сенк!
Связь со мной:
Скайп(с аватаркой) - shyraks
Телеграм - @Mramoris или +7 999 260 13 20
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)