<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Toctou on Crusader Research</title>
		<link>https://crusaderproxy.com/research/ar/tags/toctou/</link>
		<description>Recent content in Toctou 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/tags/toctou/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>
	</channel>
</rss>
