| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Безопасность в PHP |
| Автор: m1kle 22.3.2008, 02:32 |
| Теоретически возможно ли взломать такой скрипт: $a=$_POST['a']; echo $a; |
| Автор: awers 22.3.2008, 03:12 |
| Теоретически даже <?php ?> можно взломать. Проверяй регулярными выражениями, приводи к типам. Вообще научись задавать правильно вопросы |
| Автор: m1kle 22.3.2008, 04:23 |
| awers, ты прав, вопросы формулирую я фигово. Переформулирую: Что нужно учесть при работе с переменными. На что нужно их проверять, в том числе при работе с базами данных. |
| Автор: Canarat 22.3.2008, 09:31 |
m1kle, зависит от того, что происходит с этой переменной.
Зависит от конкретной задачи. Сначала переменная приводится к типу, с которым работает приложение(например $var всегда int), а потом проверяется на возможное вхождение неправильных символов. Обычно, для всяких идентификаторов достаточно (int)$variable. |
| Автор: Feldmarschall 22.3.2008, 09:46 |
| Canarat, пункт два, вообще-то, если под словом "подключается" имеется в виду include, вообще не имеет смысла. В том плане, что если не должно быть РНР кода, то и подключать ничего не нужно. Пункт один лучше переформулировать по-другому. Ни за какими символами следить не надо. А надо выполнять два правила 1. Переданные скрипту данные оформлять в соответствии с синаксисом SQL 2. В случае, если динамически формируются управляющие конструкции запроса, то подставлять их только из заранее прописанных в скрипте. m1kle, вопрос все еще "фигово сформулирован", увы. "При работе с переменными" ничего учитывать не надо. Сами по себе переменные никакой угрозы не несут. В каждом конкретном случае защита осуществляется по-разному. Про SQL я уже написал. подробнее можно прочесть здесь http://phpfaq.ru/slashes если передается что-то, что будет использоваться в качестве имени файла, следует использовать регулярное выражение или функцию basename() |
| Автор: Canarat 22.3.2008, 14:00 | ||
| Feldmarschall, собственно про SQL, я все-таки склоняюсь к более абстрактному и общему взгляду на этот пункт. Неправильно сформулировал: Никакие посторонние данные не имеют возможности изменить вид SQL-запроса А насчет подключения, я лично правил скрипт где был подобный код:
и я не думаю, что это какой-то особый случай у начинающих PHP-программистов. |
| Автор: Sannis 22.3.2008, 14:18 | ||
Дык не только у них. Многие шаблонизаторы используют eval при генерации или подключении шаблонов, что от инклюда не сильно отличается. И по хорошему тоже нужно проверять, не вставил ли дизайнер в шаблон чего-то, что может привести к нежелательным последствиям. |
| Автор: Feldmarschall 22.3.2008, 14:24 |
| Sannis, по-хорошему, шаблонизатор не должан использоать eval. Canarat, "более абстрактный и общий взгляд" не дает никаких практических рекомендаций по защите, и даже намеков на них. И, следовательно - бесполезен. По поводу же приведенного кода, опять же - надо исправлять причину, а не следствие. то есть, бить по рукам тому, кто так пишет. |
| Автор: Canarat 22.3.2008, 14:32 |
| Feldmarschall, каюсь, я привел теорию, но не привел практику. От общего к частному, дедукция, Ватсон. А насчет этого кода - то что исправлять надо причину это очевидно, но когда есть код в приложении, для которого ты пишешь модуль - сильно не развернёшься. Ещё раз - существуют ситуации, когда напыщенность типа "я не буду работать с таким паттерном, ибо он не соответствует моим религиозным воззрениям" будет только вредить, и поэтому придется подстраиваться. |
| Автор: Feldmarschall 22.3.2008, 15:41 |
| ошибки надо не называть паттернами, а исправлять |
| Автор: Canarat 22.3.2008, 20:33 |
| Feldmarschall, если кому-то не нравится Singleton или Factory - их надо удалить? Здесь я подразумевал именно паттерны, и субъективное отношение к ним. |
| Автор: bars80080 24.3.2008, 10:21 | ||
а если мы, допустим закачиваем файлик (статью уже в готовом html-е), а затем подключаем её? |
| Автор: Feldmarschall 24.3.2008, 10:26 |
| Не понял смысла вопроса. Ты спрашиваешь, можно ли вывести в браузер файл, не используя оператор include? |
| Автор: bars80080 24.3.2008, 10:38 |
| нет, допустим контентщик составляет страничку у себя, потом её закачивает через <input type="file", а страничка затем инклудится. что-то типа ленты новостей, но более красочно (замена скриптам, типа fckeditor) по факту такая система существует, всё равно же надо проверять, здесь код php может быть введён напрямую без всяких ухищрений |
| Автор: Feldmarschall 24.3.2008, 10:43 |
| Я не погу понять. То ли ты думаешь, что include интерпретирует HTML код, то ли не знаешь о функции fopen или readfile |
| Автор: skyboy 24.3.2008, 14:47 | ||
такая система делается либо через шаблонизатор более высокого уровня(к примеру, Smarty). Переданные данные сохраняются, а потом вставляются в нужное место шаблона. Либо же через readfile и иже с ним, что побыстрее, но негибко с точки зрения контентщика(либо же программисту-создателю придется продумать кучу вариантов и предоставить контентщику кучу параметров). В любом случае, максимум, чем грозит такой подход - XSS и прочие проблемы безопасности на стороне клиента(связанные с опасностью для целосности дизайна и приватной информации конечного пользователя). PHP не инклюдится. да и в отношении HTML-кода и связанных с его использованием уязвимостей - существуют и применяются решения: 1. контентщик использует код, который контроллируемо транслируется в HTML(BBCode, к примеру). HTML-код преобразуется в сущности. 2. содержимое, которое будет вставляться, заранее разбито на блоки. контентщик вводит разные блоки без указания форматирования. затем при выдаче, разные блоки имеют разный дизайн. часто, кстати, используется при высокой формализации содержимого(например, объявления на доске, состоящие из заранее определенного количества полей). HTML-код преобразуется в сущности. 3. http://php.net/strip_tags gjpdjkzпозвказать список тегов, которые удаляться не будут. таким образом можно обработать HTML-текст, выбросив из него все, кроме <b> и <i>(к примеру). впрочем, способ тупой, потому как не удаляет аттрибуты у разрешенных тегов, потому в них(в атрибуты) вполне можно вставить javascript-код. упомянул только потому, что пару раз сам использовал и хотел бы предостеречь от такого варианта. |
