Загрузка...Expose php off
Сокрытие PHP
В общем случае внесение неясности ненамного улучшает защищенность системы. Но бывают случаи, когда следует использовать малейшую возможность.
Пример #1 Маскировка PHP под другие языки программирования
Пример #2 Использование неизвестных расширений для PHP-скриптов
Пример #3 Маскировка PHP-файлов под HTML
User Contributed Notes 25 notes
So far I haven’t seen a working rewriter of /foo/bar into /foo/bar.php, so I created my own. It does work in top-level directory AND subdirectories and it doesn’t need hardcoding the RewriteBase.
# Rewrite /foo/bar to /foo/bar.php
RewriteRule ^([^.?]+)$ %
# Return 404 if original request is /foo/bar.php
RewriteCond %
RewriteRule .* — [L,R=404]
# NOTE! FOR APACHE ON WINDOWS: Add [NC] to RewriteCond like this:
# RewriteCond %
try this
RewriteEngine On
# Redirect external .php requests to extensionless url
RewriteCond %
RewriteRule ^(.+).php$ http://example.com/folder/$1 [R=301,L]
# Resolve .php file for extensionless php urls
RewriteRule ^([^/.]+)$ $1.php [L]
The session name defaults to PHPSESS >
To hide this, call session_name() with the $name parameter set to a generic name, before calling session_start(). Example:
PS. If you want to use pretty URLs (i.e. h >
http://www.example.com/home
would still be processed by the home script in our doc root, but for:
apache would actually look for the /home/contact_us.html file in our doc root.
The best solution I’ve found is to set up a virtual host (which I do for everything, even the default doc root) and override the trailing characters handling within the virtual host. So, for a virtual host listening on port 8080, the apache directives would look like this:
DocumentRoot /web/doc_root
Alias /home «/web/doc_root/home.php»
AcceptPathInfo On
Some people might question why we are overr >
You can see if somebody’s using PHP just by adding the following to the end of the URL:
?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
If the page is using PHP, this will show the PHP credits.
Setting expose_php to Off in php.ini prevents this.
I think the best way to hide PHP on Apache and Apache itself is this:
httpd.conf
————-
# .
# Minimize ‘Server’ header information
ServerTokens Prod
# Disable server signature on server generated pages
ServerSignature Off
# .
# Set default file type to PHP
DefaultType application/x-httpd-php
# .
To hide PHP, you need following php.ini settings
and in httpd.conf
ServerSignature Off
(min works, but I prefer off)
It’s a good idea to «hide» PHP anyway so you can write a RESTful web application.
Using Apache Mod Rewrite:
RewriteEngine On
RewriteRule ^control/([^/]+)/(.*)$ sitecontroller.php?control=$1&query=$2
You then use a function like the following as a way to retrieve data (in a zero indexed fashion) from the $_GET superglobal.
function myGET () <
$aGet = array();
if(isset( $_GET [ ‘query’ ])) <
$aGet = explode ( ‘/’ , $_GET [ ‘query’ ]);
>
return $aGet ;
>
?>
This is only a really basic example of course — you can do a lot with Mod Rewrite and a custom ‘GET’ function.
RewriteRule (.*).htm[l]?(.*) $1.php$2 [nocase]
in .htaccess. You’ll need mod_rewrite installed for this .
Keep in mind, if your really freaked out over hiding PHP, GD will expose you.
Go ahead — make an image with GD and open with a text editor.. Somewhere in there you’ll see a comment with gd & php all over it.
More fun includes files without file extensions.
Simply add that ForceType application/x-httpd-php bit to an Apache .htaccess and you’re set.
Oh yea, it gets even better when you play with stuff like the following:
( $_SERVER [ ‘PATH_INFO’ ], 1 );
?>
e.g. www.example.com/somepage/55
foreach ( explode ( ‘/’ , $_SERVER [ ‘PATH_INFO’ ]) as $pair ) <
list( $key , $value ) = split ( ‘=’ , $pair , 2 );
$param [ $key ] = stripslashes ( $value );
>
?>
e.g. www.example.com/somepage/param1=value1/param2=value2/etc=etc
What about this in a .htaccess file :
RewriteEngine on
RewriteRule ^$ /index.php [L]
RewriteRule ^([a-zA-Z0-9-_/]*)/$ /$1/index.php [L]
RewriteRule ^([a-zA-Z0-9-_/]*).(html|htm)$ /$1.php [L]
RewriteRule ^([a-zA-Z0-9-_/]*)$ /$1.php [L]
Typing «sub.domain.foo/anything» loads «/anything/index.php» if ‘anything’ is a directory, else it loads «/anything.php».
I’m sure you can find mutch better, but it works great on my site 🙂
I use the following in the .htaccess document
RewriteEngine On
RewriteBase /
RewriteCond %
RewriteCond %
RewriteRule . /index.php [L]
then the following simple code
= explode ( «/» , $_SERVER [ ‘REQUEST_URI’ ]);
$varone = $permalinks [ 1 ];
$vartwo = $permalinks [ 2 ];
In response to the previous messages, for apache, there is a easier way to set files without «.» to be executed by PHP, just put this in a «.htaccess» file :
I�ve found an easy way to hide php code and the uri is searchable by google and others. (only for unix or linux)
At first I have some rules in my hide.conf (i made an extra .conf for it (apache 2.0))
For example when I want to mask the index.php
My problem is, that my code should be readable.
so I made an extra folder for example srv/www/htdocs/static_output
My phpcode is in the includefolder. (for ex. mnt/source/index.php)
Then I made a link in the shell > ln mnt/source/index.php srv/www/htdocs/static_output/index
So the code is readable (with .php extension) in my includefolder and there is only the link in the srv folder without extension(which is called by the browser. ).
In order to get the PATH_INFO to work in order to pass parameters using a hidden program/trailing slash/»pretty url» in more recent versions of PHP you MUST add «AcceptPathInfo On» to your httpd.conf.
AddType application/x-httpd-php .php .html
AcceptPathInfo On
Try it out with your phpinfo page and you’ll be able to search for PATH_INFO.
If you want to drop the .php use one or both of these:
DefaultType application/x-httpd-php
ForceType application/x-httpd-php
Using the .php extension for all your scripts is not necessary, and in fact can be harmful (by exposing too much information about your server, and by limiting what you can do in the future without breaking links). There are several ways to hide your .php script extension:
(1) Don’t hard code file types at all. Don’t specify any dots, and most web servers will automatically find your .php, .html, .pdf, .gif or other matching file. This is called canonical URL format:
www.xxxxxx.com/page
www.xxxxxx.com/directory/
This gives you great flexibility to change your mind in the future, and prevents Windows browsers from making improper assumptions about the file type.
(2) In an Apache .htaccess file use:
RewriteEngine on
RewriteRule page.html page.php
(3) Force the webserver to interpret ALL .html files as .php:
AddType application/x-httpd-php .php3 .php .html
php.ini с пояснениями на русском языке
Если вы установили PHP как модуль Apache, перед вами открываются дополнительные возможности: вы можете задавать значения некоторых директив прямо в файлах httpd.conf или .htaccess. В силу специфики синтаксиса файлов конфигурации Apache, для отделения имени директивы и ее значения нужно использовать пробел, а не знак =. Кроме того, имена директив PHP должны быть предварены префиксом php_. Например, директива из php.ini auto_prepend_file=top.html будет выглядеть в httpd.conf или .htaccess так: php_auto_prepend_file top.html.
Приведенного листинга с комментариями должно быть вполне достаточно для понимания роли большинства директив PHP.
Файл php.ini
; Этот файл содержит большинство установок PHP. Чтобы PHP смог его
; обнаружить, он должен называться ‘php.ini’. Интерпретатор ищет файл в
; текущем каталоге, в случае неудачи — в каталоге, указанном в
; переменной окружения PHPRC, и, наконец, в каталоге, заданном при
; компиляции и сборке PHP (именно в таком порядке).
; В системе Windows путь, указанный при компиляции PHP,
; соответствует каталогу Windows (в большинстве случаев это
; c:windows). Папка, в которой будет производиться поиск файла
; ‘php.ini’, может быть также определена с использованием ключа –c
; командной строки.
;
; Синтаксис файла крайне прост. Пробельные символы (то есть, пробелы,
; символы табуляции и т. д.), строки, начинающиеся с точки с запятой (;)
; игнорируются (как вы, наверное, уже догадались). Заголовки секций
; (например, [Foo]) также пропускаются, но, возможно, будут учитываться
; в будущих версиях PHP.
;
; Директивы задаются примерно так:
; directive=value
; Имена директив чувствительны к регистру символов — foo=bar не то же
; самое, что FOO=bar.
;
; Значение value может быть строкой, числом, константой PHP (например,
; E_ALL или M_PI), одной из INI-констант (On, Off, True, False, Yes, No
; или None), выражением (например, E_ALL &
E_NOTICE), а также строкой
; в кавычках («foo»).
;
; В выражениях могут использоваться только побитовые и логические
; операторы, а также скобки:
; | поразрядное ИЛИ (OR)
; & поразрядное И (AND)
;
поразрядное НЕ (NOT)
; ! логическое отрицание (NOT)
;
; В качестве логических флагов со значением «истина» могут быть
; использованы значения 1, On, True или Yes. Значение «ложь» дают 0, Off,
; False и No.
;
; Пустая строка может быть задана, если «не указать ничего» после знака
; равенства, или же указать слово None:
; foo= ; устанавливаем foo равным пустой сторке
; foo=none ; аналогично
; foo=»none» ; устанавливаем foo равным строке ‘none’
;
; Если вы используете константы в качестве части значения директивы и эти
; константы определяются в каком-нибудь динамически загружаемом
; расширении (модуле PHP или Zend), вы можете указывать их только после
; строки, которая загружает расширение.
;
; Все значения в файле php.ini-dist соответствуют встроенным значениям
; по умолчанию. Если php.ini не задействуется, или же вы удалите из него
; некоторые строки, будут установлены значения по умолчанию.
; Разрешает работу PHP для сервера Apache.
engine=On
; Разрешает использовать короткие тэги
Защищаем PHP. Шаг за шагом.
Эта статья рассказывает об основных шагах в защите PHP, одном из наиболее популярных языков создания сценариев, созданном в основном для создания динамических web-страниц. Для избежания повтора информации, охваченной в предыдущей статье, мы покажем только основные различия, от процесса защиты Web сервера Apache.
В предыдущей статье «Защищаем Apache» автор описал метод защиты Web сервера Apache от несанкционированного доступа из Internet. Благодаря этому методу можно было достичь высокого уровня защиты, но в случае обслуживания только статических HTML страниц. Но как же осуществить защиту, когда необходимо взаимодействие с пользователем, а данные пользователей должны быть сохранены в локальной базе данных?
Эта статья рассказывает об основных шагах в защите PHP, одном из наиболее популярных языков создания сценариев, созданном в основном для создания динамических web-страниц. Для избежания повтора информации, охваченной в предыдущей статье, мы покажем только основные различия, от процесса защиты Web сервера Apache.
Как и в предыдущей статье, операционной системой является — FreeBSD 4.7. Однако, представленные методы можно также применять и на более современных unix и unix-подобных системах. Мы также предполагаем, что база данных MySQL установлена на хосте, и помещена в каталог «/usr/local/mysql».
Функциональные возможности будут подобны описанным в предыдущей статье. Однако, существуют некоторые изменения:
Предложения по защите
Должно быть добавлено следующее:
- PHP конфигурация должна пользоваться преимуществом встроенных механизмов защиты
- PHP сценарии должены быть выполнены в chrooted среде
- Apache сервер должен отклонять все запросы (GET и POST), которые содержат HTML-тэги (возможная атака межсайтового скриптинга), знаки апострофа “`” и двойные кавычки (возможная SQL-injection атака)
- Ни одно из PHP предупреждений или сообщений об ошибках не должно быть доступно пользовательским Web приложениям.
Подготовка программного обеспечения
Прежде всего, мы должны загрузить исходники самых последних версий Apache, PHP и модуля mod_security . Модуль будет использоваться, для защиты от CSS и SQL-injection атак. Затем, загруженное программное обеспечение должно быть распаковано, а содержание архива — помещено в основной каталог. Исходники модуля mod_security должны быть помещены в каталог Apaсhe «src/modules/extra»:
gzip -dc apache_1.3.27.tar.gz | tar xvf —
gzip -dc php-4.3.2.tar.gz | tar xvf —
gzip -dc mod_security_1.5.tar.gz | tar xvf —
cp mod_security_1.5/apache1/mod_security.c apache_1.3.27/src/modules/extra/
Если существуют любые доступные патчи защиты к вышеупомянутому программному обеспечению, то они должны быть загружены и выполнены.
Перед компиляцией программы, мы должны определиться в одном из трех методов инсталляции PHP:
Каждый из этих методов имеет свои преимущества и недостатки. Компиляция PHP, как статического модуля, принесет пользу от улучшения производительности Web сервера, но при апгрейде PHP до более новой версии придется перекомпилировать весь Web сервер. Компиляция PHP как динамического модуля, позволяет избежать этого недостатка, но производительность WEB сервера будет уменьшена приблизительно на 5%, и был бы необходим еще один модуль: mod_so. Третий метод состоит в установке PHP как интерпретатора CGI — вместе с механизмом Apache — suEXEC, что является весьма интересным решением. К сожалению, при неправильной установке этот метод может представлять серьезную угрозу защите.
Для лучшей защиты и производительности, лучшим выбором, является компиляция PHP как статического модуля. Именно поэтому остальная часть статьи основана на этом методе инсталляции.
Вообще, как описано в предыдущей статье, инсталляционный процесс Apache с PHP очень похож на процесс установки Apache без PHP, Единственное различие — использование двух дополнительных модулей: mod_PHP и mod_security.
Как и в предыдущей статье, мы начнем с создания учетной записи и группы, называемых «apache». Для этого мы должны подготовить Web сервер Apache следующим образом:
cd apache_1.3.27
./configure
И откомпилировать PHP модуль:
cd ../php-4.3.2
./configure —with-mysql=/usr/local/mysql —with-apache=../apache_1.3.27 —enable-safe-mode
make
su
make install
Затем мы перемещаемся в каталог с Apache и продолжаем установку:
cd ../apache_1.3.27
./configure —prefix=/usr/local/apache —disable-module=all —server-u > make
su
make install
chown -R root:sys /usr/local/apache
В команде «./configure», используются только те модули, которые являются необходимыми для выполнения функциональных возможностей и предложений по защите. Выбор модулей был детально обсужден в предыдущей статье. В следующем шаге мы должны возвратиться к каталогу PHP и скопировать файл конфигурации PHP:
cd ../php-4.3.2
mkdir /usr/local/lib
chmod 755 /usr/local/lib
cp php.ini-recommended /usr/local/lib/php.ini
chown root:sys /usr/local/lib/php.ini
chmod 644 /usr/local/lib/php.ini
Для сценариев PddType application/x-httpd-php .phpHP, которые будут обрабатываться Web сервером Apache, к /usr/local/Apache/conf/httpd.conf должна быть добавлена следующая строка:
AddType application/x-httpd-php .php
