Виды уязвимостей и правила безопасного программирования на PHP

[Лев]

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

Виды уязвимостей PHP

1. Демонстрация ошибок пользователю
Смысл: при каких-либо ошибках в коде пользователю выводиться информация об произошедшей ошибке. Не является критичной уязвимостью, но поваляет взломщику получить дополнительную информацию о структуре и работе сервера.
2. Доступность данных о характеристиках системы пользователю
Смысл: пользователь может получить доступ к данным, дающим представление о системе. Не является критичной уязвимостью, но поваляет взломщику получить дополнительную информацию о структуре и работе сервера. Причина этой уязвимости в ошибках и «недосмотрах» программиста. Примером может служить наличие файла phpinfo.php с одноимённой функцией в свободном доступе.
3. Доступность данных о программном коде пользователю
Смысл: пользователь может получить доступ к программным кодам модулей, имеющих расширение, отличное от php. Является критичной уязвимостью, так как позваляет взломщику получить достаточно полную информацию о структуре и работе сервера, выявить его уязвимости.
4. Простые пароли для доступа к административным страницам
Смысл: взломщик может подобрать простой пароль к административной странице, дающей ему больше возможностей для взлома. Является критичной уязвимостью, так как позваляет взломщику повлиять на работу сервера.
5. Возможность задания глобальных переменных
Смысл: при неправильных настройках PHP имеется возможность задавать глобальные переменные скрипта, через строку запроса. Является критичной уязвимостью, так как взломщик может влиять на ход работы скрипта в свою пользу.
6. PHP-инъекция
Смысл: в параметр, определяющий работу PHP с файлами или программным кодом, передаётся ссылка на сторонний программный код или сам код. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере. Выполнение кода осуществляется при помощи функций: eval(), preg_replace(), require_once(), include_once(), include(), require(), create_function(), readfile(), dir(), fopen().
7. PHP-инъекция через загрузку файлов
Смысл: при возможности задании глобальных переменных в параметр, определяющий загружаемый на сервер файл, передаётся ссылка на сторонний программный код или конфиденциальный файл на сервере. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере или получить доступ к конфиденциальным данным. Данная уязвимость возможна только при возможности задания глобальных переменных и неверной организации механизма загрузки файлов.
8. e-mail-инъекция
Смысл: в параметр, определяющий работу PHP с электронными письмами, передаётся ссылка на сторонний программный код или сам код. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере или получить доступ к данным, хранимым у пользователя.
9. SQL-инъекция
Смысл: в параметр, определяющий SQL-запрос, передаётся данные, образующее запрос для доступа к закрытым данным. Является критичной уязвимостью, так как взломщик может получить конфиденциальные данные, хранимые в базе данных. Для изменения запроса взломщик может использовать следующие конструкции: SELECT, UNION, UPDATE, INSERT, OR, AND.
10. Межсайтовый скриптинг или XSS
Смысл: в параметр, определяющий выводимые пользователю данные, передаётся сторонний программный код. Является критичной уязвимостью, так как взломщик может получить конфиденциальные данные, хранимые в браузере клиента. Для изменения запроса взломщик использует html-теги.


Правила написания безопасного кода на PHP

1. Блокирование вывода ошибок
Для этого достаточно в программном коде задать error_reporting(0) или в файле .htaccess добавить строку php_flag error_reporting 0
2. Использование сложных паролей для доступа к административным страницам
Для этого достаточно использовать многозначные пароли, не имеющие семантического значения (например, К7O0iV98dq).
3. Логирование критических действий пользователя
Не обеспечивает защиту напрямую, но позволяет выявить взломщиков и определить уязвимости, которые они использовали. Для этого действия пользователя и переданные им данные, которые касаются критических моментов работы системы, достаточно записывать в обычный текстовый файл.
Пример функции логирования и её работы:
function writelog($typelog, $log_text) {
$log = fopen('logs/'.$typelog.'.txt','a+');
fwrite($log, "$log_textrn");
fclose($log);
}
writelog('authorization', date("y.m.d H:m:s")."t".$_SERVER['REMOTE_ADDR']."tУспешный вход");
4. Закрытие доступа к модулям сайта
Обеспечивает защиту от попыток просмотра их содержимого или выполнения. Для этого достаточно в файле .htaccess настроить доступ к файлам модулей при помощи конструкций FilesMatch и Files.
Например, мы закрываем доступ ко всем модулям с расширением php, кроме файла capcha.php:
Order Deny,Allow

Deny from all


Allow from all


Отключение возможности задания глобальных переменных
Для этого достаточно в настройках сервера задать register_globals = off; или в файле .htaccess добавить строку php_flag register_globals off. Использование ini_set('register_globals',0); проблему не решит так, как переменные задаются до начала выполнения скрипта.
Отключение возможности использования удаленных файлов

Для этого достаточно в настройках сервера задать allow_url_fopen = off;. Это обеспечивает частичную защиту от PHP-инъекций, но не полную, так как взломщик может передавать не ссылку на файл с программным кодом, а сам программный код. Для полной защиты от PHP-инъекций необходимо дополнительно использовать фильтрацию поступивших данных. Иногда данную меру защиты невозможно использовать из-за особенностей работы проекта (нужно обращаться к удалённым файлам).
Фильтрация поступающих данных
Обеспечивает защиту от большенства уязвимостей. Универсального решения не существует. Желательно использовать проверку по «белому» списку символов в совокупности с проверкой на запрещённые слова. «Белым» называется список разрешенных символов. В этот список не должны входить опасные символы, например, <>. К запрещённым словам можно отнести: script, http, SELECT, UNION, UPDATE, exe, exec, INSERT, tmp, а также html-теги.
Пример фильтрации поступающих данных:
// Проверка по белому списку. Допускаются только русские и латинские буквы, цифры и знаки _-
if (preg_match("/[^(w)|(А-Яа-я-)|(s)]/",$text)) {
$text = '';
}
// Фильтрация опасных слов
if (preg_match("/script|http|<|>|<|>|SELECT|UNION|UPDATE|exe|exec|INSERT|tmp/i",$text)) {
$text = '';
}
Проверка на загрузку файла при помощи HTTP POST
Обеспечивает защиту от PHP-инъекций через загрузку файлов. Для обеспечения этого загруженные на сервер файлы необходимо проверять функцией is_uploaded_file() или перемещать функцией move_uploaded_file(). Данный вид защиты можно не использовать, если отключена возможность задания глобальных переменных.
Экранирование символов кавычек данных, передаваемых в базу данных
Обеспечивает защиту от SQL-инъекций. Наиболее оптимальным методом является обработка всех поступивших не числовых данных с помощью функции mysql_real_escape_string(). Можно так же использовать автоматическое экранирование, поступающих данных. Для этого достаточно в файле .htaccess добавить строку php_value magic_quotes_gpc on, но этот способ не является надёжным, так как может привести к двойному экранированию.
Пример экранирования кавычек с помощью функции mysql_real_escape_string():
if (!is_numeric($text)) {
$textrequest = mysql_real_escape_string($text);
}

Преобразование специальных символов в html-сущности перед выводом
Обеспечивает защиту от XSS. Для этого данные, введенные пользователем, которые могут содержать нежелательные html-тэги, при выводе достаточно обработать функцией htmlspecialchars(). Данный вид защиты можно не использовать, если фильтрация поступающих данных отсеивает опасные html-тэги.


Как видите создание продуманной системы безопасности скриптов не такое трудоёмкое дело.
Данная статья не претендует на роль учебника по безопасности скриптов, но Я надеюсь, что она подтолкнёт php-программистов использовать более продуманные методы защиты.

И еще немного на эту тему

Статус Error с 99% точностью говорит о том, что в данном месте есть XSS или SQL Injection уязвимость.
Строка кода с таким статусом может выглядеть например так:

echo $_GET['name'];

В такой ситуации при передаче в адресной строке параметра name таким образом &name= вы выделите болдом весь текст следующий за echo на сайте. Примеры могут быть и страшнее, вот один из них:

mysql_query("SELECT * FROM users WHERE user_id = ".$_GET['id']);

И если параметр в адресной строке будет выглядеть так &id=(DROP TABLE users) то такой запрос удалит таблицу users с вашего сайта. Такая атака называется SQL Injection.

Защитой в таких ситуациях является проверка получаемых от пользователя данных. В первом случае можно применить такие функции:

echo htmlentities(addslashes($_GET['name']));

А во втором случае целесообразно будет сделать так:

mysql_query("SELECT * FROM users WHERE user_id = ".intval($_GET['id']));

Сделав такие действия вы защитите свой сайт от такой уязвимости.

 

[Лев]

вот еще по поводу защиты htaccess
типа такого содержимого у вас должно быть прописано в htaccess

# защита файла .htaccess
<Files .htaccess>
order allow,deny
deny from all
</Files>
# непосредствено rewriting
DirectoryIndex index.php
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^(/component/option,com) [NC,OR]
RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|/[^.]*)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
# Защита от уязвимостей
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

 

[hans]

вот еще по поводу защиты htaccess
типа такого содержимого у вас должно быть прописано в htaccess
# защита файла .htaccess
...

Неплохо было бы прокомментировать каждую строчку для большего знания того, что вставляем в htaccess :rolleyes:

 

[t3s]

В такой ситуации при передаче в адресной строке параметра name таким образом &name= вы выделите болдом весь текст следующий за echo на сайте. Примеры могут быть и страшнее, вот один из них:

mysql_query("SELECT * FROM users WHERE user_id = ".$_GET['id']);

И если параметр в адресной строке будет выглядеть так &id=(DROP TABLE users) то такой запрос удалит таблицу users с вашего сайта. Такая атака называется SQL Injection.

вообще-то любой запрос который инициирует модификацию данных на сервере следует передавать исключительно методом POST
причем еще до того как фильтровать наличие "опасных" конструкций советую проверить реферер, поскольку POST не панацея а лишь дополнение к тому что написал ТС

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

хотя с другой стороны, если бы не было быдлокодеров - не было бы и форумов подобного этому

 

[Evilidze]

ну-ка удиви меня чем плох GET?

 

[CTAPu4OK]

Тоже хотел подобное спросить... потом прочитал внимательнее

вообще-то любой запрос который инициирует модификацию данных на сервере

Ну я еще не видел подобных программистов) поддержу, желательно все параметры передавать через пост
ибо:
1. Адресная строка имеет лимит символов
2. с $_POST происходит более защищенная передача данных (нубо защита))

В остальном, гет от пост не чем не отличаются.

 

[t3s]

зачем мне удивлять? - ведь выше указан пример для удивления :rolleyes:

предположим, что некий "суперпупертипакодер" меняет в своем скрипте емайлы или пароли по принципу как в примере:

mysql_query("UPDATE email SET email="$_GET['email']" WHERE user_id = ".$_GET['id']);

дальше продолжать?

и в свою очередь попрошу удивить меня в ответ - надеюсь имею право? :rolleyes:

можно ли продемонстрировать хотя бы один более-менее известный сайт или движок, в котором важные данные передаются методом GET?

з.ы.
пока набирал ответ, CTAPu4OK опередил...

 

[Evilidze]

а так же не внимательно прочитал)
да все важные данные POST а такие типо otdel='5' в POST можно не пихать)

 

[Met]

главное не как передаешь, а как фильтруешь.

использую такой код для фильтрации текстовых переменных:

function check($str) {
    $str = htmlentities(trim($str), ENT_QUOTES, 'UTF-8');
    $str = nl2br($str);
    $str = strtr($str, array (
        chr(0)=> '',
        chr(1)=> '',
        chr(2)=> '',
        chr(3)=> '',
        chr(4)=> '',
        chr(5)=> '',
        chr(6)=> '',
        chr(7)=> '',
        chr(8)=> '',
        chr(9)=> '',
        chr(10)=> '',
        chr(11)=> '',
        chr(12)=> '',
        chr(13)=> '',
        chr(14)=> '',
        chr(15)=> '',
        chr(16)=> '',
        chr(17)=> '',
        chr(18)=> '',
        chr(19)=> '',
        chr(20)=> '',
        chr(21)=> '',
        chr(22)=> '',
        chr(23)=> '',
        chr(24)=> '',
        chr(25)=> '',
        chr(26)=> '',
        chr(27)=> '',
        chr(28)=> '',
        chr(29)=> '',
        chr(30)=> '',
        chr(31)=> ''
    ));

    $str = str_replace("\'", "'", $str);
    $str = str_replace('\\', "\", $str);
    $str = str_replace("|", "I", $str);
    $str = str_replace("||", "I", $str);
    $str = str_replace("/\\\$/", "$", $str);
    $str = mysql_real_escape_string($str);
    return $str;
}

у кого какое мнение насчет кода?

 

[UnDeaD]

я думаю руки нужно отрывать тем, кто пишет сообщения аналогичные твоим

хотя с другой стороны, если бы не было быдлокодеров - не было бы и форумов подобного этому

вот это самооценка! респект!

[/QUOTE]

предположим, что некий "суперпупертипакодер" меняет в своем скрипте емайлы или пароли по принципу как в примере:

я меняю, внутри условий, дальше что? что-то не так в этом коде, кроме двух пропущенных точек и двух одинарных скобок ?


2 Met
[/QUOTE]

у кого какое мнение насчет кода?

смотря для каких нужд тебе нужен этот текст, и что ты собираешься в нем вообще хранить, и чего тебе вообще не жалко отрезать


P.S. чуть не забыл! Изюм написал эпическую статью про безопасность! В каком городе будем ему ставить памятник?!

 

[Met]

2 Met
смотря для каких нужд тебе нужен этот текст, и что ты собираешься в нем вообще хранить, и чего тебе вообще не жалко отрезать

для фильтрации всех строковых переменных, а дальше, если надо применяю грубую фильтрацию с помощью регулярки.

 

[rutrum]

Данные в базу надо писать именно так, как прислал их пользователь (со всеми спецсимволами ) - фильтровать и модифицировать только при выводе в браузер, чтобы xss не прошла. Фильтровать до занесения в базу необходимо только для указания на ошибку при вводе данных, типа, пароль меньше 8 символов или некорректное мыло и т. д, чтобы юзверь знал, что ошибся. А для фильтрации юзаем всякие функции: is_***, filter_var, ***val - для 95% случаев они отлично подходят, а для оставшихся 5% сочиняем регулярки.

for ex. (авторизация на PDO):

$db = new PDO ('mysql:host=localhost;dbname=***', '***', '***');
$db_t = $db->prepare("SELECT id FROM `user` WHERE email = ? AND pass = ?");
$db_t->execute(array($_POST['mail'], md5($_POST['password'] . $system['salt'])));
$userinfo = $db_t->fetchAll();

В данно примере $_POST'ы никак не фильтруются, но и создать опасную ситуацию они не могут, ибо юзаются плейсхолдеры (там, где мд5 - и фильтровать и не надо :rolleyes: ).
И, кстати, скоро уберут из пыхи драйвер mysql_, оставят толко mysqli и PDO, так что думаю, самое время начать изучать что-то из этого - что на много облегчит жизнь .

 

[t3s]

UnDeaD, изначально хотел лишь немного дополнить ТС, без перехода на личности... но если пошли фразы про мою самооценку и про мои руки то отвечу, по порядку

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

нет не все
проверка реферера - это лишь один из элементов, который не исключает а дополняет указанныю выше советы... если ты считаешь это лишним - желаю удачи в написании "безопасных" скриптов B)
напомню кстати один из первых багов в БК - так называемый неблогируемый удар по заду... он стал возможен из-за того что разрабы БК рассуждали точно так же как ты

вот это самооценка! респект!

честно говоря мне пох на твою иронию... взамен дам лишь немного советов по твоему сайту:

1. НИКОГДА не делай проверки на джаваскрипт - джаву можно использовать лишь для подсказок, не более... все входящие данные проверяй на стороне сервера, а у тебя сейчас любой посетитель с отключенным джаваскриптом видит структуру передаваемого массива

2. все же поставь проверку на реферер
а то я отправляю тебе заказ со своего ЛОКАЛЬНОГО сервера и получаю в ответ

Array
(
    [domain] => 
    [name] => 
    [target] => 
    [activity] => 
    [target_group] => 
    [needle] => Общий макет дизайна 
    [gamma] => Светлая
    [solution] => Только сплошные цвета
    [graphics] => Небольшая
    [style] => Деловой
    [type] => Резиновый
    [structure] => Блочная
    [form] => Квадратная
    [logo] => Нет
    [ca] => Да
    [ba] => Нет
    [conc] => Да
    [variants] => 1
    [rubricator] => 
    [like] => 
    [addit] => 
    [email] => 
    [contacts] => 
    [keystring] => 
    [btn] => Сгенерировать
)

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

3. не следует пренебрегать даже самыми элементарными фильтрами - к примеру ты почему-то пропускаешь конструкции вроде

<script>alert()</script>

а это потенциальная XSS

4. никогда не делай выводы о чьей-то квалификации на основе даты реги, репы, постов и т.д. - вобщем не поступай так как это делают на серче

 

[UnDeaD]

проверка реферера ..... если ты считаешь это лишним

конечно считаю. не вижу в нем вообще никакого смысла. для параноиков вообще через https нужно уж все делать

взамен дам лишь немного советов по твоему сайту:

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

 

[t3s]

хочу поделиться соображениями по поводу загрузки файлов - вроде как данный вопрос не был затронут, а ведь загрузка файлов - отличная лазейка для злоумышленника, верно? - да и тема будет развиваться и пополняться инфой а не флеймом

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


вначале проверим реферер
зачем это нам нужно?
во-первых, мы должны быть уверены, что полученные данные пришли не непонятно откуда извне (где их можно изменить), а с нашей собственной формы и нашего собственного домена
во-вторых, давайте представим на минутку, что злобный китайский хаЦкер Сунь Уй в Чай скопировал на свой сервак нашу форму, после чего шлет нам каждую секунду по мегабайтному файлу... пару сотен китайцев запросто положат сервер - оно нам надо?

вариантов реализации туева хуча, например так:

$ref=getenv("HTTP_REFERER");
$ref = explode("/", $ref);
$base = $ref[2];

возможно кому-то покажется проще "отрезать" протокол от УРЛ - не спорю, будет работать немного быстрее... но вариант с массивом мне нравится тем что позволяет гибко работать с любой частью УРЛ-а

вобщем если $base равен имени домена - работаем дальше, иначе что-то думаем...


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

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

$imageinfo = getimagesize($_FILES['filename']['tmp_name']);
type = $imageinfo['mime'];

проверяем расширение

function getExtension($filename) {
    $path_info = pathinfo($filename);
    return $path_info['extension'];
  }

$imageext = getExtension($_FILES['filename']['name']);

сейчас файл находится во временной папке за пределами нашей рабочей категории... казалось бы если тип и расширение совпали то все нормально, можно переносить в uploads (или files, или images - в общем в каталог для загрузок)

но вспомним, что самый примитивный шелл помещается в 20 байт:

<? system($_GET["cmd"]); ?>

другими словами злоумышленник с определенным уровнем знаний может разместить его среди метаданных картинки

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

function image_resize(
    $source_path, 
    $destination_path, 
    $newwidth,
    $newheight = FALSE, 
    $quality = FALSE // качество для формата jpeg
    ) {

    ini_set("gd.jpeg_ignore_warning", 1); // иначе на некотоых jpeg-файлах не работает
    
    list($oldwidth, $oldheight, $type) = getimagesize($source_path);
    
    switch ($type) {
        case 1: $typestr = 'gif';break;
        case 2: $typestr = 'jpeg'; break;
        case 3: $typestr = 'png'; break;
    }
    $function = "imagecreatefrom$typestr";
    $src_resource = $function($source_path);
    
    if (!$newheight) { $newheight = round($newwidth * $oldheight/$oldwidth); }
    elseif (!$newwidth) { $newwidth = round($newheight * $oldwidth/$oldheight); }
    $destination_resource = imagecreatetruecolor($newwidth,$newheight);
    
    imagecopyresampled($destination_resource, $src_resource, 0, 0, 0, 0, $newwidth, $newheight, $oldwidth, $oldheight);
    
    if ($type = 2) { # jpeg
        imageinterlace($destination_resource, 1); // чересстрочное формирование изображение
        if ($quality) imagejpeg($destination_resource, $destination_path, $quality);
        else imagejpeg($destination_resource, $destination_path);
    }
    else { # gif, png
        $function = "image$typestr";
        $function($destination_resource, $destination_path);
    }
    
    imagedestroy($destination_resource);
    imagedestroy($src_resource);
}

после перемещения файла из временной директории в конечную ресайзим его и переименовываем:

   
if(is_uploaded_file($_FILES["filename"]["tmp_name"])) // проверим загрузился ли файл
   {
     move_uploaded_file($_FILES["filename"]["tmp_name"], "./upload/".time().".".getExtension($_FILES['filename']['name']));

$name_image = time().".".getExtension($_FILES['filename']['name']);
$old_image = "./upload/".$name_image;
$new_image = "./upload/img".$name_image;

//делаем ресайз
image_resize ($old_image, $new_image, 400 );
//между прочим, на данном этапе можем нарезать много картинок - например маленькие для превьюшек а большие для галереи
image_resize ($old_image, $new_image.'100', 100 );// режем на 100 пикселов для примера

}

примечания:
1. в тех местах где написано "что-то думаем" - имхо лучше не выдавать ошибку явно, а либо посылать тихонечко хацкера в гугл, либо кидать на главную, либо еще что-то - т.е. не сообщать злоумышленнику явно о том что нам известны его жалкие попытки
2. "не-php-ные" (во слово получилось))) методы вроде

php_flag engine Off

сейчас пропущены намеренно


буду рад если кто выскажет свои мысли или дополнит

 

[rutrum]

Я люблю геты, как юзал, так и буду юзать. Вконтактик принимает логин и пароль через гет - и ничего, жив.

Меня тож бесит, ибо абсолютно бесполезнейшая проверка.

Минутка просвещения: http://php.net/manual/en/function.parse-url.php

Буду дергать на цитаты:

ведь многие сервера работают с php как с картинкой

[/QUOTE]

та же капча в которой картинкой является php файл

[/QUOTE]

может разместить его среди метаданных картинки

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


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

 

[t3s]

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

в-третьих, просто позлим UnDeaD-а - насколько я понял он начинает злиться когда речь идет о проверке реферера

Меня тож бесит, ибо абсолютно бесполезнейшая проверка.

по поводу "позлить" каюсь - признаю что немного вспылил... но ведь вспылил в ответ на слова в свой адрес
UnDeaD, мир? предлагаю в дальнейшем вести себя как взрослые люди, а свои посты сейчас подредактирую

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

[/QUOTE]

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

не поделитесь своими взглядами?


зы
[/QUOTE]

Вконтактик принимает логин и пароль через гет - и ничего, жив.

форма авторизации контакта:

<form method="POST" name="login" id="quick_login_form" action="https://login.vk.com/" onsubmit="if (vklogin) {return true} else {quick_login();return false;}" target="quick_login_frame">

 

[UnDeaD]

да я ни с кем не воюю) прошли те времена уже давным давно) я бы даже сейчас помодерил этот форум, дабы немного отвлечся от рутины, но мне это никто не даст=)

форма авторизации контакта:

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

на самом деле все что написано в этой теме, а если быть более точным - большинство, но весь первый пост - УЙНЯ. если нужны нормальные скрипты - к ним должен быть нормальный подход. нормальная фильтрация и т.п. у меня, почему-то, все данные проходят множество проверок перед тем, как попадут в базу данных. но даже не в этом дело. каждая переменная - это унитарная единица в кодинге. к ней нужен уникальный подход. что-то я фильтрую через strip_tags, что-то через explode, что-то через (int), что-то через прег_реплейс и т.п. в результате я получаю только те данные, которые мне нужны.


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

if (isset($_GET['p_add']))
{
    $error = '';
    $max_image_width    = 80000000;
    $max_image_height    = 10240000;
    $max_image_size        = 1024 * 1024;
    $_SESSION['page'] = 'load(1, 4);';
    $sux = false; 
    $valid_types =  array("gif","jpg", "png", "jpeg");
    if (isset($_FILES["userfile"])) {
        if (is_uploaded_file($_FILES['userfile']['tmp_name'])) {
            $filename = $_FILES['userfile']['tmp_name'];
            $ext = substr($_FILES['userfile']['name'], 
                1 + strrpos($_FILES['userfile']['name'], "."));
            if (filesize($filename) > $max_image_size) {
                #echo "error 4";
                #echo $_SESSION['page'];
                $error = 'Превышен максимальный размер файла ('.($max_image_size / 1024).' кб)! ';
            } elseif (!in_array($ext, $valid_types)) {
                $error = 'Неверный формат файла! Можно загружать только: '.implode(", ", $valid_types).'! ';
            } else {
                 $size = GetImageSize($filename);
                 if (($size) && ($size[0] < $max_image_width) 
                    && ($size[1] < $max_image_height)) {
                    if (@copy($filename, "images/".$_SESSION['userID'].'_'.basename($_FILES['userfile']['name']))) {
                        $sux = true;
                    } else {
                        $error = 'Произошла ошибка при загруке файла! ';
                    }
                } else {
                    $error = 'Размеры должны быть не больше чем '.$max_image_width.'*'.$max_image_height.'! ';
                }
            }
        } else {
            $error = 'Произошла ошибка при загруке файла! ';
        }
    }
    else 
    {
        $error = 'Вы не выбрали файл!';
    }
    if ($sux == true)
    {
        $allowed_login = "/[^a-zA-Zа-яА-Я0-9їєі:#\/._-\s]/is";
        foreach ($_POST as $k => $v)
        {
            $_POST[$k] = trim(preg_replace($allowed_login,"",$v));
        }
        mysql_query("
            INSERT INTO 
                portfolio 
            SET 
                user_id = ".$_SESSION['userID'].",
                cat_id = ".$_POST['cat_id'].",
                name = '".$_POST['name']."',
                text = '".$_POST['description']."',
                post_time = ".time().",
                img = '".$_SESSION['userID'].'_'.basename($_FILES['userfile']['name'])."'
        ");
        mysql_query("UPDATE users SET portfolio = portfolio + 1, reit = reit + 5 WHERE user_id = ".$_SESSION['userID']." ");
    }
    if ($error != '')
    {
        echo '
            <script>
                alert("'.$error.'");
                location.href = "'.$_SERVER['HTTP_REFERER'].'";
            </script>
        ';
    }
    else 
    {
        header("Location: ".$_SERVER['HTTP_REFERER']);
    }
    die;
}

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

 

[t3s]

кури мобильную версию. там все на гетах

блин, парни вы чего? откуда такая инфа?
вот форма на мобильном контакте

<form method="post" action = "https://login.vk.com/?act=login&amp;to=&amp;from_host=m.vkontakte.ru&amp;ip_h=14232211c32490cccf&pda=1">

если имеется ввиду авторизация через апи/виджеты - то там тоже пост

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

и как? - кроме курла

 

[UnDeaD]

да давно уже такое )

и как? - кроме курла

сервера обоих сервисов хавают геты на ура. у меня на старой мобиле постоянно были забиты хотлинки с логином и паролем на авторизацию