Форум PHP

<? # Файл авторизации: auth.php session_start(); $default_login = 'login'; $default_login = 'pass'; $login = $_REQUEST['login']; $pass = $_REQUEST['pass']; if(isset($login) && isset($pass)) { if($login == $default_login && $pass == $default_pass) $_SESSION['allow'] = true; } ?>

<? session_start(); include "auth.php"; # Файл с содержимым:page.php if($_SESSION['allow'] == true) { # Доступ к контенту } else die(); ?>

Два раза получается session_start()
и include "auth.php"; надо ли делать всегда

<?  # Файл авторизации: auth.php  session_start();  $default_login = 'login';  $default_login = 'pass';  if($_SERVER['REQUEST_METHOD']=='POST'){// проверка     $login = $_POST['login'];      $pass = $_POST['pass'];      if(isset($login) && isset($pass)) {          if($login == $default_login && $pass == $default_pass){              $_SESSION['allow'] = true;          }     } } ?>

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

<iframe>

. А сессия ему к примеру говорит, привет <iframe> - это ещё всего лишь малая-малая вершина айсберга беспечности.
С Ув. Денис.

В коде опечатка:
$default_login = 'login';
$default_login = 'pass';

P.S. К сказанному про <iframe> вопрос: почему так происходит?

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

$login=htmlspecialchars($login);

. Пароль же обязательно должен храниться в базе в зашифрованном, но никогда не в открытом виде. Его нужно зашифровать, верно?

$pass=md5($pass);

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

И это опять же ещё не всё! Всё, что можно проверять - проверяйте. Иногда опасность приходит оттуда, откуда можно было ожидать лишь в последнюю очередь, или не ожидать вообще, что опасность придёт именно оттуда.


С Ув.

А зачем два-три и т.д. раз? md5() - достаточно ресурсоемкая операция, да и смысла повторять её более одного раза - нет.
Если брать за основу код выше:

<?php $default_login = 'login';  $default_login = 'pass';  $login = $_REQUEST['login'];  $pass = $_REQUEST['pass'];

Тот тут пароль как бы равен pass и хэшировать ничего не надо.

И вообще, я не понимаю, зачем $_REQUEST применяют? Если человек должен авторизовываться через форму - то пусть он делает через форму, а никак не через адресную строку.

Да, кстати,
$login=htmlspecialchars($login)
Убирать тэги лучше сразу - зачем совершать лишние операции, когда без них можно обойтись
$login=htmlspecialchars($_REQUEST['login'])

>Да, кстати,
>$login=htmlspecialchars($login)
>Убирать тэги лучше сразу - зачем совершать лишние операции, когда без них можно обойтись
>$login=htmlspecialchars($_REQUEST['login'])

Ну я просто показал принципиальную схему=)

Мне интересно, зачем экранировать специальные символы в присылаемом логине, если значение этого самого логина в вышеприведенном коде (в том, где еще очепятка) нигде не выводится и никуда не записывается?
И как кулхацкер обойдет защиту с помощью <ieframe>?

Или, быть может, я что-нибудь неправильно понял?

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

: Yuriev, да, действительно, одна session_start() лишняя
IceGhost, все правильно понял, фильтрация здесь не нужна, данные ни в БД, ни из БД или куда-либо не сохраняются/не выводятся. Это скорее форма быстрой авторизации для какого-нибудь шелла =)

Т.е такой способ получается безопасный?

P.S Форма авторизации не нужна, потому и $_REQUEST, хотя можно было и $_GET сделать.

Что касается введенных пользователем даных:
1. данные из форм достаточно перед занесением в базу обработать функцией mysql_real_escape_string() (и то, если отключены магические кавычки), а при выводе на экран функцией htmlspecialchars(). (везде)
2. Тщательно фильтровать get параметры регулярными выражениями.
Это защитит от sql-инъекций и hss-атак 90% хакеров.

забыл!
3. Проверять mime типы файлов при загрузке на сервер.

>1. данные из форм достаточно перед занесением в базу обработать функцией mysql_real_escape_string() (и то, если отключены магические кавычки),

Вы думаете этого достаточно?

>а при выводе на экран функцией htmlspecialchars(). (везде)

Только лишь этой функцией? Панацея?:)))

>2. Тщательно фильтровать get параметры регулярными выражениями.
>Это защитит от sql-инъекций и hss-атак 90% хакеров.

1. Вы не забывайте, что когда пусть даже невинная красная шапочка только-только зашла на ваш мегасайт - это тоже GET.
2. Кажысь, регвыры - вспомогательная артиллерия. Чаще всего хватает встроенных РНР-функций. Смотря, что вы там собрались передавать=)))

Вы думаете этого достаточно?

Только лишь этой функцией?

А что еще требуется?

P.S. Это не критика. Я учусь. :)

Зависит от конкретной ситуации:)))

>>1. данные из форм достаточно перед занесением в базу обработать функцией mysql_real_escape_string() (и то, если отключены магические кавычки),
>
>Вы думаете этого достаточно?

от sql инъекций? Да

>>а при выводе на экран функцией htmlspecialchars(). (везде)
>
>Только лишь этой функцией? Панацея?:)))

Хотите сказать недостаточно?

>1. Вы не забывайте, что когда пусть даже невинная красная шапочка только-только зашла на ваш мегасайт - это тоже GET.

Это вы к чему?

если убрать двойной session_start() и полагать, что $_SESSION['allow'] "под контролем", то вполне, ибо в данном случае проверять что-либо не имеет смысла.
единственное, проверку $_SESSION['allow'] == true я бы сделал в auth.php

есть такая штука, как ехеккоманд. Если данные в форме облачить в такие кавычки "`" (на клаве там, где буква "ё"). Команда выполняется. Представим себе такой логин как `format C:`.
и далее строка:
if($login == $default_login && $pass == $default_pass) $_SESSION['allow'] = true;

которая сначала выполнит форматирование диска С, и если оно не возвратило код, идентичный данным в переменной default_login...
Дальше писать?

давайте, чтобы ничего не рушить, Вы попробуете поэкспериментировать с логином `dir`
или, к примеру, `mkdir flag`

когда получится - напишите дальше.

Привет Trianon! Рад тебя видеть. Я на денвере запускал всякие программы так. На серверах это ОБЫЧНО апрещается конфигурацией. Но зачем надеяться на админа? Лучше все-таки подстраховаться.
Для надежности я делаю такую проверку:

$item=str_replace("\`",'&#096;',$item);
$item=stripslashes($item);

То есть, сначала убрать эти кавычки (заслешенные, естественно), а потом уж расслешить.

Даже если для запуска форматирования нужно иметь привелегии root, это не меняет принципа. Что-то другое можно запускать и с другими привелегиями

>Привет Trianon! Рад тебя видеть.
Добрый день, kosta_in_net. Я тоже рад Вас видеть.

>Я на денвере запускал всякие программы так.
Очень хорошо. Значит есть на чем попробовать.
Вот берем денвер.

>На серверах это ОБЫЧНО апрещается конфигурацией. Но зачем надеяться на админа? Лучше все-таки подстраховаться.

Берем денвер с любой конфигурацией.

>Для надежности я делаю такую проверку:

>Даже если для запуска форматирования нужно иметь привелегии root, это не меняет принципа.

И с любыми привилегиями.

Берем вышеобсуждаемый скрипт.

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

Сутки я готов подождать.

Сейчас получилось только через eval($login);
Наверное, я перепутал, так как эксперементировал с этим несколько лет назад. Но я не запускал форматирование диска ;) я открывал блокнот.

>Сейчас получилось только через eval($login);


То есть Вы в форме авторизации - в поле логина написали eval, и скрипт выполнил команду операционной системы?

нет. Я в скрипт добавил евал. После того, как скрипт НЕ выполнил команду системы (с нескльких попыток по разному ее подсунуть), я добавил в скрипт строку

eval($login);

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

>Сейчас получилось только через eval($login);


То есть Вы в поле имени логина написали eval, и скрипт выполнил команду?

kosta_in_net, если проверяем логин, то тогда уже проще с помощью регулярок его проверить:

<? if(!preg_match("/[a-z_0-9]{1,20}/", $item)) die("Логин некорректен"); ?>