کپچای پیشفرض Yii نسخه قدیمی ReCaptcha گوگل هست. من خودم هم توی پروژه هام کپچای سفارشی خودم رو استفاده میکنم ولی این موضوع ربطی به غیر حرفه ای بودن تولید تصویر کپچا و... نداره. بجای تعمیم دادن این شکلی و کورکورانه، اول کدش رو بررسی کنید.
مثلا شما فرض کنید یک کد کپچای 5 کاراکتری، متشکل از حروف انگلیسی و اعداد، کلا حدود 60 میلیون حالت داره. هکر براش صرف نمیکنه کدهای تصادفی بفرسته، چون باید مثلا 30 میلیون درخواست بفرسته که امید داشته باشه یکیش شانسی درست دربیاد.
ولی حالا وقتی ما مقدار جمع کد اسکی کاراکترهای کد کپچا رو داریم، هکر میاد و تمام ترکیب کاراکترهایی رو که جمع کد اسکی شون اونقدر میشه پیدا میکنه، و یکی از اونا رو بصورت تصادفی به سرور میفرسته.
حالا بنظر شما تعداد حالتها هربار چقدره؟ یعنی مثلا وقتی جمع کدهای اسکی 675 است، چه تعداد ترکیب کاراکتر ممکن هست که جمع کد اسکی شون این عدد میشه؟ من نمیدونم شما هم نمیدونید، این نیاز به سواد و محاسبات ریاضیش داره که البته آنچنان سخت هم نیست و توی ریاضیات آمار و احتمالات مشابه اینطور مسائل رو شاید همه دیده باشیم حل کرده باشیم، ولی بهرحال چیزی که بنظر من مشخصه اینه که تعداد این حالتها نباید عدد چندان بزرگی بشه!
(13-07-1394، 10:59 ق.ظ)ADMIN نوشته: [ -> ]کپچای پیشفرض Yii نسخه قدیمی ReCaptcha گوگل هست. من خودم هم توی پروژه هام کپچای سفارشی خودم رو استفاده میکنم ولی این موضوع ربطی به غیر حرفه ای بودن تولید تصویر کپچا و... نداره. بجای تعمیم دادن این شکلی و کورکورانه، اول کدش رو بررسی کنید.
مهندس منم کدش رو دیدم که توی تاپیک گذاشته بودید. موضوع اینه برای حملاتی که از سمت کلاینت انجام میشن همون اطلاعات سمت کلاینت کافیه و دیگه نیازی نیست نسبت به سمت سرور چیز خاصی بدونید کار خاصی بکنید.
توابع و کدهایی که n0o0b_sina گذاشته کاملا روشن و کافیه از دید من.
الان شما اصلا به استدلال و مثالهای من دقت کردید؟ جاییش مشکل داره نشدنیه بنظر شما؟
تازه شما اگر بگی سمت سرور تصویر کپچا و ولیدیتش قوی هست هیچ نقصی نداره، اونوقت این روش ولیدیشن کلاینت ساید خیلی بیشتر حساس و چیز مسخره ای میشه، چون فرض کن امنیت سمت سرور و خود کیفیت تصویر کپچا امتیاز 500 میگیره ولی سمت کلاینت باعث میشه این امتیاز بشه 150! یعنی شما یه جا رو ضعیف درست کنی گند میزنه به همه چیز دیگه و جاهای دیگر هرچی هم اصولی و قوی باشه فایده نداره. گفتهء همیشگی درمورد امنیت اینه که امنیت مثل یک زنجیره که استحکام اون از استحکام ضعیف ترین حلقهء زنجیر بیشتر نمیشه! حالا میخواد بقیهء حلقه ها درحد حلقه های زنجیر لنگر کشتی گردن کلفت باشن، وقتی یک حلقه ضعیف باشه از همونجا پاره میشه!
اونکه n0o0b_sina گفت تصویر کپچاش راحت کرک میشه من تازه به عقل طراحان این سیستم بیشتر امید آوردم، چون گفتم خب پس چون خود تصویر کپچا چندان قوی نبوده اینا چنین سیستمی رو با علم به اینکه امنیتش در این حد هست گذاشتن. ولی اگر بگی سمت سرور بی نقص و قویه تصویر کپچا هیچ مشکلی نداره حرفه ایه، اونوقت این ولیدیشن سمت کلاینت اعتبار و سواد طراحان این سیستم رو بیشتر زیر سوال میبره چون کار به مراتب احمقانه تری میشه.
(13-07-1394، 10:52 ق.ظ)Eshpilen نوشته: [ -> ]کدوم مسئله؟
منظورم این خاصیت پیشفرض کپچای yii هست که با رفرش صفحه کپچا تغییر نمیکنه! صرفا محل قرارگیری و زاویه کاراکترها کمی عوض میشن و اینطوری اگر یه ربات نتونه درست تشخیص بده میتونه یه درخواست جدید بده و سیستم هم با کمال میل همون کپچا رو با چیدمانی متفاوت بهش میده و احتمال کرک شدن بالا میره.
البته ما میتونیم تنظیم کنیم که هربار کد جدید تولید کنه ولی خب چون پیشفرضش اینطوریه خیلی ها هم همونطوری ازش استفاده میکنن.
آقای شهرکی فکر نمیکنم این حرفم کورکورانه باشه! حداقل به نظر خودم که منطقیه
حالا اگر دلیل بر رد این حرف دارین بفرمایین.
اینطور که میگی بنظر میاد اینا روی بهینه سازی و اینکه میزان پردازش و بار سرور رو کاهش بدن خیلی حساس بودن! یعنی خواستن تعداد تصاویر کپچا که سرور تولید میکنه و پردازشی که صرف تولید تصاویر کپچا میشه حداقل باشه.
درحالیکه بنظر بنده چون کپچا در جاهای محدودی استفاده میشه فقط بخش کوچکی از ترافیک معمولی سایت رو تشکیل میده، پس نباید بطور معمول اینقدر حساس بود.
اون ولیدیشن سمت کلاینت هم که امنیت کپچا رو خیلی پایین تر میاره، لابد بخاطر همین گذاشتن که مثلا تعداد درخواست کمتری از سرور صورت بگیره (البته از نظر یوزرفرندلی هم شاید مد نظرشون بوده). چون نگاه که میکنی اصلا ولیدیشن درست و حسابی هم نیست یجورایی رندوم عمل میکنه احتمال خطا داره (ترکیبات اشتباه رو ممکنه درست تشخیص بده) و خودشون با اینکه میدونستن اگر هش قوی تری بذارن راحت میشه کپچا رو در سمت کلاینت کرک کرد، اومدن این روش من درآوردی که جواب قطعی نمیده رو گذاشتن که یه tradeoff بینابین امنیت و بهینه سازی داشته باشن. البته به خیال خودشون! اینکه در عمل تا چه حد عاقلانه و مفیده خیلی جای بحث داره.
خلاصه جالب شد چون اخیرا راجع به بیماری وسواس در بهینه سازی داشتم بحث میکردم که سرش جر و بحث شد توی اون یکی تاپیک! اینجا هم میبینیم که وسواس روی بهینه سازی میتونه به اشتباهات و کاهش امنیت منجر بشه. آیا واقعا این همه امنیت خدشه دار شده اهمیتش از اون مقدار پرفورمنس که صرفه جویی میشه کمتره؟ من مطمئن نیستم اینطور باشه!
اینه که جملاتی که بعضی افراد سرشناس گفتن آدم معناش رو در اینطور موارد میبینه.
«بهینه سازی زودهنگام ریشهء تمام پلیدی هاست». اینجا هم ما می بینیم که طرفها فقط چون فکر میکردن این بهینه سازی لازم یا مفیده انجامش دادن، ولی در مقابل امنیت رو پایین آوردن و پیچیدگی سیستم رو زیاد کردن.
«بیشتر گناهان کامپیوتری بنام کارایی انجام میشوند». اینا هم شعارشون بهینگی و پرفورمنس بالاست.
(13-07-1394، 11:49 ق.ظ)محسن نوری نوشته: [ -> ]آقای شهرکی فکر نمیکنم این حرفم کورکورانه باشه! حداقل به نظر خودم که منطقیه
نه منظورم شما نبودین. اینکه جناب Eshpilen گفتن «وقتی سمت کلاینت اینطوریه معلومه سمت سرور و تولید کدش هم همینطوریه» رو گفتم.
ضمناً فراموش نکنید ولیدیشن سمت کلاینت
فقط و فقط برای راحتی کلاینته و اعتبارش
اصلاً سمت سرور مهم نیست و فرضاً کسی بتونه اون رو مخدوش هم کنه، سمت سرور باز اعتبارسنجی انجام میشه. توی هر درخواست، Salt عوض میشه و فرضاً برای یه کپچای ثابت که هنوز هم عوض نشده (همون کپچای قبلی)، توی درخواستهای متوالی کد هش متفاوتی برای کلاینت ارسال میشه و جمع ارقام هم باید یه چیز دیگه در بیاد. اینقدرها هم تیم توسعه Yii اون جوری که فکر میکنید ناشی نبودن! تیم توسعه Yii و بخصوص خالق اصلیش 7 سال جزو تیم توسعه اصلی Prado بودن و به حد کافی در زمینه امنیت تا جایی که میدونم مطالعه و تحقیق داشتن. سایر فریمورکها هم همینطورن (دوباره بحث طرفداری از Yii رو پیش نکشید).
بحث پردازش تصویر رو هم که مطرح کردین، مربوط به Yii نیست و کلاً ReCaptcha قبلی گوگل لو رفته بود. با تمام این تفاسیر، به راحتی میتونید کپچای سفارشی خودتون رو بسازین و فقط قسمت تولید تصویر و... رو پیچیده تر کنید تا کسی نتونه دورش بزنه.
میگم اگه ما با canvas کپتچا درست کنیم و توی مموری جاوااسکریپت ذخیره کنیم، اسپمر از کجا میتونه اونو بخونه؟!
(13-07-1394، 01:08 ب.ظ)ADMIN نوشته: [ -> ]نه منظورم شما نبودین. اینکه جناب Eshpilen گفتن «وقتی سمت کلاینت اینطوریه معلومه سمت سرور و تولید کدش هم همینطوریه» رو گفتم.
مهندس اصلا دقت نمیکنی ها!
والا من کجا چنین حرفی زدم؟
اول محسن خودش گفت که «اشپیلن جان دور زدن کپچای پیشفرض yii با پردازش تصویر خیلی ساده است! مدیر بخش پردازش تصویر در سایت برنامه نویس فقید Big Grin رباتش رو نوشته بود» منم گفتم « پس لابد کد تولید تصویر کپچاش هم غیرحرفه ایه» و بقیهء ماجرا! من بر اساس حرف ایشون استناد کردم و تازه گفتم لابد! نگفتم قطعا اینطوریه.
نقل قول:ضمناً فراموش نکنید ولیدیشن سمت کلاینت فقط و فقط برای راحتی کلاینته و اعتبارش اصلاً سمت سرور مهم نیست و فرضاً کسی بتونه اون رو مخدوش هم کنه، سمت سرور باز اعتبارسنجی انجام میشه. توی هر درخواست، Salt عوض میشه و فرضاً برای یه کپچای ثابت که هنوز هم عوض نشده (همون کپچای قبلی)، توی درخواستهای متوالی کد هش متفاوتی برای کلاینت ارسال میشه و جمع ارقام هم باید یه چیز دیگه در بیاد. اینقدرها هم تیم توسعه Yii اون جوری که فکر میکنید ناشی نبودن! تیم توسعه Yii و بخصوص خالق اصلیش 7 سال جزو تیم توسعه اصلی Prado بودن و به حد کافی در زمینه امنیت تا جایی که میدونم مطالعه و تحقیق داشتن. سایر فریمورکها هم همینطورن (دوباره بحث طرفداری از Yii رو پیش نکشید).
مهندس من نمیدونم واقعا متوجه نمیشی یا مسئله چیز دیگه ایه!
اصلا به سمت سرور کاری نداره. شما یه کدی رو بصورت تصویر کپچا میفرستی سمت کلاینت، کلاینت اگر هیچ اطلاعات دیگری نداشته باشه مجبوره پردازش تصویر کنه تا کد کپچا رو تشخیص بده، ولی وقتی شما یک checksum از کد مورد نظر رو هم براش ارسال کردی، این یه اطلاعات اضافیه که میتونه در پردازش تصویر برای افزایش ضریب موفقیت تشخیص درست کمک کنه، چون به کمک اون میتونه چک کنه آیا کدی که پردازش تصویر تشخیص داده با اون checksum سازگاری داره یا نه و میتونه درست باشه یا نه. اگر دید کد نمیتونه درست باشه چون checksum اش درست درنمیاد، میتونه احتمالات محتمل دیگر رو بررسی کنه. این checksum اگر نباشه خب میاد همون حدس اول رو ارسال میکنه که اینطوری طبیعتا شانس موفقیتش کمتره.
و حتی اصلا بحث کمک پردازش تصویر هم به کنار، حمله هایی که هر بار یک کد بصورت رندوم ارسال میکنن میتونن به کمک این checksum ممکن بشن، چون کلاینت میتونه تعداد حالتهای ممکن برای کد کپچایی رو که دریافت کرده خیلی محدودتر بکنه و از میان یک مجموعهء خیلی کوچکتری شانس خودش رو امتحان کنه. یه مثال کاملا فرضی میزنم: مثلا فرض کن کلاینت checksum برابر با 639 رو دریافت میکنه، درآوردن اینکه کدوم کدها چنین checksum ای دارن کار سختی نیست، مثلا میبینه 200 تا کد ممکن وجود دارن که چنین checksum ای تولید میکنن، میاد یکی رو بصورت رندوم انتخاب میکنه و به سرور میفرسته، حالا کد ارسال شده یا ممکنه شانسی درست بوده باشه یا نبوده باشه، بهرحال اگر 200 تا درخواست به این صورت ارسال کنه بالاخره انتظار میره حداقل یکیش شانسی درست دربیاد. غیر از اینه؟ ربطی هم به کپچاهای قبلی و جدید نداره که عوض میشن و این حرفا. هر بار یک کپچای جدید میگیره با checksum خودش و میتونه اون مجموعهء 200 کد ممکن رو براحتی دربیاره و به این شکل هر بار با احتمال یک در 200 شانس خودش رو امتحان میکنه. پس در مجموع بطور میانگین به ازای هر 200 تلاش و درخواستی که ارسال میکنه، یکیش موفق میشه. برای خیلی جاها و اسپمرها و هکرها هست که صرف میکنه 200 تا درخواست بفرستن تا بالاخره یکیش موفق بشه.
ولی حالا شما فرض کن اون checksum وجود نداشت. کد کپچا بطور معمول وقتی چند میلیون حالت ممکن داره که احتمال وقوع هرکدام برابره، دیگه چنین شانسی وجود نداره طرف 100 هزارتا درخواست هم با کد رندوم بفرسته به نتیجه نمیرسه، بنابراین کسی چنین کاری نمیکنه.
بطور کلی شما هر اطلاعات اضافه ای از کد کپچا به سمت کلاینت بفرستی، یعنی تضعیف اون کد. بخاطر همین هم هست که بطور معمول هیچکس کد کپچا رو سمت کلاینت ولیدیت نمیکنه.
نقل قول:فرضاً برای یه کپچای ثابت که هنوز هم عوض نشده (همون کپچای قبلی)، توی درخواستهای متوالی کد هش متفاوتی برای کلاینت ارسال میشه و جمع ارقام هم باید یه چیز دیگه در بیاد.
ببخشید عملکرد این تابع بنظرم کاملا واضح هست:
/**
* Generates a hash code that can be used for client side validation.
* @param string $code the CAPTCHA code
* @return string a hash code generated from the CAPTCHA code
*/
public function generateValidationHash($code)
{
for ($h = 0, $i = strlen($code) - 1; $i >= 0; --$i) {
$h += ord($code[$i]);
}
return $h;
}
کجاش شما اثری از سالتی چیزی میبینی؟!
یک کد رو میگیره و جمع کد اسکی کاراکترهاش رو بعنوان هش برای سمت کلاینت تولید میکنه.
وقتی کد کپچا عوض نشده باشه هشش هم عوض نمیشه همیشه یک عدد خاص ثابت درمیاد.
همینطور به کد سمت کلاینت برای مقایسهء هشی که سمت کلاینت خودش مجددا محاسبه و با هش پاس شده توسط سرور مقایسه میکنه اگر دقت کنیم متوجه میشیم که هیچ سالتی بکار نرفته و کد چه در سمت کلاینت و چه در سمت سرور با یک روش ثابت و ساده ای بدست میاد و مقایسه میشه:
captcha: function (value, messages, options) {
if (options.skipOnEmpty && pub.isEmpty(value)) {
return;
}
// CAPTCHA may be updated via AJAX and the updated hash is stored in body data
var hash = $('body').data(options.hashKey);
if (hash == null) {
hash = options.hash;
} else {
hash = hash[options.caseSensitive ? 0 : 1];
}
var v = options.caseSensitive ? value : value.toLowerCase();
for (var i = v.length - 1, h = 0; i >= 0; --i) {
h += v.charCodeAt(i);
}
if (h != hash) {
pub.addMessage(messages, options.message, value);
}
},
الان کجای این کد معلوم نیست که داره چکار میکنه سالتی در کار هست یا نیست؟!
بعدم تازه این سالت که شما میگی حتی اگر هم وجود داشت بازم در اصل ماجرا فرقی نمیکرد، چون بهرحال اگر سمت کلاینت بخواد ولیدیت کنه باید این سالت هم به سمت کلاینت ارسال بشه تا کلاینت بتونه به کمک اون هش رو به درستی محاسبه و با هش تولید شده در سمت سرور (و ارسال شده به سمت کلاینت) مقایسه کنه. عملا هیچ فرقی نمیکنه سالتی در کار باشه و برای یک کد ثابت مقدار هش عوض بشه یا نه، چون بهرحال سمت کلاینت میتونه این هش رو محاسبه و با هش ارسال شده مقایسه کنه ببینه کد میتونه درست باشه یا نه.
میشه جوابه سوال منم بدید؟
خیر در مجموع بطور یک در دویست شانس درس بودن رو نداره چون در هر چند درخواست، کپچا عوض میشه و دوباره باید یه مجموعه بقول شما دویست تایی و در عمل و با نگاه منطقی تر، چند ده هزار تایی از حالتهای مختلف رو تست کنه تا یکیش درست در بیاد. درهرصورت همونطور که گفتم، من توی پروژه های خودم از کپچای اختصاصی که برای اینکار نوشتم استفاده میکنم و البته برای Yii1.1 هم چون چند وقته کار نمیکنم، یادم نبود سالت نداره اما زیاد مهم نیست و بهرحال این ولیدیشن سمت کلاینت رو میشه براحتی غیرفعال کرد و من خودم هم از AJAX Validation استفاده میکنم.
(13-07-1394، 02:48 ب.ظ)n0o0b_sina نوشته: [ -> ]میگم اگه ما با canvas کپتچا درست کنیم و توی مموری جاوااسکریپت ذخیره کنیم، اسپمر از کجا میتونه اونو بخونه؟!
توی مموری JS چطور ذخیره میکنید؟ منظورم اینه که بدون اینکه از سمت سرور چیزی بیاد برای کلاینت، حالا یا توی هدر و یا توی بدنه درخواست، چطور حافظه سمت کلاینت رو دستکاری میکنید؟ هکر میتونه هر دو مورد رو بخونه.
این کدهایی که دادم برای yii2 هست. اسمه فایلو گذاشتم میتونید برید ببینید.
---
خب هکر چطوری قرار محتوای متغیر رو بخونه؟
ما هر بار که با canvas یه عکس گرافیکی درست کردیم حروفشو مثلا توی متغیر x ذخیره میکنیم، میدونید که نحوه ی کار جاوااسکریپت مثله php نیست.
تو این حالت فقط یه مشکل داریم اونم غیر فعال بودن js هست، که میتونیم کلا سایت رو نشون ندیم.
(14-07-1394، 08:14 ق.ظ)ADMIN نوشته: [ -> ]خیر در مجموع بطور یک در دویست شانس درس بودن رو نداره چون در هر چند درخواست، کپچا عوض میشه
خب عوض بشه. چه ربطی داره؟
ما هر بار یک تصویر کپچا (حاوی یک کد) و هش اون کد رو از سرور دریافت میکنیم، بعد بررسی میکنیم چه کدهای ممکنی اون هش رو تولید میکنن. یکیش رو بصورت تصادفی به سرور ارسال میکنیم. حالا تعداد کدهای ممکن شاید 200 تا 1000 تا شاید کمتر شاید بیشتر، میشه با ریاضی محاسبه کرد. بهرحال ما همهء این کارها رو سمت کلاینت و هر بار داریم انجام بدیم ربطی به اینکه کپچا عوض بشه یا نشه نداره! هر کپچایی که دریافت میکنیم همراه با هش مخصوص خودش هست، که همین برای کار ما کافیه.
چون تعداد حالتهای کد کپچا کم هست، در نتیجه میشه همهء حالتها رو در زمان کوتاهی چک کرد. تازه اگر الگوریتم بهینه تری براش نباشه و نیاز باشه همه رو چک کنیم (Brute-force محض). امروزه روز بالای یک میلیارد هش md5 رو در کسری از ثانیه روی PC های معمولی on the fly تولید و مقایسه میکنن، حالا این هش که اینا از خودشون اختراع کردن اولا بنظرم از md5 پردازش کمتری داره، دوما و خیلی مهمتر اینکه کل تعداد حالتهای کد کپچا هم نهایت چند ده میلیون بیشتر نیست، بنابراین ما هر بار میتونیم تمام کدهایی رو که هش مورد نظر رو تولید میکنن در زمان کوتاهی پیدا کنیم.
چرا دوست عزیز متوجه نمیشین که میگم این ولیدیشن سمت کلاینت هیچ اعتباری نداره؟ به فرض که چند حالت تصادفی رو هم پیدا کردین. احتمال اینکه این رمز شما که یکی از حالتهای ممکنه که فقط از بین این حالتها، 1 عدد رمز درست وجود داره، در حالت پیشفرض کپچا که 6 حرف الفبا هست، میشه 1/308915776 و این عدد خیلی بیشتر از چیزیه که تصور میکنید. حالا تازه کلاً توی حالت پیشفرض 3 بار فرصت دارین این رو تست کنید و بعد کپچا عوض میشه. شما اگه حالتهای ممکن دیگه اون جمع ارقام (هش) رو هم در آورده باشین، با ارسال اونها سمت سرور جواب میگیرین «کد امنیتی اشتباه است» چون اون حالت شما، یکی از حالتهای Fake بوده نه کد اصلی و فقط تونستین ولیدیشن سمت کلاینت رو فریب بدین.
باز هم تأکید میکنم پیداکردن کدهایی که هش موردنظر رو تولید میکنن، به معنای پیدا کردن کد امنیتی سمت سرور نیست!