Въпроси за сигурността:примери, начини на защита

А ок, а той човека е искал да каже,
да ги вкарам в база данни, вместо array
Така ли ?

А и ако няма никва защита от инжекция така с array
дали няма да имам проблеми ?

if(isset($_GET['page']))
{
$rows = basename($_GET['page']);
$modules = array("index", "register", "logout", "login", "user", "lp");
if (in_array($rows, $modules))
{
require (''.$rows.'.php');
}
else
{
echo "No Page";
}
Увеличете...
 
niker каза:
А ок, а той човека е искал да каже,
да ги вкарам в база данни, вместо array
Така ли ?

А и ако няма никва защита от инжекция така с array
дали няма да имам проблеми ?

if(isset($_GET['page']))
{
$rows = basename($_GET['page']);
$modules = array("index", "register", "logout", "login", "user", "lp");
if (in_array($rows, $modules))
{
require (''.$rows.'.php');
}
else
{
echo "No Page";
}
Увеличете...
Увеличете...

Не. Array в случая си е по-добрия вариант. Исках да кажа, че за това нещо няма нужда от addslashes и htmlspecialchars, защото НЕ използваш $_GET['page'] в Базата данни (БД). Така, както си го написал няма да имаш проблеми.
 
StormBreaker каза:
За това не ти трябва addslashes(htmlspecialchars(...)). Защото тая променлива не я вкарваш в БД => няма опасност от SQL инжекция.
Увеличете...

Няма опастност от SQLi, но има опастност от XSS .. хубаво е да си имаш addslashes, htmlspecialchars и в някой случеи trim .. :) в този случай не е излишно :idea:
 
justspy каза:
StormBreaker каза:
За това не ти трябва addslashes(htmlspecialchars(...)). Защото тая променлива не я вкарваш в БД => няма опасност от SQL инжекция.
Увеличете...

Няма опастност от SQLi, но има опастност от XSS .. хубаво е да си имаш addslashes, htmlspecialchars и в някой случеи trim .. :) в този случай не е излишно :idea:
Увеличете...

Я ми кажи как ще мине през in_array нещо различно от зададените в масива стойности?
 
Нямам в предивд в този случай, защото просто така го каза, че когато данните няма да се отнасят към базата данни няма нужда от htmlspecialchars или подобни .. явно си нямал това в предвид, извинявай, просто някой може да го разбере, както аз и да си помисли, че нему трябват такива защити, и реално да се окаже, че е лесна мишена :D
 
justspy каза:
Нямам в предивд в този случай, защото просто така го каза, че когато данните няма да се отнасят към базата данни няма нужда от htmlspecialchars или подобни .. явно си нямал това в предвид, извинявай, просто някой може да го разбере, както аз и да си помисли, че нему трябват такива защити, и реално да се окаже, че е лесна мишена :D
Увеличете...

Не сме се разбрали като хората :D Казвах, че в тоя случай няма нужда. Иначе addslashes е за SQL Injection а htmlspec... пази от XSSи

Опитах се да го обясня по-просто ама явно не се е получило :)
 
А каква е точно разликата между inject и xss атака ?

Аз знам че inject е при базата данни,
ма xss, така и немога да разбера точно за какво е
 
XSS порпинцип значи Crossing site script, чудиш се защо не е CSS, защото вече думата css е заета, и така е измислено името xss, xss може да служи за вмъкване на html код във вече готовия код, или крадене на бисквитки, можеш сам да провериш как дейтсва, създай си един php файл и в него сложи този код :

Код: 
<?
$page=$_GET['page'];

if (!$page)
{
echo "Избери страница";
}
else
{
echo $page;
}
?>

да речем файла ти се казва index.php влез в index.php?page=asd и така, на мястото на asd можеш да пишеш някакав html код, да речем <h1>XSS</h1> това го сложи на мястото на asd и виш какво става, можеш да вземеш бискитки да речем, като се напише <script>alert("document.cookie")</script> но стига с подробностите, от това нещо можеш да се защитиш с htmlspecialchars, addslashes.. а SQL Injection са фълшиви заявки към базата данни, пред стави си, че имаш една заявка в която вкарваш дадено ид, без проверка директно $_GET['id'] това е в заявката ти, при проверка за уязвимост се пише знака ' и по точно кавичка, ти реално очакваш числова стойност и неси защитил нищо, при въвеждане на кавичка, ще ти излезе error, от който в повечето случаи става ясно, че си уязвим на SQL Injection .. :) мисля, че бях достатачно изчерпателен :D
 
инжекцията ясно.
А ако си защитя бисквитките с htmlsp... adsl..
Ще могат ли да ми ги крадат пак ?
 
Бисквитките няма как да бъдат защитавани с htmlspecialchars и тем подобни, ако неси наясно, htmlspecialchars върши такава работа, да речем имаш едно поле, и един бутон, и когато се натисне бутона текста въведен в поелто се извежда в страница, ако входните данни и по точно $_POST от полето, не е защитен с нищо, html кода ще дейсва в страницата, както горния пример, но ако добавиш htmlspecialchars въведения html код и изобщо какъвто и да е той няма да се изпълни а само ще се появи, addslashes добавя по още една наколонена черта при друга въведена така, ако в полето напиеш / при извеждане с addslashes ще се появи // :) а относно бисквитките, те могат да бъдат променяни, затова те неса сигорни, ако някой се добере до бисквитките на админа, може да смени неговите с тези на админа, и да се логне като админ :?:
 
Основно правило в живота и в програмиранет - не се доверявай на чужда информация преди да си я проверил. :D Всъщност ще стане \/ не // но предполагам, че това е печатна грешка :)
 
Ами възможно, покрай тези големите слова, които врътнах, и аз започнах да се обърквам :D :D :)
 
аз adsla.. и htmlsp.. ги ползвам заедно, има ли някакъв проблем или
най-добре си е при заявки към датабазата да ползвам adsla..
а при пост и т.н. htmlsp..

$name = htmlspecialchars($_post[name], ENT..);
(Select * from users where name='addslashes('.$_post[name].')')
 
Не ! по-добре недей да го правиш при заявките, отделно, че можеш да не го напишеш правилно и да ти дадеш грешка в заявката, отделно, че става по объркващо, можеш да го правиш така :

$text=htmlspecialchars(addslashes($_POST['text']));

Едитнато : Днес повече няма да пиша :D :D
 
ъъъъъъъъ аз ли нещо или има ново trim. До колкото знам то маха интервалите преди думат и след нея не и по средата
http://bg.php.net/manual/bg/function.trim.php
 
sorRy каза:
ъъъъъъъъ аз ли нещо или има ново trim. До колкото знам то маха интервалите преди думат и след нея не и по средата
http://bg.php.net/manual/bg/function.trim.php
Увеличете...

Не бъркаш се trim няма промени.. И доколкото съм запознат и във PHP6 ще си работи по този начин..
 
Ludjov каза:
sorRy каза:
ъъъъъъъъ аз ли нещо или има ново trim. До колкото знам то маха интервалите преди думат и след нея не и по средата
http://bg.php.net/manual/bg/function.trim.php
Увеличете...

Не бъркаш се trim няма промени.. И доколкото съм запознат и във PHP6 ще си работи по този начин..
Увеличете...

Не бърка човека. Трим прави тоя стринг " test string " на "test string". Трие празните места в началото и в края на низа.
 
Тип на атака: XSRF
Начин на действие: Във уязвима система се изпраща ЛС до админът с страница която съдържа дори прост бекграунд и текст - ще се зачудите как тогава се разбира паролата? Ами много просто. Добавя се 1 скрито поле и веднага щом админът цъкне на линка неговите данни се променят на каквито е пожелал атакуващият.
Работи на: Уязвими CMS системи.
Противодействие: Не приемайте странни ЛС-та и обновете до последната версия на вашата CMS система.
 
NewGuy каза:
Аз обаче бих предпочел да използвам base64 защото не е нужно да се блокират някакви символи и функцията има decode. От една страна е доста полезно защото може да се записват акаунти пароли и (току що пробвах с дълги съобщения и няма проблеми). Може лесно да се изкарва информация и няма опасност от SQL injection. Лесно при запис се минава през encode функцията а при изкарване на информация през decode. Хубавото е, че не трябва да се съобразяваме и с колацията на базата данни. :wink:
[/code]
Увеличете...

1. с base64 си всичко друго, но не и защитен
2. разликата да пазиш "$string" или "base64_encode($string)" е нулева
3. а това, че няма да се съобразяваш с чарсета, не е плюс, а проблем в програмиста
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Back
Горе