CSRF на търсачка

pix3l каза:
Явно не усещаш сърказма... :D
Смятам да си дам почивка вече. Това не беше мнението ми, а техническо решение на определен проблем.
Ако мислиш, че ти казвам как да си пишеш приложенията - разбрал си ме погрешно.
Извинявай, че явно съм те разбрал погрешно!
Ти мен изобщо не се и опита да ме разбереш... :mrgreen:
 
pro12 каза:
Благодаря ви отказах се да слагам CSRF!
Виж сега, много хора ще ти кажат, че ти е нужно да генерираш ключове, в някои случаи аз също бих използвал този вид защита, но исках да ти покажа, че освен това решение има и други и не е нужно да използваш нещо, което в по-голямата си част е пречка за време. Потребителят при всеки рефреш вика класът пък той връща резултат, пък се сетват сесии и прочие. Може просто след натискане на Изпълни да попиташ потребителя - абе приятел сигурен ли си, че искаш, и тук на потвърждението може да използваш такъв генериран ключ (защото вече няма да е излишен и ще се зареди защото ще е нужен) след това директно да изпълняваш. Мисълта ми е, че да защита е но не е правилно да е във формата и при всеки рефреш да се зарежда а да не се използва. По-добре на потвърждението да го поставяш и да централизираш системата си за оптимално ползване, а не навсякъде и постоянно. По-добре от 5 форми 3 да искат потвърждение, но потвърждението да има такъв ключ, отколкото от 5 форми 3 постоянно да генерират този ключ без дори да е наложаща защитата защото не се ползват и не обработват заявки. В частни случаи този ключ спестява много главоболия относно някои непредвидени неща, но не е цялото решение на проблема ти и изобщо не трябва само на него да разчиташ.
 
dakata__92 каза:
pro12 каза:
Благодаря ви отказах се да слагам CSRF!
Виж сега, много хора ще ти кажат, че ти е нужно да генерираш ключове, в някои случаи аз също бих използвал този вид защита, но исках да ти покажа, че освен това решение има и други и не е нужно да използваш нещо, което в по-голямата си част е пречка за време. Потребителят при всеки рефреш вика класът пък той връща резултат, пък се сетват сесии и прочие. Може просто след натискане на Изпълни да попиташ потребителя - абе приятел сигурен ли си, че искаш, и тук на потвърждението може да използваш такъв генериран ключ (защото вече няма да е излишен и ще се зареди защото ще е нужен) след това директно да изпълняваш. Мисълта ми е, че да защита е но не е правилно да е във формата и при всеки рефреш да се зарежда а да не се използва. По-добре на потвърждението да го поставяш и да централизираш системата си за оптимално ползване, а не навсякъде и постоянно. По-добре от 5 форми 3 да искат потвърждение, но потвърждението да има такъв ключ, отколкото от 5 форми 3 постоянно да генерират този ключ без дори да е наложаща защитата защото не се ползват и не обработват заявки. В частни случаи този ключ спестява много главоболия относно някои непредвидени неща, но не е цялото решение на проблема ти и изобщо не трябва само на него да разчиташ.
На мен идеята ми беше да генерирам ключ за да се защитавам от фалшиви заявки на хора а не на ботове.
 
Какво визираш под фалшиви заявки и най-вече фалшиви заявки от хора? Ако ми обясниш какво имаш предвид, то може би можем да ти дадем насоки за защита.
 
Има една платформа за форуми, Invision Community, която ограничава търсенията до 1 търсене през 30 секунди.
Помага, ако си на евтин хостинг и трябва да пестиш.
 
На няколко места в интернет прочетох, че е добре да се защитим от фалшиви заявки и имаше пример пращат линк на Иван тои го отваря и му зарежда празна стр със скрита форма и така Иван добавя коментар.
От какви атаки да си пазя приложенията? sql injection, XSS
 
pro12 каза:
На няколко места в интернет прочетох, че е добре да се защитим от фалшиви заявки и имаше пример пращат линк на Иван тои го отваря и му зарежда празна стр със скрита форма и така Иван добавя коментар.
От какви атаки да си пазя приложенията? sql injection, XSS
При такава ситуация ако нападателя използва само JS и HTML за да постне автоматично формата (тоест се ползва бот) при отваряне на някаква страница, ключът би защитил формата ти, защото JavaScript няма как да вземе съдържанието на страницата ти и посредством регулярен израз или друг приом да вземе скритият в полето ключ. До тук защитата ти ще работи добре, но и веднага се намесва PHP. Страницата влиза и взима активен ключ а от там попълва формата и JS довършва нещата. До тук и със защитата. Така че въпросната защита работи добре, до някакво положение. Трябва много неща да се комбинират за да се защитиш от CSRF, но и да кажем, че трябва да се придържаш към новите стандарти за писане на код.
 
В някои форуми решават проблема по такъв начин:
1
<form action="//www.domain.bg/forum/language/?csrfKey=f3787ccac05702ecb20d964782b2a1a8" method="post">

2
<form action="//www.domain.bg/forum/profile/?csrfKey=f3787ccac05702ecb20d964782b2a1a8" method="post">

3
<form action="//www.domain.bg/forum/settings/?csrfKey=f3787ccac05702ecb20d964782b2a1a8" method="post">

като тук работят по-централизирано и с еднозначно генериран ключ за цялата страница и всички форми в нея, като това води до използването само на една форма при един рефреш. Не лоша логика на защита, но и тя е уязвима, ако бот може да достъпи и вземе активен ключ.
 
pro12 каза:
Къде да ги видя новите стандарти за писане на код?
Отговора е в добре забравеното старо. Правилното писане и структуриране на системата е важно за апликацията. Спазвай PHP PSR, преди да напишеш нещо се поитнересувай другите как са решили този проблем, дори маловажен да ти се стори. Чети и питай. Няма място където всичко да е синтезирано и оформено добре, просто на различни места ще намериш различно полезна информация. Ето, днес научи, че ключът помага при по-прости автоматизирани системи, време е да се поровиш как да защитиш системата си от спам. Не само капча е решението на проблема ти. Има и други приоми с време от последната заявка или брой заявки в минута или flood защити и много други неща. SQLi и XSS са вече други типове атаки, които изискват четене и недопускане на нефилтрирано съдържание от формите.
 

Горе