Для начинающих PHP программистов

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


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

1.Чтобы защититься от хакера, ты должен думать как он.
Любой взломщик впервую очередь проверяет различные формы на сайте, к примеру регистрация, форумы, и т.д.
Поэтому первое, всегда фильтруйте ваши данные.
Я рекомендую использовать регулярные выражения - это мощный инструмент для работы со строками.
В скрытом поле не передавайте важные данные, если передаете то, используйте необратимое шифрование.
Ставляйте тройную проверку, да именно тройную.
1. На стороне клиента
2. На стороне сервера.
3. Пусть пользователь подтвердит себя.
Пользователь может отключить JS , но он не сможем ничего сделать против интепритатора.

2. Если вы заносите данные в БД, то обязательно как и говорилось фильтруйте данные через регулярные выражения, и используйте новые технологии к примеру PDO, делайте различные проверки, но самый мощный инструмент я бы сказал это регулярные выражения
Делайте двойное шифрование для пароля + прикрепляйте соли, таким образом если взлоумышленник получит доступ он потратит долгое время что бы это расшифровать.

3.Не используйте у себя в скриптах такие команды как exec или shel_exec(), на Windows он у Вас не сработает, но проверьте мне у меня стоит Linux и это очень мощная функция, благодоря которой можно общаться с системой.
Закрывайте доступ ко всем папкам через .htaccess конфигурационный файл, а также к файлам.
Внимательно используйте подключателей в PHP, если вы работаете с .htaccess то это не страшно.
Я сам работал со своим проектом , и получал доступ через так называемый удаленный PHP инклуд, но посредствам .htaccess это решается очень быстро, защищайте URL, передаваемые параметры шифруйте, а также проверяйте, на обеих сторонах.

4.Каждому расшерению ставляйте свои права доступа к примеру .php он выполняется на стороне сервера, а его клиент не читает поэтому ставляйте расширение только на выполнение, о том как это делаете прочтите в интернете права доступа Linux.
Почему Linux ? Все хостинги практически стоят на ядре Linux.

5.Если вы загружаете файлы обязательно проверяйте размер, тип файла, ставляйте запрет для exe. bat форматом.

И ЗАПОМНИТЕ ЛЮБОЕ ОБРАЩЕНИЕ К СИСТЕМЕ ЭТО ОПАСНО, А К ФАЙЛОВОЙ ВДВОЙНЕ

6. Если вы работаете с файлами не используйте file() readfile() fgets() так как они читают все html теги, взлоумышленник может туда внедрить js код и выполнить сценарий, используйте fgetss() которая удаляет NULL и html и php теги.

Я думаю это пока достаточно, всем спасибо)

2

Сообщение от maxoun Сам я не гуру в этом

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

0

а я все жду когда меня начнет хоть кто-то взламывать

0

Скорее вредные советы

Сообщение от maxoun Я рекомендую использовать регулярные выражения - это мощный инструмент для работы со строками.

Идет смешивание понятий валидация данных и экранирование. Регулярки не следует рассматривать как инструмент защиты

Сообщение от maxoun если передаете то, используйте необратимое шифрование.

Как же передать, если данные необратимо зашифрованы?

Сообщение от maxoun Если вы заносите данные в БД, то обязательно как и говорилось фильтруйте данные через регулярные выражения, и используйте новые технологии к примеру PDO, делайте различные проверки, но самый мощный инструмент я бы сказал это регулярные выражения

Вроде здравая мысль про PDO в начале, но потом опять совершенно не к месту регулярки.

Сообщение от maxoun exec или shel_exec(), на Windows он у Вас не сработает

Почему?
А что делать если мне надо из php скрипта что-либо запустить?

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

Как можно выполнить что-либо предварительно не прочитав? Не будет права на чтение - не будет и возможности выполнения. А вот права на выполнение как раз не нужны, поскольку выполняемыми файлами *.php файлы не являются (за редким исключением).

Сообщение от maxoun ЛЮБОЕ ОБРАЩЕНИЕ К СИСТЕМЕ ЭТО ОПАСНО, А К ФАЙЛОВОЙ ВДВОЙНЕ

ЩИТО?

Сообщение от maxoun Если вы работаете с файлами не используйте file() readfile() fgets()

А как тогда с файлами работать?

Сообщение от maxoun взлоумышленник может туда внедрить js код и выполнить сценарий

Интересно как? Для php js код не имеет никакого особого смысла.

0

Сообщение от Jewbacabra А как тогда с файлами работать?

Добавлено через 29 секунд

Сообщение от Jewbacabra Регулярки не следует рассматривать как инструмент защиты

а можно поинтересоваться почему? )

0

Сообщение от andyyy а можно поинтересоваться почему? )

Потому что нет гарантии что сам шаблон безопасен. А даже если безопасен остается вероятность ошибки. А те же стейтменты из PDO гарантируют что при подстановке параметров структура запроса не поменяется.

0

господа, изучайте постгрес, помимо кучи плюшек в самой БД (jsonb, массивы, удобные ф-и и программирование процедур), конкретно в пхп у неё шикарные функции без всего этого mysqli/PDO -зоопарка
pg_query_params() сразу посылает параметризованный запрос на сервер, где параметры передаются отдельно от текста SQL запроса.
И всё! Там 2 строчки всего.

Что касается регулярок, они не спасут и от половины атак, а кроме того, как регулярить <textarea>

0

В общем, весь опус, из разряда советов "как лучше женщину попользовать стоя на красной площади".

Добавлено через 2 минуты

Сообщение от maxoun Хочу дать пару советов на счет Безопасности для новичков. Сам я не гуру в этом

"Устриц я не едал, но вкус осуждаю".

0

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

Права выставляются для пользователей системы. Например, есть пользователи в системе: First, Second (не ROOT).
Если они из разных групп и Second не должен иметь доступа к файлам First'а, выставляем: 640, например.

First может читать и записать, если нужно. Группа, в которой состоит First, может прочитать, а вот Second вообще не получит доступа.

К клиенту (посетителю сайта и его обозревателю) права доступа системы отношения никакого не имеют.

0

Сообщение от Jewbacabra Идет смешивание понятий валидация данных и экранирование. Регулярки не следует рассматривать как инструмент защиты

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

Сообщение от Jewbacabra Если вы работаете с файлами не используйте file() readfile() fgets()

Я же сказал через fgetss(), я не говорю что отказываться от них, из можно использовать но не для серьезных проектов.

Сообщение от Jewbacabra Интересно как? Для php js код не имеет никакого особого смысла.

PHP всего лишь интепритатор который передает только результат, так вот при выводе html тегов , а именно js, передастся и сам js, тоже самое xss,

0

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

Есть молоток. Им забивают гвозди. Есть отвертка - ей болт закручивают. Можно конечно сделать и наоборот, но выйдет так себе. Так и тут - для безопасность PDO со стейтментами, для валидации и простого парсинга регулярка

Сообщение от maxoun из можно использовать но не для серьезных проектов.

А люди то используют и не знают.

Сообщение от maxoun PHP всего лишь интепритатор который передает только результат, так вот при выводе html тегов , а именно js, передастся и сам js, тоже самое xss,

htmlentities, не?

0

Делайте для форм сериалайз и будет Вам счастье )

0

cardo, каким образом serialize поможет? Или неизвестный мне "сериалайз" -- это что-то другое?

0

Про шестой пункт о функциях file(), readfile(), fgets(), fgetss() как-то не поняль, поясните, пожалуйста.

В каком случае это нужно использовать? Ну вот, у нас может быть мультимедийный (картинка) или текстовый (различные js, css, обычный текст, html) файлы.
Когда файл мультимедийный (картинка) он и должен браузеру отдаваться с соответствующий Content-Type как мультимедийный, и здесь разве могут навредить нулевые байты и теги? По-моему картинка вполне может содержать внутри такую-же последовательность байтов как и любой тег, а при удалении может сломаться. Читать, например, функцией file_get_contents(), ну или любой другой функцией с подобным функционалом.
Если у нас js и css файлы, то туда в общем случае пользователю вообще соваться незачем, да и если есть зачем, то эти файлы должны попадать только автору, а там уж сам виноват. Если там обычный текст, то либо сразу хранить с преобразованном функцией htmlentities() виде, либо же преобразовывать сразу после прочтения (что по-моему даже предпочтительнее, ибо так сложнее допустить ошибку и пропустить отсутствие экранирования, хоть это и требует экранирования каждый раз против одного раза при создании файла). Если это сгенерированный html файл, то там нужно экранировать введённые пользователем данные ещё при создании файла, ибо иначе как определить, какие теги должны быть частью разметки, а какие пользователь сам повписывал для внедрения кода? Можно читать всё той же функцией file_get_contents().

0

Сообщение от полудух , как регулярить <textarea>

? как обычно наверное)

0

Сообщение от Jewbacabra htmlentities, не?

Но многие начинающие пользователи об этом не знают, они думают фильтровать данные должны только при передаче форм и все.

Сообщение от Jewbacabra А люди то используют и не знают.

Так вот моя цель была им это объяснить хотя бы так, а вы не поняли

Сообщение от Jewbacabra Есть молоток. Им забивают гвозди. Есть отвертка - ей болт закручивают. Можно конечно сделать и наоборот, но выйдет так себе. Так и тут - для безопасность PDO со стейтментами, для валидации и простого парсинга регулярка

При правильной оптимизации и защита не нужна, есть места где нужно использовать регулярные выражения, а есть места где не нужно его использовать, так вот отвечаю, передается логин и пароль. которые должны в себе содержать только 0-9a-zA-Z конечно легче здесь использовать регялрку, чем какие то 5-6 раз проверки, ты смелостью можешь довеять регуляркам, каждому свое где то он подходит,а где то нет

0

речь о том, что регулярки это поиск патернов, а не средство защиты, думаю Jewbacabra пытался донести до вас именно эту мысль.

При правильной оптимизации и защита не нужна, есть места где нужно использовать регулярные выражения, а есть места где не нужно его использовать, так вот отвечаю, передается логин и пароль. которые должны в себе содержать только 0-9a-zA-Z конечно легче здесь использовать регялрку, чем какие то 5-6 раз проверки, ты смелостью можешь довеять регуляркам, каждому свое где то он подходит,а где то нет

мммм, а если хэшировать логин с паролем, то и регулярка не нужна - может это оптимальней и правильней?)

1

maxoun, вы про регулярки то узнали только после того, как я вам показал пример
а теперь уже создаёте темы про безопасность, хотя и пользоваться то ими не умеете
Даже Я тут не создаю темы про безопасность, а "без года программист" уже эксперт.
почему вообще это читают "начинающие", как будто это действительно полезная для них тема

Добавлено через 2 минуты

Сообщение от spawnsnip мммм, а если хэшировать логин с паролем, то и регулярка не нужна - может это оптимальней и правильней?)

вообще-то логин иногда надо выводить где-нибудь, как тут, например: "Добро пожаловать, полудух"
в письме иногда указывается

0

Сообщение от полудух вообще-то логин иногда надо выводить где-нибудь, как тут, например: "Добро пожаловать, полудух" в письме иногда указывается

согласен, просто хотел показать, что не всё упирается в 1 решение, тем более в одно решение с использованием оптимальных и правлиных регулярок

0

0