|
|
|
| В штатном режиме РНР файл вызывается вот таким образом:
<script type="text/javascript" src="hide.php"></script>
|
Можно ли в самом hide.php прописать какой-то код и с его помощью проконтролировать, что файл hide.php был вызван именно так, а не из адресной строки?
(Вариант формирования на странице РНР переменной флага и последующий её контроль в файле hide.php не очень подходит). | |
|
|
|
|
|
|
|
для: Владимир55
(30.12.2011 в 19:28)
| | Дело в том, что браузер к нему обращается таким образом, что не отличишь, это он его подгружает для отображения основной страницы или пользователь вбил имя в строку запроса. Никак нельзя эти состояния отличить.
PS Даже если бы был какой-то флаг, его бы все-равно подделывали. | |
|
|
|
|
|
|
|
для: cheops
(30.12.2011 в 19:32)
| | PS Даже если бы был какой-то флаг, его бы все-равно подделывали.
В коде страницы, из которой вызываем этот файл, пишем:
А в вызванном РНР файле проверяем состояние переменной $flag.
О самом её существоании никто знать не может, а потому никак и не подделает. Верно?
Нюанс в том, что переменная $flag при вызове через скрипт не передается! А должна передаваться? Или она и не должна передаваться? | |
|
|
|
|
|
|
|
для: Владимир55
(30.12.2011 в 19:41)
| | Нет. PHP-флаг вы действительно можете скрыть, но для того, чтобы им воспользоваться, вы должны узнать у Web-сервера как был вызван файл со стороны клиента. Он не знает - для него все вызовы едины. Однако, даже, если бы он знал и требовал бы от клиентов сообщать при помощи специального флага, как кто вызывает файл, сам браузер или пользователь, то вот такой бы флаг было бы очень просто подделать (со стороны клиента все подделывается). А ситуация еще хуже, даже флага такого нет - т.е. кто там вызывал на самом деле этот файл - не известно. | |
|
|
|
|
|
|
|
для: cheops
(30.12.2011 в 19:45)
| | А не поможет ли
| |
|
|
|
|
|
|
|
для: Владимир55
(30.12.2011 в 21:56)
| | Не все посылают его и подделать можно, хотя можно попробовать, обычно при загрузке JavaScript-файлов HTTP_REFERER отправляется клиентом. Если же от потери JavaScript-библиотеки ничего страшного не будет (т.е. если это библиотека защиты от копирования), то вообще можно смело пробовать: максимум что грозит клиентам: страница не будет защищена от копирования. | |
|
|
|
|
|
|
|
для: cheops
(30.12.2011 в 22:19)
| | Не все посылают его
В смысле, не все браузеры посылают рефферер? | |
|
|
|
|
|
|
|
для: Владимир55
(30.12.2011 в 22:22)
| | Они не обязаны это делать, более того, пользователь может заблокировать такую возможность, сейчас вроде такого нет, но некоторое время назад было модно блокировать реферер при помощи FireWall, возможно и до сих пор некоторые FireWall-ы или антивирусы могут так поступать. В общем, это довольно ненадежный канал.
PS Хотя когда я в последний раз возился со снифером, JavaScript-файлы сопровождались реферером. | |
|
|
|
|
|
|
|
для: Владимир55
(30.12.2011 в 19:28)
| | Скрыть то код можно, но firebug все равно покажет все что было загружено в браузер, если честно открыть страницу Вашего сайта. Поэтому защита скрипта будет работать только от тех, кто не знает что такое firebug. Она Вам действительно так нужна? Хорошее сокрытие кода повысит нагрузку на сервер, а результата ведь ноль. Правда для тех кто не знает что такое firebug, получение javascript кода можно сделать непроходимым квестом. | |
|
|
|
|
|
|
|
для: deimand
(30.12.2011 в 23:28)
| | Да и без FireBug можно обойтись... исходный код можно посмотреть не через контекстное, а через обычное меню или клавиатурное сокращение. В конце концов его можно просто в кэше на диске найти. Любой пользователь с 3 годами стажа, без знания программирования и плагинов - упрет любой текст с любой страницы (ну с флешкой может повозиться чуть-чуть подольше). Единственное, надежное средство - лень пользователя :))), но если пользователь завелся - пиши пропало. | |
|
|
|
|
|
|
|
для: cheops
(30.12.2011 в 23:42)
| | Я всегда был уверен, что скрипты можно уничтожать сразу после подгрузки и их никто не увидит без прослушки сети. Одним скриптом беру другой срипт, исполняю, уничтожаю.
Я конечно не знаю на счет кэша, не пробовал, но хочу провести эксперемент. Не подскажете где примерно кэш скриптов искать? В папке программы? В моем случае мозиллы, значит в Programm Files/Mozilla Firefoz, правильно?
Пока проверял так. Подключил внешний скрипт с объявленной переменной с уникальным именем. Нашел в указанной папке в под под под папке с именем cache.
После чего создал еще один внешний скрипт с уже другой уникальной переменной и исполнил его с помощью скрипта, а затем уничтожил. Поиск имени этой переменной уже не дал результатов, а на странице переменная видна.
А использовал я
createElement('script')
appendChild
removeChild
|
| |
|
|
|
|
|
|
|
для: 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-ы я там вижу (понятно они идут вперемешку с изображениями и по названию файла сориентироваться не удасться, но поискать там стоит). | |
|
|
|
|
|
|
|
для: cheops
(31.12.2011 в 13:00)
| | Показалось интересным такое решение.
В вызывающем файле заносим в сессию время вызова (можно в мкс), а в скрипте его сравниваем с тем, какое было при предыдущем вызове.
Если значения совпадают, то это значит, что файл открывают из адресной строки.
(Если браузер закрывали, то совпадают нулевые значения. Если хотя бы одна копия остается открытой, то совпадают последний значения из вызова через <script>).
Вроде, работает... | |
|
|
|
|
|
|
|
для: Владимир55
(02.01.2012 в 23:52)
| | Ммм... не очень понятно. Допустим мы в главном HTML/PHP-файле поставили метку, браузер начинает загружать скрипты из <script> и вы при обращении к этим файлам видите, что они загружаются позже. Но так ведь если пользователь откроет HTML/PHP-файл, посмотрит исходный код и вызовет скрипт - вы тоже зафиксируете более позднюю временную метку... | |
|
|
|
|
|
|
|
для: 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") // Защита используется по назначению. Продолжаем.
|
| |
|
|
|
|
|
|
|
для: Владимир55
(03.01.2012 в 11:46)
| | Все равно не понимаю, пользователь сначала откроет HTML/PHP, все загрузиться, заполняться переменные $_SESSION['start'] и $_SESSION['start_old'], посмотрит исходный код и обратиться к grenada.php, время будет опять другое и все ему должно выдастся. Он же в этом же самом браузере скорее всего будет код просматривать. Вот с другого сайта использовать ваши скрипты уже не смогут (вы, кстати, сами в такую ситуацию можете попасть, если будете производить горизонтальное масштабирование). | |
|
|
|
|
|
|
|
для: cheops
(03.01.2012 в 16:20)
| | У нас же задача - проконтролировать, что скрипт вызван не из адресной строки, а посредством
<script type="text/javascript" src="hide.php"></script>
|
Вот этот контроль мы здесь и осуществляем с помощью флага.
За счет этого контроля невозможно прочитать отображаемое содержимой файла grenada.php, запустив его через браузер из адресной строки, ибо в этом случае оно скрыто.
А когда этот файл вызывается в теле основной HTML/PHP страницы, то содержащийся в файле grenada.php JS код просто исполнится, но в HTML коде страницы его не видно, поскольку это директивы самому браузеру. | |
|
|
|
|
|
|
|
для: Владимир55
(03.01.2012 в 19:22)
| | Я к тому, что пользователь очень редко помнит на изучить пути к JS/CSS файлам, он скорее всего сначала все-таки откроет HTML/PHP, чтобы посмотреть путь, а это запустит механизм доступа. Так как домен не меняется, то сессия останется в порядке и будет работать так, как для обычно страницы. | |
|
|
|
|
|
|
|
для: cheops
(03.01.2012 в 19:50)
| | . | |
|
|
|
|
 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');
}
?>
|
| |
|
|
|
|
|
|
|
для: deimand
(03.01.2012 в 14:07)
| | Высший пилотаж! | |
|
|
|