دوستان ایا روش yii برای چک کردن کپتچا امنه؟
yii کد تولید شده رمزنگاری میکنه (چون جاوااسکریپت تو چشمه راحت میشه دکدش کرد) و بعد توی data المنت body ذخیره میکنه
---
خب این امنه؟ اگه امنه خیلی بهتر از ajax هستش
من الان نگاه کردم، کد کپتچا رو تبدیل به char code میکنه توی هر 2 طرف بعد با هم جمع میکنه، خب چه کاریه؟! یه دفعه متنه کپتچا رو بزاره دیگ
اگه کسی میدونه چرا یه توضیچی به ما بده
البته شایدم خواسته حجمش بیاد پایین نمیدونم!!!
دوست عزیز، توی Yii هر دفعه متن رو هش کنید، یه رمز جدید تولید میشه. برای اینه که از روی متن شما نتونن حدس بزنن رمز اصلی چیه.
نه رمز جدید تولید نمیشه، من کپتچا رو میگم با رمز کاری ندارم که، اونم توی هر بار رفرش کپتچا مقدار دیتای المنت body تغییر میکنه، و هر بار حروف کپتچا رو به char code تبدیل میکنه و با هم جمع میکنه، من میخوام بدونم:
1- این روش اعتبار سنجی برای کپتچا امنه؟
2- چرا char code هارو با هم جمع میکنه و حروف معمولی رو اعتبار سنجی نمیکنه؟
امیدوارم متوجه شده باشید
کجا چنین چیزی دیدین؟ این کدی هست که من توی متد validate دیدم:
public function validate($input,$caseSensitive)
{
$code = $this->getVerifyCode();
$valid = $caseSensitive ? ($input === $code) : strcasecmp($input,$code)===0;
$session = Yii::app()->session;
$session->open();
$name = $this->getSessionKey() . 'count';
$session[$name] = $session[$name] + 1;
if($session[$name] > $this->testLimit && $this->testLimit > 0)
$this->getVerifyCode(true);
return $valid;
}
این کد جاوا اسکریپت برای اعتبار سنجی کد کپتچایی هست که از کاربر گرفته میشه، دقت کنید ورودی کاربر تبدیل به char code میشه و با هم جمع میشن.
yii.validatin.js
line 246
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);
}
},
---
هش بالا که از المت body گرفته میشه اینجوری تولید میشه، وقیقا char code هر حرف رو میگیره و جمع میکنه، بعدش پاس میده به المت body تا سمته کاربر اعتبار سنجی انجام بشه
/**
* 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;
}
دوست عزیز، این Validation سمت کاربر برای این به این صورت انجام میشه که توی سورس کدی که سمت کاربر میاد، کد کپچای سمت سرور دیده نشه تا نتونه با cURL اون رو بخونه و دور بزنه.
آره اینجوری نمیتونه بخونه
من اولین باره دارم این مدلیشو میبینم
---
بعد یه سوال دیگ، چرا همه از ajax استفاده میکنن؟ این روش بهتر نیست؟
تشکر
تاجاییکه بنده میدونم و به ذهنم میرسه، هر نوع هشی که از کد کپچا گرفته بشه و سمت کلاینت درج بشه، امنیت کد کپچا رو به میزان زیادی پایین میاره. این تابع که دارم میبینم هم تاجاییکه میفهمم یک هش من درآوردی تولید میکنه، که اگر به مراتب بدتر نباشه بهتر از هش های استاندارد هم نیست!
اصولا ولیدیشن کپچا در سمت کلاینت معنی نداره. چون اگر بشه درست بودن کد کپچا رو سمت کلاینت (بدون ارتباط با سرور) تست کرد پس میشه براحتی الگوریتم Brute-force سمت کلاینت براش نوشت. از اونجایی که تعداد حالتهای ممکن کدهای کپچا بسیار کمه، در برابر Brute-force هیچ مقاومتی ندارن و در کسر کوچکی از ثانیه کرک میشن.
مثلا شما فرض کنید یک کد کپچای 5 کاراکتری، متشکل از حروف انگلیسی و اعداد، کلا 60466176 حالت بیشتر نداره. تمام این تعداد حالت رو در کسر کوچکی از یک ثانیه میشه تست کرد!
البته این تابعی که نوشته همینطور سطحی نگاه میکنم بنظرم میشه نتیجه گرفت که برای چندین کد کپچای متفاوت یک مقدار یکسان میده! چون مقدار کد اسکی کاراکترها رو با هم جمع کرده. این یعنی اینکه ترتیب کاراکترها در نتیجش تفاوتی ایجاد نمیکنه. یعنی مثلا کد بدست اومده برای abc با کد بدست آمده برای cba و cab یکسانه. در نتیجه کرکر در اینجا با Brute-force کردن یک نتیجهء قطعی بدست نمیاره، بلکه چندین نتیجهء محتمل بدست میاره، که اگر شانسی نتیجهء درست رو به سرور بفرسته قبول میشه ولی اگر مورد غلطی رو بفرسته باید از اول شروع کنه.
ولی بهرحال اینم تاجاییکه من میدونم باز پایین آوردن امنیت کد کپچا رو در پی داره، چون تعداد حالتهای ممکن رو به شدت کاهش میده.
ضمنا اصلا لازم نیست کاراکترها دقیقا یکسان باشن همونا باشن و فقط ترتیبشون عوض بشه! بلکه ممکنه کاراکترها هم تغییر بکنن اما بازم جمع کد اسکی اونا همون عدد بشه.
پس میتونیم بگیم این یک نوع تابع هش خیلی ضعیف هست و فقط خطاهای محدودی رو میشه باهاش تشخیص داد. پس اونوقت دیگه این چجور ولیدیشنی میشه که طرف اشتباه هم وارد کنه ممکنه بعنوان درست تشخیص داده بشه؟!
این ولیدیشن سمت کلاینت اصلاً اعتبار نداره و فقط برای راحتی بیشتر خود کلاینته و بهرصورت سمت سرور هم اعتبارسنجی میشه. پس خطری توی امنیت ایجاد نمیکنه. هدف فقط این بوده که کد اصلی کپچای سمت سرور توی سورس کد سمت کلاینت درج نشه.
بله میدونم که سمت سرور ولیدیت میشه. ولی موضوع اینه که شما با این کار یه اطلاعاتی رو به سمت کلاینت میفرستید که میتونه برای کرک کردن کد کپچا کمک بزرگی باشه!
فرض کنید مثلا خیلی الگوریتم های پردازش تصویر، برای یک کد کپچا چند نتیجه بدست میارن. یعنی چند نتیجه که احتمالا یکی از اونا درسته. حالا فرضا برنامه ای که اطلاع کمکی دیگری از کد کپچا نداره مجبوره یکی از اون کدها رو به سمت سرور ارسال کنه به این امید که درست باشه، و اگر نادرست باشه، کد کپچا عوض میشه و باید دوباره یک کد کپچای جدید رو کرک کنه. ولی حالا با این اطلاعات کمکی که در سمت کلاینت داره میتونه شانس موفقیت خودش رو بالاتر ببره، چون میتونه نتایج ممکن رو با روش هش این تابع چک کنه ببینه کدوم یا چندتاشون کد هش یکسانی دارن، و اینطوری هست که شانس کرک موفقیت آمیز کپچا بالاتر میره. این فقط یک سناریو بود که گفتم! بیش از این میشه در این مورد صحبت کرد. اصولا در کرک کد کپچا این مطرح نیست که حتما باید با ضریب احتمال 100% نتیجه درست باشه، بلکه ضریب موفقیت به یک درصد قابل توجهی هم برسه (شاید حتی 5%)، کفایت میکنه و اون کپچا شکسته شده محسوب میشه، چون بهرصورت اسپمرها و هکرها از چنین حدی از موفقیت هم میتونن استفاده کنن و این برای سایت میتونه دردسرساز باشه.
بنظر من، با اطلاعاتی که تاحالا در این زمینه دارم، این تابع و ولیدیشن سمت کلاینت، یک کار غیرحرفه ای و ناشیانه ای هست.
حالا بازم شک دارید من میخوام توی جای مناسبش مطرح کنم ببینیم متخصصان چه جوابی میدن!
مسئله دقیقاً همینه که الگوریتمی که انتخاب شده هیچ کمکی به کرک کردن کپچای سمت سرور نمیکنه. یک هش با همون سیستم داره تولید میشه که با توجه به قرارگرفتن یک کد خاص و تصادفی در سمت سرور برای تولید این هش از روی کد کپچا (مفهومی شبیه Salt) عملاً توی درخواست بعدی بدرد نمیخوره و از اونجا که خود کپچا هم بعد از هر 3 درخواست (در حالت پیشفرض) عوض میشه، عملاً کاربردی نداره. اگه به کد دقت کنید میبینید که یه متغیر hash توی JS تعریف شده که توسط سرور ساخته میشه و توی هر درخواست فرق میکنه. این موضوع باعث میشه عملاً نتایج کشف شده توسط هکر فقط توی همون درخواست یا نهایتاً اگه تنظیمات پیشفرض رو تغییر ندیم، توی 3 درخواست متوالی اعتبار داشته باشه. از اونجا که Salt هم سمت سرور مرتباً عوض میشه، راهی برای دسترسی به کپچای سمت سرور وجود نداره. بعلاوه میشه برای امنیت بیشتر، بجای clientValidation از ajaxValidation استفاده کرد یا اصلاً برای فیلد کپچا ولیدیشن سمت کلاینت رو خاموش کرد. همه این حالتها برای راحتی بیشتر کاربران درنظر گرفته شده و مسائل امنیتی توسط افراد خبره مرتباً داره چک میشه. پیشنهاد میکنم سورس CCaptchaAction و همچنین CCaptcha رو توی گیت هاب Yii1.1 بررسی کنید.
(13-07-1394، 10:12 ق.ظ)Eshpilen نوشته: [ -> ]بله میدونم که سمت سرور ولیدیت میشه. ولی موضوع اینه که شما با این کار یه اطلاعاتی رو به سمت کلاینت میفرستید که میتونه برای کرک کردن کد کپچا کمک بزرگی باشه!
فرض کنید مثلا خیلی الگوریتم های پردازش تصویر، برای یک کد کپچا چند نتیجه بدست میارن. یعنی چند نتیجه که احتمالا یکی از اونا درسته. حالا فرضا برنامه ای که اطلاع کمکی دیگری از کد کپچا نداره مجبوره یکی از اون کدها رو به سمت سرور ارسال کنه به این امید که درست باشه، و اگر نادرست باشه، کد کپچا عوض میشه و باید دوباره یک کد کپچای جدید رو کرک کنه. ولی حالا با این اطلاعات کمکی که در سمت کلاینت داره میتونه شانس موفقیت خودش رو بالاتر ببره، چون میتونه نتایج ممکن رو با روش هش این تابع چک کنه ببینه کدوم یا چندتاشون کد هش یکسانی دارن، و اینطوری هست که شانس کرک موفقیت آمیز کپچا بالاتر میره. این فقط یک سناریو بود که گفتم! بیش از این میشه در این مورد صحبت کرد. اصولا در کرک کد کپچا این مطرح نیست که حتما باید با ضریب احتمال 100% نتیجه درست باشه، بلکه ضریب موفقیت به یک درصد قابل توجهی هم برسه (شاید حتی 5%)، کفایت میکنه و اون کپچا شکسته شده محسوب میشه، چون بهرصورت اسپمرها و هکرها از چنین حدی از موفقیت هم میتونن استفاده کنن و این برای سایت میتونه دردسرساز باشه.
بنظر من، با اطلاعاتی که تاحالا در این زمینه دارم، این تابع و ولیدیشن سمت کلاینت، یک کار غیرحرفه ای و ناشیانه ای هست.
حالا بازم شک دارید من میخوام توی جای مناسبش مطرح کنم ببینیم متخصصان چه جوابی میدن!
اشپیلن جان دور زدن کپچای پیشفرض yii با پردازش تصویر خیلی ساده است!
مدیر بخش پردازش تصویر در سایت برنامه نویس فقید
رباتش رو نوشته بود.
در ضمن اکر موقع خوندن کپچای yii به چندتا نتیجه رسید کافیه صفحه رو رفرش کنه تا کپچای فعلی با حالت دیگه ای تولید بشه و اینطوری احتمال خطای ربات هم کمتر میشه.
ماشالا اکثر برنامه نویسا هم که به این مساله توجه نمیکنن!!
(13-07-1394، 10:25 ق.ظ)محسن نوری نوشته: [ -> ]اشپیلن جان دور زدن کپچای پیشفرض yii با پردازش تصویر خیلی ساده است! مدیر بخش پردازش تصویر در سایت برنامه نویس فقید رباتش رو نوشته بود.
پس لابد کد تولید تصویر کپچاش هم غیرحرفه ایه.
پس این تشکیلات ولیدیشن سمت کلاینت هم که گذاشتن حکایت مورچه چیه که کله پاچش چیه، گفتن کد کپچای ما بهرحال ضعیفه حالا فرقی نمیکنه چندتا ترفند غیرحرفه ای دیگه هم استفاده کنیم یا نکنیم بذار حداقل از نظر یوزرفرندلی و پرفورمنس ارتقا بدیم!
نقل قول:در ضمن اکر موقع خوندن کپچای yii به چندتا نتیجه رسید کافیه صفحه رو رفرش کنه تا کپچای فعلی با حالت دیگه ای تولید بشه و اینطوری احتمال خطای ربات هم کمتر میشه.
حالا اونکه من گفتم فقط مثال بود. اصلا نمیدونم تاحالا ندیدم این برنامه های کرک چه انواعی دارن چطور کار میکنن، ولی بهرصورت میدونم که هر نوع اطلاعات کمکی میتونه در کرک به کمک پردازش تصویر استفاده بشه و شانس موفقیت و آمار کرک موفقیت آمیز رو بالا ببره.
شما اصلا فرض کن ما پردازش تصویر هم نمیکنیم و صرفا از راه تصادفی اقدام میکنیم. یعنی هر بار یک کد تصادفی به سرور میفرستیم میگیم خب مثلا هزار درخواست فرستادیم بالاخره یکیش تصادفی درست درمیاد! کپچاهای حرفه ای طوری طراحی میشن که این آمار اونقدر پایین باشه که برای هکرها/اسپمرها صرف نکنه. مثلا طرف وقتی میبینه باید 500 هزارتا درخواست بفرسته که یکیش شانسی درست دربیاد، خب براش صرف نمیکنه از نظر زمان و منابع سخت افزاری که باید صرف این کار بشه. ولی هزارتا شاید برای خیلی اسپمرها به صرفه باشه. حالا عددهای دقیقش رو نمیدونم نیاز به تفکر و تحلیل و تحقیق بیشتر و دقیقتر و موثق تری داره، ولی دارم کلیت رو مثال میزنم که داستان اینطوریه.
وقتی شما داری این کد هش رو سمت کلاینت میذاری، یعنی تعداد کدهای تصادفی ای رو که برنامهء هکر باید هر بار از بین اونا یکی رو بصورت تصادفی بفرسته به شدت کاهش میدی، و این یعنی به تعداد خیلی کمتری درخواست نیازه تا تصادفا یکیش درست دربیاد. چون هر بار هکر میدونه که چه ترکیبی از کاراکترها یک هش خاص رو تولید میکنن، و این ترکیب کاراکترها تعداد کمی هستن، نه کل حالتهای ممکن برای کدهای کپچا.
نقل قول:ماشالا اکثر برنامه نویسا هم که به این مساله توجه نمیکنن!!
کدوم مسئله؟