Безопасное программирование на PHP


Содержание

Делаем безопасные формы средствами PHP

Содержание

PHP и JavaScript — безопасные формы

Иногда нам приходиться писать различные модули для общения с посетителем сайта. Это может быть форум, гостевая книга или форма для отправки Email. Одной из основополагающей части этих программ являются поля для получения информации от пользователя, так называемые формы. Пользователь заполняет их и тем самым информация передается администраторам или всем посетителям, в зависимости от обработчика. Большинство людей не имеют зловредных целей, но порой попадаются пользователи с плохими намерениями. Они стремятся использовать вредоносные теги, спамить и флудить, администраторы же стремятся свести риск повреждения своей программы к нулю. Есть множество способов сделать это, я попробую рассказать лишь об основных. Все дело в Обработчике, именно он является главной частью нашей программы, в него поступают все сведения, и его задачей является отделить нужное от не нужного, полезное от без полезного. В данных примерах будет использоваться язык сетевого программирования PHP.

Пример

Начну по порядку. Для того, что бы ограничить вводимый текст в поле, нужно использовать такую конструкцию:

Теперь объясню, maxlength=10, означает, что максимальная длина этого поля составляет 10 символов и что попросту больше ввести нельзя. Но этот простой код еще не обеспечит полной защиты от бесконечно длинного и безобразного имени, которое выдумал пользователь. Необходимо употребить жесткую фильтрацию, путем вставки в обработчик примерно такой строчки:

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

В этой строчке мы видим, что htmlspecialchars() попросту убирает теги. Хм… А что если администратору хочется писать жирным или курсивом? Ответ прост:

Мы заменим привычный нам тег на [b] [/b]. То есть мы будем писать в сообщении вместо обычных тегов, новые. Обработчик будет отслеживать новые и менять на старые =). Кстати, с помощью str_replace можно заменять смайлики вида «=)» на картинку:

Рекомендуется тег вообще заменять на автоматически, из-за HTML5.

Самостоятельные шаги

Немного отвлеклись. Всегда нужно быть осторожными и продумывать шаги. Поля такие как: имя, город, Email и так далее, являются однострочными, следовательно, переход на новую строку должен пресекаться.

Знак \n — означает переход на новую строку, он заменяется на пробел. Для того, что бы проверить, что переход на новую строку состоит из двух символов, создайте пустой текстовый файл и просто стукните enter. Вы перейдете на новую строку. Не делая никаких изменений после, просто закройте редактор, предварительно сохранившись. Посмотрите свойства только что созданного файла. Объем будет составлять два байта, то есть два символа.

Следующей проблемой, являются незаполненные поля, а что если они очень важны? Заполнение формы будет напрасным. Выход вот:

Приравниваем значение переменной $name к нулю, если это так, то символов нет значит, поле пустое, информируем посетителя об этом и прекращаем выполнение последующих шагов. Так же можно попробовать вот это:

Смысл один и тот же у последних двух примеров, только разве что информационное сообщение другое =). Многие пользователи так и норовят по натыкать везде непонятных закорючек — &^*] [. Если к тому же мы используем MySQL то такой язык пользователя может привести к ошибке. Лекарство:

Но учтите, что нужно разрешить использование «собаки» при вводе в поле Email, иначе получиться не вполне корректно:

Заключение

Такого рода фильтры (два последних) не используйте для ограничения ввода в текстовом поле, на пример сообщение в гостевой книге.

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

В этой статье я описал основные способы избежать проблемной ситуации при использовании форм и обработчика написанного на PHP. Думаю, эти фильтры вам очень помогут.

Дополнительная информация по теме

Все о программировании форм на PHP — защита, теоретические основы Download и реальные примеры

Статья рассказывает о все растущей популярности кошек на всех социальных сайтах и ресурсах с медиа-контентом

Здесь рассказывается о самых популярных паролях пользователей на примере взломанной базы пользователей Adobe

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

БЕЗОПАСНОСТЬ WEB-ПРИЛОЖЕНИЙ НА PHP

студент, факультет информатики Самарский национальный исследовательский университет,

студент, факультет информатики Самарский национальный исследовательский университет,

студент, факультет информатики Самарский национальный исследовательский университет,

студент, факультет информатики Самарский национальный исследовательский университет,

Безопасность веб-приложений — один из наиболее острых вопросов в информационной безопасности. Как правило большинство веб-сайтов, доступных в Интернете, имеют различного рода уязвимости и постоянно подвергаются атакам. В данной статье мы покажем некоторые используемые приемы для защиты веб-приложений на языке PHP.

Валидация входящих данных

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

Необходимо всегда проверять и фильтровать входящие данные в PHP скриптах. Если для валидации данных используется JavaScript, то в любой момент злоумышленник может отключить его в своём браузере. В таком случае приложение находится в опасности, поэтому необходимо перепроверять данные в PHP скриптах.

Защита от XSS атак

Межсайтовый скриптинг (Cross Site Scripting — XSS) позволяет злоумышленнику включать свой HTML код в вашу станицу. Наиболее уязвимы для такого вида атак являются приложения, где происходит динамическое формирование страниц. Суть атаки — выйти за пределы HTML тега, через специальные символы, и далее внедрять свой код. Защита от этого вида атак сводится к фильтрованию данных отосланных пользователем.

Рассмотрим код уязвимой станицы, отображенный на рисунке 1:

Рисунок 1. Форма ввода, подверженная атакам XSS

Злоумышленнику достаточно сформировать URL следующего вида:

и страница будет уже содержать следующий код:

Рисунок 2. Демонстрация уязвимости

Данный код не причиняет вреда, а лишь демонстрирует уязвимость XSS, отображая cookie. Следует помнить, что код может быть другим, более опасным.

Чтобы обезопасить себя от такого вида атак, следует отфильтровать значение, передаваемое через параметр username, например, при помощи регулярных выражений:

Рисунок 3. Проверка данных с помощью регулярного выражения

Следует проверять все переменные получаемые от пользователя — GET, POST, COOKIE. Во все из них без труда можно встроить зловредный код. Особое внимание следует уделять паролям, так как в них не принято вводить ограничения на символы.

PHP обладает несколькими функциями, позволяющими значительно облегчить задачу защиты web-приложений. Одной из таких функций является htmlspecialchars() которая гарантирует, что любой введенный пользователем код (php, javascript и т.д.) будет отображен, но выполняться не будет.

Защита от CSRF атак

Следующий вид атаки, который мы рассмотрим, это CSRF атака или подделка межсайтовых запросов. Атакующий использует различные трюки для получения конфиденциальной информации или совершения сделки без ведома жертвы. В основном это происходит на плохо защищённых сайтах, где бизнес логика строится на работе GET запросов.

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

В качестве предотвращения подобного рода атак, используйте только POST запросы к процессам, предназначенным для изменения информации в базе данных. Не используйте $_REQUEST. Пользуйтесь $_GET-ом для обработки GET параметров, и $_POST для извлечения POST параметров.


В качестве дополнительных мер можно сгенерировать какой-то уникальный токен и прикреплять его к каждому POST запросу. При входе пользователя в систему, можно генерировать случайный токен и записывать его в сессию. Поскольку все формы выводятся пользователю, данный токен нужно записывать в скрытое поле. В бизнес логике приложения должен быть предусмотрен функционал, который будет проверять токен из форм и токен, хранящийся в сессии.

Предотвращение SQL инъекций

SQL-инъекции — абсолютно другой вид атаки и он наиболее опасен. В Web-приложения, где есть данного вида уязвимость, злоумышленник может внедрить свой SQL код, что может провести к потери информации, краже или полному уничтожению базы данных.

Для выполнения запросов к базе данных следует использовать PDO. Благодаря параметризированным запросам и подготовленным выражениям, вы можете свести на нет угрозу SQL инъекций.

Давайте рассмотрим следующий пример:

Рисунок 4. Проверка данных с помощью PDO

В коде, представленном выше, мы отправляем запрос в метод prepare(), включая именные параметры: :name и :age. Таким образом, запрос пре-компилируется для дальнейшей подстановки данных. При вызове метода execute(), запрос полностью формируется и выполняется. Если вы пользуетесь подобной техникой, то все попытки злоумышленника осуществить SQL инъекцию будут сведены к нулю.

Обработка ошибок

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

На публичном сервере вам необходимо отключить такие опции, как display_errors и display_start_up_errors, а вот такие опции как error_reporting и log_errors, должны быть активны, чтоб все ошибки, возникшие у пользователей, записывались в логи.

Также вы можете использовать “set_error_handler” для определения своего собственного обработчика ошибок. Однако тут могут возникнуть ограничения, ведь собственный обработчик уступает родному PHP механизму. Ошибки E_CORE_ERROR, E_STRICT или E_COMPILER_ERROR не смогут быть отловлены в том же файле, где и определённый обработчик. Более того, ошибки, которые могут возникнуть в самом обработчике также не смогут быть отловлены.

Для более элегантного способа отлавливания исключений, потенциально опасный код нужно помещать в блок try/catch. Все собственные исключения должны быть объектами классов или подклассов Exception. Если исключения и были выброшены, то в блоке try/catch их можно обработать.

Защита подключаемых файлов

Часто в PHP скриптах происходит подгрузка других файлов, таких как подключение к базе и многих других. Некоторые разработчики дают таким файлам расширение .inc. Такие файлы по умолчанию PHP не парсит. Если обратиться к ним по адресу напрямую, пользователь сможет увидеть текст данного файла. Если же хакеру удастся получить доступ к файлу хранящиму данные подключение к базе, то в последствии он может получить доступ ко всем данным вашего приложения. Так что всегда используйте расширение .php для подгружаемых файлов и храните их там, куда нет прямого пользовательского доступа.

Безопасность

Во всем мире в аэропортах можно найти лозунг «Security is not a joking matter» (Безопасность — прежде всего). Такой же лозунг каждый системный администратор должен был бы закрепить рядом со своим сервером PHP. А любой, кто подключается к серверу, находящемуся в Интернете, должен принимать надлежащие меры защиты или рисковать потерей данных и даже денег из-за того, что злонамеренные взломщики программного обеспечения сумеют нанести ущерб, пользуясь клавиатурой своего компьютера.

Разработчик сайта, озабоченный проблемами защиты, обязан постоянно повторять: «Не доверяйте сети». Если вы беспокоитесь о защите своего сайта, повторяйте это высказывание, разрабатывая код будущих страниц сайта. Любая информация, передаваемая на сервер по сети (будь то URL, данные из формы HTML или данные, поступающие через какой-то другой сетевой порт), должна рассматриваться как потенциально опасная. В настоящей статье предложено несколько методов, позволяющих обезопасить поступающую информацию. Необходимо не только применять эти методы, но и уделять определенное время для того, чтобы обнаружить другие потенциальные опасности и найти способы их предотвращения.

Вторым эмпирическим правилом создания защищенного сайта является следующее: «Минимизируйте ущерб». Что будет, если написанная вами программа, которая, по вашему мнению, является вполне надежной, фактически окажется уязвимой? Даже просто для того, чтобы оставаться в полной безопасности, ограничивайте ущерб, который мог бы нанести нарушитель, воспользовавшись этой уязвимостью.

Когда на ваш сайт приходят посетители, они надеются, что сайт содержит действительную информацию, которая не нанесет вреда ни им, ни компьютерам, и что предоставленная ими информация будет обрабатываться должным образом. Для посетителя всегда имеется определенный риск нарушения защиты при взаимодействии с любым сайтом, независимо от того, развлекательный ли это сайт, информационный или электронной коммерции. Обязанности по защите посетителей от таких рисков возложены на проектировщика сайта. Это означает, что вы обязаны не только надежно хранить на своем сервере информацию, предоставленную посетителями, но и принять меры по защите предоставляемой информации во время ее передачи с компьютеров посетителей на ваш сервер.

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

Возможные нападения

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

Обычно хакерами называют тех, кого было бы правильнее назвать взломщиками программной защиты. В компьютерном сообществе взломщиками защиты называют специалистов, которые, пользуясь удачным стечением обстоятельств или своими навыками, преодолевают защиту компьютерных систем и наносят ущерб. А хакеры — это программисты, умеющие виртуозно составлять программы и способные не только разбираться в сложном коде, но и самостоятельно писать эффективный (и часто недоступный для понимания посторонних) код на многих языках. Для программиста приобретение звания хакера является честью, а звание взломщика программного обеспечения, по-видимому, означает, что его владелец должен следить за заметками в рубрике «Разыскивается».

Не понимая того, насколько унизительным является звание взломщика программного обеспечения, многие начинающие программисты вступают на эту стезю, прибегая к использованию инструментальных средств и сценариев, которые они находят в веб. Таких начинающих взломщиков называют script-kiddie или по нашему кулхацкерами. Эти люди часто сами почти не понимают, что они делают. Обычно именно такая категория нарушителей стоит за примитивными атаками, такими как компрометация сайта, XSS и SQL-инъекции.

Компрометация сайта и атаки XSS

Случаи компрометации сайта, которые чаще бывают в большей степени неприятными, чем действительно вредными, довольно распространены, поскольку многие сайты открывают для взломщика программной защиты возможность объявить всему миру о том, что он сумел добиться своей цели. Для компрометации неправильно спроектированного веб-сайта иногда достаточно воспользоваться одним лишь веб-браузером. Рассмотрим, например, следующую программу:

Страница с простой формой добавления комментариев

Эта программа реализует систему комментариев в очень примитивной форме (если вы изучаете мое руководство по PHP с начала, то возможно вы еще не знакомы с операциями работы с базами данных; если это так, то рекомендую вам вернуться к этой статье после ознакомления с соответствующим материалом по MySQL).

Читая этот код, опытный программист начинает чувствовать себя не совсем уверенно (помните — «Не доверяйте сети»). Такая программа принимает данные формы, которые, согласно ожиданиям, должны содержать текст комментария. Этот текст присваивается переменной $comment и сохраняется в базе данных для отображения перед следующими посетителями. Если введенные данные будут такими, какие мы ожидаем, то проблемы не возникнут.

А теперь поставьте себя на мгновение на место кулхацкера и представьте, что произойдет, если во входных данных будут содержаться дескрипторы HTML. Эта простая программа механически вставит такие дескрипторы в формируемую страницу, и эта искаженная страница будет разворачиваться в браузерах других посетителей вместо обычной. Одним из дескрипторов, которые могут оказаться особенно опасными с точки зрения защиты данных, является дескриптор

Илон Маск рекомендует:  Что такое код asp logextfileserverip

Безопасное программирование веб-приложений

Данная статья не претендует на роль всеобъемлющего руководства на тему «как сделать так, чтоб меня никто не поломал». Так не бывает. Единственная цель этой статьи — показать некоторые используемые мной приемы для защиты веб-приложений типа WWW-чатов, гостевых книг, веб-форумов и других приложений подобного рода. Итак, давайте рассмотрим некоторые приемы программирования на примере некоей гостевой книги, написанной на PHP.

Первой заповедью веб-программиста, желающего написать более-менее защищенное веб-приложение, должно стать «Никогда не верь данным, присылаемым тебе пользователем». Пользователи — это по определению такие злобные хакеры, которые только и ищут момента, как бы напихать в формы ввода всякую дрянь типа PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому подобных ужасных вещей. Поэтому первое, что необходимо сделать — это жесточайшим образом отфильтровать все данные, присланные пользователем.
Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде:

На роль настоящей защиты, конечно, это претендовать не может — единственное назначение этого элемента — ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:

Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут — то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного — а береженого Бог бережет.

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

Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака «_» (подчерк), пробела и цифр:

Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие паттерна в строке или поменять один паттерн на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi() . Я не буду приводить здесь эти примеры — это достаточно подробно описано в мануале.

Для поля ввода адреса e-mail добавим в список разрешенных символов знаки «@» и «.», иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:

Поле ввода текста мы не будем подвергать таким жестким репрессиям — перебирать все знаки препинания, которые можно использовать, попросту лень, поэтому ограничимся использованием функций nl2br() и htmlspecialchars() — это не даст врагу понатыкать в текст сообщения html-тегов. Некоторые разработчики, наверное, скажут: «а мы все-таки очень хотим, чтобы пользователи _могли_ вставлять теги». Если сильно неймется — можно сделать некие тегозаменители, типа «текст, окруженный звездочками, будет высвечен bold‘ом.». Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов — от тривиального до супернавороченного .

Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Учитывая еще пару особенностей строения чата, через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент на чате пользователей. Как? Да очень просто — чату был послан тег , в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей, сидевших под lynx’ом :-) ). А скрипт, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения — в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя. С вышеупомянутым результатом.
Посему мое мнение — да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах — это красиво, но игра не стоит свеч — вряд ли пользователи пойдут к Вам на книгу или в чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP — возможности javascript’a я перечислять не буду :-)

Для примитивной гостевой книги перечисленных средств хватит, чтобы сделать ее более-менее сложной для взлома. Однако для удобства, книги обычно содержат некоторые возможности для модерирования — как минимум, возможность удаления сообщений. Разрешенную, естественно, узкому (или не очень) кругу лиц. Посмотрим, что можно сделать здесь.

Допустим, вся система модерирования книги также состоит из двух частей — страницы со списком сообщений, где можно отмечать подлежащие удалению сообщения, и непосредственно скрипта, удаляющего сообщения. Назовем их соответственно admin1.php и admin2.php.

Простейший и надежнейший способ аутентикации пользователя — размещение скриптов в директории, защищенной файлом .htaccess. Для преодоления такой защиты нужно уже не приложение ломать, а web-сервер. Что несколько сложнее и уж, во всяком случае, не укладывается в рамки темы этой статьи. Однако не всегда этот способ пригоден к употреблению — иногда бывает надо проводить авторизацию средствами самого приложения.

Первый, самый простой способ — авторизация средствами HTTP — через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm’а логин и пароль, и только в случае неудачи потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах:

Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и PHP_AUTH_PW , в которых соответственно будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе:

*** Внимание. ***
В приведенном ниже фрагменте кода сознательно допущена серьезная ошибка в безопасности. Попытайтесь найти ее самостоятельно.
Упомянутая ошибка, между прочим, очень распространена среди начинающих и невнимательных программистов. Когда-то я сам поймался на эту удочку — по счастью, особого вреда это не принесло, не считая оставленных хакером в новостной ленте нескольких нецензурных фраз.
Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password() , так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге — $password == $rpassword , условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь — вставкой следующего фрагмента кода: То есть — проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше.
Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек — то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет — браузер втихомолку передаст пароль. Если же нет — ну, тогда и поругаться не грех. Скажем, вывести ту же фразу «hacker? he-he. «.

К сожалению, не всегда удается воспользоваться алгоритмом авторизации через код 401 и приходится выполнять ее только средствами приложения. В общем случае модель такой авторизации будет следующей:

  • Пользователь один раз авторизуется при помощи веб-формы и скрипта, который проверяет правильность имени и пароля.
  • Остальные скрипты защищенной части приложения каким-нибудь образом проверяют факт авторизованности пользователя.

Такая модель называется сессионной — после прохождения авторизации открывается так называемая «сессия», в течение которой пользователь имеет доступ к защищенной части системы. Сессия закрылась — доступ закрывается. На этом принципе, в частности, строится большинство www-чатов: пользователь может получить доступ к чату только после того, как пройдет процедуру входа. Основная сложность данной схемы заключается в том, что все скрипты защищенной части приложения каким-то образом должны знать о том, что пользователь, посылающий данные, успешно авторизовался.
Рассмотрим несколько вариантов, как это можно сделать:

  1. После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться — я сам такое видел).
    Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того — нет возможности отличить одного пользователя от другого.
  2. Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах — для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER — но, как я уже говорил, никаких гарантий она не дает.
  3. Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть — значит, авторизация была, если нет — «hacker? he-he. » :-)
    Это более надежный способ — не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad’инга — это вполне реально.
  4. Единственным, известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid. Рассмотрим ее более подробно.

После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число: Это число он:
а) заносит в локальный список авторизовавшихся пользователей;
б) Выдает пользователю.

Пользователь при каждом запросе, помимо другой информации (сообщение в чате, или список сообщений в гостевой книге), отправляет серверу свой uid. При этом в документе с формами ввода будет присутствовать, наряду с другими формами, тег вида: Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid’ом, хранящимся в локальной базе и либо выполняет свою функцию, либо. «hacker? he-he. «.


Единственное, что необходимо сделать при такой организации — периодически чистить локальный список uid’ов и/или сделать для пользователя кнопку «выход», при нажатии на которую локальный uid пользователя сотрется из базы на сервере — сессия закрыта.

Некоторые программисты используют в качестве uid не «одноразовое» динамически генерирующееся число, а пароль пользователя. Это допустимо, но это является «дурным тоном», поскольку пароль пользователя обычно не меняется от сессии к сессии, а значит — хакер сможет сам открывать сессии. Та же самая модель может быть использована везде, где требуется идентификация пользователя — в чатах, веб-конференциях, электронных магазинах.

В заключение стоит упомянуть и о такой полезной вещи, как ведение логов. Если в каждую из описанных процедур встроить возможность занесения события в лог-файл с указанием IP-адреса потенциального злоумышленника — то в случае реальной атаки вычислить хакера будет гораздо проще, поскольку хакеры обычно пробуют последовательно усложняющиеся атаки. Для определения IP-адреса желательно использовать не только стандартную переменную REMOTE_ADDR, но и менее известную HTTP_X_FORWARDED_FOR, которая позволяет определить IP пользователя, находящегося за прокси-сервером. Естественно — если прокси это позволяет.
При ведении лог-файлов, необходимо помнить, что доступ к ним должен быть только у Вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности — создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all).

. Alexey пишет 25.01.2001 @ 09:08

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

. Scarab пишет 05.03.2001 @ 12:25

По поводу cookies могу сказать следующее. Сам я эту технологию маленько недолюбливаю, как минимум — потому что подавляющее большинство пользователей сидят под вендозе, а я не доверяю ничему, что касается вендозе.
В некоторых частных случаях, зависит от проекта в целом, она может применяться, в целом я бы не стал на нее расчитывать.
Я помню, как сравнительно недавно меня, как системного администратора, вызывает в интернет-зал тамошний оператор. Прихожу, и вижу следующее: пользователь не может зайти на mail.ru. То есть — он набирает www.mail.ru, и попадает в чужой ящик. Видимо, того человека, который сидел на этой машине и не разрегистрировался. Перезапуск браузера ничего не дал, пока ручками не полез в cookies.txt и не поубивал там все — так оно и не работало.
Я никоим образом не дискредитирую mail.ru, скорее всего — это была просто ошибка самого пользователя. Но факт есть факт.
Вывод — пока cookies общие, пока они не хранятся у каждого пользователя в homedir, как в юниксовых системах — существует вероятность использования сессии пользователя A пользователем B. Да, путем различных ухищрений типа выставления тайм-аутов можно свести эту вероятность к минимуму — но факт есть факт.
UID — можно передавать и в строке GET. Я обычно делаю именно так.
Но хранить его в cooikes? А если браузер возьми и не сотри по истечении срока? А я от експлодера и не такого могу ожидать :-)
Поэтому мое мнение — иногда можно, даже без особых потерь в секурности, но я так не делаю.
Конкретнее — когда можно, когда нет — надо смотреть проект целиком.

. =KRoN= пишет 19.03.2001 @ 17:55

Оффтопик, но по поводу cookies и mail.ru
Есть более серьёзный у них глюк — у нас несколько фирм ходит через один корпоративный proxy. Так вот, однажды у меня на ICQ всплывает некая девушка и рассказывает, что она регулярно попадает в мой почтовый ящик на mail.ru. После недолгих разбирательств выяснилось, что она работает в нашем здании, ходит через тот же прокси (squid/FreeBSD). Видно где-то там и кешировались куки. Вылечилось переходом с mail.ru на beep.ru (в службе поддержки mail.ru фактически послали, сказав, что это наша проблема)

. Alex пишет 26.03.2001 @ 23:27
. Alexander пишет 06.04.2001 @ 22:56
. MaxVT пишет 13.04.2001 @ 08:46
. Shadow пишет 01.06.2001 @ 07:16
. Надя пишет 04.06.2001 @ 08:54
. Xenomorph пишет 17.06.2001 @ 09:50
. Олег пишет 08.07.2001 @ 01:52
. piroman пишет 16.02.2002 @ 15:01

Спецально для таких ламеров как я. Правильный код проверку переменной окружения web-сервера HTTP-REFERER:

. USE пишет 12.02.2003 @ 13:37
. DanchouS пишет 18.05.2003 @ 16:20
. пишет 18.05.2003 @ 17:30

У меня вот такой вопросик:
Почему у меня не работает вот эта часть скрипта?

if (mysql_numrows($result) != 1) <
Header(«HTTP/1.0 401 Auth Required»);
Header(«WWW-authenticate: basic realm=’My Realm'»);
exit;
>

пишет вот такую вигню!

Warning: Cannot add header information — headers already sent by (output started at . \index.php:24) in . \admin.php on line 44

. Lizardus пишет 20.07.2003 @ 12:32

>. пишет 18.05.2003 @ 17:30
>Почему у меня не работает вот эта часть скрипта?

До этой части скрипта ты выводил клиенту данные в скрипте admin.php в строке 44. И PHP понял, что заголовки ты отправлясть больше не намерен, поэтому успел отправить http-заголовок и дополнений к нему не принимает.

. SooS пишет 02.08.2003 @ 20:28

>Почему у меня не работает вот эта часть скрипта?
Объясняю более популярно, ты его в тексте повыше подними ;)

А всё-таки с сессиями по моему надёжне, Через сессии я лайвтаим им реализую в 20 минут и всё ок

. Satan Klaus пишет 07.04.2004 @ 03:24
. пишет 18.04.2004 @ 11:36
. антигерой пишет 12.07.2004 @ 09:39

>Почему у меня не работает вот эта часть скрипта?
>if (mysql_numrows($result) != 1) <
>Header(«HTTP/1.0 401 Auth Required»);
>Header(«WWW-authenticate: basic realm=’My Realm'»);
>exit;>
>пишет вот такую вигню!
>Warning: Cannot add header information — headers already sent by (output started at . \index.php:24) >in . \admin.php on line 44

Это должно быть до отправки тела BODY. Ставь в самом начале скрипта и проблем не будет. В САМОМ — САМОМ начале. Пусть эти функции вызываются первыми. Такая-же ошибка будет с куками. Они должны ставиться тоже в начале, до отправки самого кода странички юзеру.

Могу ещё предложить не писать строку (mailto:) , а сделать через скрипт:

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

обязателен, иначе это будет всё чёрт знает куда пихаться.

Тогда уродские роботы уродов спамеров не найдут в коде вашей странички eMail и обломаются. Спам приходить не будет, если сами своё мыло не просохатите где-нибудь в другом месте.

Также можно написать простенький скрипт по ссылочке, который будет генерить для тех-же роботов поток рандомных eMail`ов и ткнуть небольшую задержку в виде sleep(0,1) Если вам траффик критичен.

IntSystem.org

Случаи из опыта разработки различных WEB проектов. Интересные факты, статьи, впечатления. Программирование и все о нем в сфере WEB.

Концепт защиты PHP сайта

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

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

Хорошо, или допустим вы из тех кто считает что безопасность и правильная настройка сервера лишней не бывает? Если так то добро пожаловать под кат.

Нет, в статье вы не найдете какой-то супер пупер плагин, фильтрующий все данные, который нужно приинклудить ко всем файлам. Моя идея заключается в использовании директивы auto_prepend_file и постройки списка разрешенных файлов… Но в общем читайте сами…

Данная идея у меня давно сидела в голове, но наконец у меня дошли руки, хоть ничего сложного тут и нету, и я смог эту систему реализовать и написать статью =)

Принцип работы

Как я уже говорил выше, система основанна на работе директивы auto_prepend_file в php.ini. Отвечает она за установку скрипта, который будет выполнятся ПЕРЕД выполнением основного.


К примеру вы открыли index.php, а перед его выполнением запускается файл, указанный в auto_prepend_file. Суть в том, что в этом скрипте мы сможем контролировать дальнейшую работу остальных скриптов. Грубо говоря, продолжить работу и запустить запрошенный скрипт, или завершиться сразу (die()).

К примеру ситуация — злоумышленник залил на ваш сайт шелл через какую нибудь уязвимость и пытается его открыть в браузере. А вместо его шелла, ему, без всяких на то причин, отдается, вот такая вот ошибка:

Меня бы подобное ввело бы в ступор…

Для работы мой системы, нужен список разрешенных файлов, доступ к файлам, отсутствующим же в этом списке будет блокироваться.

(Не знаю нужна ли эта диаграмма, вроде бы и так все должно быть понятно…)

Конечно составлять такой список вручную — дело не благородное, поэтому я пришел к выводу, что имеет смысл реализовать так называемый «режим обучения». Режим в котором все обращения ко всем скриптам будут заносится в список разрешенных файлов автоматически.

Что это дает? Вы можете запустить эту систему в режиме обучения и продолжить пользоваться своим сайтом. По мере того как вы будете им пользоваться, ваша база будет пополнятся теми страницами, которыми вы пользуетесь (простите за каламбур). И допустим через месяц — другой у вас в списке будут содержаться все файлы которые имеют отношение к вашему сайту (к которым вы непосредственно обращались).

Причем заметьте, в списке будут содержаться только те файлы, с которыми вы непосредственно будете работать. Обычный среднестатистический движок сайта имеет кучу подключаемых файлов (с классами, с функциями, библиотеки, модули и прочее), эти файлы в этот список не попадут, и доступ к ним в дальнейшем будет блокироваться на уровне нашей защиты (конечно среднестатистические движки имеют защиту от прямого запуска, но вдруг гдето эта защита пропущенна).

Что умеем

Так как это концепт, то и умеем мы не много.

  • Блокирование неразрешенных скриптов (собственно основная функция). Но опять же это настраиваемо, можно не блокировать соединение, а только лишь уведомлять админа по email
  • Уведомление о нелегитимных запросах администратору по email (краткий отчет или полный отчет, последний включает заголовки пакета и данные POST запроса если таковые имеются)
  • Можно указать IP администратора, который будет иметь доступ к любым скриптам, т.е. данная система его затрагивать не будет (эти IP не будут участвовать в режиме обучения). К примеру теперь не надо закрывать .htaccess-ом софтины типа PhpMyAdmin, SupexDumper и прочие системные утилиты.
  • Ксати Ip адреса поддерживают простенькие маски=)
  • Полностью прокомментированный код, и подробно описанна каждая директива конфигурации
  • Хз что еще…

Настройка

Теперь о том как встроить эту защиту в ваш сайт…

Для этого вам необходим доступ к файлу php.ini

  1. Для начала скачиваем сам скрипт: PrependSecuritySystem
  2. Распаковываем содержимое архива (data.txt и main.php) в какую либо папку на сервере, желательно в папку не доступную из веба (не обязательно, т.к. работать будет в любой, это имеет смысл чтобы убрать скрипт подальше от глаз взломщика)
  3. Открываем файл main.php и редактируем настройки. Необходимо обязательно поменять ip адрес и email админа. Остальные настройки же — по вашему желанию.
  4. Устанавливаем права доступа к распакованным файлам. Под никсами желательно изменить владельца для обоих файлов, отличного от пользователя из под которого работает веб сервер. Для файла main.php необходимо запретить запись для всех. Для файла data.txt необходимо установить права на чтение и на запись для всех (это временно, на период обучения)
  5. Открываем php.ini и вписываем следующее:
    auto_prepend_file=[путь до распакованного файла main.php]
  6. С данного момента начинается обучение системы. Выжидаем определенное колличество времени, достаточное, по вашему мнению, для полного обучения данной системы.
  7. По окончанию обучения открываем файл main.php и редактируем костанту PSS_STATUS_BLOCK, устанавливаем ее значение в true, сохраняем
  8. Изменяем права доступа на файл data.txt. Запрещаем редактирование данного файла для всех.
  9. Теперь система перешла в режим блокирования неразрешенных скриптов

Многовато шагов, конечно, но с этим, как мне кажется, справится даже ребенок.

Если вам необходимо переобучить систему (с нуля или дополнить), то вам необходимо:

  1. Разрешить запись в файл data.txt
  2. Очистить содержимое data.txt (ТОЛЬКО если вам необходимо переобучить систему с нуля)
  3. Отредактировать костанту PSS_STATUS_BLOCK в файле main.php, установив ее значение в false
  4. Проводим переобучение…
  5. По окончанию переобучения редактируем константу PSS_STATUS_BLOCK устанавливая ее значение обратно в true
  6. Запрещаем запись файла data.txt

Ну а теперь о грустном

Лукавить я не буду, и теперь расскажу о недостатках.

  • Пожалуй главный недостаток по сравнению с которым меркнут все остальные, это то, что эту систему можно обойти. Вы спросите: как же так? Все очень просто, директиву auto_prepend_file можно указать и в .htaccess. И если подойти трезво то если злоумышленник вдруг смог залить шелл, то наверняка он сможет залить и свой .htaccess в котором он может отключить оригинальную директиву.
    Это работает только под apache, но к примеру под nginx этот трюк не выйдет (у nginx нет файлов .htaccess). НО! Под Nginx можно вообще залить свой php.ini в любую папку и в этой папке будут действовать новые директивы.
  • Злоумышленник может отредактировать «разрешенный» скрипт если есть допустимые права на это, и с этим наша система ничего, к сожалению, сделать не сможет. Разве что необходимо устанавливать правильные права на все исполнемые файлы
  • Помимо PHP есть еще всякие perl, cgi и прочее… с ними данная система не работает.
  • Дополнительная нагрузка. Но вртяли эта нагрузка будет ощутима.

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

Заключение

Все же, так или иначе, это концепт, может быть вы сможете придумать на ее основе что то лучшее. А может быть вас устроит моя система.

На мой взгляд разумной защиты много не бывает. Использовать что-либо подобное или нет, у вас на сайтах решать вам.

Фуф. Ну и написал я, почти целый день ушел. Простите если описал несколько сумбурно. В общем задавайте ваши вопросы в комментариях, я постараюсь ответить.

PS: хоть я и кодил максимально адекватно, скрипт может иметь баги. Тестировалось на win/apache/php 5.2 — все было ок.

Безопасность в PHP — проверяем типы переменных

Известно, что PHP относится к слабо типизированным языкам программирования. Что же это значит? Мы можем проводить различные операции между переменными разного типа, и получать «что-то» на выходе. С одной стороны, это удобно. Строка превращается в целое число, целое число может стать объектом, а объект плавно перейти в массив.

Но любой программист при создании сайтов на языке php рано или поздно сталкивается с тем, что во многих случаях типы переменных следует приводить (или, как минимум, проверять перед началом использования).

Такое строгое отношение к переменным связано с тем, что большинство скриптов на php подвержено нездоровому вниманию злоумышленников с целью подстановки параметров различного типа в строке запроса сайта. Это может привести от генерации ошибки с раскрытием пути, по которому находится файл, вплоть до обхода некоторых ограничений.

Повышения прав пользователя в ранних версиях WordPress путём передачи имени пользователя как массива, а не строки, в скрипт аутентификации в admin панели, или же подстановки в строку запроса вместо целых чисел (например, id новости) – специально сформированных запросов sql с целью несанкционированного доступа, создание на сайте так называемых sql инъекций.

Так что, по возможности, проверяйте типы переменных перед их использованием или явно приводите их во время программирования на PHP. Приведём функции, которые будут нам полезны с целью контроля безопасности входных данных:

  • (string) trim($str)Принимаемые параметры: $var – строка для удаления пробельных символов и символов разрыва строки. Обрезает символы конца строки и пробельные символы вначале и в конце строки, возвращает переменную строкового типа.
  • (bool) is_string($var)Принимаемые параметры: $var – переменная для проверки. Является ли переменная $var строкой? Возвращает: true: если является, false: если не является.
  • (bool) is_numeric($var)Принимаемые параметры: $var – переменная для проверки. Является ли переменная $var набором цифр ? Возвращает: true: если является, false: если не является.
  • (bool) is_float($var)Принимаемые параметры: $var – переменная для проверки. Является ли переменная $var вещественным числом? Возвращает: true: если является, false: если не является.
  • (bool) is_array($var)Принимаемые параметры: $var – переменная для проверки. Является ли переменная $var массивом? Возвращает: true: если является, false: если не является.
  • (bool) is_int($var)Принимаемые параметры: $var – переменная для проверки. Является ли переменная $var целым числом? Возвращает: true: если является, false: если не является.
  • (bool) isset($var)Принимаемые параметры: $var – переменная для проверки. Проверяет, существует ли переменная $var (любой тип данных), если существует, возвращает true, иначе возвращает false.
  • (bool) is_resource($var)Принимаемые параметры: $var – переменная для проверки. Является ли переменная $var ресурсом? Возвращает: true: если является, false: если не является.
  • (bool) empty($var)Принимаемые параметры: $var – переменная для проверки. Проверяет, пуста ли существующая переменная или нет, возвращаемые значения: true для значений (“”, 0, 0.0, “0”, NULL,FALSE,array()), false в остальных случаях.

Пример использования при программировании в PHP скриптах. Передаем в форму через пост запрос массив данных $user, полученный при регистрации пользователя:

Еще один пример использования в PHP скриптах. Зададим вопрос к базе данных:

Дело в том, что очень полезно проверять, является ли параметр ресурсом, перед передачей функции, заведомо требующей параметр типа ресурс. Например, в случае sql запросов такой подход может подсказать об ошибке, которая произошла в запросе, или попросту о том, что сервер базы данных (или текущее подсоединение) занято.

Безопасное программирование на PHP

В этой статье я хочу рассказать основные принципы безопасного программирования на PHP. На написание статьи меня подтолкнул тот факт, что в интернете очень много статей о том как взламывать сайты через дыры в PHP-скрпитах, но очень мало советов (и все они разбросаны) как не делать ошибок, через которые сайт может быть взломан. Статью я решил разделить на несколько частей, каждая из которых посвящена какому то типу ошибок и примером, как этой ошибки избежать. В конце статьи я хочу дать общие советы. Итак, приступим.
Include-баг

PHPTIME

Безопасность

Прямой эфир

adogay 9 января 2020, 13:49

pechen 5 декабря 2020, 06:39

clod 2 февраля 2020, 18:28

isudakoff 19 марта 2020, 07:55


pantsarny 23 апреля 2015, 10:40

Adik88 10 марта 2015, 19:43

JudKavel 2 февраля 2015, 23:11

rmrevin 4 декабря 2014, 20:55

Grover 13 октября 2014, 16:48

amor_amore 15 сентября 2014, 13:59

rmrevin 3 сентября 2014, 13:51

Adik88 2 сентября 2014, 13:13

rmrevin 2 сентября 2014, 13:12

rmrevin 16 июня 2014, 19:27

hui_nana 28 мая 2014, 13:33

Grover 26 мая 2014, 11:42

Grover 26 мая 2014, 11:41

hui_nana 23 мая 2014, 10:26

Блоги

  • Q&A9.42
  • Frontend7.96
  • Yii framework7.92
  • OS Linux5.66
  • CMS 1C-Bitrix5.65
  • PHP. Продукты4.63
  • PHP. Производительность4.53
  • PHP. Особенности и фичи4.53
  • Безопасность4.52
  • HTML51.25

Ловушки PHP

После прочтения статьи Securing PHP, написанной Джеймсом Каннингемом, я подумал, что неплохо бы собрать воедино несколько тезисов об использовании PHP. Имейте в виду, что я не эксперт по вопросам безопасности. Однако эта статья содержит несколько отправных точек по предотвращению заражения экcплоитами, повышению защищенности PHP-приложений и прочим вещам, которые я считаю самыми полезными из своей практики. Ваша оценка может (и, вероятно, будет) колебаться: нормально воспринимать все с недоверием. И это не зависит от того, где вы прочтете такую информацию — здесь или в другом месте. Это не столько контрольный список конкретных действий, сколько набор правил, на которые надо обратить внимание при программировании.

Одержимость PHP

Первое, с чем вы столкнетесь при начале работы с PHP — отвратительная репутация интерпретатора. Вы услышите много высказываний, в том числе: «он не масштабируется», «это не настоящий язык», «в php нет X, поэтому php – отстой», «он не безопасен», или «это парадокс Блаба и ты слишком глуп, чтобы понять парадокс Блаба». С точки зрения времени, проведенного за изучением языка, все это полная чушь. Тем не менее, в данных высказываниях есть доля правды — хотя это вообще не ошибка в PHP. Вина за все причисленные «косяки» лежит исключительно на разработчиках, использующих его. Может вас это и не утешит, но другие языки и фреймворки страдают ровно от тех же проблем. Просто это не афишируется. Ошибки в PHP-приложениях кажутся настолько огромными и многочисленными из-за того, что язык широко распространен и достаточно мощен.

Основы: как работает PHP

Поскольку PHP является таким доступным и повсеместным, многие «сообразительные» люди копируют и вставляют готовые скрипты в одном приложении. Таким «разработчикам» в более совершенном мире напрочь запретили бы прикасаться к исходному коду. Поступая таким образом ты обязан знать, как работает система изнутри.

На самом фундаментальном уровне веб-сервер обрабатывает PHP-код после приема запроса из браузера пользователя. Это на самом деле очень простая концепция, применяемая в большинстве случаев. В настоящее время большинство серьезных веб-серверов сконфигурированы для интерпертирования PHP. Обработка PHP-кода делается только со стороны веб-сервера. После обработки результат передается в браузер пользователя. Но так было не всегда. В прошлом веб-серверы часто запускали полный вариант PHP-кода при каждом запросе. Такой подход может показаться вам неэффективным, и вы будете абсолютно правы. Когда люди, наконец, поняли, насколько расточителен этот метод, они приняли нынешнюю модель повторного использования PHP-экземпляров после завершения его работы. Тем не менее, на некоторых хостингах все еще используется старая модель.

Чистый лист

Каждый разработчик должен усвоить один принципиальный момент. Среда создается только один раз за PHP-запрос. Что бы вы ни делали в течение последних запросов, следующий запрос к веб-серверу начнется с абсолютно чистого листа. Эта ситуация характерна для многих веб-языков. Другие оперируют с постоянной окружающей средой. При работе с PHP это ограничение позволяет выполнять одни вещи удивительно просто, а с другими могут возникнуть проблемы. Все зависит от ваших требований. Если взглянуть с положительной стороны, это позволяет разработчикам смотреть на каждый запрос, как на изолированную проблему. Кроме того, гораздо труднее сделать ошибку, которая обрушивает весь сервер. Меньше расходуется память и другие ресурсы, которые находятся в состоянии выполнения. С другой стороны, такое ограничение означает, что восстановление среды для каждого запроса требует вычислительных затрат. Кроме того, разработчики не считают такой уж большой проблемой весьма медленную работу приложения и, соответственно, не стремятся ускорить процессы, забывая о том, что продуктивная работа сторонится на принципе экономии ресурсов, в том числе временных.

Чего следует избегать

В первую очередь всего, что подразумевает процедуру инициализации. Не загружать, не проверять, не подключать и не вычислять ненужное. PHP не сможет реализовать вашу мечту и стать ООП. Избегайте огромных иерархий классов. Имейте в виду, что вся эта структура должна разбираться, а затем создаваться при каждом запросе. Так что во многих случаях лучше иметь максимально плоскую систему классов. Не храните большие объемы данных в переменной $ _SESSION, потому что она тоже должна перегружаться при каждом запросе. Если вы уверены, что ваш веб-сервер не поддерживает кэширование (например, APC), не используйте огромные файлы, наполненные ненужным исходным кодом.

Что нужно делать

Функциональное программирование — не обязательно зло. Оно весьма эффективно срабатывает каждый раз, когда на первый план для вас выходят такие характеристики, как скорость и/или простота. Безусловно, необходимы require()/include() файлы. Рассмотрите возможность использования загрузчика класса (осторожно), чтобы загрузить функциональные модули по требованию.

Что необходимо знать

Профилирование, профилирование, профилирование .

PHP позволяет легко отслеживать количество времени и памяти, которые использует ваше приложение. Отслеживать эти показатели очень важно! Если попытаться оценить их интуитивно, можно прийти к выводу, что скорость выполнения PHP находится где-то между Руби и JavaScript (V8). Тут легко наделать ошибок, которые в конечном итоге сожрут много памяти и/или ценных процессорных ресурсов.

Вам даже не нужны серверные отладчики или специальные инструменты для достижения этой цели. Функция microtime() показывает метку времени в микросекундах, а memory_get_usage() дает общее представление о памяти, затраченной на ваш скрипт. Это облегчает вам проверку двух наиболее фундаментальных ресурсов, задействованных в ключевых моментах при работе с вашим приложением.

Лично я привык использовать очень простую профилирующую функцию, основанную на microtime(). Использование этой функции для профилирования кода позволит вам понять, насколько ужасны определенные операции на самом деле. Например, подключение к базе данных, запуск регулярных выражений. Эти операции тоже затрачивают определенные ресурсы, и вы должны знать, сколько именно. Всегда нужно знать, что происходит внутри системы.

Для более серьезного профилирования и отладки переходите на http://xdebug.org/ но microtime() — по-прежнему быстро дает вам ценную информацию в любой среде PHP.

Ввод и вывод

Одна из наиболее распространенных ошибок — неспособность обезопасить ввод данных в веб-приложение. Важно помнить, что каждый кусок данных, поступающих в ваше приложение, потенциально опасен. В PHP массив $ _REQUEST содержит все параметры, относящиеся к текущему запросу, и важно не доверять им. К сожалению, не существует единого способа обеспечить безопасность данных. Все зависит от того, что вы будете с ними делать. В лучшем случае, обработка пользовательского ввода попадает в одну или несколько нижеследующих категорий. Существующие стандартные методы позволят избежать нежелательных последствий:

>>> Правило безопасности ввода данных №1: Стереть с лица Земли — это единственный способ, быть уверенным!

  • перевод
  • , php

  • Чем так хорош язык веб-разработки PHP

    Дата публикации: 2020-10-26

    От автора: пришла пора рассказать о языке, который формирует большинство современных веб-страниц. Кто-то отзывается о нем хорошо, кто-то плохо, но не существует разработчиков, которые бы игнорировали его существование. Сегодня разберем все основные моменты, которые таит в себе язык веб-разработки PHP. Заодно выясним, как использовать его с максимальной эффективностью.

    Все преимущества

    На «препроцессор» ругаются даже те, кто ничего о нем не знает. Новичку достаточно услышать от опытного программиста нелестную критику, и он, уже подражая корифею, отзывается негативно. Вы тоже не раз слышали подобное: низкая типизация данных, ошибки в коде и много всего другого. Но об этом позже: сначала о хорошем.

    Предназначение: для чего создан язык

    Днем рождения принято считать 8 июня 1995 года, когда Расмус Лердорф выпустил первую версию Personal Home Page Tools (PHP Tools). За основу он взял Perl и создал интерпретатор шаблонов, который должен был ускорить веб-разработку. Через два года он выпустил вторую версию шаблонизатора, разработка которого велась с помощью С.

    Как создать сайт самому?

    Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

    Но настоящее рождение «препроцессора», как языка, который известен сегодня, произошло в 1998 году, когда был полностью переписан код. Увидев перспективную разработку, программисты со всего мира принялись совершенствовать ее. Именно благодаря общему труду, сегодня язык поддерживает создание wеб-приложений на основе различных серверов и баз данных. Ну, а тот «препроцессор», который вдохновил Цукерберга на создание Facebook, появился в 2004.

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

    Так много на PHP

    Хотя и программисты любят наговорить плохого о «препроцессоре», они знают, как много удачных проектов взяли его за основу. Самыми популярными из них являются Facebook и WordPress. C первым вы знакомы давно: это самая большая социальная сеть в мире. Они даже выпустили собственный транслятор для языка, который называется HipHop. Для Цукерберга, скорее всего, выбор был обусловлен простотой языка. Изначально, FB не планировался настолько масштабным, потому разработка с помощью «гипертекстового препроцессора» казалась хорошей идеей.

    Все страницы и веб-приложения работали на языке долгие годы, пока команда не решила отказаться от этого. Они создали новый, чтобы с его помощью продолжить поддержку сайта. Но правда в том, что даже новый язык — это тот же «препроцессор», только с некоторыми дополнениями. В основе языка Hack лежит PHP, но разработанный для нужд Facebook. Скорее всего, разработка с помощью уникального языка была скорее коммерческим ходом, чем необходимостью.

    О том, что в основе WordPress лежит PHP, не знает разве что ленивый. При этом сама платформа работает отлично, особенно в новых версиях. Самые любопытные даже знают о том, что в свое время проблемы с сериализацией создавали опасность для сайтов, сделанных в WP. Некоторые даже пророчили крах CMS, но 12 июля 2020 года компания выпустила версии, где все проблемы были устранены. Кстати, при помощи того же «препроцессорa».

    Но социальная сеть и система управления могут показаться не самыми весомыми доказательствами эффективности PHP. Нужно привести web-приложение, которое полностью работает на этом языке, решает глобальные проблемы и имеет коммерческий успех. Что ж, платформа электронной коммерции WooCommerce тоже полностью разработана с помощью «препроцессорa». Через нее проходит почти половина всех интернет-покупок в мире. Кстати, в основе их ближайшего конкурента — Magento — тоже лежит PHP.

    Почему же все эти проекты и web-приложения взяли такой критикуемый шаблонизатор за основу? Об этом далее!

    О достоинствах

    Надо сказать, что большинство позитивных сторон PHP и так известны программистам. Вот перечень преимуществ, которые делают широко применимым его в веб-разработке:

    разработка с помощью PHP дает много возможностей. При должном уровне владения, с помощью шаблонизатора можно создавать не только сценарии для веб-приложений, но и полноценные программы. Существуют решения, позволяющие создавать мобильные приложения на PHP;

    изучение PHP не требует много времени. Это одновременно и плюс, и минус. Ведь основательное знание требует практики, но об этом позже;

    кроссплатформенность. PHP может быть запущен в любой операционной системе, включая юниксоиды;

    поддержка веб-серверов. Сложно найти тот, который бы не работал с PHP;

    Как создать сайт самому?

    Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

    бесплатное распространение. Возможно, PHP не был так популярен для создания web-приложений, если бы не был бесплатным, как и большинство инструментов для работы с ним. Аналоги, которые, в основном, могут выполнить ту же работу, обычно стоят дороже;

    имеет достаточную произвольность для web-разработки. Конечно, такие базовые языки, как C-семейство, работают быстрее, но для веба это не критично;

    наличие учебных материалов. Все знают о «косяках» PHP лишь потому, что разработку, в основном, ведут с его помощью. Попробуйте найти в Google недостатки «Virtual Reality Modeling Language». Будет сложно, ведь его мало кто знает. Зато основу недостатков «препроцессорa» уже все выучили наизусть из-за широкой используемости языка. Именно потому, если у вас что-то не получается, всегда можно заглянуть в поисковик: с вашей проблемой, вероятнее всего, кто-то уже сталкивался;

    непрерывное развитие. То, что сегодня о шаблонизаторе знают так много, означает лишь одно: с недостатками, рано или поздно, справятся.

    Около 80% всех существующих web-приложений было создано на шаблонизаторе, и естественно, что в них были найдены ошибки. К тому же, низкий порог входа позволяет новичкам создавать масштабные продукты. Их «поделки» редко отличаются качеством, но все-же работают.

    Проблемы, требующие решения

    Несмотря на широкую используемость в сфере создания сайтов и web-приложений, у «препроцессорa» действительно есть недостатки. Но если одни видят в них причины не изучать язык, то другие видят предупреждение, которое нужно воспринимать как путеводитель. Среди проблем:

    узкопрофильность. Если вы выучили разработку с помощью PHP, то у вас одна дорога — в веб. И хотя возможности расширены различными реализациями, все же он «заточен» под программирование для Интернета;

    безопасность. У PHP есть средства безопасности уровня системы и уровня web-приложения. Но, опять же, широкая используемость сыграла злую шутку: дыры в PHP находят быстрее, чем разработчики успевают их закрывать. В PHP 7 множество проблем решено, но злоумышленник всегда впереди. В силу того, что массы знают «препроцессор», трудно предугадать всё;

    противоречия в коде. Когда шаблонизатор был только создан, все программное обеспечение разрабатывались с помощью С. Потому в языке было применено множество синтаксиса из него. В то же время, современная аудитория больше сконцентрирована на Java. В итоге, код переполнен различными остатками из разных языков. И все они могут даже быть сконцентрированы в одном выражении кода.

    Но основы всех проблем, с которыми связывают PHP, спровоцированы не самим шаблонизатором, а скорее, с окружающими обстоятельствами. Сам по себе язык отлично интегрировался в разработку современных веб-приложений. И такая ситуация сохраняется уже много лет. Начиная с 1998 года веб-разработка с помощью PHP проводится в 8 случаях из 10. Таких долгожителей в программировании не так уж много: тренды меняются очень быстро.

    Не стоит и забывать, что «препроцессор» создан для конкретной цели: веб-разработка. И если молодой разработчик в нем делает ошибки, это не так уж важно. Тем более, что люди, получившие основу при изучении PHP, гораздо охотнее развиваются далее, чем те, кто обломил энтузиазм о сложность таких языков, как Java.

    Впереди развитие

    Не был бы «препроцессор» так популярен для создания веб-приложений, если бы так стремительно не развивался. Особенно порадовала разработчиков седьмая версия, которая имеет ряд позитивных отличий. Среди них, например, внедрение оператора объединения с null, объявления скалярных типов и много другого. Как и планировалось в шестой, седьмая версия полностью принимает шестнадцатеричный Unicode.

    Примечательно, что уже идет разработка версии 7.2, которая готовит еще больше новостей, чем предшественник. Множество функций в шаблонизаторе, с помощью которого будет идти веб-разработка в будущем, теперь признаны устаревшими.

    Но в отличие от растущего конкурента Go — малоиспользуемого, но эффективного Ruby — новому PHP уже есть, у кого поучиться. Он используется настолько широко, что материалы для освоения выходят почти синхронно с самими версиями. Каждый год ему пророчат полную замену аналогами по разным причинам: считается, что серверная сторона на языке не будет нужна, а ее полностью заменит клиентский JavaScript. Но несмотря на предсказания, новые фреймворки выходят, а самих сайтов на шаблонизаторе меньше не становится.

    «Препроцессор», как язык web-приложений, однозначно нужно учить. Человеку, который уже знает С или подобные, он «зайдет» на ура. А тому, кто только пришел в разработку, он не доставит много хлопот. Это настоящий подарок: интересное начинается с самого начала. Так что:

    Безопасность

    User Contributed Notes 14 notes

    If a single file has to be included than I use the following

    index.php ( where the file is gonna be included )
    ___________
    ( ‘thefooter’ , TRUE );
    include( ‘folder/footer.inc.php’ );
    ?>

    and the footer file (for example) looks this way then

    footer.inc.php ( the file to be inluded )
    ___________
    ( ‘thefooter’ ) or die( ‘Not with me my friend’ );
    echo( ‘Copyright to me in the year 2000’ );
    ?>

    So when someone tries to access the footer.php file directly he/she/it will get the «Not with me my friend» messages written on the screen. An alternative option is to redirect the person who wants to access the file directly to a different location, so instead of the above code you would have to write the following in the footer.inc.php file.

    ( ‘thefooter’ ) or header ( ‘Location: http://www.location.com’ );
    echo( ‘Copyright to me in the year 2000’ );
    ?>

    In normal case a redirection to an external site would be annoying to the visitor, but since this visitor is more interested in hacking the site than in reading the content, I think it’s only fair to create such an redirection. We dont’ realy want someome like this on our sites.

    For the file protection I use .htaccess in which I say to protect the file itself and every .inc file

    Order allow,deny
    Deny from all
    Satisfy All

    The .htaccess file should result an Error 403 if someone tries to access the files directly. If for some reason this shouldn’t work, then the «Not with me my friend» text apears or a redirection (depending what is used)

    In my eyes this looks o.k. and safe.

    If your PHP pages include() or require() files that live within the web server document root, for example library files in the same directory as the PHP pages, you must account for the possibility that attackers may call those library files directly.

    Any program level code in the library files (ie code not part of function definitions) will be directly executable by the caller outside of the scope of the intended calling sequence. An attacker may be able to leverage this ability to cause unintended effects.

    The most robust way to guard against this possibility is to prevent your webserver from calling the library scripts directly, either by moving them out of the document root, or by putting them in a folder configured to refuse web server access. With Apache for example, create a .htaccess file in the library script folder with these directives:

    Order Allow,Deny
    Deny from any

    I’d recommend a 404 over a 403 considering a 403 proves there is something worth hacking into.

    index.php:
    ( ‘isdoc’ , 1 );
    include( ‘includes/include.sqlfunctions.php’ );
    // Rest of code for index.php
    ?>

    include.sqlfunctions.php (or other include file):
    if( isdoc !== 1 ) // Not identical to 1
    <
    header ( ‘HTTP/1.1 404 Not Found’ );
    echo » \n \n 404 Not Found \n » ;
    echo » \n

    Not Found

    The requested URL » . $_SERVER [ ‘REQUEST_URI’ ]. » was not found on this server.

    \n» ;
    echo » \n» . $_SERVER [ ‘SERVER_SIGNATURE’ ]. «\n

    Илон Маск рекомендует:  Что такое код mb_strwidth
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL