pix3l каза:
Не случайно използвах "хак", понеже ако излъжеш CSRF защитата, електронното банкиране ще спре да съществува.
CSRF не защитава само GET заявки... POST заявките са по-критичната част.
Не знам ти какви ботове пишеш на PHP, аз съм използвал само Java и Python за подобно нещо. PHP не ми се струва подходящ.
Така, сега ще го обясня по друг начин. Имаш сайт с ограничен достъп или по-просто казано с регистрация. Нямаш CAPTCHA за защита на формата, но имаш някакъв token на нея, като моят прост пример по-нагоре. Не говоря за username и password, приемаме, че ги имаме. Та с Curl подавам POST заявката и се логвам с въпросните имена и пароли в акаунта и правя каквото си искам, защото при логването се създава бисквитка, сздава се сесия и си браузвам из страниците от локалната машина все едно съм аз. Естествено ще парсвам съдържанието на формите и ще взимам съдържанието на въпросният токен по вътрешните страници и ще правя каквото имам като права с акаунта. Игри като ImperiaOnline v4 съм ги автоматизирал изцяло докато ги играех. Та как да избегнеш целият проблем? Ами слага се на логин формата CAPTCHA и вече бота не може да се логне. Щом не може да се логне, то той не може да изпълнява всичките тези манипулации свободно във вътрешните страници. CSRF. Това, което се опитвам да обясня, е че заради CAPTCHA валидирането на потребителите при логин, не е необходимо да се защитават вътрешните форми след логин, защото ботове от външни места не могат да се логнат. От там и следва, че дори да има манипулиране на някакво действие, то то е постигнато по различен начин. Пример ще дам с кликър програми, с които казваш на мишката къде по монитора, през колко време да цъка. Идеята е, че щом веднъш си валидирал потребителя, че е човек, а не бот от там нататъка се поемат нещата под друг знаменател. Прекалено е трудно бот да използва OCR софтуер и да разпознае изображението, след което да се логне с потребителското име и парола, за да върши автоматизирани действия. CSRF е комплексен проблем на приложението, структурата и начина на достъп. Колко от формите му са публични и колко от тях са със след регистрационен контрол. Важно е да защитите логването на бот в приложението Ви, не да защитавате всяка вътрешна форма с ненужни генерирания на ключове. Те няма да Ви спасят от спама и автоматизираните действия в системата, ако даден бот се е логнал. За пример ще дам форумите. Те са често под спам атаки, точно защото не спират логването на ботовете в системата им. Те са външни системи, с перфектни лични карти. Защитавате регистрационната си форма с капча но не и логин формата си??? И двете трябва да бъдат правилно защитени. Злосторника регистрира акаунт и подава име и парола на бота, който се логва и започва да спами. А ако ботът не може да се логне дори да има име и парола, то той става неизползваем. Да форумите имт други защити, но не това е идеята ми. Искам да обясня, че CSRF не е само външна намеса в приложението или някаква кражба, а и логически проблем ако са объркани различни нива за структура на апликацията. Ако ще генерирате token на всяка форма в приложението, лошо няма, но сам по себе си той не решава проблема, и за това постоянно давам библиотеката CURL, като пример. Много от приложенията, които ползвате ще изпищят, на много от известните сайтове за въпросната уязвимост, но те се защитават с добра логика и структурираност. Да в много и от тях мога да се логна с бот и да си автоматизирам разни дивотии. Да накарам бота примерно да се логне във фейсбук и да пише на всичките ми приятели или да поства, но това не означава, че ако направя една multitasking атака спамейки стените на приятелите ми няма да получа бан. Всичко е до компромисите, на база желан резултат. Ако искате си слагайте генерирани ключове в скрити полета на формите, аз предпочитам да сложа капча на логин формата и да защитавам вътрешните страници с други приоми, според приложението.