В последната статия се опитах да опиша какво точно е тази уязвимост и че не е от значение, изпълнението на всички условия, необходими за типа на CSRF атаки.
В тази статия ще се опитам да се говори за защита срещу атаки от този вид на парти:
- От страната на клиента - основните начини да се предпазите
- От страна на сървъра - подходящите приложения за дизайн
Ако се чудите как да се предпазите от CSRF сте добре дошли при среза.
обща информация
Като цяло, аз искам да напомня, CSRF - НЕ е уязвима, този тип атака. И това е извършено нападение на уеб приложението за крайния потребител, като се използва уязвимост в това приложение, което може да се обозначават като "липса на надлежна проверка на източника на разследване" (на името на моята собствена, не съди строго, но това е вярно). Но по-нататък ще се отнасят до CSRF уязвимости и нападения в едната посока е по-лесно, и това е, което прави =)
И след като атаката е извършена от страна на потребителя, а потребителят да бъдат защитени ... шега =) Въпросът е, че всеки потребител може да се намали възможността за извършване на тази атака срещу всеки сайт, който той използва (дори и ако тези сайтове не са вградена защита срещу CSRF). Но в допълнение към потребителите, разработчиците на сайтове могат да проектират вашата кандидатура, така че nedopustit възможност на тази атака срещу своите потребители.
Помислете за защита от двете страни.
Защита от потребителя
Като цяло всичко е много банална:
Това е всичко. Ние сега се обръщат към основните.
Защита от разработчиците
Както вече споменахме, уязвимостта се крие в липсата на надлежен източник молба за удостоверяване. Това е, когато разработването на приложения, трябва да се изгради функционална проверка на източника. И първото нещо, което идва на ум chtozhe? Точно така! Проверете Referer.
Проверете Referer
Аз трябва да кажа, за тези, които прочели статията по диагонала. Да се основава защитата си на проверка на това заглавие - (!) Зле. Защо - виж по-долу ..
Да започнем с това, ние трябва да разберем, какво е този метод.
Но ада. Въпросът тук не е, че можете да фалшив референт (какво нормален нападател ще поиска от жертвата, че тя е заместена референтът и премина чрез линк). А фактът, че статистическите данни при около 5% от потребителите Препоръчител предаване на прекъсвания. Това означава, че или пет на сто не ще бъде в състояние да работи със сайта изобщо или те ще бъдат уязвими към тази атака (в зависимост от приложението си политика).
Voosche като независим метод, този метод е безсмислена.
Потвърждаване на действия
Така че сега единственият коректен и надежден начин.
Смисълът на този метод е да се добави параметър съдържа някои "жетони" на всяка връзка, изпратете формата и така нататък. Искането е постъпило в сървъра трябва да се провери наличието на токена в получените параметри. Естествено, всеки знак за всеки потребител трябва да е уникално, а дори и по-добре, ако всеки знак е уникален.
Един от най-простите и надеждни примери за изпълнение - в знак се генерира за всяка заявка за нова и е монтиран на бисквитките потребителски и се добавя към параметрите на форми и връзки на страницата:
И тогава, при получаването на всяка знак от искането е в сравнение с бисквитки и белегът е посочено във формата на параметри. И ако те са едни и същи, източникът на искането е законно. След това означение се генерира отново, и отново, разположен в бисквитки и т.н. в кръг.
Като цяло, изпълнението може да бъде различен, но проблемът е, че преходът към жетоните е доста трудно, защото трябва да се разгледа всеки справка, всяка форма, всяка страница ... Можете да защитите само важно страници / форми / справка, но след това има шанс да има някои от тях пропуснете.
Аз лично защитава само POST форми и важни връзки. Това е пост в молбата ми не работи без подходяща знак. Това елиминира възможността да се забравя да се защити това, което тази форма, тъй като той просто няма да работи и аз веднага се забелязва.
Надявам се, че в тази статия ви научили как да се защитава срещу CSRF атаки.
PS: За да се продължи :)
Вижте също
- Уязвимост CSRF. Скриване Referer когато пренасочване
Практически пример изпълнение забраните на скоростната кутия при пренасочване на референт. Пренасочване без да изпрати Referer. Описание CSRF атака, когато на разстояние референт.
Здравейте Днес, аз се допълва поредицата от статии за CSRF. Но сега аз отивам да се движи плавно на "грешната страна." Както се казва.
Общо описание на типа CSRF атака. Прост пример за практическото използване на тази уязвимост крос-сайт искане за фалшифициране. Картинен уязвимост диаграма CSRF.
Да, спомням си, че съм обещал в предишния пост, за да пиша за CAPTCHA, но трябва да бъда честен, да пиша за тези CAPTCHAs имат.
Описание на критичните уязвимости в CMS NetCat. изпълнение на код. NetCat SEARCH_QUERY изпълнение на код.
Точно днес, един от клиентите ми ми писа, че неговият сайт е хакнат. Честно казано бях много го изненада. Толкова много.
Пример защита PHP включва. Метод за предотвратяване на откриване и задържане крекинг атака.
Нека мислите, кой е хакер? Хакер - това не е бедняк! Хората често бъркат тези понятия. Hacker - един.
Е Е, нека да опитаме с вас, за да обсъдят тази тема. Да кажем, че аз знам как CAPTCHA (бележка в моя блог има почти цял раздел, за да го posveschenny).
Изпълнение на CAPTCHA може да бъде различен, а може би и по-правилно да се каже, че повечето от неговите приложения все още е в състояние да защити срещу CSRF (с някои изключения). Е, отново, ако погледнете следното изречение идва под надслов "жетони": Така че сега единственият правилен и безопасен начин .. Мисля, че това предложение трябва да се допира от идеята, че цялата тази идея с подобен тест не е съвсем разумен) - в контекста на статията, това е само един пример за нестандартно мислене.
Ами говорим за това някои реализации на CAPTCHA не могат да предпазват от CSRF ... Ами тогава извинение. Това е грешка, програмист, за изпълнение на дупки капитан. И със сигурност не на последно проблема. Със същия успех можем да говорим за жетони, казват те или безполезно ", ако знаете, че механизмът на жетоните и мисля, че по-малко."
жетон се генерира за всяка заявка за нова и е монтиран на бисквитките потребителски
Бисквитката ако потребителят е изключен? Вероятно> 5% ..
Сесия без използването на бисквитки? Ако сте стандартен механизъм сесии PHP, тогава този идентификатор на сесията също се съхранява в бисквитка. Не бисквитки - не сесии.
Ах ... помогне по-добре фрагмент заявка етекст = дешифрира която остава в референт, след като потребителят идва от търсене Yandex.
Можете да представи вашия материал е много достъпна, благодарение
Един от най-простите и надеждни примери за изпълнение - в знак се генерира за всяка заявка за нова и е монтиран на бисквитките потребителски и се добавя към параметрите на форми и връзки на страницата:
Точно така, за защита, което трябва да направите, просто знак, но и за това, което всеки път, за да се генерира нов знак и го сложи в бисквитка?
Просто не разбирам защо в бисквитка в магазина не правилното нещо?
Ами знак съхранява в бисквитка - нещо не е от значение. Това е просто по-лесно, отколкото да го приберете в база данни. Моля, имайте предвид написах:
Един от най-простите и най-надеждни ...
Можете да го съхранява в базата данни. По принцип, абсолютно не ме интересува ... Не е нужно да я съхранява на друго място, и да генерира уникални данни, въз основа на потребителя, както и някаква тайна сървъра сол.
Възможности за масата, в статията се задава само един от тях :)
Добър ден. Prompt като жетони, предписан в кода на страницата, предпазва от CSRF? Защо не мога да се zloumyshoennik реи знак и да премине в искането за пост?
Разбор една от страниците на сайта дърпане на символа и на следващата стъпка otpravlyaemm на правилния екип вече на означението.
Какво отбрана?
И тогава аз мисля, защо някои услуги понякога се изисква да въведете парола, когато вземането на критични операции, това е защита.
Вие очевидно не е чел за това, което самата атака. Няма възможност на някой хакер реи знак. Token е уникален за всеки потребител.
Повторни парола води - Защита от други проблеми.
Имам обичайните уеб-ТА време-па-бот-чик. Пи-шу тук, че ми в тези с висока резолюция, но с това, което имам ли-nuzh ден стана-ки-ддс-Ся в сфера-ре в интернет, неговата Кабо-дали раса-suzh де-ТА веднъж ме-ридание неправителствена schayu Най сто-ти.
Не забравяйте да се абонирате:
И това е много про-шу, не-за кандидат-Уай-оставащите lyat-ком-мъже-та-Рий до около Chi-Tang Ним за-пи-НДСВ.
Свързани статии