<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Bug Class Deep Dives on Crusader Research</title>
		<link>https://crusaderproxy.com/research/ar/series/bug-class-deep-dives/</link>
		<description>Recent content in Bug Class Deep Dives on Crusader Research</description>
		<generator>Hugo</generator>
		<language>ar</language>
		
		
		
		
			<lastBuildDate>Sun, 05 Jul 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://crusaderproxy.com/research/ar/series/bug-class-deep-dives/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>الفوز بثغرات حالة السباق في الويب باستخدام single-packet attack</title>
				<link>https://crusaderproxy.com/research/ar/posts/winning-the-race-condition-bugs/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/ar/posts/winning-the-race-condition-bugs/</guid>
				<description>&lt;p&gt;معظم الشروحات تخبرك أن race condition هي &amp;ldquo;نافذة زمنية بين الفحص والاستخدام&amp;rdquo;. صحيح، لكنه عديم الفائدة — لأن سبب فشل هجمات السباق لديك ليس أنك لا تفهم المفهوم. السبب أن &lt;strong&gt;النافذة أصغر مما هي عليه دقة الإنترنت.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;نافذة السباق النموذجية — الفجوة بين قراءة التطبيق لـ&lt;code&gt;balance&lt;/code&gt; وكتابته لـ&lt;code&gt;balance - amount&lt;/code&gt; — تُقاس بـ&lt;strong&gt;الميكروثواني إلى بضعة مللي ثوانٍ&lt;/strong&gt;. أما التذبذب بين طلبَي HTTP تُرسلهما في اللحظة &lt;em&gt;نفسها&lt;/em&gt;، بحلول وقت &lt;em&gt;وصولهما&lt;/em&gt; وجدولتهما على الخادم، فيتراوح عادةً بين &lt;strong&gt;1 و10 مللي ثوانٍ&lt;/strong&gt;، وأسوأ عبر الإنترنت العام. فتصل طلباتك &amp;ldquo;المتزامنة&amp;rdquo; في صفٍ أنيقٍ صغير، ويعالجها الخادم واحدًا تلو الآخر، ويصمد الحد، فتستنتج أن نقطة النهاية آمنة. إنها ليست كذلك. أنت فقط خسرت السباق أمام التذبذب الشبكي قبل أن يكون للخادم رأي أصلًا.&lt;/p&gt;</description>
			</item>
			<item>
				<title>تجاوز الفلاتر السهلة في SSRF: التباس محلّل الـ URL ونقطة نهاية بيانات التعريف</title>
				<link>https://crusaderproxy.com/research/ar/posts/ssrf-past-the-easy-filters/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/ar/posts/ssrf-past-the-easy-filters/</guid>
				<description>&lt;p&gt;تزوير الطلب من جانب الخادم (SSRF) هو أحد أصناف الثغرات القليلة التي تسلّمك فيها ثغرة واحدة بيانات اعتماد سحابية. الآلية تافهة في وصفها — تجعل الخادم يجلب URL تتحكم فيه — وكل شرح يتوقف عند هذا الحد، وهذا بالضبط سبب عدم جدواها. الحمولة التعليمية، &lt;code&gt;http://169.254.169.254/&lt;/code&gt; الملصقة في حقل URL، محجوبة في كل مكان بقوائم الحظر. السبب في أن SSRF لا يزال أحد أكثر أصناف الثغرات إنتاجية في 2026 ليس أن المطوّرين نسوا الفلترة. بل هو أن &lt;strong&gt;الفلتر الخاص بهم وعميل الـ HTTP لديهم يقرآن الـ URL بطريقتين مختلفتين، وأنت تعيش في تلك الفجوة.&lt;/strong&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>‏IDOR يسكن في المعرّف الثاني: العثور على BOLA عبر Shadow Replay بحسابين</title>
				<link>https://crusaderproxy.com/research/ar/posts/finding-idor-bola-with-shadow-replay/</link>
				<pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/ar/posts/finding-idor-bola-with-shadow-replay/</guid>
				<description>&lt;p&gt;كل دليل تعليمي عن IDOR يسلّمك التمرين نفسه: اعثر على &lt;code&gt;/api/orders/48210&lt;/code&gt;، وغيّره إلى &lt;code&gt;48211&lt;/code&gt;، وابحث عن &lt;code&gt;200&lt;/code&gt;. هذا التمرين يدرّبك على مهاجمة المعرّف الوحيد الذي يُرجَّح أن يتحقق منه التطبيق. المفتاح الأساسي في مسار الـ URL هو حيث تعيش تعليقة &lt;code&gt;@authorize&lt;/code&gt; التي يضعها إطار العمل، وحيث تُحصر استعلامات الـ ORM، وحيث تركّزت المراجعة. إنه الطُّعم. تعبث به، وتحصل على استجابات &lt;code&gt;403&lt;/code&gt;، وتصف النقطة بأنها آمنة، وتمرّ بجوار الثغرة مباشرةً.&lt;/p&gt;&#xA;&lt;p&gt;لأن الثغرة تكاد لا تكون أبدًا في الـ ID الذي تراه. إنها في المعرّف &lt;em&gt;الثاني&lt;/em&gt; — ذاك الذي نسي التطبيق أنه معرّف من الأساس.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
