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