Kolyan [Off] [#] (20.10.2009 / 16:31)

АхqрхА, идиот если честно. Зачем писать функции если они уже есть .
Изм. Kolyan (20.10.2009 / 16:34) [1]

AlkatraZ (SV!) [Off] [#] (20.10.2009 / 17:22) Уездный предводитель Каманчей

AxqpxA (20.10.2009/20:24)
я вообще не пользуюсь не mysql_real_escape_string() не htmlspecialchars() не пользуюсь! я написал свою функцию замены символов, на html теги Напрасно.
Не следует изобретать велосипед, если он уже изобретен и выполняет свои функции.
Встроенные функции в большинстве случаев намного быстрее.

AxqpxA [Off] [#] (20.10.2009 / 19:08) хуйгомноебаллапатай

Ну допустим если написать такой текст echo 'text'; то htmlspecialchars() не даст записать в базу

Kolyan [Off] [#] (20.10.2009 / 19:41)

Речь идет о обработке данных посетителя ...Ну ...все равно идиот ( Зачем echo''; пихать в базу?

Дедушко_АнаниЙ [Off] [#] (20.10.2009 / 19:47)

AxqpxA (20.10.2009/23:08)
Ну допустим если написать такой текст echo 'text'; то htmlspecialchars() не даст записать в базу htmlspecialchars() обрабатывает далеко не все символы.
Я например предпочитаю htmlentities() с параметром ENT_QUOTES и UTF-8

Дедушко_АнаниЙ [Off] [#] (20.10.2009 / 19:50)

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

А вот уже при выводе в браузер, можно обрабатывать HTML символы и прочую хуйню.

AxqpxA [Off] [#] (20.10.2009 / 20:00) хуйгомноебаллапатай

Дедушко_АнаниЙ, Я вот кодингом занимаюсь буквально полтора месяца! просвети не опытного, чем лучше если сохранять в том виде, в котором поступают от юзера?

AxqpxA [Off] [#] (20.10.2009 / 20:03) хуйгомноебаллапатай

Kolyan (20.10.2009/23:41)
Речь идет о обработке данных посетителя ...Ну ...все равно идиот ( Зачем echo''; пихать в базу?еба! допустим сайт для мастеров! и вот кто то вставляет кусок кода, и там присутствует одинарная кавычка! логично?

Дедушко_АнаниЙ [Off] [#] (20.10.2009 / 20:05)

Ну я же и написал выше.
Когда принимаешь от клиента обрабатывай

$text = trim($_POST['text']);

это ты занес в переменную, но в базу еще добавлять нельзя, будет инъекция.
Перед добавлением нужно обработать:
$text = mysql_real_escape_string($text);
И все, инъекция уже не страшна.
---
А когда достаешь из базы и выводишь в браузер, нужно обработать htmlentities() или htmlspecialchars() чтоб хакеры не подпихнули всякую гадость.
И будет тебе счастье

Kolyan [Off] [#] (20.10.2009 / 20:05)

Пиздец логика
echo '';

Дедушко_АнаниЙ [Off] [#] (20.10.2009 / 20:06)

То есть, реал_ескейп для того и предназначен, что экранирует все опасные для базы символы, которые могут быть восприняты как управляющие.

Kolyan [Off] [#] (20.10.2009 / 20:07)

Отображается.Че дальше? )

AxqpxA [Off] [#] (20.10.2009 / 20:10) хуйгомноебаллапатай

Дедушко_АнаниЙ, это я понял! я не понимаю разницы, если экранирова при записи, либо выводе

Дедушко_АнаниЙ [Off] [#] (20.10.2009 / 20:10)

В JohnCMS например так и сделано.
На форуме, данные хранятся так. как поступают от клиента, при записи обрабатываются реал_ескейпом, а при выводе htmlentities()

Дедушко_АнаниЙ [Off] [#] (20.10.2009 / 20:13)

AxqpxA (21.10.2009/00:10)
Дедушко_АнаниЙ, это я понял! я не понимаю разницы, если экранирова при записи, либо выводе Есть большая разница.
С необработанным текстом легче работать.
К примеру, надо тебе порезать на 200 символов. А вдруг, эта обрезка попадает на XHTML сущность, например, посередине & и вот тебе, ошибка XHTML.
---
Я на форуме JohnCMS смог полностью избавиться от этих ошибок только тогда, когда перевел на чистое хранение.
---
Ну а короткие тексты, типа названия статьи, или ника, или города, можно обрабатывать и на входе, разницы нет.

AxqpxA [Off] [#] (20.10.2009 / 20:14) хуйгомноебаллапатай

Дедушко_АнаниЙ, Ну так я спрашиваю, какая разница что я буду экранирывать при записи, либо при выводе? что это мне дает?

AxqpxA [Off] [#] (20.10.2009 / 20:16) хуйгомноебаллапатай

Дедушко_АнаниЙ, Х.м я как то о этом даже не задумывался

LYCUK [Off] [#] (14.12.2009 / 10:32)

Это-же запросы к базе.Они соотносятсо к скрипту который построен на базе данных.
=====
Принцип атаки внедрения SQL
Допустим, серверное ПО, получив входной параметр id, использует его для создания SQL-запроса. Рассмотрим следующий PHP-скрипт:
# Предыдущий код скрипта...
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
# Следующий код скрипта...
Если на сервер передан параметр id, равный 5 (например так: http://example.org/script.php?id=5), то выполнится следующий SQL-запрос:
SELECT * FROM news WHERE id_news = 5
Но если злоумышленник передаст в качестве параметра id строку -1 OR 1=1 (например, так: http://example.org/script.php? ... R+1=1), то выполнится запрос:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Таким образом, изменение входных параметров путём добавления в них конструкций языка SQL вызывает изменение в логике выполнения SQL-запроса (в данном примере вместо новости с заданным идентификатором будут выбраны все имеющиеся в базе новости, поскольку выражение 1=1 всегда истинно).

LYCUK [Off] [#] (14.12.2009 / 10:33)

Кароче если ты с компа то можеш посмареть взлом своими глазами по видеоРолику гг я ржал
http://www.youtube.com/watch?v ... BsIOY

john77 (SV!) [Off] [#] (14.12.2009 / 12:12) чморылое одоробло

LYCUK (14.12.2009/13:32)
Это-же запросы к базе.Они соотносятсо к скрипту который построен на базе данных. ===== Принцип атаки внедрения SQL Допустим, серверное ПО, получив входной параметр id, использует его для создания SQL-В данном случае выручит intval()