Php закрыть доступ к файлу
Осуществляет попытку изменения режима доступа указанного файла на режим, переданный в параметре permissions .
Список параметров
Обратите внимание, что значение параметра permissions не переводится автоматически в восьмеричную систему счисления, поэтому, чтобы удостовериться в том, что режим был установлен верно, предваряйте нулём (0) значение передаваемое в параметре permissions . Строки, такие как "g+w", не будут работать должным образом.
chmod ( "/somedir/somefile" , 755 ); // десятичное, скорее всего, указано неверно
chmod ( "/somedir/somefile" , "u+rwx,go+rx" ); // строка, неверный способ
chmod ( "/somedir/somefile" , 0755 ); // восьмеричное, верный способ
?>?php
Значение параметра permissions состоит из трёх восьмеричных чисел, определяющих уровень доступа для владельца файла, для группы, в которую входит владелец, и для других пользователей, соответственно. Число, определяющее уровень пользователя, может быть вычислено путём суммирования значений, определяющих права: 1 - доступ на выполнение, 2 - доступ на запись, 4 - доступ на чтение. Сложите эти числа для указания нужного права доступа. Более подробно о системе прав в системах Unix вы можете узнать с помощью команд 'man 1 chmod' и 'man 2 chmod'.
// Доступ на запись и чтение для владельца, нет доступа для других
chmod ( "/somedir/somefile" , 0600 );
// Доступ на запись и чтение для владельца, доступ на чтение для других
chmod ( "/somedir/somefile" , 0644 );
// Полный доступ для владельца, доступ на чтение и выполнение для других
chmod ( "/somedir/somefile" , 0755 );
// Полный доступ для владельца, доступ на чтение и выполнение для группы владельца
chmod ( "/somedir/somefile" , 0750 );
?>
Возвращаемые значения
Возвращает true в случае успешного выполнения или false в случае возникновения ошибки.
Ошибки
В случае возникновения ошибки выдаётся ошибка уровня E_WARNING .
Примечания
Замечание:
Текущим пользователем является пользователь, от имени которого выполняется PHP. Возможно, что это будет не тот пользователь, под именем которого вы получаете доступ к командной оболочке или учётной записи FTP. На большинстве систем режим доступа к файлу может быть изменён только его владельцем.
Замечание: Эта функция неприменима для работы с удалёнными файлами, поскольку файл должен быть доступен через файловую систему сервера.
Смотрите также
- chown() - Изменяет владельца файла
- chgrp() - Изменяет группу файла
- fileperms() - Возвращает информацию о правах на файл
- stat() - Возвращает информацию о файле
User Contributed Notes 17 notes
BEWARE, a couple of the examples in the comments suggest doing something like this:
chmod(file_or_dir_name, intval($mode, 8));
However, if $mode is an integer then intval( ) won't modify it. So, this code.
$mode = 644;
chmod('/tmp/test', intval($mode, 8));
. produces permissions that look like this:
Instead, use octdec( ), like this:
BEWARE using quotes around the second parameter.
If you use quotes eg
chmod (file, "0644");
php will not complain but will do an implicit conversion to an int before running chmod. Unfortunately the implicit conversion doesn't take into account the octal string so you end up with an integer version 644, which is 1204 octal
Value Permission Level
400 Owner Read
200 Owner Write
100 Owner Execute
40 Group Read
20 Group Write
10 Group Execute
4 Global Read
2 Global Write
1 Global Execute
In the previous post, stickybit avenger writes:
Just a little hint. I was once adwised to set the 'sticky bit', i.e. use 1777 as chmod-value.
Note that in order to set the sticky bit on a file one must use '01777' (oct) and not '1777' (dec) as the parameter to chmod:
chmod ( "file" , 01777 ); // correct
chmod ( "file" , 1777 ); // incorrect, same as chmod("file",01023), causing no owner permissions!
?>
Rule of thumb: always prefix octal mode values with a zero.
use a stored string for the mask is a pain
ex: $mask contains a string 0755
int($mask) not work (return 755)
the only way i found is use octdec($mask)
Changes file mode recursive in $pathname to $filemode
$iterator = new RecursiveIteratorIterator (new RecursiveDirectoryIterator ( $pathname ));
foreach( $iterator as $item ) chmod ( $item , $filemode );
>
Note that info at rvgate dot nl's chmodnum function produces INCORRECT results. The resutls are base-10 numbers that only LOOK like they are octal numbers. The function also ignores setuid, setgid and sticky bits, and will produce incorrect numbers if such a file is encountered. Instead, this brute-force code works. Maybe there is something more slick, but this isn't too CPU-intensive (note that it assumes you've error-checked that you indeed have a 10-character string!):
$permissions = 'drwxr-xr-x' ; // or whatever
$mode = 0 ;
if ( $permissions [ 1 ] == 'r' ) $mode += 0400 ;
if ( $permissions [ 2 ] == 'w' ) $mode += 0200 ;
if ( $permissions [ 3 ] == 'x' ) $mode += 0100 ;
else if ( $permissions [ 3 ] == 's' ) $mode += 04100 ;
else if ( $permissions [ 3 ] == 'S' ) $mode += 04000 ;
if ( $permissions [ 4 ] == 'r' ) $mode += 040 ;
if ( $permissions [ 5 ] == 'w' ) $mode += 020 ;
if ( $permissions [ 6 ] == 'x' ) $mode += 010 ;
else if ( $permissions [ 6 ] == 's' ) $mode += 02010 ;
else if ( $permissions [ 6 ] == 'S' ) $mode += 02000 ;
if ( $permissions [ 7 ] == 'r' ) $mode += 04 ;
if ( $permissions [ 8 ] == 'w' ) $mode += 02 ;
if ( $permissions [ 9 ] == 'x' ) $mode += 01 ;
else if ( $permissions [ 9 ] == 't' ) $mode += 01001 ;
else if ( $permissions [ 9 ] == 'T' ) $mode += 01000 ;
printf ( 'Mode is %d decimal and %o octal' , $mode , $mode );
?>
Windows has a very different file permission model to Unix and integrates them only minimally.
On Windows, all this function can do is to change the "read only" flag, which is turned on if $mode & 0200 does not pass.
i.e. it only checks if u+w is missing from the bitmask, and if it is, it sets the read only flag.
The executable flag cannot be set as Windows determines it based on file extension.
The write flag cannot be set as Windows determines write access based on ACLs, which are not integrated here.
If you cannot chmod files/directories with PHP because of safe_mode restrictions, but you can use FTP to chmod them, simply use PHP's FTP-functions (eg. ftp_chmod or ftp_site) instead. Not as efficient, but works.
Just an update of the solution with octdec. You have to give octdec the string as a parameter.
$mode = '644';
chmod(file_or_dir_name, octdec($mode));
an update to 'neil at 11 out of 10's code for changing mode using FTP.
changes: proper array added within the function (better for those of us who only need to connect to one ftp server) so only the mode and directory name need to be passed.
the octal added, for completeness and predictable stability.
$path = "public" ;
$mod = intval ( $xcite , 8 );
// extract ftp details (array keys as variable names)
extract ( $ftp_details );
// set up basic connection
$conn_id = ftp_connect ( $ftp_server );
// login with username and password
$login_result = ftp_login ( $conn_id , $ftp_user_name , $ftp_user_pass );
// try to chmod $path directory
if ( ftp_site ( $conn_id , 'CHMOD ' . $mod . ' ' . $ftp_root . $path ) !== false ) <
$success = TRUE ;
>
else <
$success = FALSE ;
>
// close the connection
ftp_close ( $conn_id );
return $success ;
>
?>
for those of you, like me, who were looking for a way to make an 'un-hackable' uploader, here's the closest i got, now for a field test, good luck!
I was trying to change permissions of a folder with chmod command with FTP connection. (I needed a writable folder to upload pictures with php)
I got the following respond:
"SITE CHMOD 777 uploads: command not understood"
The reason: Server is running under Windows system that does not allow to set file permissions via FTP. Conversely, the UNIX-running servers allow that.
1. If your web hosting provider has a web-based control panel that lets you set file permissions, then you need to login there and make changes.
2. It is possible to contact the hosting provider and ask them about this issue; maybe they can make the changes.
3. It is possible to change the hosting provider that has servers run on UNIX, and keep the site there.
error_reporting ( E_ERROR | E_PARSE );
/* Makes is so Directories are not browseable to the public,
removing only the Public = Read permission, while leaving
the other chmod permissions for the file in tact.
If you have exectue already on, and read off, public viewers will only
be able to view files through links, but not browse
around to see what's inside of directories and see what
you've got laying around. */
//-------------------------------------------------------
// Get file mode
// Get file permissions supported by chmod
function getmod ( $filename ) <
$val = 0 ;
$perms = fileperms ( $filename );
// Owner; User
$val += (( $perms & 0x0100 ) ? 0x0100 : 0x0000 ); //Read
$val += (( $perms & 0x0080 ) ? 0x0080 : 0x0000 ); //Write
$val += (( $perms & 0x0040 ) ? 0x0040 : 0x0000 ); //Execute
// Misc
$val += (( $perms & 0x40000 ) ? 0x40000 : 0x0000 ); //temporary file (01000000)
$val += (( $perms & 0x80000 ) ? 0x80000 : 0x0000 ); //compressed file (02000000)
$val += (( $perms & 0x100000 ) ? 0x100000 : 0x0000 ); //sparse file (04000000)
$val += (( $perms & 0x0800 ) ? 0x0800 : 0x0000 ); //Hidden file (setuid bit) (04000)
$val += (( $perms & 0x0400 ) ? 0x0400 : 0x0000 ); //System file (setgid bit) (02000)
$val += (( $perms & 0x0200 ) ? 0x0200 : 0x0000 ); //Archive bit (sticky bit) (01000)
//-------------------------------------------------------
// Take the read option off of all the subdirectories of the included path
function pathlock ( $dir , $listall = false , $testrun = true ) <
echo "START @ " . date ( "F j, Y, h:i:s A" ) . "
" ;
echo ( $testrun ? '**Test Run Activated (no changes will be made).**
' : '**Live Run Activated.**
' );
echo $dir . " is our directory.
\n" ;
echo "[. IN PROGRESS. ]
" ;
$file_list = '' ;
$stack [] = $dir ;
while ( $stack ) <
$current_dir = array_pop ( $stack );
if ( $dh = opendir ( $current_dir )) <
while (( $file = readdir ( $dh )) !== false ) <
if ( $file !== '.' AND $file !== '..' ) <
$current_file = " < $current_dir >/ < $file >" ;
if ( is_dir ( $current_file )) <
// BEG ADD PATH
$mode = getmod ( $current_file ); //Get the mode
$HasPubRead = hasmod ( $mode , 4 );
if ( $HasPubRead || $listall ) < // Can the public read this dir?
//======================================
$ch = true ;
$take = 0 ;
// Change the mode:
if ( $HasPubRead ) <
$take = 4 ; // Value for Public Read. 4 is the same in octal and decimal.
if (! $testrun ) <
$ch = chmod ( $current_file , $mode - $take );
>
>
echo $current_file . ",current keyword">. decoct ( $mode ) .
(( $mode !== $mode - $take ) ? ",new keyword">. decoct ( $mode - $take ) : '' ) .
( $ch ? '' : ',FAILED' ) . "
\n" ;
> // end if hasmod
// END ADD PATH
$stack [] = $current_file ;
> // if if_dir
> //if ($file !== '.' AND $file !== '..')
> //while (($file = readdir($dh)) !== false)
> //if ($dh = opendir($current_dir))
> // while ($stack)
echo "
COMPLETE @ " . date ( "F j, Y, h:i:s A" ) . "
\n" ;
return;
//return $path_list;
> // end function
//-------------------------------------------------------
//listall Show all folders, even one's we're not going to process?
//testrun Do a test run without making any changes
pathlock ( $_SERVER [ "DOCUMENT_ROOT" ], false , true ); // listall?=false, testrun?=true
Задача по разграничению доступа к файлам, которые хранятся на диске довольно редка, но она может возникнуть при написании: online-магазина, который торгует файлами или файлового сервера вроде rapidshare.de. В данной статье я рассмотрю 3-и способа разграничения доступа при помощи php, mysql и специальных модулей веб сервера apache.
Это самый простой на мой взгляд способ, он не требует установки каких-то дополнительных модулей apache, но в то же время, в чистом виде, это наименее гибкий метод и работать он будет только на сервере под управлением *nix. Темнеменее это метод прекрасно подойдет для файлового хостинга.
Что нужно сделать:
1. Создадим две директории, в одной из которых будут храниться все файлы, доступ к которым нужно ограничить, а вторая пока будет пуста. Для примере я создал у себя директории: members и free;
2. В директории members создадим файл .htaccess с одной директивой «deny from all», таким образом мы закрываем эту директорию и все файлы, которые вней находятся;
4. Теперь предположим что пользователь авторизовался на вашем сайте или выполнил любые другие действия, после которых он может получить доступ к закрытому файлу. Чтобы дать ему доступ все что нужно это создать символьную ссылку на это файл в директории, которая не закрыта при помощи .htaccess. В моем случае это будет выглядеть примерно так:
exec('cd free; ln -s ../members/test.html test.html');
таким образом в каталоге free у нас будет ссылка на файл из каталога members и мы сможет редиректить на него пользователя или выдать URL.
Так же можно и нужно примешать к названию символьной ссылки какой-нибудь хеш и время, до которого она будет активна. Для удаления просроченных ссылок довольно просто можно написать CLI скрипт и выполнять его по крону раз в N минут.
Что нужно сделать:
1. Создадим таблицу в нашей MySQL базе:
CREATE TABLE `users_sessions` (
`cookie_name` varchar(32) NOT NULL,
`cookie_value` varchar(32) NOT NULL,
`expire` int(11) default '0',
`ip` varchar(15) NOT NULL,
`login` varchar(32) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
где: cookie_name — имя cookie, cookie_value — значение cookie, expire — время окончания действия cookie в формате unix timestamp (в php текущее время в этом формате возвращается функцией time()), ip — удаленный IP, с которого зашел пользователь, login — логин текущего пользователя (нужен для создания личных файлов .htaccess).
3. После успешной авторизации пользователя на сайте сделаем следующие действия:
// Подготавливаем дату окончания действия cookie
$expire = time() + 60 * 60; // cookie будет действовать 1 час
// Подготавливаем значение для авторизационной cookie
$cookieValue = md5($userPassword . $userLogin . $expire . $_SERVER['REMOTE_ADDR']);
// Устанавливаем авторизационную cookie
setcookie('AuthorizationCookie', $cookieValue);
// Сохраняем значения cookie в базе
mysql_query('insert into users_sessions values ("AuthorizationCookie", "' . $cookieValue . '", ' . $expire . ', "' . $_SERVER['REMOTE_ADDR'] . '", "' . $userLogin . '")');
После этих действий мы можем редиректить пользователя на любой файл, находящийся в каталоге members.
Вот собственно и все. На данный момент это все известные мне способы разграничения прав доступа к файлам под управлением веб сервера apache. Если кто-то знает другие — поделитесь ссылкой и я с удовольствием о них почитаю.
Здравствуйте! Не могу определится как лучше реализовать защиту php файлов от прямого доступа:
1) в index.php прописать define('EXEC', true); и в остальных php файлах делать проверку defined('EXEC') || die;
2) .htaccess запретить доступ к php файлам разрешить только index.php
3) ваш вариант
Какой вариант лучше правильней и безопасней?
- Вопрос задан более трёх лет назад
- 6131 просмотр
часто все файлы к которым прямой доступ должен быть запрещен просто выносят за пределы веб директории
/src (здесь весь код приложения)
/web (сюда смотрит apache/nginx)
-- index.php
Поддерживаю. Точки входа в отдельную папку, на которую смотрит Webсервер, а исполняемые файлы в других,недоступных webсерверу папках.
riky: кстати я думал над таким вариантом, но я где то читал что это замедляет работу скрипта, не знаю правда это или нет, но вариант очень хороший, спасибо) я почему спросил, потому что 1 вариант используют многие cmc frameworke итд, а как по мне этот вариант не очень)
при такой структуре вынести будет сложнее - папка src у обоих проектов будет одна. придется извращаться как то.
правильная структура для хостингов - внутри директорий доменов создавать дополнительные директори на которые смотрит веб сервер
www
web
puvlic_html
итд
если вы делаете продукт не для одного заказчика а на сто тыщ пользователей, которые должны будут ставить домохозяйки - то лучше в одну папку все.
так же можно весь закрытый код положить в одну папку и добавить
.htaccess внутрь с текстом
deny from all
это также запретит доступ через веб ко всему внутри.
Рассмотрим следующий пример, в котором пользователь создал скрипт, удаляющий файл из его домашней директории. Предполагается ситуация, когда веб-интерфейс, написанный на PHP , регулярно используется для работы с файлами, и настройки безопасности позволяют удалять файлы в домашнем каталоге.
// Удаление файла из домашней директории пользователя
$username = $_POST [ 'user_submitted_name' ];
$userfile = $_POST [ 'user_submitted_filename' ];
$homedir = "/home/ $username " ;
unlink ( " $homedir / $userfile " );
echo "Файл был удалён!" ;
?>
Поскольку переменные вводятся в пользовательской форме, существует возможность удалить файлы, принадлежащие кому-либо другому, введя соответствующие значения. В этом случае может понадобиться авторизация. Посмотрим, что произойдёт, если будут отправлены значения "../etc/" и "passwd". Скрипт выполнит следующие действия:
// Удаление любого файла, доступного из PHP-скрипта.
// В случае, если PHP работает с правами пользователя root:
$username = $_POST [ 'user_submitted_name' ]; // "../etc"
$userfile = $_POST [ 'user_submitted_filename' ]; // "passwd"
$homedir = "/home/ $username " ; // "/home/../etc"
unlink ( " $homedir / $userfile " ); // "/home/../etc/passwd"
echo "Файл был удалён!" ;
?>
- Ограничить доступ пользователя, с правами которого работает веб-сервер с PHP .
- Проверять все данные, вводимые пользователем.
// Удаление любого файла, к которому имеет доступ пользователь,
// под которым запущен PHP.
$username = $_SERVER [ 'REMOTE_USER' ]; // использование авторизации
$userfile = basename ( $_POST [ 'user_submitted_filename' ]);
$homedir = "/home/ $username " ;
$filepath = " $homedir / $userfile " ;
if ( file_exists ( $filepath ) && unlink ( $filepath )) $logstring = " $filepath удалён\n" ;
> else $logstring = "Не удалось удалить $filepath \n" ;
>
$fp = fopen ( "/home/logging/filedelete.log" , "a" );
fwrite ( $fp , $logstring );
fclose ( $fp );
echo htmlentities ( $logstring , ENT_QUOTES );
Однако и такая проверка не учитывает все возможные ситуации. Если система авторизации позволяет пользователям выбирать произвольные логины, взломщик может создать учётную запись вида "../etc/" и система опять окажется уязвимой. Исходя из этого, вам может понадобиться более строгая проверка:
$username = $_SERVER [ 'REMOTE_USER' ]; // использование авторизации
$userfile = $_POST [ 'user_submitted_filename' ];
$homedir = "/home/ $username " ;
$filepath = " $homedir / $userfile " ;
if (! ctype_alnum ( $username ) || ! preg_match ( '/^(?:[a-z0-9_-]|\.(?!\.))+$/iD' , $userfile )) die( "Неправильное имя пользователя или файл" );
>
В зависимости от используемой вами операционной системы необходимо предусматривать возможность атаки на разнообразные файлы, включая системные файлы устройств (/dev/ или COM1), конфигурационные файлы (например /etc/ или файлы с расширением .ini), хорошо известные области хранения данных (/home/, My Documents), и так далее. Исходя из этого, как правило, легче реализовать такую политику безопасности, в которой запрещено все, исключая то, что явно разрешено.
User Contributed Notes 7 notes
(A) Better not to create files or folders with user-supplied names. If you do not validate enough, you can have trouble. Instead create files and folders with randomly generated names like fg3754jk3h and store the username and this file or folder name in a table named, say, user_objects. This will ensure that whatever the user may type, the command going to the shell will contain values from a specific set only and no mischief can be done.
(B) The same applies to commands executed based on an operation that the user chooses. Better not to allow any part of the user's input to go to the command that you will execute. Instead, keep a fixed set of commands and based on what the user has input, and run those only.
For example,
(A) Keep a table named, say, user_objects with values like:
username|chosen_name |actual_name|file_or_dir
--------|--------------|-----------|-----------
jdoe |trekphotos |m5fg767h67 |D
jdoe |notes.txt |nm4b6jh756 |F
tim1997 |_imp_ folder |45jkh64j56 |D
and always use the actual_name in the filesystem operations rather than the user supplied names.
(B)
$op = $_POST [ 'op' ]; //after a lot of validations
$dir = $_POST [ 'dirname' ]; //after a lot of validations or maybe you can use technique (A)
switch( $op ) case "cd" :
chdir ( $dir );
break;
case "rd" :
rmdir ( $dir );
break;
.
default:
mail ( "webmaster@example.com" , "Mischief" , $_SERVER [ 'REMOTE_ADDR' ]. " is probably attempting an attack." );
>
All of the fixes here assume that it is necessary to allow the user to enter system sensitive information to begin with. The proper way to handle this would be to provide something like a numbered list of files to perform an unlink action on and then the chooses the matching number. There is no way for the user to specify a clever attack circumventing whatever pattern matching filename exclusion syntax that you may have.
Anytime you have a security issue, the proper behaviour is to deny all then allow specific instances, not allow all and restrict. For the simple reason that you may not think of every possible restriction.
Well, the fact that all users run under the same UID is a big problem. Userspace security hacks (ala safe_mode) should not be substitution for proper kernel level security checks/accounting.
Good news: Apache 2 allows you to assign UIDs for different vhosts.
devik
A basic filename/directory/symlink checking may be done (and I personally do) via realpath() .
if (isset( $_GET [ 'file' ])) <
$base = '/home/polizei/public_html/' ; // it seems this one is good to be realpath too.. meaning not a symlinked path..
if ( strpos ( $file = realpath ( $base . $_GET [ 'file' ]), $base ) === 0 && is_file ( $file )) <
unlink ( $file );
> else <
die( 'blah!' );
>
>
?>
when using Apache you might consider a apache_lookup_uri on the path, to discover the real path, regardless of any directory trickery.
then, look at the prefix, and compare with a list of allowed prefixes.
for example, my source.php for my website includes:
if(isset($doc)) $apacheres = apache_lookup_uri($doc);
$really = realpath($apacheres->filename);
if(substr($really, 0, strlen($DOCUMENT_ROOT)) == $DOCUMENT_ROOT) if(is_file($really)) show_source($really);
>
>
>
hope this helps
regards,
KAT44
I don't think the filename validation solution from Jones at partykel is complete. It certainly helps, but it doesn't address the case where the user is able to create a symlink pointing from his home directory to the root. He might then ask to unlink "foo/etc/passwd" which would be in his home directory, except that foo is a symlink pointing to /.
Personally I wouldn't feel confident that any solution to this problem would keep my system secure. Running PHP as root (or some equivalent which can unlink files in all users' home directories) is asking for trouble.
If you have a multi-user system and you are afraid that users may install scripts like this, try security-enhanced Linux. It won't give total protection, but it at least makes sure that an insecure user script can only affect files which the web server is meant to have access to. Whatever script someone installs, outsiders are not going to be able to read your password file---or remove it.
I think the lesson is clear:
(1) Forbit path separators in usernames.
(2) map username to a physical home directory - /home/username is fine
(3) read the home directory
(4) present only results of (3) as an option for deletion.
I have discovered a marvelous method of doing the above in php but this submission box is too small to contain it.
Может запускаться через инклуд, может принимать обращения через ajax.
Как запретить доступ к нему по прямой ссылке? Возможно ли это как-то без htaccess?
Оценить 1 комментарий
Воу воу. В index.php создайте константу которую будете проверять, и после во всех подключаемых файлах проверяйте ее.
п.с. не посмотрел дату вопроса)) но может пригодится
Оставь этот файл в покое. Никому он не нужен.
Куда важнее для тебя разобраться, что
1. К информационной безопасности твой вопрос не имеет ни малейшего отношения
2. "Закрыть" этот файл от доступа извне в принципе невозможно.
3. Все вышеперечисленное плюс любимое заклинание "хтаксесс! хтаксесс!" говорит нам, что ты не понимаешь, как устроена система браузер-сервер. И вот это-то в сто раз важнее твоего несчастного файла. Тебе надо понять, как устроено веб-приложение, где у тебя РНР, а где. Как только ты это поймешь, то дурацких вопросов типа этого у тебя уже возникать не будет.
сюда же добавлю мысль автору вопроса:
Подумайте, чем отличается "открытие файла через аякс", от простого открытия файла.
И что мешает злоумышленнику сделать запрос так, чтобы сервер считал что через аякс
Oleg: POST-параметры? Теорию знаю, думал об этом, но тем не менее, вдруг существуют какие-то технологии и уловки, о которых я не знаю.
nikolaypetrov: отличается только доп параметром который можно легко добавлять
Те от взломщика защиты нет - он сам может всегда добавить такой параметр
не слабо, вопрос звучал:
Как запретить доступ к нему по прямой ссылке? Возможно ли это как-то без htaccess?
мой код аккурат определяет по прямой ссылке обратились или нет, по хорошему нужно так:
preg_quote($_SERVER['DOCUMENT_ROOT'] . $_SERVER['PHP_SELF'])
то есть, слово "аякс" ты не увидел? Это очень интересный случай избирательной слепоты, я не в первый раз с таким сталкиваюсь.
nikolaypetrov: хаха, ты до сих пор в этом сомневаешься? То есть вопрос "как запретить доступ к скрипту, к которому требуется доступ" кажется тебе нормальным и логичным?
nikolaypetrov: ну то есть тебя не смущает постановка вопроса "как закрыть доступ к тому, к чем доступ должен быть обязательно"? И ответы в стиле КО ("никак") тебя тоже до сих пор не убедили? Тогда, боюсь, новая информация тебе уже не поможет. Никакая.
FanatPHP: при прямом обращении к файлу веб сервер выдаст 403. При обращении к файлу из другого файла через директиву include страница загрузиться как обычно. Конечно на сервере стоит *nix.
ну у тебя и каша в голове. во-первых, чаще всего веб-сервер запускается не из-под владельца сайтов. То есть, такой чмод тупо убьет весь сайт. Во-вторых, веб-сервер запускает скрипты под тем же пользователем, под которым читает файлы. и если пользователь не сможет прочесть, то РНР, запущенный из-под того же пользователя, не сможет заинклюдить. И третье - ну РАЗУМЕЕТСЯ, ты тоже не прочел про аякс.
под пользователем чтитать UID. А то, не дай бог, ты прочтешь это как полхователь сайта и начнешь меня обвинять в неграмотности. Что меня реально в вас, ламерах, бесит - это если автору вопроса можно дать POC, а дальше он сам, то вам, сцуко, надо шлифовать каждое слово, потому что он пришел учиться, а ты - учить. И ищешь не у себя бревно в глазу - принципиальные, фундаментальные ошибки, незнание основ - а соринку у меня, отдельное слово, к оторое можно истолковать двояко или опечатку.
FanatPHP: К примеру есть 4 файла: ./index.php, ./Controller/controller.class.php, ./View/view.class.php, ./Model/model.class.php. Внутри файлов реализовано что index.php инклудит ./Controller/controller.class.php, а он в свою очередь инклудит ./View/view.class.php и ./Model/model.class.php. Я знаю что если пользователь сайта обратиться к ./View/view.class.php или ./Model/model.class.php он получит пустой экран, но все таки я хочу чтобы он не мог их запустить гепотетически. На стороне файловой системы я делаю chmod 700 ./View/view.class.php и chmod 700 ./Model/model.class.php и chmod 700 ./Controller/controller.class.php и тогда при образении к этим файлам со стороны пользователя сайта вернет пользователю 403. При выполнении include в файле index.php файлы поключаться потому что обращение будет идти к ним от имени владельца файла index.php а следовательно владельца и файлов классов. Все аякс запросы только на index.php, от остальных файлов 403. Все просто если уметь пользоваться системой безопасности файлов в линукс. Если вы не умеете ей пользоваться то не стоит говорить что это положит весь сайт, не будет обеспечивать безопасность и т.п! Все будет работать если сделать грамотно. И еще: вытаскивайте свои бревна в своих глазах и более спокойно относитесь к другим точкам зрения, способам и методам безопасности файлов! Спасибо.
Это не будет работать, по причинам, которые я описал выше. с таким чмодом индекс не сможет заинклюдить модель. Горите в аду, ламеры. Максим Каракулов видишь? Вот поэтому я сразу посылаю. Потому что проще дурака сразу послать, и не тратить время на попытки объяснить. Потому что все равно не поймет. И все твои розовые теории про "редактирование" и "улучшение" в реальности разбиваются об эту тупость помноженную на самомнение. Тут напалмом надо жечь, а не политес разводить "Ах разрешите, я помарочку в вашем ответе удалю!"
Читайте также: