[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Решение ли от SQL инъекций
Страницы: 1, 2
Manat
народ. подскажите пожалуйста новичку избавляет ли следующее от sql инъекций

$sql="select * from users where name='".mysql_real_escape_strings(myFunc($_GET["hisname"]))."'";

function myFunc($str)
{
делает реплейс "or" на "myor", "select" na "myselect", "delete" na "mydelete" и так далее.
}

и второе безопаснее ли мм например хранить пароли в пхп.файлах пряма в корне сайта например

файлы такого типа
if (5==4)
{
echo "(user)(id)145(_id)(passw)hispassword(_passw)(_user)";
echo "(user)(id)258(_id)(passw)hispassword2(_passw)(_user)";
}

а вытаскивать их патома с помощь. fopen?
Manat
то есть наоборот myFunc(mysql_real_escape_strings($_GET["hisname"]))
ApuktaChehov
myFunc - паранойя. Она не нужна, если правильно обработать всё mysql_real_escape_string().

А зачем там хранить пароли, если вы БД используете? Вообще, если вы собираетесь хранить пароли в файлах, то такие файлы нужно вынести за пределы веб-сервера. Это не панацея от похищения паролей, но добавит сложностей злоумышленнику.

P.S. Нужно не защиты изобретать, а писать безопасный код. Если у вас в коде дыра, то никакая защита вас не защитит.

P.S.S. mysql_real_escape_strings = mysql_real_escape_string

_____________
Manat
с пост-криптумом абсолютно согласен.
но есть шанс что все таки какую-нить дырку в коде я допущу.
и поэтому пытаюсь 1) обезопаситься от иньъекций
2) если он все таки сможет посмотреть базу с помощью этих иньекций то в пхп. файл с паролем он заглянуть не сможет же. даже если он будет в корне сайта (или это не так)

п.с. вот таким построением запросов для текстовых обеспечиваю ли я себе безопасность от иньекций в запрос
$sql="select * from users where name='".mysql_real_escape_string($_GET["name"]."'";

неужели этого достаточно? просто я слышал где-то звон но незнаю где он)) что этого вроде недостаточно

а для численных достаточно ли $sql="select * from users where id='".intval($_GET["id"]."'";


еще раз п.с.
все таки меня сильно волнует вопрос сможет ли хакер посмотреть код passw.php если он лежит в корне сайта. случаи дырок у хостера естесно я не рассматриваю.
ApuktaChehov
Вы пытаетесь выбирать меньшее из зол. Если злоумышленник получит доступ к БД, зачем ему ваши пароли? Он и так сделает все что ему надо.

Конечно, попытка скрыть пароли в php код, который по идее никогда не выдастся в поток - хороша. Но опять же не панацея. Это тоже можно обойти, при желании.

mysql_real_escape_string - достаточно.
intval тоже достаточно.

passw.php сможет посмотреть.

Поймите одно, ломается ВСЕ, абсолютно безопасной системы не существует. Вопрос в стоимости взлома. То о чем я говорю, это элементарная защита.

И не забывайте про htmlspecialchars() при выводе контента. А то куки упрут в миг.

_____________
Manat
млин что то я воообще в шоке))) а именно от фразы
"Конечно, попытка скрыть пароли в php код, который по идее никогда не выдастся в поток - хороша. Но опять же не панацея. Это тоже можно обойти, при желании."

я еще раз повторюсь что все мои мысли с условием что у хостера нет дыр.

если возможно посмотреть пхп-код файлов то естественно чтобы я не придумал то все коту под хвост((((
хотя-бы потому-что при шифровании использую ключи которые хранятся в пхп файлах как переменные.
ApuktaChehov
Manat - все возможно. Это не теория.

По этому не делайте дыр и не будет проблем.

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

_____________
Manat
s chego vy rehili shto ya uminchau? i ya soglasen shto shoby shtoto novoye izobresti ne nuzhno polagatsya na frazu "zachem zanovo izobretat velosiped"

p.s mne kazhetsya v nashem sluchae hranenie v mysql ne yavalyaetsya starym sposobom po sravnenyu s hraneniem v textovyh filah
Michael
Manat, если касается паролей пользователей, то распространено хранение не паролей а хэшей пароля. Зная хэш пароль не узнаешь, в общем случае.

_____________
There never was a struggle in the soul of a good man that was not hard
ApuktaChehov
ApuktaChehov - да я про "умничать" не в плохом смысле. Не обижайтесь. Думаю, что вам стоит изучить существующие средства защиты паролей, а не изобретать свои.

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

_____________
Manat
может мне просто перефразировать вопрос тогда)))

случай 1)
хранить пароли и и-мейлы в зашифрованном виде в БД

случай 2)
хранить пароли и и-мейлы в такомже зашифрованном виде в пхп-файлах

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

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

а насчет экспертства)) я тока как пару недель начал инет читать на эту тему
killer8080
Manat
вам для начала сюда
Manat
killer8080 да я уже "обчитался".
и не только здесь. и понял что простым mysql_real_escape_string в нужном месте не защитишся на 100% от иньекций в связи с этим решил заменять скл-команды в переменной пришедшей извне на другие слова, а ' и " на например _quote_ и _doublequote_. - но кажися это как сказали панацея))))


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

про пароли это понятно что надо хеши хранить - вернее даже не просто хеши.

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

и на данный момент я работаю над скл-иньекциями



Michael
Цитата (Manat)
и понял что простым mysql_real_escape_string в нужном месте не защитишся на 100% от иньекций

Есть конкретный пример обхода mysql_real_escape_string? А то что то не верится.

Есть еще PDO и подготовленные запросы, там иньекций нет.


_____________
There never was a struggle in the soul of a good man that was not hard
killer8080
Цитата (Manat @ 19.02.2013 - 11:12)
killer8080 да я уже "обчитался".и не только здесь. и понял что простым mysql_real_escape_string в нужном месте не защитишся на 100% от иньекций

плохо значит читал, раз до сих пор не понял сути.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.