WeiXinVote
1.0.0
لقد رأيت مؤخرًا منشورًا لحشد الأصوات على WeChat، وأجريت بعض الأبحاث حوله عندما لم يكن لدي ما أفعله، ووجدت أن هذا النشاط يمكن استخدامه لتجاهل الأصوات. وسأسجل بإيجاز عملية كتابة السيناريو لتجاهل الأصوات. في الواقع، يعد تنفيذ هذا النوع من تعليمات الزاحف دائمًا مشكلة صغيرة. الشيء المهم هو أنك تحتاج إلى معرفة منطق صفحات الآخرين وكيفية تحليلها والزحف إليها.
افتح صفحة التصويت في WeChat، واسحب الشاشة للأسفل وستجد أن "صفحة الويب هذه مقدمة بواسطة XXX" معروضة في الجزء العلوي من الشاشة. تجدر الإشارة إلى أن "XXX" هنا ليس "mp.weixin.qq. com"، ولكن اسم مجال الطرف المنظم للحدث. بمعنى آخر، يتم تشغيل برنامج نشاط التصويت هذا على خادم S Mall. يتضمن ذلك مفهوم OpenID لمنصة WeChat العامة. التفسير الرسمي لـ OpenID هو: بعد تشفير معرف WeChat، يكون لدى كل مستخدم OpenID فريد لكل حساب رسمي. أي أن المستخدم لديه OpenId فريد لحساب عام.
منطق التصويت هو أن المستخدم سيقدم معرف OpenID الخاص به في معلمة POST عند تقديم طلب التصويت بعد تلقي طلب التصويت POST، يمكن لخادم S mall حظر مستخدم واحد عن طريق الاستعلام عما إذا كان OpenID الحالي قد صوت في غضون 4 ساعات؛ يتكرر فعل التصويت.
ومع ذلك، هناك ثغرة كبيرة هنا!
يمكن لـ S Mall فقط تحديد ما إذا كان OpenID مكررًا، لكن لا يمكنه التحقق من صحة OpenID لأنه لا يمكنه الاتصال بخادم WeChat للتحقق من OpenID.
ثم نحتاج فقط إلى إنشاء OpenId يتوافق مع التنسيق وإرسال طلب نشر.
لكن التصويت الواحد هو أيضًا أمر غريب لأنه يتم إجراؤه في خطوتين. المرة الأولى هي طلب الحصول (الجزء المشفر في الصورة مخصص للخصوصية. ما عليك سوى معرفة أنه يتم إكمال صوت واحد من خلال طلبين.
عندما رأيت اسم الطلب الأول، اعتقدت أن الطلب مكتمل، لكن عند استخدام الزاحف للوصول إلى هذه الواجهة، لم يزيد عدد الأصوات. وبعد الفحص الدقيق، اكتشفت أن هناك طلبًا آخر.
مسار هذا الطلب غريب جدًا، فهو عبارة عن سلسلة من الأحرف المشوهة، ويختلف في كل مرة. بعد تشغيل الطلب الأول فقط، لم يتم تنفيذ أي عمليات أخرى في هذا الوقت، يمكنني التأكد من أن التصويت سيتم من خلال الحصول على بعض المعلمات التي تم إنشاؤها عشوائيًا من خلال الطلب الأول، ثم إحضار هذه المعلمات مع الطلب الثاني لضمان الشرعية بالنسبة للطلب الثاني، فهذا يكمل عملية التصويت. لذلك يجب أن يكون هناك مكان ما في صفحة الطلب الأول الذي يستدعي الطلب الثاني. عندما تحققت من الكود المصدري في هذا الوقت، وجدت أن هناك سلسلة من التعليمات البرمجية مثل هذه في الصفحة
عندما يتم العثور على أحرف مشوهة في الصفحة، فغالبًا ما يكون ذلك بسبب تشفير الكود.
اثنان من المعلمات هما مساران للطلب الثاني. ويمكن ملاحظة أن هذه السلسلة من الأحرف المشوهة مرتبطة بالطلب الثاني، وسلسلة الرموز التعبيرية هي تشفير كود js. على الرغم من أننا لا نفهم ما تعنيه هذه السلسلة من الأحرف المشوشة، إلا أنه يمكننا الضغط على الفاصلة المنقوطة (؛) لتنسيق سلسلة الأحرف المشوشة وتشغيلها مباشرة في وحدة تحكم Chrome لتنفيذ الطلب الثاني (يجب أن يكون هذا المكان قادرًا على استعادة الرمز. إذا كنت تعرفه، فيمكنك شرحه.)
يتم ذلك بشكل أساسي، والباقي هو تنفيذ التعليمات البرمجية بشكل عام، وهو الوصول إلى الطلب الأول، واستخدام التعبيرات العادية للزحف إلى المعلمات في الصفحة، واستخدام المعلمات كمسار للطلب الثاني لمعالجة الطلب الثاني. طلب الوصول. بالطبع، يوجد أيضًا وكيل IP، مع فترات زمنية عشوائية للوصول، ومن الأفضل محاكاة الأجهزة المختلفة ديناميكيًا، أي أننا لن نشرح المشكلات الشائعة المتعلقة بتعديل وكيل المستخدم ، يمكنك إرسال بريد إلكتروني.
بشكل عام، ليس من الصعب تنفيذ التعليمات البرمجية باستخدام بايثون. تكمن الصعوبة في التحليل خطوة بخطوة، وإتقان منطق الموقع، والمحاولة المستمرة. لن يكون هذا فعالاً إلا إذا قمت بذلك أكثر
