Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Можно ли узнать, как вызван скрипт?
 
 автор: Владимир55   (30.12.2011 в 19:28)   письмо автору
 
 

В штатном режиме РНР файл вызывается вот таким образом:
<script type="text/javascript" src="hide.php"></script>


Можно ли в самом hide.php прописать какой-то код и с его помощью проконтролировать, что файл hide.php был вызван именно так, а не из адресной строки?

(Вариант формирования на странице РНР переменной флага и последующий её контроль в файле hide.php не очень подходит).

  Ответить  
 
 автор: cheops   (30.12.2011 в 19:32)   письмо автору
 
   для: Владимир55   (30.12.2011 в 19:28)
 

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

PS Даже если бы был какой-то флаг, его бы все-равно подделывали.

  Ответить  
 
 автор: Владимир55   (30.12.2011 в 19:41)   письмо автору
 
   для: cheops   (30.12.2011 в 19:32)
 

PS Даже если бы был какой-то флаг, его бы все-равно подделывали.

В коде страницы, из которой вызываем этот файл, пишем:
<?php $flag "YES"?>


А в вызванном РНР файле проверяем состояние переменной $flag.

О самом её существоании никто знать не может, а потому никак и не подделает. Верно?

Нюанс в том, что переменная $flag при вызове через скрипт не передается! А должна передаваться? Или она и не должна передаваться?

  Ответить  
 
 автор: cheops   (30.12.2011 в 19:45)   письмо автору
 
   для: Владимир55   (30.12.2011 в 19:41)
 

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

  Ответить  
 
 автор: Владимир55   (30.12.2011 в 21:56)   письмо автору
 
   для: cheops   (30.12.2011 в 19:45)
 

А не поможет ли
$_SERVER['HTTP_REFERER']

  Ответить  
 
 автор: cheops   (30.12.2011 в 22:19)   письмо автору
 
   для: Владимир55   (30.12.2011 в 21:56)
 

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

  Ответить  
 
 автор: Владимир55   (30.12.2011 в 22:22)   письмо автору
 
   для: cheops   (30.12.2011 в 22:19)
 

Не все посылают его

В смысле, не все браузеры посылают рефферер?

  Ответить  
 
 автор: cheops   (30.12.2011 в 23:01)   письмо автору
 
   для: Владимир55   (30.12.2011 в 22:22)
 

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

PS Хотя когда я в последний раз возился со снифером, JavaScript-файлы сопровождались реферером.

  Ответить  
 
 автор: deimand   (30.12.2011 в 23:28)   письмо автору
 
   для: Владимир55   (30.12.2011 в 19:28)
 

Скрыть то код можно, но firebug все равно покажет все что было загружено в браузер, если честно открыть страницу Вашего сайта. Поэтому защита скрипта будет работать только от тех, кто не знает что такое firebug. Она Вам действительно так нужна? Хорошее сокрытие кода повысит нагрузку на сервер, а результата ведь ноль. Правда для тех кто не знает что такое firebug, получение javascript кода можно сделать непроходимым квестом.

  Ответить  
 
 автор: cheops   (30.12.2011 в 23:42)   письмо автору
 
   для: deimand   (30.12.2011 в 23:28)
 

Да и без FireBug можно обойтись... исходный код можно посмотреть не через контекстное, а через обычное меню или клавиатурное сокращение. В конце концов его можно просто в кэше на диске найти. Любой пользователь с 3 годами стажа, без знания программирования и плагинов - упрет любой текст с любой страницы (ну с флешкой может повозиться чуть-чуть подольше). Единственное, надежное средство - лень пользователя :))), но если пользователь завелся - пиши пропало.

  Ответить  
 
 автор: deimand   (31.12.2011 в 01:44)   письмо автору
 
   для: cheops   (30.12.2011 в 23:42)
 

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

Я конечно не знаю на счет кэша, не пробовал, но хочу провести эксперемент. Не подскажете где примерно кэш скриптов искать? В папке программы? В моем случае мозиллы, значит в Programm Files/Mozilla Firefoz, правильно?

Пока проверял так. Подключил внешний скрипт с объявленной переменной с уникальным именем. Нашел в указанной папке в под под под папке с именем cache.

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

А использовал я
createElement('script')
appendChild
removeChild

  Ответить  
 
 автор: cheops   (31.12.2011 в 13:00)   письмо автору
 
   для: deimand   (31.12.2011 в 01:44)
 

>В моем случае мозиллы, значит в Programm Files/Mozilla Firefoz, правильно?
Вряд ли там, про Mozilla не скажу, а Opera хранит примерно тут
Documents and Settings/User/Local Settings/Application Data/Opera/Opera/opcache
Для FireFox, нужно рыться примерно тут
Documents and Settings/User/Local Settings/Application Data/Mozilla/Firefox/Profiles/ - по-крайней мере JavaScript-ы я там вижу (понятно они идут вперемешку с изображениями и по названию файла сориентироваться не удасться, но поискать там стоит).

  Ответить  
 
 автор: Владимир55   (02.01.2012 в 23:52)   письмо автору
 
   для: cheops   (31.12.2011 в 13:00)
 

Показалось интересным такое решение.

В вызывающем файле заносим в сессию время вызова (можно в мкс), а в скрипте его сравниваем с тем, какое было при предыдущем вызове.

Если значения совпадают, то это значит, что файл открывают из адресной строки.

(Если браузер закрывали, то совпадают нулевые значения. Если хотя бы одна копия остается открытой, то совпадают последний значения из вызова через <script>).

Вроде, работает...

  Ответить  
 
 автор: cheops   (03.01.2012 в 00:34)   письмо автору
 
   для: Владимир55   (02.01.2012 в 23:52)
 

Ммм... не очень понятно. Допустим мы в главном HTML/PHP-файле поставили метку, браузер начинает загружать скрипты из <script> и вы при обращении к этим файлам видите, что они загружаются позже. Но так ведь если пользователь откроет HTML/PHP-файл, посмотрит исходный код и вызовет скрипт - вы тоже зафиксируете более позднюю временную метку...

  Ответить  
 
 автор: Владимир55   (03.01.2012 в 11:46)   письмо автору
 
   для: cheops   (03.01.2012 в 00:34)
 

На главном HTML/PHP-файле проинклюдил
<?php
    
// Посылаем в сессии время открытия страницы

    
ob_start();
    
session_start();
    
$_SESSION['start'] = time ();
    echo 
chr(13).chr(10) . '<script type="text/javascript" src="grenada.php"></script>';


А в файле grenada.php
<?php
    
// Скрипт формирования защитного кода
    // В сессии получаем время запуска скрипта с тематической страницы.
    // Если это время совпадает со временем предыдущего вызова, то имеет место
    // самостоятельный запуск этого файла из адресной строки с целью считывания защитного кода
    // В этом случае код не показывается.

    
ob_start();
    
session_start();
    
$start $_SESSION['start'];
    
$start_old $_SESSION['start_old'];

    if (
$start == $start_old$flag "VZLOM";
    else 
$flag "NO";

    
$_SESSION['start_old'] = $start;

    if (
$flag == "NO")  // Защита используется по назначению. Продолжаем. 

  Ответить  
 
 автор: cheops   (03.01.2012 в 16:20)   письмо автору
 
   для: Владимир55   (03.01.2012 в 11:46)
 

Все равно не понимаю, пользователь сначала откроет HTML/PHP, все загрузиться, заполняться переменные $_SESSION['start'] и $_SESSION['start_old'], посмотрит исходный код и обратиться к grenada.php, время будет опять другое и все ему должно выдастся. Он же в этом же самом браузере скорее всего будет код просматривать. Вот с другого сайта использовать ваши скрипты уже не смогут (вы, кстати, сами в такую ситуацию можете попасть, если будете производить горизонтальное масштабирование).

  Ответить  
 
 автор: Владимир55   (03.01.2012 в 19:22)   письмо автору
 
   для: cheops   (03.01.2012 в 16:20)
 

У нас же задача - проконтролировать, что скрипт вызван не из адресной строки, а посредством
<script type="text/javascript" src="hide.php"></script> 


Вот этот контроль мы здесь и осуществляем с помощью флага.

За счет этого контроля невозможно прочитать отображаемое содержимой файла grenada.php, запустив его через браузер из адресной строки, ибо в этом случае оно скрыто.

А когда этот файл вызывается в теле основной HTML/PHP страницы, то содержащийся в файле grenada.php JS код просто исполнится, но в HTML коде страницы его не видно, поскольку это директивы самому браузеру.

  Ответить  
 
 автор: cheops   (03.01.2012 в 19:50)   письмо автору
 
   для: Владимир55   (03.01.2012 в 19:22)
 

Я к тому, что пользователь очень редко помнит на изучить пути к JS/CSS файлам, он скорее всего сначала все-таки откроет HTML/PHP, чтобы посмотреть путь, а это запустит механизм доступа. Так как домен не меняется, то сессия останется в порядке и будет работать так, как для обычно страницы.

  Ответить  
 
 автор: deimand   (05.01.2012 в 04:05)   письмо автору
 
   для: cheops   (03.01.2012 в 19:50)
 

.

  Ответить  
 
 автор: deimand   (03.01.2012 в 14:07)   письмо автору
23.6 Кб
 
   для: Владимир55   (30.12.2011 в 19:28)
 

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

.htaccess
 AddHandler application/x-httpd-php .css


index.php
<?php
  session_start
();
?><html>

<head>
  <title></title>
</head>

<body>

<?php
 $_SESSION
['javascript'] = true;
?>
<script>
  // этот скрипт желательно получше запрятать
  var script=document.createElement('script');
  script.setAttribute('type','text/javascript');
  script.setAttribute('src','comments.css');
  // применить скрипт
  document.body.appendChild(script);
  // сразу же уничтожить примененный тег script 
  document.body.removeChild(script);
</script>

<a href="index.css">Теперь посмотреть скрипт</a>
</body>

</html>


comments.css
<?php

 session_start
();

 if (isset(
$_SESSION['javascript']))
 {
   
// обязательно блокировать последующие обращения
   
unset($_SESSION['javascript']);

   
// сам скрипт
   
?>
   alert('Все работает! И до этого скрипта просто так не добраться)');
   <?php
 
}
 else
 {
   
// с понтом на jquery
   // лучше держать экземпляр у себя на сервере, вдруг по этому адресу ее удалят
   
echo file_get_contents('http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js');
 }
?>

  Ответить  
 
 автор: Владимир55   (03.01.2012 в 14:32)   письмо автору
 
   для: deimand   (03.01.2012 в 14:07)
 

Высший пилотаж!

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования