Есть скрипт, для авторизации администратора
login.php

примечания: 

• при заходе на эту страницу сессия уничтожается (происходит logout).
• пользователь только один - новых регистрировать нельзя

Есть скрипт, для проверки валидности сессии, и для её продлевания
check.php

примечания: 

• globals.php состоит всего из одной строчки, в которой инициализируется время валидности сессии ($session_timeout = 900;)

И есть много страниц самой админки. Посути, страница одна, но от различных значений переменных инклудятся разные скрипты. 
Вопрос такой: нужно ли мне вставлять require "check.php" в каждый скрипт, который потом инклудится в главную страницу, или можно ограничеться только одной главной страницей?

Если есть один скрипт - точка входа, достаточно подключать в нем. 

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

Что если я, не проходя логина, вызову основную страницу следующим образом:



Переменной $session в сессии нет. Не зарегистрирована. Но вы же и не проверяете, что она зарегистрирована. Ваш скрипт спокойно "скушает" ее из GET. Никакой проверки на правдоподобность $session['id'] тоже нет. Хакеру остается только подобрать подходящий таймстемп.

Советую:
*) отключить register_globals
*) различать, откуда приходят переменные ($_GET, $_POST, $_COOKIE, $_SESSION)
*) возможно, добавить проверку на правдоподобность $session['id']

Ну и не стоит одну и ту же функцию get_ip() определять в двух файлах. Подключайте ее из какого-то одного

Добавлено через 10 минут и 58 секунд
Сами логин и пароль тоже безопаснее хранить не зашитыми hardcoded в скрипт, а где-нибудь в конфигурации за пределами DOCUMENT_ROOT или защищенной .htaccess 

Это сообщение отредактировал(а) Golda - 2.7.2007, 00:08

Ну как же... у меня в каждой странице стоит вначале require "check.php";
так что проверка на session[id] всё же есть   

index.html


так что хакеру придётся ещё вычислить md5 от собственного ip   


спасибо за то что указали на дырку. делалось ночию, недоглядел   


а как же другим страницам узнать, что администратор авторизировался?


это всё будет. сейчас главное сделать авторизацию   

Это сообщение отредактировал(а) HackMan - 2.7.2007, 01:13

Ну и что? Ну, попал он в check.php. Там скрипт попытает поднять сессию (session_start()). Переменная $session из сессионных данных не появилась. Но зато она существует благодаря GET-запросу. Поэтому проверка isset($session) будет пройдена. Вторая проверка - тоже не невыполнимая задача.



Да, проверка на session[id] есть. Я проглядела. Но, поверьте, хакеру не сложно будет узнать как свой IP, так и md5()от него. Даже подбор значения по известному хешу md5() часто возможен. А уж прямое преобразование точно проблемы не представляет, если стало ясно, какие данные пользователя искать.

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



Со всеми бывает   



Подключайте check.php вначале, до загрузки остальных модулей. Тогда, если сессия пользователя невалидна, строки



перенаправят пользователя на login.php и завершат работу скрипта. А если уж дальнейшие модули загрузились, значит с авторизацией все в порядке. Остальным модулям ничего и проверять не нужно

Я строчку unset($session) запихнул не в тот скрипт   
Его надо было в check.php. Тогда переменная $session просто обнуляется, и неважно, чем она была раннее передана. А дальше открывается сессия, и если переменная $session не подгругилась из неё, то и проверка isset($session) не будет выполнена.

Но как я понимаю, мне придётся в каждый скрипт прописывать require "check.php" для того чтобы проверить, создана ли сессия. Иначе пользователь просто введёт в строке адреса путь к нужному скрипту, и смысла от авторизации никакой  . Или я не прав?

Да, это решает проблему. Я бы все же отключила register_globals, чтобы не нарваться в дальнейшем на подобные, но... вольному воля   



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

• можно дать подключаяемым модулям специфическое расширение (наример, .inc.php) и запретить в .htaccess доступ к файлам с таким расширением
  
  

  Код

  <files "*.inc.php">     Deny from all  </files>

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

Это сообщение отредактировал(а) Golda - 2.7.2007, 07:47

гениально!   
вобщем, надо через .htaccess запретить доступ к подключаемым скриптам, а в основных писать require "check.php"   

Большое спасибо!

P.S. Жалко, нехватает несколько постов, что бы мог плюсики выставлять...

помнится, в manual-e по PHP учат вместо unset($_SESSION) использовать присваивание: $_SESSION = Array();

А где вы видели, что бы я использовал unset($_SESSION)?

Вот. Извини, не заметил отсутствия прочерка 

Это сообщение отредактировал(а) ilyalyu - 10.7.2007, 23:55